RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM

[Volker Simonis]

Thanks for opening the bug!

They first opened http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60963
but categorized it as 'ubsan' (i.e. sanitizer bug) which it isn't.

Hopefully  they'll fix it soon:)

Regards,
Volker


On Fri, Apr 25, 2014 at 3:38 PM, Andrew Haley <aph at redhat.com> wrote:
> On 04/25/2014 11:31 AM, Andrew Haley wrote:
>> On 04/25/2014 01:10 AM, John Rose wrote:
>>> On Apr 24, 2014, at 9:41 AM, Andrew Haley <aph at redhat.com> wrote:
>>>
>>>> On 04/24/2014 05:21 PM, Volker Simonis wrote:
>>>>> And I'm not quite sure how to fix this in HotSpot.
>>>>>
>>>>> I first thought I could solve this with an anonymous union like:
>>>>>
>>>>> union {
>>>>>  void* _relocbuf[ _relocbuf_size ];
>>>>>  Relocation _reloc;
>>>>> }
>>>>> Relocation* reloc() const { return &_reloc; }
>>>>>
>>>>> but unfortunately I can't put a Relocation into a union because it is
>>>>> not a POD (at least not with C++98).
>>>>>
>>>>> Any other ideas how we could fool GCC 4.9?
>>>>>
>>>>> I more and more think this should be fixed in GCC because I can
>>>>> imagine this will also break other code.
>>>>
>>>> Only code that is not legal C++, and GCC developers have historically
>>>> been very reluctant to support that.  So, it might not happen.
>>>>
>>>> AFAICS there is no C++98 way to embed a non-POD object in an object in this
>>>> way.  It could be done via a pointer, but that wastes some space.
>>>
>>> That design (RelocationHolder, bitwise non-PODS copy) was committed
>>> 1998-02-27.  (Full discl.—courtesy of yours truly.)
>>
>> :-)
>>
>>> Sorry it got in your way.  We've seen occasional problems with it
>>> before at high optimization levels.  And I agree that current C++
>>> standards make this doubtful usage.
>>
>> I don't think that this transformation in GCC does anything useful.
>
> GCC list seems to think it is a bug in GCC.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965
>
> Andrew.
>