gcc's C parser bitten by error recovery changes in bison 1.50

[Zack Weinberg]

When bison 1.50 is used to build GCC mainline, we get a number of
testsuite failures:

FAIL: gcc.dg/noncompile/920923-1.c  (test for errors, line 69)
FAIL: gcc.dg/noncompile/920923-1.c  (test for errors, line 72)
FAIL: gcc.dg/noncompile/920923-1.c  (test for errors, line 74)

(repeated for every combination of -O switches).  Error messages are
not being issued when expected.  920923-1.c is fairly complicated, but
I've managed to cut it down to

int *mem_hash;
void *a_translate(int v_addr)
{
     register int *bucket;
     bucket = mem_hash;
     do {
          if (1 {
          }
     } while (0);

     return p_addr;
}

The installed gcc-3.2 on this system (with a 1.35-based parser)
produces these diagnostics:

920923-1.c:8: parse error before `{'
920923-1.c:12: `p_addr' undeclared (first use in this function)

whereas the just-built cc1 (with its 1.50-based parser) only emits

920923-1.c:8: error: parse error before '{' token

Examining -dy dumps reveals that this is because of the corrected
error recovery behavior in 1.50 - the dumps are attached to this
message, but the key difference is

(1.35)
Reading a token: Next token is 125 ('}' [}])
Error: state stack now 0 1 3 38 141 221 314 417 504 571 669 619 277 379 451 458 
541 618 708 770
Error: state stack now 0 1 3 38 141 221 314 417 504 571 669 619 277 379 451 458 
541 618 708
Error: state stack now 0 1 3 38 141 221 314 417 504 571 669 619 277 379 451 458 
541 618
Error: state stack now 0 1 3 38 141 221 314 417 504 571 669 619 277 379 451 458 
541
Error: state stack now 0 1 3 38 141 221 314 417 504 571 669 619 277 379 451 458
Error: state stack now 0 1 3 38 141 221 314 417 504 571 669 619 277 379 451
Reducing via rule 444 (line 1934), lineno_stmt_decl_or_labels_ending_stmt  -> 
lineno_stmt_decl_or_labels
state stack now 0 1 3 38 141 221 314 417 504 571 669 619 277 379
Entering state 455
Next token is 125 ('}' [}])
Discarding token 125 ('}').

(1.50)
Reading a token: Next token is token '}' ( [}])
Error: popping nterm c99_block_lineno_labeled_stmt ()
Error: state stack now 0 2 5 42 146 225 316 415 501 568 666 616 280 381 449 456 
538 615 705 767
Error: popping nterm @30 ()
Error: state stack now 0 2 5 42 146 225 316 415 501 568 666 616 280 381 449 456 
538 615 705
Error: popping token DO ( [}])
Error: state stack now 0 2 5 42 146 225 316 415 501 568 666 616 280 381 449 456 
538 615
Error: popping nterm c99_block_start ()
Error: state stack now 0 2 5 42 146 225 316 415 501 568 666 616 280 381 449 456 
538
Error: popping nterm save_lineno ()
Error: state stack now 0 2 5 42 146 225 316 415 501 568 666 616 280 381 449 456
Error: popping nterm save_filename ()
Error: state stack now 0 2 5 42 146 225 316 415 501 568 666 616 280 381 449
Error: popping nterm lineno_stmt_decl_or_labels_ending_stmt ()
Error: state stack now 0 2 5 42 146 225 316 415 501 568 666 616 280 381
Shifting error token, Entering state 446
Next token is token '}' ( [}])
Reducing via rule 461 (line 2048), error  -> compstmt_contents_nonempty

Two questions:

(for gcc-bugs:) Do we care?  This test case is just checking that the
compiler doesn't crash on wildly erroneous input.  The errors are all
enumerated so that dg.exp will be happy, but we could just shove a
{ dg-excess-errors } in there and be done with it.  The exact set of
errors isn't, IMO, all that interesting, and the new C++ parser should
do a _lot_ better.

(for help-bison:) Assuming that we do care, how should the .y file be
modified so that 1.35 and 1.50 behave the same way?

Thanks,
zw

dy.32
Description: Text document

dy.33
Description: Text document