This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: fcmove on Alpha not qualified with /su when compiling -mieee - is that correct ?


Richard Henderson wrote:
> 
> On Mon, Jul 03, 2000 at 09:16:26PM +0200, Toon Moene wrote:
> > Hmmmm, fascinating - let's see if I can compile my own kernel ;-)
> 
> Or perhaps try the errata update kernel from Red Hat 6.2, which
> I believe to be 2.2.16 based.

Thanks for the hint ...

> > BTW, so what you're saying is:  It is immaterial whether you specify
> > -mieee w.r.t. denormals.  That's interesting, because I managed to
> > "cure" several fpe's in our code by just compiling it with -mieee 1).
> > Perhaps that was just a fortuitous side-effect.
> 
> No, that's not what I'm saying.  I'm saying that it's immaterial
> to the slow speed of the program whether you specify -mieee,
> since the processor is going to trap either way.
> 
> However, -mieee code should be handled by the kernel's software
> floating-point implementation, and the program should see SIGFPE
> iff such an exception is warrented by IEEE rules (SNaN or whatever,
> modulo the current IEEE exception mask).

Hmmm, yes - I see - according to Table B-2 of the Alpha Architecture
manual (Version 3, but that's probably not relevant), denormals that are
input to an instruction are always treated by an OS trap (apart from
floating point compare, load, store, copy-sign and - indeed - fcmove),
when the instruction was qualified with /s.  Does this mean that,
without /s, it is OS-implementation-defined what happens with
denormals-on-input on the Alpha ?

> > 1) Aside from the fact that I repaired a number of utterly
> > non-physical assumptions, like a water vapor saturation pressure
> > table starting from 13 K ...
> 
> Heh.
> 
> Interesting that someone would decide to start the table at 13 K rather
> than 0 K.  I mean, if you're not actually thinking about the realities
> of water to begin with, why would you think about 13 K rather than have
> the table be "complete"?

My pet theory is that the table first started at 130 K (more reasonable)
with steps of 0.1 K.  Then someone decided that was not "precise" enough
and constructed a table with 0.01 K steps, but kept the lower bound at
1300 ...  (Note, it's not just water but H2O as either ice or water -
the funny thing about 13 K is that there is no `air' in which vapor
pressure has a meaning).

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]