[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]

------- 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=21832&action=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