RFR [XS] 8041658: Use of -fdevirtualize on macroAssembler_x86.o (via -O2) with gcc 4.9.0 creates broken VM
Andrew Haley
aph at redhat.com
Fri Apr 25 13:38:15 UTC 2014
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.
More information about the hotspot-dev
mailing list