Re: [PATCH, MIPS] .gnu.attribute support for sdemtk -mno-float

[Jim Wilson <wilson at codesourcery dot com>]

On Sat, 2010-05-01 at 09:18 +0100, Richard Sandiford wrote:
> ...why is it relevant that -mno-float links to a library without the
> soft-float routines (or indeed any float routines)?

I was just trying to explain what -mno-float does.  I am not sure who
all is familiar with it, as only the sdemtk target supports it, and this
target was apparently not actively maintained in the FSF tree.

> Or to put it another way: -mno-float only differs from -msoft-float in the
> way that its libraries are constructed.  There is no difference in the
> compiler itself beyond the set of preprocessor macros that are defined.
> I'm uncomfortable with the idea of .gnu_attribute being used to model
> things that are related to preprocessor macros rather than code generation.

I don't know the original justification for this work.  It was done at
MTI, and most of the original people aren't available for questions
anymore.  I can see a purpose here though.

Suppose you are a 3rd party library vendor, and you want to build and
distribute a library compatible with an MTI and/or CodeSourcery
toolchain.  Your library does not use any FP code.  And yet, because of
the FP ABI encoded into .gnu_attribute, you must build and distribute 4
different versions of your library compiled for the 4 different FP ABIs.
The -mno-float option solves this problem.  It is a compile time
assertion that there is no FP code, and hence the result is compatible
with all 4 FP ABIs.  If you compile with -mno-float, you now need only
one version of the library for the different FP ABIs.

It is true, the current implementation of -mno-float only differs in
library construction and preprocessor macros.  It is possible that
future implementations could do more to verify the compile-time
assertion.  Meanwhile, however, the main purpose of the -mno-float
option is currently not being served, because an important piece is
missing, the gnu_attribute setting.  I believe the .gnu_attribute patch
should be added in, irrespective of whether the -mno-float
implementation is improved.  I think improving the -mno-float
implementation to do more compile-time checking for FP code should be a
separate issue.

Jim