Processor-specific code

[FX Coudert]

> You'll find that globally changing the rounding mode will screw up
> libm functions.  Which is pretty much going to make this useless.

OK. I didn't know that, and it's going to be annoying. So, the GNU libm 
doesn't enable us to call mathematical function with non-default 
rounding mode? IIUC, this is a requirement for the Fortran standard.

> Further, when folks need rounding modes other than round-to-nearest,
> they tend to need to switch rounding modes during the program too.

Yes. And we will need that too, and once the code for doing such things 
is written, we can employ it whenever we want to.

> Thus I think an environment variable to do this is doubly useless.

Your point is good for GFORTRAN_FPU_ROUNDING. There are other variables, 
such as GFORTRAN_FPU_PRECISION, which I do not think is very isefull; 
others (GFORTRAN_FPU_UNDERFLOW, GFORTRAN_FPU_DIVIDE and such) control 
whether a FPE should be raised whenever we encounter an underflow, or a 
division by zero.

I only began to write such code because the current gfortran code 
actually reads those environnement variables, and does not act upon 
them. If we decide that some of those are useless, that's fine with me, 
but we need to remove then from the code. So, here, I'm mainly speaking 
to the gfortran gurus: what do you think of thoses variables (3 types of 
environment variables, for rouding mode, precision and controlling FPE). 
Which do you think we want to implement, and which do we remove?

> All that said, C99 has <fenv.h> to control just about anything you
> could want about the fpu.

No, you can't control FPEs or precision, for example. AFAIK, those need 
special functions (for i387-linux, e.g.) or assembly code (for ppc-darwin).

FX