https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #14 from joseph at codesourcery dot com ---
On Tue, 29 Nov 2016, bergner at gcc dot gnu.org wrote:
> Using gdb, I see:
>
> (gdb) info registers f1 f2
> f1 27 (raw 0x403b)
> f2 -3.08148791101
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #13 from Breno Leitao ---
(In reply to Bill Schmidt from comment #11)
> Breno, what is your environment? Which glibc is present?
We found this problem originally on Debian[1], but we tested and reproduced it
even on Big Endian distr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #12 from Bill Schmidt ---
Ah, I was incorrect about that. If I use -O0, the test produces 26 in my
environment as well. At higher optimization the whole computation is folded.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #11 from Bill Schmidt ---
Breno, what is your environment? Which glibc is present?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #10 from Bill Schmidt ---
OK, that accounts for it. That would be a glibc problem.
Building this code with GCC trunk on Ubuntu 14.04 with glibc 2.19, the program
produces 27 as expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #9 from Peter Bergner ---
(In reply to jos...@codesourcery.com from comment #7)
> What are the actual high and low doubles in the return from powl? The
> simplest reason for the reported result here would be that powl returns a
> r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #8 from Bill Schmidt ---
At the time, Breno reported 0x403b as the high half, which is
accurate. Looking back, I didn't get a report of the low half. If somehow
that were produced as a negative number, that would also a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #7 from joseph at codesourcery dot com ---
What are the actual high and low doubles in the return from powl? The
simplest reason for the reported result here would be that powl returns a
result very slightly less than 27 (which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #5 from Bill Schmidt ---
Andreas, it can't be a lack of accuracy, because 27.0 = 2^4 x 1.6875. There
can't be any rounding error; this is an exact number in all floating-point
representations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #4 from Andreas Schwab ---
Why do you think this isn't a lack of accuracy? Floating to integer always
truncates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #2 from Andreas Schwab ---
Why do you think 27 is wrong?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #1 from Bill Schmidt ---
The conversion is done by __fixtfdi in libgcc.
15 matches
Mail list logo
