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 ian@airs.com 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: 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: 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 URL: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 URL: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
+ * MERCHANTABILITY or FITNESS FOR A
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
[Bug ada/25900] [4.2 Regression] ACATS ICE cxac0004 in set_value_range, at tree-vrp.c:161 on x86-linux
--- Comment #1 from laurent at guerby dot net 2006-01-22 09:14 --- Was working with 109966, started failing with 109968 r109968 | law | 2006-01-19 17:30:59 +0100 (Thu, 19 Jan 2006) | 9 lines * tree-vrp.c (extract_range_from_assert): Refine the result range if the variable referenced by the ASSERT_EXPR has a range and either the tentative result range or the previous range is a VR_ANTI_RANGE. * gcc.dg/tree-ssa/vrp25.c: New test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25900
[Bug ada/18819] [4.1/4.2 Regression] ACATS cdd2a01 cdd2a02 fail at runtime
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2006-01-22 10:19 --- Any ideas why this would be the case? The types are not supposed to alias each other. The lines in the .dg file are: R8b : fdd2a00__write__A7b__2 := ada__streams__Tstream_element_offsetB?( system__arith_64__add_with_ovflo_check (interfaces__integer_64 ?(stream.last), interfaces__integer_64?( ada__streams__Tstream_element_offsetB(item'length'reference; [constraint_error when R8b.all = R5b.all and then (R5b.all 1 or else R8b.all ada__streams__Tstream_element_offsetB(R3b)) range check failed] ada/trans.c:3053 case N_Reference: /* Like 'Access as far as we are concerned. */ gnu_result = gnat_to_gnu (Prefix (gnat_node)); gnu_result = build_unary_op (ADDR_EXPR, NULL_TREE, gnu_result); gnu_result_type = get_unpadded_type (Etype (gnat_node)); break; These N_Reference nodes are an endless source of problems because they cause gigi to take the address of objects that are not aliased. We have been working towards eliminating them as much as possible by using renaming instead; this case (check on the result of a function call) is probably the most delicate one. No real solution as of this writing, only a poor workaround: not compiling the support files with -gnato (overflow checks). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug c++/9990] locale_facets.h contains invalid typedef
--- Comment #7 from gdr at gcc dot gnu dot org 2006-01-22 10:32 --- (In reply to comment #6) I think this is related to PR 13095 or least the definition of what is a base class is. That PR is different. A using declaration must nominate a base class. This PR is not about a using declaration. I believe, however, that there is a core issue related to it. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9990
[Bug c++/10416] 'unused variable' warning ignores ctor/dtor side-effects
--- Comment #9 from gdr at gcc dot gnu dot org 2006-01-22 10:44 ---
(In reply to comment #0)
Sometimes a variable is created only for the side-effects of its
constructor/destructor. For example, in the following code:
struct Closer { ~Closer() { CloseClipboard(); } } closer;
the closer variable is only used to make sure the clipboard is closed when the
function leaves (normally or exceptionally).
G++ apparently does not think this is valid use of a variable, and warns:
warning: unused variable.
Release:
gcc 3.2
How-To-Repeat:
Compile:
void f () { struct atend { ~atend () { std::cout leaving f\n; } } a; }
with -Wall.
The construct reported in this PR is a widely known and used C++ idiom:
Resource Acquisition Is Initialization (RAII). It is inappropriate for
-Wall to warn about it. However, the mechanism underpining it is so broad
that we would need more accurate measure to fix it.
Of course, the compiler (more precisely the middle-end) knows that the
destructor has a side-effect. But GCC middle-end tends to have little
knowledge of language specific idioms. Notice also that a is used
from a very high level abstraction point of view -- not from byte-fiddling
point of view. This is another instance of diagnostic PR better handed off
to the front-end.
-- Gaby
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
CC||gdr at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10416
[Bug c++/10891] code using dynamic_cast causes segfaults when -fno-rtti is used
--- Comment #2 from gdr at gcc dot gnu dot org 2006-01-22 10:52 --- Definitely. Use of dynamic_cast should be rejected if -fno-rtti. Working on a patch. -- Gaby -- gdr at gcc dot gnu dot org changed: What|Removed |Added CC||gdr at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |gdr at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-11 23:08:53 |2006-01-22 10:52:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10891
[Bug c++/25909] New: Internal compiler error when compiling qt4.
g++ -c -pipe -I/usr/include/mysql -march=pentium4 -march=pentium4 -march=pentium4 -march=pentium4 -O2 -s -pipe -ffast-math -s -pipe -ffast-math -s -pipe -ffast-math -s -pipe -ffast-math -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC -DQT_SHARED -DQT_EDITION=QT_EDITION_DESKTOP -DQT_BUILD_SVG_LIB -DQT_NO_CAST_TO_ASCII -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++ -I. -I../../include/QtCore -I../../include/QtGui -I../../include/QtXml -I../../include -I../../include/QtSvg -I.moc/release-shared -I. -o .obj/release-shared/qsvghandler.o qsvghandler.cpp -v -save-temps g++: warning: -pipe ignored because -save-temps specified Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1-20051112/configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --prefix=/usr --enable-shared --enable-languages=c,c++,objc --enable-threads=posix --enable-__cxa_atexit Thread model: posix gcc version 4.1.0 20051112 (experimental) /usr/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1plus -E -quiet -v -I/usr/include/mysql -I../../mkspecs/linux-g++ -I. -I../../include/QtCore -I../../include/QtGui -I../../include/QtXml -I../../include -I../../include/QtSvg -I.moc/release-shared -I. -D_GNU_SOURCE -D_REENTRANT -DQT_SHARED -DQT_EDITION=QT_EDITION_DESKTOP -DQT_BUILD_SVG_LIB -DQT_NO_CAST_TO_ASCII -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_NO_DEBUG -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE qsvghandler.cpp -march=pentium4 -march=pentium4 -march=pentium4 -march=pentium4 -Wall -W -ffast-math -ffast-math -ffast-math -ffast-math -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -O2 -fpch-preprocess -o qsvghandler.ii ignoring nonexistent directory /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/include ignoring duplicate directory . #include ... search starts here: #include ... search starts here: /usr/include/mysql ../../mkspecs/linux-g++ . ../../include/QtCore ../../include/QtGui ../../include/QtXml ../../include ../../include/QtSvg .moc/release-shared /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0 /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/i686-pc-linux-gnu /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/backward /usr/local/include /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/include /usr/include End of search list. /usr/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1plus -fpreprocessed qsvghandler.ii -quiet -dumpbase qsvghandler.cpp -march=pentium4 -march=pentium4 -march=pentium4 -march=pentium4 -auxbase-strip .obj/release-shared/qsvghandler.o -O2 -Wall -W -version -ffast-math -ffast-math -ffast-math -ffast-math -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -o qsvghandler.s GNU C++ version 4.1.0 20051112 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.1.0 20051112 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: d5866e95069f2f899e0672beaab630e0 qsvghandler.cpp: In function âvoid parseQPen(QPen, QSvgNode*, const QXmlAttributes, QSvgHandler*)â: qsvghandler.cpp:414: error: statement marked for throw in middle of block # TMT.9013D.134605_3608(ab) = V_MAY_DEF TMT.9013D.134605_1739; # TMT.9014D.134606_2679(ab) = V_MAY_DEF TMT.9014D.134606_2230; # TMT.9018D.134610_3609(ab) = V_MAY_DEF TMT.9018D.134610_3267; penwD.84426_832 = widthF (penD.84383_817); qsvghandler.cpp:414: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. I will attach .ii file in a moment. -- Summary: Internal compiler error when compiling qt4. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dawid dot ciezarkiewicz at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25909
[Bug c++/25909] Internal compiler error when compiling qt4.
--- Comment #1 from dawid dot ciezarkiewicz at gmail dot com 2006-01-22 11:27 --- Created an attachment (id=10700) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10700action=view) qsvghandler.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25909
[Bug target/25898] [4.2 Regression] All Ada tests fail
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-01-22 11:30 --- I did see the same effect on interal builds of 4.1 with the patches applied, but Honza could not reproduce either. I believe there's some magic going on in that Ada uses the host compiler for some/all tests? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25898
[Bug ada/18819] [4.1/4.2 Regression] ACATS cdd2a01 cdd2a02 fail at runtime
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2006-01-22 11:43 --- No real solution as of this writing, only a poor workaround: not compiling the support files with -gnato (overflow checks). Well, I may have spoken too soon. :-) We are calling Remove_Side_Effects on: N_Type_Conversion (Node_Id=1679) (analyzed) Rewritten: original node = N_Op_Add Oadd (Node_Id=39499) Parent = N_Range (Node_Id=1681) Sloc = 7611 fdd2a00.adb:6:38 Etype = N_Defining_Identifier Tstream_element_offsetB (Entity_Id=2017) Subtype_Mark = N_Identifier Tstream_element_offsetB (Node_Id=39497) Expression = N_Function_Call (Node_Id=39496) Conversion_OK = True It turns out that the fix is already present in the front-end, but inhibited: -- If this is a type conversion, leave the type conversion and remove -- the side effects in the expression. This is important in several -- circumstances: for change of representations, and also when this -- is a view conversion to a smaller object, where gigi can end up -- creating its own temporary of the wrong size. -- ??? this transformation is inhibited for elementary types that are -- not involved in a change of representation because it causes -- regressions that are not fully understood yet. elsif Nkind (Exp) = N_Type_Conversion and then (not Is_Elementary_Type (Underlying_Type (Exp_Type)) or else Nkind (Parent (Exp)) = N_Assignment_Statement) then Remove_Side_Effects (Expression (Exp), Name_Req, Variable_Ref); Scope_Suppress := Svg_Suppress; return; However, another possible fix is to make a copy when we know we will not be able to use a renaming. Tentative patch to be attached. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug ada/18819] [4.1/4.2 Regression] ACATS cdd2a01 cdd2a02 fail at runtime
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2006-01-22 11:44 --- Created an attachment (id=10701) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10701action=view) Patch for miscompilation on s390x. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug target/25898] [4.2 Regression] All Ada tests fail
--- Comment #6 from laurent at guerby dot net 2006-01-22 11:49 --- ACATS use the host base compiler for compiling two tools that are used to preprocess test sources. Everything else is done using the just built gnatmake. I can't find special processing for tune/cpu in the Ada sources. Andrew did you add -mtune or something to your copy of gcc/testsuite/ada/acats/run_all.sh? If not could you post a bit more from ada/acats/acats.log? (full gnatmake commands are displayed IIRC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25898
[Bug tree-optimization/25315] [4.2 regression] testsuite failure:27_io/basic_ostream/inserters_character/char/9555-oc.cc wchar_t/9555-oc.cc exec
--- Comment #7 from amodra at bigpond dot net dot au 2006-01-22 13:00
---
Dan Berlin suggested this patch on irc. (At least, this is how I remember the
sugestion..) Bootstrapped and reg tested powerpc64-linux. Cures the problem.
Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c (revision 110074)
+++ gcc/tree-ssa-pre.c (working copy)
@@ -2745,6 +2745,8 @@ insert_extra_phis (basic_block block, ba
FOR_EACH_EDGE (e, ei, block-preds)
{
+ if (e-flags EDGE_ABNORMAL)
+ return;
if (first)
{
bitmap_set_copy (tempset, AVAIL_OUT (e-src));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25315
[Bug middle-end/25905] [4.2 regression] ICE in expand_compound_operation
--- Comment #3 from pbrook at gcc dot gnu dot org 2006-01-22 13:41 ---
Smaller testcase:
void
read_encoded_value_with_base (const unsigned char *p, unsigned * val)
{
union unaligned
{
unsigned short u2;
}
__attribute__ ((__packed__));
const union unaligned *u = (const union unaligned *) p;
*val = u-u2;
}
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-01-22 13:41:02
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25905
[Bug libgomp/25910] New: bootstrap failure
/home/cow/obj.ia32/gcc/./gcc/xgcc -B/home/cow/obj.ia32/gcc/./gcc/ -B/opt/gcc-4.2//i686-linux-gnu/bin/ -B/opt/gcc-4.2//i686-linux-gnu/lib/ - isystem /opt/gcc-4.2//i686-linux-gnu/include -isystem /opt/gcc-4.2//i686-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../../src/gcc-4. 2/libgomp -I. -I../../../../src/gcc-4.2/libgomp/config/linux/x86 -I../../../../src/gcc-4.2/libgomp/config/linux -I../../../../src/gcc-4.2/l ibgomp/config/posix -I../../../../src/gcc-4.2/libgomp -Wall -Werror -ftls-model=initial-exec -march=i486 -pthread -mtune=i686 -O2 -W -Wall -Wextra -march=pentium4 -g -ggdb -O0 -g -ggdb3 -mtune=pentium4 -MT alloc.lo -MD -MP -MF .deps/alloc.Tpo -c ../../../../src/gcc-4.2/libgomp/ alloc.c -fPIC -DPIC -o .libs/alloc.o cc1: warnings being treated as errors In file included from ../../../../src/gcc-4.2/libgomp/libgomp.h:49, from ../../../../src/gcc-4.2/libgomp/alloc.c:32: ../../../../src/gcc-4.2/libgomp/config/linux/sem.h:56: warning: unused parameter 'sem' In file included from ../../../../src/gcc-4.2/libgomp/libgomp.h:50, from ../../../../src/gcc-4.2/libgomp/alloc.c:32: ../../../../src/gcc-4.2/libgomp/config/linux/mutex.h:59: warning: unused parameter 'mutex' make[4]: *** [alloc.lo] Error 1 This can be fixed by the attached patch gcc.libgomp_unused_arg.01.diff -- Summary: bootstrap failure Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aldot at gcc dot gnu dot org GCC build triplet: i686-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25910
[Bug c/25911] New: ice in vect_recog_dot_prod_pattern
I just tried to compile package gsl-1.7-2 from Suse Linux with a recent GNU C compiler version 4.2 snapshot 20060121. The compiler snapshot said /home/dcb/gnu/42-20060121/results/bin/gcc -g -O3 -Wall -fmessage-length=0 -DHAVE_CONFIG_H -I. -I. -I.. -I.. -O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -O3 -finline-limit=720 --param max-inline-insns-auto=160 -ffast-math -funroll-loops -fno-strict-aliasing -momit-leaf-frame-pointer -funit-at-a-time -ftree-vectorize -c bessel_Kn.c -fPIC -DPIC -o bessel_Kn.o bessel_Kn.c: In function sel_Kn.c:103: internal compiler error: in vect_recog_dot_prod_pattern, at tree-vect-patterns.c:246 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. It seems that the flags -O2 -ffast-math -ftree-vectorize are required. Preprocessed source code attached. -- Summary: ice in vect_recog_dot_prod_pattern Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25911
[Bug libgomp/25910] bootstrap failure
--- Comment #1 from aldot at gcc dot gnu dot org 2006-01-22 14:04 --- Created an attachment (id=10702) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10702action=view) Mark arguments as unused. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25910
[Bug c/25911] ice in vect_recog_dot_prod_pattern
--- Comment #1 from dcb314 at hotmail dot com 2006-01-22 14:05 --- Created an attachment (id=10703) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10703action=view) c source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25911
[Bug libgomp/25910] bootstrap failure
--- Comment #2 from aldot at gcc dot gnu dot org 2006-01-22 14:06 --- (In reply to comment #1) Created an attachment (id=10702) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10702action=view) [edit] Mark arguments as unused. Now the bootstrap stops later on with: /home/cow/obj.ia32/gcc/./gcc/xgcc -B/home/cow/obj.ia32/gcc/./gcc/ -B/opt/gcc-4.2//i686-linux-gnu/bin/ -B/opt/gcc-4.2//i686-linux-gnu/lib/ -isystem /opt/gcc-4.2//i686-linux-gnu/include -isystem /opt/gcc-4.2//i686-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../../src/gcc-4.2/libgomp -I. -I../../../../src/gcc-4.2/libgomp/config/linux/x86 -I../../../../src/gcc-4.2/libgomp/config/linux -I../../../../src/gcc-4.2/libgomp/config/posix -I../../../../src/gcc-4.2/libgomp -Wall -Werror -ftls-model=initial-exec -march=i486 -pthread -mtune=i686 -O2 -W -Wall -Wextra -march=pentium4 -g -ggdb -O0 -g -ggdb3 -mtune=pentium4 -MT iter.lo -MD -MP -MF .deps/iter.Tpo -c ../../../../src/gcc-4.2/libgomp/iter.c -fPIC -DPIC -o .libs/iter.o cc1: warnings being treated as errors ../../../../src/gcc-4.2/libgomp/iter.c: In function 'gomp_iter_static_next': ../../../../src/gcc-4.2/libgomp/iter.c:48: warning: comparison between signed and unsigned ../../../../src/gcc-4.2/libgomp/iter.c: In function 'gomp_iter_guided_next_locked': ../../../../src/gcc-4.2/libgomp/iter.c:248: warning: comparison between signed and unsigned make[4]: *** [iter.lo] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25910
[Bug target/25898] [4.2 Regression] All Ada tests fail
--- Comment #7 from hjl at lucon dot org 2006-01-22 14:45 --- It looks like an old bug. -- hjl at lucon dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25898
[Bug target/25898] [4.2 Regression] All Ada tests fail
--- Comment #8 from hjl at lucon dot org 2006-01-22 14:47 --- I will be that the installed gcc Ada 4.2 compiler was used for make check, similar to PR 14435. *** This bug has been marked as a duplicate of 14435 *** -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25898
[Bug ada/14435] gnatchop cannot use the compiled compiler in Ada's testsuite because of changed GCC_EXEC_PREFIX semantics
--- Comment #8 from hjl at lucon dot org 2006-01-22 14:47 --- *** Bug 25898 has been marked as a duplicate of this bug. *** -- hjl at lucon dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435
[Bug target/25899] [4.2 Regression] ACATS FAIL c34006a cc1226b on x86-linux
--- Comment #2 from hjl at lucon dot org 2006-01-22 14:51 --- I don't know anything about Ada. Can you convert the testcase into C? -- hjl at lucon dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25899
[Bug other/25757] Small memory leak in 'prefix_from_string' of file 'collect2.c'
--- Comment #2 from christophe dot jaillet at wanadoo dot fr 2006-01-22 15:35 --- Created an attachment (id=10704) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10704action=view) patch to correct the memory leak Correct the memory leak describded. Bootstrapped against i686-pc-cygwin OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25757
[Bug libgomp/25910] bootstrap failure
--- Comment #3 from aldot at gcc dot gnu dot org 2006-01-22 15:46 --- Created an attachment (id=10705) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10705action=view) Probably improper patch to make it build somehow. With this patch libgomp builds again for me. This patch is most likely not accurate, so please fix proper. In gomp_iter_dynamic_next() and gomp_iter_guided_next() i added a check for an early return, which is of course not needed to fix the bootstrap failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25910
[Bug target/25899] [4.2 Regression] ACATS FAIL c34006a cc1226b on x86-linux
--- Comment #3 from hjl at lucon dot org 2006-01-22 16:08 --- Are you sure that r109969 really works. I got mkdir -p ada/bldtools/nmake_b cp -p /net/gnu-13/export/gnu/src/gcc-last/gcc/gcc/ada/sinfo.ads /net/gnu-13/export/gnu/src/gcc-last/gcc/gcc/ada/nmake.adt /net/gnu-13/export/gnu/src/gcc-last/gcc/gcc/ada/xnmake.adb ada/bldtools/nmake_b (cd ada/bldtools/nmake_b; gnatmake -q xnmake ; ./xnmake -b ../../nmake.adb ) s-finroo.ads:65:15: identifier expected s-finroo.ads:69:15: identifier expected gnatmake: xnmake.adb compilation error /bin/sh: line 1: ./xnmake: No such file or directory make[3]: *** [ada/nmake.adb] Error 127 make[3]: Leaving directory `/export/build/gnu/gcc-last/build-i686-linux/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/export/build/gnu/gcc-last/build-i686-linux' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/export/build/gnu/gcc-last/build-i686-linux' make: *** [all] Error 2 when I tried to build C and Ada with r109969. -- hjl at lucon dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25899
[Bug target/25899] [4.2 Regression] ACATS FAIL c34006a cc1226b on x86-linux
--- Comment #4 from hjl at lucon dot org 2006-01-22 16:14 --- I got the same Ada bootrap problem with revision 109968. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25899
[Bug ada/18819] [4.1/4.2 Regression] ACATS cdd2a01 cdd2a02 fail at runtime
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2006-01-22 16:31 --- Created an attachment (id=10706) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10706action=view) Other patch for miscompilation on s390x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug target/25899] [4.2 Regression] ACATS FAIL c34006a cc1226b on x86-linux
--- Comment #5 from laurent at guerby dot net 2006-01-22 16:50 --- It does work for me. What is the version of your host Ada compiler? On the machine I used to bootstrap 109969 it is: $ gnatls -v GNATLS 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) ... mkdir -p ada/bldtools/nmake_b cp -p /n/05/guerby/trunk-109969/gcc/ada/sinfo.ads /n/05/guerby/trunk-109969/gcc/ada/nmake.adt /n/05/guerby/trunk-109969/gcc/ada/xnmake.adb ada/bldtools/nm\ ake_b (cd ada/bldtools/nmake_b; gnatmake -q xnmake ; ./xnmake -b ../../nmake.adb ) mkdir -p ada/bldtools/nmake_s cp -p /n/05/guerby/trunk-109969/gcc/ada/sinfo.ads /n/05/guerby/trunk-109969/gcc/ada/nmake.adt /n/05/guerby/trunk-109969/gcc/ada/xnmake.adb ada/nmake.adb a\ da/bldtools/nmake_s (cd ada/bldtools/nmake_s; gnatmake -q xnmake ; ./xnmake -s ../../nmake.ads ) -- laurent at guerby dot net changed: What|Removed |Added Last reconfirmed|2006-01-21 23:33:03 |2006-01-22 16:50:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25899
[Bug c/25912] New: Problem compiling Asterisk 1.2.2 with Debian 3.1 (Sarge) gcc (3.3.5 (Debian 1:3.3.5-13))
When I try to compile Asterisk 1.2.2 on a pretty standard Debian 3.1 Sarge system, I get the following: gcc -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declaration s -g3 -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE -O6 -march=i586 -fomit-frame-pointer-c -o channel.o channel.c channel.c: In function `ast_channel_bridge': channel.c:3537: internal compiler error: Segmentatie fout Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-3.3/README.Bugs. make: *** [channel.o] Fout 1 [EMAIL PROTECTED]:~/asterisk-1.2.2$ gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,ob jc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --enable-__cxa_atexi t --with-system-zlib --enable-nls --without-included-gettext --enable-clocale=gn u --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc versie 3.3.5 (Debian 1:3.3.5-13) -- Summary: Problem compiling Asterisk 1.2.2 with Debian 3.1 (Sarge) gcc (3.3.5 (Debian 1:3.3.5-13)) Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: julius at zgod dot cjb dot net GCC build triplet: i386-pc-linux-gnu GCC host triplet: i386-pc-linux-gnu GCC target triplet: i386-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25912
[Bug target/25898] [4.2 Regression] All Ada tests fail
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-22 17:11 --- Reopen, this is a bug in Ada's checking mechanism and not really in the driver. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25898
[Bug target/25898] [4.2 Regression] All Ada tests fail
--- Comment #10 from hjl at lucon dot org 2006-01-22 17:28 --- Can you remove the installed gcc 4.2 and rerun the Ada tests to see what happens? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25898
[Bug c++/10891] code using dynamic_cast causes segfaults when -fno-rtti is used
--- Comment #3 from gdr at gcc dot gnu dot org 2006-01-22 17:32 ---
Subject: Bug 10891
Author: gdr
Date: Sun Jan 22 17:32:30 2006
New Revision: 110092
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110092
Log:
2006-01-22 Gabriel Dos Reis [EMAIL PROTECTED]
PR c++/10891
* rtti.c (build_dynamic_cast): Reject dynamic_cast use if
-fno-rtti.
testsuite/
2006-01-22 Gabriel Dos Reis [EMAIL PROTECTED]
PR c++/10891
* g++.dg/rtti/no-rtti.C: New.
Added:
trunk/gcc/testsuite/g++.dg/rtti/no-rtti.C (with props)
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/rtti.c
trunk/gcc/testsuite/ChangeLog
Added: trunk/gcc/testsuite/g++.dg/rtti/no-rtti.C
URL:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/g%2B%2B.dg/rtti/no-rtti.C?root=gccview=autorev=110092
==
--- trunk/gcc/testsuite/g++.dg/rtti/no-rtti.C (added)
+++ trunk/gcc/testsuite/g++.dg/rtti/no-rtti.C Sun Jan 22 17:32:30 2006
@@ -1,0 +1,18 @@
+// { dg-do compile }
+// { dg-options -fno-rtti }
+
+// PR C++/10891
+
+struct A {
+ virtual ~A() { }
+};
+
+struct B : A {
+};
+
+A* f();
+
+int main()
+{
+ B* b = dynamic_castB*(f()); // { dg-error error: }
+}
Propchange: trunk/gcc/testsuite/g++.dg/rtti/no-rtti.C
('svn:mime-type' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10891
[Bug c++/10891] code using dynamic_cast causes segfaults when -fno-rtti is used
--- Comment #4 from gdr at gcc dot gnu dot org 2006-01-22 17:39 --- Fixed in 4.2.0. -- gdr at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10891
[Bug c/25912] Problem compiling Asterisk 1.2.2 with Debian 3.1 (Sarge) gcc (3.3.5 (Debian 1:3.3.5-13))
--- Comment #1 from julius at zgod dot cjb dot net 2006-01-22 17:41 --- Created an attachment (id=10707) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10707action=view) gcc -v -save-temps ... gcc -v -save-temps -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g3 -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE -O6 -march=i586 -fomit-frame-pointer -c -o channel.c This is my first bug in the GCC Bugzilla, I hope this is the correct file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25912
[Bug c++/11224] [3.4 regression] warning value computed is not used no longer emitted
--- Comment #14 from gdr at gcc dot gnu dot org 2006-01-22 17:44 --- Fixed in 4.0.0 and higher. Won't fix in 3.4.x -- gdr at gcc dot gnu dot org changed: What|Removed |Added CC||gdr at gcc dot gnu dot org Target Milestone|3.4.6 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11224
[Bug tree-optimization/25909] Internal compiler error when compiling qt4.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |blocker Component|c++ |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25909
[Bug fortran/17741] ICE in gfc_free_namespace, at fortran/symbol.c:2208
--- Comment #2 from kargl at gcc dot gnu dot org 2006-01-22 19:18 --- Here's the back trace. #0 gfc_free_namespace (ns=0x861d800) at ../../gcc4x/gcc/fortran/symbol.c:2361 #1 0x0808a292 in free_sym_tree (sym_tree=0x8616560) at ../../gcc4x/gcc/fortran/symbol.c:2328 #2 0x0808a2e3 in gfc_free_namespace (ns=0x861d800) at ../../gcc4x/gcc/fortran/symbol.c:2376 #3 0x0808a3ea in gfc_symbol_done_2 () at ../../gcc4x/gcc/fortran/symbol.c:2423 #4 0x08073318 in gfc_done_2 () at ../../gcc4x/gcc/fortran/misc.c:293 #5 0x080786e6 in unexpected_eof () at ../../gcc4x/gcc/fortran/parse.c:1242 #6 0x08079439 in parse_spec (st=ST_NONE) at ../../gcc4x/gcc/fortran/parse.c:1395 #7 0x08079791 in parse_spec (st=ST_INTERFACE) at ../../gcc4x/gcc/fortran/parse.c:1526 #8 0x08079a55 in parse_progunit (st=ST_ALLOCATE) at ../../gcc4x/gcc/fortran/parse.c:2328 #9 0x0807a0e0 in gfc_parse_file () at ../../gcc4x/gcc/fortran/parse.c:2631 The 2nd Error is trying to clean up a name space where the reference count has not been increment from 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17741
[Bug fortran/25901] [gfortran, 4.2.0 regression] overloaded function is rejected
--- Comment #1 from pault at gcc dot gnu dot org 2006-01-22 19:54 --- I have just posted the patch that I intend to commit tomorrow. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25901
[Bug libstdc++/25913] New: Client's isnormal function is broken by cmath
I believe the program below should compile:
#include cmath
#include string
struct employee
: private std::string
{
};
struct manager
: public employee
{
};
bool isnormal(const employee e)
{
return false;
}
int main()
{
manager m;
bool b = isnormal(m);
}
cmath: error: invalid cast from type 'manager' to type 'double'
--
Summary: Client's isnormal function is broken by cmath
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25913
[Bug libstdc++/25913] Client's isnormal function is broken by cmath
--- Comment #1 from gdr at cs dot tamu dot edu 2006-01-22 20:10 --- Subject: Re: New: Client's isnormal function is broken by cmath hhinnant at apple dot com [EMAIL PROTECTED] writes: | I believe the program below should compile: Does the problem exist if you configure with --disable-c99? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25913
[Bug libstdc++/25913] Client's isnormal function is broken by cmath
--- Comment #2 from hhinnant at apple dot com 2006-01-22 20:25 --- (In reply to comment #1) Does the problem exist if you configure with --disable-c99? I haven't tried that configuration. The docs say that setting may change libstdc++'s ABI. So this is expected behavior for the default configuration? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25913
[Bug libstdc++/25913] Client's isnormal function is broken by cmath
--- Comment #3 from gdr at cs dot tamu dot edu 2006-01-22 20:42 --- Subject: Re: Client's isnormal function is broken by cmath hhinnant at apple dot com [EMAIL PROTECTED] writes: | (In reply to comment #1) | | Does the problem exist if you configure with --disable-c99? | | I haven't tried that configuration. The docs say that setting may change | libstdc++'s ABI. Indeed. The question was to what extent the issue is completely fixable. | So this is expected behavior for the default configuration? if you keep ADL and template deduction, sort of :-) This is the error I get: /home/gdr/lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/cmath: In function 'int __gnu_cxx::__capture_isnormal(_Tp) [with _Tp = manager]': /home/gdr/lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/cmath:537: instantiated from 'int std::isnormal(_Tp) [with _Tp = manager]' t.C:22: instantiated from here /home/gdr/lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/cmath:466: error: cannot convert 'manager' to 'long double' for argument '1' to 'int __fpclassifyl(long double)' /home/gdr/lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/cmath:466: error: cannot convert 'manager' to 'double' for argument '1' to 'int __fpclassify(double)' /home/gdr/lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/cmath:466: error: cannot convert 'manager' to 'float' for argument '1' to 'int __fpclassifyf(float)' which shows that std::isnormal is being used -- because it provides a better match. Two issues here: (1) the std::isnormal template is way too liberal -- probably needs an enable-if decoration. (2) std::isnormal is there only if C99 is enabled with a compbination of C99 macro dynamic. See the contrived logic in std_cmath.h. (3) even when isnormal is enable-if hacked, you still potentially run into the same problem. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25913
[Bug libstdc++/25913] Client's isnormal function is broken by cmath
--- Comment #4 from hhinnant at apple dot com 2006-01-22 20:49 --- (In reply to comment #3) (3) even when isnormal is enable-if hacked, you still potentially run into the same problem. For example? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25913
[Bug libstdc++/25913] Client's isnormal function is broken by cmath
--- Comment #5 from gdr at cs dot tamu dot edu 2006-01-22 21:17 --- Subject: Re: Client's isnormal function is broken by cmath hhinnant at apple dot com [EMAIL PROTECTED] writes: | (In reply to comment #3) | |(3) even when isnormal is enable-if hacked, you still potentially |run into the same problem. | | For example? Plain #include math.h -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25913
[Bug other/25914] New: strsignal.c:558: warning: comparison between signed and unsigned
/mnt/gnu/gcc-3.3/objdir/./gcc/xgcc -B/mnt/gnu/gcc-3.3/objdir/./gcc/
-B/opt/gnu64
/gcc/gcc-4.2.0/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-4.2.0/hppa64-hp-hpu
x11.11/lib/ -isystem /opt/gnu64/gcc/gcc-4.2.0/hppa64-hp-hpux11.11/include
-isyst
em /opt/gnu64/gcc/gcc-4.2.0/hppa64-hp-hpux11.11/sys-include -c -DHAVE_CONFIG_H
-
O2 -g -O2 -I. -I../../../gcc/libiberty/../include -W -Wall -pedantic
-Wwrite-s
trings -Wstrict-prototypes ../../../gcc/libiberty/strsignal.c -o strsignal.o
../../../gcc/libiberty/strsignal.c: In function 'psignal':
../../../gcc/libiberty/strsignal.c:558: warning: comparison between signed and
u
nsigned
#ifndef HAVE_PSIGNAL
void
psignal (unsigned signo, char *message)
{
if (signal_names == NULL)
{
init_signal_tables ();
}
if ((signo = 0) || (signo = sys_nsig))
I'm not sure whether the if should be fixed or the type of signo
should be changed to int. The first argument in the linux implementation
has the type of int.
--
Summary: strsignal.c:558: warning: comparison between signed and
unsigned
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
GCC build triplet: hppa*-*-hpux*
GCC host triplet: hppa*-*-hpux*
GCC target triplet: hppa*-*-hpux*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25914
[Bug c++/24996] [4.0/4.1/4.2 Regression] ICE on throw code
--- Comment #11 from rakdver at gcc dot gnu dot org 2006-01-22 21:49
---
This ICE works this way: to build_throw, we get expression exp that looks like
TARGET_EXPR D.2066, b ? aggr_init_expr (... t1 ...) : aggr_init_expr (... t2
...)
Where t1 and t2 are TARGET_EXPRs with cleanups (*). build_throw generates code
TARGET_EXPR D.2069, __cxa_allocate_exception (1);
try
{
*(struct logic_error *) D.2069 = exp;
}
catch
{
__cxa_free_exception (D.2069);
};
__cxa_throw (D.2069, (void *) _ZTI11logic_error, 0B);
This is a problem, since exp (that contains cleanups) is withing the try
statement,
and gimplify_cleanup_expr expects that there never is a compound statement
between
cleanup and cleanup_point_expr (except for COND_EXPRs).
For comparison, with
void foo(bool b) {
throw logic_error(1);
}
exp is
TARGET_EXPR D.2066, aggr_init_expr (... t1 ...)
In this case, however, stabilize_init will allow to pre-evaluate t1, and the
produced
code is (where exp' is exp with t1 replaced by tmp):
TARGET_EXPR tmp, t1
TARGET_EXPR D.2069, __cxa_allocate_exception (1);
try
{
*(struct logic_error *) D.2069 = exp';
}
catch
{
__cxa_free_exception (D.2069);
};
__cxa_throw (D.2069, (void *) _ZTI11logic_error, 0B);
Here gimplify_cleanup_expr has no problem, since t1 is outside of the try
statement.
Now the question is whether we can persuade throw_expr to also evaluate
(the relevant parts of) exp outside of the try statement. Answering this
question
is far beyond my understanding of c++ frontend; stabilize_init claims that
/* If the initializer is a COND_EXPR, we can't preevaluate
anything. */
if (TREE_CODE (t) == COND_EXPR)
return false;
which might suggest that it is not possible, but the statement is too vague for
me to
be sure.
If it is somehow possible, it would be much preferable. The other possibility
is to teach
gimplify_cleanup_expr to deal with try statements, which basically means to
rewrite it
completely from scratch.
--
(*) The exact expression is
TARGET_EXPR D.2066
init: bD.2024
? TARGET_EXPR D.2062
init: aggr_init_expr (__comp_ctor ;
0B, (struct string ) TARGET_EXPR D.2061
init: aggr_init_expr
(__comp_ctor ;
0B, 0, (struct
allocator ) (struct allocator *) TARGET_EXPR D.2045
init: {}
clean: __comp_dtor (D.2045);
D.2061)
D.2062)
: TARGET_EXPR D.2065
init: aggr_init_expr (__comp_ctor ;
0B, (struct string ) TARGET_EXPR D.2064
init: aggr_init_expr
(__comp_ctor ;
0B, 1, (struct
allocator ) (struct allocator *) TARGET_EXPR D.2063
init: {}
clean: __comp_dtor (D.2063);
D.2064)
D.2065)
;
;
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
CC||mark at codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24996
[Bug ada/18819] [4.1/4.2 Regression] ACATS cdd2a01 cdd2a02 fail at runtime
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2006-01-22 22:29 --- (From update of attachment 10701) Probably too gross. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Attachment #10701|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug c++/25915] New: instantiated templates with anonymous classes as arguments should be static
Consider:
---
template typename foo
void bar() {}
namespace { class C {};}
void (*FP)() = barC;
---
Because 'bar' is instantiated with 'C', a class in an anonymous namespace, this
instantiation can never be shared across other translation units. As such, it
should be marked static, to improve static and dynamic link times and improve
future IPO potential.
On PPC Darwin, the instantion of bar turns into:
.section __TEXT,__textcoal_nt,coalesced,no_toc
.align 2
.weak_definition __Z3barIN21_GLOBAL__N_t.cczMkGAb1CEEvv
.private_extern __Z3barIN21_GLOBAL__N_t.cczMkGAb1CEEvv
.section __TEXT,__textcoal_nt,coalesced,no_toc
.align 2
__Z3barIN21_GLOBAL__N_t.cczMkGAb1CEEvv:
blr
-Chris
--
Summary: instantiated templates with anonymous classes as
arguments should be static
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25915
[Bug c++/25915] instantiated templates with anonymous classes as arguments should be static
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25915
[Bug rtl-optimization/25890] [4.2 regression] testsuite failure: gcc.c-torture/compile/20051228-1.c
--- Comment #2 from jsm28 at gcc dot gnu dot org 2006-01-23 00:46 --- Appeared on ia64-hp-hpux11.23 between revisions 109876 and 110062. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added CC||jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25890
[Bug target/25917] New: [4.0] gcc.c-torture/compile/20051228-1.c fails
The following appeared on 4.0 branch (only) on ia64-hp-hpux11.23, -milp32 only, between 20060104 (revision 109314) and 20060106 (revision 109408), presumably when this test was added. Appears unrelated to bug 25890 concerning the same testcase on mainline. FAIL: gcc.c-torture/compile/20051228-1.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/20051228-1.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/20051228-1.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/20051228-1.c -Os (test for excess errors) /var/tmp//ccbMrJGq.s: Assembler messages: /var/tmp//ccbMrJGq.s:20: Error: Operand 3 of `extr.u' should be a 6-bit bit pos (0-63) -- Summary: [4.0] gcc.c-torture/compile/20051228-1.c fails Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org GCC target triplet: ia64-*-hpux* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25917
[Bug tree-optimization/25918] New: gcc.dg/vect/vect-reduc-dot-s16.c scan-tree-dump-times vectorized 1 loops 1 and gcc.dg/vect/vect-reduc-pattern-2.c scan-tree-dump-times vectorized 2 loops 1 fail
The following appeared on mainline on ia64-hp-hpux11.23 (both -milp32 and -mlp64) between 20060118 (revision 109876) and 20060121 (revision 110062), probably when these tests were added. FAIL: gcc.dg/vect/vect-reduc-dot-s16.c scan-tree-dump-times vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-reduc-pattern-2.c scan-tree-dump-times vectorized 2 loops 1 -- Summary: gcc.dg/vect/vect-reduc-dot-s16.c scan-tree-dump-times vectorized 1 loops 1 and gcc.dg/vect/vect-reduc-pattern- 2.c scan-tree-dump-times vectorized 2 loops 1 fail Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25918
[Bug c++/11856] unsigned warning in template
--- Comment #10 from gdr at gcc dot gnu dot org 2006-01-23 01:17 ---
With this code:
template typename t
void f(t c) {
assert(0 = c and c = 2);
}
int main() {
funsigned char(5);
}
I only get a warning on instantiation.
I see, I oversimplified the problem a bit. Here is a better example:
--
#include cassert
template typename Int, Int D
void f(Int x) {
assert(0 = x and x = D);
}
This kind of template tends to be common place for certain catgories
of codes. It is annoying. This also manifests in gcjx.
I don't know which way to go yet, but certainly it should be
controlable by -Walways-true.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
||org, gdr at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
[Bug c++/12242] g++ should warn about out-of-range int-enum conversions
--- Comment #6 from gdr at gcc dot gnu dot org 2006-01-23 01:20 --- Working on a patch. -- gdr at gcc dot gnu dot org changed: What|Removed |Added CC||gdr at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |gdr at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-11 23:27:30 |2006-01-23 01:20:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12242
[Bug c++/11856] unsigned warning in template
--- Comment #11 from gdr at cs dot tamu dot edu 2006-01-23 01:23 ---
Subject: Re: unsigned warning in template
gdr at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| I see, I oversimplified the problem a bit. Here is a better example:
| --
| #include cassert
| template typename Int, Int D
| void f(Int x) {
|assert(0 = x and x = D);
| }
|
| This kind of template tends to be common place for certain catgories
| of codes. It is annoying.
To be clear, it is not the template, it is the warning in case
there is a doubt :-)
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
[Bug tree-optimization/25909] Internal compiler error when compiling qt4.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-23 01:26 --- this 4.1 is old, please update your GCC. *** This bug has been marked as a duplicate of 23948 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25909
[Bug tree-optimization/23948] [4.1 Regression] internal compiler error: verify_stmts failed
--- Comment #25 from pinskia at gcc dot gnu dot org 2006-01-23 01:26 --- *** Bug 25909 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dawid dot ciezarkiewicz at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23948
[Bug tree-optimization/25911] [4.2 Regression] ice in vect_recog_dot_prod_pattern
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |tree-optimization Keywords||ice-on-valid-code Summary|ice in |[4.2 Regression] ice in |vect_recog_dot_prod_pattern |vect_recog_dot_prod_pattern Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25911
[Bug testsuite/25766] objc.dg/stret-2.m fails on i686-darwin
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-23 02:08 --- I should note the reason why I filed this bug here is because this is a GCC testsuite failure on i686-darwin. Even though this is testing the NeXT runtime, this is still a bug in either the objc front-end or the testsuite of GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25766
[Bug testsuite/25891] gomp tests run on non-libgomp (non-thread) ports, failing all
--- Comment #1 from hp at gcc dot gnu dot org 2006-01-23 04:11 --- I'll see if I can fix it with the suggestion in the description of this PR. -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-23 04:11:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25891
[Bug fortran/25901] [gfortran, 4.2.0 regression] overloaded function is rejected
--- Comment #2 from pault at gcc dot gnu dot org 2006-01-23 05:07 --- Subject: Bug 25901 Author: pault Date: Mon Jan 23 05:07:52 2006 New Revision: 110106 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110106 Log: 2005-01-23 Paul Thomas [EMAIL PROTECTED] PR fortran/25901 * decl.c (get_proc_name): Replace subroutine and function attributes in already defined test by the formal arglist pointer being non-NULL. Fix regression in testing of admissability of attributes. * symbol.c (gfc_add_attribute): If the current_attr has non-zero intent, do not do the check for a dummy being used. * decl.c (attr_decl1): Add current_attr.intent as the third argument in the call to gfc_add_attribute. * gfortran.h: Add the third argument to the prototype for gfc_add_attribute. 2005-01-23 Paul Thomas [EMAIL PROTECTED] PR fortran/25901 * gfortran.dg/internal references_2.f90: New test. Fix regression in testing of admissability of attributes. * gfortran.dg/intent_used_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/intent_used_1.f90 trunk/gcc/testsuite/gfortran.dg/internal_references_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/libgomp/Makefile.in trunk/libgomp/aclocal.m4 trunk/libgomp/testsuite/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25901
[Bug c++/24996] [4.0/4.1/4.2 Regression] ICE on throw code
--- Comment #12 from mmitchel at gcc dot gnu dot org 2006-01-23 05:10
---
I don't fully understand stabilize_expr; that's Jason's invention, IIRC.
However, I think that the problem is that for a COND_EXPR we can't pre-evaluate
both arms of the conditional, because only one of them is supposed to be
executed at runtime.
I think this is a bug in the gimplifier. I certainly don't see anything in the
documentation for CLEANUP_EXPR that suggests the restriction you've described.
I suppose that we could try to turn:
b ? T(x) : T(y)
into:
SAVE_EXPR b,
TARGET_EXPR (tmp, b ? T(tmp, x) : T(tmp, y), b ? cleanup1 : cleanup2)
but that seems difficult, and I'm not sure it would work.
By the way, here's a simpler test case:
struct A {
A();
~A();
};
struct S {
S(const A);
~S();
};
void foo(bool b)
{
throw b ? S(A()) : throw 0;
}
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24996
[Bug target/25899] [4.2 Regression] ACATS FAIL c34006a cc1226b on x86-linux
--- Comment #6 from hjl at lucon dot org 2006-01-23 05:32 --- I think it is a latent bug. When I added -mtune=k8 with revsion 109969, I got the same failure on c34006a. Laurent, can you verify it as well as cc1226b? Why do we only see it in Ada? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25899
[Bug target/25899] [4.2 Regression] ACATS FAIL c34006a cc1226b on x86-linux
--- Comment #7 from hjl at lucon dot org 2006-01-23 05:34 --- [EMAIL PROTECTED] ada-1]$ make /export/build/gnu/gcc-last/build-i686-linux/gcc/xgcc -B/export/build/gnu/gcc-last/build-i686-linux/gcc/ -v Reading specs from /export/build/gnu/gcc-last/build-i686-linux/gcc/specs Target: i686-pc-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc-last/gcc/configure --enable-clocale=gnu --with-system-zlib --disable-libunwind-exceptions --with-demangler-in-ld --enable-languages=c,ada --enable-shared --enable-threads=posix --enable-haifa --disable-checking --prefix=/usr/gcc-last --with-local-prefix=/usr/local Thread model: posix gcc version 4.2.0 20060119 (experimental) [trunk revision 109969 clean] ADA_INCLUDE_PATH=/export/build/gnu/gcc-last/build-i686-linux/gcc/ada/rts ADA_OBJECTS_PATH=/export/build/gnu/gcc-last/build-i686-linux/gcc/ada/rts /export/build/gnu/gcc-last/build-i686-linux/gcc/xgcc -B/export/build/gnu/gcc-last/build-i686-linux/gcc/ -gnatws -O2 -I/export/build/gnu/gcc-next/build-i686-linux/gcc/testsuite/ada/acats/support -c c34006a.adb /export/build/gnu/gcc-next/build-i686-linux/gcc/gnatbind -aO./ -I/export/build/gnu/gcc-next/build-i686-linux/gcc/testsuite/ada/acats/support -I- -x c34006a.ali /export/build/gnu/gcc-next/build-i686-linux/gcc/gnatlink c34006a.ali --GCC=/export/build/gnu/gcc-next/build-i686-linux/gcc/xgcc -B/export/build/gnu/gcc-next/build-i686-linux/gcc/ ./c34006a ,.,. C34006A ACATS 2.5 06-01-22 21:33:54 C34006A CHECK THAT THE REQUIRED PREDEFINED OPERATIONS ARE DECLARED (IMPLICITLY) FOR DERIVED RECORD TYPES WITHOUT DISCRIMINANTS AND WITH NON-LIMITED COMPONENT TYPES. C34006A PASSED . [EMAIL PROTECTED] ada-1]$ make clean rm -f c34006a c34006a.o [EMAIL PROTECTED] ada-1]$ make /export/build/gnu/gcc-last/build-i686-linux/gcc/xgcc -B/export/build/gnu/gcc-last/build-i686-linux/gcc/ -v Reading specs from /export/build/gnu/gcc-last/build-i686-linux/gcc/specs Target: i686-pc-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc-last/gcc/configure --enable-clocale=gnu --with-system-zlib --disable-libunwind-exceptions --with-demangler-in-ld --enable-languages=c,ada --enable-shared --enable-threads=posix --enable-haifa --disable-checking --prefix=/usr/gcc-last --with-local-prefix=/usr/local Thread model: posix gcc version 4.2.0 20060119 (experimental) [trunk revision 109969 clean] ADA_INCLUDE_PATH=/export/build/gnu/gcc-last/build-i686-linux/gcc/ada/rts ADA_OBJECTS_PATH=/export/build/gnu/gcc-last/build-i686-linux/gcc/ada/rts /export/build/gnu/gcc-last/build-i686-linux/gcc/xgcc -B/export/build/gnu/gcc-last/build-i686-linux/gcc/ -gnatws -O2 -I/export/build/gnu/gcc-next/build-i686-linux/gcc/testsuite/ada/acats/support -mtune=k8 -c c34006a.adb /export/build/gnu/gcc-next/build-i686-linux/gcc/gnatbind -aO./ -I/export/build/gnu/gcc-next/build-i686-linux/gcc/testsuite/ada/acats/support -I- -x c34006a.ali /export/build/gnu/gcc-next/build-i686-linux/gcc/gnatlink c34006a.ali --GCC=/export/build/gnu/gcc-next/build-i686-linux/gcc/xgcc -B/export/build/gnu/gcc-next/build-i686-linux/gcc/ ./c34006a ,.,. C34006A ACATS 2.5 06-01-22 21:34:11 C34006A CHECK THAT THE REQUIRED PREDEFINED OPERATIONS ARE DECLARED (IMPLICITLY) FOR DERIVED RECORD TYPES WITHOUT DISCRIMINANTS AND WITH NON-LIMITED COMPONENT TYPES. * C34006A INCORRECT :=. * C34006A INCORRECT QUALIFICATION. * C34006A INCORRECT SELF CONVERSION. * C34006A INCORRECT CONVERSION TO PARENT. * C34006A INCORRECT SELECTION (VALUE). C34006A FAILED . [EMAIL PROTECTED] ada-1]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25899
[Bug testsuite/25891] gomp tests run on non-libgomp (non-thread) ports, failing all
--- Comment #2 from hp at gcc dot gnu dot org 2006-01-23 05:52 --- http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01515.html -- hp at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25891
[Bug target/25899] [4.2 Regression] ACATS FAIL c34006a cc1226b on x86-linux
--- Comment #8 from hjl at lucon dot org 2006-01-23 06:03 --- This is very strange. Even without the -mtune=generic patch, c34006a fails on Linux/i686 with -Os, -mtune[i386 i486 pentium k6 athlon k8 pentium4 nocona]. Laurent, do you know why? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25899
[Bug target/25919] New: Bootstrap failure with ICE in expand_compound_operation
The mainline compiler for sh4-*-linux-gnu fails during libgcc build:
/exp/ldroot/dodes/xsh-gcc-orig/./gcc/xgcc
-B/exp/ldroot/dodes/xsh-gcc-orig/./gcc/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC
-DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic
-DNO_FPSCR_VALUES -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-I. -I. -I../../ORIG/trunk/gcc -I../../ORIG/trunk/gcc/.
-I../../ORIG/trunk/gcc/../include -I../../ORIG/trunk/gcc/../libcpp/include
-I../../ORIG/trunk/gcc/../libdecnumber -I../libdecnumber -DL_negvsi2
-fvisibility=hidden -DHIDE_EXPORTS -c ../../ORIG/trunk/gcc/libgcc2.c -o
libgcc/./_negvsi2.o
../../ORIG/trunk/gcc/libgcc2.c: In function '__negvsi2':
../../ORIG/trunk/gcc/libgcc2.c:174: internal compiler error: in
expand_compound_operation, at combine.c:5644
A reduced testcase is:
void foo (int a)
{
int w = -a;
if (a = 0 ? w 0 : w 0)
bar ();
}
which fails to compile with -O. This ICEs also on sh-elf with -O -m4.
Binary search shows that it starts to fail after the patch:
r109961 | bonzini | 2006-01-19 23:54:57 +0900 (Thu, 19 Jan 2006) | 13 lines
2006-01-19 Paolo Bonzini [EMAIL PROTECTED]
* combine.c (try_combine): Do not worry about MEMs wrapped by USEs.
(expand_compound_operation, expand_field_assignment): Fail if the
bit lengths of an extract operation are out of range.
(make_extraction): Compute wanted_inner_mode based on the position
and length of the extraction. Make it extraction_mode for non-constant
positions, and do not modify offset in that case. When generating a
new MEM, use a mode that can hold the extraction while keeping correct
alignment. Remove code that supported MEMs wrapped by USEs.
(simplify_shift_const_1, force_to_mode) case USE: Remove.
--
Summary: Bootstrap failure with ICE in expand_compound_operation
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, build, ice-checking
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: sh4-*-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25919
[Bug fortran/25920] New: after compiled with -pg for profiling, all the spec2kfp cases failed at runtime
after compiled with -pg, all the spec2kfp cases (including both c and fortran cases ) failed at runtime, with the error message : segmentation fault. -- Summary: after compiled with -pg for profiling, all the spec2kfp cases failed at runtime Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yhd at ict dot ac dot cn GCC build triplet: ia64-unknown-linux-gnu GCC host triplet: ia64 - itanium 2 - linux 2.1AS 2.4.18-e.12smp GCC target triplet: ia64 - itanium 2 - linux 2.1AS 2.4.18-e.12smp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25920
[Bug fortran/25920] after compiled with -pg for profiling, all the spec2kfp cases failed at runtime
--- Comment #1 from yhd at ict dot ac dot cn 2006-01-23 06:57 --- This bug also exist when i tried gcc 3.3.4, on itanium 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25920
