Patch to fix -fsyntax-only

Jeffrey A Law law@hurl.cygnus.com
Sun Feb 28 18:15:00 GMT 1999


  In message < 19990219145637.9068.qmail@deer >you write:
  > Yes, that's the case.  The *idea* of the original code is to avoid
  > doing (some) needless RTL generation.  As I discovered when fixing
  > ICEs resulting from g77 invocations, RTL generation happens anyway,
  > though not from that particular place, due to all the other entry
  > points in stmt.c, the ones relating to jumps, loops, case statements,
  > and so on.
Right.  I personaly despise all those additional entry points in stmt.c.
Killing them is on my (and other folks) to do list.  

  > So, I *tried* fixing all of those, but there were too many dependencies
  > on some crumbs of RTL generation in stmt.c (and perhaps elsewhere) to
  > make a go of it.
Yea.  I can certainly believe that.


  > (This was near the end of an iterative process of debugging ICEs: I
  > had a list of ICEs for g77 tests using -fsyntax-only; picked the top
  > item; debugged it; added code to fix it; verified the fix on that
  > one case; reran the tests; and repeated.)
I just had an interesting idea.  Run the testsuites through -fsyntax-only.

Anyway...


  > Nice, but there were nagging concerns:
  > 
  >   -  The code testing flag_syntax_only in stmt.c had been broken in
  >      the past due to other code relying on RTL-generation "crumbs"
  >      (you noted one of my fixes below).
Yup.  Poorly designed code IMHO.  One could argue that most of the
benefit of -fsyntax-only is being able to avoid all those passes kicked off
by rest_of_compilation -- avoiding rtl generation in stmt.c doesn't make a
lot of sense from a long term maintainability standpoint.


  > In essence, I'm proposing we apply the elimination rule: if we can't
  > see a *requirement* for eliminating this test (and I'm saying
  > "avoid RTL generation" isn't it, because this test *alone* does
  > not avoid that, so it's incomplete to keep it as is), we eliminate it.
I'd call it a guideline, not a rule :-)  I think in this case following
that guideline probably does make sense.

  > But, I think it'd be best to eliminate all tests of flag_syntax_only
  > in stmt.c, and leave it up to whoever really *wants* to disable
  > all RTL generation accordingly, throughout stmt.c, to add *all*
  > the tests in a comprehensive fashion.  (I don't know for sure
  > that stmt.c represents all of the pertinent front-end interface,
  > beyond varasm.c routines such as assemble_zeros, which g77 uses,
  > for example.  But I think it's the major player.)
Long term I don't see stmt.c as being a major interface between the front
end and rest of the commpiler.

Let's take a trivial example.  expand_goto.  This puppy could easily be
handled with a GOTO_EXPR tree node and routing such requests through
expand_expr.

Similarly for the loop stuff and other entry points one finds in stmt.c.

This is one of the key steps for the functions-as-trees long term goal.


  > In summary: my proposed changes leave a fairly small, perhaps
  > almost minimal, set of tests of flag_syntax_only in the code
  > to support *no* output of code to asm_out_file.  Avoiding RTL
  > generation is a whole 'nother thing, requiring *lots* of tests
  > and, perhaps, reworking of code in stmt.c and elsewhere -- the
  > one test in stmt.c I propose we eliminate is nowhere near the
  > complete picture, and has probably misled some people into
  > thinking it was.
Agreed.

  > >  > 	* varasm.c (assemble_zeros, assemble_variable,
  > >  > 	output_constant_def): Do nothing when -fsyntax-only.
  > >This is OK.
  > 
  > I'll commit that part of it sometime soon.
OK.  I think you should probably commit the stmt.c change too.

jeff



More information about the Gcc-patches mailing list