[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-09-21 09:52 --- Subject: Bug 45580 Author: rguenth Date: Tue Sep 21 09:52:00 2010 New Revision: 164474 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164474 Log: 2010-09-21 Richard Guenther rguent...@suse.de PR tree-optimization/45580 * tree-ssa-propagate.c (substitute_and_fold): Always replace regular uses. * gimple-fold.c (gimple_fold_obj_type_ref): For a BINFO without virtuals fold the call into a regular indirect one. * g++.dg/torture/pr45580.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr45580.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-propagate.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-09-21 09:53 --- ICE fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-09-20 09:10 --- 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|2010-09-07 16:51:12 |2010-09-20 09:10:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-09-20 11:45
---
namespace std {
typedef __SIZE_TYPE__ size_t;
}
inline void* operator new(std::size_t, void* __p) throw() {
return __p;
}
extern C void abort (void);
class Foo {
public:
virtual void test (void) { abort (); }
};
class Bar {
public:
virtual void test (void) { }
};
int main()
{
Foo f;
Bar *b;
b = new (f) Bar();
b-test();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #14 from hubicka at gcc dot gnu dot org 2010-09-20 14:26 --- The fact that C++ vtables are weak or external should no longer bother us with const_decl_known flag. The problem is that array constructor provided by C++ frontend don't have explicit indexes and thus current folders ignore them. This is addresses by the long patch of mine using get_ref_base_and_extend I am just trying to break up ;) To get folding done I need 1) fixed array folding 2) tree-ssa-ccp patch to get rid of OBJ_TYPE_REF when constant operand is known and not get bothered by NOP_EXPRs we produce around. Still we usually need FRE to actually get into at vtable address (it is stored to memory and then read from it) so we actually fold only after inlining and then it is all (almost) pointless excercise. So we would also need 3) Do FRE in early passes (that would make sense now when we do have alias info, I plan to benchmark just moving the pass there) or to teach some other pass to copy propagate through memory Still I don't think low level folding should be the mechanizm we rely on when implementing devirtualization. It is way too low level and requires tracking of value stored to memory cross call boundaries that is hard. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-09-19 10:19 --- Created an attachment (id=21832) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21832action=view) patch Patch I'm testing. The call isn't a virtual one, so in principle the FE lied to us here (probably ignoring the placement new itself). So we can try to recover. The propagation part ensures the original ICE happens at first CCP pass already. Now - we should be able to extract the method we call from bb 2: jsNull (); MEM[(struct NonNullPassRefPtr *)D.2023] = D.2021_16(D); JSObject::JSObject (MEM[(struct JSByteArray *)cell].D.1813, D.2023); MEM[(struct JSByteArray *)cell].D.1813.D.1778._vptr.JSCell = _ZTV11JSByteArray[2]; MEM[(struct JSByteArray *)cell].m_classInfo = 0B; D.1967_8 = MEM[(struct JSCell *)cell]._vptr.JSCell; D.1968_9 = *D.1967_8; D.1968_9 (cell); but FRE only manages to simplify it down to D.1967_8 = _ZTV11JSByteArray[2]; D.1968_9 = *D.1967_8; D.1968_9 (cell); I suppose that's where Honza's SCCVN folding will eventually help. At DOM: D.1968_9 = _ZTV11JSByteArray[2]; D.1968_9 (cell); but maybe we are confused by the vtable being weak: .weak _ZTV11JSByteArray .section .rodata._ZTV11JSByteArray,aG,@progbits,_ZTV11JSByteArray,comdat .align 8 .type _ZTV11JSByteArray, @object .size _ZTV11JSByteArray, 16 _ZTV11JSByteArray: .long 0 .long _ZTI11JSByteArray .long _ZN11JSByteArrayD1Ev .long _ZN11JSByteArrayD0Ev though .rodata means we should have folded it anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-09-18 09:32 --- (In reply to comment #4) The problem is a big one. In short, placement new operator changes the type of an object to another, which re-sets up the VMT. Then there is call of a virtual method of the latter type. CCP however happily propagates the initial declaration (of a type with no virtual methods) to the OBJ_TYPE_REF and attempts to fold it. The folding function naturally expect to see some virtual methods in BINFOs but there are none and we dereference a NULL pointer. I don't quite understand from the description what is going on. Did you manage to produce a smaller testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-18 10:02 --- autoreducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #7 from aanisimov at inbox dot ru 2010-09-18 10:11 --- (In reply to comment #6) autoreducing. Is this I reduce it myself or I have some tool reduce it for me? If the latter is the case, then what is the tool for automatic testcase reduction? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-09-18 10:15 --- (In reply to comment #7) (In reply to comment #6) autoreducing. Is this I reduce it myself or I have some tool reduce it for me? If the latter is the case, then what is the tool for automatic testcase reduction? I have some tool. See http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-09-18 12:54 --- Created an attachment (id=21828) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21828action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-09-18 15:06 --- Well - I think the point is that if the dynamic type of storage differs from its static type (as it happens with placement new) you cannot rely on TYPE_BINFO to be correct at all. Which means that instead of ICEing you can get wrong code easily as well. I think you need to dump using TYPE_BINFO completely and instead rely on the function pointer only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-09-17 18:21 --- The problem is a big one. In short, placement new operator changes the type of an object to another, which re-sets up the VMT. Then there is call of a virtual method of the latter type. CCP however happily propagates the initial declaration (of a type with no virtual methods) to the OBJ_TYPE_REF and attempts to fold it. The folding function naturally expect to see some virtual methods in BINFOs but there are none and we dereference a NULL pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #1 from aanisimov at inbox dot ru 2010-09-07 12:27 --- Created an attachment (id=21727) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21727action=view) Preprocessed source for JSGlobalData.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-07 16:51 --- It is caused by revision 161655: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg6.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-07 16:51:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
[Bug tree-optimization/45580] [4.6 Regression] Building WebKit fails with compiler catching SIGSEGV in gimple_fold_obj_type_ref_known_binfo()
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-07 17:02 --- Valgrind reports: Compiler executable checksum: 49fb87eb28749ed7ad604cc77a74ec38 ==24854== Invalid read of size 2 ==24854==at 0x1258998: gimple_fold_obj_type_ref_known_binfo (gimple-fold.c:1383) ==24854==by 0x1258E57: gimple_fold_obj_type_ref (gimple-fold.c:1416) ==24854==by 0x1259081: fold_gimple_call (gimple-fold.c:1460) ==24854==by 0x125931D: fold_stmt_1 (gimple-fold.c:1522) ==24854==by 0x12596C6: fold_stmt (gimple-fold.c:1601) ==24854==by 0xDE9EC7: substitute_and_fold (tree-ssa-propagate.c:1135) ==24854==by 0xD4FD07: ccp_finalize (tree-ssa-ccp.c:877) ==24854==by 0xD58452: do_ssa_ccp (tree-ssa-ccp.c:2357) ==24854==by 0xB5B1A0: execute_one_pass (passes.c:1569) ==24854==by 0xB5B38F: execute_pass_list (passes.c:1624) ==24854==by 0xB5B3B0: execute_pass_list (passes.c:1625) ==24854==by 0xCE6503: tree_rest_of_compilation (tree-optimize.c:452) ==24854== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==24854== ../3rdparty/javascriptcore/JavaScriptCore/runtime/JSGlobalData.cpp: In static member function static void QTJSC::JSGlobalData::storeVPtrs(): ../3rdparty/javascriptcore/JavaScriptCore/runtime/JSGlobalData.cpp:79:6: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580
