https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
Bug ID: 94103
Summary: Wrong optimization: reading value of a variable
changes its representation for optimizer
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
It seems the optimizer sometimes computes the representation of variables from
its value instead of tracking it directly. This is wrong when the value admits
different representations.
(Given that the value is used, the representation should be valid (non-trap).)
Example with lost padding in x86-64 long double:
----------------------------------------------------------------------
#include <string.h>
#include <stdio.h>
int main()
{
long double x;
// fill x including the padding
unsigned long u[2] = {0xEEEEEEEEEEEEEEEE, 0xEEEEEEEEEEEEEEEE};
memcpy(&x, &u, sizeof x);
// print the representation of x (initial)
memcpy(&u, &x, sizeof u);
printf("%016lX %016lX\n", u[1], u[0]);
// change the representation of x a bit
++*(unsigned char *)&x;
(void)-x; // use the value of x but don't write it
// print the representation of x (resulting)
memcpy(&u, &x, sizeof u);
printf("%016lX %016lX\n", u[1], u[0]);
}
----------------------------------------------------------------------
$ gcc -std=c2x -pedantic -Wall -Wextra test.c && ./a.out
EEEEEEEEEEEEEEEE EEEEEEEEEEEEEEEE
EEEEEEEEEEEEEEEE EEEEEEEEEEEEEEEF
$ gcc -std=c2x -pedantic -Wall -Wextra -O3 test.c && ./a.out
EEEEEEEEEEEEEEEE EEEEEEEEEEEEEEEE
000000000000EEEE EEEEEEEEEEEEEEEF
----------------------------------------------------------------------
gcc x86-64 version: gcc (GCC) 10.0.1 20200305 (experimental)
----------------------------------------------------------------------
Zeros in the last output line are wrong.
