Re: Results for 4.1.0 20060117 (prerelease) testsuite on powerpc-apple-darwin8.4.0 (-m64 results)
and I was hoping that this might clear up a significant fraction of the 7,000+ 64-bit testsuite failures for 4.1 on powerpc-apple- darwin8.4.0. But it appears this hasn't happened yet. Does anyone wish to try yet again to drive it into my thick skull what goals gcc 4.1 has on powerpc-apple-darwin8.4.0? I've been mostly testing the apple branch for the 64-bit stuff, but unfortunately after this just tested mainline. Way too many failures and they need to be investigated. (And I still can't seem to use the Apple tools to build 64-bit shared libraries that work; but that isn't a problem for this list ...) I'll investigate the problems that you've got for this, it should work. -eric
Re: Request for 48 hours of just regression/bug fixes
On Sat, Jan 21, 2006 at 07:03:27PM -0800, Mark Mitchell wrote: > Andrew Pinski wrote: > > I noticed today that there were three projects which were merged into > > the mainline within a 24 hour period yesterday. > > > > Date: Thu, 19 Jan 2006 01:42:49 - IAB - Daniel Berlin > > Date: Thu, 19 Jan 2006 10:24:04 - Vect - Dorit > > Date: Thu, 19 Jan 2006 16:55:54 - GOMP - Diego Novillo > > > > So I am requesting that we go through a 48 hour period starting Monday > > (as the weekends are usually quiet for patch committing) for a stage 3 > > type regression only/bug fixes. > > I'm inclined to agree. Any objections? Monday in Hawaii is basically Tuesday in New-Zealand (23 hours difference right now), so you should make clear in which timezone you define the 48 hour period. Apart from this I have nothing to say about the convenience of such a freeze, I'm mostly a lurker who regularly bootstraps GCC (once a week or so) but have not had any problem in a long time compiling my own rather simple code. I'd just like to take the opportunity to thank all the people who make this great compiler available. Regards, Gabriel
Re: RTL alias analysis
ian@airs.com (Ian Lance Taylor) wrote on 21.01.06 in <[EMAIL PROTECTED]>:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
> > I think he's saying that _this_ one might generate invalid code:
> >
> > void test(void)
> > {
> > union { int i; double d; } u;
> > int *ip;
> > double *dp;
> > int ii;
> > double dd;
> >
> > dp = &u.d;
> > ip = &u.i;
> > *ip = 15;
> > ii = *ip;
> > *dp = 1.5;
> > dd = *dp;
> > printf("ii=%d dd=%f\n", ii, dd);
> > }
>
> That function is valid too.
>
> Here is an example of an invalid function:
>
> void test(void)
> {
> union { int i; double d; } u;
> int *ip;
> double *dp;
> int ii;
> double dd;
>
> dp = &u.d;
> ip = &u.i;
> *ip = 15;
> *dp = 1.5;
> ii = *ip;
> dd = *dp;
> printf("ii=%d dd=%f\n", ii, dd);
> }
And of course(?), stack slot sharing is supposed to be like the first two
examples, not the last.
Hmm. I think I begin to see what this is about. RTL AA (if I got this
right) gets confused when two vars at the same address *can't* be
distinguished by type, so that would be
void test(void)
{
union { int i1; int i2; } u;
int *ip1;
int *ip2;
int ii1;
int ii2;
ip1 = &u.i1;
ip2 = &u.i2;
*ip1 = 15;
ii1 = *ip1;
*ip2 = 17;
ii2 = *ip2;
printf("ii1=%d ii2=%d\n", ii1, ii2);
}
Hmm. I don't know if ISO allows *that* ... though I can see how it might
arise naturally.
MfG Kai
Re: RTL alias analysis
Ian Lance Taylor writes:
> [EMAIL PROTECTED] (Kai Henningsen) writes:
>> void test(void)
>> {
>> union { int i; double d; } u;
>> int *ip;
>> double *dp;
>> int ii;
>> double dd;
>>
>> ip = &u.i;
>> *ip = 15;
>> ii = *ip;
>> dp = &u.d;
>> *dp = 1.5;
>> dd = *dp;
>> printf("ii=%d dd=%f\n", ii, dd);
>> }
>>
>> So you're saying this function is not valid?
>
> That function is valid.
I'm going to regret this, but... I don't follow. How is Kai's testcase
different from:
int ii;
double dd;
void foo (int *ip, double *dp)
{
*ip = 15;
ii = *ip;
*dp = 1.5;
dd = *dp;
}
void test (void)
{
union { int i; double d; } u;
foo (&u.i, &u.d);
}
? foo() can write *dp before reading *ip.
Richard
Re: Request for 48 hours of just regression/bug fixes
Mark Mitchell <[EMAIL PROTECTED]> wrote: >> Date: Thu, 19 Jan 2006 01:42:49 - IAB - Daniel Berlin >> Date: Thu, 19 Jan 2006 10:24:04 - Vect - Dorit >> Date: Thu, 19 Jan 2006 16:55:54 - GOMP - Diego Novillo >> >> So I am requesting that we go through a 48 hour period starting >> Monday (as the weekends are usually quiet for patch committing) for >> a stage 3 type regression only/bug fixes. > > I'm inclined to agree. Any objections? Can we have a metabug with the most critical bugs we want fixed (or at least properly analyzed) before unslushing? This would be a motivation for working on fixing them. Otherwise, there's absolutely no guarantess that GCC on Wednesday be better than GCC on Monday. Giovanni Bajo
Re: Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)
On Mon, 16 Jan 2006, DJ Delorie wrote: > Two copies of gcc, both configured for the same target and built from > the same sources, should produce identical objects regardless of how > they are built or what they run on. For the record, this unfortunately isn't so, at least wasn't weeks ago, comparing cross-compiler output from a "32-bit host" (i686-) and a "64-bit host" (x64_64-) for a 32-bit target (cris-), at least not when compiling 64-bit code (i.e. "long long" on this target). brgds, H-P
Re: Request for 48 hours of just regression/bug fixes
On 1/22/06, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Andrew Pinski wrote: > > I noticed today that there were three projects which were merged into > > the mainline within a 24 hour period yesterday. > > > > Date: Thu, 19 Jan 2006 01:42:49 - IAB - Daniel Berlin > > Date: Thu, 19 Jan 2006 10:24:04 - Vect - Dorit > > Date: Thu, 19 Jan 2006 16:55:54 - GOMP - Diego Novillo > > > > So I am requesting that we go through a 48 hour period starting Monday > > (as the weekends are usually quiet for patch committing) for a stage 3 > > type regression only/bug fixes. > > I'm inclined to agree. Any objections? I would even extend this "slush" to the point where all P1 4.1 regressions are fixed and a first 4.1.0 RC could be built. Richard.
Re: RTL alias analysis
On Jan 22, 2006, Richard Sandiford <[EMAIL PROTECTED]> wrote:
> Ian Lance Taylor writes:
>> [EMAIL PROTECTED] (Kai Henningsen) writes:
>>> void test(void) { union { int i; double d; } u;
>>> int *ip; double *dp; int ii; double dd;
>>> ip = &u.i; *ip = 15; ii = *ip; dp = &u.d; *dp = 1.5; dd = *dp;
>>> printf("ii=%d dd=%f\n", ii, dd); }
>>> So you're saying this function is not valid?
>>
>> That function is valid.
> I'm going to regret this, but... I don't follow. How is Kai's testcase
> different from:
> int ii; double dd; void foo (int *ip, double *dp) {
> *ip = 15; ii = *ip; *dp = 1.5; dd = *dp; }
> void test (void) { union { int i; double d; } u;
> foo (&u.i, &u.d); }
> ? foo() can write *dp before reading *ip.
I don't think it is any different. GCC's exception for unions only
applies if the object is accessed using the union type. So they are
indeed equivalent. The scary thing is that I don't think they
actually violate the ISO C strict aliasing rules, but they might still
be mis-optimized by GCC, assuming I understand correctly what GCC
does.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: RTL alias analysis
On 1/22/06, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> I don't think it is any different. GCC's exception for unions only
> applies if the object is accessed using the union type. So they are
> indeed equivalent. The scary thing is that I don't think they
> actually violate the ISO C strict aliasing rules, but they might still
> be mis-optimized by GCC, assuming I understand correctly what GCC
> does.
ISO C says that the following violates aliasing rules:
int foo(float f)
{
union { int i; float f; } u;
i.f = f;
return i.i;
}
because the memory at u is accessed as two different effective types.
Using a union doesn't change this. The correct solution for converting
a float to an integer (bit-representation) as in the expample is to use
two different memory locations and memcpy (which avoids aliasing
issues by means of using the special rules for access through 'char').
Richard.
Re: Bootstrap failure on Linux/x86-64
> I use: > --enable-checking=misc,tree,gc,rtl,rtlflag,assert > [...] > > Andreas FYI, you're missing "runtime" checking in that list which is normally part fo the default set. I use --enable-checking=yes,rtl when I want to add "rtl" to the default list so I don't miss any existing (or newly added) flags as time goes by. (The "yes" flag works as of 4.0.) I did this on i686 last night, so your problem is probably confined to x86_64. http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01144.html --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: floot_log2() - two functions with the same name in GCC.
On 2006-01-22, at 04:35, Andrew Pinski wrote: OK. Looking closer I have just found that in gcc/toplev.c #if GCC_VERSION < 3004 ... #endif Is missing around the floor_log2() and exact_log2() functions. You are mssing the fact that the ones in the headers are declared as extern inline. Yes I saw them. However pease look at the if else endif guards in the header. extern inline is just supposed to guarantee that a copy of the function will be spawn out to an .o file when it's seen. Right? The variant in toplev.c will be of course generated as well. And then it's just link order roulette which one of them will be used... No. This is GCC "extern inline" and not C99 "extern inline". GCC's "extern inline" means inline if you can but if we don't inline, use the external version and don't emit the function in the .o. It is my understanding that this interpretation applies only to old versions of it. Which is precisely what the proposed if/endif is guarding against.
Re: RTL alias analysis
On Sun, 22 Jan 2006, Richard Sandiford wrote:
> I'm going to regret this, but... I don't follow. How is Kai's testcase
> different from:
>
> int ii;
> double dd;
> void foo (int *ip, double *dp)
> {
> *ip = 15;
> ii = *ip;
> *dp = 1.5;
> dd = *dp;
> }
>
> void test (void)
> {
> union { int i; double d; } u;
> foo (&u.i, &u.d);
> }
You have read DR#236 and the subsequent discussions in the past five
years' WG14 papers (e.g. N), right?
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: RTL alias analysis
On Sun, 22 Jan 2006, Richard Guenther wrote:
> ISO C says that the following violates aliasing rules:
>
> int foo(float f)
> {
> union { int i; float f; } u;
> i.f = f;
> return i.i;
> }
>
> because the memory at u is accessed as two different effective types.
> Using a union doesn't change this. The correct solution for converting
> a float to an integer (bit-representation) as in the expample is to use
> two different memory locations and memcpy (which avoids aliasing
> issues by means of using the special rules for access through 'char').
It's not at all clear which types (of the union, or the union member) are
the relevant effective types in such cases. Certainly N treats such
cases as intended to be defined, and the response to DR#283 makes the
possibility of type punning through unions explicit (albeit in a footnote,
i.e. non-normative).
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: floot_log2() - two functions with the same name in GCC.
Andrew Pinski <[EMAIL PROTECTED]> writes:
> No. This is GCC "extern inline" and not C99 "extern inline".
Does GCC plan to move to the C99 semantics of inline and extern inline
in C?
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
branch_target_register_class - receipt for a crash
Inside gcc/target.h we have the declaration of
struct gcc_target { struct asm_out { struct sched { ...
there is a function refernce field named
int (* branch_target_register_class) (void);
The only place where this is referenced is in gcc/bt-load.c
and in esp the global branch_target_load_optimize() function.
Right away at the start. However there is no initialization of
brnach_target_register_class at all anywhere.
This of course will let the compiler crash on *every* call
to branch_target_load_optimize().
Again:
ejb227:~/gcc dalecki$ svngrep branch_target_register_class
.//gcc/bt-load.c: enum reg_class class = (enum reg_class)
targetm.branch_target_register_class ();
.//gcc/ChangeLog-2003: * target.h (branch_target_register_class):
Change return type to int.
.//gcc/ChangeLog-2003: * target.h (struct gcc_target): Add
branch_target_register_class
.//gcc/target.h: int (* branch_target_register_class) (void);
Let's check who calls branch_target_load_optmize()...
We can see that all calls are guarded by
flag_branch_target_load_optimize
and a corresponding report option:
gcc/common.opt:Common Report Var(flag_branch_target_load_optimize)
Enabing this option is going to crash the compiler miserable.
Looking at the use of flag_brnach_target_load_optmize2 I think all of
the
associated code should be simply deleted.
Marcin Dalecki
Re: branch_target_register_class - receipt for a crash
On Sun, Jan 22, 2006 at 05:00:34PM +0100, Marcin Dalecki wrote:
> Inside gcc/target.h we have the declaration of
> struct gcc_target { struct asm_out { struct sched { ...
> there is a function refernce field named
>
> int (* branch_target_register_class) (void);
>
> The only place where this is referenced is in gcc/bt-load.c
> and in esp the global branch_target_load_optimize() function.
> Right away at the start. However there is no initialization of
> brnach_target_register_class at all anywhere.
> This of course will let the compiler crash on *every* call
> to branch_target_load_optimize().
If this were true, it would have been very easy to check: pass the
option, watch the compiler crash. Did you try it?
- It's not in struct sched, which is not in struct asm_out.
- If you'd loaded up the compiler in GDB you'd probably have
seen it initialized to hook_int_void_no_regs.
- This comes from TARGET_BRANCH_TARGET_REGISTER_CLASS.
- SH redefines that to sh_target_reg_class.
--
Daniel Jacobowitz
CodeSourcery
Re: RTL alias analysis
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> On Sun, 22 Jan 2006, Richard Sandiford wrote:
>
>> I'm going to regret this, but... I don't follow. How is Kai's testcase
>> different from:
>>
>> int ii;
>> double dd;
>> void foo (int *ip, double *dp)
>> {
>> *ip = 15;
>> ii = *ip;
>> *dp = 1.5;
>> dd = *dp;
>> }
>>
>> void test (void)
>> {
>> union { int i; double d; } u;
>> foo (&u.i, &u.d);
>> }
>
> You have read DR#236 and the subsequent discussions in the past five
> years' WG14 papers (e.g. N), right?
No, and I wasn't trying to suggest otherwise, or describe what is
and isn't valid. And I didn't realise my message justified such
a snide response... but perhaps it did.
I was just trying to point out that Ian's claim that the original code
was valid doesn't reflect what GCC implements.
Richard
Re: Bootstrap failure on Linux/x86-64
Andreas, FWIW I've had successful bootstrap with these checking flags on x86_64-unknown-lunux-gnu Graham
Re: RTL alias analysis
Richard Sandiford <[EMAIL PROTECTED]> writes: > I was just trying to point out that Ian's claim that the original code > was valid doesn't reflect what GCC implements. Yeah, I think I'm going to step back from trying to argue what is and is not valid. To cut to the chase, I think the best approach for this particular problem is to wholly avoid having union types share the same stack slot. Ian
Re: branch_target_register_class - receipt for a crash
On 2006-01-22, at 17:08, Daniel Jacobowitz wrote:
On Sun, Jan 22, 2006 at 05:00:34PM +0100, Marcin Dalecki wrote:
Inside gcc/target.h we have the declaration of
struct gcc_target { struct asm_out { struct sched { ...
there is a function refernce field named
int (* branch_target_register_class) (void);
If this were true, it would have been very easy to check: pass the
option, watch the compiler crash. Did you try it?
I was actually just trying to understand how the code works and
why it didn't occur. OK. Thank you for bothering to explain it to me.
I missed the static initialization in one go.
Re: Bootstrap failure on Linux/x86-64
Graham Stott wrote: Andreas, FWIW I've had successful bootstrap with these checking flags on x86_64-unknown-lunux-gnu Graham My bootstrap was fine also using x86_64-suse-linux-gnu. Kenny
Re: Bootstrap failure on Linux/x86-64
Andreas Jaeger wrote: Andrew Pinski <[EMAIL PROTECTED]> writes: On Jan 21, 2006, at 1:09 PM, Andreas Jaeger wrote: On Sat, Jan 21, 2006 at 12:42:24PM -0500, Andrew Pinski wrote: On Jan 21, 2006, at 12:38 PM, Andreas Jaeger wrote: I'm still seeing this with current Subversion. Anybody else having the same problem on x86-64? It fails for me on the two systems I tested it on, What reversion is this on? This worked for me on 110050 and 110059. I'll try 110059 now to double check. Perhaps my configure flags are the problem, I use: /cvs/gcc-svn/trunk/configure --prefix=/opt/gcc/4.2-devel --enable-checking=misc,tree,gc,rtl,rtlflag,assert --enable-threads=posix --enable-clocale=gnu --enable-__cxa_atexit --enable-shared --with-system-zlib x86_64-suse-linux-gnu --enable-languages=c,ada,c++,fortran,java,objc,treelang I just used 110067 and it worked. Maybe it is one of the checking options you are using which is causing it. I just used the default checking. I now used 110067 with the default checking options - and it worked, so it's the checking options. Kenneth, Zdenek, could you look into this? Please use the same checking options that I have above. Let me double check with the checking you have. Thanks, Andreas I am not going to see this failure on my machine. I have a 2gb x86-64 which will easily handle compiling this size file. I was watching top as it compiled a stage2 insn-addrtab, which I think is the largest function in the gcc stack and the VIRT topped at 501mb, which is no sweat for this machine. You could argue, (and I would not disagree with you) that 501mb is not tolerable and is symptomatic of something bad happening. There are, most likely storage leaks in the system. But I do not think that you are going to necessarily find the problem by looking to see which version happens to crash on your machine. The worst case senario is that this is just footprint creep and the version that failed was just the one the added the straw that broke the camels back with you particular config. I am not fully into building stage3 and have no failure. btw, I am doing this with the latest baseline compiler. I can go back to earlier compilers if you want. But given that andreas's failed with the following line: cc1: out of memory allocating 22752576 bytes after a total of 142843904 bytes I am not going to see the problem. Kenny
Re: RTL alias analysis
Ian Lance Taylor wrote: > Yeah, I think I'm going to step back from trying to argue what is and > is not valid. To cut to the chase, I think the best approach for this > particular problem is to wholly avoid having union types share the > same stack slot. RTH agrees with you. Upon reading the thread carefully, so do I. Would anyone care to prepare such a patch? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Build on mainline broken
Hi! I'm keeping an eye on building GCC for vax-linux /vax-linux-uclibc (only some config changes needed for that; I'll submit those once the first libc support is committed). Note that this is a cc0 port. An automated build at 20060120-141501 UTC still showed the ICE in udivmodsi4.c . This was probably fixed by r110030: 2006-01-20 Zdenek Dvorak <[EMAIL PROTECTED]> * loop-iv.c (iv_analysis_loop_init): Use df in more conservative way. Since the next automated build at 20060120-171500 UTC, I'm getting a different ICE: /tmp/build-temp-vax-linux-uclibc/build/gcc1/./gcc/xgcc -B/tmp/build-temp-vax-linux-uclibc/build/gcc1/./gcc/ -B/tmp/build-temp-vax-linux-uclibc/install/usr/vax-linux-uclibc/bin/ -B/tmp/build-temp-vax-linux-uclibc/install/usr/vax-linux-uclibc/lib/ -isystem /tmp/build-temp-vax-linux-uclibc/install/usr/vax-linux-uclibc/include -isystem /tmp/build-temp-vax-linux-uclibc/install/usr/vax-linux-uclibc/sys-include -O2 -O2 -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc -I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/. -I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/../include -I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/../libcpp/include -I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/../libdecnumber -I../libdecnumber -fexceptions -c /tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/unwind-dw2-fde.c -o libgcc/./unwind-dw2-fde.o /tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/unwind-dw2-fde.c:1: warning: -g is only supported when using GAS on this processor, /tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/unwind-dw2-fde.c:1: warning: -g option disabled /tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/unwind-dw2-fde.c: In function 'fde_single_encoding_compare': /tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/unwind-dw2-fde.c:350: internal compiler error: in expand_compound_operation, at combine.c:5644 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [libgcc/./unwind-dw2-fde.o] Error 1 make[2]: Leaving directory `/tmp/build-temp-vax-linux-uclibc/build/gcc1/gcc' make[1]: *** [libgcc.a] Error 2 make[1]: Leaving directory `/tmp/build-temp-vax-linux-uclibc/build/gcc1/gcc' make: *** [all-gcc] Error 2 This is the SIGN_EXTRACT case of expand_compound_operation(), maybe this does ring a bell? Thanks, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
Re: Build on mainline broken
Hello, > I'm keeping an eye on building GCC for vax-linux /vax-linux-uclibc (only > some config changes needed for that; I'll submit those once the first libc > support is committed). Note that this is a cc0 port. > > An automated build at 20060120-141501 UTC still showed the ICE in > udivmodsi4.c . This was probably fixed by r110030: > > 2006-01-20 Zdenek Dvorak <[EMAIL PROTECTED]> > > * loop-iv.c (iv_analysis_loop_init): Use df in more conservative way. > > > Since the next automated build at 20060120-171500 UTC, I'm getting a > different ICE: > > /tmp/build-temp-vax-linux-uclibc/build/gcc1/./gcc/xgcc > -B/tmp/build-temp-vax-linux-uclibc/build/gcc1/./gcc/ > -B/tmp/build-temp-vax-linux-uclibc/install/usr/vax-linux-uclibc/bin/ > -B/tmp/build-temp-vax-linux-uclibc/install/usr/vax-linux-uclibc/lib/ -isystem > /tmp/build-temp-vax-linux-uclibc/install/usr/vax-linux-uclibc/include > -isystem > /tmp/build-temp-vax-linux-uclibc/install/usr/vax-linux-uclibc/sys-include -O2 > -O2 -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings > -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem > ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. > -I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc > -I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/. > -I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/../include > -I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/../libcpp/include > -I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/../libdecnumber > -I../libdecnumber -fexceptions -c > /tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/unwind-dw2-fde.c -o > libgcc/./unwind-dw2-fde.o > /tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/unwind-dw2-fde.c:1: warning: -g > is only supported when using GAS on this processor, > /tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/unwind-dw2-fde.c:1: warning: -g > option disabled > /tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/unwind-dw2-fde.c: In function > 'fde_single_encoding_compare': > /tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/unwind-dw2-fde.c:350: internal > compiler error: in expand_compound_operation, at combine.c:5644 > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > make[2]: *** [libgcc/./unwind-dw2-fde.o] Error 1 > make[2]: Leaving directory `/tmp/build-temp-vax-linux-uclibc/build/gcc1/gcc' > make[1]: *** [libgcc.a] Error 2 > make[1]: Leaving directory `/tmp/build-temp-vax-linux-uclibc/build/gcc1/gcc' > make: *** [all-gcc] Error 2 > > This is the SIGN_EXTRACT case of expand_compound_operation(), maybe this does > ring a > bell? no idea; this is either completely unrelated, or we randomly clobber memory somewhere. Could you please provide a preprocessed testcase (preferably reduced one)? Zdenek
Re: Build on mainline broken
On Sun, 2006-01-22 21:49:31 +0100, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: [...] > > This is the SIGN_EXTRACT case of expand_compound_operation(), maybe this > > does ring a > > bell? > > no idea; this is either completely unrelated, or we randomly clobber memory > somewhere. > Could you please provide a preprocessed testcase (preferably reduced > one)? Thanks for commenting on this. I've just started a build with r110030 and will try to produce something. Once that is done (it takes some time:-) Thanks, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
Re: Build on mainline broken
On Sun, 2006-01-22 21:54:47 +0100, Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote:
> On Sun, 2006-01-22 21:49:31 +0100, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> [...]
> > > This is the SIGN_EXTRACT case of expand_compound_operation(), maybe this
> > > does ring a
> > > bell?
> >
> > no idea; this is either completely unrelated, or we randomly clobber memory
> > somewhere.
> > Could you please provide a preprocessed testcase (preferably reduced
> > one)?
>
> Thanks for commenting on this. I've just started a build with r110030
> and will try to produce something. Once that is done (it takes some
> time:-)
First of all, this indeed starts with r110030. -O2 is needed, the
problem goes away if no -O is used. While trying to cut it down, I
noticed that the ICE is probably connected to the bitfields. It's 75
lines right now:
--
typedef long unsigned int size_t;
extern void abort (void) __attribute__ ((__noreturn__));
typedef unsigned _Unwind_Ptr __attribute__((__mode__(__pointer__)));
struct fde_vector
{
size_t count;
const struct dwarf_fde *array[];
};
struct object
{
struct fde_vector *sort;
struct {
unsigned long mixed_encoding : 1;
unsigned long encoding : 8;
} b;
struct object *next;
};
typedef int sword __attribute__ ((mode (SI)));
struct dwarf_cie
{
sword CIE_id;
} __attribute__ ((packed, aligned (__alignof__ (void *;
struct dwarf_fde
{
sword CIE_delta;
} __attribute__ ((packed, aligned (__alignof__ (void *;
typedef struct dwarf_fde fde;
static struct object *seen_objects;
static _Unwind_Ptr
base_from_object (unsigned char encoding)
{
if (encoding)
abort ();
}
static const fde *
search_object (struct object* ob, void *pc)
{
struct fde_vector *vec = ob->sort;
int encoding = ob->b.encoding;
_Unwind_Ptr base = base_from_object (encoding);
size_t lo, hi;
for (lo = 0, hi = vec->count; lo < hi; )
{
size_t i = (lo + hi) / 2;
const fde *f = vec->array[i];
_Unwind_Ptr pc_begin;
if ((_Unwind_Ptr) pc < pc_begin)
return f;
}
}
const fde *
_Unwind_Find_FDE (void *pc)
{
struct object *ob;
const fde *f = ((void *)0);
for (ob = seen_objects; ob; ob = ob->next)
f = search_object (ob, pc);
return f;
}
--
To build it:
(This is binutils from CVS)
.../binutils/configure --target=vax-linux-uclibc --disable-nls --prefix=...
make all-binutils
make all-ld
make all-gas
make install-binutils
make install-ld
make install-gas
(GCC)
.../gcc/configure --disable-multilib --with-newlib --disable-nls \
--enable-threads=no --disable-threads --enable-symvers=gnu \
--enable-__cxa_atexit --disable-shared --target=vax-linux-uclibc \
--prefix=... \
--enable-languages=c,c++
make all-gcc
This patch is used for GCC:
diff -Nurp src-gcc-fresh/gcc/config/vax/linux.h
src-gcc-hacked/gcc/config/vax/linux.h
--- src-gcc-fresh/gcc/config/vax/linux.h1970-01-01 01:00:00.0
+0100
+++ src-gcc-hacked/gcc/config/vax/linux.h 2005-12-09 21:57:45.0
+0100
@@ -0,0 +1,31 @@
+#ifndef _CONFIG_VAX_LINUX_H
+/*
+ * Copyright (C) 2005 Free Software Foundation, Inc.
+ *
+ * This file is part of GCC.
+ *
+ * GCC is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * GCC is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GCC; see the file COPYING. If not, write to
+ *
+ * Free Software Foundation
+ * 51 Franklin Street, Fifth Floor
+ * Boston, MA 02110-1301
+ * USA
+ */
+
+/*
+ * This file contains definitions specific to Linux using GNU libc and
+ * the ELF binary format.
+ */
+
+#endif /* _CONFIG_VAX_LINUX_H */
diff -Nurp src-gcc-fresh/gcc/config/vax/uclinux.h
src-gcc-hacked/gcc/config/vax/uclinux.h
--- src-gcc-fresh/gcc/config/vax/uclinux.h 1970-01-01 01:00:00.0
+0100
+++ src-gcc-hacked/gcc/config/vax/uclinux.h 2005-12-09 21:57:45.0
+0100
@@ -0,0 +1,31 @@
+#ifndef _CONFIG_VAX_UCLINUX_H
+/*
+ * Copyright (C) 2005 Free Software Foundation, Inc.
+ *
+ * This file is part of GCC.
+ *
+ * GCC is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * GCC is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+
Re: Help - Crash gcc 3.4.2 64 bits Shared Library
> Sometimes I have got a bus error at libstdc++ with gcc 3.4.2 in SUN. I'm afraid the information you've given is pretty scant. Far more information will be required, plus some work on your side to try and isolate the problem. Perhaps you could try reporting the problem to the gcc-help@ list, with some more information? Thanks, Ben
Re: Request for 48 hours of just regression/bug fixes
> > Mark Mitchell <[EMAIL PROTECTED]> wrote: > > >> Date: Thu, 19 Jan 2006 01:42:49 - IAB - Daniel Berlin > >> Date: Thu, 19 Jan 2006 10:24:04 - Vect - Dorit > >> Date: Thu, 19 Jan 2006 16:55:54 - GOMP - Diego Novillo > >> > >> So I am requesting that we go through a 48 hour period starting > >> Monday (as the weekends are usually quiet for patch committing) for > >> a stage 3 type regression only/bug fixes. > > > > I'm inclined to agree. Any objections? > > > Can we have a metabug with the most critical bugs we want fixed (or at least > properly analyzed) before unslushing? This would be a motivation for working > on > fixing them. Otherwise, there's absolutely no guarantess that GCC on Wednesday > be better than GCC on Monday. I think this is a great idea. Thanks, Andrew Pinski
Re: Build on mainline broken
> > --ZMT28BdW279F9lxY > Content-Type: text/plain; charset=utf-8 > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Sun, 2006-01-22 21:49:31 +0100, Zdenek Dvorak <[EMAIL PROTECTED] > cuni.cz> wrote: > [...] > > > This is the SIGN_EXTRACT case of expand_compound_operation(), maybe thi= > s does ring a > > > bell? > >=20 > > no idea; this is either completely unrelated, or we randomly clobber memo= > ry somewhere. > > Could you please provide a preprocessed testcase (preferably reduced > > one)? > > Thanks for commenting on this. I've just started a build with r110030 > and will try to produce something. Once that is done (it takes some > time:-) I think this is either PR 25890 or PR 25905. -- Pinski
Re: Request for 48 hours of just regression/bug fixes
Andrew Pinski <[EMAIL PROTECTED]> writes: | > | > Mark Mitchell <[EMAIL PROTECTED]> wrote: | > | > >> Date: Thu, 19 Jan 2006 01:42:49 - IAB - Daniel Berlin | > >> Date: Thu, 19 Jan 2006 10:24:04 - Vect - Dorit | > >> Date: Thu, 19 Jan 2006 16:55:54 - GOMP - Diego Novillo | > >> | > >> So I am requesting that we go through a 48 hour period starting | > >> Monday (as the weekends are usually quiet for patch committing) for | > >> a stage 3 type regression only/bug fixes. | > > | > > I'm inclined to agree. Any objections? | > | > | > Can we have a metabug with the most critical bugs we want fixed (or at least | > properly analyzed) before unslushing? This would be a motivation for working on | > fixing them. Otherwise, there's absolutely no guarantess that GCC on Wednesday | > be better than GCC on Monday. | | I think this is a great idea. Indeed. (As a side note: next round, nobody would like to have its projects classified "stage 2", since stage 2 is guaranteed "stage 3" for indeterminate amount of time.) -- Gaby
Re: Request for 48 hours of just regression/bug fixes
Richard Guenther wrote: > I would even extend this "slush" to the point where all P1 4.1 regressions are > fixed and a first 4.1.0 RC could be built. Shutting down the mainline to get folks to focus on 4.1 is a step I'd prefer not to take; I'm hopeful that the 4.1 P1s will get the attention they deserve. However, I am concerned about instability on mainline. If someone will put together the meta-bug, I'll consider the request to slush mainline. In the absence of that, I'd certainly ask that we hold off on additional major merges until the consensus is that things have been reasonably stabililized. I do agree that we tend to let serious regressions sit for far too long. It's true that Stage 1 is for major changes, and that those will inevitably introduce problems, but we should not treat that as an excuse to ignore regressions introduced at that point until our backs are against the wall right before a release. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Bootstrap failure on Linux/x86-64
I'll look further into this myself now, thanks for trying to reproduce this, Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpm7POxiErAh.pgp Description: PGP signature
