--- Comment #2 from jsun at junsun dot net 2009-05-09 06:04 ---
We have confirmed that this problem still exists in gcc 4.3.3.
It appears other than this problem, XIP on ARM actually works. XIP on ARM also
worked fine with gcc 3.x, with -fpic -msingle-pic-base compile option.
--
--- Comment #2 from scovich at gmail dot com 2009-05-09 08:16 ---
Computed gotos can easily make it impossible for the compiler to call
constructors and destructors consistently. This is a major gotcha of computed
gotos for people who have used normal gotos in C++ and expect destructors
/home/marcus/projects/gcc.trunk/BIN/bin/gcc -c -O3 -o dplay.o dplay.i
dplay.i:44: error: missing callgraph edge for call stmt:
# .MEM_13 = VDEF .MEM_10
D.2719_6 = xcbDeletePlayerFromAllGroups ();
xDP_IF_EnumGroupsInGroup.clone.0/10(-1) [0x7fa23ece1800]: (inline copy in
xDP_IF_DestroyPlayer/3)
--- Comment #1 from marcus at jet dot franken dot de 2009-05-09 09:11
---
Created an attachment (id=17834)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17834action=view)
dplay.i
reduced testcase
gcc -c -O3 dplay.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40080
--- Comment #1 from dcb314 at hotmail dot com 2009-05-09 11:08 ---
Created an attachment (id=17835)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17835action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40081
--- Comment #16 from jv244 at cam dot ac dot uk 2009-05-09 14:57 ---
tried once running under valgrind, but that doesn't give more info, no errors
till the point of the stack overflow:
GNU Fortran (GCC) version 4.5.0 20090509 (experimental) [trunk revision 147317]
(x86_64-unknown-linux
On Linux/Intel64, revision 147294 gave:
gcc -c -o function.o -DSPEC_CPU -DNDEBUG -I. -O3 -ffast-math -funroll-loops
-DSPEC_CPU_LP64 function.c
function.c:8078: error: edge points to wrong declaration:
function_decl 0x2b1ba1268f00 do_clobber_return_reg
type function_type
On Linux/Intel64, revision 147294 gave
g++ -c -o StylesheetExecutionContextDefault.o -DSPEC_CPU -DNDEBUG
-DAPP_NO_THREADS -DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom
-Ixercesc/dom/impl -Ixercesc/sax -Ixercesc/util/MsgLoaders/InMemory
-Ixercesc/util/Transcoders/Iconv -Ixalanc/include
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-09 15:21 ---
preprocessed source?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-09 15:22 ---
preprocessed source?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from meissner at linux dot vnet dot ibm dot com 2009-05-09
15:56 ---
Subject: Re: [4.5 Regression] Power bootstrap is broken in building libstdc++
On Sat, May 09, 2009 at 02:44:29PM -, hubicka at ucw dot cz wrote:
--- Comment #3 from hubicka at ucw dot cz
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-09 16:02 ---
Created an attachment (id=17837)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17837action=view)
A testcase failed at -O3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40084
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-09 16:02 ---
Created an attachment (id=17838)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17838action=view)
A testcase failed at -O3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40083
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-09 17:57 ---
Same problem in 4.4, 4.3 and 4.2, just only the type verifier verifies this.
It's not critial (it will be treated the same as struct copies - thus it is
simply inefficient). I'll see if a fix is simple.
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-09 18:07 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jsm28 at gcc dot gnu dot org 2009-05-09 18:09 ---
gimplify_init_constructor does
tree ctor = TREE_OPERAND (*expr_p, 1);
...
new_ctor = optimize_compound_literals_in_ctor (ctor);
elts = CONSTRUCTOR_ELTS (new_ctor);
...
gimplify_init_ctor_preeval
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-09 18:09 ---
Revision 147294:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00268.html
is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-09 18:10 ---
Revision 147294:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00268.html
is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hubicka at ucw dot cz 2009-05-09 18:29 ---
Subject: Re: [4.5 Regression] ICE in purge_dead_edges, at cfgrtl.c:2274
The problem here is that combine constructs (set (pc) (pc)) as noo-op
move expecting it to be removed immediately. It is however
misinterpreted as
--- Comment #5 from hubicka at gcc dot gnu dot org 2009-05-09 18:31 ---
Subject: Bug 40082
Author: hubicka
Date: Sat May 9 18:31:32 2009
New Revision: 147319
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147319
Log:
PR bootstrap/40082
* ipa.c
--- Comment #3 from hubicka at ucw dot cz 2009-05-09 18:52 ---
Subject: Re: [4.5 Regression] error: missing callgraph edge for call stmt
Hi,
I am testing the following:
Index: cgraphunit.c
===
--- cgraphunit.c
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-05-09 20:10 ---
Subject: Bug 40080
Author: hubicka
Date: Sat May 9 20:10:37 2009
New Revision: 147320
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147320
Log:
PR middle-end/40080
* cgraphunit.c
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
--- Comment #4 from hubicka at ucw dot cz 2009-05-09 21:06 ---
Subject: Re: [4.5 Regression] Revision 147294 failed 483.xalancbmk in SPEC
CPU 2006 at -O3
Hi,
I am testing the following patch thasolves the ICE.
Problem here was that we cleated ipa-cp clone and clonning proces
allowed
Executing on host: /home/dave/gcc-4.5/objdir/./gcc/g++ -shared-libgcc
-B/home/da
ve/gcc-4.5/objdir/./gcc -nostdinc++
-L/home/dave/gcc-4.5/objdir/hppa-linux/libst
dc++-v3/src -L/home/dave/gcc-4.5/objdir/hppa-linux/libstdc++-v3/src/.libs
-B/hom
e/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/bin/
--- Comment #1 from danglin at gcc dot gnu dot org 2009-05-09 21:07 ---
The backtrace is:
(gdb) bt
#0 0x0011ddec in cp_diagnostic_starter (context=0x978844,
diagnostic=0xfe25c30c) at ../../gcc/gcc/cp/error.c:2624
#1 0x002aab28 in diagnostic_report_diagnostic (context=0x978844,
--- Comment #2 from danglin at gcc dot gnu dot org 2009-05-09 21:11 ---
The var that triggered the error is:
(gdb) p debug_tree (var)
var_decl 0x402ebb40 DW.ref.__gxx_personality_v0
type pointer_type 0x401c9700
type void_type 0x401c9690 void asm_written VOID
--- Comment #2 from ubizjak at gmail dot com 2009-05-09 21:37 ---
(In reply to comment #1)
There is no bug for current trunk. So bug fixed.
Not really, the move insn is moved to the beginning of the function:
0060 int_int:
60: 89 f8 mov%edi,%eax
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-09 22:02 ---
This is caused by revision 145494:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00115.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40074
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-09 22:10 ---
How can that be if the bug also happens on the 4.4 branch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40074
--- Comment #7 from hjl dot tools at gmail dot com 2009-05-09 22:15 ---
(In reply to comment #6)
How can that be if the bug also happens on the 4.4 branch?
The testcase in comment #4 compiles fine with gcc 4.4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40074
--- Comment #8 from hjl dot tools at gmail dot com 2009-05-09 22:31 ---
(In reply to comment #1)
Created an attachment (id=17832)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17832action=view) [edit]
Preprocessed source of source that triggers ICE
This was introduced between
--- Comment #9 from jakub at gcc dot gnu dot org 2009-05-09 22:54 ---
The original testcase failure fails with both 4.4.x and trunk and was
introduced between 138524 and 138811. The reduced testcase only fails on the
trunk, not on the 4.4 branch.
--
With revision 147269 this test passed.
From revision 147274 and on, this test has failed as follows:
Running /tmp/rforall_1b/gcc/gcc/testsuite/gfortran.dg/dg.exp ...
...
FAIL: gfortran.dg/forall_1.f90 -O1 execution test
With the message in the logfile being:
Executing on host:
--- Comment #1 from hp at gcc dot gnu dot org 2009-05-09 23:02 ---
Seen for cris-elf too.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from hp at gcc dot gnu dot org 2009-05-10 00:04 ---
Created an attachment (id=17839)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17839action=view)
slightly reduced test-case
It's the second abort call that's executed, but removing the first causes the
test to
--- Comment #10 from jakub at gcc dot gnu dot org 2009-05-10 00:08 ---
r138553 in particular. -O2 -ftree-vectorize -m32 -msse2 is needed to reproduce
it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40074
--- Comment #11 from hjl dot tools at gmail dot com 2009-05-10 00:23
---
It is caused by revision 138553:
http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg00112.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40074
--- Comment #12 from dougkwan at google dot com 2009-05-10 00:56 ---
Created an attachment (id=17840)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17840action=view)
C test-case for the same problem on x86_64 and i386.
The original C++ test-case does not crash on x86_64 and i386.
--- Comment #6 from meissner at linux dot vnet dot ibm dot com 2009-05-10
01:05 ---
Subject: Re: [4.5 Regression] Power bootstrap is broken in building libstdc++
On Sat, May 09, 2009 at 02:44:29PM -, hubicka at ucw dot cz wrote:
--- Comment #3 from hubicka at ucw dot cz
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-05-10
01:11 ---
Created an attachment (id=17841)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17841action=view)
inherit dllexport from class to typeinfo
Now testing a solution based on the approach of adding the
--- Comment #6 from billingd at gcc dot gnu dot org 2009-05-10 01:15
---
Subject: Bug 38956
Author: billingd
Date: Sun May 10 01:14:50 2009
New Revision: 147326
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147326
Log:
2009-04-10 David Billinghurst billi...@gcc.gnu.org
This is gcc-4.3.3 in Gentoo, compiled with CHOST=i686-pc-linux-gnu and the
configure arguments:
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.3
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.3/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.3
--- Comment #1 from markus at cs dot wisc dot edu 2009-05-10 01:41 ---
Created an attachment (id=17842)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17842action=view)
reverse.c
(The strange usage of pointers is there since I found the bug in C++ code, but
noticed it's present in
--- Comment #2 from markus at cs dot wisc dot edu 2009-05-10 01:44 ---
`gcc -O1 reverse.c -o reverse -Wall objdump -d reverse`
[...]
08048470 reverse:
8048470: 55 push %ebp
8048471: 89 e5 mov%esp,%ebp
8048473: 53
--- Comment #3 from markus at cs dot wisc dot edu 2009-05-10 01:48 ---
Sorry, but there's one last thing. Here's the output I get with -O1.
1 2 3 4 5 6 7 8
8 7 6 5 4 3 2 1
and with -O2:
1 2 3 4 5 6 7 8
8 7 6 4 5 3 2 1
--
--- Comment #3 from matz at gcc dot gnu dot org 2009-05-10 01:54 ---
I haven't analyzed this one, but only because I've found that particular
testcase also failing before expand from SSA, e.g:
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg02860.html
--- Comment #13 from matz at gcc dot gnu dot org 2009-05-10 02:09 ---
Created an attachment (id=17843)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17843action=view)
type-correct version
This is a type-corrected version of the same C testcase. Two structs are
different types
--- Comment #7 from billingd at gcc dot gnu dot org 2009-05-10 03:36
---
Subject: Bug 38956
Author: billingd
Date: Sun May 10 03:35:53 2009
New Revision: 147327
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147327
Log:
2009-04-10 David Billinghurst billi...@gcc.gnu.org
--- Comment #8 from billingd at gcc dot gnu dot org 2009-05-10 03:38
---
Fixed on trunk and 4.4 branch.
--
billingd at gcc dot gnu dot org changed:
What|Removed |Added
When a std::ostringstream object is created, it references a locale object
which is synchronized by a global mutex.
This causes a significant performance problem for multi-threaded applications
running on systems with many CPU's if they use string streams frequently.
--
Summary:
--- Comment #4 from dannysmith at users dot sourceforge dot net 2009-05-10
05:01 ---
(In reply to comment #3)
Created an attachment (id=17841)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17841action=view) [edit]
inherit dllexport from class to typeinfo
Now testing a
52 matches
Mail list logo
