This is the mail archive of the
mailing list for the binutils project.
Re: GAS .fpu directive
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Renato Golin <renato dot golin at linaro dot org>
- Cc: Matt Thomas <matt at 3am-software dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Thu, 28 Aug 2014 12:05:25 +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>
On 27/08/14 18:48, Renato Golin wrote:
> On 27 August 2014 17:41, Richard Earnshaw <firstname.lastname@example.org> 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
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.
>> 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.