https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856
--- Comment #3 from Tom Tromey <tromey at gcc dot gnu.org> ---
(In reply to Josh Triplett from comment #2)
> > The attribute syntax in the test case doesn't work with gcc. The attributes
> > on the function definitions can't appear at the end.
>
> Placing attributes at the end of the function definition works with Sparse,
> and as far as I can tell with GCC as well. The Linux kernel uses trailing
> attributes on functions (both prototypes and definitions) fairly frequently,
> including with the context attribute.
Experimentally it works with function declarations but not function
definitions.
There was some reason for this (ambiguity with K&R style?), but I forget
exactly.
void declaration(void) __attribute__((const));
void definition(void) __attribute__((const))
{
}
pokyo. gcc --syntax-only q.c
q.c:3:1: error: attributes should be specified before the declarator in a
function definition
void definition(void) __attribute__((const))
^
> In general, it seems useful to have the ability to reference argument names
> in attributes on a function. For instance, imagine using argument names
> rather than indexes for the printf attribute or another attribute like it.
Yeah, I agree.
> The context attribute, though, wants something more complex than that: the
> ability to provide expressions based on those arguments, such as arg->lock.
> That does seem like a tall order.
Ok, it wasn't clear to me exactly what the meaning of that argument was.
>From the original text here it seemed like it would just be a plain name.
So, that's something to nail down. I looked at sparse's test suite but
it doesn't test this construct.
> So I suspect it may make sense to run this after inlining, specialization,
> dead-code elimination, and similar.
One difficulty in this case is choosing how to represent __context__.
My hack makes it a const function, and the value is never used, so gcc
is free to just drop all the calls to it. But the further back in
the pipeline the new pass is added, the harder it is to preserve this.
It would be simpler for the plugin if __context__ were instead another
attribute on a different set of functions. I don't know how hard this
is on the kernel end though.
> I don't mind the use of Python, though I wonder how easily such a script
> could work by default. Given this script, how do you invoke GCC and run it?
> How much stability does this interface provide? Could the Linux kernel ship
> such a script and invoke it as part of the compile, given some dependency
> checks (and likely a Kconfig option if it increases build time
> significantly)?
One nice thing about Python is that because it is so dynamic, it's reasonably
easy to make it adapt to different versions of gcc-python-plugin, if needed.
Running it is easy. The "gcc-with-python2" wrapper script is just a
single line:
${CC:-gcc} -fplugin=python2 -fplugin-arg-python2-script=$@
So, it's really just adding a couple of options to the command line.
It wouldn't be completely nuts to just put the whole gcc-python-plugin source
into the tree. It also wouldn't be too hard to just recode this plugin
in C++.
