From: Martin Sebor <msebor@gmail.com>
To: Sandra Loosemore <sandra@codesourcery.com>,
Jeff Law <law@redhat.com>,
Gcc Patch List <gcc-patches@gcc.gnu.org>
Subject: Re: [doc PATCH] document when GCC ignores attribute aligned
Date: Tue, 04 Dec 2018 18:42:00 -0000 [thread overview]
Message-ID: <28f9005d-0ba1-09f6-750c-4b5369b39751@gmail.com> (raw)
In-Reply-To: <1b7d7cd7-065b-48bf-1693-33b69263a53e@codesourcery.com>
On 12/4/18 12:20 AM, Sandra Loosemore wrote:
> On 12/3/18 8:23 PM, Martin Sebor wrote:
>> Last week we agreed to clarify that attribute aligned on a function
>> can decrease its alignment if it hasn't been previously declared
>> with one. Attached is this change.
>>
>> Besides the above, I also mention that the attribute specifies
>> the alignment of the first instruction of the function (in case
>> that wasn't obvious) , and that it has no effect in the absence
>> of a definition.
>>
>> I wrote some tests to convince myself this actually works as
>> I expected. Where it does I add those tests to the testsuite
>> via this patch. Where it doesn't I opened a bug (PR 88345).
>>
>> Martin
>
>> Index: gcc/doc/extend.texi
>> ===================================================================
>> --- gcc/doc/extend.texi   (revision 266766)
>> +++ gcc/doc/extend.texi   (working copy)
>> @@ -2386,16 +2386,20 @@ and may not be available on all targets.
>> Â @itemx aligned (@var{alignment})
>> Â @cindex @code{aligned} function attribute
>> Â The @code{aligned} attribute specifies a minimum alignment for
>> -the function, measured in bytes. When specified, @var{alignment} must
>> -be an integer constant power of 2. Specifying no @var{alignment}
>> argument
>> -implies the maximum alignment for the target, which is often, but by no
>> -means always, 8 or 16 bytes.
>> +the first instruction of the function, measured in bytes. When
>> specified,
>> +@var{alignment} must be an integer constant power of 2. Specifying no
>> +@var{alignment} argument implies the ideal alignment for the target,
>> +which is often, but by no means always, 8 or 16 bytes. The attribute
>
> I think you might as well delete the end of the sentence starting with
> "which is often...". It adds words but no useful information. (Maybe
> it's 8 bytes, maybe it's 16 bytes, maybe it's something else....)
I added those words in r265498. I was hoping to give people
an idea of roughly what they might expect because I couldn't
think of a good way to find out. But since then I realized
that the __alignof__ operator can be used to query this
alignment and I agree that the sentence isn't helpful anymore
(maybe it never really was). I've replaced it with a reference
to __alignof__ instead and checked in r266792.
Martin
>
>> +has no effect when a definition for the function is not provided in
>> +the same translation unit.
>>
>> -You cannot use this attribute to decrease the alignment of a function,
>> -only to increase it. However, when you explicitly specify a function
>> -alignment this overrides the effect of the
>> -@option{-falign-functions} (@pxref{Optimize Options}) option for this
>> -function.
>> +The attribute cannot be used to decrease the alignment of a function
>> +previously declared with a more restrictive alignment; only to increase
>> +it. Attempts to do otherwise are diagnosed. Some targets specify
>> +a minimum default alignment for functions that is greater than 1. On
>> +such targets, specifying a less restrictive alignment is silently
>> ignored.
>> +Using the attribute overrides the effect of the
>> @option{-falign-functions}
>> +(@pxref{Optimize Options}) option for this function.
>>
>> Â Note that the effectiveness of @code{aligned} attributes may be
>> Â limited by inherent limitations in the system linker
>
> This patch is OK with the above nit fixed.
>
> -Sandra
prev parent reply other threads:[~2018-12-04 18:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-04 3:23 Martin Sebor
2018-12-04 7:20 ` Sandra Loosemore
2018-12-04 18:42 ` Martin Sebor [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=28f9005d-0ba1-09f6-750c-4b5369b39751@gmail.com \
--to=msebor@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=law@redhat.com \
--cc=sandra@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).