This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: real.c implementation
- From: dewar at gnat dot com (Robert Dewar)
- To: aph at redhat dot com, gcc at gcc dot gnu dot org
- Date: Tue, 22 Oct 2002 06:38:09 -0400 (EDT)
- Subject: Re: real.c implementation
> I agree. gcj, if course, requires exact IEEE float conversion and
> relies on gcc to do it right,
Well what does this mean?
Are you talking about the IEEE requirements for float conversion
Or are you talking about last bit exact conversion (they are not the same,
you need arbitrary precision for last bit exact conversion).
And what about the issue of biased vs unbiased rounding. The IEEE standard
has nothing to say about this (more accurately, it requires the choice to be
delayed till runtime so that it is done with the current dynamic rounding,
but that's too silly to take seriously).
Just saying "exact" is not good enough here.
One thing I am not clear on for all ports is whether any of them trust
the assembler to do decimal to float conversion correctly. I know that
this was the case in GCC 2.8.1, and if you do that, the game gets lost
at the assembler level. It is definitely important to generate all
float constants in proper machine form in hex.