Patch to fix -fsyntax-only

Jeffrey A Law
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.


  > 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

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.

  > >  > 	* 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.


More information about the Gcc-patches mailing list