This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Doc update for attribute
- From: Georg-Johann Lay <avr at gjlay dot de>
- To: Carlos O'Donell <carlos at redhat dot com>
- 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: Wed, 21 May 2014 14:41:08 +0200
- 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> <537B5949 dot 7070104 at redhat dot com>
Am 05/20/2014 03:31 PM, schrieb Carlos O'Donell:
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
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
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.
It won't work to let the compiler pick the used registers.
Referencing the variables by name and letting gcc emit the right
register is useful, but only if it works consistently and today it
In order to use the passed arguments, you must know the ABI and how / where the
arguments are passed. Then the asm template can use this information
explicitly, but the asm itself still has no arguments.
The hook mentioned above is to avoid extra code besides (non-existing)
pro/epilogue and the asm itself. So that naked function with arguments and asm
without arguments work at any optimization level.
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.