On 6/24/20 2:15 PM, Asher Gordon wrote:
Hi Martin,
Asher Gordon <asd...@posteo.net> writes:
Martin Sebor <mse...@gmail.com> writes:
Unfortunately, attributes don't have locations (yet).
Hmm, well maybe I could implement that. I'm not very familiar with the
GCC source (this is my first patch), but I'll see if I can figure it
out. It would probably be useful for other warnings/errors too.
Well, I've been trying to implement source locations for
IDENTIFIER_NODEs. But I ran into some very strange problems. If I add a
'location_t' for 'struct tree_identifier' like this:
everything works fine. However, if I then try to use the 'location_t' I
just added, like this:
then lots of ICEs occur. Or, if I don't use IDENTIFIER_SOURCE_LOCATION,
but add 'locus' before 'id' instead of after it, like this:
then, again, lots of ICEs occur.
My best guess for why the ICEs occur, is that perhaps there is a
'struct' with a similar structure to 'struct tree_identifier', and
pointers to these 'struct's are being casted to each other. Something
like this, sort of:
Do you think something like that is possible? And if so, where might it
occur? Or maybe the wrong member of 'union tree_node' is being used
somewhere? But that seems unlikely, since I configured with
--enable-checking...
I have no experience with changing tree nodes but I wouldn't be
surprised if there were assumptions baked into code that made it
a non-trivial exercise.
There's also lots of sharing of data in GCC so I'm not sure it
makes sense for an identifier to have an associated location.
I imagine two different entities with the same name might share
the same identifier. It should be easy to verify. For example
with this test case:
void f (int i) { }
void g (int i) { }
and a breakpoint in finish_decl() in c/c-decl.c, the debugger
will stop twice, once for the i in f and then again for the one
in g. They are two different arguments (with different addresses)
but they both have the same DECL_NAME().
Martin
Thanks,
Asher
