public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug web/107436] New: Is -fsignaling-nans still experimental?
@ 2022-10-27 15:17 florian.schanda at bmw dot de
  2022-10-27 15:27 ` [Bug middle-end/107436] " pinskia at gcc dot gnu.org
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: florian.schanda at bmw dot de @ 2022-10-27 15:17 UTC (permalink / raw)
  To: gcc-bugs

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!

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug middle-end/107436] Is -fsignaling-nans still experimental?
  2022-10-27 15:17 [Bug web/107436] New: Is -fsignaling-nans still experimental? florian.schanda at bmw dot de
@ 2022-10-27 15:27 ` pinskia at gcc dot gnu.org
  2022-10-28  5:32 ` florian.schanda at bmw dot de
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-10-27 15:27 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=57994,
                   |                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=67052,
                   |                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=77926,
                   |                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=88640,
                   |                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=97965,
                   |                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=52258,
                   |                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=46993

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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 ...

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug middle-end/107436] Is -fsignaling-nans still experimental?
  2022-10-27 15:17 [Bug web/107436] New: Is -fsignaling-nans still experimental? florian.schanda at bmw dot de
  2022-10-27 15:27 ` [Bug middle-end/107436] " pinskia at gcc dot gnu.org
@ 2022-10-28  5:32 ` florian.schanda at bmw dot de
  2022-10-28  9:26 ` florian.schanda at bmw dot de
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: florian.schanda at bmw dot de @ 2022-10-28  5:32 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436

--- Comment #2 from Florian Schanda <florian.schanda at bmw dot de> ---
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 :)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug middle-end/107436] Is -fsignaling-nans still experimental?
  2022-10-27 15:17 [Bug web/107436] New: Is -fsignaling-nans still experimental? florian.schanda at bmw dot de
  2022-10-27 15:27 ` [Bug middle-end/107436] " pinskia at gcc dot gnu.org
  2022-10-28  5:32 ` florian.schanda at bmw dot de
@ 2022-10-28  9:26 ` florian.schanda at bmw dot de
  2022-10-28 11:53 ` rguenth at gcc dot gnu.org
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: florian.schanda at bmw dot de @ 2022-10-28  9:26 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436

--- Comment #3 from Florian Schanda <florian.schanda at bmw dot de> ---
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?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug middle-end/107436] Is -fsignaling-nans still experimental?
  2022-10-27 15:17 [Bug web/107436] New: Is -fsignaling-nans still experimental? florian.schanda at bmw dot de
                   ` (2 preceding siblings ...)
  2022-10-28  9:26 ` florian.schanda at bmw dot de
@ 2022-10-28 11:53 ` rguenth at gcc dot gnu.org
  2022-10-28 11:56 ` florian.schanda at bmw dot de
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-10-28 11:53 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
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?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug middle-end/107436] Is -fsignaling-nans still experimental?
  2022-10-27 15:17 [Bug web/107436] New: Is -fsignaling-nans still experimental? florian.schanda at bmw dot de
                   ` (3 preceding siblings ...)
  2022-10-28 11:53 ` rguenth at gcc dot gnu.org
@ 2022-10-28 11:56 ` florian.schanda at bmw dot de
  2022-10-28 14:21 ` jakub at gcc dot gnu.org
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: florian.schanda at bmw dot de @ 2022-10-28 11:56 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436

--- Comment #5 from Florian Schanda <florian.schanda at bmw dot de> ---
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 :)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug middle-end/107436] Is -fsignaling-nans still experimental?
  2022-10-27 15:17 [Bug web/107436] New: Is -fsignaling-nans still experimental? florian.schanda at bmw dot de
                   ` (4 preceding siblings ...)
  2022-10-28 11:56 ` florian.schanda at bmw dot de
@ 2022-10-28 14:21 ` jakub at gcc dot gnu.org
  2022-11-29  9:54 ` florian.schanda at bmw dot de
  2024-01-04 18:55 ` florian.schanda at bmw dot de
  7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-10-28 14:21 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug middle-end/107436] Is -fsignaling-nans still experimental?
  2022-10-27 15:17 [Bug web/107436] New: Is -fsignaling-nans still experimental? florian.schanda at bmw dot de
                   ` (5 preceding siblings ...)
  2022-10-28 14:21 ` jakub at gcc dot gnu.org
@ 2022-11-29  9:54 ` florian.schanda at bmw dot de
  2024-01-04 18:55 ` florian.schanda at bmw dot de
  7 siblings, 0 replies; 9+ messages in thread
From: florian.schanda at bmw dot de @ 2022-11-29  9:54 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436

Florian Schanda <florian.schanda at bmw dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #7 from Florian Schanda <florian.schanda at bmw dot de> ---
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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug middle-end/107436] Is -fsignaling-nans still experimental?
  2022-10-27 15:17 [Bug web/107436] New: Is -fsignaling-nans still experimental? florian.schanda at bmw dot de
                   ` (6 preceding siblings ...)
  2022-11-29  9:54 ` florian.schanda at bmw dot de
@ 2024-01-04 18:55 ` florian.schanda at bmw dot de
  7 siblings, 0 replies; 9+ messages in thread
From: florian.schanda at bmw dot de @ 2024-01-04 18:55 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436

--- Comment #8 from Florian Schanda <florian.schanda at bmw dot de> ---
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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2024-01-04 18:55 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-27 15:17 [Bug web/107436] New: Is -fsignaling-nans still experimental? florian.schanda at bmw dot de
2022-10-27 15:27 ` [Bug middle-end/107436] " pinskia at gcc dot gnu.org
2022-10-28  5:32 ` florian.schanda at bmw dot de
2022-10-28  9:26 ` florian.schanda at bmw dot de
2022-10-28 11:53 ` rguenth at gcc dot gnu.org
2022-10-28 11:56 ` florian.schanda at bmw dot de
2022-10-28 14:21 ` jakub at gcc dot gnu.org
2022-11-29  9:54 ` florian.schanda at bmw dot de
2024-01-04 18:55 ` florian.schanda at bmw dot de

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).