[Bug target/28194] R_ARM_GOTOFF32 breaks execute-in-place
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28194
[Bug middle-end/37722] destructors not called on computed goto
--- 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 to be
handled properly. Consider this program, for instance:
#include stdio.h
templateint i
struct foo {
foo() { printf(%s%d\n, __FUNCTION__, i); }
~foo() { printf(%s%d\n, __FUNCTION__, i); }
};
enum {RETRY, INSIDE, OUTSIDE, EVIL};
int bar(int idx) {
static void* const gotos[] = {RETRY, INSIDE, OUTSIDE, EVIL};
bool first = true;
{
RETRY:
foo1 f1;
if(first) {
first = false;
goto *gotos[idx];
}
INSIDE:
return 1;
}
if(0) {
foo2 f2;
EVIL:
return 2;
}
OUTSIDE:
return 0;
}
int main() {
for(int i=RETRY; i = EVIL; i++)
printf(%d\n, bar(i));
return 0;
}
Not only does it let you jump out of a block without calling destructors, it
lets you jump into one without calling constructors:
$ g++-4.4.0 -Wall -O3 scratch.cpp ./a.out
foo1
foo1
~foo1
1
foo1
~foo1
1
foo1
0
foo1
~foo2
2
Ideally, the compiler could analyze possible destinations of the goto
(best-effort, of course) and emit suitable diagnostics:
scratch.cpp:16: warning: computed goto bypasses destructor of 'foo1 f1'
scratch.cpp:13: warning: declared here
scratch.cpp:23: warning: possible jump to label 'EVIL'
scratch.cpp:16: warning: from here
scratch.cpp:22: warning: crosses initialization of 'foo2 f2'
In this particular example the compiler should be able to figure out that no
labels reach a live f1 and call its destructor properly. If it's not feasible
to analyze the possible destinations of the computed goto, regular control flow
analysis should at least be able to identify potentially dangerous labels and
gotos, e.g.:
scratch.cpp:16: warning: computed goto may bypass destructor of 'foo1 f1'
scratch.cpp:13: warning: declared here
scratch.cpp:23: warning: jump to label 'EVIL'
scratch.cpp:8: warning: using a computed goto
scratch.cpp:22: warning: may cross initialization of 'foo2 f2'
--
scovich at gmail dot com changed:
What|Removed |Added
CC||scovich at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37722
[Bug middle-end/40080] New: error: missing callgraph edge for call stmt
/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) (clone of xDP_IF_EnumGroupsInGroup.clone.0/8) availability:local 38 insns body local finalized inlinable called by: xcbDeletePlayerFromAllGroups/9 (9.18 per call) (inlined) calls: ff/4 (9.18 per call) dplay.i:44: internal compiler error: verify_cgraph_node failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: error: missing callgraph edge for call stmt Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de 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=40080
[Bug middle-end/40080] error: missing callgraph edge for call stmt
--- 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
[Bug c++/40081] verify_stmts failed with -O2
--- 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
[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
--- 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-gnu) compiled by GNU C version 4.5.0 20090509 (experimental) [trunk revision 147317], GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ==27399== Stack overflow in thread 1: can't grow stack to 0x7FE801FF8 ==27399== Can't extend stack to 0x7FE801700 during signal delivery for thread 1: ==27399== no stack segment ==27399== ==27399== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==27399== Access not within mapped region at address 0x7FE801700 ==27399==at 0x529DC8: gt_ggc_mx_lang_tree_node (gt-fortran-f95-lang.h:46) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
[Bug middle-end/40083] New: [4.5 Regression] 403.gcc in SPEC CPU 2006 failed at -O3
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 0x2b1ba0f45e40 type void_type 0x2b1ba0b0b3c0 void VOID align 8 symtab 0 alias set -1 canonical type 0x2b1ba0b0b3c0 pointer_to_this pointer_type 0x2b1ba0b0b480 QI size integer_cst 0x2b1ba0aec7e0 constant 8 unit size integer_cst 0x2b1ba0aec810 constant 1 align 8 symtab 0 alias set -1 canonical type 0x2b1ba0f45f00 arg-types tree_list 0x2b1ba113af90 value pointer_type 0x2b1ba0c5e6c0 rtx chain tree_list 0x2b1ba113af60 value pointer_type 0x2b1ba0b0b480 chain tree_list 0x2b1ba0b099f0 value void_type 0x2b1ba0b0b3c0 void pointer_to_this pointer_type 0x2b1ba0f420c0 addressable used nothrow static decl_5 QI file function.c line 6764 col 1 align 8 initial block 0x2b1ba1543060 arguments parm_decl 0x2b1ba102ba20 reg type pointer_type 0x2b1ba0c5e6c0 rtx type record_type 0x2b1ba0c5e3c0 rtx_def sizes-gimplified public unsigned DI size integer_cst 0x2b1ba0aecb70 constant 64 unit size integer_cst 0x2b1ba0aecba0 constant 8 align 64 symtab 0 alias set -1 canonical type 0x2b1ba0c5e540 pointer_to_this pointer_type 0x2b1ba1021000 used unsigned DI file function.c line 6765 col 10 size integer_cst 0x2b1ba0aecb70 64 unit size integer_cst 0x2b1ba0aecba0 8 align 64 context function_decl 0x2b1ba1268f00 do_clobber_return_reg arg-type pointer_type 0x2b1ba0c5e6c0 rtx chain parm_decl 0x2b1ba102bab0 arg type pointer_type 0x2b1ba0b0b480 used unsigned DI file function.c line 6766 col 12 size integer_cst 0x2b1ba0aecb70 64 unit size integer_cst 0x2b1ba0aecba0 8 align 64 context function_decl 0x2b1ba1268f00 do_clobber_return_reg attributes tree_list 0x2b1ba122c630 arg-type pointer_type 0x2b1ba0b0b480 result result_decl 0x2b1ba1542500 D.19286 type void_type 0x2b1ba0b0b3c0 void ignored VOID file function.c line 6765 col 6 align 8 context function_decl 0x2b1ba1268f00 do_clobber_return_reg saved-insns 0x2b1ba102bb40 chain function_decl 0x2b1ba126b000 do_use_return_reg Instead of: function_decl 0x2b1ba126b000 do_use_return_reg type function_type 0x2b1ba0f45e40 type void_type 0x2b1ba0b0b3c0 void VOID align 8 symtab 0 alias set -1 canonical type 0x2b1ba0b0b3c0 pointer_to_this pointer_type 0x2b1ba0b0b480 QI size integer_cst 0x2b1ba0aec7e0 constant 8 unit size integer_cst 0x2b1ba0aec810 constant 1 align 8 symtab 0 alias set -1 canonical type 0x2b1ba0f45f00 arg-types tree_list 0x2b1ba113af90 value pointer_type 0x2b1ba0c5e6c0 rtx chain tree_list 0x2b1ba113af60 value pointer_type 0x2b1ba0b0b480 chain tree_list 0x2b1ba0b099f0 value void_type 0x2b1ba0b0b3c0 void pointer_to_this pointer_type 0x2b1ba0f420c0 addressable used nothrow static decl_5 QI file function.c line 6789 col 1 align 8 initial block 0x2b1ba1543480 arguments parm_decl 0x2b1ba102bd80 reg type pointer_type 0x2b1ba0c5e6c0 rtx type record_type 0x2b1ba0c5e3c0 rtx_def sizes-gimplified public unsigned DI size integer_cst 0x2b1ba0aecb70 constant 64 unit size integer_cst 0x2b1ba0aecba0 constant 8 align 64 symtab 0 alias set -1 canonical type 0x2b1ba0c5e540 pointer_to_this pointer_type 0x2b1ba1021000 used unsigned DI file function.c line 6790 col 10 size integer_cst 0x2b1ba0aecb70 64 unit size integer_cst 0x2b1ba0aecba0 8 align 64 context function_decl 0x2b1ba126b000 do_use_return_reg arg-type pointer_type 0x2b1ba0c5e6c0 rtx chain parm_decl 0x2b1ba102be10 arg type pointer_type 0x2b1ba0b0b480 used unsigned DI file function.c line 6791 col 12 size integer_cst 0x2b1ba0aecb70 64 unit size integer_cst 0x2b1ba0aecba0 8 align 64 context function_decl 0x2b1ba126b000 do_use_return_reg attributes tree_list 0x2b1ba1228570 arg-type pointer_type 0x2b1ba0b0b480 result result_decl 0x2b1ba1542c80 D.19311 type void_type 0x2b1ba0b0b3c0 void ignored VOID file function.c line 6790 col 6 align 8 context function_decl 0x2b1ba126b000 do_use_return_reg saved-insns 0x2b1ba102bea0 chain var_decl 0x2b1ba125a1e0 outer_function_chain specmake[3]: *** [function.o] Error 1 -- Summary: [4.5 Regression] 403.gcc in SPEC CPU 2006 failed at -O3 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com
[Bug middle-end/40084] New: [4.5 Regression] 483.xalancbmk in SPEC CPU 2006 failed at -O3
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 -DPROJ_XMLPARSER -DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 -DPROJ_DOM -DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -O3 -ffast-math -funroll-loops -DSPEC_CPU_LP64 -DSPEC_CPU_LINUX StylesheetExecutionContextDefault.cpp In file included from DOMAttrImpl.cpp:67: xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNode* xercesc_2_5::castToNode(const xercesc_2_5::DOMParentNode*)': xercesc/dom/DOMCasts.hpp:148: warning: invalid access to non-static data member 'xercesc_2_5::DOMElementImpl::fParent' of NULL object xercesc/dom/DOMCasts.hpp:148: warning: (perhaps the 'offsetof' macro was used incorrectly) xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNode* xercesc_2_5::castToNode(const xercesc_2_5::DOMNodeImpl*)': xercesc/dom/DOMCasts.hpp:154: warning: invalid access to non-static data member 'xercesc_2_5::DOMElementImpl::fNode' of NULL object xercesc/dom/DOMCasts.hpp:154: warning: (perhaps the 'offsetof' macro was used incorrectly) xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNodeImpl* xercesc_2_5::castToNodeImpl(const xercesc_2_5::DOMParentNode*)': xercesc/dom/DOMCasts.hpp:162: warning: invalid access to non-static data member 'xercesc_2_5::DOMElementImpl::fNode' of NULL object xercesc/dom/DOMCasts.hpp:162: warning: (perhaps the 'offsetof' macro was used incorrectly) xercesc/dom/DOMCasts.hpp:163: warning: invalid access to non-static data member 'xercesc_2_5::DOMElementImpl::fParent' of NULL object xercesc/dom/DOMCasts.hpp:163: warning: (perhaps the 'offsetof' macro was used incorrectly) In file included from DOMAttrMapImpl.cpp:68: xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNode* xercesc_2_5::castToNode(const xercesc_2_5::DOMParentNode*)': xercesc/dom/DOMCasts.hpp:148: warning: invalid access to non-static data member 'xercesc_2_5::DOMElementImpl::fParent' of NULL object xercesc/dom/DOMCasts.hpp:148: warning: (perhaps the 'offsetof' macro was used incorrectly) xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNode* xercesc_2_5::castToNode(const xercesc_2_5::DOMNodeImpl*)': xercesc/dom/DOMCasts.hpp:154: warning: invalid access to non-static data member 'xercesc_2_5::DOMElementImpl::fNode' of NULL object xercesc/dom/DOMCasts.hpp:154: warning: (perhaps the 'offsetof' macro was used incorrectly) xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNodeImpl* xercesc_2_5::castToNodeImpl(const xercesc_2_5::DOMParentNode*)': xercesc/dom/DOMCasts.hpp:162: warning: invalid access to non-static data member 'xercesc_2_5::DOMElementImpl::fNode' of NULL object xercesc/dom/DOMCasts.hpp:162: warning: (perhaps the 'offsetof' macro was used incorrectly) xercesc/dom/DOMCasts.hpp:163: warning: invalid access to non-static data member 'xercesc_2_5::DOMElementImpl::fParent' of NULL object xercesc/dom/DOMCasts.hpp:163: warning: (perhaps the 'offsetof' macro was used incorrectly) In file included from DOMCDATASectionImpl.cpp:65: xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNode* xercesc_2_5::castToNode(const xercesc_2_5::DOMParentNode*)': xercesc/dom/DOMCasts.hpp:148: warning: invalid access to non-static data member 'xercesc_2_5::DOMElementImpl::fParent' of NULL object xercesc/dom/DOMCasts.hpp:148: warning: (perhaps the 'offsetof' macro was used incorrectly) xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNode* xercesc_2_5::castToNode(const xercesc_2_5::DOMNodeImpl*)': xercesc/dom/DOMCasts.hpp:154: warning: invalid access to non-static data member 'xercesc_2_5::DOMElementImpl::fNode' of NULL object xercesc/dom/DOMCasts.hpp:154: warning: (perhaps the 'offsetof' macro was used incorrectly) xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNodeImpl* xercesc_2_5::castToNodeImpl(const xercesc_2_5::DOMParentNode*)': xercesc/dom/DOMCasts.hpp:162: warning: invalid access to non-static data member 'xercesc_2_5::DOMElementImpl::fNode' of NULL object xercesc/dom/DOMCasts.hpp:162: warning: (perhaps the 'offsetof' macro was used incorrectly) xercesc/dom/DOMCasts.hpp:163: warning: invalid access to non-static data member 'xercesc_2_5::DOMElementImpl::fParent' of NULL object xercesc/dom/DOMCasts.hpp:163: warning: (perhaps the 'offsetof' macro was used incorrectly) In file included from DOMCharacterDataImpl.cpp:66: xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNode* xercesc_2_5::castToNode(const xercesc_2_5::DOMParentNode*)': xercesc/dom/DOMCasts.hpp:148: warning: invalid access to non-static data member 'xercesc_2_5::DOMElementImpl::fParent' of NULL object xercesc/dom/DOMCasts.hpp:148: warning: (perhaps the 'offsetof' macro was used incorrectly) xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNode*
[Bug middle-end/40083] [4.5 Regression] 403.gcc in SPEC CPU 2006 failed at -O3
--- 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 CC||hubicka at gcc dot gnu dot ||org Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40083
[Bug middle-end/40084] [4.5 Regression] 483.xalancbmk in SPEC CPU 2006 failed at -O3
--- 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 CC||hubicka at gcc dot gnu dot ||org Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40084
[Bug bootstrap/40082] [4.5 Regression] Power bootstrap is broken in building libstdc++
--- 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 2009-05-09 14:44 --- Subject: Re: [4.5 Regression] Power bootstrap is broken in building libstdc++ Hi, I am testing the attached patch. It makes testcase to compile, does it solve bootstrap issues too? I just fired off a bootstrap, and will let you know when I get back to the computer in a few hours. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40082
[Bug middle-end/40084] [4.5 Regression] 483.xalancbmk in SPEC CPU 2006 failed at -O3
--- 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
[Bug middle-end/40083] [4.5 Regression] 403.gcc in SPEC CPU 2006 failed at -O3
--- 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
[Bug tree-optimization/40081] verify_stmts failed with -O2
--- 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. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Known to fail||4.3.3 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40081
[Bug tree-optimization/40081] verify_stmts failed with -O2
--- 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 AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-05-09 13:34:34 |2009-05-09 18:07:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40081
[Bug middle-end/40026] [4.5 Regression] ICE during gimplify_init_constructor
--- 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 (TREE_OPERAND (*expr_p, 1), pre_p, post_p, preeval_data); (which changes a COND_EXPR to have void type, updating the pointer to that COND_EXPR in TREE_OPERAND (*expr_p, 1) - the old constructor - to point to the gimplifier-generated temorary instead) ... if (!cleared || num_nonzero_elements 0) gimplify_init_ctor_eval (object, elts, pre_p, cleared); (which goes through the elements of the new constructor, finds the modified COND_EXPR and ends up segfaulting because of that). This looks like the compound literal changes must be responsible and that it is a gimplifier bug. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-09 18:09:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40026
[Bug middle-end/40084] [4.5 Regression] Revision 147294 failed 483.xalancbmk in SPEC CPU 2006 at -O3
--- 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 Summary|[4.5 Regression]|[4.5 Regression] Revision |483.xalancbmk in SPEC CPU |147294 failed 483.xalancbmk |2006 failed at -O3 |in SPEC CPU 2006 at -O3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40084
[Bug middle-end/40083] [4.5 Regression] Revision 147294 failed 403.gcc in SPEC CPU 2006 at -O3
--- 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 Summary|[4.5 Regression] 403.gcc in|[4.5 Regression] Revision |SPEC CPU 2006 failed at -O3 |147294 failed 403.gcc in ||SPEC CPU 2006 at -O3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40083
[Bug middle-end/39886] [4.5 Regression] ICE in purge_dead_edges, at cfgrtl.c:2274
--- 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 jump that is giong to be removed at the end of BB and update_cfg_for_uncondjump add FALLTHRU flag on the edge that fails in verification. Interestingly enough modifying update_cfg_for_uncondjump to ignore insns that are not last in BB seem to cause miscompilations in testsuite I am looking into the cgraph failures now, but this should be easy to fix. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39886
[Bug bootstrap/40082] [4.5 Regression] Power bootstrap is broken in building libstdc++
--- 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 (update_inlined_to_pointer): New function. (cgraph_remove_unreachable_nodes): Use it. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40082
[Bug middle-end/40080] [4.5 Regression] error: missing callgraph edge for call stmt
--- 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(revision 147319)
+++ cgraphunit.c(working copy)
@@ -1762,7 +1762,12 @@ cgraph_materialize_all_clones (void)
for (e = node-callees; e; e = e-next_callee)
{
tree decl = gimple_call_fndecl (e-call_stmt);
- if (decl != e-callee-decl)
+ /* When function gets inlined, indirect inlining might've invented
+ new edge for orginally indirect stmt. Since we are not
+ preserving clones in the original form, we must not update here
+ since other inline clones don't need to contain call to the same
+ call. Inliner will do the substitution for us later. */
+ if (decl decl != e-callee-decl)
{
gimple new_stmt;
gimple_stmt_iterator gsi;
@@ -1808,6 +1813,9 @@ cgraph_materialize_all_clones (void)
verify_cgraph_node (node);
#endif
}
+#ifdef ENABLE_CHECKING
+ verify_cgraph ();
+#endif
cgraph_remove_unreachable_nodes (false, cgraph_dump_file);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40080
[Bug middle-end/40080] [4.5 Regression] error: missing callgraph edge for call stmt
--- 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 (cgraph_materialize_all_clones): Do not redirect indirect calls; verify cgraph afterwards. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40080
[Bug fortran/39996] Double typing of function results not detected
-- 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 | Status|NEW |ASSIGNED Last reconfirmed|2009-05-05 20:35:34 |2009-05-09 20:53:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39996
[Bug middle-end/40084] [4.5 Regression] Revision 147294 failed 483.xalancbmk in SPEC CPU 2006 at -O3
--- 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 devirtualization that however creates new dirrect call and
callgraph is not properly updated.
We should handle devirtualization when inlining or const propagating,
this seems common case. We seem to miss here number of inlining
oppurtunities.
Honza
Index: tree-inline.c
===
--- tree-inline.c (revision 147320)
+++ tree-inline.c (working copy)
@@ -1522,7 +1522,8 @@ copy_bb (copy_body_data *id, basic_block
gcc_assert (dest-needed || !dest-analyzed);
if (id-transform_call_graph_edges == CB_CGE_MOVE_CLONES)
cgraph_create_edge_including_clones (id-dst_node, dest,
stmt,
- bb-count,
CGRAPH_FREQ_BASE,
+ bb-count,
+
compute_call_stmt_bb_frequency (id-dst_node-decl, bb),
bb-loop_depth,
CIF_ORIGINALLY_INDIRECT_CALL);
else
@@ -3535,8 +3536,9 @@ fold_marked_statements (int first, struc
if (BASIC_BLOCK (first))
{
gimple_stmt_iterator gsi;
+ basic_block bb = BASIC_BLOCK (first);
- for (gsi = gsi_start_bb (BASIC_BLOCK (first));
+ for (gsi = gsi_start_bb (bb);
!gsi_end_p (gsi);
gsi_next (gsi))
if (pointer_set_contains (statements, gsi_stmt (gsi)))
@@ -3545,14 +3547,26 @@ fold_marked_statements (int first, struc
if (fold_stmt (gsi))
{
+ tree decl;
+
/* Re-read the statement from GSI as fold_stmt() may
have changed it. */
gimple new_stmt = gsi_stmt (gsi);
update_stmt (new_stmt);
- if (is_gimple_call (old_stmt))
- cgraph_update_edges_for_call_stmt (old_stmt, new_stmt);
+ if (is_gimple_call (new_stmt)
+ (decl = gimple_call_fndecl (new_stmt)))
+ {
+ struct cgraph_node *node = cgraph_node
(current_function_decl);
+ if (cgraph_edge (node, old_stmt))
+ cgraph_update_edges_for_call_stmt (old_stmt, new_stmt);
+ else
+ cgraph_create_edge_including_clones
+ (node, cgraph_node (decl), new_stmt, bb-count,
+ compute_call_stmt_bb_frequency
(current_function_decl, bb),
+ bb-loop_depth, CIF_ORIGINALLY_INDIRECT_CALL);
+}
if (maybe_clean_or_replace_eh_stmt (old_stmt, new_stmt))
gimple_purge_dead_eh_edges (BASIC_BLOCK (first));
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40084
[Bug c++/40085] New: ICE compiling libmudflap.c++/fail24-frag.cxx
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/
-B/home/dave/opt/gnu/gcc/gcc-4.5.0/
hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/include
-is
ystem /home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/sys-include -ggdb3
-DDEBUG_ASS
ERT -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections
-fdata-secti
ons -g -O2 -D_GNU_SOURCE -I/home/dave/gcc-4.5/gcc/libmudflap/testsuite
-I/home/d
ave/gcc-4.5/gcc/libmudflap/testsuite/.. -I.. -nostdinc++
-I/home/dave/gcc-4.5/ob
jdir/hppa-linux/libstdc++-v3/include/hppa-linux
-I/home/dave/gcc-4.5/objdir/hppa
-linux/libstdc++-v3/include -I/home/dave/gcc-4.5/gcc/libstdc++-v3/libsupc++
-I/h
ome/dave/gcc-4.5/gcc/libstdc++-v3/include/backward
-I/home/dave/gcc-4.5/gcc/libs
tdc++-v3/testsuite/util
-L/home/dave/gcc-4.5/objdir/hppa-linux/./libmudflap/.lib
s /home/dave/gcc-4.5/gcc/libmudflap/testsuite/libmudflap.c++/fail24-frag.cxx
-
fmudflap -lmudflap
-L/home/dave/gcc-4.5/objdir/hppa-linux/./libmudflap/testsuit
e -ldl -lm -o ./fail24-frag.exe(timeout = 300)
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html for instructions.
compiler exited with status 1
output is:
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html for instructions.
FAIL: libmudflap.c++/fail24-frag.cxx (test for excess errors)
The ICE occurs here:
Program received signal SIGSEGV, Segmentation fault.
0x0011ddec in cp_diagnostic_starter (context=0x978844, diagnostic=0xfe25c30c)
at ../../gcc/gcc/cp/error.c:2624
2624 if (DECL_FUNCTION_MEMBER_P (fn))
It seems DECL_LANG_SPECIFIC (fn) is NULL:
(gdb) p debug_tree ($r3)
function_decl 0x402dff80 _GLOBAL__I_00099_0_zoo
type function_type 0x401cf150
type void_type 0x401c9690 void asm_written VOID
align 8 symtab 0 alias set -1 canonical type 0x401c9690
pointer_to_this pointer_type 0x401c9700
SI
size integer_cst 0x401b2560 constant 32
unit size integer_cst 0x401b2300 constant 4
align 32 symtab 0 alias set -1 canonical type 0x401cf150
arg-types tree_list 0x401b2b20 value void_type 0x401c9690 void
pointer_to_this pointer_type 0x402c6930
used static SI file
/home/dave/gcc-4.5/gcc/libmudflap/testsuite/libmudflap.c++/fail24-frag.cxx line
12 col 1 align 32 initial block 0x402ecbd0
result result_decl 0x402898f0 D.2369 type void_type 0x401c9690 void
VOID file
/home/dave/gcc-4.5/gcc/libmudflap/testsuite/libmudflap.c++/fail24-frag.cxx line
12 col 1
align 8 context function_decl 0x402dff80 _GLOBAL__I_00099_0_zoo
saved-insns 0x402899f8
(gdb) p ((tree)$r3)-decl_common
$13 = {common = {common = {base = {code = FUNCTION_DECL,
side_effects_flag = 0, constant_flag = 0, addressable_flag = 0,
volatile_flag = 0, readonly_flag = 0, unsigned_flag = 0,
asm_written_flag = 0, nowarning_flag = 0, used_flag = 1,
nothrow_flag = 0, static_flag = 1, public_flag = 0, private_flag = 0,
protected_flag = 0, deprecated_flag = 0, saturating_flag = 0,
default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0,
lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0,
lang_flag_6 = 0, visited = 0, spare = 0, ann = 0x0}, chain = 0x0,
type = 0x401cf150}, locus = 1317191, uid = 2368, name = 0x402ecb98,
context = 0x0}, size = 0x0, mode = SImode, nonlocal_flag = 0,
virtual_flag = 0, ignored_flag = 0, abstract_flag = 0, artificial_flag = 1,
user_align = 0, preserve_flag = 0, debug_expr_is_from = 0, lang_flag_0 = 0,
lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0,
lang_flag_5 = 0, lang_flag_6 = 0, lang_flag_7 = 0, decl_flag_0 = 0,
decl_flag_1 = 0, decl_flag_2 = 0, decl_flag_3 = 0, gimple_reg_flag = 0,
no_tbaa_flag = 0, decl_by_reference_flag = 0, decl_common_unused = 0,
off_align = 0, size_unit = 0x0, initial = 0x402ecbd0, attributes = 0x0,
abstract_origin = 0x0, align = 32, pointer_alias_set = -1,
lang_specific = 0x0}
--
Summary: ICE compiling libmudflap.c++/fail24-frag.cxx
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
GCC build triplet: hppa-unknown-linux-gnu
GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40085
[Bug c++/40085] ICE compiling libmudflap.c++/fail24-frag.cxx
--- 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, diagnostic=0xfe25c30c) at ../../gcc/gcc/diagnostic.c:415 #2 0x002aae20 in internal_error (gmsgid=value optimized out) at ../../gcc/gcc/diagnostic.c:670 #3 0x002aae6c in fancy_abort (file=value optimized out, line=1167, function=0x882480 expand_one_var) at ../../gcc/gcc/diagnostic.c:724 #4 0x00702e00 in expand_one_var (var=0x402ebb40, toplevel=1 '\001', really_expand=1 '\001') at ../../gcc/gcc/cfgexpand.c:1160 #5 0x00706a54 in gimple_expand_cfg () at ../../gcc/gcc/cfgexpand.c:1535 #6 0x00449758 in execute_one_pass (pass=0x964730) at ../../gcc/gcc/passes.c:1291 #7 0x00449a14 in execute_pass_list (pass=0x964730) at ../../gcc/gcc/passes.c:1340 #8 0x00557d44 in tree_rest_of_compilation (fndecl=0x402dff80) at ../../gcc/gcc/tree-optimize.c:394 #9 0x0069a68c in cgraph_add_new_function (fndecl=0x402dff80, lowered=0 '\0') at ../../gcc/gcc/cgraph.c:1830 #10 0x0069c390 in cgraph_build_static_cdtor (which=73 'I', body=0x402ee040, priority=99) at ../../gcc/gcc/cgraphunit.c:1463 #11 0x001cb53c in mudflap_finish_file () at ../../gcc/gcc/tree-mudflap.c:1328 #12 0x00503c48 in toplev_main (argc=49, argv=0xfe25bb48) ---Type return to continue, or q return to quit--- at ../../gcc/gcc/toplev.c:1054 #13 0x4056693c in __libc_start_main (ma...@0x96a55a: 0x21e914 main, argc=49, ubp_av=0xfe25bb48, init=error reading variable, fi...@0x968192: 0x96a61c, rtld_fi...@0x401a867a: 0x40197ed8 _dl_fini, stack_end=0xfe25bd80) at libc-start.c:251 #14 0x00067398 in _start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40085
[Bug c++/40085] ICE compiling libmudflap.c++/fail24-frag.cxx
--- 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 align 8 symtab 0 alias set -1 canonical type 0x401c9690 pointer_to_this pointer_type 0x401c9700 asm_written public unsigned SI size integer_cst 0x401b2560 constant 32 unit size integer_cst 0x401b2300 constant 4 align 32 symtab 1076204584 alias set 5 canonical type 0x401c9700 pointer_to_this pointer_type 0x401cf0e0 reference_to_this reference_type 0x401cde00 public unsigned ignored weak SI file /home/dave/gcc-4.5/gcc/libmudflap/testsuite/libmudflap.c++/fail24-frag.cxx line 12 col 1 size integer_cst 0x401b2560 32 unit size integer_cst 0x401b2300 4 align 32 initial var_decl 0x402ebb40 DW.ref.__gxx_personality_v0 (mem/f/i:SI (symbol_ref/i:SI (DW.ref.__gxx_personality_v0) [flags 0x200] var_decl 0x402ebb40 DW.ref.__gxx_personality_v0) [5 DW.ref.__gxx_personality_v0+0 S4 A32]) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40085
[Bug target/40072] Nonoptimal code - CMOVxx %eax,%edi; mov %edi,%eax; retq
--- 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 62: 83 ff 08cmp$0x8,%edi 65: ba 00 00 00 00 mov$0x0,%edx 6a: 0f 4d c2cmovge %edx,%eax 6d: c3 retq -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40072
[Bug tree-optimization/40074] [4.4/4.5 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:944
--- 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
[Bug tree-optimization/40074] [4.4/4.5 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:944
--- 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
[Bug tree-optimization/40074] [4.4/4.5 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:944
--- 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
[Bug tree-optimization/40074] [4.4/4.5 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:944
--- 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 revisions 138059 and 13934. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40074
[Bug tree-optimization/40074] [4.4/4.5 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:944
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40074
[Bug rtl-optimization/40086] New: [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution
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: /tmp/rforall_1b/gccobj/gcc/testsuite/gfortran/../../gfortran -B/tmp/rforall_1b/gccobj/gcc/testsuite/gfortran/../../ /tmp/rforall_1b/gcc/gcc/testsuite/gfortran.dg/forall_1.f90 -O1 -pedantic-errors -isystem /tmp/rforall_1b/gccobj/cris-elf/./newlib/targ-include -isystem /tmp/rforall_1b/gcc/newlib/libc/include -B/tmp/rforall_1b/gccobj/cris-elf/./libgloss/cris/ -L/tmp/rforall_1b/gccobj/cris-elf/./libgloss/cris -L/tmp/rforall_1b/gcc/libgloss/cris -B/tmp/rforall_1b/gccobj/cris-elf/./newlib/ -L/tmp/rforall_1b/gccobj/cris-elf/./newlib -sim3 -B/tmp/rforall_1b/gccobj/cris-elf/./libgfortran/.libs -L/tmp/rforall_1b/gccobj/cris-elf/./libgfortran/.libs -L/tmp/rforall_1b/gccobj/cris-elf/./libiberty -lm -o ./forall_1.exe (timeout = 300) PASS: gfortran.dg/forall_1.f90 -O1 (test for excess errors) program stopped with signal 6. FAIL: gfortran.dg/forall_1.f90 -O1 execution test (that is, abort is called) Author of patches in suspect revision range CC:ed. -- Summary: [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: cris-axis-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40086
[Bug middle-end/40079] [4.5 Regression] Revision 147294 caused extra failures
--- 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||hp at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-09 23:02:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40079
[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution
--- 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 pass. Here's a slightly reduced case, removing the parts after the abort call. Tell me if you need further assistance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40086
[Bug tree-optimization/40074] [4.4/4.5 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:944
--- 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
[Bug tree-optimization/40074] [4.4/4.5 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:944
--- 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
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- 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. I compared the generated code and found that ARM EABI requires constructors to return values. That is not common and certainly is not the case on x86_64 and i386. So gcc generates very different code on both targert very early on. The C test-case was created based on the lowered C++ code in the middle-end. It crashes with just -O2 on x86_64 with both 4.3.1 and 4.4.0; it crashes on i386 similarly with 4.3.1. I did not test 4.4.0 on i386. Unfortunately this does not crash on ARM. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug bootstrap/40082] [4.5 Regression] Power bootstrap is broken in building libstdc++
--- 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 2009-05-09 14:44 --- Subject: Re: [4.5 Regression] Power bootstrap is broken in building libstdc++ Hi, I am testing the attached patch. It makes testcase to compile, does it solve bootstrap issues too? It does solve the bootstrap issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40082
[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
--- 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 dllexport attribute to the class' typeinfo object when the class is passed to i386_pe_adjust_class_at_definition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
[Bug fortran/38956] tests gfortran.dg/chmod_{1,2,3}.f90 fails on i686-pc-cygwin
--- 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 PR fortran/38956 * gfortran.dg/chmod_1.f90: Don't run on *-*-cygwin*. * gfortran.dg/chmod_2.f90: Likewise. * gfortran.dg/chmod_3.f90: Likewise. * gfortran.dg/open_errors.f90: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/chmod_1.f90 trunk/gcc/testsuite/gfortran.dg/chmod_2.f90 trunk/gcc/testsuite/gfortran.dg/chmod_3.f90 trunk/gcc/testsuite/gfortran.dg/open_errors.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38956
[Bug c/40087] New: Bad assembly for -O2
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 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.3/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.3/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --enable-java-awt=gtk --with-arch=i686 --enable-languages=c,c++,java,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.3-r2 p1.1, pie-10.1.5' Some simple code works with -O1 but not -O2. I'll attach the C file and the disassembly from objdump. I'm no good with assembly, but I find it weird that 'last' is decremented by 8 at one point. -- Summary: Bad assembly for -O2 Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: markus at cs dot wisc dot edu 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=40087
[Bug c/40087] Bad assembly for -O2
--- 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 C as well.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40087
[Bug c/40087] Bad assembly for -O2
--- 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 push %ebx 8048474: 8b 4d 08mov0x8(%ebp),%ecx 8048477: 8b 45 0cmov0xc(%ebp),%eax 804847a: 39 c8 cmp%ecx,%eax 804847c: 75 1a jne8048498 reverse+0x28 804847e: eb 36 jmp80484b6 reverse+0x46 8048480: 8b 11 mov(%ecx),%edx 8048482: 8b 03 mov(%ebx),%eax 8048484: 89 01 mov%eax,(%ecx) 8048486: 89 13 mov%edx,(%ebx) 8048488: 83 c1 04add$0x4,%ecx 804848b: 39 d9 cmp%ebx,%ecx 804848d: 74 27 je 80484b6 reverse+0x46 804848f: 83 eb 04sub$0x4,%ebx 8048492: 39 d9 cmp%ebx,%ecx 8048494: 75 ea jne8048480 reverse+0x10 8048496: eb 1e jmp80484b6 reverse+0x46 8048498: 8d 58 fclea-0x4(%eax),%ebx 804849b: 39 d9 cmp%ebx,%ecx 804849d: 8d 76 00lea0x0(%esi),%esi 80484a0: 74 14 je 80484b6 reverse+0x46 80484a2: 8b 11 mov(%ecx),%edx 80484a4: 8b 03 mov(%ebx),%eax 80484a6: 89 01 mov%eax,(%ecx) 80484a8: 89 13 mov%edx,(%ebx) 80484aa: 83 c1 04add$0x4,%ecx 80484ad: 39 cb cmp%ecx,%ebx 80484af: 74 05 je 80484b6 reverse+0x46 80484b1: 83 eb 04sub$0x4,%ebx 80484b4: eb dc jmp8048492 reverse+0x22 80484b6: 5b pop%ebx 80484b7: 5d pop%ebp 80484b8: c3 ret [...] `gcc -O2 reverse.c -o reverse -Wall objdump -d reverse` [...] 08048470 reverse: 8048470: 55 push %ebp 8048471: 89 e5 mov%esp,%ebp 8048473: 56 push %esi 8048474: 8b 4d 08mov0x8(%ebp),%ecx 8048477: 53 push %ebx 8048478: 8b 5d 0cmov0xc(%ebp),%ebx 804847b: 39 cb cmp%ecx,%ebx 804847d: 74 37 je 80484b6 reverse+0x46 804847f: 8d 73 fclea-0x4(%ebx),%esi 8048482: 39 f1 cmp%esi,%ecx 8048484: 74 30 je 80484b6 reverse+0x46 8048486: 8b 43 fcmov-0x4(%ebx),%eax 8048489: 8b 11 mov(%ecx),%edx 804848b: 89 01 mov%eax,(%ecx) 804848d: 83 c1 04add$0x4,%ecx 8048490: 39 ce cmp%ecx,%esi 8048492: 89 53 fcmov%edx,-0x4(%ebx) 8048495: 74 1f je 80484b6 reverse+0x46 8048497: 83 eb 08sub$0x8,%ebx 804849a: eb 07 jmp80484a3 reverse+0x33 804849c: 8d 74 26 00 lea0x0(%esi,%eiz,1),%esi 80484a0: 83 eb 04sub$0x4,%ebx 80484a3: 39 d9 cmp%ebx,%ecx 80484a5: 74 0f je 80484b6 reverse+0x46 80484a7: 8b 03 mov(%ebx),%eax 80484a9: 8b 11 mov(%ecx),%edx 80484ab: 89 01 mov%eax,(%ecx) 80484ad: 83 c1 04add$0x4,%ecx 80484b0: 39 d9 cmp%ebx,%ecx 80484b2: 89 13 mov%edx,(%ebx) 80484b4: 75 ea jne80484a0 reverse+0x30 80484b6: 5b pop%ebx 80484b7: 5e pop%esi 80484b8: 5d pop%ebp 80484b9: c3 ret 80484ba: 8d b6 00 00 00 00 lea0x0(%esi),%esi [...] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40087
[Bug c/40087] Bad assembly for -O2
--- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40087
[Bug c++/40085] [4.5 Regression] ICE compiling libmudflap.c++/fail24-frag.cxx
--- 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 http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg02491.html The backtrace points to me of course, but probably it just moved the point of error from whereever it was before to that place. I don't know for hppa of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40085
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- 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 even if they contain the same members, so the casts and accesses as 'struct a' where the object really was 'struct b' are not valid. That can be solved by modeling the same as in C++, via proper subobjects of base-type. This testcase still exhibits the abort() with -O2 with 4.3.2 on i386 and x86_64. It doesn't fail with current trunk, but most probably for the same coincidence since a-i merge. I haven't checked 4.4.x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug fortran/38956] tests gfortran.dg/chmod_{1,2,3}.f90 fails on i686-pc-cygwin
--- 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 PR fortran/38956 * gfortran.dg/chmod_1.f90: Don't run on *-*-cygwin*. * gfortran.dg/chmod_2.f90: Likewise. * gfortran.dg/chmod_3.f90: Likewise. * gfortran.dg/open_errors.f90: Likewise. Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/chmod_1.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/chmod_2.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/chmod_3.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/open_errors.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38956
[Bug fortran/38956] tests gfortran.dg/chmod_{1,2,3}.f90 fails on i686-pc-cygwin
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38956
[Bug libstdc++/40088] New: Creating a std::ostringstream object locks a global mutex
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: Creating a std::ostringstream object locks a global mutex Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: davewx7 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40088
[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
--- 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 solution based on the approach of adding the dllexport attribute
to the class' typeinfo object when the class is passed to
i386_pe_adjust_class_at_definition.
Hello Dave,
Rather than use DLL linkage (and so force client to resort to auto-import
magic)
why not just always emit the RTTI with one-only comdat linkage.
* decl2.c (import_export_decl): Always emit RTTI with comdat linkage
rather than import if MULTIPLE_SYMBOL_SPACES.
Index: decl2.c
===
--- decl2.c (revision 147015)
+++ decl2.c (working copy)
@@ -2351,15 +2351,21 @@
{
class_type = type;
import_export_class (type);
- if (CLASSTYPE_INTERFACE_KNOWN (type)
- TYPE_POLYMORPHIC_P (type)
- CLASSTYPE_INTERFACE_ONLY (type)
- /* If -fno-rtti was specified, then we cannot be sure
-that RTTI information will be emitted with the
-virtual table of the class, so we must emit it
-wherever it is used. */
- flag_rtti)
- import_p = true;
+ /* Do not import typeinfo if the class might be in a DLL.
+Dllimports do not have a constant address at compile time,
+causing problems for static initialization of tables with RTTI
+fields. Set to comdat instead. */
+ if (MULTIPLE_SYMBOL_SPACES)
+ comdat_p = true;
+ else if (CLASSTYPE_INTERFACE_KNOWN (type)
+ TYPE_POLYMORPHIC_P (type)
+ CLASSTYPE_INTERFACE_ONLY (type)
+ /* If -fno-rtti was specified, then we cannot be sure
+ that RTTI information will be emitted with the
+ virtual table of the class, so we must emit it
+ wherever it is used. */
+ flag_rtti)
+import_p = true;
else
{
if (CLASSTYPE_INTERFACE_KNOWN (type)
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org |sourceforge dot net
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-05-10 05:01:24
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
