[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 Richard Biener changed: What|Removed |Added Target Milestone|9.5 |---
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 Richard Biener changed: What|Removed |Added Target Milestone|9.4 |9.5 --- Comment #16 from Richard Biener --- GCC 9.4 is being released, retargeting bugs to GCC 9.5.
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.3 |9.4 --- Comment #15 from Jakub Jelinek --- GCC 9.3.0 has been released, adjusting target milestone.
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.2 |9.3 --- Comment #14 from Jakub Jelinek --- GCC 9.2 has been released.
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #13 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 Segher Boessenkool changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #12 from Segher Boessenkool --- So yes what Joseph says in #c7 seems to be what is going on.
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 --- Comment #11 from Segher Boessenkool --- If you use -fsignaling-nans everything works as expected.
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #10 from Richard Biener --- FRE uses native_encode_real / native_interpret_int to read the NAN as integer. I suspect that something goes wrong with native_encode_real here or in real_to_target which is used by that function.
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 --- Comment #9 from Segher Boessenkool --- (In reply to Bill Schmidt from comment #8) > That makes sense -- we already have a NaN rather than an SNaN by the time we > hit the Ealias pass. It's already a QNaN in 004t.original (the very first dump file) (but at the time the builtin_nan* are constructed, in fold_const_builtin_nan, it is all okay still).
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 --- Comment #8 from Bill Schmidt --- That makes sense -- we already have a NaN rather than an SNaN by the time we hit the Ealias pass.
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 --- Comment #7 from joseph at codesourcery dot com --- If you use __builtin_nansf128 (which returns _Float128) but __float128 is long double, it's possible the implicit conversion from storing the result of __builtin_nansq in y.value results in converting a signaling NaN to a quiet NaN (it's unspecified whether conversion by assignment to the same floating-point format is a convertFormat or copy operation). If that's what's going on, then, given that __builtin_nansq etc. correspond to the type name __float128 (not to _Float128), those built-in functions (all the *q ones) should be mapped to those for whatever type __float128 is equivalent to, to avoid such conversions of signaling to quiet NaNs. I.e., if the issue is such an implicit conversion of signaling to quiet NaN, the patch attached to this issue is using the right approach for a fix.
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 --- Comment #6 from Segher Boessenkool --- The values created for the four NaNs are 7fff8001 7fff8002ab3c 7fff8001 7fff8002ab3c with -mabi=ieeelongdouble and 7fff8001 7fff8002ab3c 7fff0001 7fff0002ab3c with -mabi=ibmlongdouble (the latter is correct).
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 --- Comment #5 from Michael Meissner --- Created attachment 44342 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44342&action=edit Patch to map 'q' builtins to 'l' instead of 'f128' This patch 'fixes' the problem by changing the __builtin_nanq and __builtin_nansq functions to __builtin_nanl and __builtin_nansl when long double is IEEE, but I suspect it is just papering over the problem. If you call __builtin_nanf128, it will still fail.
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 --- Comment #4 from Michael Meissner --- If I change the __builtin_nanq calls to __builtin_nanl and the __builtin_nansq calls to __builtin_nansl when __float128 and long double use the same type, the test works fine.
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 Michael Meissner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-06-29 Ever confirmed|0 |1
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 --- Comment #3 from Michael Meissner --- BTW, I compiled the same code on the x86 with both -mlong-double-80 and -mlong-double-128 options, and FRE1 deletes the code, but returns 0 instead of calling abort.
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 Bill Schmidt changed: What|Removed |Added Keywords||wrong-code Target||powerpc64le-linux Target Milestone|--- |9.0
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 --- Comment #2 from Michael Meissner --- Created attachment 44341 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44341&action=edit Fre1 tree pass
[Bug tree-optimization/86367] FRE1 tree pass deletes code in gcc.target/powerpc/nan128-1.c when long double is IEEE 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367 --- Comment #1 from Michael Meissner --- Created attachment 44340 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44340&action=edit Ealias tree pass (pass before FRE1)
