--- Comment #4 from sezeroz at gmail dot com 2009-02-21 08:06 ---
Created an attachment (id=17337)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17337action=view)
intptr_t type check patch for libiberty configure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39065
--- Comment #6 from laurent at guerby dot net 2009-02-21 09:12 ---
Also seen on powerpc64-unknown-linux-gnu on etch with trunk
http://gcc.gnu.org/ml/gcc/2009-02/msg00302.html
Temporary workaround:
Index: libgomp/configure
--- Comment #6 from dominiq at lps dot ens dot fr 2009-02-21 09:14 ---
On powerpc-apple-darwin9 gcc-4.3.3 gives almost the same ICE:
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/va-arg-trap-1.c: In
function 'bar':
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
CC||ktietz at gcc dot gnu dot
|
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
CC||ktietz at gcc dot gnu dot
|
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
CC||ktietz at gcc dot gnu dot
|
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
CC||ktietz at gcc dot gnu dot
|
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
CC||ktietz at gcc dot gnu dot
|
--- Comment #4 from rob1weld at aol dot com 2009-02-21 10:54 ---
(In reply to comment #3)
...
There are no more coredump messages to grep for but Ada still has this:
comm: file 2 is not in sorted order
Rob
Prior to trunk revision 144331 the comm: file 2 is not in sorted order
--- Comment #7 from dominiq at lps dot ens dot fr 2009-02-21 12:31 ---
On powerpc-apple-darwin9 the test fails with -m64 as well as -m32 (default).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
--- Comment #40 from hubicka at gcc dot gnu dot org 2009-02-21 12:40
---
I happen to have compiler with statistics around:
We still need about 400MB, mostly integer constants:
c-decl.c:473 (bind) 125040: 0.0% 0:
0.0% 0: 0.0%
--- Comment #41 from rguenther at suse dot de 2009-02-21 12:50 ---
Subject: Re: [4.2/4.3/4.4 regression] Uses lots of memory when
compiling large initialized arrays
On Sat, 21 Feb 2009, hubicka at gcc dot gnu dot org wrote:
--- Comment #40 from hubicka at gcc dot gnu dot org
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-02-21 12:54
---
Patch posted.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from hubicka at gcc dot gnu dot org 2009-02-21 13:00
---
I had somehting along this lines in mind:
Index: config/i386/i386.c
===
*** config/i386/i386.c (revision 144352)
--- config/i386/i386.c (working
--- Comment #27 from rguenth at gcc dot gnu dot org 2009-02-21 13:05
---
That patch looks reasonable. Care to bootstrap/test it to settle this last P1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39226
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39233
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39241
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39242
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38922
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38957
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P2
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-21 13:16 ---
In which gcc version did this work?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39028
--- Comment #3 from jsm28 at gcc dot gnu dot org 2009-02-21 13:16 ---
Another ICE with possibly the same cause (ICEs in the same place):
int (*g(int y))[z]
{
return 0;
}
t.c:1: error: 'z' undeclared here (not in a function)
t.c:2: internal compiler error: tree check: expected
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.0
Known to work||4.2.4 4.4.0
--
aesok at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||36467
AssignedTo|unassigned at gcc dot gnu |aesok at gcc dot
--- Comment #9 from steven at gcc dot gnu dot org 2009-02-21 15:25 ---
It looks like this is some kind of quadratic insertion problem, maybe PPRE
after all. I hacked GCSE a bit to see what is going on.
I fist counted the number basic blocks and edges per function, the number of
--- Comment #28 from hjl dot tools at gmail dot com 2009-02-21 15:38
---
(In reply to comment #26)
I had somehting along this lines in mind:
Index: config/i386/i386.c
===
*** config/i386/i386.c (revision 144352)
---
--- Comment #4 from hjl at gcc dot gnu dot org 2009-02-21 15:56 ---
Subject: Bug 39256
Author: hjl
Date: Sat Feb 21 15:55:53 2009
New Revision: 144355
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144355
Log:
gcc/
2008-02-21 H.J. Lu hongjiu...@intel.com
PR
--- Comment #10 from steven at gcc dot gnu dot org 2009-02-21 16:09 ---
OK, I checked what we're PREing here. This is indeed partial-partial PRE.
I suppose something like the following is a good idea. I'll admit it's
brute-force, but I'm not sure how else to stop GCSE-PRE from doing
This meaningless testcase (reduced by delta from the real program), when
compiled with g++ 4.4 (but not 4.3), produces an ICE.
extern C int __mysetjmp () __attribute__ ((__returns_twice__));
class TContStatus {};
class TContEvent
{
public:
inline void Execute () throw();
};
class TCont
{
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-21 17:56 ---
Confirmed. IPA-CP clones the setjmp function what hits this assert.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I. -I../mpglib -I.. -Wall -pipe
-march=core2 -mtune=core2 -msse4.1 -O4 -ffast-math -floop-block
-floop-strip-mine -floop-interchange -save-temps -MT vbrquantize.lo -MD -MP -MF
.deps/vbrquantize.Tpo -c vbrquantize.c -o vbrquantize.o
gcc: warning: -pipe
--- Comment #1 from yast4ik at yahoo dot com 2009-02-21 18:22 ---
Created an attachment (id=17338)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17338action=view)
vbrquantize.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39260
--- Comment #2 from yast4ik at yahoo dot com 2009-02-21 18:39 ---
My OS is Xubuntu 8.10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39260
--- Comment #103 from rguenther at suse dot de 2009-02-21 18:42 ---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
On Sat, 21 Feb 2009, lucier at math dot purdue dot edu wrote:
--- Comment #102 from lucier at math dot purdue dot edu 2009-02-21
--- Comment #10 from jsm28 at gcc dot gnu dot org 2009-02-21 18:45 ---
This issue was discussed on the WG14 reflector in October 2008, and the general
view was that the standard should not make INT_MIN % -1 well defined (as this
would impose a significant performance cost on many
--- Comment #104 from lucier at math dot purdue dot edu 2009-02-21 18:56
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
Cool, that leaves me with
DFS = ???
SCC = ? Confict ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
With revision 144357, I got
FAIL: gcc.target/i386/avx-set-v4di-4.c (internal compiler error)
FAIL: gcc.target/i386/avx-set-v4di-4.c (test for excess errors)
FAIL: gcc.target/i386/avx-set-v4di-5.c (internal compiler error)
FAIL: gcc.target/i386/avx-set-v4di-5.c (test for excess errors)
bash-3.2$
--- Comment #105 from steven at gcc dot gnu dot org 2009-02-21 19:04
---
SCC as in SCCVN
DFS = Depth First Search
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #1 from hjl at gcc dot gnu dot org 2009-02-21 19:08 ---
Subject: Bug 39257
Author: hjl
Date: Sat Feb 21 19:08:44 2009
New Revision: 144360
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144360
Log:
Mention PR bootstrap/39257.
Modified:
trunk/gcc/ChangeLog
--
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-21 19:10 ---
Fixed as of revision 144360.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-21 19:27 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39261
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-21 19:58 ---
That assert is introduced by revision 139945:
http://gcc.gnu.org/ml/gcc-cvs/2008-09/msg00103.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39259
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-02-21
20:18 ---
This problem in darwin10 is in fact due to c++ comments in
/usr/include/Availability.h and /usr/include/AvailabilityInternal.h. Replacing
those with c style comments allows the gcc.dg/cpp/trad/include.c
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-21 20:22 ---
Revision 139945 caused this.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #23 from steven at gcc dot gnu dot org 2009-02-21 22:17 ---
What is the Assigned: field worth if nothing happens for 3 years?
How about just moving this one to SUSPENDED?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26266
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-21 22:25 ---
Confirmed, then... I've tested 3.4, 4.1, and 4.3. I suppose 4.2 is the same.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from tkoenig at gcc dot gnu dot org 2009-02-21 22:25 ---
Subject: Bug 38914
Author: tkoenig
Date: Sat Feb 21 22:25:06 2009
New Revision: 144362
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144362
Log:
2008-02-21 Thomas Koenig tkoe...@gcc.gnu.org
PR
--- Comment #24 from mmitchel at gcc dot gnu dot org 2009-02-21 22:26
---
The problem isn't the database schema; it's keeping it up to date.
I'm not actively working on this issue any more, so I've unassigned myself.
--
mmitchel at gcc dot gnu dot org changed:
What
--- Comment #106 from dberlin at gcc dot gnu dot org 2009-02-21 22:34
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
Right.
Basically, the value numbering PRE uses as a pre-pass is known as SCCVN.
It value numbers by doing a depth first
--- Comment #3 from spop at gcc dot gnu dot org 2009-02-21 23:48 ---
Subject: Re: Failed to build lame-3.98-2 source with
graphite
Reduced testcase:
VBR_encode_frame (int mode_gr, int channels_out, int max_bits[2][2])
{
int max_nbits_ch[2][2];
int gr, ch;
for (gr = 0;
--- Comment #2 from hjl at gcc dot gnu dot org 2009-02-22 00:44 ---
Subject: Bug 39261
Author: hjl
Date: Sun Feb 22 00:44:23 2009
New Revision: 144366
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144366
Log:
2008-02-21 H.J. Lu hongjiu...@intel.com
PR target/39261
--- Comment #4 from spop at gcc dot gnu dot org 2009-02-22 01:23 ---
Subject: Re: Failed to build lame-3.98-2 source with
graphite
I'm testing the attached patch on amd64-linux.
Sebastian Pop
--
AMD - GNU Tools
--- Comment #5 from spop at gcc dot gnu dot org
--- Comment #1 from rob1weld at aol dot com 2009-02-22 01:27 ---
Here are two more results.
The first is created using gmake -i check and the second with
gmake -i -k check RUNTESTFLAGS=--target_board=unix\{-m64,-m32\} .
Results for 4.4.0 20090220 (experimental) [trunk revision
--- Comment #6 from spop at gcc dot gnu dot org 2009-02-22 01:43 ---
Subject: Bug 39260
Author: spop
Date: Sun Feb 22 01:43:04 2009
New Revision: 144368
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144368
Log:
2009-02-21 Sebastian Pop sebastian@amd.com
PR
# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../miro/configure solaris2.11
Thread model: posix
gcc version 4.4.0 20080520 (experimental) [miro revision 144368] (GCC)
# gmake
...
echo timestamp s-modes-h
/usr/share/src/miro_build/./prev-gcc/xgcc
# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../miro/configure solaris2.11
Thread model: posix
gcc version 4.4.0 20080520 (experimental) [miro revision 144368] (GCC)
I am compiling using gcc ./configured with:
# gcc -v
Using built-in specs.
Target:
--- Comment #1 from ubizjak at gmail dot com 2009-02-22 07:40 ---
Rob, did you ever read http://gcc.gnu.org/bugs.html#report ?
To be honest, I don't even know _what_ are you reporting here. There is no
point to post hundreds of lines from build logs, since this is too much for
anybody
60 matches
Mail list logo
