fenv.h fixes for softfloat

David Schultz das at freebsd.org
Fri Jan 20 17:55:39 UTC 2012


On Fri, Jan 20, 2012, Ian Lepore wrote:
> On Tue, 2012-01-17 at 15:15 -0500, David Schultz wrote:
> > If declaring the flags variable volatile is enough to get things
> > working, more or less, then perhaps we ought to do that until we
> > have a real 21st-century compiler.
> 
> I've been pondering this for a couple days, and I think it's probably a
> good idea.  The problem seems to be that the compiler and optimizer are
> unaware of the fact that the fenv stuff can change across certain
> operations, and 'volatile' tells the compiler exactly "this value can
> change in ways you are unaware of."  I can't think of any downside other
> than trying to figure out/remember 5 years from now why the variable is
> volatile, and that can be fixed with a little comment nearby.

To address another issue, I tweaked the implementation in r23036
so that none of the fenv routines are inlined anymore.  This
should achieve the same result as declaring the variables
volatile.  The compiler may still assume that it can reorder the
floating-point computations around the function calls, however.
That's partly what FENV_ACCESS is intended to address.

By the way, I checked in a new test in tools/regression/usr.bin/cc,
which covers some of the more rudimentary things about the compiler
and FP emulation than the libm tests do.  It might provide some
insight into what needs to be fixed for the libm tests to pass,
although I think I know what the answer is, and it's not clear
that it's worth the trouble of fixing.

> Oh, another thing I've been meaning to mention... Doesn't the mips
> platform also use software floating point?  If so, then I think
> libc/mips/gen/flt_rounds.c needs to be modified to look more like the
> one I did for arm, with separate software and hardware implementations.

Yes, probably.  I haven't looked at it much for lack of time, and
because of the difficulties of doing development for platforms I
don't have.  The MIPS code appears to have been copied from the
ARM code verbatim in most cases, so I'm fairly confident that it's
all wrong.


More information about the freebsd-arm mailing list