This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] MIPS: Add a GNU attribute for -mips32 -mfp64 objects
Richard Sandiford wrote:
> Paul Koning <firstname.lastname@example.org> writes:
> >>>>>> "Richard" == Richard Sandiford <email@example.com> writes:
> > Richard> I agree with Joseph here. Although it's redundant to
> > Richard> specify -mfp64 with -msoft-float, it isn't actively wrong.
> > Richard> The options have traditionally been orthogonal. I don't
> > Richard> think the assembler should assume that -mfp64 implies
> > Richard> -mhard-float.
> > It seems strange, since -msoft-float means no float registers, while
> > -mfp64 says there are float registers and they are 64 bits wide.
> Well, -mhard-float and -msoft-float are ABI options. -mfp64 is
> an architectural configuration option, and only affects calling
> conventions when combined with -mhard-float.
But "-mhard-float -mfp64" constitutes a new ABI variant. This is
the case I want to cover. The "-msoft-float -mfp64" should stay
tagged as soft float object.
> It is perfectly
> possible to write code that conforms to the soft-float ABI while
> still using FPU instructions within a function.
I wonder how relevant this possibility is in practice. To me it
sounds too subtle to be of much use.
> (Strictly speaking,
> the use of FPU instructions is also part of the ABI. But it isn't
> what this attribute specifies; this attribute is about the calling
> The practical example of the difference is MIPS16. -mhard-float
> -mips16 doesn't say "use the FPU from MIPS16 code"; you can't.
> It says instead that the hard-float ABI is in effect, and that
> we need to use special stubs to interface with non-MIPS16 code.
And, for completeness, we have "-mips32r2 -mips16 -mhard-float -mfp64",
which tells the compiler to generate different stubs than the ones
needed for the standard hard float.