https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856
--- Comment #6 from Tom Tromey <tromey at gcc dot gnu.org> --- (In reply to Josh Triplett from comment #4) > Unfortunate, and I'd love to see GCC handle trailing attributes (does a bug > already exist for that somewhere?), but not something that should block > *this* > feature. Offhand I don't know if there is a bug covering this. > (As a vaguely related aside, how does GCC disambiguate whether an attribute > preceding the function declaration or definition applies to the return type > or > to the function? I really hope that doesn't depend on the specific > attribute.) It does, see the various *_required fields in struct attribute_spec (tree-core.h). It's worse than you think, as I believe a given attribute handler can decide where to put the attribute based on any criteria it likes. > Could you represent __context__ as a new GCC builtin? Would that make this > any > easier? It's basically the same thing. One idea might be not to make the function const; then have the pass rip out the calls to it. However then you might have a situation where these calls formerly interfered with some optimization, meaning that their presence did affect code generation. I don't really know if this is possible. > Sparse actually tracks context as a property of basic blocks. I was thinking this might be doable but I don't really know how gcc handles basic block coalescing -- if two blocks are merged we'd want to ensure that the resulting block ends up with the correct context property. It might help to see exactly where __context__ is used in real code. > (if > they ship it at all; AFAICT Debian only ships gcc-python3-plugin). The version of python doesn't matter much. For people whose distro doesn't package gcc-python-plugin, it is simple to build; just git clone + make. > So, I suspect the unfortunate answer is that Linux would probably want to > ship > the plugin as C/C++ and build it at build time if enabled. That's also fine, it's easy(-ish) to rewrite.
