https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600
Jakub Jelinek changed:
What|Removed |Added
URL||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600
Jakub Jelinek changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600
--- Comment #5 from Jakub Jelinek ---
Actually, I think this is a glibc bug rather than gcc, because the values
computed at compile time look right, rather than those at runtime.
Consider:
int e = 69;
int main() {
long double a =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600
--- Comment #4 from Jakub Jelinek ---
Printing the numbers in detail (for all of them the long double and the two
double portions after that)):
a -0x1.f1d5d27f89914ab924b2cd0995p+69 -0x1.f1d5d27f89915000p+69
0x1.51b6d34cbd9ac000p+15
b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600
--- Comment #3 from Matthias Kretz (Vir) ---
I should be more precise. Take this test case:
int e = 69;
int main() {
__ibm128 a = -__builtin_ldexpl(
1.9446689187403240306919491832695730985733566864714824565497322973045558e+00l,
e);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600
--- Comment #2 from Matthias Kretz (Vir) ---
The runtime modf actually returns a large number. This is not about precision
but about completely bogus values. You can adjust the testcase to:
int e = 69;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
