This is the mail archive of the 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: [plugins] Add user attribute


On Wed, Apr 1, 2009 at 9:39 AM, Taras Glek <> wrote:
> Joseph S. Myers wrote:
>> On Wed, 1 Apr 2009, Richard Guenther wrote:
>>> On Tue, Mar 31, 2009 at 8:17 PM, Taras Glek <> wrote:
>>>> Hi,
>>>> This patch adds a user("annotation") attribute to gcc for use with gcc
>>>> plugins that require code to be annotated.
>>>> Thanks,
>>>> Taras
>>> Hm. ?I wonder if it makes more sense to have a plugin hook for attribute
>>> processing?
>> On the whole I agree that we should let plugins register new attributes
>> (whose table entries would get processed in init_attributes) rather than
>> adding one attribute all plugins have to go through. ?These attributes would
>> then have all the flexibility of built-in attributes with regard to the
>> different ways decl_attributes can process them. ?If the plugin isn't
>> loaded, they'd get a warning as for unknown attributes at present.
> On the other hand, with one plugin-specific attribute it's immediately clear
> to the user that the attribute is for some sort of an analysis is not
> intended for gcc itself. Attributes are typically hidden behind macros, so
> it doesn't matter what the attribute is named, so the end user wouldn't
> really see any benefit.
> I agree with Diego that it's nice to have GCC ignore user-attributes when no
> plugin is loaded.
> I can make a new patch for registering attributes, but that seems like
> over-engineering to me.

Given that an unknown attribute will not cause a fatal syntax error, I
think (and agree with Richard and Joseph) that allowing plugins to
register new attributes is more flexible and useful than providing
only a 'user' attribute. One shortcoming of the 'user' attribute I can
think of is that there is no easy way for a plugin attribute to take
arguments. Based on your current design, if a new plugin attribute
'new_attr' requires two arguments 'arg1' and 'arg2' (as shown below),
the plugin will most likely need to parse the string to get the
attribute name and the arguments,

__attribute__((user("new_attr(arg1, arg2)")))

while if we provide hooks to allow plugins to register new attributes
so that the above attribute will become

__attribute__((new_attr(arg1, arg2)))

then individual plugin doesn't have to parse the arguments and we have
all the power of the existing attribute processing code (for example,
checking the required number of arguments).

Anyway, providing attribute support for plugins is, in my opinion,
important and thanks a lot for working on it.


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