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,
