Re: GAS .fpu directive

[Renato Golin <renato dot golin at linaro dot org>]

On 28 August 2014 12:05, Richard Earnshaw <rearnsha@arm.com> wrote:
> Because it's partial at best and some folks like to consider warnings as
> fatal.

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
respect that.

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
still stands.

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:

.cpu cortex-a15
.fpu neon

.text
...
.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
choices.

cheers,
--renato