https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|middle-end |target
Keywords| |wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed| |2020-03-10
Target| |x86_64-*-*, i?86-*-*,
| |m68k-*-*
CC| |law at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
There's a related bug about x87 stores not storing all bytes which was closed
as INVALID, the testcase was using a union to pun long double and a character
array IIRC. Here the situation is quite similar - the IL has (from your
unused load):
x.1_6 = x;
_18 = MEM[(char * {ref-all})&x];
MEM[(char * {ref-all})&u] = _18;
_7 = u[0];
_8 = u[1];
printf ("%016lX %016lX\n", _8, _7);
where x.1_6 is of type long double and _18 is __int128. Value-numbering
then decides that it can elide the load to _18 and also optimize the loads
from u[] as:
x.1_6 = x;
_31 = VIEW_CONVERT_EXPR<__int128 unsigned>(x.1_6);
MEM[(char * {ref-all})&u] = _31;
_32 = (long unsigned int) _31;
_33 = BIT_FIELD_REF <_31, 64, 64>;
printf ("%016lX %016lX\n", _33, _32);
which is because the backend tells us the FP load x.1_6 = x loads all
bits and do not modify the underlying representation. Now, for x87
modes GET_MODE_SIZE isn't in agreement with what the actual instruction
does nor does the load reflect the fact that a x87 load (not the
long double variant) can end up doing a rounding step. m68k is
probably similarly affected. And yes, compared to the other bug I
was able to close as INVALID conveniently this one looks "real"
(if also artificially constructed and unfortunate...). Jeff, you
also were involved in the other bug, do you agree here? I still don't
see any good solution though.
I agree that the decimal float variant is an entirely different bug,
maybe you can open a new one for this?
