This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Doc update for attribute
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Georg-Johann Lay <avr at gjlay dot de>
- Cc: David Wohlferd <dw at LimeGreenSocks dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Andrew Haley <aph at redhat dot com>, Richard Sandiford <rdsandiford at googlemail dot com>
- Date: Tue, 20 May 2014 09:31:53 -0400
- Subject: Re: RFC: Doc update for attribute
- Authentication-results: sourceware.org; auth=none
- References: <53718DCF dot 4030303 at LimeGreenSocks dot com> <537647F8 dot 9060306 at redhat dot com> <537B0B7B dot 6020300 at gjlay dot de>
On 05/20/2014 03:59 AM, Georg-Johann Lay wrote:
> Am 05/16/2014 07:16 PM, schrieb Carlos O'Donell:
>> On 05/12/2014 11:13 PM, David Wohlferd wrote:
>>> After updating gcc's docs about inline asm, I'm trying to
>>> improve some of the related sections. One that I feel has
>>> problems with clarity is __attribute__ naked.
>>>
>>> I have attached my proposed update. Comments/corrections are
>>> welcome.
>>>
>>> In a related question:
>>>
>>> To better understand how this attribute is used, I looked at the
>>> Linux kernel. While the existing docs say "only ... asm
>>> statements that do not have operands" can safely be used, Linux
>>> routinely uses asm WITH operands.
>>
>> That's a bug. Period. You must not use naked with an asm that has
>> operands. Any kind of operand might inadvertently cause the
>> compiler to generate code and that would violate the requirements
>> of the attribute and potentially generate an ICE.
>
> There is target hook TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS that is
> intended to cater that case. For example, the documentation
> indicates it only works with optimization turned off. But I don't
> know how reliable it is in general. For avr target it works as
> expected.
>
> https://gcc.gnu.org/onlinedocs/gccint/Misc.html#index-TARGET_005fALLOCATE_005fSTACK_005fSLOTS_005fFOR_005fARGS-4969
It's still a bug for now. That hook is there because we've allowed
bad code to exist for so long that at this point we must for legacy
reasons allow some type of input arguments in the asm. However, that
doesn't mean we should actively promote this feature or let users
use it (until we fix it).
Ideally you do want to use the named input arguments as "r" types to
avoid needing to know the exact registers used in the call sequence.
Referencing the variables by name and letting gcc emit the right
register is useful, but only if it works consistently and today it
doesn't.
Features that fail to work depending on the optimization level should
not be promoted in the documentation. We should document what works
and file bugs or fix what doesn't work.
Cheers,
Carlos.