Elements of ridpointers[] inappropriately tested for equality
Matthew Hiller
hiller@redhat.com
Fri Nov 17 15:48:00 GMT 2000
For C, C++, and Objective C, leastaways, ridpointers is
initialized as follows:
ridpointers = (tree *) xcalloc ((int) RID_MAX, sizeof (tree));
for (i = 0; i < N_reswords; i++)
{
/* If a keyword is disabled, do not enter it into the table
and so create a canonical spelling that isn't a keyword. */
if (reswords[i].disable & mask)
continue;
id = get_identifier (reswords[i].word);
C_RID_CODE (id) = reswords[i].rid;
ridpointers [(int) reswords[i].rid] = id;
...
}
reswords is set up such that different keywords can correspond to
the same RID_CODE. (There are elements for "__volatile", "__volatile__",
and "volatile", for example). get_identifier won't find "__volatile" when
searching for "__volatile__", however, and will in turn invoke make_node
for the new keyword, and return a different value as id. This new id will
then replace the old one in ridpointers [(int) reswords[i].rid].
This in itself is a problem only if existing trees are compared to
values in ridpointers. Alas, this happens a lot. In c-parse.in, for
example:
| ASM_KEYWORD maybe_type_qual '(' expr ':' asm_operands ')' ';'
{ stmt_count++;
c_expand_asm_operands ($4, $6, NULL_TREE, NULL_TREE,
$2 == ridpointers[(int)RID_VOLATILE],
input_filename, lineno); }
$2 == ridpointers[(int)RID_VOLATILE] will come out as 1 if if
maybe_type_qual came from a "volatile" in the source code, but not a
"__volatile".
The source tree seems to be fairly shot through with uses of
ridpointers like what I've shown above. A fix that works for the code
shown above is changing the fourth line of it to
C_RID_CODE ($2) == RID_VOLATILE,
but I don't know how general a solution this is, and it could be hard to
ferret out every place where this needs fixing. Should I proceed with that
course of action, or does anyone have other suggestions?
Matt Hiller
More information about the Gcc-bugs
mailing list