https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
Florian Weimer <fw at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fw at gcc dot gnu.org
--- Comment #21 from Florian Weimer <fw at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #20)
> Yeah. Not sure how often dynamic objects are opened from within threads
> though.
We know that some shared objects call pthread_create from ELF constructors,
which is enough to potentially expose the issue if the ELF constructors are
ordered in certain ways.
> That said, a possibility to enforce "consistency" at least would
> be to save/restore the FP state around dlopen() so that shared objects
> loaded not at program startup would not affect FP state at all?
> The same could be done for shared objects loaded at program startup of
> course.
I think GCC should not automatically link crtfastmath.o with -shared. That will
fix this particular issue for new shared objects, where the
action-at-a-distance issue is most prominent and least desirable I think.
> The other way around would eventually be to make the CTOR __tls, that
> should eventually force all threads to change their FP state(?).
No, all current TLS constructors run lazily when some language construct is
used. There is no way to run TLS constructors at dlopen time. We can in theory
change CPU state using glibc's SETXID broadcast, but it will impact legitimate
uses of the control register (e.g., changes to the FP control word around a
block of code that is executed in a non-default mode).
These days, we'd probably use GNU property notes for something like this
(although we'd likely not make it a global property in the first place, not for
this).
