The mainline compiler (trunk revision 138833) fails to compile
the test case below with -O1:
foo.c:24: internal compiler error: in build2_stat, at tree.c:3257
static union {
char buf[12 * sizeof (long long)];
} u;
int main ()
{
int off, len, i;
char *p, *q;
for (off = 0; off (sizeof
--- Comment #5 from jamborm at gcc dot gnu dot org 2008-08-08 07:50 ---
(In reply to comment #4)
Interesting. I may have a look into the CCP problem.
Well, I think that we have pass_rebuild_cgraph_edges precisely because
passes like CCP are not trusted to update call graph
--- Comment #8 from schilds at sun dot ac dot za 2008-08-08 08:31 ---
What does Fortran 2003 have to do with legacy mode? Nothing. So far as I know
the GCC compiler is at odds with Solaris, Intel, Vax, you name it. All of these
allowed you to touch unit 6 without affecting the print*,
An attempt to build OpenFOAM 1.5 (www.opencfd.co.uk/openfoam/version1.5.html)
on
powerpc-ibm-aix5.3.0.0 resulted in 7 compiler internal errors (ICEs) with gcc
4.3.1 and 6 ICEs with gcc 4.2.0.
The 4.2.0 compiler suite is as downloaded from the IBM AIX RPM repository
--- Comment #1 from jorn dot amundsen at ntnu dot no 2008-08-08 08:48
---
Created an attachment (id=16043)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16043action=view)
g++ preprocessed file
g++ preprocessed file, ICE with powerpc-ibm-aix5.3.0.0 compiles cleanly with
--- Comment #2 from jorn dot amundsen at ntnu dot no 2008-08-08 08:53
---
Created an attachment (id=16044)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16044action=view)
makeChemkinReactions.C assembler output
GCC 4.3.1 powerpc-ibm-aix5.3.0.0 assembler output from compiling
--- Comment #3 from jorn dot amundsen at ntnu dot no 2008-08-08 09:01
---
Created an attachment (id=16045)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16045action=view)
g++ preprocessed file
GCC 4.2.0 powerpc-ibm-aix5.3.0.0 preprocessed source, not tested on any other
GCC 4.2.x
--- Comment #4 from jorn dot amundsen at ntnu dot no 2008-08-08 09:02
---
Created an attachment (id=16046)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16046action=view)
makeChemkinReactions.C assembler output
GCC 4.2.0 powerpc-ibm-aix5.3.0.0 assembler output from compiling
--- Comment #9 from burnus at gcc dot gnu dot org 2008-08-08 09:50 ---
(In reply to comment #8)
What does Fortran 2003 have to do with legacy mode? Nothing.
Well, any compiler strives to be standard compliant thus I would expect all of
the compilers to behave *by default* according to
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-08-08 10:00 ---
Mine. Some tuplification errors in tree-ssa-loop-niter.c.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jh at suse dot cz 2008-08-08 10:47 ---
Subject: Re: internal compiler error: in emit_unop_insn, at optabs.c:3806
Hi,
this is patch I am testing.
Index: optabs.c
===
*** optabs.c(revision 138862)
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-08 11:31 ---
Subject: Bug 37056
Author: rguenth
Date: Fri Aug 8 11:30:13 2008
New Revision: 138865
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138865
Log:
2008-08-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-08 11:31 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from mikpe at it dot uu dot se 2008-08-08 13:58 ---
(In reply to comment #4)
I can confirm that the reduced test case fails for me with gcc 4.0.4, 4.1.2,
4.2.4, and 4.3.1 on both powerpc and powerpc64. gcc-3.4.6 and older work.
It doesn't fail for me with gcc-4.x on
--- Comment #2 from eric dot weddington at atmel dot com 2008-08-08 14:38
---
The regression tester found that this regression was on revision 138238, by Jan
Hubicka.:
http://gcc.gnu.org/ml/gcc-regression/2008-07/msg00034.html
Jan, can you take a look at this please?
--
eric dot
I see
FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
UNRESOLVED: gcc.dg/tree-prof/bb-reorg.c execution,-fprofile-use
-D_PROFILE_U
SE
FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE
UNRESOLVED: gcc.dg/tree-prof/pr34999.c execution,
--with-gnu-as
--with-tune=generic --prefix=/opt/gnu/gcc/gcc-4.4.0 --enable-debug=no
--disable-nls --enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-java-gc=boehm
Thread model: posix
gcc version 4.4.0 20080808 (experimental
$ gcc -O2 -S sparc-tdep.i
In function #8216;memcpy#8217;,
inlined from #8216;sparc32_store_return_value#8217; at sparc-tdep.i:39:
sparc-tdep.i:8: warning: call to __builtin___memcpy_chk will always overflow
destination buffer
--
Summary: [4.3/4.4 regression] Bogus
--- Comment #1 from schwab at suse dot de 2008-08-08 15:16 ---
Created an attachment (id=16047)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16047action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37060
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-08 15:43 ---
We fail to see that the len == 16 case cannot happen in the second if (), more
specifically we fail to jump-thread because of the twisted CFG.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #10 from kargl at gcc dot gnu dot org 2008-08-08 15:57 ---
(In reply to comment #8)
What does Fortran 2003 have to do with legacy mode? Nothing.
You are aware that Fortran 2003 is backwards compatible with
Fortran 77, right?
So far as I know the GCC compiler is at odds
--- Comment #1 from joel at gcc dot gnu dot org 2008-08-08 16:03 ---
Also occurs on powerpc-rtems4.9 -
4.4.0 20080807 (experimental) [trunk revision 138841]
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from joel at gcc dot gnu dot org 2008-08-08 16:08 ---
Created an attachment (id=16048)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16048action=view)
Updated RTEMS support for revision 138841
--
joel at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from joel at gcc dot gnu dot org 2008-08-08 16:08 ---
2008-08-08 Joel Sherrill [EMAIL PROTECTED]
* s-oscons-tmplt.c: RTEMS defines AF_INET6 but does support it.
* gsocket.h, socket.c: Update to support RTEMS.
* gcc-interface/Make-lang.in: Include
I'm compiling gcc snapshot 20080801 on a Solaris 2.10 (amd64) machine with host
tools from binutils 2.18 and gcc 4.3.
I've configured with:
../gcc-4.4-20080801/configure --disable-static --enable-shared
--prefix=/home/huron/jeffga/sfw/gcc-4.4
--with-gmp=/home/huron/jeffga/sfw/gcc-4.4
gcc 4.3.0 issues warnings for the unreachable code on lines 7 and 9 below
but fails to issue one for line 17.
$ cat -n t.C g++ -Wunreachable-code -c t.C
1 int f ()
2 {
3 int i = 0;
4
5 if (i == 0) return 0;
6
7 throw i;// unreachable,
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-08 19:06 ---
17 return 1; // unreachable, no warning
This is only unreachable with optimization turned on so closing as invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
I would expect gcc to optimize away the unreachable code in both functions
below but only in the first one is it eliminated. In addition, even though
the call to f1() in f3() can never be executed the compiler issues no
warning.
$ cat -n t.C g++ -Wunreachable-code -O3 -S t.C
1 void f1 ();
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-08-08 19:43 ---
Fixed in for 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
gcc assumes that functions defined with the pure attribute have no side
effects and do not modify program state, including through pointers passed
to such functions as arguments. The function below does modify the object
pointed to by its argument. It would be useful if gcc issued a diagnostic
for
--- Comment #1 from sebor at roguewave dot com 2008-08-08 19:47 ---
Similarly, functions declared with the const attribute such as f1() in the
test case below that violate the compiler's assumptions should be diagnosed:
$ cat -n t.C g++ -c -O2 -Wall -W t.C
1 extern int i;
2
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-08-08 20:16
---
This breaks building the kernel as well.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jv244 at cam dot ac dot uk 2008-08-08 20:34 ---
(In reply to comment #5)
(In reply to comment #4)
If you look, the patch preceeded the PR. Toon posted the problem on the list,
promising to develop this testcase. This he duly did. Please keep it open
another
--- Comment #5 from jv244 at cam dot ac dot uk 2008-08-08 20:39 ---
has J3 judged the testcase ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34805
--- Comment #21 from andreast at gcc dot gnu dot org 2008-08-08 20:50
---
Ok, to clarify, the bootstrap issue 'has gone', but the reduced test case from
#17 still fails. Failure confirmed on i686-apple-darwin r138861.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36766
--- Comment #19 from jv244 at cam dot ac dot uk 2008-08-08 20:52 ---
Is this still an ice-on-valid-code ? I can't reproduce that here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34828
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-08 20:53 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-08 21:01 ---
*** This bug has been marked as a duplicate of 18487 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-08-08 21:01 ---
*** Bug 37064 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jv244 at cam dot ac dot uk 2008-08-08 21:06 ---
what is the 'rejects-valid' testcase here? apart from ifort, all compilers I
can access right now reject the program in the initial comment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35299
--- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca 2008-08-08
21:06 ---
Subject: Re: ICE: GNU MP: Cannot reallocate memory for
gfortran.dg/parameter_array_init_3.f90
--- Comment #19 from jv244 at cam dot ac dot uk 2008-08-08 20:52 ---
Is this still an
--- Comment #3 from jv244 at cam dot ac dot uk 2008-08-08 21:13 ---
works correctly with e.g. ifort and xlf90, so worth fixing somehow.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #4 from reichelt at gcc dot gnu dot org 2008-08-08 21:19
---
Subject: Bug 35985
Author: reichelt
Date: Fri Aug 8 21:17:54 2008
New Revision: 138886
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138886
Log:
PR c++/35985
* decl.c (xref_basetypes):
--- Comment #5 from reichelt at gcc dot gnu dot org 2008-08-08 21:22
---
Fixed on mainline.
Btw, the patch was approved here:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00194.html
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jv244 at cam dot ac dot uk 2008-08-08 21:31 ---
This turned in a rejects valid ?
pr35840.f90:1.25:
write(10,*, asynchronous=Y//E//trim(S ))
1
Error: ASYNCHRONOUS= specifier at (1) must be an initialization expression
--
jv244 at cam dot
--- Comment #6 from jv244 at cam dot ac dot uk 2008-08-08 21:38 ---
the testcase in comment #4 is working now. Is the bug still open?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
--- Comment #5 from reichelt at gcc dot gnu dot org 2008-08-08 21:40
---
I can still reproduce this on the 4.3 branch as of 2008-08-07.
On mainline the bug disappeared between 2008-07-29 and 2008-08-02.
--
reichelt at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from jv244 at cam dot ac dot uk 2008-08-08 21:43 ---
also works without problems on x86_64 (linux)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35952
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to
--- Comment #7 from dominiq at lps dot ens dot fr 2008-08-08 21:50 ---
On i686-apple-darwin9, the testcase in comment #4 gives a Bus error at -m32
(rev. 138886).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
--- Comment #3 from jv244 at cam dot ac dot uk 2008-08-08 22:15 ---
Maybe a hint from xlf90:
xlf90 test.f90
test.f90, line 3.41: 1516-045 (E) Source is longer than target. Truncation
will occur on the left.
test.f90, line 6.14: 1516-045 (E) Source is longer than target. Truncation
will
--- Comment #4 from jv244 at cam dot ac dot uk 2008-08-08 22:23 ---
this bug seems fixed in 4.4.0, should it be closed?
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #14 from jv244 at cam dot ac dot uk 2008-08-08 22:27 ---
This appears fixed on current trunk, should the bug be closed.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #6 from jv244 at cam dot ac dot uk 2008-08-08 22:33 ---
I wonder if this bug can be closed, the testcase appears to work with trunk
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
--- Comment #6 from mmitchel at gcc dot gnu dot org 2008-08-08 22:46
---
Janis --
I don't understand this PR. It sounds like this should just be closed out,
since the failures reported are long-standing, and, if necessary, new PRs
opened for the other issues reported here. Is that
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36881
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36904
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36908
--- Comment #5 from mmitchel at gcc dot gnu dot org 2008-08-08 22:50
---
The submitter indicates that a subsequent revision corrected the problem.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37014
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-08 22:52 ---
This effects more than SPU, for shared libaries, the more runtime relocations
that happen, the slower the load time (usually). Just for SPU, runtime
relocations are not supported which is why there is error here.
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-01-01 01:25 ---
*** Bug 34633 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2008-08-08 23:16 ---
Subject: Bug 28875
Author: manu
Date: Fri Aug 8 23:15:31 2008
New Revision: 138890
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138890
Log:
2008-08-08 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR 28875
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-08 23:20 ---
FIXED in GCC 4.4
Thanks for the report Behdad!
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--version
GNU C (GCC) version 4.3.2 20080808 (prerelease) [gcc-4_3-branch revision
138890] (x86_64-unknown-linux-gnu)
$ ./cc1 a.c -O2
bar
a.c: In function 'bar':
a.c:6: error: 'X' undeclared (first use in this function)
a.c:6: error: (Each undeclared identifier is reported only once
a.c:6: error
--- Comment #3 from pault at gcc dot gnu dot org 2008-08-08 23:24 ---
Subject: Bug 37011
Author: pault
Date: Fri Aug 8 23:22:51 2008
New Revision: 138891
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138891
Log:
2008-08-09 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-08-08 23:25 ---
The ICE is there still, you just don't see it:
a.c:8: confused by earlier errors, bailing out
That means there was an ICE after other errors had happened :).
--
--- Comment #4 from pault at gcc dot gnu dot org 2008-08-08 23:26 ---
Fixed as obvious.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dfranke at gcc dot gnu dot org 2008-08-08 23:28 ---
No testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37011
--- Comment #27 from manu at gcc dot gnu dot org 2008-08-08 23:33 ---
Subject: Bug 7651
Author: manu
Date: Fri Aug 8 23:32:23 2008
New Revision: 138892
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138892
Log:
2008-08-09 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR 7651
--- Comment #7 from janis at gcc dot gnu dot org 2008-08-08 23:34 ---
Mark, the tests started failing because -fdump-rtl-loop2 used to produce dump
files for all loop2_* passes. The compiler could be fixed to do that again, or
the tests mentioned here could be changed to use
--- Comment #8 from mark at codesourcery dot com 2008-08-08 23:40 ---
Subject: Re: [4.4 Regression] test failures between
revs. 134696 and 134717
janis at gcc dot gnu dot org wrote:
--- Comment #7 from janis at gcc dot gnu dot org 2008-08-08 23:34 ---
Mark, the tests
--- Comment #2 from mmitchel at gcc dot gnu dot org 2008-08-08 23:44
---
Andrew --
If indeed this is an optimization regression on other platforms, then I agree
that this should be a P2 defect. Is the optimization problem present on all
platforms with -fPIC? If not, what's a
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu
2008-08-08 23:46 ---
Subject: Re: scope of variables in statement function do not acquire rank from
host
On Fri, Aug 08, 2008 at 09:06:37PM -, jv244 at cam dot ac dot uk wrote:
--- Comment #9 from jv244
--- Comment #4 from manu at gcc dot gnu dot org 2008-08-08 23:58 ---
Subject: Bug 36901
Author: manu
Date: Fri Aug 8 23:57:19 2008
New Revision: 138893
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138893
Log:
2008-08-09 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR 36901
--- Comment #5 from manu at gcc dot gnu dot org 2008-08-08 23:59 ---
Fixed in GCC 4.4
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from manu at gcc dot gnu dot org 2008-08-09 00:32 ---
Subject: Bug 12242
Author: manu
Date: Sat Aug 9 00:30:41 2008
New Revision: 138898
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138898
Log:
2008-08-09 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #19 from manu at gcc dot gnu dot org 2008-08-09 00:35 ---
FIXED in GCC 4.4
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
While member objects are constructed or destructed, the owner object's
overloaded virtual function is called.
It may be a problem because the owner object is not fully constructed at these
stage.
I think it is correct if base class' virtual function is called because the
base object is fully
--- Comment #21 from kargl at gcc dot gnu dot org 2008-08-09 05:15 ---
(In reply to comment #19)
Is this still an ice-on-valid-code ? I can't reproduce that here.
As with Dave, I can confirm that this problem no longer occurs
on x86_64-*-freebsd. The PR can probably be closed.
--
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2008-08-09 05:20
---
I was holding this open until I back port to 4.3. I got too busy on other
stuff, so I will try this weekend.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36582
82 matches
Mail list logo
