Re: [PATCH] MIPS: Add a GNU attribute for -mips32 -mfp64 objects

[Thiemo Seufer <ths at networkno dot de>]

Joseph S. Myers wrote:
> On Wed, 14 Nov 2007, Thiemo Seufer wrote:
> 
> > While I wrote this patch I noticed that the tagging takes only place
> > when the respective gnu_attribute is found in the source code. This
> > leaves objects created from assembly untagged. I wonder if it is a good
> > idea to generally add a FP ABI attribute, derived from the assembler's
> > command line flags, unless this is overridden by a gnu_attribute
> > directive in the source. Is there a backward compatibility issue I fail
> > to see, or some other effect which makes this a bad idea?
> 
> I didn't think the compiler passed the -msoft-float/-mhard-float ABI 
> information to the assembler, so this could cause problems with incorrect 
> tagging when older compilers are used with newer assemblers.

The compiler currently doesn't pass down the -m*-float options. So
the assembler won't see the option, and therefore won't tag the object.
The -mfp64 is passed, but it is AFAICS unlikely to generate invalid
tagging: Presumably the reason to use the compiler's -mfp64 option is
to generate 64-bit FP code, which isn't compatible to the other variants
as soon as e.g. a mfhc1 instruction is used.

The idea is to pass the relevent options to the assembler (at least for
.s/.S source files, for compiler generated files it would be redundant).

> The ABI is a 
> separate matter from what instructions are enabled, and a valid ABI is 
> being compatible with both hard and soft float; a file with purely integer 
> instructions could be a soft-float file if the functions are taking 
> floating-point parameters, or a file compatible with both if they are 
> taking integer parameters.  How would you deduce the C language function 
> call compatibility of an object (which is what the attributes describe) 
> from the assembler source and command line options?

I think of all those, soft-float and "no-float" are the only compatible
ones. They would stay link compatible, as "no FP option" means tag 0.

A hard-float object which happens not to use floating point at all wouldn't
be link compatible any more, this is the same effect which was evidently
regarded as acceptable in newer GCC compilers.


Thiemo