On Thu, Feb 21, 2019 at 03:39:21PM -0700, Martin Sebor wrote:
> On 2/21/19 1:27 PM, Jeff Law wrote:
> > On 2/21/19 1:12 PM, Martin Sebor wrote:
> > > On 2/21/19 12:08 PM, Jeff Law wrote:
> > > > On 2/18/19 7:53 PM, Martin Sebor wrote:
> > > > > Please let me know what it will take to get the fix for these two
> > > > > issues approved. I've answered the questions so I don't know what
> > > > > else I'm expected to do here.
> > > > >
> > > > > https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00793.html
> > > > I think there is still a fundamental disagreement about whether or not
> > > > this should be handling expressions. Without an agreement on that it's
> > > > hard to see how this could go forward.
> > >
> > > I think it's wrong to hold up a fix for an ICE because you don't
> > > like the current design. The built-in successfully handles common
> > > expressions (see c-c++-common/builtin-has-attribute-5.c). It just
> > > fails for some of the less common ones. Not fixing those will only
> > > penalize users who run into the ICE, and cast a bad light on
> > > the quality of the release. Any design questions should be
> > > settled separately of these ICEs (should have been when
> > > the feature was being reviewed).
> > >
> > > That said, I have explained the rationale for the current design.
> > > Neither you nor Jakub has explained what you find wrong with it or
> > > why either of your alternatives is preferable. You said it should
> > > be an error to apply the built-in to expressions (why?). Jakub
> > > thought there perhaps should be two built-ins, one for expressions
> > > and another for decls. His rationale? The current design is not
> > > good. Clearly, the two of you don't agree on what you'd like to
> > > see; the only thing you agree on is that you don't like what's
> > > there now. What do you expect me to do with that, now at the end
> > > of stage 4?
> > Fix the ice in another way. Handling expressions here seems
> > fundamentally wrong. ISTM that making this query on an expression
> > should result in an immediate error.
>
> Sorry but "it seems wrong" is not a compelling argument. You need
> to explain what you think is wrong with it.
"Attributes apply to decls and types, not expressions" seems like an
argument strong enough. (There are also special attributes for enums
and ';' and labels.)
> The built-in is modeled on the sizeof, alignof, and typeof operators.
> The manual documents like this:
>
> bool __builtin_has_attribute (type-or-expression, attribute)
>
> ...The type-or-expression argument is subject to the same
> restrictions as the argument to typeof (see Typeof).
>
> It was reviewed and approved with no objections to the API. So it
> seems that it's up to you to provide a convincing argument that this
> was the wrong choice. What serious problems do you think it might
> cause that justify rejecting expressions, and how will users overcome
> this limitation?
>
> I already explained the rationale behind the decision to have
> the built-in accept expressions: to be able to easily query for
> type attributes in expressions such as:
>
> typedef __attribute__ ((may_alias)) int* BadInt;
>
> void f (BadInt *p)
> {
> _Static_assert (__builtin_has_attribute (*p, may_alias));
> }
>
> or
>
> struct S {
> int a[1] __attribute__ ((packed));
> };
>
> void f (struct S *p)
> {
> _Static_assert (__builtin_has_attribute (p->a, packed));
> }
>
> or even
>
> _Static_assert (__builtin_has_attribute (p->a[0], packed));
>
> If the built-in rejects expressions, I don't see how one would
> query for these properties.
So how about __builtin_has_attribute (typeof (p->a), packed)?
Trying to query/set attributes on things like "1 + 1" just doesn't make any
sense. So why don't we handle TYPE_P/DECL_P and give an error for the rest?
Marek
