[Bug middle-end/92824] Wrong optimization: representation of long doubles not copied even with memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92824
Alexander Cherepanov changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW |RESOLVED
--- Comment #5 from Alexander Cherepanov ---
I thought that memcpy ignored after the assignment here but the problem remain
even after replacing `y = x;` with `-x;`. After fre1 we get a normalized value:
MEM <__int128 unsigned> [(char * {ref-all})] = 0x18000;
So this is an exact dup of pr94103.
*** This bug has been marked as a duplicate of bug 94103 ***
[Bug middle-end/92824] Wrong optimization: representation of long doubles not copied even with memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92824 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-30 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/92824] Wrong optimization: representation of long doubles not copied even with memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92824
--- Comment #4 from Alexander Cherepanov ---
(In reply to Richard Biener from comment #3)
> shows we're constant folding this to
>
> __builtin_printf ("%lf\n",
> 3.36210314311209350626267781732175260259807934484647124011e-4932);
Unfortunately, in this form, it's not clear whether normalization already
happened or not (unlike with clang which prints such numbers as hex).
OTOH I would not expect problems with only one variable after pr71522 was
fixed.
> now. When we put #pragma GCC unroll 16 before your testcases loop we
> get the following (unrolling and constant folding happens after the
> "bad" transform)
>
> main ()
> {
>[local count: 82570746]:
> printf ("%02x ", 128);
> printf ("%02x ", 128);
> printf ("%02x ", 0);
> printf ("%02x ", 0);
> printf ("%02x ", 128);
> printf ("%02x ", 0);
> printf ("%02x ", 0);
> printf ("%02x ", 0);
> printf ("%02x ", 0);
> printf ("%02x ", 0);
> printf ("%02x ", 0);
> printf ("%02x ", 0);
> __builtin_putchar (10);
> return 0;
After inserting `#pragma GCC unroll 16` in my testcase I get something else:
main ()
{
[local count: 63136024]:
printf ("%02x ", 0);
printf ("%02x ", 0);
printf ("%02x ", 0);
printf ("%02x ", 0);
printf ("%02x ", 0);
printf ("%02x ", 0);
printf ("%02x ", 0);
printf ("%02x ", 1);
printf ("%02x ", 128);
printf ("%02x ", 0);
printf ("%02x ", 0);
printf ("%02x ", 0);
printf ("%02x ", 0);
printf ("%02x ", 0);
printf ("%02x ", 0);
printf ("%02x ", 0);
__builtin_putchar (10);
return 0;
}
Please note 16 values being printed instead of 12, "1" printed in exponent and
zeroes in padding (exactly as in the description of this pr). I'm testing on
x86-64.
[Bug middle-end/92824] Wrong optimization: representation of long doubles not copied even with memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92824
--- Comment #3 from Richard Biener ---
So
int main()
{
long double x;
// make x pseudo-denormal
x = 0;
unsigned char *px = (unsigned char *)
px[7] = 0x80;
// set padding
px[10] = 0x80;
px[11] = 0x80;
px[12] = 0x80;
px[13] = 0x80;
px[14] = 0x80;
px[15] = 0x80;
__builtin_printf("%lf\n", x);
return 0;
}
shows we're constant folding this to
__builtin_printf ("%lf\n",
3.36210314311209350626267781732175260259807934484647124011e-4932);
now. When we put #pragma GCC unroll 16 before your testcases loop we
get the following (unrolling and constant folding happens after the
"bad" transform)
main ()
{
[local count: 82570746]:
printf ("%02x ", 128);
printf ("%02x ", 128);
printf ("%02x ", 0);
printf ("%02x ", 0);
printf ("%02x ", 128);
printf ("%02x ", 0);
printf ("%02x ", 0);
printf ("%02x ", 0);
printf ("%02x ", 0);
printf ("%02x ", 0);
printf ("%02x ", 0);
printf ("%02x ", 0);
__builtin_putchar (10);
return 0;
[Bug middle-end/92824] Wrong optimization: representation of long doubles not copied even with memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92824 --- Comment #2 from Andreas Schwab --- On m68k the padding is internal, and actually part of the representation.
[Bug middle-end/92824] Wrong optimization: representation of long doubles not copied even with memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92824 Andrew Pinski changed: What|Removed |Added Target||x86_64-linux-gnu, m68k --- Comment #1 from Andrew Pinski --- y = x; I thought that would only copy the representational bits. so padding for the scalar value is ignored. NOTE this is only an issue with x86 (and maybe m68k too)'s 80bit but with 16bit (or 48bit) worth of padding. Those are the only scalar types with padding. No other targets have this padding issue.
