- Joseph Myers
- The C and Objective-C parser is replaced by a hand-written recursive descent parser. Eight versions have been posted to gcc-patches, with further explanation, discussion and timings. From the fifth version onwards they have been feature-complete including ObjC support and bootstrapped with no regressions.
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01969.html http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02019.html http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02409.html http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00240.html http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00347.html http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00302.html http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00195.html http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00339.html
- Although timings showed a 1.5% speedup, the main benefits are facilitating of future enhancements including: OpenMP pragma support; lexing up front for C so reducing the number of different code paths; diagnostic location improvements (and potentially other diagnostic improvements); merging cc1/cc1obj into a single executable with runtime conditionals (which has been of interest to some Apple people in the past). Many defects and oddities in the existing parser which would not have been readily fixable there have been identified, recorded with ??? comments in the new parser and reproduced bug-compatibly and the new parser will facilitate their fixing.
- Code may be wrongly accepted which should be rejected, or wrongly rejected which should be accepted. These are mitigated by lack of any testsuite regressions, with tests having been added to the testsuite for all diagnostics that came directly from the old parser. In addition, care has been taken to reproduce all identified oddities in the old grammar bug-compatibly rather than being led into temptation to combine such changes unnecessarily with the replacement of the parser. (Tests for every token type in every context are no longer proposed; no other front end in GCC has such tests.) Bootstrap with no regressions has been confirmed on x86, x86_64, ia64, ppc, ppc64 (Linux; last three platforms tested by Steven Bosscher) and ppc-darwin-7.7 (Marcin Dalecki). Steven Bosscher might also be doing distribution build tests, although the present timing in terms of SUSE release plans isn't so good for this as when he originally volunteered to do so; failing such tests before the parser goes into mainline, there will inevitably be such testing once it is in mainline. On the testing so far it is expected that any variation from the currently accepted language, beyond slight differences in diagnostic location, is on obscure code and easy to fix. As for differences in diagnostic location, these have been avoided for cases covered in the GCC testsuite, and any external code is expected to depend far less on the exact line of diagnostics. Error recovery might go into infinite loops; the code has been audited for cases of this similar to those found in the past, and it is expected on the basis of that experience that any remaining cases will be easy to fix.