On 04/28/2015 11:35 AM, Orion Poplawski wrote:
It appears that shared libraries compiled with -ffast-math (as libopenjpeg.so
is) will call set_fast_math() in the library init code:
Watchpoint 1: $mxcsr
Old value = [ IM DM ZM OM UM PM ]
New value = [ DAZ IM DM ZM OM UM PM FZ ]
0x00007fffe619d112 in set_fast_math () from /lib64/libopenjpeg.so.1
#0 0x00007fffe619d112 in set_fast_math () from /lib64/libopenjpeg.so.1
#1 0x00007ffff7deaf2a in call_init (l=<optimized out>, argc=argc@entry=1,
argv=argv@entry=0x7fffffffd6a8, env=env@entry=0x7fffffffd6b8) at dl-init.c:76
This will then affect the floating point operations of all code run after the
library is loaded, regardless of its use of -ffast-math or not, which can lead
to some unexpected behavior.
This seems like it's a pretty broad and generic problem and I'm wondering how
best to handle it.
So, the solution appears to be that libopenjpeg (and any other library) should
not link with -ffast-math, but only compile with it.
This appears to be the gcc bug mentioned in that report:
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com