[Bug tree-optimization/28798] New: remove_phi_node attempts removal of a phi node resized by resize_phi_node
If a phi node has been resized using resize_phi_node, it may later be attempted
to be removed by remove_dead_inserted_code using remove_phi_node, as the old
phi node will be present in inserted_exprs, yet the phi node will not be in the
chain of phi nodes for its original basic block.
I believe the fix is to make remove_phi_node bail out if the phi node is not
present in the list of phi nodes for its basic block:
void
remove_phi_node (tree phi, tree prev)
{
tree *loc;
if (prev)
{
loc = PHI_CHAIN (prev);
}
else
{
for (loc = (bb_for_stmt (phi)-phi_nodes);
loc *loc != phi;
loc = PHI_CHAIN (*loc))
;
}
if (!loc) return;
/* Remove PHI from the chain. */
*loc = PHI_CHAIN (phi);
/* If we are deleting the PHI node, then we should release the
SSA_NAME node so that it can be reused. */
release_phi_node (phi);
release_ssa_name (PHI_RESULT (phi));
}
--
Summary: remove_phi_node attempts removal of a phi node resized
by resize_phi_node
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hosking at cs dot purdue dot edu
GCC build triplet: i386-apple-darwin8.7.1
GCC host triplet: i386-apple-darwin8.7.1
GCC target triplet: i386-apple-darwin8.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28798
[Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-22 06:10 --- What are you trying to do? It seems like you are using the API wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28798
[Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-22 06:17 --- We should never had needed resize_phi_node inside PRE and resize_phi_node also does an exact replacement so that means you are keeping a reference to the old PHI node when adding an edge which is wrong. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28798
[Bug middle-end/28776] [4.2 Regression] dwarf2out.c:2160: ICE: in build_polynomial_chrec, at tree-chrec.h:108
--- Comment #11 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-08-22 08:05 --- Subject: Re: [4.2 Regression] dwarf2out.c:2160: ICE: in build_polynomial_chrec, at tree-chrec.h:108 The fix seems OK to me, could you please test and submit it? The following fixes it: Index: tree-scalar-evolution.c === *** tree-scalar-evolution.c (revision 116257) --- tree-scalar-evolution.c (working copy) *** fold_used_pointer (tree expr) *** 1847,1852 --- 1847,1854 if (new0 == op0 new1 == op1) return expr; + new0 = chrec_convert (TREE_TYPE (expr), new0, NULL_TREE); + new1 = chrec_convert (TREE_TYPE (expr), new1, NULL_TREE); if (code == PLUS_EXPR) expr = chrec_fold_plus (TREE_TYPE (expr), new0, new1); else -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28776
[Bug tree-optimization/28794] missed optimization with non-COND_EXPR and vrp and comparisions
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-08-22 08:10 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-22 08:10:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28794
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-08-22 08:26 --- I confirm there are problems in the i386/x86_64 backends and possibly the middle-end expanders. And I appreciate testcases that show wrong or inconsistent behavior (even more so if citing the relevant standards and parts of gcc documentation). And I'm going to take these bugs (if they're middle-end or x86 specific) and fix them. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug fortran/28799] New: functions and allocated vectors
Hello, I have a problem with functions wich have the same allocated vector in input and output. Program test (see below) returns a segmentation fault when it is compiled by gfortran, but works with intel compiler. The problem is that gfortran does not use a temporary vector and try to write directly on the input vector. Thank you for your help. program test implicit none double precision, dimension(:), allocatable::a integer::n print*,'entrez n' read*,n allocate(a(n)) a(:)=1d0 a=equal(a) print*,a=,a deallocate(a) contains function equal(v) result(u) double precision, intent(in),dimension(:)::v double precision, dimension(size(v))::u u=v end function equal end program test -- Summary: functions and allocated vectors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: delphine dot jennequin at cea dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28799
[Bug c++/28659] [4.2 regression] ICE (segfault) while compiling kdelibs 4.0 snapshot
--- Comment #9 from mueller at gcc dot gnu dot org 2006-08-22 09:19 --- Thanks Jason! I'll regtest immediately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
[Bug c/28800] New: Incorrect warning ISO C forbids an empty source file
I get the following warning: dixsept:~ cat tst.c #define FOO dixsept:~ gcc -pedantic -c tst.c tst.c:1: warning: ISO C forbids an empty source file But the source isn't empty (and AFAIK, the ISO C doesn't forbid empty sources). Perhaps gcc mixes up with a translation unit, in which case the wording should be changed. -- Summary: Incorrect warning ISO C forbids an empty source file Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vincent at vinc17 dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28800
[Bug c/28800] Incorrect warning ISO C forbids an empty source file
--- Comment #1 from falk at debian dot org 2006-08-22 10:16 --- Correct, the warning should say ISO C forbids an empty translation unit. -- falk at debian dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28800
[Bug middle-end/28776] [4.2 Regression] dwarf2out.c:2160: ICE: in build_polynomial_chrec, at tree-chrec.h:108
--- Comment #12 from patchapp at dberlin dot org 2006-08-22 11:45 --- Subject: Bug number PR28776 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/msg00779.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28776
[Bug fortran/28799] functions and allocated vectors
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-22 11:51 --- What version of gfortran are you using? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28799
[Bug fortran/28799] functions and allocated vectors
--- Comment #2 from delphine dot jennequin at cea dot fr 2006-08-22 12:05 --- Subject: Re: functions and allocated vectors pinskia at gcc dot gnu dot org a écrit : --- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-22 11:51 --- What version of gfortran are you using? I use GCC 4.0.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28799
[Bug fortran/28799] functions and allocated vectors
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-22 12:12 --- All fixed in 4.1.0: D.609 = NON_LVALUE_EXPR D.607 + 1; D.610 = _gfortran_internal_malloc (D.609 * 8); atmp.11.data = D.610; atmp.11.offset = 0; atmp.11.dim[0].stride = 0; equal (atmp.11, D.600); -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28799
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #101 from bkoz at gcc dot gnu dot org 2006-08-22 12:44 --- Fixed. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
Re: [Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
pinskia at gcc dot gnu dot org wrote: --- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-22 06:17 --- We should never had needed resize_phi_node inside PRE and resize_phi_node also does an exact replacement so that means you are keeping a reference to the old PHI node when adding an edge which is wrong. PRE never directly calls resize_phi_node The insert_on_edge call PRE makes should *never* cause the number of predecessors to change, so i can't see why resize_phi_node would ever be called. Without an example case where it does, i can't debug this further. However, it's not wrong to keep a reference to a phi node when a random edge in the program changes. The API that doesn't allow such a thing is just broken. This is a symptom of the fact that our phi node arguments are stored in pretend vectors, even though it would be saner to use an embedded vec in that structure. This would allow reallocating arguments without having to change the entire phi node structure.
[Bug tree-optimization/28798] remove_phi_node attempts removal of a phi node resized by resize_phi_node
--- Comment #3 from dberlin at gcc dot gnu dot org 2006-08-22 12:47 --- Subject: Re: remove_phi_node attempts removal of a phi node resized by resize_phi_node pinskia at gcc dot gnu dot org wrote: --- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-22 06:17 --- We should never had needed resize_phi_node inside PRE and resize_phi_node also does an exact replacement so that means you are keeping a reference to the old PHI node when adding an edge which is wrong. PRE never directly calls resize_phi_node The insert_on_edge call PRE makes should *never* cause the number of predecessors to change, so i can't see why resize_phi_node would ever be called. Without an example case where it does, i can't debug this further. However, it's not wrong to keep a reference to a phi node when a random edge in the program changes. The API that doesn't allow such a thing is just broken. This is a symptom of the fact that our phi node arguments are stored in pretend vectors, even though it would be saner to use an embedded vec in that structure. This would allow reallocating arguments without having to change the entire phi node structure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28798
[Bug java/28801] New: libgcj build broken for gnu/CORBA/CDR/gnuRuntime.java
Current svn trunk gives: /home/mark/src/gcc-obj/gcc/gcj -B/home/mark/src/gcc-obj/i686-pc-linux-gnu/libjava/ -B/home/mark/src/gcc-obj/gcc/ -ffloat-store -fomit-frame-pointer -fclasspath= -fbootclasspath=/home/mark/src/gcc-obj/i686-pc-linux-gnu/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -fjni -findirect-dispatch -fno-indirect-classes -c @gnu-CORBA.list -fPIC -o .libs/gnu-CORBA.o gnu/CORBA/CDR/gnuRuntime.java: In class 'gnu.CORBA.CDR.gnuRuntime$Redirection': gnu/CORBA/CDR/gnuRuntime.java: In method 'gnu.CORBA.CDR.gnuRuntime$Redirection.toString()': gnu/CORBA/CDR/gnuRuntime.java:95: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [gnu-CORBA.lo] Error 1 The same can be seen on the builder.classpath.org: http://lists.gnu.org/archive/html/classpath-testresults/2006-08/msg00126.html This doesn't happen on x86_64-unknown-linux-gnu. -- Summary: libgcj build broken for gnu/CORBA/CDR/gnuRuntime.java Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mark at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28801
[Bug tree-optimization/28802] New: Operations on data in dynamically allocated structure can't get vectorized
This should get vectorized but isn't:
#include stdlib.h
typedef struct
{
int data[256];
} S;
void f()
{
S* restrict a = (S*) malloc( sizeof(S) );
S* restrict b = (S*) malloc( sizeof(S) );
for ( int i = 0; i 256; ++i ) {
b-data[i] += a-data[i];
}
}
--
Summary: Operations on data in dynamically allocated structure
can't get vectorized
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nomis80 at nomis80 dot org
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=28802
[Bug tree-optimization/28802] Operations on data in dynamically allocated structure can't get vectorized
--- Comment #1 from nomis80 at nomis80 dot org 2006-08-22 13:12 --- Created an attachment (id=12112) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12112action=view) Tree dump Command-line: gcc -std=c99 -O3 -march=pentium4 -ftree-vectorize -ftree-vectorizer-verbose=7 -fdump-tree-vect -c test_vect.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28802
[Bug target/28803] New: No SSE inline expansion for lrint
C99 lrint is not expanded to SSE cvts[sd]2[sd]i{q}.
--
Summary: No SSE inline expansion for lrint
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: x86_64-*-*, i?86-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28803
[Bug target/28803] No SSE inline expansion for lrint
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-08-22 13:28 --- Mine. Patch posted. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||28177 nThis|| AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||08/msg00783.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-22 13:28:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28803
[Bug java/28801] libgcj build broken for gnu/CORBA/CDR/gnuRuntime.java
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-08-22 13:56 --- Confirmed. Happens on x86_64-unknown-linux-gnu, too: gnu/CORBA/CDR/AbstractCdrOutput.java:112: internal compiler error: Segmentation fault -- rguenth 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-08-22 13:56:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28801
[Bug tree-optimization/28003] [4.2 Regression] optimizer bug
--- Comment #12 from dberlin at gcc dot gnu dot org 2006-08-22 14:04 --- Subject: Bug 28003 Author: dberlin Date: Tue Aug 22 14:04:16 2006 New Revision: 116323 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116323 Log: 2006-08-22 Daniel Berlin [EMAIL PROTECTED] PR tree-optimization/28003 * tree-ssa-alias.c (compute_may_aliases): Compute call clobbered before grouping aliases. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr28003.C Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28003
[Bug tree-optimization/28003] [4.2 Regression] optimizer bug
--- Comment #13 from dberlin at gcc dot gnu dot org 2006-08-22 14:05 --- Fixed -- dberlin at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dberlin at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28003
[Bug tree-optimization/28003] [4.2 Regression] optimizer bug
--- Comment #14 from dberlin at gcc dot gnu dot org 2006-08-22 14:05 --- Fixed -- dberlin at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28003
[Bug libstdc++/24660] versioning weak symbols in libstdc++
--- Comment #31 from bkoz at gcc dot gnu dot org 2006-08-22 14:05 --- This experiment is deemed sucessful. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
[Bug rtl-optimization/17810] [3.4 Regression] internal compiler error: in verify_local_live_at_start for arm-rtems, arm-linux
--- Comment #10 from hvreddy1110 at gmail dot com 2006-08-22 14:28 --- Hi, I used and Xfree86-4.4 and 4.5 with gcc-3.4.3 But both the time it is giving same problem as slicer.cc: In function `void triangulateRect(Arc*, Backend, int, int, int)': slicer.cc:382: internal compiler error: in verify_local_live_at_start, at flow.c:546 What could be the problem. Thanks Regards, Harsha (In reply to comment #5) http://sources.redhat.com/ml/crossgcc/2005-05/msg00154.html is a report of a similar problem with gcc-3.4.3. xfree86-4.5.0's fontutils.c causes an ICE when compiled with -O3 -fno-strict-aliasing. Backing down to xfree86-4.4.0, or using -O2, or not using -no-strict-aliasing, or using gcc-4.0.0, makes the problem go away. I'll attach a reduced testcase. To reproduce, do $ arm-unknown-linux-gnu-gcc -O3 -fno-strict-aliasing -c fontutils.i Error is fontutils.i:44: internal compiler error: in verify_local_live_at_start, at flow.c:546 Is this the same problem, or should I file a new report? -- hvreddy1110 at gmail dot com changed: What|Removed |Added CC||hvreddy1110 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17810
[Bug c/28805] New: Xfree86-4.4 and 4.5 X compile failed with gcc-3.4.3
HI, I tryed to cross compile Xfree86-4.4 and 4.5 with my cross tool built with gcc-3.4.3 But in both the cases it is giving error as slicer.cc: In function `void triangulateRect(Arc*, Backend, int, int, int)': slicer.cc:382: internal compiler error: in verify_local_live_at_start, at flow.c:546 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [slicer.o] Error 1 What could be the reason? Thanks and Regards, Harsha -- Summary: Xfree86-4.4 and 4.5 X compile failed with gcc-3.4.3 Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hvreddy1110 at gmail dot com GCC build triplet: i386 GCC host triplet: i386 GCC target triplet: IMX31/ARM11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28805
[Bug target/28806] New: lround is not expanded inline to SSE conversion sequence
The C99 lround function should be expanded inline to (long)(x + copysign (0.5, x)) -- Summary: lround is not expanded inline to SSE conversion sequence Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: x86_64-*-*, i?86-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28806
[Bug target/28806] lround is not expanded inline to SSE conversion sequence
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-08-22 15:01 --- Mine. I have a patch in testing. -- 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 Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-22 15:01:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28806
[Bug c/28805] Xfree86-4.4 and 4.5 X compile failed with gcc-3.4.3
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-08-22 15:08 --- 3.4.3 is neither the latest release form 3.4 (which would be 3.4.6) nor in active maintainance anymore. You need to reproduce it with at least 4.0.2 and provide a testcase. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Summary|Xfree86-4.4 and 4.5 X |Xfree86-4.4 and 4.5 X |compile failed with gcc-|compile failed with gcc- |3.4.3 |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28805
[Bug java/28801] [4.2 Regression] libgcj build broken for gnu/CORBA/CDR/gnuRuntime.java
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-22 15:13 --- Fixed by: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00788.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Summary|libgcj build broken for |[4.2 Regression] libgcj |gnu/CORBA/CDR/gnuRuntime.jav|build broken for |a |gnu/CORBA/CDR/gnuRuntime.jav ||a Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28801
[Bug c/28805] Xfree86-4.4 and 4.5 X compile failed with gcc-3.4.3
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-22 15:17 --- Look at PR 17810 again, this was fixed in 3.4.5. *** This bug has been marked as a duplicate of 17810 *** -- 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=28805
[Bug rtl-optimization/17810] [3.4 Regression] internal compiler error: in verify_local_live_at_start for arm-rtems, arm-linux
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-08-22 15:17 --- *** Bug 28805 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17810
[Bug target/24367] [4.0/4.1/4.2 Regression] unrecognizable insn with -fPIC -O2 -funroll-loops
--- Comment #4 from krebbel at gcc dot gnu dot org 2006-08-22 15:17 --- Happens on mainline as well. -- krebbel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |krebbel at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-08-15 12:05:42 |2006-08-22 15:17:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24367
[Bug c++/28450] [4.0/4.1/4.2 regression] ICE with new and complex/vector types
--- Comment #4 from patchapp at dberlin dot org 2006-08-22 15:43 --- Subject: Bug number PR C++/28450 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/msg00793.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28450
[Bug tree-optimization/28802] Operations on data in dynamically allocated structure can't get vectorized
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-22 15:46 --- *** This bug has been marked as a duplicate of 21591 *** -- 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=28802
[Bug tree-optimization/21591] not vectorizing a loop with access to structs
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-22 15:46 --- *** Bug 28802 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||nomis80 at nomis80 dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21591
[Bug target/24367] [4.0/4.1/4.2 Regression] unrecognizable insn with -fPIC -O2 -funroll-loops
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-22 15:51 --- This was a P2 before the new Priority system came into effect so moving it to a P3. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24367
[Bug middle-end/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #26 from howarth at nitro dot med dot uc dot edu 2006-08-22 16:06 --- Should the testcase for this bug be marked as expected to fail on darwin since that platform has section-anchors disabled? I see... FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors) both on my machine and the logs from regress. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug middle-end/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #27 from pinskia at gcc dot gnu dot org 2006-08-22 16:08 --- (In reply to comment #26) FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors) Darwin support for section anchors is messed up and really I had wished Apple would have fixed the support for it but oh well. I gave them notice like 3-5 months from when it was broken but nothing happened so I don't care about the testresults on powerpc-darwin as Apple does not care either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug middle-end/28776] [4.2 Regression] dwarf2out.c:2160: ICE: in build_polynomial_chrec, at tree-chrec.h:108
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-08-22 16:26 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28776
[Bug middle-end/28776] [4.2 Regression] dwarf2out.c:2160: ICE: in build_polynomial_chrec, at tree-chrec.h:108
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-08-22 16:27 --- Subject: Bug 28776 Author: rguenth Date: Tue Aug 22 16:26:32 2006 New Revision: 116326 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116326 Log: 2006-08-22 Richard Guenther [EMAIL PROTECTED] PR middle-end/28776 * tree-scalar-evolution.c (fold_used_pointer): Add at_stmt parameter. Convert arguments to arithmetic expression to the chrecs type. (analyze_scalar_evolution_1): Adjust caller. * gcc.c-torture/compile/pr28776-1.c: New testcase. * gcc.c-torture/compile/pr28776-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr28776-1.c trunk/gcc/testsuite/gcc.c-torture/compile/pr28776-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-scalar-evolution.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28776
[Bug c++/28659] [4.2 regression] ICE (segfault) while compiling kdelibs 4.0 snapshot
--- Comment #10 from jason at gcc dot gnu dot org 2006-08-22 16:38 --- That patch didn't fix it, but I do have a fix now; I'll check it in soon. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mueller at gcc dot gnu dot |jason at gcc dot gnu dot org |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
[Bug target/28763] sizeof macro appears broken when bitfields are in structures
--- Comment #8 from mcvick_e at iname dot com 2006-08-22 16:42 ---
To try to be more helpful here, after doing a large amount of investigation
into the signature of this problem, it's been observed that the GNU compiler
simply defines (or appears to define) a bitfield (regardless of it's type
(char, short, int)) as nothing more than a byte aligned entity. Now if the
structure has a larger constituent primitive type (short, int) then the
structure will align to the largest primitive type.
For example. One of the tests that I performed was simply to define two
structures.
struct foo1 {
unsigned intbar1 : 10;
unsigned intbar2 : 10;
unsigned intbar3 : 12;
unsigned short bar4;
unsigned char bar5;
};
struct foo2 {
unsigned intbar1 : 10;
unsigned intbar2 : 10;
unsigned intbar3 : 12;
unsigned short bar4;
unsigned char bar5;
unsigned char bar6;
};
foo1 will report the size as being 0x8 (which is correct), where as foo2 will
report the size as 0xA which is incorrect. It's correct if the structure has
short alignment, however according to the ABI the structure should align to a
32-bit alignment because of the unsigned int bitfield.
Taking the same example above, if you substitute an unsigned int for the
unsigned short, then you get the alignment that you expect across all
situations. Merely because an integer primitive type is embedded within the
structure.
I hope this helps some.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++
--- Comment #12 from sje at cup dot hp dot com 2006-08-22 16:46 --- The patch mentioned in comment #11 also works for me. Note that I had to only use the patch that fixed the bug, the sencond patch / rest of the patch that is for improved debuggability caused warnings during bootstraps and would not work. The exact patch that I tested was: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00661.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28672
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #10 from eweddington at cso dot atmel dot com 2006-08-22 17:38 --- Subject: RE: Add option to have GCC not search $(prefix) Are you aware of this discussion http://gcc.gnu.org/ml/gcc/2006-07/msg00313.html and this alternative patch, installed in a csl vendor branch http://gcc.gnu.org/ml/gcc-cvs/2006-07/msg00684.html Danny Hi Danny, Yes, I was aware of that discussion; I even mentioned it on the GCC list recently. I was not aware of the alternative patch. And I don't think that Carlos was aware of this bug report, even though this bug report stemmed from a discussion on gcc that I had with Mark Mitchell years ago. I've now Cced Carlos on this bug report. Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug tree-optimization/28807] New: [4.2 Regression] wrong code with may_alias and structs
Testcase:
#include stdio.h
struct S { short x; };
typedef struct S __attribute__((__may_alias__)) test;
int f() {
int a=10;
test *p=(test *)a;
test s={1};
*p=s;
return a;
}
int main() {
if (f() == 10)
__builtin_abort()
return 0;
}
---
Even though the struct is not the same size as int, this should still work as
the struct is marked as may_alias so we get an aliasing set of 0.
--
Summary: [4.2 Regression] wrong code with may_alias and structs
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28807
[Bug tree-optimization/28807] [4.2 Regression] wrong code with may_alias and structs
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.0 Known to work||4.1.2 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28807
[Bug libgcj/27890] [4.2 regression] lib/logging.properties pollutes common namespace
--- Comment #11 from david at jpackage dot org 2006-08-22 18:03 --- I am just voicing my support for comment #2. In practice, we see a problem when installing both classpath and gcj on the same system, since they both install classpath.security and logging.properties files. Ideally, both classpath and gcj could share these files, or perhaps not and each JVM should be able to have its own configuration. Even if that's the case, these files look like global configuration files, that apply to any JVM using classpath or classpath derivatives. The location should likely be changed in either case. These are configuration files and likely need to be writable, so they should not be placed under /usr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27890
[Bug libgcj/24798] classmap.db should reside in /var/lib/gcj/
--- Comment #1 from david at jpackage dot org 2006-08-22 18:06 --- I agree with reporter. Bug #27890 is also related to FHS compliance with regard to readonly /usr partitions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24798
[Bug tree-optimization/28807] [4.2 Regression] wrong code with may_alias and structs
--- Comment #1 from dberlin at gcc dot gnu dot org 2006-08-22 18:18 --- Add an alias dump so we can see what things think of all this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28807
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #14 from iano at apple dot com 2006-08-22 18:25 ---
For your amusement:
[ollmia:/tmp] iano% cat main.c
#include stdio.h
extern int __isnand( double );
static __inline__ int __inline_isnan( double __a )
{
if( __builtin_isnan( __builtin_nan() ) )
return __builtin_isnan( __a );
return __isnand( __a); //this is our isnan() compiled in a separate
compilation unit that always works
}
int main( void )
{
volatile double g = __builtin_nan();
printf( isnan(%g) = %d\n, g, __inline_isnan( g ) );
return 0;
}
[ollmia:/tmp] iano% gcc main.c -O0 -g -ffast-math ; ./a.out
isnan(nan) = 0
If you step through in gdb, we see that what the compiler has done here is use
the IEEE compare result to determine that __builtin_isnan( __builtin_nan() )
is always true. It faills through to the next line where, __builtin_isnan()
returns always false.
For reasons I can't explain, we also see this:
[ollmia:/tmp] iano% cat main.c
#include stdio.h
extern int __isnand( double );
static __inline__ int __inline_isnan( double __a )
{
static const double nan = __builtin_nan();
if( nan != nan )
return __a != __a;
return __isnand( __a);
}
int main( void )
{
volatile double g = __builtin_nan();
printf( isnan(%g) = %d\n, g, __inline_isnan( g ) );
return 0;
}
[ollmia:/tmp] iano% gcc main.c -O0 -g -ffast-math ; ./a.out
isnan(nan) = 1
[ollmia:/tmp] iano% gcc main.c -O3 -g -ffast-math ; ./a.out
isnan(nan) = 0
[ollmia:/tmp] iano% gcc main.c -O0 -g -ffinite-math-only ; ./a.out
isnan(nan) = 1
[ollmia:/tmp] iano% gcc main.c -O3 -g -ffinite-math-only ; ./a.out
isnan(nan) = 0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug c++/28659] [4.2 regression] ICE (segfault) while compiling kdelibs 4.0 snapshot
--- Comment #11 from jason at gcc dot gnu dot org 2006-08-22 18:27 --- Subject: Bug 28659 Author: jason Date: Tue Aug 22 18:27:26 2006 New Revision: 116329 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116329 Log: PR c++/28659 * typeck.c (merge_types): If either of the types have the right attributes, return that one. * tree.c (cp_build_type_attribute_variant): Make sure we aren't doing this to class types. * typeck.c (original_type): Deal with type quals properly. Added: trunk/gcc/testsuite/g++.dg/ext/attrib26.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/cp/typeck.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
[Bug c/28808] New: Alignment problem in __gthread_once_t in vxWorks
The __gthread_once_t struct should use aligned ints instead of chars. This
allows the values to be manipulated on PowerPC using the stwcx and lwarx
instructions (as is done in the vxTas() function call) without causing
alignment issues. The fix is probably applicable to other architectures (SH4?)
as well.
--- old/gcc/gthr-vxworks.h 2006-08-22 09:26:05.0 -0400
+++ new/gcc/gthr-vxworks.h 2006-08-22 09:26:15.0 -0400
@@ -103,8 +103,8 @@
typedef struct
{
- volatile unsigned char busy;
- volatile unsigned char done;
+ volatile unsigned int busy;
+ volatile unsigned int done;
}
__gthread_once_t;
--
Summary: Alignment problem in __gthread_once_t in vxWorks
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: atgraham at gmail dot com
GCC target triplet: powerpc-vxworks-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28808
[Bug c++/27115] [4.0/4.1 Regression] ICE in cp_expr_size or miscompilation with statement expressions and constructors (and ?: )
--- Comment #7 from jason at gcc dot gnu dot org 2006-08-22 18:41 --- This is too big a change to apply to 4.0 or 4.1, so WONTFIX there. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27115
[Bug c/28808] Alignment problem in __gthread_once_t in vxWorks
--- Comment #1 from atgraham at gmail dot com 2006-08-22 18:43 --- Patch was submitted to gcc-patches earlier, which is the same as the patch already posted to the previous comment. http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00786.html -- atgraham at gmail dot com changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28808
[Bug c++/28420] [4.0/4.1/4.2 regression] ICE with typeid as template parameter
--- Comment #2 from jason at gcc dot gnu dot org 2006-08-22 18:51 --- Subject: Bug 28420 Author: jason Date: Tue Aug 22 18:51:40 2006 New Revision: 116330 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116330 Log: PR c++/28420 * parser.c (cp_parser_postfix_expression): Make sure that the saved value for parser-type_definition_forbidden_message is restored before returning to avoid an invalid free(). Added: trunk/gcc/testsuite/g++.dg/template/typeid-template-argument.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28420
[Bug debug/28692] [4.2 Regression] ICE in rtl_for_decl_init, at dwarf2out.c
--- Comment #7 from geoffk at gcc dot gnu dot org 2006-08-22 19:16 --- Subject: Bug 28692 Author: geoffk Date: Tue Aug 22 19:16:03 2006 New Revision: 116331 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116331 Log: Index: gcc/ChangeLog 2006-08-21 Geoffrey Keating [EMAIL PROTECTED] PR debug/28692 * dwarf2out.c (rtl_for_decl_init): Don't try to create RTL for complex values, nor for generic vector values. Index: gcc/testsuite/ChangeLog 2006-08-21 Geoffrey Keating [EMAIL PROTECTED] PR debug/28692 * gcc.dg/debug/const-1.c: New. * gcc.dg/debug/const-2.c: New. * gcc.dg/debug/dwarf2/const-1.c: New. * gcc.dg/debug/dwarf2/const-2.c: New. * gcc.dg/debug/dwarf2/const-2b.c: New. Added: trunk/gcc/testsuite/gcc.dg/debug/const-1.c trunk/gcc/testsuite/gcc.dg/debug/const-2.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/const-1.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/const-2.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/const-2b.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28692
[Bug c++/23211] [4.0/4.1/4.2 regression] using dec in nested class doesn't import name
--- Comment #11 from jason at gcc dot gnu dot org 2006-08-22 19:17 --- The using-declaration is invalid because foo is not a base of bar. icc also rejects the testcase if you try to instantiate bar. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23211
[Bug debug/28692] [4.2 Regression] ICE in rtl_for_decl_init, at dwarf2out.c
--- Comment #8 from geoffk at gcc dot gnu dot org 2006-08-22 19:17 --- Patch above should have fixed this. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28692
[Bug c++/14167] Unneeded C++ types are output in debug info due to use of static constants
--- Comment #5 from jason at gcc dot gnu dot org 2006-08-22 19:34 --- [basic.def.odr] says that an object that appears in an integral constant expression is not thereby used, and it seems reasonable to extend that to not setting TREE_USED. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14167
[Bug c++/27714] [4.0/4.1/4.2 regression] operator new as friend in template class rejected
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-05-26 14:59:48 |2006-08-22 19:45:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27714
[Bug fortran/28809] New: [gfortran] internal compiler error: in gfc_conv_ss_descriptor, at fortran/trans-array.c:1265
Attempting to compile the following code gives the error message below: -- recursive real function det(A) result(res) ! Parameters. real, dimension(:,:), intent(in) :: A ! Local variables. real :: d integer:: n n = size(A,1) d = 0.0 if (n==2) then res = A(1,1)*A(2,2)-A(1,2)*A(2,1) return else if (n==3) then d = A(1,1)*(A(2,2)*A(3,3)-A(3,2)*A(2,3)) d = d-A(1,2)*(A(2,1)*A(3,3)-A(3,1)*A(2,3)) d = d+A(1,3)*(A(2,1)*A(3,2)-A(3,1)*A(2,2)) res = d return else if (n==4) then res = A(1,1)*det(A((/2,3,4/),(/2,3,4/))) -A(1,2)*det(A((/2,3,4/),(/1,3,4/))) +A(1,3)*det(A((/2,3,4/),(/1,2,4/))) -A(1,4)*det(A((/2,3,4/),(/1,2,3/))) return else write(*,*) 'det for matrices bigger than 4x4 not implemented' stop end if end function det program main real, dimension(4,4) :: A integer :: i,j do i = 1,4 do j = 1,4 call random_number(A(i,j)) end do end do write(*,*) det(A) end program main -- [EMAIL PROTECTED] detbug]$ gfortran -o detbug detbug.f90 detbug.f90: In function 'det': detbug.f90:21: internal compiler error: in gfc_conv_ss_descriptor, at fortran/trans-array.c:1265 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://bugzilla.redhat.com/bugzilla for instructions. [EMAIL PROTECTED] detbug]$ gfortran --version GNU Fortran 95 (GCC 4.0.2 20051125 (Red Hat 4.0.2-8)) Copyright (C) 2005 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING -- Summary: [gfortran] internal compiler error: in gfc_conv_ss_descriptor, at fortran/trans-array.c:1265 Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jchodera at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28809
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #2 from pault at gcc dot gnu dot org 2006-08-22 20:02 --- I have figured out what the problem is: The module procedure formal arguments go into their own namespace; derived type references pointing to the contained namespace. In the reformed association of derived types, the symbols to which the formal arguments are pointing are removed when host association occurs. It is something of a miracle that the old system works - it certainly was not intentional! Now for a clean solution! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug c++/14167] Unneeded C++ types are output in debug info due to use of static constants
--- Comment #6 from drow at gcc dot gnu dot org 2006-08-22 20:03 --- The use in main should still set TREE_USED, though; should TREE_USED on a member ought to cause the class to be emitted? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14167
[Bug c++/28659] [4.2 regression] ICE (segfault) while compiling kdelibs 4.0 snapshot
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-08-22 20:12 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
[Bug preprocessor/28810] New: gcc -MD -MP doesn't add phony rule for source file
When I generate depends using gcc -MD -MP, it generates a dependency for the object file on the source file and all the headers. It also generates an empty dependency for each header (to handle the case where the header has gone away - that's the point of -MP). It doesn't, however, do that for the main source file. This behavior, admittedly, is documentented in the manual; the manual doesn't give a reason for this choice. And it's causing problems for me: if I move the main source file (without moving the corresponding object file, an admittedly rare occurrence), then make refuses to rebuild my object file, because the dependency generated by GCC on the old source file still exists. If there's a reason for GCC's current behavior, then I can live with it - I don't move a source file (without also moving the corresponding object file!) nearly as often as I move headers. But if there's no particular reason, then I think the current behavior is suboptimal. I've seen this over a range of GCC releases, including 3.2.3 and 4.1.1. -- Summary: gcc -MD -MP doesn't add phony rule for source file Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: carlton at bactrian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28810
[Bug c++/28255] [4.1/4.2 regression] ICE with C99 compund literal (scalar), initializer and templates
--- Comment #4 from jason at gcc dot gnu dot org 2006-08-22 20:22 --- It seems we've never really handled compound-literals properly within templates. This doesn't seem like a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28255
[Bug c++/28255] [4.1/4.2 regression] ICE with C99 compund literal (scalar), initializer and templates
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-22 20:26 --- (In reply to comment #4) It seems we've never really handled compound-literals properly within templates. This doesn't seem like a regression. Yes this is PR 28766. The ICE part is a regression or at least that is what I remember being, in that we should not change an rejects-valid into an ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28255
[Bug c++/23211] [4.0/4.1/4.2 regression] using dec in nested class doesn't import name
--- Comment #12 from igodard at pacbell dot net 2006-08-22 20:28 --- If the using is invalid then there should be a diagnostic on line 7 that says so. -- igodard at pacbell dot net changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23211
[Bug preprocessor/28810] gcc -MD -MP doesn't add phony rule for source file
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28810
[Bug libstdc++/28811] New: undefined versioned symbol name [EMAIL PROTECTED]
i've configured my gcc with -with-pic option and trying to build statically linked shared c++ library. $ make g++ -O2 -g0 -Wall -z defs test.cpp -o libtest.so -fPIC -shared \ -nodefaultlibs \ -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic \ -lc -lgcc_eh /usr/bin/ld: libtest.so: undefined versioned symbol name [EMAIL PROTECTED] /usr/bin/ld: failed to set dynamic section sizes: Bad value collect2: ld returned 1 exit status -- Summary: undefined versioned symbol name [EMAIL PROTECTED] IBCXX_3.4 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC build triplet: x86-64-linux GCC host triplet: x86-64-linux GCC target triplet: x86-64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
[Bug libstdc++/28811] undefined versioned symbol name [EMAIL PROTECTED]
--- Comment #1 from pluto at agmk dot net 2006-08-22 20:29 --- Created an attachment (id=12113) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12113action=view) makefile for testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
[Bug libstdc++/28811] undefined versioned symbol name [EMAIL PROTECTED]
--- Comment #2 from pluto at agmk dot net 2006-08-22 20:30 --- Created an attachment (id=12114) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12114action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
[Bug c++/23211] using dec in nested class doesn't import name
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-08-22 20:30 --- So this is just a diagnostic issue and not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords|rejects-valid |diagnostic Summary|[4.0/4.1/4.2 regression]|using dec in nested class |using dec in nested class |doesn't import name |doesn't import name | Target Milestone|4.1.2 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23211
[Bug c++/28687] [4.2 regression] dynamic_castvoid* disallowed too rigorously with -fno-rtti
--- Comment #16 from pkasting at google dot com 2006-08-22 20:31 --- Comment 4 seems to make it clear that GCC's current behavior differs from past behavior that was legal under the spec. I fail to see the utility of the current behavior or why it would be objectionable to apply the patch on this bug. (In reply to comment #12) | I'm not claiming that the behavior isn't conformant to the docs, I'm claiming | that you regressed a construct No, we did not regress because the documentation was very explicit. The documentation was previously incorrect. The compiler was changed to match the documentation's behavior, rather than the documentation being changed to match the compiler's behavior and the C++ standard. The patch on this bug makes the IMO correct fix of keeping the compiler behavior and documentation in sync, but making them match the old, standards-compliant behavior that existing products rely on. This bug should be REOPENED. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28687
[Bug libstdc++/28811] undefined versioned symbol name [EMAIL PROTECTED]
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-22 20:35 --- How sure are you that this is not a binutils bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
[Bug c++/28687] [4.2 regression] dynamic_castvoid* disallowed too rigorously with -fno-rtti
--- Comment #17 from bangerth at dealii dot org 2006-08-22 20:36 --- I agree that we should allow this behavior. Clearly the standard has nothing to say about whether -fno-rtti should allow this or not, but the standard has an explicit provision for the case of dynamic_castvoid*. Furthermore, we have a patch to both the code and the documentation that would allow to get us back to the previous behavior (even if it was wrongly documented). The patch is minimal and adds a useful feature. I don't see why we should reject it. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28687
[Bug libgcj/27890] [4.2 regression] lib/logging.properties pollutes common namespace
--- Comment #12 from fitzsim at gcc dot gnu dot org 2006-08-22 20:37 --- Subject: Bug 27890 Author: fitzsim Date: Tue Aug 22 20:37:36 2006 New Revision: 116332 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116332 Log: 2006-08-22 Thomas Fitzsimmons [EMAIL PROTECTED] PR libgcj/27890 * gnu/classpath/natSystemProperties.cc (insertSystemProperties): Set gnu.classpath.home.url to TOOLEXECLIBDIR. * configure.ac: Do not add --with-native-libdir to ac_configure_args. * java/security/libgcj.security: Remove file. * java/util/logging/logging.properties: Likewise. * classpath/m4/acinclude.m4 (CLASSPATH_TOOLEXECLIBDIR): New macro. * classpath/resource/Makefile.am (loggingdir): Define to toolexeclibdir. (securitydir): Likewise. * classpath/configure.ac: Call CLASSPATH_TOOLEXECLIBDIR. Set default nativeexeclibdir using toolexeclibdir. * HACKING: Fix classpath aclocal arguments. * Makefile.am (secdir): Remove variable. (propdir): Likewise. (AM_CXXFLAGS): Replace LIBDIR definition with TOOLEXECLIBDIR definition. (all_property_files): Remove variable. (install-data-local): Do not install libgcj.security or logging.properties. * configure, Makefile.in, classpath/configure, classpath/Makefile.in, classpath/native/jni/java-lang/Makefile.in, classpath/native/jni/midi-alsa/Makefile.in, classpath/native/jni/classpath/Makefile.in, classpath/native/jni/midi-dssi/Makefile.in, classpath/native/jni/Makefile.in, classpath/native/jni/java-nio/Makefile.in, classpath/native/jni/java-net/Makefile.in, classpath/native/jni/gconf-peer/Makefile.in, classpath/native/jni/java-io/Makefile.in, classpath/native/jni/xmlj/Makefile.in, classpath/native/jni/java-util/Makefile.in, classpath/native/jni/qt-peer/Makefile.in, classpath/native/jni/gtk-peer/Makefile.in, classpath/native/Makefile.in, classpath/native/jawt/Makefile.in, classpath/native/target/Linux/Makefile.in, classpath/native/target/Makefile.in, classpath/native/target/generic/Makefile.in, classpath/native/fdlibm/Makefile.in, classpath/native/plugin/Makefile.in, classpath/resource/Makefile.in, classpath/scripts/Makefile.in, classpath/tools/Makefile.in, classpath/doc/Makefile.in, classpath/doc/api/Makefile.in, classpath/lib/Makefile.in, classpath/external/Makefile.in, classpath/external/sax/Makefile.in, classpath/external/w3c_dom/Makefile.in, classpath/external/relaxngDatatype/Makefile.in, classpath/include/Makefile.in, classpath/aclocal.m4, classpath/examples/Makefile.in, aclocal.m4: Regenerate. Removed: trunk/libjava/java/security/libgcj.security trunk/libjava/java/util/logging/logging.properties Modified: trunk/libjava/ChangeLog trunk/libjava/HACKING trunk/libjava/Makefile.am trunk/libjava/Makefile.in trunk/libjava/aclocal.m4 trunk/libjava/classpath/Makefile.in trunk/libjava/classpath/aclocal.m4 trunk/libjava/classpath/configure trunk/libjava/classpath/configure.ac trunk/libjava/classpath/doc/Makefile.in trunk/libjava/classpath/doc/api/Makefile.in trunk/libjava/classpath/examples/Makefile.in trunk/libjava/classpath/external/Makefile.in trunk/libjava/classpath/external/relaxngDatatype/Makefile.in trunk/libjava/classpath/external/sax/Makefile.in trunk/libjava/classpath/external/w3c_dom/Makefile.in trunk/libjava/classpath/include/Makefile.in trunk/libjava/classpath/lib/Makefile.in trunk/libjava/classpath/m4/acinclude.m4 trunk/libjava/classpath/native/Makefile.in trunk/libjava/classpath/native/fdlibm/Makefile.in trunk/libjava/classpath/native/jawt/Makefile.in trunk/libjava/classpath/native/jni/Makefile.in trunk/libjava/classpath/native/jni/classpath/Makefile.in trunk/libjava/classpath/native/jni/gconf-peer/Makefile.in trunk/libjava/classpath/native/jni/gtk-peer/Makefile.in trunk/libjava/classpath/native/jni/java-io/Makefile.in trunk/libjava/classpath/native/jni/java-lang/Makefile.in trunk/libjava/classpath/native/jni/java-net/Makefile.in trunk/libjava/classpath/native/jni/java-nio/Makefile.in trunk/libjava/classpath/native/jni/java-util/Makefile.in trunk/libjava/classpath/native/jni/midi-alsa/Makefile.in trunk/libjava/classpath/native/jni/midi-dssi/Makefile.in trunk/libjava/classpath/native/jni/qt-peer/Makefile.in trunk/libjava/classpath/native/jni/xmlj/Makefile.in trunk/libjava/classpath/native/plugin/Makefile.in trunk/libjava/classpath/native/target/Linux/Makefile.in trunk/libjava/classpath/native/target/Makefile.in trunk/libjava/classpath/native/target/generic/Makefile.in
[Bug c++/23211] using dec in nested class doesn't import name
--- Comment #14 from igodard at pacbell dot net 2006-08-22 20:38 --- Not, it's an error: invalid text is accepted without diagnostic (if the identifier introduced with the using is not itself used, then the using statement is invalid but gets no diagnostic). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23211
[Bug c++/28558] [4.0/4.1/4.2 regression] Trouble with new and __attribute__
--- Comment #2 from jason at gcc dot gnu dot org 2006-08-22 20:41 ---
This testcase reproduces the bug without new. The problem is that applying
attributes to a type creates a new TYPE_MAIN_VARIANT, which is fundamentally
nonsensical for class types. We really need to impose more design on the whole
attribute system.
IMO we should give an error for this code.
struct A
{
A(int) { }
};
int main()
{
A a = (A __attribute__((unused)))0;
}
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28558
[Bug libgcj/27890] [4.2 regression] lib/logging.properties pollutes common namespace
--- Comment #13 from fitzsim at redhat dot com 2006-08-22 20:41 --- Fixed by installing logging.properties and classpath.security in both lib and lib64, in the multilib case. This means that 32- and 64-bit property and module lists can be manipulated separately. Doing so will also fix PR28775. -- fitzsim at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27890
[Bug java/28775] gcj-dbtool fails to work on x86_64: NoSuchAlgorithmException: MD5
--- Comment #3 from fitzsim at redhat dot com 2006-08-22 20:41 --- Fixed on trunk by commit for PR 27890. -- fitzsim at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28775
[Bug c++/28560] [4.0/4.1/4.2 regression] Trouble with __attribute__ in template parameter
--- Comment #1 from jason at gcc dot gnu dot org 2006-08-22 20:42 --- *** This bug has been marked as a duplicate of 28558 *** -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28560
[Bug c++/28558] [4.0/4.1/4.2 regression] Trouble with new and __attribute__
--- Comment #3 from jason at gcc dot gnu dot org 2006-08-22 20:42 --- *** Bug 28560 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28558
[Bug c++/28558] [4.0/4.1/4.2 regression] Trouble with new and __attribute__
--- Comment #4 from jason at gcc dot gnu dot org 2006-08-22 20:43 --- Related to PR 28659. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28558
[Bug fortran/28809] [gfortran] internal compiler error: in gfc_conv_ss_descriptor, at fortran/trans-array.c:1265
--- Comment #1 from kargl at gcc dot gnu dot org 2006-08-22 20:53 --- Upgrade your compiler to at least 4.1.1, and try again. Also, you need an explicit interface for the recursive function in your main program interface recursive real function det(a) result(res) real, dimension(:,:), intent(in) :: a end function det end interface -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28809
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #11 from carlos at codesourcery dot com 2006-08-22 21:02 --- Created an attachment (id=12115) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12115action=view) When relocated do not add paths that contain the configured prefix. Thanks for adding me to the CC. A relocated compiler should never search the configured prefix for programs, libraries or start files. A relocated compiler searching for files in the configured prefix is troublesome. The configured prefix may contain a conflicting toolchain, or a slow network path. The old behaviour of searching the conifgured prefix is not what users expect from a relocated toolchain. Consider 3 types of paths: 1. Relocated paths. 2. Configured prefix paths. 3. Well known system paths. The type 1 and type 3 paths are always added to our search lists. The type 2 paths are only added if the compiler is installed at the configured prefix. This patch groups the 3 path types logically in gcc/gcc.c, and adds the paths based on the wether the compiler is relocated or unrelocated. Could you test this patch out and tell me if it helps? There is a caveat, running 'make -k check' from the object directory may not work. In certain cases, bare-metal targets for example, contains the required start files to build and run the tests. I have an additional patch for this, but it is still in testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug c++/23372] [4.0/4.1/4.2 Regression] Temporary aggregate copy not elided when passing parameters by value
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-07-05 09:38:34 |2006-08-22 21:08:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug fortran/28809] [gfortran] internal compiler error: in gfc_conv_ss_descriptor, at fortran/trans-array.c:1265
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de 2006-08-22 21:08 --- Using gfortran 4.1.2 20060705 (prerelease) (SUSE Linux) and GNU Fortran 95 (GCC) 4.2.0 20060822 (experimental) it compiles and gives the output (from the program): det for matrices bigger than 4x4 not implemented John Chodera, I would really recommend to update to 4.1.x or to 4.2-snapshots as gfortran in GCC 4.0.x is rather buggy. See http://gcc.gnu.org/wiki/GFortranBinaries for binary GCC versions. In addition: As the NAG compiler points out: --- Error: Explicit interface required for DET from MAIN - argument A (no. 1) is an assumed-shape array --- The problem is that Fortran passes an array differently for A(*) or A(n) than for A(:). The latter is called assumed-shaped array and is an addition to Fortran 90 (the former also work with Fortran 77). In order to let the compiler know that you want to pass an assumed-shaped array, you need to either create a module, which contains the function det, or you put it below contains in the program section or you write an interface in the program section. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28809
[Bug c++/24009] [4.0/4.1/4.2 regression] C++ fails to print #include stack
--- Comment #12 from jason at gcc dot gnu dot org 2006-08-22 21:25 --- *** Bug 24037 has been marked as a duplicate of this bug. *** -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24009
[Bug c++/24037] [4.0/4.1/4.2 regression] C++ front-end does not print #include stack for parsering errors
--- Comment #8 from jason at gcc dot gnu dot org 2006-08-22 21:25 --- *** This bug has been marked as a duplicate of 24009 *** -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24037
[Bug rtl-optimization/28812] New: RTL aliasing vs may_alias and structs
The following testcase should work with -fstrict-aliasing -O2 but does not:
struct S { short x; };
typedef struct S __attribute__((__may_alias__)) test;
test *p;
int g(int *a)
{
p = (test*)a;
}
int f()
{
int a;
g(a);
a = 10;
test s={1};
*p=s;
return a;
}
int main() {
if (f() == 10)
__builtin_abort();
return 0;
}
--
Summary: RTL aliasing vs may_alias and structs
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28812
[Bug libstdc++/28811] undefined versioned symbol name [EMAIL PROTECTED]
--- Comment #4 from hjl at lucon dot org 2006-08-22 21:39 --- libstdc++ doesn't supports building PIC archive properly. The archive shouldn't include symbol version even if it is compiled with PIC since symbol version info is generated by linker when building a shared library. In glibc, we use -DSHARED to indicate if a file is compiled for shared library. We need to change ./src/compatibility.cc from #if defined(_GLIBCXX_SYMVER_GNU) defined(PIC) to #if defined(_GLIBCXX_SYMVER_GNU) defined(SHARED) and define -DSHARED when compiling for shared library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28811
[Bug fortran/28813] New: gfortran.dg/direct_io_6.f90 can exhaust system disk space
The current implementation of the direct_io_6 doesn't check for available disk space before attempting to use it. This can result in complete exhaustion of the disk space on a build system resulting in the failure of other tasks running on it. Since this test is run eight times with different compiler flags, the possiblity of causing some other task on the build machine to crash is even higher. This really should be addressed before 4.2 is released. -- Summary: gfortran.dg/direct_io_6.f90 can exhaust system disk space Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran 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=28813
[Bug tree-optimization/28807] [4.2 Regression] wrong code with may_alias and structs
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-22 21:49 ---
Better testcase which shows the problem before SRA:
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;
}
--
I will attach the aliasing dump after this.
--
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 #3 from pinskia at gcc dot gnu dot org 2006-08-22 21:50 --- Created an attachment (id=12116) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12116action=view) aliasing dump aliasing dump for the newest testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28807
[Bug c/28814] New: ICE when compiling Stalin under 4.1 but not 4.0
Stalin is a Scheme compiler that generates C code. Stalin is itself written in C and can compile itself. I am preparing a new release of Stalin for Debian Etch. This release compiles with earlier versions of gcc, such as gcc-4.0, but not with gcc-4.1. It gives an ICE. The preprocessed source is huge. I submitted an earlier bug report that included the preprocessed source but apparently the email bounced. I am resubmitting making the preprocessed source available on the web instead. I would appreciate if someone from GCC/GNU can let me know when you have downloaded the preprocessed source so that I can remove it from my web site. Environment: System: Linux chino 2.6.15-1-k7-smp #2 SMP Mon Mar 6 15:50:26 UTC 2006 i686 GNU/Linux Architecture: i686 I am submitting this from a different machine than that which generated the error because the latter has no email connection. Both run Debian Etch on identical hardware. host: i486-pc-linux-gnu build: i486-pc-linux-gnu target: i486-pc-linux-gnu configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --with-tune=i686 --enable-checking=release i486-linux-gnu How-To-Repeat: [EMAIL PROTECTED]gcc -v -save-temps -o stalin -I./include -O3 -fomit-frame-pointer -fno-strict-aliasing -freg-struct-return stalin.c -L./include -lm -lgc Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5) /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1 -E -quiet -v -I./include stalin.c -mtune=i686 -fomit-frame-pointer -fno-strict-aliasing -freg-struct-return -O3 -fpch-preprocess -o stalin.i ignoring nonexistent directory /usr/local/include/i486-linux-gnu ignoring nonexistent directory /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../i486-linux-gnu/include ignoring nonexistent directory /usr/include/i486-linux-gnu #include ... search starts here: #include ... search starts here: ./include /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.1.2/include /usr/include End of search list. /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1 -fpreprocessed stalin.i -quiet -dumpbase stalin.c -mtune=i686 -auxbase stalin -O3 -version -fomit-frame-pointer -fno-strict-aliasing -freg-struct-return -o stalin.s GNU C version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5) (i486-linux-gnu) compiled by GNU C version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 3efbb0b5b3119ec825babd3e1cecb910 stalin.c: In function âf9226â: stalin.c:369354: internal compiler error: in compare_values, at tree-vrp.c:415 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-4.1/README.Bugs. Preprocessed source stored into /tmp/ccYcxZDO.out file, please attach this to your bugreport. 395.851u 3.338s 6:39.21 99.9% 0+0k 0+0io 0pf+0w [EMAIL PROTECTED]gcc-4.0 -v -save-temps -o stalin -I./include -O3 -fomit-frame-pointer -fno-strict-aliasing -freg-struct-return stalin.c -L./include -lm -lgc Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3) /usr/lib/gcc/i486-linux-gnu/4.0.4/cc1 -E -quiet -v -I./include stalin.c -mtune=i686 -fomit-frame-pointer -fno-strict-aliasing -freg-struct-return -O3 -fpch-preprocess -o stalin.i ignoring nonexistent directory /usr/local/include/i486-linux-gnu ignoring nonexistent directory /usr/include/i486-linux-gnu #include ... search
