[Bug rtl-optimization/27735] [4.2 Regression] ICE at -O3 caused by loop unswitching
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-25 06:48 --- *** Bug 28843 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||twhall at twhall dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27735
[Bug fortran/28843] internal compiler error: in verify_loop_structure, at cfgloop.c:1268
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-25 06:48 --- *** This bug has been marked as a duplicate of 27735 *** -- 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=28843
[Bug other/28824] "no multiarch mapping for multilib" should be an error, not an ICE
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-25 06:39 --- This is a bug specific to Debian's GCC. There is no such ICE in the whole of GCC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28824
[Bug fortran/28843] New: internal compiler error: in verify_loop_structure, at cfgloop.c:1268
gfortran fails with an internal error when the attached file is compiled with -O3 optimization: error: edge from 62 to 64 should not be marked irreducible error: basic block 64 should not be marked irreducible error: edge from 64 to 53 should not be marked irreducible internal compiler error: in verify_loop_structure, at cfgloop.c:1268 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. The error does not occur with -O2 optimization. Comand line and output: gfortran -v -c -O3 -std=legacy -fargument-alias -fno-backslash -fdollar-ok -ffixed-line-length-72 -Wsurprising -Wuninitialized -W -fno-f2c pg3cl9.f Using built-in specs. Target: i386-apple-darwin8.7.1 Configured with: ../gcc-4.2-20060805/configure --enable-languages=fortran Thread model: posix gcc version 4.2.0 20060805 (experimental) /usr/local/libexec/gcc/i386-apple-darwin8.7.1/4.2.0/f951 pg3cl9.f -ffixed-form -fPIC -quiet -dumpbase pg3cl9.f -mtune=i386 -auxbase pg3cl9 -O3 -Wsurprising -Wuninitialized -W -std=legacy -version -fargument-alias -fno-backslash -fdollar-ok -ffixed-line-length-72 -fno-f2c -I /usr/local/lib/gcc/i386-apple-darwin8.7.1/4.2.0/finclude -o /var/tmp//ccEAPkTX.s GNU F95 version 4.2.0 20060805 (experimental) (i386-apple-darwin8.7.1) compiled by GNU C version 4.2.0 20060805 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 pg3cl9.f: In function 'pg3cl9': pg3cl9.f:214: error: edge from 62 to 64 should not be marked irreducible pg3cl9.f:214: error: basic block 64 should not be marked irreducible pg3cl9.f:214: error: edge from 64 to 53 should not be marked irreducible pg3cl9.f:214: internal compiler error: in verify_loop_structure, at cfgloop.c:1268 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. The legacy FORTRAN source file, pg3cl9.f (This compiled with -O3 in g77) C--- C ROUTINE: PG3CL9 C PURPOSE: To assign a new type to the line segs, and to decide C which lines are to be used in the resultant PG2-SET. C C ARGS: NTOP INTEGER pointer to the starting point Cof a polygon in the linked list C ID,XP,ZP other PG3-SET C TYPE INTEGER set operation type C ICURVE INTEGER number of current PG2-SET C1=A 2=B C XMN,ZMN, REAL coordiantes of box of ID,XP,ZP. C XMX,ZMX C A,B,C,D REAL*8 coefficients of equation of Cplane of ID,XP,YP,ZP. C IDS,XS,ZSPG3-SET of edges being evaluated. C AS BS CS DS REAL*8 coeficients of equation of Cplane of IDS,XS,YS,ZS. C NUMSEG INTEGER number of segs looked at. C NUMADD INTEGER number of segs added. C--- SUBROUTINE PG3CL9 (NTOP, ICURVE, + ID, XP,ZP, TYPE, + XMN,ZMN,XMX,ZMX, + A, B, C, D, + IDS,XS,ZS, TYPES, + AS,BS,CS,DS, + NUMSEG, NUMADD, *) C C Arguments. INTEGERNTOP, ICURVE, ID(*), IDS(*), NUMSEG, NUMADD, + TYPES, TYPE REAL*8 A,B,C,D, AS,BS,CS,DS REAL XP(*),ZP(*), XS(*),ZS(*), XMN,ZMN, XMX,ZMX C C COMMON storage. INTEGER*4 NLNWMX, NPNWMX PARAMETER (NLNWMX = 5000, +NPNWMX = 5000) C COMMON /NW3SET/ LBNWA(NLNWMX), LENWA(NLNWMX), +NLNWA, +PXNWA(NPNWMX), PYNWA(NPNWMX), PZNWA(NPNWMX), +NPNWA, +LBNWB(NLNWMX), LENWB(NLNWMX), +NLNWB, +PXNWB(NPNWMX), PYNWB(NPNWMX), PZNWB(NPNWMX), +NPNWB, +LBNWC(NLNWMX), LENWC(NLNWMX), +NLNWC, +PXNWC(NPNWMX), PYNWC(NPNWMX), PZNWC(NPNWMX), +NPNWC INTEGER*4 LBNWA, LENWA, NLNWA, NPNWA, +LBNWB, LENWB, NLNWB, NPNWB, +LBNWC, LENWC, NLNWC, NPNWC REAL*4 PXNWA, PYNWA, PZNWA, +PXNWB, PYNWB, PZNWB, +PXNWC, PYNWC, PZNWC C INTEGER*4 NPMAX, NDMAX PARAMETER (NPMAX = 5000, +NDMAX = 5000) C INTEGER*4 NPOINT REAL*4 X, Y, Z LOGICAL*4 INT COMMON /TWOPT/ NPOINT, +X(NPMAX), Y(NPMAX), Z(NPMAX), INT(NPMAX) C INTEGER*4 NNODE, NODE COMMON /TWOND/ NNODE, +NODE(6,NDMAX) C REAL*4 XM1, YM1, XM2, YM2, XM3, YM3,
[Bug other/28824] "no multiarch mapping for multilib" should be an error, not an ICE
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-25 06:34 --- And I don't get an ICE though for either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28824
[Bug middle-end/28116] [4.1 Regression] ICE when building konverter with gcc-4.1 with -O3 [RSO]
--- Comment #7 from bonzini at gnu dot org 2006-08-25 06:33 ---
reduced testcase from pr28840
struct QDateTime
{
QDateTime addSecs( int secs ) const;
int t;
};
QDateTime gridToDate(long x)
{
QDateTime date;
date = date.addSecs(1);
return date;
}
void whatsOnAt(long x, long y)
{
gridToDate(x);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28116
[Bug other/28824] "no multiarch mapping for multilib" should be an error, not an ICE
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-25 06:32 --- For the mainline, I get cc1 reading from the stdin which is just plain weird. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28824
[Bug other/28824] "no multiarch mapping for multilib" should be an error, not an ICE
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-25 06:31 --- For 4.1.2, I get: cc1: error: unrecognized command line option "-imultilib" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28824
[Bug fortran/28818] C/Fortran interoperability: variable number of arguments passed from fortran to C causes Illegal instruction
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-25 06:27 --- This is not a bug as the code you are using is undefined as the Fortran program is not calling a var-args C function, it is a Fortran function which always not a var-args function. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28818
[Bug ada/28835] Incorrect numeric result in multiplication of user-defined type with universal integer
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-25 06:25 --- I am thinking this is undefined behavior because 120 is outside the range of Three. In fact with -gnato, there is a constraint error: In the output that follows, the three values of the type Three are multiplied by 120 and the result should be 0, 120, 240. The third result obtained with Gnat 3.4.6 or 4.2, is -16 which. is incorrect. 0 0 1 120 raised CONSTRAINT_ERROR : multiplication_bug.adb:16 overflow check failed so this is not a bug as far as I can tell. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28835
[Bug c++/28840] internal compiler error
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-25 06:11 ---
Note the reduced testcase is:
struct QDateTime
{
QDateTime addSecs( int secs ) const;
int t;
};
QDateTime gridToDate(long x)
{
QDateTime date;
date = date.addSecs(1);
return date;
}
void whatsOnAt(long x, long y)
{
gridToDate(x);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28840
[Bug middle-end/28116] [4.1 Regression] ICE when building konverter with gcc-4.1 with -O3 [RSO]
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-25 06:05 --- *** Bug 28840 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||eemax at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28116
[Bug c++/28840] internal compiler error
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-25 06:05 --- *** This bug has been marked as a duplicate of 28116 *** -- 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=28840
[Bug tree-optimization/28839] [4.2 Regression] ICE in tree-vectorizer.c with -O2 -ftree-vectorize -funswitch-loops
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-25 05:17 --- Confirmed, a regression from 4.1.2. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.2.0 Known to work||4.1.1 4.1.2 Last reconfirmed|-00-00 00:00:00 |2006-08-25 05:17:05 date|| Summary|ICE in tree-vectorizer.c|[4.2 Regression] ICE in |with -O2 -ftree-vectorize - |tree-vectorizer.c with -O2 - |funswitch-loops |ftree-vectorize -funswitch- ||loops Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28839
[Bug tree-optimization/28839] ICE in tree-vectorizer.c with -O2 -ftree-vectorize -funswitch-loops
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-25 05:16 ---
Testcase:
static int ready[10];
void test_once (int t,int t1)
{
int i, repeat;
for (i = 0; i < 10; i++)
{
ready[i] = 0;
if (t1)
if (b())
abort ();
}
if (t)
abort ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28839
[Bug other/27832] texi2pod issues
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-25 04:52 --- *** Bug 28842 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||adam dot buchbinder at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27832
[Bug other/28842] gcc(1) manpage has extraneous markup in it.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-25 04:52 --- *** This bug has been marked as a duplicate of 27832 *** -- 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=28842
[Bug c++/26757] C++ front-end producing two DECLs with the same UID
--- Comment #31 from pinskia at gcc dot gnu dot org 2006-08-25 04:31 --- *** Bug 28841 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||lee dot adamson at macquarie ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757
[Bug c++/28841] Quantlib compile error...
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-25 04:31 --- This is a dup of bug 26757 and was fixed in 4.1.2. *** This bug has been marked as a duplicate of 26757 *** -- 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=28841
[Bug other/28842] New: gcc(1) manpage has extraneous markup in it.
There is leftover markup from the texinfo source in the manual page for gcc(1).
Specifically, search for @pxref and @anchor, which shouldn't be showing up in
the output.
Also, the documentation for -print-multi-lib seems to be mangled:
-print-multi-lib
Print the mapping from multilib directory names to compiler
switches that enable them. The directory name is separated from
the switches by ;, and each switch starts with an @} instead of the
@samp{-, without spaces between multiple switches. This is sup-
posed to ease shell-processing.
(You can't see it here, but "instead of the" is bold as well; it should not
be.) This should likely read:
-print-multi-lib
Print the mapping from multilib directory names to compiler
switches that enable them. The directory name is separated from
the switches by ;, and each switch starts with an @ instead of the
-, without spaces between multiple switches. This is supposed
to ease shell-processing.
The source which generates this manpage is in gcc/doc/invoke.texi.
--
Summary: gcc(1) manpage has extraneous markup in it.
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adam dot buchbinder at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28842
[Bug c++/28840] internal compiler error
--- Comment #2 from fang at csl dot cornell dot edu 2006-08-25 04:10 --- possibly PR 28358 and/or PR 28116 -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28840
[Bug other/25028] TImode-to-floating conversions broken
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2006-08-25 03:59 --- After looking at this in detail, only six of the testcases for the single precision float conversions in TEST_I_F(TItype, UTItype, float, FLT_MANT_DIG) fail. These are... TEST_I_F_VAL (I, F, HVAL0S (P, I) + 1, P_OK (P, I)); \ TEST_I_F_VAL (I, F, HVAL1S (P, I) - 1, P_OK (P, I)); \ TEST_I_F_VAL (I, F, -HVAL0S (P, I) - 1, P_OK (P, I)); \ TEST_I_F_VAL (I, F, -HVAL1S (P, I) + 1, P_OK (P, I)); \ TEST_I_F_VAL (U, F, HVAL0U (P, U) + 1, P_OK (P, U)); \ TEST_I_F_VAL (U, F, HVAL1U (P, U) - 1, P_OK (P, U)); \ Might this in anyway give us some hints as to where we should look for the problem in the currently proposed TImode implementation for Darwin? This patch is at... http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00581.html as I mentioned earlier. On the positive side, we completely pass all of the testcases for double and long double conversions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25028
[Bug middle-end/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #49 from amacleod at redhat dot com 2006-08-25 01:56 --- links to the 2 notes on gcc-patches: live range changes: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00895.html TER changes: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00896.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug middle-end/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #48 from amacleod at redhat dot com 2006-08-25 01:42 --- Created an attachment (id=12136) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12136&action=view) Patch for the remaining SSA to Normal time issues I've attached a patch to address the slowdowns in TER. Again, not sure this is stage 3, but I'll send a note to gcc-patches with the full breakdown, but basically I replaced the expression linked lists with bitmaps. This patch has been bootstrapped on 1686-pc-linux-gnu with no new regressions. at -O2 timings go from: tree SSA to normal: 30.79 (19%) usr 0.06 ( 2%) sys 31.89 (19%) wall to tree SSA to normal: 1.33 ( 1%) usr 0.02 ( 1%) sys 1.86 ( 1%) wall and at -O3: tree SSA to normal: 32.08 (35%) usr 0.08 ( 1%) sys 32.92 (28%) wall to tree SSA to normal: 18.75 (24%) usr 0.06 ( 1%) sys 18.83 (23%) wall when combined with the previous live on entry/exit patch, I get the following times at -O2 : tree SSA to normal: 30.79 (19%) usr 0.06 ( 2%) sys 31.89 (19%) wall to tree SSA to normal: 1.16 ( 1%) usr 0.01 ( 0%) sys 1.17 ( 1%) wall and at -O3: tree SSA to normal: 32.08 (35%) usr 0.08 ( 1%) sys 32.92 (28%) wall to tree SSA to normal: 2.50 ( 4%) usr 0.08 ( 1%) sys 2.61 ( 2%) wall -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug middle-end/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #47 from amacleod at redhat dot com 2006-08-25 01:37 --- Created an attachment (id=12135) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12135&action=view) patch to resolve some of the SSA to Normal slowdowns. By re-implementing the live on entry/exit code, I get the following improvement at -O3: tree SSA to normal: 32.08 (35%) usr 0.08 ( 1%) sys 32.92 (28%) wall to tree SSA to normal: 16.19 (22%) usr 0.08 ( 1%) sys 16.33 (13%) wall the remaining SSA to normal time is the fault of TER at both -O3 and -O2. I'm not so sure this is stage 3 material, but I could be convinced. I'll attach the patch, but I'll post a full breakdown of what was implemented in a note to gcc-patches. It has been bootstrapped on i686-pc-linux-gnu with no new regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug other/25028] TImode-to-floating conversions broken
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2006-08-25 01:36 --- Interestingly out of the lines in the fp-int-convert-timode testcase, the one that causes the abort is... TEST_I_F(TItype, UTItype, float, FLT_MANT_DIG); The other two lines for double and long double tests pass without complaint on Darwin ppc. The exact line in fp-int-convert.h where the aborts begin for the float type is... TEST_I_F_VAL (I, F, HVAL0S (P, I) + 1, P_OK (P, I)); \ Any suggestions on how to debug this further? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25028
[Bug c++/28841] Quantlib compile error...
--- Comment #1 from lee dot adamson at macquarie dot com 2006-08-25 01:22 --- Created an attachment (id=12134) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12134&action=view) Preprocessed source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28841
[Bug debug/28834] [4.0/4.1/4.2 Regression] -O3 -g crashes sometimes when using may_alias and structs
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-25 01:20 --- Confirmed by Janis. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|i686-pc-linux-gnu |dwarf2 Last reconfirmed|-00-00 00:00:00 |2006-08-25 01:20:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug c++/28841] New: Quantlib compile error...
Error trying to compile Quantlib with gcc-4.1.1: emgsydapp42-ladamson [View: ]: /opt/gcc/gcc-4.1.1-x86-solaris2.10/bin/g++ -DHAVE_CONFIG_H -I. -I. -I../../../ql -I../../.. -I../../.. -I/home/qad/lee/x86_sol_view/usr/dev/ccase/vobs/development/imagine_vob/imagine_release/emg_quant/boost -march=pentium4 -mfpmath=sse -msse2 -O3 -ftree-vectorize -MT discretizedconvertible.lo -MD -MP -MF .deps/discretizedconvertible.Tpo -c discretizedconvertible.cpp -fPIC -DPIC -o .libs/discretizedconvertible.o discretizedconvertible.cpp: In member function 'void QuantLib::DiscretizedConvertible::addCoupon(QuantLib::Size)': discretizedconvertible.cpp:183: internal compiler error: in mark_operand_necessary, at tree-ssa-dce.c:266 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: Quantlib compile error... Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lee dot adamson at macquarie dot com GCC build triplet: i386-pc-solaris2.10 GCC host triplet: i386-pc-solaris2.10 GCC target triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28841
[Bug c++/28840] internal compiler error
--- Comment #1 from eemax at web dot de 2006-08-25 00:39 --- Created an attachment (id=12133) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12133&action=view) test case (gzipped because it's too big) [/usr/source/Radio-TV/qttv_0.0.1/qttv] dc(1)$ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1.1/configure --prefix=/usr --enable-languages=all,ada,c,c++,fortran,java,objc,obj-c++,treelang Thread model: posix gcc version 4.1.1 [/usr/source/Radio-TV/qttv_0.0.1/qttv] dc(1)$ gcc -O3 test.ii test.cpp: In member function 'void tvGuide::whatsOnAt(long int, long int)': test.cpp:15: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6336 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28840
[Bug c++/28840] New: internal compiler error
internal compiler error: in expand_expr_addr_expr_1, at expr.c:6336 -- Summary: internal compiler error Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eemax at web dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28840
[Bug driver/28528] [4.0/4.1 Regression] C language extensions override -x in C++ driver
--- Comment #11 from dannysmith at users dot sourceforge dot net 2006-08-25 00:27 --- Fixed on mainline. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Known to fail|3.4.0 4.0.0 4.1.0 4.2.0 |3.4.0 4.0.0 4.1.0 Known to work|3.3.3 |3.3.3 4.2.0 Summary|[4.0/4.1/4.2 Regression] C |[4.0/4.1 Regression] C |language extensions override|language extensions override |-x in C++ driver|-x in C++ driver http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28528
[Bug driver/28528] [4.0/4.1/4.2 Regression] C language extensions override -x in C++ driver
--- Comment #10 from dannysmith at gcc dot gnu dot org 2006-08-25 00:24 --- Subject: Bug 28528 Author: dannysmith Date: Fri Aug 25 00:24:10 2006 New Revision: 116392 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116392 Log: PR driver/28528 * g++spec.c (lang_specific_driver): Always check if we need to swallow a space-separated arg to '-x'. * lang-specs.h: Don't create ouput files for '-xc++-header' if -fsyntax-only. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/g++spec.c trunk/gcc/cp/lang-specs.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28528
[Bug bootstrap/23158] building GCC 3.3.6 fails on ppc64 with gcc4 and gcc4.1
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-08-25 00:02 --- (In reply to comment #17) > Any progress in solving this problem? I still have the same problem with my G5 > running ppc64 linux. This was not a bug in the new version of GCC but the older one which is no longer being maintained. Make sure you are using "make bootstrap" and make STAGE1_CFLAGS is not being set. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||yangdh at cableplus dot com ||dot cn http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23158
[Bug bootstrap/23158] building GCC 3.3.6 fails on ppc64 with gcc4 and gcc4.1
--- Comment #17 from yangdh at cableplus dot com dot cn 2006-08-24 23:55 --- Any progress in solving this problem? I still have the same problem with my G5 running ppc64 linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23158
[Bug debug/28834] [4.0/4.1/4.2 Regression] -O3 -g crashes sometimes when using may_alias and structs
--- Comment #3 from janis at gcc dot gnu dot org 2006-08-24 23:35 --- A regression hunt on powerpc-linux identified this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=87036 r87036 | dpatel | 2004-09-03 17:10:40 + (Fri, 03 Sep 2004) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||dpatel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug c/28839] ICE in tree-vectorizer.c
--- Comment #1 from aldot at gcc dot gnu dot org 2006-08-24 22:59 --- Created an attachment (id=12132) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12132&action=view) preprocessed from a testcase of plain gettext-0.15 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28839
[Bug c/28839] New: ICE in tree-vectorizer.c
/root/src/buildroot/build_x86_64/staging_dir/libexec/gcc/x86_64-linux-uclibc/4.2.0/cc1
-fpreprocessed gettext_test-lock.i -quiet -dumpbase gettext_test-lock.i
-mtune=generic -auxbase gettext_test-lock -O2 -version -ftree-vectorize
-funswitch-loops -fvariable-expansion-in-unroller -o /tmp/ccflUJcQ.s
GNU C version 4.2.0 20060824 (experimental) (x86_64-linux-uclibc)
compiled by GNU C version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 3bea3173e03ea3601524f7ad8491537d
test-lock.c: In function 'test_once':
test-lock.c:566: internal compiler error: in
slpeel_update_phi_nodes_for_guard1, at tree-vectorizer.c:595
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Full backtrace with original args:
(gdb) b slpeel_update_phi_nodes_for_guard1
Breakpoint 1 at 0x4fa9c0: file
/root/src/buildroot/toolchain_build_x86_64/gcc-4.2.0/gcc/tree-vectorizer.c,
line 508.
(gdb) set args -fpreprocessed gettext_test-lock.i -quiet -dumpbase
gettext_test-lock.i -mtune=nocona -march=nocona -msse -msse2 -msse3
-mfpmath=sse -auxbase gettext_test-lock -O2 -version -fPIC -ftree-loop-optimize
-ftree-vectorize -ftree-vect-loop-version -funroll-loops -freorder-blocks
-freorder-blocks-and-partition -fprefetch-loop-arrays -funswitch-loops
-fbranch-target-load-optimize -ftree-loop-linear -ftree-loop-im
-ftree-loop-ivcanon -fgcse-after-reload -fvariable-expansion-in-unroller
-fivopts -o /tmp/ccInilaw.s
(gdb) run
Starting program:
/root/src/buildroot/build_x86_64/staging_dir/libexec/gcc/x86_64-linux-uclibc/4.2.0/cc1
-fpreprocessed gettext_test-lock.i -quiet -dumpbase gettext_test-lock.i
-mtune=nocona -march=nocona -msse -msse2 -msse3 -mfpmath=sse -auxbase
gettext_test-lock -O2 -version -fPIC -ftree-loop-optimize -ftree-vectorize
-ftree-vect-loop-version -funroll-loops -freorder-blocks
-freorder-blocks-and-partition -fprefetch-loop-arrays -funswitch-loops
-fbranch-target-load-optimize -ftree-loop-linear -ftree-loop-im
-ftree-loop-ivcanon -fgcse-after-reload -fvariable-expansion-in-unroller
-fivopts -o /tmp/ccInilaw.s
GNU C version 4.2.0 20060824 (experimental) (x86_64-linux-uclibc)
compiled by GNU C version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 3bea3173e03ea3601524f7ad8491537d
Breakpoint 1, slpeel_update_phi_nodes_for_guard1 (guard_edge=0x2b5d60da1800,
loop=0xcc8b50, is_new_loop=0 '\0', new_exit_bb=0x7fd46a08,
defs=0x7fd46a10)
at
/root/src/buildroot/toolchain_build_x86_64/gcc-4.2.0/gcc/tree-vectorizer.c:508
508 {
(gdb) bt
#0 slpeel_update_phi_nodes_for_guard1 (guard_edge=0x2b5d60da1800,
loop=0xcc8b50, is_new_loop=0 '\0', new_exit_bb=0x7fd46a08,
defs=0x7fd46a10)
at
/root/src/buildroot/toolchain_build_x86_64/gcc-4.2.0/gcc/tree-vectorizer.c:508
#1 0x004fbd8b in slpeel_tree_peel_loop_to_edge (
loop=, loops=,
e=, first_niters=0x2b5d60dac900,
niters=0x2b5d60b26e70, update_first_loop_count=0 '\0')
at
/root/src/buildroot/toolchain_build_x86_64/gcc-4.2.0/gcc/tree-vectorizer.c:1168
#2 0x00501e17 in vect_do_peeling_for_loop_bound (loop_vinfo=0xcb6ef0,
ratio=0x7fd46bc8, loops=0xcbdae0)
at
/root/src/buildroot/toolchain_build_x86_64/gcc-4.2.0/gcc/tree-vect-transform.c:2609
#3 0x005068f5 in vect_transform_loop (loop_vinfo=0xcb6ef0,
loops=0xcbdae0)
at
/root/src/buildroot/toolchain_build_x86_64/gcc-4.2.0/gcc/tree-vect-transform.c:3060
#4 0x004f9336 in vectorize_loops (loops=0xcbdae0)
at
/root/src/buildroot/toolchain_build_x86_64/gcc-4.2.0/gcc/tree-vectorizer.c:2066
#5 0x004ee310 in tree_vectorize ()
at
/root/src/buildroot/toolchain_build_x86_64/gcc-4.2.0/gcc/tree-ssa-loop.c:193
#6 0x007c6c6c in execute_one_pass (pass=0xb8e600)
at /root/src/buildroot/toolchain_build_x86_64/gcc-4.2.0/gcc/passes.c:864
#7 0x007c6ddc in execute_pass_list (pass=0xb8e600)
at /root/src/buildroot/toolchain_build_x86_64/gcc-4.2.0/gcc/passes.c:911
#8 0x007c6dee in execute_pass_list (pass=0xb8e480)
at /root/src/buildroot/toolchain_build_x86_64/gcc-4.2.0/gcc/passes.c:912
#9 0x007c6dee in execute_pass_list (pass=0xb8dac0)
at /root/src/buildroot/toolchain_build_x86_64/gcc-4.2.0/gcc/passes.c:912
#10 0x0048e89e in tree_rest_of_compilation (fndecl=0x2b5d60b3e9a0)
at
/root/src/buildroot/toolchain_build_x86_64/gcc-4.2.0/gcc/tree-optimize.c:417
#11 0x0040c665 in c_expand_body (fndecl=0x2b5d60da1800)
at /root/src/buildroot/toolchain_build_x86_64/gcc-4.2.0/gcc/c-decl.c:6757
#12 0x0081d5f6 in cgraph_expand_function (node=0x2b5d60b760c0)
at
/root/src/buildroot/toolchain_build_x86_64/gcc-4.2.0/gcc/cgraphunit.c:1230
#13 0x0082
[Bug other/25028] TImode-to-floating conversions broken
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2006-08-24
22:12 ---
Strangely, while the testcase first presented here...
int printf(const char *, ...);
typedef int TItype __attribute__((mode(TI)));
TItype x = -1;
int main(void) { printf("%f %f\n", (float)x, (double)x); return 0; }
works fine on Darwin with the proposed TImode support, the actual
fp-int-convert-timode.c testcase aborts.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25028
[Bug rtl-optimization/19097] [4.1/4.2 regression] Quadratic behavior with many sets for the same register in VRP
--- Comment #40 from amylaar at gcc dot gnu dot org 2006-08-24 20:50 --- (In reply to comment #37) > For a proper patch, the number should of course be a PARAM and I think using > bitmap_count_bits penalizes the common case too much (walking the whole bitmap > is cache expensive even for small bitmaps). How about: - if (vr && vr->equiv) + if (vr && vr->equiv && vr->equiv->first && (!vr->equiv->first->next || bitmap_count_bits (vr->equiv) < VRP_EQUIVALENCE_THRESHOLD))) bitmap_ior_into (equiv, vr->equiv); The 0 bit case is sped up, and the 1 bit case is guaranteed to only need two pointer dereferences to check that there are not too many bits. Other small bit numbers should still have a high likelyhood to he handled without a bitmap_count_bits call. The quick & dirty check might allow more than VRP_EQUIVALENCE_THRESHOLD bits through if they are tightly packed, but that is still imited to 64 for a host with 32 bit longs, 128 for a host with 64 bit longs. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added CC||amylaar at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097
[Bug tree-optimization/17506] [4.0/4.1/4.2 regression] warning about uninitialized variable points to wrong location
--- Comment #25 from amylaar at gcc dot gnu dot org 2006-08-24 20:04 --- Created an attachment (id=12131) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12131&action=view) This patch checks if the warning location is within cfun. I probably won't find CPU cycles to test this properly in the near future. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17506
[Bug other/25028] TImode-to-floating conversions broken
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2006-08-24 21:44 --- The testcase presented here appears to work as expected on Darwin when gcc trunk is built with Geoff Keating's proposed patch to add TImode support to Darwin... http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00581.html ...producing the correct results of "-1.00 -1.00". FYI. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25028
[Bug fortran/28005] [4.1 only] gfortran: matmul produces wrong result
--- Comment #9 from paulthomas2 at wanadoo dot fr 2006-08-24 21:40 --- Subject: Re: [4.1 only] gfortran: matmul produces wrong result Tobias, Seeing as it is you, I just put a first version on to cook; I simply copied everything below the line if (GFC_DESCRIPTOR_RANK (retarray) == 1) from 4.2 to 4.1. I have to admit to not having kept up to speed on the interface differences between the two, which is why I have been so long in getting around to it. In fact, I had half hoped that you would do it..! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28005
[Bug fortran/28005] [4.1 only] gfortran: matmul produces wrong result
--- Comment #8 from tobias dot burnus at physik dot fu-berlin dot de 2006-08-24 19:43 --- *ping* -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28005
[Bug tree-optimization/16876] [4.0/4.1/4.2 Regression] ICE on testcase with -O3 in fold-const
--- Comment #15 from amylaar at gcc dot gnu dot org 2006-08-24 19:13 --- Created an attachment (id=12130) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12130&action=view) patch I think this should do the trick. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16876
[Bug c/28838] LIB_SPECS lacks pthread
--- Comment #1 from mbanck at debian dot org 2006-08-24 19:12 --- Created an attachment (id=12129) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12129&action=view) gcc.libspec.diff Possible (untested) fix, not taking line lenghts into account. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28838
[Bug c/28838] New: LIB_SPECS lacks pthread
Passing -pthread while compiling a trivial program does not work: [EMAIL PROTECTED]:~$ gcc -pthreads test.c gcc: unrecognized option '-pthreads' Looking at bug 20705, it seems -pthread should be supported. -- Summary: LIB_SPECS lacks pthread Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mbanck at debian dot org GCC build triplet: i386-pc-gnu GCC host triplet: i386-pc-gnu GCC target triplet: i386-pc-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28838
[Bug middle-end/28753] [4.2 regression] ICE in extract_insn, at recog.c:2075 on powerpc
--- Comment #11 from dje at gcc dot gnu dot org 2006-08-24 18:19 --- Created an attachment (id=12128) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12128&action=view) allow immediate load into CRs Ulrich Weigand pointed out the instruction that is failing is a secondary reload already. Reload fundamentally does not check predicates, so that is a red herring. The bug is an omission in the movcc_internal1 pattern. The secondary reload is trying to load an immediate into a GPR, but the pattern does not provide any alternative for immediate constants. Although PPC CRs themselves generally cannot materialize an immediate constant, a GPR in CC mode loading a constant must be described by the pattern, which it was not. PPC CRs can materialize two constants easily: all zeros and all ones. The particular case in this bug is (const_int 0) and that will be more common, so I also added an alternative to materialize that directly without the secondary reload. -- dje at gcc dot gnu dot org changed: What|Removed |Added Attachment #12118|0 |1 is obsolete|| AssignedTo|unassigned at gcc dot gnu |dje at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28753
[Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #18 from ams at gnu dot org 2006-08-24 18:05 --- Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared > I'll try to get around it as soon as I can. Thanks. It has been a month... would be nice if you could look at it soon. Thanks for poking, I got stuck on a strange bug that causes make to assert while building the Java bits and I haven't gotten around to fixing it. I'll try and get around to atleast fixing this bug ASAP; which may take some time. :( Is there a hurry getting this in, I could try and reprioritise my tasks if it is urgent. Happy hacking, and thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
Re: [Bug target/28102] [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
> I'll try to get around it as soon as I can. Thanks. It has been a month... would be nice if you could look at it soon. Thanks for poking, I got stuck on a strange bug that causes make to assert while building the Java bits and I haven't gotten around to fixing it. I'll try and get around to atleast fixing this bug ASAP; which may take some time. :( Is there a hurry getting this in, I could try and reprioritise my tasks if it is urgent. Happy hacking, and thanks.
[Bug c++/28774] Request for warning where const/volatile is ignored in a cast
--- Comment #2 from simon_baldwin at yahoo dot com 2006-08-24 16:53 --- You didn't miss anything. There's no bug here, just a request for a new warning message. As you note, the const-volatile qualifications in the cast have no meaning, and are completely ignored by the compiler. While it's busy ignoring them, it could note this as a warning, in case the code author really meant something different. icc warns here; this PR aims to improve agreement in warnings between g++ and icc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28774
[Bug c++/28746] gcc -g and shared objects
--- Comment #7 from jmbnyc at gmail dot com 2006-08-24 16:47 --- Subject: Re: gcc -g and shared objects I finally updated my system today. I now have: [EMAIL PROTECTED] BUtil]$ uname -a Linux localhost.localdomain 2.6.17-1.2174_FC5smp #1 SMP Tue Aug 8 16:00:39 EDT 2006 i686 i686 i386 GNU/Linux I built the library (same as before) and this time all works as expected. During the update, I saw that both glibc and binutils were updated so somewhere in the system the problem was fixed. /JMB On 8/15/06, Jeffrey M. Birnbaum <[EMAIL PROTECTED]> wrote: > Ok, I will update the system when I have a chance. > > I had looked at the .s and I did not see anything unusual. > > What do you mean by "memory problems"? > /JMB > > On 16 Aug 2006 02:55:58 -, pinskia at gcc dot gnu dot org > <[EMAIL PROTECTED]> wrote: > > > > > > --- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-16 02:55 > > --- > > (In reply to comment #4) > > > Subject: Re: gcc -g and shared objects > > > > > > Just because it works for you does not mean it is not a problem. I am > > > not an idiot (and I am not saying that you implied that I was) and I > > > believe there is a problem. I believe the problem is not in ld, but in > > > the aspect of gcc that produces -g output. > > > > Use -save-temps and look at the output of the .s file, there is nothing > > unusual > > about it. Also binutils includes as which is what converts the .s file into > > the .o file. > > > > > Perhaps I have something > > > screwed up with my system, but it is an unpatched default install of > > > RH FC5. I tried a regular c file and it worked fine with -g. So, it is > > > something with C++ compilation using -g. > > > > And I am using a default install of FC5 too, though updated. Also so many > > other people use FC5 without this issue too. > > > > Anyways I think you should try to update FC5 and then if does not work, try > > seeing if you are having memory issues. > > > > > > -- > > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28746 > > > > --- You are receiving this mail because: --- > > You are on the CC list for the bug, or are watching someone who is. > > You reported the bug, or are watching the reporter. > > > > > -- > /JMB > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28746
[Bug c++/27714] [4.0/4.1/4.2 regression] operator new as friend in template class rejected
--- Comment #5 from jason at gcc dot gnu dot org 2006-08-24 16:35 --- . -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27714
[Bug c++/27714] [4.0/4.1/4.2 regression] operator new as friend in template class rejected
--- Comment #4 from jason at gcc dot gnu dot org 2006-08-24 16:35 --- Subject: Bug 27714 Author: jason Date: Thu Aug 24 16:35:03 2006 New Revision: 116381 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116381 Log: PR c++/27714 * pt.c (push_template_decl_real): A friend template with class scope isn't primary. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/friend46.C - copied unchanged from r116379, trunk/gcc/testsuite/g++.dg/template/friend46.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27714
[Bug c++/27714] [4.0/4.1/4.2 regression] operator new as friend in template class rejected
--- Comment #3 from jason at gcc dot gnu dot org 2006-08-24 16:34 --- Subject: Bug 27714 Author: jason Date: Thu Aug 24 16:34:46 2006 New Revision: 116380 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116380 Log: PR c++/27714 * pt.c (push_template_decl_real): A friend template with class scope isn't primary. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/friend46.C - copied unchanged from r116379, trunk/gcc/testsuite/g++.dg/template/friend46.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27714
[Bug target/28764] [4.2 Regression] libjava build failure on sh4
--- Comment #7 from amylaar at gcc dot gnu dot org 2006-08-24 16:22 --- (In reply to comment #0) Actually, I think this code: /* If this is an abnormal edge, we'll insert at the end of the previous block. */ if (eg->flags & EDGE_ABNORMAL) ... is just nonsense. It's not safe to insert at the end of the previous block, since it may be more than one successor. In fact, this is expected both for exception handling (where there is a fall-through path) as well as computed jumps (if there is only one successor, why compute it?) And when the other code to handle abnormal edges is fixed, we should not even try to insert a mode set on an abnormal edge, so the above code can be changed into gcc_assert (! (eg_flags & EDGE_ABNORMAL)) On possible optimization is to identify when there is no fall-through predecessor for the edge destination, and a means exists to redirect the abnormal edge (that should be possible in a simple exception handling scenario); in that case, the abnormal edge can be redirected to a newly created fall-through predecssor of the original successor block. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28764
[Bug c++/27714] [4.0/4.1/4.2 regression] operator new as friend in template class rejected
--- Comment #2 from jason at gcc dot gnu dot org 2006-08-24 15:54 --- Subject: Bug 27714 Author: jason Date: Thu Aug 24 15:54:39 2006 New Revision: 116379 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116379 Log: PR c++/27714 * pt.c (push_template_decl_real): A friend template with class scope isn't primary. Added: trunk/gcc/testsuite/g++.dg/template/friend46.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27714
[Bug debug/28834] [4.0/4.1/4.2 Regression] -O3 -g crashes sometimes when using may_alias and structs
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-24 15:50 --- Janis, Could you run a regression hunt on this bug? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug ada/28591] [4.2 regression] ICE in splice_child_die, at dwarf2out.c:5513
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-08-24 15:42 --- > I wonder if this is related to PR 28834 at all. The ICE stems from a new sanity check in the DWARF-2 back-end and we have fixed the problem in Gigi. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28591
[Bug testsuite/28837] New: need to prune "can't find atom for N_GSYM stabs" warnings on Darwin for -m64
Currently the ld64 on Darwin seems to create warnings of the form... can't find atom for N_GSYM stabs i:G(0,2) in /var/tmp//cc6KtMzX.o when compiling Fortran COMMON blocks at -m64 with the -g flag. These warnings incorrectly cause about 38 apparent fortran testsuite failures on Darwin. This problem can be suppressed until the issue causing the warnings (whose cause is currently unknown) is addressed. The following patch (sorry about the unified format) allows these warnings to be pruned and ignored during a -m64 make check. --- gcc-4.2-20060822/gcc/testsuite/lib/prune.exp.org2006-08-23 18:33:56.0 -0400 +++ gcc-4.2-20060822/gcc/testsuite/lib/prune.exp2006-08-23 18:41:28.0 -0400 @@ -43,6 +43,7 @@ regsub -all "(^|\n)\[^\n\]*file path prefix \[^\n\]* never used" $text "" text regsub -all "(^|\n)\[^\n\]*linker input file unused since linking not done" $text "" text +regsub -all "(^|\n)can't find atom for N_GSYM stabs \[^\n\]* in \[^\n\]*" $text "" text #send_user "After:$text\n" return $text With this patch in place the fortran testsuite failures for -m64 are identical to those for -m32 with three unexpected passes. This patch will help remove the "noise" off of the Darwin -m64 test results. -- Summary: need to prune "can't find atom for N_GSYM stabs" warnings on Darwin for -m64 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: powerpc-apple-darwin8 GCC host triplet: powerpc-apple-darwin8 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28837
[Bug target/28764] [4.2 Regression] libjava build failure on sh4
--- Comment #6 from amylaar at gcc dot gnu dot org 2006-08-24 15:32 ---
(In reply to comment #5)
> > I think the only sane way to handle this is not to emit any mode
> > switching code for exception edges at the potential trapping site,
> > and make the exception handling code assume no particular mode is
> > present (unless the compiler can prove that an exception handler can only
> > be reached from throwing/trapping sites that all have the same mode).
>
> Although the mode switching code beyonds me,
I don't think the MODE_AFTER hack works - it fails to affect transparency
and anticipatability.
> how does the exception
> handling code have no particular mode at its start?
Actually, this code seems to attempt to do that already:
/* Pretend the mode is clobbered across abnormal edges. */
{
edge_iterator ei;
edge e;
FOR_EACH_EDGE (e, ei, bb->preds)
if (e->flags & EDGE_COMPLEX)
break;
if (e)
RESET_BIT (transp[bb->index], j);
}
However, this is not safe in case BB has a locally anticipatable mode.
In addition to the REST_BIT invocation, it needs:
ptr = new_seginfo (no_mode, insn, bb->index, live_now);
add_seginfo (info + bb->index, ptr);
so that we won't show an anticipatable mode.
> By calling make_preds_opaque for the corresponding BB and set
> no_mode to seginfo->mode?
No, although calling make_preds_opaque on the successor block should work,
that would be a gross pessimization.
make_preds_opaque is called when we effetively move a mode set upwards
in the flowgraph to one or more 'earliest' locations, and thus the mode
information in the mode-switchable entity becomes live on all the paths
upwards from the use of the mode to the sets of the required mode. Thus,
we know that we may not switch the mode-switchable entity to any other
mode on these paths.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28764
[Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
--- Comment #13 from hosking at cs dot purdue dot edu 2006-08-24 15:27
---
Is this enough?
Here is the dump output, followed by stack traces at the resize and remove
points (the remove goes on to fail). The edge being split is:
(gdb) p *e
$9 = {
src = 0x425cc8d0,
dest = 0x425cc8a0,
insns = {
r = 0x425ccc90,
t = 0x425ccc90
},
aux = 0x424a1270,
goto_locus = 0x0,
flags = 0,
probability = 0,
count = 0,
dest_idx = 565824
}
Its src is:
(gdb) p *(e->src)
$12 = {
stmt_list = 0x425cd7e0,
preds = 0x425bd7e0,
succs = 0x0,
aux = 0x0,
loop_father = 0x0,
dom = {0x1, 0x2710},
prev_bb = 0x0,
next_bb = 0x0,
il = {
rtl = 0x2
},
phi_nodes = 0x0,
predictions = 0x0,
count = 4781934674863446560,
index = 0,
loop_depth = 0,
frequency = 0,
flags = 1
}
Its dest is:
(gdb) p *(e->dest)
$13 = {
stmt_list = 0x425cd780,
preds = 0x425bd7e0,
succs = 0x0,
aux = 0x0,
loop_father = 0x0,
dom = {0x1, 0x2710},
prev_bb = 0x0,
next_bb = 0x0,
il = {
rtl = 0x3
},
phi_nodes = 0x0,
predictions = 0x0,
count = 4781934262546585568,
index = 0,
loop_depth = 0,
frequency = 0,
flags = 1
}
Here is the dump:
;; Function TrestleGoo__PutProp (TrestleGoo__PutProp)
TrestleGoo__PutProp (M3_BFdKo9_vv, M3_Af40ku_ref)
{
* M3_BFdKo9_v;
word_32 M3_Cwb5VA_tc;
* M3_BhAG13_p;
* M3_BhAG13_e;
struct
{
} L_2;
* D.403;
* D.406;
* D.407;
* D.419;
(*) ( *) D.506;
* D.505;
* * D.504;
* D.503;
* D.502;
* * L_2.3;
D.500;
D.499;
word_32 D.498;
word_32 D.497;
word_32 D.496;
int_32 D.495;
int_32 * D.494;
* D.493;
* * D.492;
* * D.491;
D.490;
word_32 D.489;
word_32 D.488;
int_32 M3_Cwb5VA_tc.2;
D.486;
D.485;
word_32 D.484;
word_32 D.483;
word_32 D.482;
int_32 D.481;
int_32 * D.480;
* D.479;
* * D.478;
* D.477;
D.476;
D.475;
word_32 D.474;
word_32 D.473;
word_32 D.472;
int_32 D.471;
int_32 * D.470;
* D.469;
* * M3_BhAG13_e.1;
* * D.467;
* * D.466;
* D.465;
* D.464;
* D.463;
* * D.462;
* D.461;
int_32 D.460;
* D.459;
int_32 D.458;
int_32 * D.457;
* D.456;
int_32 D.455;
word_32 D.454;
word_32 D.453;
word_32 D.452;
int_32 D.451;
int_32 * D.450;
* D.449;
* D.448;
int_32 * D.447;
* D.446;
(*) ( *) D.445;
* D.444;
* * D.443;
* D.442;
* * D.441;
* D.440;
* * D.439;
* D.438;
D.437;
D.436;
word_32 D.435;
word_32 D.434;
word_32 D.433;
int_32 D.432;
int_32 * D.431;
* D.430;
* D.429;
* * D.428;
* D.427;
# BLOCK 0 freq:1000
# PRED: ENTRY [100.0%] (fallthru,exec)
D.427_4 = &MM_TrestleGoo + 52;
D.428_5 = ( * *) D.427_4;
# VUSE ;
D.429_6 = *D.428_5;
if (D.429_6 == 0B) goto ; else goto ;
# SUCC: 43 [19.0%] (true,exec) 1 [81.0%] (false,exec)
# BLOCK 43 freq:190
# PRED: 0 [19.0%] (true,exec)
:;
goto ();
# SUCC: 3 [100.0%] (fallthru)
# BLOCK 1 freq:810
# PRED: 0 [81.0%] (false,exec)
:;
D.430_166 = D.429_6 + ;
D.431_167 = (int_32 *) D.430_166;
# VUSE ;
# VUSE ;
D.432_168 = *D.431_167;
D.433_169 = (word_32) D.432_168;
D.434_170 = D.433_169 << 22;
D.435_171 = D.434_170 >> 31;
if (D.435_171 == 0) goto ; else goto ;
# SUCC: 44 [70.0%] (true,exec) 2 [30.0%] (false,exec)
# BLOCK 44 freq:567
# PRED: 1 [70.0%] (true,exec)
:;
goto ();
# SUCC: 3 [100.0%] (fallthru)
# BLOCK 2 freq:243
# PRED: 1 [30.0%] (false,exec)
:;
# MM_TrestleGoo_239 = V_MAY_DEF ;
# L_2_240 = V_MAY_DEF ;
RTHooks__CheckLoadTracedRef (D.429_6);
# SUCC: 3 [100.0%] (fallthru,exec)
# BLOCK 3 freq:1000
# PRED: 43 [100.0%] (fallthru) 44 [100.0%] (fallthru) 2 [100.0%]
(fallthru,exec)
# L_2_187 = PHI ;
# MM_TrestleGoo_177 = PHI ;
:;
D.438_7 = &L_2 + 8;
D.439_8 = ( * *) D.438_7;
# VUSE ;
D.440_11 = *D.428_5;
# L_2_199 = V_MAY_DEF ;
*D.439_8 = D.440_11;
D.441_15 = ( * *) D.440_11;
# VUSE ;
# VUSE ;
D.442_16 = *D.441_15;
D.443_17 = ( * *) D.442_16;
# VUSE ;
# VUSE ;
D.444_18 = *D.443_17;
D.445_19 = ( (*) ( *)) D.444_18;
# MM_TrestleGoo_200 = V_MAY_DEF ;
# L_2_201 = V_MAY_DEF ;
D.445_19 (D.440_11);
# SUCC: 4 [100.0%] (fallthru,exec)
# BLOCK 4 freq:1000
# PRED: 3 [100.0%] (fallthru,exec)
:;
D.446_23 = &L_2 + 4;
D.447_24 = (int_32 *) D.446_23;
# L_2_202 = V_MAY_DEF ;
*D.447_24 = 6;
# MM_TrestleGoo_203 = V_MAY_DEF ;
# L_2_204 = V_MAY_DEF ;
RTHooks__PushEFrame (&L_2);
# SUCC: 5 [100.0%] (fallthru,exec)
# BLOCK 5 freq:1000
# PRED: 4 [100.0%] (fallthru,exec)
# MM_TrestleGoo_205 = V_MAY_DEF ;
# L_2_206 = V_MAY_DEF ;
D.403_26 = TrestleGoo__TrueChild (M3_BFdKo9_vv_25);
# SUCC: 6 [100.0%] (fallthru,exec)
# BLOCK 6 freq:1000
# PRED: 5 [100.0%] (fallthru,exec)
if (M3_Af40ku_ref_29 == 0B) goto ; else goto ;
# SUCC: 45 [19.0%] (true,exec) 7
[Bug tree-optimization/28807] [4.2 Regression] wrong code with may_alias and structs
--- Comment #8 from patchapp at dberlin dot org 2006-08-24 15:18 --- Subject: Bug number PR 28807 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00878.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28807
[Bug tree-optimization/28807] [4.2 Regression] wrong code with may_alias and structs
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-24 15:16 --- Mine, all mine. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||08/msg00878.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2006-08-24 15:16:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28807
[Bug c++/28836] gcc 4.1.1 rejects possible valid code containing the "using" keyword
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-24 14:57 --- 4.0.x was incorrect in accepting this code in the first place. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28836
[Bug c++/28836] New: gcc 4.1.1 rejects possible valid code containing the "using" keyword
A third-party library I'm using doesn't compile with gcc 4.1.1 anymore (it
still did with 4.0). The problem is that some header files contain a code
fragment (I've stripped it down) like this:
#include
using namespace std;
template class I {
public:
int size;
};
template class D : private I {
using D< T >::size;
};
int main() {
D test;
cout << "Hello world" << endl;
}
gcc 4.1.1 generates the following error:
test.cpp: In instantiation of 'D':
test.cpp:15: instantiated from here
test.cpp:11: error: type 'D' is not a base type for type 'D'
gcc 4.0 doesn't see any problem.
I'm not sure this kind of construct is valid. If "using D< T >::size;" is
replaced by "using I< T, double >::size;" gcc 4.1.1 is happy again.
My system is Mac OS X 10.4.7 (PowerPC).
gcc was compiled with darwinports:
"Using built-in specs.
Target: powerpc-apple-darwin8.7.0
Configured with: ../gcc-4.1.1/configure --prefix=/opt/local
--enable-languages=c,c++,java,objc,obj-c++,fortran
--libdir=/opt/local/lib/gcc41 --includedir=/opt/local/include/gcc41
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-dp-4.1 --with-gxx-include-dir=/opt/local/include/gcc41/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local --with-as=/opt/local/bin/odas
--with-ld=/opt/local/bin/odld --with-ar=/opt/local/bin/odar --disable-multilib
Thread model: posix
gcc version 4.1.1
"
The command used to compile was simply "g++ test.cpp"
The library that contains the code fragments is EO (Evolutionary algorithms,
http://www2.lifl.fr/~cahon/paradisEO/eo/index.html)
Thx,
Werner Van Geit
--
Summary: gcc 4.1.1 rejects possible valid code containing the
"using" keyword
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wernervangeit at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28836
[Bug tree-optimization/15452] [tree-ssa] Optimize cascaded a = a == 0;
--- Comment #7 from dberlin at gcc dot gnu dot org 2006-08-24 14:43 ---
Subject: Re: [tree-ssa] Optimize cascaded a
= a == 0;
pinskia at gcc dot gnu dot org wrote:
> --- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-24 04:27
> ---
> Another interesting case would be (but which could be handled by VRP):
> int
> foo (int a)
> {
> a = a!=0;
> a = a!=0;
> a = a!=0;
> a = a!=0;
> a = a!=0;
> return a;
> }
> Which should be optimized to:
> int foo(int a) { return a!=0;}
>
>
Uh, FRE could also optimize this to the same thing, I just don't
remember whether it bothers to look at conditionals as eliminable
expressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15452
Re: [Bug tree-optimization/15452] [tree-ssa] Optimize cascaded a = a == 0;
pinskia at gcc dot gnu dot org wrote:
> --- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-24 04:27
> ---
> Another interesting case would be (but which could be handled by VRP):
> int
> foo (int a)
> {
> a = a!=0;
> a = a!=0;
> a = a!=0;
> a = a!=0;
> a = a!=0;
> return a;
> }
> Which should be optimized to:
> int foo(int a) { return a!=0;}
>
>
Uh, FRE could also optimize this to the same thing, I just don't
remember whether it bothers to look at conditionals as eliminable
expressions.
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-08-24 13:41 --- See also the target specific fix http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00873.html and the middle-end fix http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00874.html (as this is not a regression this may have to wait for 4.3 or 4.2.1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug debug/26881] [4.1/4.2 Regression] internal compiler error in dwarf2out_finish
--- Comment #19 from hubicka at gcc dot gnu dot org 2006-08-24 13:30 --- Subject: Bug 26881 Author: hubicka Date: Thu Aug 24 13:30:45 2006 New Revision: 116374 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116374 Log: PR debug/26881 * cgraph.c: Fix comments. (cgraph_varpool_mark_needed_node): Mark only variables not already output to file. * cgraphunit.c: Update comments; include gt-cgraphunit.h (cgraph_varpool_assembled_nodes_queue): New static variable. (cgraph_varpool_assemble_decl): Record output decls for debug out code. (cgraph_varpool_output_debug_info): New function. (cgraph_finalize_compilation_unit, cgraph_optimize): Call it. * Makefile.in: Add gt-cgraphunit.h * gcc.dg/debug/pr26881.c: New file. Added: trunk/gcc/testsuite/gcc.dg/debug/pr26881.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/cgraph.c trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26881
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-08-24 13:17 --- Created an attachment (id=12127) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12127&action=view) patch I'm going to improve the situation by following the principle of least surprise and not relying on the undefinedness -ffinite-math-only produces. I appreciate help with testcases that verify invariants in either mode though (the attached patch does not have those). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-08-24 13:03 --- One problem is that in fold-const.c we use HONOR_XXX macros, while in builtins.c folding we use MODE_HAS_XXX. HONOR_XXX changes with -ffinite-math-only and friends, while MODE_HAS_XXX not (of course). So to make behavior consistent, we need to switch either use to the other scheme. Meanwhile I also spotted case BUILT_IN_FINITE: if (!MODE_HAS_NANS (TYPE_MODE (TREE_TYPE (arg))) && !MODE_HAS_INFINITIES (TYPE_MODE (TREE_TYPE (arg return omit_one_operand (type, integer_zero_node, arg); which needs to read integer_one_node as result. Fortunately modes with no nans don't come along here that often. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug ada/28835] Incorrect numeric result in multiplication of user-defined type with universal integer
--- Comment #1 from S dot Sangwine at IEEE dot org 2006-08-24 11:39 --- Created an attachment (id=12126) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12126&action=view) Stand-alone Ada main program that demonstrates the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28835
[Bug ada/28835] New: Incorrect numeric result in multiplication of user-defined type with universal integer
Multiplication of a variable of a user-defined integer type with range 0 .. 2 by an integer literal causes incorrect result in the case when the variable has value 2. A negative result is given even though the variable and literal are positive. Found this error with Gnat 3.4.6 (AdaCore Libre version, 2006), but reproduced the same problem with the latest development code (4.2.0). The problem is demonstrated by the short stand-alone program code provided with this report. Compiler configuration details (but see also above about 3.4.6): Configured with: /Users/drew/Developer/Compiler/gcc-head/configure --prefix=/usr/local/ada-4.2 --disable-libssp --disable-libgomp --enable-languages=c,ada -- Summary: Incorrect numeric result in multiplication of user- defined type with universal integer Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: S dot Sangwine at IEEE dot org GCC build triplet: gcc version 4.2.0 20060429 (experimental) GCC host triplet: powerpc-apple-darwin8.6.0 GCC target triplet: powerpc-apple-darwin8.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28835
[Bug ada/28591] [4.2 regression] ICE in splice_child_die, at dwarf2out.c:5513
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-24 11:16 --- I wonder if this is related to PR 28834 at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28591
[Bug middle-end/28831] [4.0/4.1/4.2 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-24 11:12 --- This is going to be hard to fix really, unless we make explicate the target's behavior for passing structs (via value or by reference). Right now we get: D.1992 = f () [return slot optimization]; g (D.1992) [tail call]; Which looks ok if we are passing via value but since we need to pass by reference, the middle-end thinks we need a new stack space for it because it does not know that D.1992 is not used after the call to g. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end GCC target triplet|i386-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28831
[Bug debug/28834] [4.0/4.1/4.2 Regression] -O3 -g crashes sometimes when using may_alias and structs
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-24 11:06 --- This worked in 3.4.0 so this is a regression. Note this is the testcase for 28807 which I was using for testing so the testcase might be added to the testsuite by the time someone gets around to looking into the bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.0.0 4.1.0 4.2.0 Known to work||3.4.0 Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug debug/28834] New: [4.0/4.1/4.2 Regression] -O3 -g crashes sometimes when using may_alias and structs
Testcase that crashes at -O3 -g:
struct S { short x; };
typedef struct S __attribute__((__may_alias__)) test;
int f() {
int a=10;
test *p=(test *)&a;
p->x = 1;
return a;
}
int main() {
if (f() == 10)
__builtin_abort();
return 0;
}
-
mayalias-2.c:2: internal compiler error: in splice_child_die, at
dwarf2out.c:5513
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: [4.0/4.1/4.2 Regression] -O3 -g crashes sometimes when
using may_alias and structs
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug target/28833] GCC 4.1.1 ICEs compiling Xorg 6.8.2
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-24 10:55 --- Fixed in 4.1.2. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||ice-on-valid-code Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28833
[Bug middle-end/28776] [4.2 Regression] dwarf2out.c:2160: ICE: in build_polynomial_chrec, at tree-chrec.h:108
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-08-24 10:39 --- *** Bug 28815 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||happyarch at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28776
[Bug middle-end/28815] gcc-4.2-20060819 failed to compile Linux kernel 2.6.18-rc4-git1
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-08-24 10:39 --- *** This bug has been marked as a duplicate of 28776 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28815
[Bug c/28833] GCC 4.1.1 ICEs compiling Xorg 6.8.2
--- Comment #1 from peter at empeg dot com 2006-08-24 10:37 --- Created an attachment (id=12124) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12124&action=view) gzipped preprocessed source of testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28833
[Bug c/28833] New: GCC 4.1.1 ICEs compiling Xorg 6.8.2
Attached (gzipped) fbmmx.i (from Xorg 6.8.2 xc/programs/Xserver/fb/fbmmx.c) gives "fbmmx.c:871: internal compiler error: in push_reload, at reload.c:1303" when compiled with 4.1.1 on i686-linux-gnu. This is probably a regression as I've previously compiled the same Xorg release fine with 4.1.0. GCC also emits lots of warnings, but no errors. --- GCC version [EMAIL PROTECTED] fb]$ gcc --version gcc (GCC) 4.1.1 --- GCC configured with ../g*/configure --prefix=/usr --enable-shared --enable-languages=c,c++,java --enable-threads --enable-__cxa_atexit --with-system-zlib --disable-multilib --- GCC command to trigger failure gcc -m32 -c -O2 -O9 -march=pentium4 -mtune=pentium4 -mmmx -msse -msse2 -pipe -ansi -pedantic -Wall -Wpointer-arith -Wundef-fno-merge-constants -c -mmmx -Winline --param inline-unit-growth=1 --param large-function-growth=1 fbmmx.i --- GCC output fbmmx.c:39: warning: specifying vector types with __attribute__ ((mode)) is depr ecated fbmmx.c:39: warning: use __attribute__ ((vector_size)) instead fbmmx.c:40: warning: specifying vector types with __attribute__ ((mode)) is depr ecated fbmmx.c:40: warning: use __attribute__ ((vector_size)) instead fbmmx.c:41: warning: specifying vector types with __attribute__ ((mode)) is depr ecated fbmmx.c:41: warning: use __attribute__ ((vector_size)) instead fbmmx.c:43: warning: ISO C90 does not support ?long long? fbmmx.c:79: warning: ISO C90 forbids specifying subobject to initialize fbmmx.c:80: warning: ISO C90 forbids specifying subobject to initialize fbmmx.c:81: warning: ISO C90 forbids specifying subobject to initialize fbmmx.c:82: warning: ISO C90 forbids specifying subobject to initialize fbmmx.c:83: warning: ISO C90 forbids specifying subobject to initialize fbmmx.c:84: warning: ISO C90 forbids specifying subobject to initialize fbmmx.c:85: warning: ISO C90 forbids specifying subobject to initialize fbmmx.c:86: warning: ISO C90 forbids specifying subobject to initialize fbmmx.c:87: warning: ISO C90 forbids specifying subobject to initialize fbmmx.c:88: warning: ISO C90 forbids specifying subobject to initialize fbmmx.c:89: warning: ISO C90 forbids specifying subobject to initialize fbmmx.c:90: warning: ISO C90 forbids specifying subobject to initialize fbmmx.c:91: warning: ISO C90 forbids specifying subobject to initialize fbmmx.c:92: warning: ISO C90 forbids specifying subobject to initialize fbmmx.c:93: warning: ISO C90 forbids specifying subobject to initialize fbmmx.c:94: warning: ISO C90 forbids specifying subobject to initialize fbmmx.c: In function ?expand565?: fbmmx.c:306: warning: ISO C90 forbids mixed declarations and code fbmmx.c: In function ?fbCompositeSolidMask_nx8xmmx?: fbmmx.c:658: warning: ISO C90 does not support ?long long? fbmmx.c:701: warning: ISO C90 does not support ?long long? fbmmx.c: In function ?fbCompositeSolidMask_nx8x0565mmx?: fbmmx.c:764: warning: ISO C90 does not support ?long long? fbmmx.c:824: warning: ISO C90 does not support ?long long? fbmmx.c:871: internal compiler error: in push_reload, at reload.c:1303 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: GCC 4.1.1 ICEs compiling Xorg 6.8.2 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: peter at empeg dot com 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=28833
[Bug c++/28820] sizeof == 0 for empty class
--- Comment #4 from jz201115 at zodiac dot mimuw dot edu dot pl 2006-08-24 10:22 --- Andrew, So do you want to say this is not a bug? I know the class isn't intersting but I think it shouldn't have size equal to 0. Thanks, Janek -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28820
