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.
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.
Martin
