[OpenJDK 2D-Dev] [PATCH FOR REVIEW] Building ExtensionSubtables.cpp should use -fno-strict-aliasing
philip.race at oracle.com
Wed May 23 16:50:33 UTC 2012
On 5/23/2012 9:32 AM, Andrew Hughes wrote:
> ----- Original Message -----
>> I suppose the problem that some new version of GCC enables this
>> 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
>> 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 ..
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.
>> On 5/23/2012 5:59 AM, Andrew Hughes wrote:
>>> At present, the building of ExtensionSubtables.cpp produces a
>>> 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:
>>> making the code safer in the process.
>>> Ok for jdk8? If so, can I have a bug ID for this please?
More information about the 2d-dev