[OpenJDK 2D-Dev] [PATCH FOR REVIEW] Building ExtensionSubtables.cpp should use -fno-strict-aliasing

[Phil Race]

On 5/23/2012 9:32 AM, Andrew Hughes wrote:
>
> ----- Original Message -----
>> I suppose the problem that some new version of GCC enables this
>> option
>> by default and
>> we could run into a problem at run time if we don't disable it ?
>>
> Yes, 4.4 to be precise.  It's not particularly new; it came out on
> April 21st, 2009.
>
>> But this patch would appear to disable it for the whole ICU library
>> ..
>> and any other C++ code in the .so
>> which I would have to suppose impacts the compiler's ability to
>> optimise
>> the code, in order to
>> eliminate a single warning.
>>
>> Can you devise a more targeted fix ?
>>
> Yes, I thought the same.  But I don't see how you can direct flags to
> one specific file in the Makefiles.  Any ideas?

I would normally suggest a pragma but when I googled around
it looks like the appropriate one is actually non-functional on purpose ..
https://bugzilla.redhat.com/show_bug.cgi?id=486176

So it might require a bit more makefile smarts. I think there's a chance
some other example template of how to do this exists but I do not know.

> Alternatively, is this READ_LONG macro even necessary?  I'm not surprised
> gcc balks at it to be honest.

I would suppose it is needed but haven't closely examined the code.

-phil.
>> -phil.
>>
>> On 5/23/2012 5:59 AM, Andrew Hughes wrote:
>>> At present, the building of ExtensionSubtables.cpp produces a
>>> warning:
>>>
>>> ../../../src/share/native/sun/font/layout/ExtensionSubtables.cpp:57:31:
>>> warning: dereferencing type-punned pointer will break
>>> strict-aliasing rules [-Wstrict-aliasing]
>>>
>>> due to this code:
>>>
>>> // read a 32-bit value that might only be 16-bit-aligned in memory
>>> #define READ_LONG(code) (le_uint32)((SWAPW(*(le_uint16*)&code)<<
>>>   16) + SWAPW(*(((le_uint16*)&code) + 1)))
>>>
>>> where code is a le_uint32.
>>>
>>> This can be avoided by setting -fno-strict-aliasing, as done in
>>> this webrev:
>>>
>>> http://cr.openjdk.java.net/~andrew/no-strict-aliasing/
>>>
>>> making the code safer in the process.
>>>
>>> Ok for jdk8?  If so, can I have a bug ID for this please?
>>>
>>> Thanks,
>>