[Bug target/71475] [5/6/7 Regression] Optimization of copying into long double looses bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71475 --- Comment #9 from Alexander Cherepanov --- On 2016-06-12 00:59, joseph at codesourcery dot com wrote: >> Ok, what about this: > > This bug is closed as INVALID. No-one will pay any attention to comments > on a closed bug proposing different examples that might or might not be > valid and might or might not be related. Different examples should go in > different bugs; such bugs can be closed as duplicates if necessary. I see, thanks for the explanation! I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71522 . Indeed, it's better to treat it as a separate issue. OTOH this PR could be used as an reference about trap representation in long double.
[Bug target/71475] [5/6/7 Regression] Optimization of copying into long double looses bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71475
--- Comment #8 from Alexander Cherepanov ---
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
#include
int main()
{
long double d1, d2;
memset(, 'A', sizeof d1);
memcpy(, "", 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
--
[Bug target/71475] [5/6/7 Regression] Optimization of copying into long double looses bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71475 --- Comment #7 from joseph at codesourcery dot com --- On Fri, 10 Jun 2016, ch3root at openwall dot com wrote: > Ok, what about this: This bug is closed as INVALID. No-one will pay any attention to comments on a closed bug proposing different examples that might or might not be valid and might or might not be related. Different examples should go in different bugs; such bugs can be closed as duplicates if necessary.
[Bug target/71475] [5/6/7 Regression] Optimization of copying into long double looses bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71475
--- Comment #6 from Alexander Cherepanov ---
Ok, what about this:
--
#include
#include
int main()
{
long double d;
char s[sizeof(long double)];
memcpy(, "AAA", sizeof d);
memcpy(, , sizeof s);
printf("%s\n", s);
}
--
Results:
--
$ gcc -std=c11 -pedantic -Wall -Wextra test.c && ./a.out
AAA
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
--
gcc version: gcc (GCC) 7.0.0 20160608 (experimental)
[Bug target/71475] [5/6/7 Regression] Optimization of copying into long double looses bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71475 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jakub Jelinek --- So you're trying to construct Intel extended double with 0x4141414141414141LL mantissa, 0 MSB of mantissa, exponent 0x4141 and sign bit of 0. E.g. https://en.wikipedia.org/wiki/Extended_precision says on this: Unnormal. Only generated on the 8087 and 80287. The 80387 and later treat this as an invalid operand. I think you are just in the teritory of undefined behavior this, glibc probably doesn't check carefully enough that the value you're passing to it the first time is invalid, and in the second time, the compiler when it sees invalid value as it transforms it into its internal representation and back, it transforms it into something valid.
[Bug target/71475] [5/6/7 Regression] Optimization of copying into long double looses bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71475 Jakub Jelinek changed: What|Removed |Added Summary|[6/7 Regression]|[5/6/7 Regression] |Optimization of copying |Optimization of copying |into long double looses |into long double looses |bytes |bytes --- Comment #4 from Jakub Jelinek --- Ah, actually if you don't just talk about the undefined bytes in the padding, but those part of the XFmode value, this is something that regressed with r213045.
