https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71475
--- Comment #8 from Alexander Cherepanov <ch3root at openwall dot com> ---
Here is a more clear illustration that gcc treats this representation as
a trap representation. The previous example could be explained by this
representation being an alternative representation for some value and
glibc treating it differently from gcc. Now the influence of libc is
eliminated. The only place where long double values appear is the ==
operator which is implemented by gcc.
For ordinary values (and given that d1 and d2 are not pointers:-) we have:
d1 and d2 have the same representation and the result of the == operator
is well-defined and should be the same for both variables.
Relevant rules:
C11, 6.2.6.1p4: "Two values (other than NaNs) with the same object
representation compare equal"
C11, 6.5.9p3: "For any pair of operands, exactly one of the relations is
true."
But we see that the results for d1 and d2 differ and depend on the
optimizations level. Thus, yes, this is a trap representation in gcc.
The same is true for clang.
Source code:
----------------------------------------------------------------------
#include <string.h>
#include <stdio.h>
int main()
{
long double d1, d2;
memset(&d1, 'A', sizeof d1);
memcpy(&d2, "AAAAAAAAAAAAAAAA", sizeof d2);
printf("%d %d\n", d1 == d1, d2 == d2);
}
----------------------------------------------------------------------
gcc (GCC) 7.0.0 20160614 (experimental):
----------------------------------------------------------------------
$ gcc -std=c11 -pedantic -Wall -Wextra test.c && ./a.out
0 0
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
0 1
----------------------------------------------------------------------
clang version 3.9.0 (trunk 271312):
----------------------------------------------------------------------
$ clang -std=c11 -Weverything test.c && ./a.out
0 0
$ clang -std=c11 -Weverything -O3 test.c && ./a.out
1 0
----------------------------------------------------------------------
