This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: real.c implementation
- From: Stephen L Moshier <steve at moshier dot net>
- To: gcc at gcc dot gnu dot org
- Date: Fri, 25 Oct 2002 21:00:46 -0400 (EDT)
- Subject: Re: real.c implementation
>On Tue, Oct 22, 2002 at 02:11:27PM -0400, Robert Dewar wrote:
>> > We do now. We did have code in the compiler to prevent this
>> > (unconditionally, mind!) until recently; I considered this a
>> > bug and removed it. If you don't want to trap on denormals,
>> > then don't write denormal constants. Simple as that.
>>
>> Well not quite as simple, you are asking people to do careful
analysis
>> of legacy code and tailor parts of it in a target dependent manner.
>
>No, we were asking them to do that before, since when they
>wrote 2**-149, we *silently* gave them 0.
If you write 10^-4000 to an IEEE double, the nearest representable
value is zero, the compiler generates zero and there is no warning.
In this other case the target machine's arithmetic is flush-to-zero.
In that system, the closest representable number to your example is zero
so the compiler should generate zero. If the alpha people wanted a
warning, which they did not, check_float_value could give a warning.
>Anyway, if they leave nothing unchanged, they'll get a SIGFPE,
>which can be fixed immediately by using -mieee.
They enable the flush to zero mode deliberately because it is faster
than IEEE mode, or because they are running a VAX program. In those
cases they don't want to use mieee.