This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[tree-ssa][diag][rfc] error recovery vs maintainability vs testsuite


The problem I'm trying to address here is regressions in the testsuite
that come from doing less recovery after errors, and so stopping 
compilation before emitting all of the expected errors.

I do not imagine for a moment that the new compiler will generate 
exactly the same set of errors as the old compiler.  I do, however,
consider the existing "don't compile anything else if you've seen
any errors whatsoever" method of recovery to be a QoI regression.

It turns out, rather unsurprisingly, that all options are nasty.

I have two patches here.  They both work in that they solve

-FAIL: g++.old-deja/g++.other/vaarg3.C  (test for errors, line 23)
-FAIL: g++.old-deja/g++.other/vaarg3.C  (test for errors, line 26)
-FAIL: gcc.dg/20020919-1.c  (test for errors, line 89)
-FAIL: gcc.dg/20020919-1.c  (test for errors, line 105)
-FAIL: gcc.dg/20020919-1.c  (test for errors, line 114)
-FAIL: gcc.dg/20020919-1.c  (test for errors, line 123)
-FAIL: gcc.dg/20020919-1.c  (test for errors, line 132)
-FAIL: gcc.dg/20020919-1.c  (test for errors, line 141)
-FAIL: gcc.dg/20020919-1.c  (test for errors, line 159)
-FAIL: gcc.dg/20020919-1.c  (test for errors, line 177)
-FAIL: gcc.dg/20020919-1.c  (test for errors, line 195)
-FAIL: gcc.dg/20020919-1.c  (test for errors, line 222)
-FAIL: gcc.dg/20020919-1.c  (test for errors, line 231)
-FAIL: gcc.dg/20020919-1.c  (test for errors, line 244)
-FAIL: gcc.dg/torture/builtin-attr-1.c (test for excess errors)

and create no new regressions.  I'd like some feedback on what
folks think we ought to do:

  (1) Patch 1 assumes that the gimplifier is robust in the face of
      all input, and sanitizes out anything harmful.  We can then
      proceed with compilation of any function that we're given
      and all will be well.

      This adds a rather lot of checks and code to the gimplfier.
      In some cases we still have to resort to not processing certain
      constructs if any error has been seen, because we can get too
      confused down the line.

  (2) Patch 2 tries to track when any one function has seen an error,
      and not compile that function.  This means that subsequent 
      functions will be processed normally, and will generate proper
      error messages.

      On the surface this seems trivial and robust.  A hook in the
      diagnostic routines sets a flag on current_function_decl, and
      voila, we know when to stop.

      Except of course it isn't quite that easy.  I found at least
      two ways that errors could creap in without the error flag being
      set.  Mostly from errors generated outside of a function, but
      Stuff saved and then imported into some function later.

      So we still have some amount of churn to handle in the gimplifiers,
      but less.  We don't have to propagate back error codes everywhere.

  (3) Do nothing.  Give up on the QoI as too expensive wrt maintainence.
      Adjust the testsuite to test all the same things, but not all in
      one file.

At the moment I'm leaning toward (2) because I think it's slightly more
robust, with less code involved.  Gaby may have something to say about
hooking into the diag routines like I did.

Thoughts?


r~

Attachment: d-errors-1.gz
Description: GNU Zip compressed data

Attachment: d-errors-2.gz
Description: GNU Zip compressed data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]