gcc-4.2.0-20060909 compiles jikes-1.22! very thanks!
The snapshot gcc-4.2.0-20060909 compiles jikes-1.22. It's OK. Thanks Andrew Pinski Obtenga su E-mail GRATUITO en http://www.clanomega.com ___ Get your own Web-based E-mail Service at http://www.zzn.com
Re: libgfortran build broken on Darwin ppc
Eric, You definitely want the autoconf patch added in otherwise builds of libgfortran will crash when older cctools are used (like Xcode 2.3). I'll try a build of current gcc trunk with your new darwin.c correction but without the autoconf patch to see if all the literal16 support exists in Xcode 2.4 or if we need a even newer cctools for that. Jack
Re: Branch st/cli opened to host development of CLI back-end
Hi Roberto, On Thu, 7 Sep 2006, Roberto COSTA wrote: > following previous discussions in this mailing list and the approval > from RMS and the steering committee about a CLI port of gcc, I've opened > a development branch to host its development. The branch is st/cli. would you mind adding a description of that branch (and the rules governing it) to htdocs/svn.html in our wwwdocs CVS module, alongside the other development branches? If you'd like to add a page under htdocs/projects with a longer description, that might be a good idea as well (but that part is optional). Thanks, Gerald
Re: Linker scripts
GCC passes a linker script to the linker for some targets (e.g., powerpc-eabi with -mads). If you specify a linker script using -Wl,-T,script.ld, you get both passed to the linker and there may be conflicts. Is there any option to GCC which says to not pass the predefined linker script to the linker? If you use your own linker scripts, you really shouldn't use gcc to do the linking step; call ld directly, instead. gcc has no idea what your linker script does, so it might well call ld with the wrong options... Segher
-ftree-vectorize can't vectorize plus?
A silly little testcase which the vectorizer doesn't vectorize:
unsigned char qa[128];
unsigned char qb[128];
unsigned char qc[128];
unsigned char qd[128];
void autovectqi (void)
{
int i;
for (i = 0; i < 128; i ++)
qd[i] = qa[i] ^ qb[i] + qc[i];
}
Revision 116799 with '-O3 -fomit-frame-pointer -S -dp -ftree-vectorize
-march=prescott' produces:
autovectqi:
xorl%edx, %edx # 54*movsi_xor [length = 2]
.L2:
movzbl qb(%edx), %eax # 20*movqi_1/3 [length = 4]
addbqc(%edx), %al # 21*addqi_1_lea/2 [length = 3]
xorbqa(%edx), %al # 23*xorqi_1/1 [length = 3]
movb%al, qd(%edx) # 24*movqi_1/7 [length = 3]
addl$1, %edx# 26*addsi_1/1 [length = 3]
cmpl$128, %edx # 27*cmpsi_1_insn/1 [length = 6]
jne .L2 # 28*jcc_1 [length = 2]
ret # 51return_internal [length = 1]
If I change 'qb[i] + qc[i]' to e.g. 'qb[i] & qc[i]' the vectorizer works
fine.
;; Function autovectqi (autovectqi)
[snip lots of stuff]
autovecttest.c:11: note: Access function of PHI: {0, +, 1}_1
autovecttest.c:11: note: Analyze phi: qd_23 = PHI ;
autovecttest.c:11: note: virtual phi. skip.
autovecttest.c:11: note: === vect_analyze_operations ===
autovecttest.c:11: note: examining phi: ivtmp.28_1 = PHI ;
autovecttest.c:11: note: examining phi: i_24 = PHI ;
autovecttest.c:11: note: examining phi: qd_23 = PHI ;
autovecttest.c:11: note: ==> examining statement: :
autovecttest.c:11: note: irrelevant.
autovecttest.c:11: note: ==> examining statement: D.1860_8 = qa[i_24]
autovecttest.c:11: note: num. args = 4 (not unary/binary op).
autovecttest.c:11: note: vect_is_simple_use: operand qa[i_24]
autovecttest.c:11: note: not ssa-name.
autovecttest.c:11: note: use not simple.
autovecttest.c:11: note: ==> examining statement: D.1861_9 = (signed char)
D.1860_8
autovecttest.c:11: note: vect_is_simple_use: operand D.1860_8
autovecttest.c:11: note: def_stmt: D.1860_8 = qa[i_24]
autovecttest.c:11: note: type of def: 2.
autovecttest.c:11: note: no optab.
autovecttest.c:11: note: vect_is_simple_use: operand (signed char) D.1860_8
autovecttest.c:11: note: not ssa-name.
autovecttest.c:11: note: use not simple.
autovecttest.c:11: note: not vectorized: relevant stmt not supported: D.1861_9
= (signed char) D.1860_8
autovecttest.c:11: note: bad operation or unsupported loop bound.
autovecttest.c:11: note: vectorized 0 loops in function.
autovectqi ()
{
unsigned int ivtmp.28;
int pretmp.22;
int i;
unsigned char D.1867;
signed char D.1866;
signed char D.1865;
unsigned char D.1864;
unsigned char D.1863;
unsigned char D.1862;
signed char D.1861;
unsigned char D.1860;
:
# ivtmp.28_1 = PHI ;
# i_24 = PHI ;
:;
D.1860_8 = qa[i_24];
D.1861_9 = (signed char) D.1860_8;
D.1862_12 = qb[i_24];
D.1863_15 = qc[i_24];
D.1864_16 = D.1863_15 + D.1862_12;
D.1865_17 = (signed char) D.1864_16;
D.1866_18 = D.1865_17 ^ D.1861_9;
D.1867_19 = (unsigned char) D.1866_18;
qd[i_24] = D.1867_19;
i_21 = i_24 + 1;
ivtmp.28_2 = ivtmp.28_1 - 1;
if (ivtmp.28_2 != 0) goto ; else goto ;
:;
goto ();
:;
return;
}
[cut]
--
Rask Ingemann Lambertsen
Re: Linker scripts
Segher Boessenkool wrote: GCC passes a linker script to the linker for some targets (e.g., powerpc-eabi with -mads). If you specify a linker script using -Wl,-T,script.ld, you get both passed to the linker and there may be conflicts. Is there any option to GCC which says to not pass the predefined linker script to the linker? If you use your own linker scripts, you really shouldn't use gcc to do the linking step; call ld directly, instead. gcc has no idea what your linker script does, so it might well call ld with the wrong options... There are a number of targets which pass linker scripts to ld, along with whatever libraries or support files (like crti.o) are needed. The spec file insures that the correct options are passed. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Linker scripts
If you use your own linker scripts, you really shouldn't use gcc to do the linking step; call ld directly, instead. gcc has no idea what your linker script does, so it might well call ld with the wrong options... There are a number of targets which pass linker scripts to ld, along with whatever libraries or support files (like crti.o) are needed. The spec file insures that the correct options are passed. No it doesn't, it cannot possibly know _what_ the correct options are, nor whether it should pass library or startup file references. Sure, for some linker scripts that are close enough to the "standard" linker scripts, this might work (modulo the bug in the spec file the original poster seems to hit), but in general, it cannot. The only way to be sure if calling the linker via GCC when doing non-standard linking things will work correctly, is to look at all the arguments that are passed to ld; the only way to make sure it _will_ work correctly is to pass those arguments yourself, directly to ld. Segher
Re: Linker scripts
Segher Boessenkool wrote: If you use your own linker scripts, you really shouldn't use gcc to do the linking step; call ld directly, instead. gcc has no idea what your linker script does, so it might well call ld with the wrong options... There are a number of targets which pass linker scripts to ld, along with whatever libraries or support files (like crti.o) are needed. The spec file insures that the correct options are passed. No it doesn't, it cannot possibly know _what_ the correct options are, nor whether it should pass library or startup file references. Sure, for some linker scripts that are close enough to the "standard" linker scripts, this might work (modulo the bug in the spec file the original poster seems to hit), but in general, it cannot. Sorry, I'm not interested in some theoretical general solution which might handle every possible linker script. A linker script passed to the gcc driver should override the one which the driver would pass by default. The linker script which is specified must be, as you say, close enough to the standard script that things will work correctly. In the real world, linker scripts may be generated automatically to describe the memory layout of a board or processor. There is no compelling reason to prohibit this *correct* linker script from being passed to the gcc driver and from there to ld. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: 4.1 status?
Richard Guenther writes: > On 9/9/06, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > Kenny Simpson wrote: > > > What is the status of the 4.1 branch? Any word on 4.1.2? > > > > My current plan is to do a 4.1.2 along with 4.2.0. My concern has been > > that with 4.2.0 moving slowly, trying to organize another release might > > just distract the developer community. > > > > However, I realize that's a pretty wide gap between 4.1.1 and 4.1.2. We > > could also do 4.1.2 sooner, and then do 4.1.3 along with 4.2.0. (I want > > to do a 4.1.x release along with 4.2.0 so as to avoid the problems we > > have in past with quality "going backwards" between releases from > > different branches.) > > > > I'm sure that, a priori, people would prefer a 4.1.2 release, but it > > does take effort. On the other hand, many 4.1 bugs are also in 4.2. > > > > Any thoughts? > > With my vendor hat on I'd prefer a 4.1.2 release sooner than I expect > 4.2.0 - which would make the time we branch for 4.2.0 a good candidate. > >From a pure GCC development side I do not care very much about > 4.1.2 (or even 4.0.4 which I don't expect at all). > > I guess a release of 4.1.2 together with branching for 4.2.0 might encourage > to backport regression fixes from 4.2 to 4.1, as with stage1 starting, 4.1.2 > will get even less attention than 4.2.0. +1 for a 4.1.2 release when/after the 4.2.0 branch is created. I'll propose this release to the Debian release managers to be included into the upcoming Debian 4.0 release. Matthias
Re: Linker scripts
On Sun, Sep 10, 2006 at 10:16:29PM +0200, Segher Boessenkool wrote: > >GCC passes a linker script to the linker for some > >targets (e.g., powerpc-eabi with -mads). If you specify a > >linker script using -Wl,-T,script.ld, you get both > >passed to the linker and there may be conflicts. > > > >Is there any option to GCC which says to not pass > >the predefined linker script to the linker? > > If you use your own linker scripts, you really shouldn't use gcc > to do the linking step; call ld directly, instead. gcc has no > idea what your linker script does, so it might well call ld with > the wrong options... This is wrong. Always use GCC to do the linking. It's simply astounding the number of bugs I've seen that were caused by someone thinking they knew everything they needed to invoke ld correctly; GCC encapsulates this knowledge. If some GCC configuration passes some specific option that is wrong, then that GCC configuration is broken and a bug should be filed. -- Daniel Jacobowitz CodeSourcery
Re: Linker scripts
A linker script passed to the gcc driver should override the one which the driver would pass by default. Yes, and if current GCC has some problems with that, those bugs should be fixed. Sorry if I gave the impression that this would be "user error". The linker script which is specified must be, as you say, close enough to the standard script that things will work correctly. In the real world, linker scripts may be generated automatically to describe the memory layout of a board or processor. There is no compelling reason to prohibit this *correct* linker script from being passed to the gcc driver and from there to ld. As long as those scripts are close enough to the "standard" scripts, it might/should work fine. In most cases (as far as I have seen) where people use non-standard linking scripts though, all bets are off (for more or less obvious reasons), and those people would be much better of calling ld directly. I only tried to warn the original poster of the perils involved, I didn't try to draw away the attention from the apparent GCC bug. I guess I miserably failed, sorry about that :-) Segher
gcc algol 60 milestone 1
Hi list! For those interested, GCC Algol 60 project, the byproduct of GCC Frontend Howto diploma thesis, still lives, and its first milestone is available: http://projects.almad.net/gcc-algol/wiki/Milestones Thanks, PM
Re: libgfortran build broken on Darwin ppc
On 10/09/2006, at 6:48 AM, Jack Howarth wrote: Eric, You definitely want the autoconf patch added in otherwise builds of libgfortran will crash when older cctools are used (like Xcode 2.3). Typically what we do is just say that GCC requires a later version of cctools. smime.p7s Description: S/MIME cryptographic signature
