David Edelsohn wrote:

> Matt> That seems to be a rather big hammer to smash that fly.  Any other
> Matt> way to make moves not use FP?  Allow floating point, but only if
> Matt> the program is using floating point types.
> 
> 	No.  Either you allow the compiler to use the FPU or you don't.
> There is no safe and reliable way to implement the policy that you
> request.  The request of the compiler ultimately is inconsistent: you are
> telling it to enable the the FPU and FPRs, but somehow "know" when you
> really want it used.  Expecting DWIM behavior will lead to problems.

Is this a new optimization in GCC V3?  We're currently using the Wind
River rendition of GCC ~2.95 (which they dub 2.96) for our VxWorks
platform.  It generates floating point moves from floating point source,
and integer moves from integer source.  ie: for

  long long a, b;  a = b;

it generates a pair of lwz instructions followed by a pair of stw,
whereas for

  double a, b; a = b;

it generates an lfd followed by a stfd.

One of the the problem with -msoft-float is that, for code that actually
does FP stuff at least, GCC generates calls to library routines that
aren't provided with the compiler, nor it seems, are they provided with
NetBSD.  For example, there's no "__muldf3" anywhere that I can see.

--Doug.