On Wed, 15 Jun 2016, Bernd Edlinger wrote:
> Hi,
>
> I modified Aexander's test case a bit, and found something
> unexpected, which looks like a GCC-BUG to me:
>
> cat test.c
> #include <string.h>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main()
> {
> long double d0, d;
>
> memcpy(&d0,
> "\x00\x00\x00\x00\x00\x00\x00\x00\xff\x3f\x00\x00\x00\x00\x00\x00", sizeof
> d0);
>
> // d = d0;
> memcpy(&d, &d0, sizeof d0);
> // if (memcmp(&d, &d0, sizeof d))
> // abort();
>
> printf("d = %Lf\n", d);
>
> for (unsigned char *p = (unsigned char *)&d + sizeof d; p > (unsigned char
> *)&d;)
> printf("%02x ", *--p);
> printf("\n");
> }
> // EOF
>
> gcc -O3 test.c && ./a.out
> d = 0.000000
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> but, when I un-comment the memcmp the test case shows the expected
> result:
> d = 0.000000
> 00 00 00 00 00 00 3f ff 00 00 00 00 00 00 00 00
>
> gcc-Version 7.0.0 20160613 (experimental) (GCC)
>
>
> Would'nt you agree, that if we use memcpy it should be possible
> to preserve denormalized or otherwise invalid bit patterns?
> And why should the memcmp have an influence on the memcpy?
I think this is PR71522 which I already fixed on trunk. memcmp
takes the address of the var and by doing that inhibits the broken
transform.
Richard.
