This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Fix PR 23439/23440
On 15 Sep, Daniel Berlin wrote:
> On Thu, 2005-09-15 at 09:30 +0200, Volker Reichelt wrote:
[snip]
>> The C++ parser expects a statement (the loop body) after the
>> parentheses of a for-statement and tries to annotate it.
>> But in the testcase above this statement isn't there - we already
>> reached the end of the token stream. That's why we get a NULL
>> file name.
>>
>> One could try to fix this in the callers of annotate_with_file_line,
>> but to be sure that all cases are caught, I'd prefer to fix
>> annotate_with_file_line.
>
> ISTM a better solution would be to fix the callers, and add an assert
> that the argument isn't null to make sure "all cases are caught".
>
> You shouldn't have to continually workaround people calling functions
> with bad input. Adding these types of "if someone called us with bad
> arguments, return early" tests everywhere is death by 1000 pinpricks in
> terms of making gcc slower.
It's not clear who's at fault in this particular situation.
Is {NULL, 0} (NULL-pointer for file name and 0 for line number)
a valid location_t?
If so, annotate_with_file_line should be able to handle it gracefully.
If not, the definition of UNKNOWN_LOCATION is broken and should be fixed
(likewise for the annotation of eof_token in the C++ parser.)
I assumed {NULL, 0} was valid, but if there's consensus that it isn't
I can prepare a patch. The following one fixes the C++ failures by giving
the eof_token the file name "eof_token" (it survives bootstrap and
regtesting). I haven't tested a fix for the C parser yet.
===================================================================
--- gcc/gcc/cp/parser.c 8 Sep 2005 13:14:13 -0000 1.356
+++ gcc/gcc/cp/parser.c 15 Sep 2005 15:40:38 -0000
@@ -76,7 +76,7 @@ static const cp_token eof_token =
#if USE_MAPPED_LOCATION
0
#else
- {0, 0}
+ {"eof_token", 0}
#endif
};
===================================================================
What's the preferred strategy?
Regards,
Volker