[Bug middle-end/107436] Is -fsignaling-nans still experimental?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436 --- Comment #8 from Florian Schanda --- I am no longer working at BMW. For safety topics please contact alexander.schem...@bmw.de or markus.schur...@bmw.de For TRLC and LOBSTER topics please contact philipp.wullstein-kamm...@bmw.de or create issues on public github https://github.com/bmw-software-engineering/trlc/issues
[Bug middle-end/107436] Is -fsignaling-nans still experimental?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436 Florian Schanda changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Florian Schanda --- 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.
[Bug middle-end/107436] Is -fsignaling-nans still experimental?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436 --- Comment #5 from Florian Schanda --- 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 :)
[Bug middle-end/107436] Is -fsignaling-nans still experimental?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436 --- Comment #3 from Florian Schanda --- 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?
[Bug middle-end/107436] Is -fsignaling-nans still experimental?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436 --- Comment #2 from Florian Schanda --- 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 :)
[Bug web/107436] New: Is -fsignaling-nans still experimental?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436 Bug ID: 107436 Summary: Is -fsignaling-nans still experimental? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: florian.schanda at bmw dot de Target Milestone: --- 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!
