This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PING [PATCH] fix ICE in __builtin_has_attribute (PR 88383 and 89288)
On 3/21/19 4:25 PM, Jakub Jelinek wrote:
On Thu, Mar 21, 2019 at 04:19:37PM -0600, Martin Sebor wrote:
Say that the argument is either a type or an expression that is
either an identifier (for C++ id-expression) to cover 1) and
a postfix expression with . or -> operator (to cover COMPONENT_REF)?
That doesn't look easy to understand.
Why? Those users that don't read corresponding language standards
will just see the compiler diagnosing any uses but those 3 kinds
and can then just read the documentation which will show in examples what is
accepted and what it will do.
Because to most users it suggests that . and -> are the only operators
that are accepted in the expression and so something like p[0].a is not
a valid argument.
Those who don't read the manual will be puzzled when, after having had
p[0].a accepted, p->a[0] will trigger an error.
We do not want to allow INDIRECT_REF, ARRAY_REF, etc.
Why not? What exactly is the concern?
Because only the . and -> operators are needed to get at the non-static
member declaration. INDIRECT_REF or ARRAY_REF aren't useful for that,
and then it raises the question what exactly is supposed to be the behavior
when you use *expr or expr[0] or expr->field[0]. Those expression don't
have any decl, so we'd be back at your suggestion to pretty randomly
sometimes return DECL_ATTRIBUTES, sometimes TYPE_ATTRIBUTES, sometimes both.
That is just a bad design. If people want type attributes, they should use
__typeof or decltype or just type itself in the argument.
I never suggested to "pretty randomly sometimes return
DECL_ATTRIBUTES, sometimes TYPE_ATTRIBUTES, or sometimes both."
That's a silly mischaracterization, just as it would be to say
the same thing about __alignof__, and it works much the same way.
It operates on expressions and returns the alignment either
explicitly speciified for the variable (or function) or that
specified for its type.
I modeled the built-in on __alignof__. There may bugs where it
behaves differently, or subtle deviations where I chose a different
approach, but it's certainly not random. I'd like to fix the bugs,
and I'm open to reconsidering the deviations, but using either as
a justification for rejecting those kinds of expressions would
result in hard-to-use API. And _that_ would be bad design.
Martin