This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: [C,C++] integer constants in attribute arguments

From: Marc Glisse <marc dot glisse at inria dot fr>
To: Jason Merrill <jason at redhat dot com>
Cc: gcc-patches at gcc dot gnu dot org
Date: Mon, 3 Feb 2014 18:46:04 +0100 (CET)
Subject: Re: [C,C++] integer constants in attribute arguments
Authentication-results: sourceware.org; auth=none
References: <alpine dot DEB dot 2 dot 02 dot 1311301103070 dot 10346 at stedding dot saclay dot inria dot fr> <52C5DD73 dot 2070305 at redhat dot com> <alpine dot DEB dot 2 dot 02 dot 1401182314190 dot 23143 at stedding dot saclay dot inria dot fr> <52EFCA96 dot 9000908 at redhat dot com>

On Mon, 3 Feb 2014, Jason Merrill wrote:

On 01/18/2014 05:33 PM, Marc Glisse wrote:
So when we have: __attribute__((nonnull(bar,bar)))
the parser will keep bar as an identifier for the first argument, but
parse the second one as an expr-list and thus find the associated
function_decl.
OK, that makes sense. But why do we need to handle that specially? Isn'tthat an invalid argument whether or not it decays to a pointer?

The C version of default_conversion does not convert a function_decl to apointer (that's done earlier, during parsing), it ICEs. As you can see forthe one attribute that is C++-only, I don't have any protection beforecalling default_conversion, it is only for the C front-end (for whichcalling default_conversion is useless anyway, but that's how it isalready done in a couple other attributes).


--
Marc Glisse

Follow-Ups:
- Re: [C,C++] integer constants in attribute arguments
  - From: Jason Merrill

References:
- Re: [C,C++] integer constants in attribute arguments
  - From: Jason Merrill

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]