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? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1327530 Title: [arm64] float to double conversion does not silence sNaN To manage notifications about this bug go to: https://bugs.launchpad.net/gcc/+bug/1327530/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
