[Bug target/104045] [AArch64] combine related to insn fmaxnm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104045 --- Comment #5 from joseph at codesourcery dot com --- Folding the fmax operation should be valid in the absence of -fsignaling-nans (fmax (a, +Inf) should return +Inf without raising any exceptions, for any x not a signaling NaN). However, replacing the division with the constant +Inf is only valid with -fno-trapping-math (though it would be OK by default to use the fact that the result is +Inf in optimizing the fmax call, as long as the division itself doesn't get removed so the divide-by-zero exception is preserved).
[Bug target/104045] [AArch64] combine related to insn fmaxnm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104045 --- Comment #4 from Andrew Pinski --- Note I don't even think llvm implements-ftrapping-math . Still not a gcc bug. There is a bug request on changing the default already opened for gcc.
[Bug target/104045] [AArch64] combine related to insn fmaxnm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104045 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Yes I just checked and we get the constant folding as expected with -fno-trappimg-math. So the defaults are different between the two.
[Bug target/104045] [AArch64] combine related to insn fmaxnm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104045 --- Comment #2 from Andrew Pinski --- I read that wrong. We have Max. I suspect the issue is gcc has -ftrapping-math turned on by default while clang does not. Does -fno-trapping-math fix the issue?
[Bug target/104045] [AArch64] combine related to insn fmaxnm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104045 --- Comment #1 from Andrew Pinski --- I think gcc is correct and clang is wrong. Fmax treats Nan as missing data so fmax is really just a.
