Only the following options would make sense:
1. An option to declare 100% IEEE compatibility if possible at all on
the particular arch, since it's a well known reference.
2. An option to declare 100% FPU architecture exposure.
3. A set of highly target dependent options to control some well
defined features of a particular architecture. (Rounding mode,
controll, use of MMX or SSE[1234567] for example...)
I would replace 3 above with:
3. When compiled without either of the above options, adhere
strictly to
the relevant language standard.
Given that Java, Fortran 95, C and C++ all have differences in their
definitions of floating-point, this will need to be (as it already is,
to some extent) language-specific.
Any kind of abstraction between point 1. and 2. and I would see
myself analyzing the assembler output to see what the compiler
actually did anyway.
On further reflection, I don't see how a middle ground can even be
defined. The three states above seem to make sense: IEEE, hardware, or
language standard.
And last but not least: Most of this isn't really interesting at the
compilation unit level at all. This is the completely uninteresting
scope. If anything one should discuss about the pragma directive
level, since this is where fine control of numerical behavior happens
in the world out there. The ability to say for example:
#pragma unroll 4 sturd 8
would be really of "infinite" more value then some fancy -fblah-blah.
GCC seems to have a fancy for options, since that is what most people
ask for. I agree that a set of "tuning" pragmas would be a good way of
defining the compilation requirements for a given algorithm.