> > BTW, Mouse: GCC already avoids this tactic on chips for which FP
> > registers do not hold arbitrary values (i386, m68k, to name a
> > couple).  Please, give them _some_ credit.
> 
> Um, then, I guess I don't understand.  Surely it's easy enough to avoid
> it on any machine, then, just by telling gcc that the FP registers work
> like the i386 or m68k FP registers and can't hold arbitrary values?  I
> thought someone said that it was difficult to teach gcc to not do this,
> which seemed at odds with gcc already knowing how to not do this.

It's not necessarily that trivial.  It depends on the way the ISA works.   
In particular it can depend on how integer<->float conversion is done.

If the processor converts integers to floats by loading an integer into a 
floating-point register and then running a conversion instruction on the 
result, then gcc *has* to have rules to allow integer-values to be loaded 
into floating point registers[1].  Once you have that then the compiler 
will see that it's possible for a floating point register to hold any 
value and it can try to make use of that.

If simply transferring an integer value into a floating point register 
will cause a conversion to happen then there is no need for the compiler 
to have rules that allow arbitrary integers to be loaded into floating 
point registers.  Without the rules to load integer values into floating 
point registers then FP registers will never get used for general-purpose 
copying.

R.

[1]  Not strictly true, it is possible to not give the compiler any rules 
to load an integer value directly into a floating point register from 
memory; in that case the compiler has to load the value into an integer 
register and then move it to the floating point unit.  But that can lead 
to sub-optimal code if those instructions do exist and the compiler is 
just unaware of them.