> > Fast floating point would be good, but only if it is IEEE compliant.  
> > Anything else is going to cause problems for a lot of others.  Don't 
> > forget that understanding of the IEEE data format is embedded deeply 
> > within many programs and libraries (starting with, but not limited to 
> > libc, gcc, gas, gdb ...)
> 
> As a programmer of numerical math, I say that programs depending on
> the format of floating point numbers, are bad  And yes, there are a
> lot of bad programs out there. I needed it for my own numerical work,
> where speed is indeed much more important than compliance to some
> irrelevant standard. Besides, I had planned on just letting floats
> be fast, while doubles was to be IEEE.

You miss the point.

How can the system library efficiently implement atod or printf if it 
doesn't understand the underlying format?  How can a compiler 
(particularly a cross compiler) optimise "double x = 1.0 + 33.5" if it 
doesn't know the rules for safe constant folding?  How can an assembler 
(again, particularly a cross-assembler) generate the object implementation 
for .double 5.0 if it doesn't know the binary representation?

In the end, something has to know what the translation between the binary 
and human formats are.  I accept that there are too many user programs 
that abuse this ability to know; but many system programs *need* to know 
this in order to function correctly.  There's no system call that will 
tell a compiler that the size of a double is 8, it just has to know this.

> > I've seen installations where the compiler looks at the machine its 
> > running on and then generates code for that type of machine by default.  
> > They suck.  It causes no end of support issues when you ship a binary to a 
> > customer with a different configuration.
> 
> That is a good point. But most code compiled locally are used locally,
> and people making software for shipping are usually competent enough
> to specify a compatibility switch when compiling. That is why I think
> optimizing for speed should be default. It is often possible to make
> a compromize where one gets just a few percent loss in speed for a usable
> large degree of portability.

In my experience you've got this backwards.  Release engineers have more 
than enough to do than to mess with options such as this (and many 
platforms different to work on).  If these options aren't selected until a 
release is being made, then tests suddenly start to fail, the option gets 
forgotten (and hence non-working code gets shipped which looks bad at the 
customer site -- slower code might cause grumbles; non-functioning code 
will probably cause a customer to look elsewhere [I think you've done that 
yourself]).

Finally, developers writing the code are the ones who will best know when 
its better to use a particular combination of options.  After all, they 
are the ones who know what the code is supposed to do.