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

[Akim Demaille]

Hi People!

| 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?

Wow...  I do hope that you don't care :(  But if you really do want to
do that, you want to apply a patch similar to the reverse of:

http://savannah.gnu.org/cgi-bin/viewcvs/bison/bison/data/Attic/bison.simple.diff?r1=1.26&r2=1.27&hideattic=0