Nasty parsing bug?

Aaron Ballman aaron at
Fri Aug 15 04:51:45 PDT 2014

On Fri, Aug 15, 2014 at 4:10 AM, Abramo Bagnara
<abramo.bagnara at> wrote:
> Il 07/08/2014 15:42, Aaron Ballman ha scritto:
>> On Thu, Aug 7, 2014 at 9:30 AM, Abramo Bagnara <abramo.bagnara at> wrote:
>>> On 07/08/2014 15:15, Aaron Ballman wrote:
>>>> On Thu, Aug 7, 2014 at 5:39 AM, Abramo Bagnara
>>>> <abramo.bagnara at> wrote:
>>>>> In the following source
>>>>> enum e { a };
>>>>> enum e __attribute__((unused)) x;
>>>>> enum e
>>>>> __attribute__((unused)) y;
>>>>> the declaration of x is parsed without errors, but the declaration of y
>>>>> gives a parse error i.e. the presence of the newline makes a difference (!)
>>>>> Indeed I cannot imagine a reason why the parsing should be influenced by
>>>>> token position.
>>>>> Opinions anyone?
>>>> Both are illegal parses -- a GNU-style attribute cannot appear in that
>>>> location.
>>> Hmmm... but GCC compiles the source without any warning...
>>> Do you mean it is an undocumented feature of GCC or a GCC bug?
>> Undocumented feature, as far as I can tell. That would attach the
>> attribute to the enum e type based on position, but it seems to
>> appertain to the declaration instead.
>> But if GCC accepts this, we may want to consider implementing it as
>> well if there's sufficient reason.
> As we already behave in a GCC compatible way parsing
> struct s
> __attribute__((used)) x;
> int __attribute__((used)) y;
> I think that the proper fix is the attached one (i.e. we don't want to
> detect as illegal something that later we will accept)
> Ok to commit?

Except that if GCC considers that parsing to be a bug, then all we're
really doing is enforcing their bug. Do you know of GCC's stance on
whether this is a bug or not? If it's not a bug, but something they
want to continue supporting, then I think we should fix it as well.

As for your patch -- it's missing parsing and semantics test cases for
both C and C++ (eg, how well does this work with enum class
declarations in C++?). Otherwise, the approach looks reasonable to me.


More information about the cfe-commits mailing list