On Wed, 24 Jun 2020, Asher Gordon via Gcc-patches wrote: > I see. So perhaps this isn't the best way to go about implementing > attribute locations. What do you think would be a better way? Perhaps > using a DECL_MINIMAL for attributes?
In general, too many things in GCC have the static type "tree". Ideally identifiers wouldn't be "tree" - there are very few places where something can, at runtime, be either an identifier or another kind of tree, which makes them a good candidate for a different static type. But there are tricky memory allocation issues around identifiers that make changing their representation complicated. Attributes also have the static type "tree". They're TREE_LISTs, and TREE_LIST is used for many different things and is not a particularly efficient type. Unlike identifiers, there's nothing essential that would make it hard to change attributes to have a different static type (which could have room to store a location - the parsers know the location for each token, it's just that in many cases it ends up getting thrown away rather than stored in the datastructures they create) - it would just be a large, global change requiring testing across many different targets (which should definitely not be combined with any change trying to add a new feature - the aim would be that such a change to the internal representation does not change how GCC behaves at all). But each bit of that large change should be fairly straightforward. (I'd guess you might have a vec.h vector, each of whose elements is a new attribute type, rather than using a linked list with the same type for attributes and lists thereof.) There was at least one previous attempt at changing attributes to have a different static type (see commit 4b0b31a65819f64bfeea244bfdcd1a1b8fc3c3cc on refs/dead/heads/static-tree-branch), but that was so long ago, and so much has changed in GCC since then (including regarding the representation of attributes, as part of supporting C++11 attributes and distinguishing them from attributes using GNU syntax), that it wouldn't be a useful starting point for such a change now. However, the changes made for supporting C++11 attributes would probably make such a change *easier* than it was then, because more uses of attributes now go through APIs relating specifically to attributes rather than generic TREE_LIST APIs. -- Joseph S. Myers jos...@codesourcery.com