On 2/21/19 3:42 PM, Jeff Law wrote:
On 2/21/19 3:39 PM, 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 on expressions seems fundamentally broken. Jakub has raised
this issue as well. If you want things to move forward you need to
address this fundamental issue.
I need to understand what this fundamental problem is.
The built-in is modeled on the sizeof, alignof, and typeof operators.
The manual documents like this:
Understood, but that makes it rather different from most (all?) other
attributes. Attributes apply to decls and types, not expressions.
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.
ANd I botched that. Mistakes happen.
It was also reviewed by Joseph and Jason.
Can you show how one would query for attribute packed in the example
I gave if the built-in were to reject expressions:
struct S {
int a[1] __attribute__ ((packed));
};
void f (struct S *p)
{
_Static_assert (__builtin_has_attribute (p->a, packed));
}
In any event, if there is a problem I will certainly fix it. But
I need to know what the problem is first.
Martin
