This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GAS .fpu directive

On 27 August 2014 01:56, Matt Thomas <> wrote:
> You could have something
> .fpu neon
> <function neon>
> .fpu vfp2
> <function vfp2>

There is no way of poping context, so the .fpu vfp2 would be valid for
the rest of the file unless you knew what the previous flag was and
added at the end of your sub-context. This is not always possible with
inline asm, or included asm, or even if the compiler is implementing

> and then the caller decides what routine to call depending on the presence
> of neon or not (GNU IFUNC per chance).  Same could be said for pre-r6 mips
> code and mipsr6 mips code.  Forcing them to be separate files seems harsh.

Between harsh and incorrect, I choose harsh any day.

> I would except the attributes emitted to first match the -mfpu=xxx
> option passed to gas, then the first .fpu directive encountered.

I think we all agree on this one, except when the first .fpu flag is
actually from an overriding snippet, say, an IFUNC implementation,
where you *don't* want that to be the default.

> Forcing them to be in the "header" makes cpp-processed assembly
> more painful than it should be.

The reason why I suggest that is outlined above. Again, better harsh
than incorrect.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]