Re: [PATCH 1/2] Add support for O32 FPXX ABI

[Richard Sandiford <rdsandiford at googlemail dot com>]

Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
>> > I propose a further option to fix this. -minfer-abi and .module infer-
>> fpabi.
>> 
>> No!!! :-)  Even more options would just make things unnecessarily
>> complicated.
>> Anything passing the command-line options or generating the .module
>> should
>> say what the ABI is instead.
>
> Are you saying you think the user should have to write .gnu_attribute
> 4,5 or .gnu_attribute 4,6 to get any FP ABI attribute other than 'any'?
> Your comment below suggests not...

The command line, .module and .gnu_attribute can all be used to set
the FP ABI.

>> The general principle is that an asm file can include code that requires
>> features outside the module-level setting.  We should never infer
>> anything about the global FPU ABI from something like an ADD.D that
>> we happen to see.  It might be that the ADD.D is part of an ifunc
>> (or similar mechanism) that only runs when an FPU is available.
>> 
>> IMO we should just leave the FPU ABI as "any" unless a command-line
>> option,
>> .module or .gnu_attribute says what the ABI actually is.
>
> My problem is with the command line options, not .module. The writer of
> the code has control over .module but not over the command line
> options. I.e. consider a toolchain prepared with --with-fp=xx and a
> toolchain prepared with --with-fp=32/default. Depending on the toolchain
> used then any hand-crafted assembly code may be tagged with an
> incompatible FP ABI. While we could validly assume that options like
> -mfpxx won't be used explicitly by people building code that they did
> not write... implied options from the toolchain mean that the compiler
> driver may use them. For FPXX to work we have to enable linux
> distributions to include a compiler that is FPXX by default to
> facilitate the transition but do so safely. Any thoughts on how to make
> this safe?

We fundamentally can't make it safe, in the sense that an asm file
without an explicit annotation by definition doesn't say what ABI
it uses.  The same problem occurs if using inline asms in a C compilation.
If you use a header file with floating-point inline asms, those asms
will be included in code whose .module or .gnu_attribute is dictated by
the GCC command-line options.  There's no guarantee that the inline asms
are safe for all such .modules or .gnu_attributes.  The problem isn't
specific to the assembler command line.

If command-line options are given, we need to assume that that's the
output that the user wants.  We can detect cases where there are
"obvious" breaches of the ABI outside of an appropriate push/pop, but
IMO it should be that way around: assume that the command-line, .module
or .gnu_attribute (in increasing order of precedence) specify the ABI
correctly and report a diagnostic when the code seems to be something
else.

Thanks,
Richard