This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Major debugging breakage
law@redhat.com wrote:-
> OK. Slowly this is starting to make sense. It turns out the C++ front-end
> handles this correctly.
Good. Something I couldn't work out is how this broke - the way
c-lex.c currently works seems to be the same as it was in early 2.96
days (I have pored over diffs looking at semantic differences between
pre-integrated CPP and post-integrated CPP more than once).
> If we look at the C front-end we have:
>
> /* Value is number of statements counted as of the closeparen. */
> simple_if:
> if_prefix c99_block_lineno_labeled_stmt
> { c_finish_then (); }
> /* Make sure c_expand_end_cond is run once
> for each call to c_expand_start_cond.
> Otherwise a crash is likely. */
> | if_prefix error
> ;
>
> if_prefix:
> IF '(' expr ')'
> { c_expand_start_cond (truthvalue_conversion ($3),
> compstmt_count);
> $<itype>$ = stmt_count;
> if_stmt_file = $<filename>-2;
> if_stmt_line = $<lineno>-1; }
Now it makes sense - it looks likely that it was introduced sometime
in the 3.0 cycle when more C99 block support was added.
It would be great to figure out a way to have tests of the stabs
output like you showed in your original message to check for subtle
linenumber breakage like this. Do you think you will be able to cook
up a test case for this? If you do, I would be happy to extend a
working test to generate more tests to cover other cases (like "while"
etc.)
> Note that we call c_expand_start_cond (which records the line number for
> the statement) *after* we've parsed the entire expression. Thus the
> recorded line number is wrong.
>
> At least that's my theory :-)
It looks very likely to me.
Neil.