public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Jeff Law <law@redhat.com>, Gcc Patch List <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] handle expressions in __builtin_has_attribute (PR 88383)
Date: Thu, 13 Dec 2018 22:22:00 -0000	[thread overview]
Message-ID: <4e9198aa-3348-c45f-e3e7-7b3c23f94190@gmail.com> (raw)
In-Reply-To: <20181213195651.GZ12380@tucnak>

On 12/13/18 12:56 PM, Jakub Jelinek wrote:
> On Thu, Dec 13, 2018 at 12:48:18PM -0700, Martin Sebor wrote:
>>> The support is necessary in order to determine the attributes
>>> in expressions such as:
>>>
>>>     struct S { __attribute__ ((packed)) int a[32]; };
>>>
>>>     extern struct S s;
>>>
>>>     _Static_assert (__builtin_has_attribute (s.a, packed));
>>
>> An example involving types might be a better one:
>>
>>    typedef __attribute__ ((may_alias)) int* BadInt;
>>
>>    void f (BadInt *p)
>>    {
>>      _Static_assert (__builtin_has_attribute (*p, may_alias));
>>    }
> 
> So how is the builtin defined then?  Is the argument always an expression
> and you only return whether its type has the attribute, or do something
> different if the expression is of certain kind?

For a DECL the built-in looks at both the DECL_ATTRIBUTES and
the DECL's type's TYPE_ATTRIBUTES.  For expressions, it just
looks at TYPE_ATTRIBUTES of the expression's type.  I'm not
sure that this is necessarily the cleanest design but it's
meant to follow how attributes are applied to DECLs.  Sometimes
they get applied to the DECL itself and other times to its type.
This has been causing confusion to both users and GCC devs such
as myself so at some point I'd like to make this clearer somehow.
Not sure exactly how yet.

> Perhaps it would be better have two builtins, one would always take
> type from the expression, the other would only accept decls (or perhaps
> some syntax for the FIELD_DECLs).

I'm not sure I see a need for two built-ins here.

There is another way to handle the may_alias example: by using
typeof first and then the built-in on the result:

   _Static_assert (__builtin_has_attribute (__typeof__ (*p), may_alias));

so it seems that it would be possible to do what Jeff suggests
and only accept DECLs and TYPEs.  But I'm also not sure I see
an advantage of restricting the built-in like that.

FWIW, I had in mind two uses when I introduced the built-in:
1) a conditional attribute copy (where the condition would be
whether or not the source DECL or TYPE has some attribute), and
2) detecting that attributes have been successfully applied as
expected in tests.  I haven't implemented (1) yet but I'd like
to at some point (if only to avoid hardcoding into GCC the set
of attributes that are excluded from copying).  I have added
a handful of tests that make use of the built-in.  So if changes
should be made to the built-in, I will want to make sure they
don't make these use cases difficult.

Martin

  reply	other threads:[~2018-12-13 22:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-06  3:56 Martin Sebor
2018-12-13 18:59 ` Jeff Law
2018-12-13 19:21   ` Martin Sebor
2018-12-13 19:48     ` Martin Sebor
2018-12-13 19:56       ` Jakub Jelinek
2018-12-13 22:22         ` Martin Sebor [this message]
2018-12-13 23:40           ` Jakub Jelinek
2018-12-14  4:04             ` Martin Sebor
2018-12-14  7:41               ` Jakub Jelinek
2018-12-15  0:18                 ` Martin Sebor
2018-12-21  2:56       ` Martin Sebor
2019-01-03 22:22         ` PING " Martin Sebor
2019-01-08  0:32           ` PING #2 " Martin Sebor
2019-01-15 16:31             ` Martin Sebor
2019-01-17  1:16               ` Jeff Law

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=4e9198aa-3348-c45f-e3e7-7b3c23f94190@gmail.com \
    --to=msebor@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=law@redhat.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).