On Fri, Apr 26, 2024 at 10:19 AM Roger Sayle <ro...@nextmovesoftware.com> wrote: > > > This patch addresses PR middle-end/111701 where optimization of signbit(x*x) > using tree_nonnegative_p incorrectly eliminates a floating point > multiplication when the operands may potentially be signaling NaNs. > > The above bug fix also provides a solution or work-around to the tricky > issue in PR middle-end/111701, that the results of IEEE operations on NaNs > are specified to return a NaN result, but fail to (precisely) specify > the exact NaN representation of this result. Hence for the operation > "-NaN*-NaN" different hardware implementations (targets) return different > results. Ultimately knowing what the resulting NaN "payload" of an > operation is can only be known by executing that operation at run-time, > and I'd suggest that GCC's -fsignaling-nans provides a mechanism for > handling code that uses NaN representations for communication/signaling > (which is a different but related concept to IEEE's sNaN). > > One nice thing about this patch, which may or may not be a P2 regression > fix, is that it only affects (improves) code compiled with -fsignaling-nans > so should be extremely safe even for this point in stage 3. > > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > and make -k check, both with and without --target_board=unix{-m32} > with no new failures. Ok for mainline?
Hmm, but the bugreports are not about sNaN but about the fact that the sign of the NaN produced by 0/0 or by -NaN*-NaN is not well-defined. So I don't think this is the correct approach to fix this. We'd instead have to use tree_expr_maybe_nan_p () - and if NaN*NaN cannot be -NaN (is that at least specified?) then the RECURSE path should still work as well. Richard. > > 2024-04-26 Roger Sayle <ro...@nextmovesoftware.com> > > gcc/ChangeLog > PR middle-end/111701 > * fold-const.cc (tree_binary_nonnegative_warnv_p) <case MULT_EXPR>: > Split handling of floating point and integer types. For equal > floating point operands, avoid optimization if the operand may be > a signaling NaN. > > gcc/testsuite/ChangeLog > PR middle-end/111701 > * gcc.dg/pr111701-1.c: New test case. > * gcc.dg/pr111701-2.c: Likewise. > > > Thanks in advance, > Roger > -- >