This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN


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

Sujoy <ssaraswati at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssaraswati at gmail dot com

--- Comment #2 from Sujoy <ssaraswati at gmail dot com> ---
I could reproduce this on x86_64-linux-gnu with 4.9 and trunk.

As far as the issue is concerned, the ccp propagates the sNaN value at -O1 or
higher optimization level. Should this be done only when -fsignaling-nans is
on? From the man page of gcc, -fsignaling-nans says -

"Compile code assuming that IEEE signaling NaNs may generate user-visible traps
during floating-point operations.  Setting this option disables optimizations
that may change the number of exceptions visible with signaling NaNs."

Going by this, should we stop ccp from folding sNaN values when
-fsignaling-nans is on? However, the man page also says the following for
-fsignaling-nans -

"This option is experimental and does not currently guarantee to disable all
GCC optimizations that affect signaling NaN behavior."

Given this, may be we can probably let ccp propagate the sNaN value if
-fsignaling-nans is on, and change it to qNaN otherwise. With this though, we
would still see different behavior for the test case at -O0 and -O1 when
-fsignaling-nans is used.

Is my understanding right? I would be interested in pushing a patch for this if
this issue is confirmed. What would be the process to get this confirmed?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]