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

[Richard Sandiford <rsandifo at nildram dot co dot uk>]

Thiemo Seufer <ths@networkno.de> writes:
> 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).

I agree with Joseph here.  Although it's redundant to specify -mfp64
with -msoft-float, it isn't actively wrong.  The options have traditionally
been orthogonal.  I don't think the assembler should assume that -mfp64
implies -mhard-float.

I agree that it's a good idea to make -mfp64 -mgp32 a separate value for
the existing attribute (rather than introducing a new attribute, say).
But at the moment, only the compiler or assembly programmer knows the
right value for the attribute.

FWIW, I think it would be perfectly OK to add an extra case to gcc's
attribute code now, even though we're in stage 3.  I'll volunteer to
do that if you don't have a patch already.

Richard