Re: fixing ARM aeabi fesetround and friends

[Daniel Jacobowitz <drow at false dot org>]

There's no dependable way to get the desired result, because (unlike
on some other platforms) it's easy and common to link soft-float and
VFP code together.  For instance:

arm-none-linux-gnueabi-gcc -mfloat-abi=softfp -c first.c
arm-none-linux-gnueabi-gcc -mfloat-abi=soft -c second.c
arm-none-linux-gnueabi-gcc first.o second.o

So if first.c calls fegetround, it ought to succeed.

IMO the right way to do this is either what Joseph described:

> One approach would be for the __aeabi_* software floating-point functions 
> to use VFP is VFP is available at runtime, so that binaries built for 
> software floating point will use the VFP instructions if available (slower 
> than building them for VFP directly, faster than them using software).  

Or, take a compromise position that uses slower
rounding-mode-sensitive softfp functions and save the rounding mode
somewhere they can find it.  That, in turn, can be done two ways:
either by making them read the VFP state if there is one, or by making
even the VFP versions of the rounding mode functions set the software
emulation rounding mode.

The compromise position is useful if you care about rounding in
soft-float mode; the former is useful if you care about performance of
soft-float code on hardware systems.  No reason we couldn't do both.

There are some other ways we could implement the optimized functions,
including the upcoming STT_GNU_IFUNC mechanism that Ulrich Drepper
is adding to glibc.  That's simpler than having separate libraries,
but does add some dynamic linker overhead.  Or, we could check at
runtime in the soft-float functions whether a VFP unit is present.
But that's got its own overhead.

-- 
Daniel Jacobowitz
CodeSourcery