Re: GAS .fpu directive

[Richard Earnshaw <rearnsha@arm.com>]

On 27/08/14 18:48, Renato Golin wrote:
> On 27 August 2014 17:41, Richard Earnshaw <rearnsha@arm.com> wrote:
>> It depends on whether "incorrect" here means "if you don't know what
>> you're doing you can foul things up; but if you're careful, this is very
>> powerful", or whether it means, "this is fundamentally broken".
> 
> The difference between "powerful" and "broken" is if you hit the edge
> cases or not. The C++ standard has some clear rules about undefined,
> unspecified or implementation defined behaviour, and I believe this
> case is of a similar trait. All I'm asking is to acknowledge that this
> is undefined and that users should be made aware of the problems, at
> least via a warning. In my view, a tool is fundamentally broken if it
> allows broken edge cases to pass all checks, and that's exactly what
> both assemblers are doing in this case.
> 
> The one fundamentally broken issue is the context. It seems that Power
> has the ability to push/pop features, which fixes it. We don't. I'm
> trying to mitigate the issues by warning the user on dangerous
> behaviour, and later on to restrict usage (or at least the context) to
> a more sane semantics.
> 
> Whether the latter is done or not should not stop the former from
> being done. I can't see how a warning on multiple directives would
> hurt anything, to be honest.
> 

Because it's partial at best and some folks like to consider warnings as
fatal.  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?  But this is a very practical case where the
code has to work and a warning would be incorrect.

Next consider cases where the assembler has built-in defaults.

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?

As I say, this is all quite complex and making changes without working
through all the use cases is potentially going to cause more problems
than it solves.

R.

> 
>> What I don't want to see is someone tinkering with what is clearly a
>> fragile API and causing problems for existing toolchains without having
>> worked through the issues.
> 
> That's why I sent the email to the list, to collect ideas and more
> edge cases. I've done the homework before contacting the list, but I
> can't possibly do that to all architectures on my own, and I'm not
> experienced enough to do that comprehensively even for ARM, without
> resorting to people like you to validate my findings.
> 
> I really appreciate your support and I understand that this is not
> high priority.
> 
> cheers,
> --renato
>