Hi, Is the following statement in the documentation on "-fsignaling-nans" still correct? > This option is experimental and does not currently guarantee to > disable all GCC optimizations that affect signaling NaN behavior. The context is that we have a safety mechanism in a third-party library that relies signalling nans to work correctly; and if we cannot guarantee it with this option it would be a major headache indeed. Any advice (or even better statement that the experimental note is outdated and can be deleted) would be appreciated. Many thanks in advance!
There seems like there are still known issues with signalling nans on different targets still. There has been many fixes in recent years but not all might be there. Also it depends on the target you are targetting. A third party library depending on signaling NaNs is slightly an issue in general considering -fsignaling-nans is not on by default and some (many?) targets fpu have issues with signaling NaNs in general ...
Hi Andrew, thank you so much for your reply. The architecture in question is Goldmont, is the flag alright for that target? > A third party library depending on signaling NaNs is slightly an > issue in general considering -fsignaling-nans is not on by default > and some (many?) targets fpu have issues with signaling NaNs in general ... Tell me about it :)
Maybe some additional constraints under which we operate can help: - we never change our rounding mode away from RNE - we never disable support for subnormals in any way - we only ever use float32 and float64, we do not use the intel extended precision format Under those constraints, will -fsignaling-nans work?
The question is what the expectations are. I think that all issues would be considered bugs (see the list of referenced bugs). Can you evaluate it according to your needs and file bugreports for issues not covered?
Richard, if I may rephrase your statement (for clarity), you're saying: > Under your assumptions, -fsignaling-nans should work. There are no known bugs > in this setup, but if you find something please report it. Is that accurate? If yes, then this is something we could live with :)
(In reply to Florian Schanda from comment #5) > Richard, if I may rephrase your statement (for clarity), you're saying: > > > Under your assumptions, -fsignaling-nans should work. There are no known bugs > > in this setup, but if you find something please report it. > > Is that accurate? No. See the See Also bugs referenced in this bug.
OK, thank you again all for your answers. We have found an alternative approach for verifying that the implementation defined behaviour the 3rd party library depends on is irrelevant in our specific use case. Not great, but it kinda works. Killing the ticket.
I am no longer working at BMW. For safety topics please contact alexander.schemmel@bmw.de or markus.schurius@bmw.de For TRLC and LOBSTER topics please contact philipp.wullstein-kammler@bmw.de or create issues on public github https://github.com/bmw-software-engineering/trlc/issues