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: Richard Earnshaw <rearnsha at arm dot com>
- Cc: Matt Thomas <matt at 3am-software dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Thu, 28 Aug 2014 13:07:13 +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> <CAMSE1kegoq6Upp4auoEKcLnVTJH-z1bajj19s_0K=TxBTqdo0Q at mail dot gmail dot com> <53FE0A33 dot 9080808 at arm dot com> <CAMSE1kcY8DFgbv7XPTYTy5CFezvSM_XTi4EwD-oVv3b7FxSibQ at mail dot gmail dot com> <53FF0CF5 dot 3050506 at arm dot com>
On 28 August 2014 12:05, Richard Earnshaw <firstname.lastname@example.org> wrote:
> Because it's partial at best and some folks like to consider warnings as
I'm sure they will be happy to realise they've been doing something
wrong. But that's more of an LLVM opinion than a GNU one, and I
That's why, on my latest proposal (http://llvm.org/PR20757), the main
difference here is *only* that "directives in text won't change unit
level attributes". Everything else is optional.
> Consider the use case of
> gas -mfpu=neon
> then having .fpu vfpv3 inside the code. Are you going to warn for that
> as well? If not, why not?
It depends. Will said the directive overrides the argument, and that
The issue here is only between header and text flags. Multiple flags
in the header is also fine, last seen sticks, as is today.
The only difference is that, if a flag is seen in text, it shouldn't
change the global behaviour, only local. This is what's wrong with GAS
right now and should be fixed.
> Next consider cases where the assembler has built-in defaults.
That falls into the same category as compiler flags, since a default
is just an implicit flag.
> Finally, there's the case where no instructions are emitted between two
> .fpu directives (or code is emitted, but the directive has no effect on
> that code). Are you going to rule that out as well?
If you see my proposal in the bug I created (not my first emails, as
they were uninformed), you'll see that I don't want to remove any
feature nor warn on every potential problem.
1. Header directives shall warn when used in text and *only* change
the behaviour for instruction selection purposes, not for module-wide
properties (like build attributes).
2. If header directives are not present in the header, module-wide
properties will be inferred from the command line, architectural
descriptions, etc. even if they are present in the text.
3. The semantics of directives in text will be that they will change
only the specific behaviour they're related to and they will be valid
until another similar directive is issues or the end of file (compile
unit) is reached.
4. Related flags shall complement each other. So, .cpu cortex-a8 shall
set VFP3 and NEON, while .fpu vfp2 shall only unset VFP3, not NEON and
not move the CPU back to where VFP2 was the default. This is the
current behaviour and shall remain valid.
5. Duplicate header directives in the header generates a *different*
warning, but are accepted on a last come, last served basis. This can
be ignored, or only turned on with -Weverything.
6. Both warnings should become errors when in -Werror mode.
I also don't mention duplicated directives in text because they
shouldn't cause any harm other than setting flags for instructions
selection purposes. So, in the first round of changes, one would still
be able to write:
.fpu vfp2 // downgrade vfp, keep neon
.fpu vfp3 // upgrade vfp
.fpu vfp4 // upgrade vfp again
Weather those warnings are enabled with -Wall or -Weverything or
-pedantic is up to the specific assembler. I'd prefer to enable that
by default, you would prefer not, and those are both perfectly valid