This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: _Bool and trap representations


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]