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

[Phil Race]

It may not be easy but its worth investigating.

BTW .. I have not recently tried the new build mechanism, but does anyone
on the build list know what kinds of build changes will very probably 
just work
with that too, and which will need to be tested separately ?

-phil.

On 5/23/2012 9:12 AM, Damon Hart-Davis wrote:
> Hi,
>
> FWIW, and I have not looked at any of the build system for this, when building large optimised cross-platform critical C++ projects I had the option to turn down or off optimisation for individual files for individual compilers/platforms.
>
> At worst you might accomplish that (with other maintenance risks) with an explicit build rule in the makefile for that .cpp file for that platform/compiler, but only if the macro is local to that .cpp file.
>
> Anyhow, I'm speaking from ignorance of all the detail here, so please ignore me!
>
> Rgds
>
> Damon
>
>
> On 23 May 2012, at 17:01, Phil Race wrote:
>
>> 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 ?
>>
>> 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 ?
>>
>> -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,