This is the mail archive of the
mailing list for the binutils project.
Re: GAS .fpu directive
- From: Renato Golin <renato dot golin at linaro dot org>
- To: Matt Thomas <matt at 3am-software dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 27 Aug 2014 17:23:48 +0100
- Subject: Re: GAS .fpu directive
- Authentication-results: sourceware.org; auth=none
- References: <CAMSE1keWd0+uUS0fpaC3-yXsnN-z2_Bsa5anwvQAQwXgWuw_Yw at mail dot gmail dot com> <53F4C261 dot 8090900 at redhat dot com> <53F4CB31 dot 9080701 at arm dot com> <1408553484 dot 5894 dot 8 dot camel at otta> <CAMSE1kdDQOuuKhPcF8qasM-PMXBkAKDfjioCmYc39cORV3o4gA at mail dot gmail dot com> <1408562067 dot 5894 dot 23 dot camel at otta> <CAMSE1kfq3CoxR8KWOo6dzgoR4CxyLqyA+_o=ZVU_MfJwHf8-mA at mail dot gmail dot com> <6D39441BF12EF246A7ABCE6654B0235320EF4632 at LEMAIL01 dot le dot imgtec dot org> <CAMSE1kdvh+uVriMQV1LeJJYGVY-g7BcO0ZVsESiGUeXs132eBw at mail dot gmail dot com> <6D39441BF12EF246A7ABCE6654B0235320EF47F9 at LEMAIL01 dot le dot imgtec dot org> <B2E0E3AA-8421-4504-B1B9-3305AD6D394F at 3am-software dot com>
On 27 August 2014 01:56, Matt Thomas <email@example.com> 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