`--syntax-only' after error

`--syntax-only' after error

[Peter Gerwinski]

Hello, everybody!

We noticed that if we set `flag_syntax_only' after the first
error, compilation of the remaining (errorneous) source file
speeds up significantly (and finds possible other errors in the
file much faster).

Since this is a rather trivial change I wonder why it is not
done in GCC (at least not in egcs-1.1.1).

(In fact parts of the effect of `flag_syntax_only' seem to be
done since compilation _does_ speed up a little after the first
error, but not as drastically as with `--syntax-only'.)

    Peter

-- 
Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118
  PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75
Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

Re: `--syntax-only' after error

[craig]

>We noticed that if we set `flag_syntax_only' after the first
>error, compilation of the remaining (errorneous) source file
>speeds up significantly (and finds possible other errors in the
>file much faster).

Cool idea!  Us developers would need to be able to override it via a
command-line option (I propose `-fwrite-after-errors' or something
similar), because we sometimes want to look at the output that
happens after an error is detected.

I wonder if people would expect the whole file to be written,
though, if they specified `-S' or `-save-temps'....

        tq vm, (burley)

Re: `--syntax-only' after error

[Jeffrey A Law]

  In message < 19990214131426.12017.qmail@deer >you write:
  > Cool idea!  Us developers would need to be able to override it via a
  > command-line option (I propose `-fwrite-after-errors' or something
  > similar), because we sometimes want to look at the output that
  > happens after an error is detected.
  > 
  > I wonder if people would expect the whole file to be written,
  > though, if they specified `-S' or `-save-temps'....
I'm not sure we even need the write-after-errors flag.  In 10 years of hacking
gcc I can't think of an instance where I actually cared about the resulting
assembly file if the compilation had some kind of fatal error.

jeff

Re: `--syntax-only' after error

[Joern Rennecke]

> Hello, everybody!
> 
> We noticed that if we set `flag_syntax_only' after the first
> error, compilation of the remaining (errorneous) source file
> speeds up significantly (and finds possible other errors in the
> file much faster).

But it won't find any semantic errors this way.

Re: `--syntax-only' after error

[Marc Espie]

In article < 199902152204.WAA04856@phal.cygnus.co.uk > you write:

>> We noticed that if we set `flag_syntax_only' after the first
>> error, compilation of the remaining (errorneous) source file
>> speeds up significantly (and finds possible other errors in the
>> file much faster).

>But it won't find any semantic errors this way.

Looks like a good compromise anyway... I believe that, in the general
case, people are only looking at further errors in a file because 
compilation takes time, and so correcting more errors with one pass
is more useful. But what is the ratio of syntactic vs full semantic
analysis time in a compiler such as egcs ?

This also caters for the newer generation :) , who tend to use egcs on
fast machines, and get thru the error checking one bug at a time:
compile - fix first bug - compile again - and so on...

Re: `--syntax-only' after error

[Peter Gerwinski]

Joern Rennecke wrote:
>
> > We noticed that if we set `flag_syntax_only' after the first
> > error, compilation of the remaining (errorneous) source file
> > speeds up significantly (and finds possible other errors in the
> > file much faster).
> 
> But it won't find any semantic errors this way.

With `--syntax-only', the parser still does its job, including
type definitions and checks.  It's just the actual code generation
that is switched off.

    Peter

-- 
Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118
  PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75
Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

Re: `--syntax-only' after error

[Peter Gerwinski]

Hello again,

it seems that the idea is accepted.  The patch consists in
adding a single line

    flag_syntax_only = 1;

to the `v_error_...()' functions in `toplev.c' - or better to a
central place like `count_error()'.  Since I would have to
download a recent EGCS snapshot first (I only have egcs-1.1.1
here) and I am short of disk space and bandwidth, I would prefer
if someone else could do the actual change.

Greetings and thanks,

    Peter

-- 
Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118
  PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75
Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

Re: `--syntax-only' after error

[craig]

>it seems that the idea is accepted.  The patch consists in
>adding a single line
>
>    flag_syntax_only = 1;
>
>to the `v_error_...()' functions in `toplev.c' - or better to a
>central place like `count_error()'.  Since I would have to
>download a recent EGCS snapshot first (I only have egcs-1.1.1
>here) and I am short of disk space and bandwidth, I would prefer
>if someone else could do the actual change.

I don't mind taking care of this.  I still have reservations about
it, e.g., it'll probably make *some* types of error detection
stop working after the first error.  I believe those types include
errors/warnings stemming from RTL analysis, such as uninitialized-
variable and such.  Even a programmer who sees a fatal error in
one routine might want to also see an uninit-var warning in a
subsequent, distinct routine.

Also, I'd like to have some time to look over the pertinent bits
of code to see whether there might be a nesting problem that could
lead to compiler crashes in some cases.  (Not worth trying to explain
that here.)

Finally, I think this would make for enough of a user-visible difference
that, IMO, it should not be the default, but be enabled by an option,
which, if it is indeed not on by default, I suggest be called
something like `-ffail-faster'.  (Not `-ffail-fast'; that would
do something like call `exit(FAILURE);' upon seeing the first
fatal message, like my Mac's old Think C system used to do.)

Any feedback on the above would be appreciated, and there's quite a
bit of time, as I won't get to this until next week at the earliest,
barring some miracle.

        tq vm, (burley)

Re: `--syntax-only' after error

[Joe Buck]

> >    flag_syntax_only = 1;

> I don't mind taking care of this.  I still have reservations about
> it, e.g., it'll probably make *some* types of error detection
> stop working after the first error.

Yikes.  Let's be careful out there.

> errors/warnings stemming from RTL analysis, such as uninitialized-
> variable and such.

Exactly.  If I didn't see such errors and then saw new ones when I
recompiled, I'd be annoyed.  To me, the uninitialized variable warnings
are quite important; if I specify -Wall, I have asked for all warnings,
not just all warnings before the first error.

> Even a programmer who sees a fatal error in
> one routine might want to also see an uninit-var warning in a
> subsequent, distinct routine.

Yes, many programmers want to catch as many errors and warnings
as possible in one compile.  This is particularly important for large
projects.

Please let's consider the consequences carefully before making this
change.  Is it really that much of a performance win?

Re: `--syntax-only' after error

[Joern Rennecke]

> Please let's consider the consequences carefully before making this
> change.  Is it really that much of a performance win?

I don't think it is - if the compiler hasn't finished after you have fixed
as many bugs as you wanted, you can always kill and restart it...

Re: `--syntax-only' after error

[Jeffrey A Law]

  In message < 199902170245.SAA01426@atrus.synopsys.com >you write:
  > 
  > > >    flag_syntax_only = 1;
  > 
  > > I don't mind taking care of this.  I still have reservations about
  > > it, e.g., it'll probably make *some* types of error detection
  > > stop working after the first error.
  > 
  > Yikes.  Let's be careful out there.
  > 
  > > errors/warnings stemming from RTL analysis, such as uninitialized-
  > > variable and such.
  > 
  > Exactly.  If I didn't see such errors and then saw new ones when I
  > recompiled, I'd be annoyed.  To me, the uninitialized variable warnings
  > are quite important; if I specify -Wall, I have asked for all warnings,
  > not just all warnings before the first error.
The behavior could be dependent on extra_warnings and/or specific warning
flags which depend on analysis done by optimization passes.

  > Please let's consider the consequences carefully before making this
  > change.  Is it really that much of a performance win?
In an optimizing compile?  Yes.  The amount of time spent in the front-end
up to initial rtl generation is dwarfed by the amount of time spent in the
optimizers.

For unoptimized compiles it's less of a win.

jeff

Re: `--syntax-only' after error

[Per Bothner]

> Exactly.  If I didn't see such errors and then saw new ones when I
> recompiled, I'd be annoyed.

Heh?  But this happens all the time, anyway.  In many cases,
it is pointless to continue after an error, or at the least
the compiler may need to pop a few levels before it makes sense
to emit more messages.

After an error, it is better to suppress following error
messages, unless you are reasonably confident they are not
caused by earlier errors.

So if a few more errors are missed because we turn on
flag_syntax_only, I don't see that it's a big deal.

Not that I care much either way about this issue.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: `--syntax-only' after error

[Mark Mitchell]

>>>>> "craig" == craig  <craig@jcb-sc.com> writes:

    craig> Finally, I think this would make for enough of a
    craig> user-visible difference that, IMO, it should not be the
    craig> default, but be enabled by an option.

Personally, I disagree.  I don't think the user-visible differences
will be sufficiently great.  And, we have so many options as it is.  I
think we should think very hard about adding additional ones, without
a compelling reason.  And, in the long term, we should make some of
the ones we have no-ops, even if we still accept them for
backwards-compatibility!

A friend once pointed out that to fully test a product with n options
requires exponentially many tests (in n).

I do think that you're right about various problems that require RTL
not being diagnosed, but I just don't see that as very important.

My two cents.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: `--syntax-only' after error

[Peter Gerwinski]

Jeffrey A Law wrote:
>   > Please let's consider the consequences carefully before making this
>   > change.  Is it really that much of a performance win?
> In an optimizing compile?  Yes.  The amount of time spent in the front-end
> up to initial rtl generation is dwarfed by the amount of time spent in the
> optimizers.
> 
> For unoptimized compiles it's less of a win.

Even in an unoptimized compile I noticed a factor of five
between compilation with and without `--syntax-only'.  The
change can be a significant win in a large project where there
is one error near the beginning and another one near the end.

    Peter

-- 
Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118
  PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75
Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

Re: `--syntax-only' after error

[craig]

>Exactly.  If I didn't see such errors and then saw new ones when I
>recompiled, I'd be annoyed.  To me, the uninitialized variable warnings
>are quite important; if I specify -Wall, I have asked for all warnings,
>not just all warnings before the first error.

That's a good point.

>Please let's consider the consequences carefully before making this
>change.  Is it really that much of a performance win?

Joe, what do you think of my idea of making this not the default,
but conditional on an option like `-ffail-faster' or something?
Then, only people who really want just the first fatal diagnostic
will be the only ones affected, as only they will use the option.

        tq vm, (burley)

Re: `--syntax-only' after error

[Geert Bosch]

On Tue, 16 Feb 1999, Mark Mitchell wrote:
|I do think that you're right about various problems that require RTL
|not being diagnosed, but I just don't see that as very important.

I agree with this, especially because syntax errors may very well lead
to wrong and confusing error messages later on. The GNAT (GNU Ada95)
compiler uses the approach of not doing semantic checking in the case of
syntax errors and not doing code generation in the case of any errors.
This approach has turned out to be very useful, both for speed and quality
of error messages.

Of course the situation in C may be different because of the preprocessing
of all header files that must be done before checking the source file that
is being compiled. 

Regards,
   Geert

Re: `--syntax-only' after error

[Peter Gerwinski]

Joe Buck wrote:
> 
> Exactly.  If I didn't see such errors and then saw new ones when I
> recompiled, I'd be annoyed.  To me, the uninitialized variable warnings
> are quite important; if I specify -Wall, I have asked for all warnings,
> not just all warnings before the first error.

Then this must not be the default when `-Wall' is specified and
probably in some other cases, too.  This still leaves us with a
lot of cases where turning off optimization and code generation
after the first error is only benefical.

> Is it really that much of a performance win?

Yes.

craig@jcb-sc.com wrote:
>
> Joe, what do you think of my idea of making this not the default,
> but conditional on an option like `-ffail-faster' or something?

Such an option could be useful for someone who wants to force
the behaviour in question even with `-Wall'.  But in general one
should determine which sorts of warnings need the optimizers and
code generators to be run and switch `-ffail-faster' on if no
such warning is requested.

(In fact I do not like the option name `-ffail-faster' which
lets me think of compiler failures occuring faster ...)

> Then, only people who really want just the first fatal diagnostic
> will be the only ones affected, as only they will use the option.

This does not describe exactly the effect I proposed:  Even with
the option the parser will find all errors in the source, but
only those warnings that can only be generated while optimizing
or generating code will vanish.

    Peter

-- 
Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118
  PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75
Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

Re: `--syntax-only' after error

[craig]

>Personally, I disagree.  I don't think the user-visible differences
>will be sufficiently great.  And, we have so many options as it is.  I
>think we should think very hard about adding additional ones, without
>a compelling reason.  And, in the long term, we should make some of
>the ones we have no-ops, even if we still accept them for
>backwards-compatibility!

As you might recall, I agree wholeheartedly with what you say about
options in general.  In this case, I felt that both proposed options
made long-term sense and were easy enough to support in any batch-I/O-
based compiler like gcc, regardless of how it might be rewritten,
that'd they'd be "safe" in the long run.

>A friend once pointed out that to fully test a product with n options
>requires exponentially many tests (in n).

Yes, that was one of my concerns as well, which I thought I'd
expressed.  (In particular, I'd like to check first whether I can
see obvious reasons the proposed `-ffail-faster' option might
introduce ICEs.)

>I do think that you're right about various problems that require RTL
>not being diagnosed, but I just don't see that as very important.

It's funny -- some people say that they just want the first error,
others (like myself) *know* we've enjoyed making use of multiple
error messages from a single compile, probably including cases where
subsequent errors came from code-generation and related analysis.

So, the first group wants the current behavior to change, but, as I'm
suggesting, it's possible the compiler currently isn't actually
designed and coded to support this.  (For example, `-fsyntax-only'
has been broken in the 1.2 sources for a couple of months, though
I haven't gotten around to fixing it just yet...and I *do* test it
using my personal g77 test suite.  I've had to fix that option at
least once before, in gcc2, awhile ago.)

The second group is happy with the current behavior, and does *not*
want it to change.

Note that the current behavior is made more appropriate and reasonable
as the error recovery for a given front end (plus the back end) improves
over time.  If we decide to offer only the *proposed* behavior (stop
generating code after first error), we'll still have good reasons
to improve that error recovery, which makes the *current* behavior even
more useful to people (if it held sway) anyway.

If we decide, however, to simply `exit (FAILURE);' on the first error,
then we can, over time, eliminate all error-recovery code from the
compiler, including (perhaps) all sorts of code that tests ERROR_MARK
(aka error_mark_node).  This would make the compiler much more
maintainable over time.

Those are some things to consider, and suggest you have a point about
not introducing new options, but just picking one behavior and sticking
with it.

However, if we go *that* route, IMO, the proposed behavior (which I
call `-ffail-faster') is the least worthwhile, because it still
requires graceful error recovery, which in turn leads to more helpful
subsequent errors, some of which this behavior *also* decides will
never be produced after all, just to save some compile time.

So, IMO, the only two behaviors worth considering *assuming* we don't
introduce any new command-line options (in other words, mandating
a behavior, just like we do now) are:

  1.  Continue all normal processing after an error (current behavior),
      and, over time, improve error recovery in various front ends
      and back ends to make subsequent diagnostics more pertinent.

  2.  Exit (with appropriate failure exit code) after an error, and,
      over time, eliminate error-recovery code in the compiler.

I don't see what the "middle ground" buys us, since, to avoid ICEs
generally, we have to continue to maintain and, perhaps, improve
error recovery anyway, but some of the benefits of that will never
be seen by users, because diagnostics that depend on code-generation
happening won't trigger.

So if we *really want* that middle ground, where code generation is
turned off after the first error, I say it is not useful to do it
*except* via a command-line option (either to enable or disable it,
i.e. the default is not really important, in this particular context).

        tq vm, (burley)

Re: `--syntax-only' after error

[Nick Ing-Simmons]

<craig@jcb-sc.com> writes:
>>Exactly.  If I didn't see such errors and then saw new ones when I
>>recompiled, I'd be annoyed.  To me, the uninitialized variable warnings
>>are quite important; if I specify -Wall, I have asked for all warnings,
>>not just all warnings before the first error.
>
>That's a good point.

Maybe -Wall should turn it off ?

>
>>Please let's consider the consequences carefully before making this
>>change.  Is it really that much of a performance win?
>
>Joe, what do you think of my idea of making this not the default,
>but conditional on an option like `-ffail-faster' or something?

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: `--syntax-only' after error

[Mark Mitchell]

>>>>> "craig" == craig  <craig@jcb-sc.com> writes:

    >> I do think that you're right about various problems that
    >> require RTL not being diagnosed, but I just don't see that as
    >> very important.

    craig> It's funny -- some people say that they just want the first
    craig> error, others (like myself) *know* we've enjoyed making use
    craig> of multiple error messages from a single compile, probably
    craig> including cases where subsequent errors came from
    craig> code-generation and related analysis.

First, let me say that I don't feel to strongly about this issue.

Second, I think that your logic, while *always* well-reasoned,
sometimes lead you astray.  We're human, and we're talking about a
computer-human interface here, so logic isn't always the guiding
light.

    craig> So, IMO, the only two behaviors worth considering
    craig> *assuming* we don't introduce any new command-line options
    craig> (in other words, mandating a behavior, just like we do now)
    craig> are:

    craig>   1.  Continue all normal processing after an error
    craig> (current behavior), and, over time, improve error recovery
    craig> in various front ends and back ends to make subsequent
    craig> diagnostics more pertinent.

    craig>   2.  Exit (with appropriate failure exit code) after an
    craig> error, and, over time, eliminate error-recovery code in the
    craig> compiler.

I understand how you got here, but I don't agree with:

    craig> I don't see what the "middle ground" buys us, since, to
    craig> avoid ICEs generally, we have to continue to maintain and,
    craig> perhaps, improve error recovery anyway, but some of the
    craig> benefits of that will never be seen by users, because
    craig> diagnostics that depend on code-generation happening won't
    craig> trigger.

I don't think there are all that many diagnostics that depend on
code-generation.  I know that there are some.  I find that in my own
code, typos (syntax errors) are the most usual problem.  If I sit down
and right a thousand lines, and then compile the file, there will
probably be a bunch of syntax errors, and probably no RTL-based
errors.  (In particular, I'm usually not compiling -O, which disables
some unitializedness checks at present.) 

So, getting through the whole file (good error-recovery) *is*
important to me.  I want to fix the whole bunch of syntax errors
before recompiling.  Getting them all quickly is also very important;
C++ in particular has the odd behavior that after much compilation you
can get new syntax errors (essentially) from looking at the same
template in a different way.  Thus, your option 2 is no good for me.

I do think we should improve error-recovery, etc.  But, if the
original poster is correct in noting a 5x decrease in
compilation-time, I'm all for making the change.  I know of real
programs that I really compile where this could really save me a lot
of time, and I don't (frankly) remember any situations where I would
have been really peeved not to have seen an RTL-based error until the
next compilation pass.

I'm afraid that's about the total of my (possibly) useful input on
this topic...

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: `--syntax-only' after error

[Donn Terry]

Another alternative implementation of this, if it's concluded
that we can't afford to lose errors in a fatal compilation:

1) Turn optimization level down to 0.  (This probably turns off
   "unused variable" warnings, but...)  That's trivial, and has
   a pretty high return, because optimization is the expensive
   part of many compilations anyway.  (Turn off profiling and
   the like at the same time.)
2) Not so trivial: turn off any remaining compilation stages
   in toplev that don't yield warnings/errors.  (Specifically,
   those that do the generation of the acutal assembler.)
   (Probably the code just below the comment:
     /* Now turn the rtl into assembler code.  */
   in toplev.c.)

This doesn't save as much as --syntax-only would, but it's a
viable intermediate position to leaving everything on.

(Don't count this as a vote for not doing --syntax-only after
an error; the reality is that you can never trust a compiler
to catch all errors after a syntax error anyway, so I don't see
the lossage as too significant.  I know others disagree.  I have
used compilers that appear to do this, and I never felt burdened
by the possible loss of a (subtle) error message or two.)

Thinking out loud... there are syntax errors (e.g. grammar) that
can cause the compiler to go crazy, and there are semantic errors
that make the program uncompilable, but which don't cascade
(e.g. undeclared variable).  Should they do different things?
(No opinion expressed, just a thought.)

Donn

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: `--syntax-only' after error

[craig]

>Thus, your option 2 is no good for me.

I don't particularly like it either.  (This is the exit-after-first-
fatal-diagnostic behavior, as the only behavior available.)

Seems to me the best answer is: leave the behavior as is, and
people who want faster compiles should just get a faster system,
or turn off optimization (or use `-fsyntax-only') until they know
they get a clean compile.  They could even hide the latter behind
a script, make rules, whatever.  Or they could just apply the one-line
patch to their own version of gcc (but make sure they don't report
any ICEs involving fatal-error-containing code without first checking
the same code against a pristine gcc, in case their patch exposes
latent bugs in the assumption that flag_syntax_only, or whatever
it changes, does not change during the compiler run).

That *really* is all we're ending up talking about here, it
seems: nobody seems to be actually advocating the position that,
given an infinitely fast compiler, at least some diagnostics
after the first fatal one should not be output.

So, right now, I personally feel we should *not* change the
default behavior, and also that there's just not enough call
for a new option or two (for which I'll at least propose
new names for: `-fdiagnose-faster' and `-fdiagnose-fast', the
first turning on flag_syntax_only, the second calling `exit (FAILURE);',
after issuing the first fatal diagnostic).

The tentative conclusion I reach is, there's no consensus on anything
except, perhaps, not changing the compiler at all in any of the proposed
ways.

        tq vm, (burley)

Re: `--syntax-only' after error

[Joern Rennecke]

> Another alternative implementation of this, if it's concluded
> that we can't afford to lose errors in a fatal compilation:
> 
> 1) Turn optimization level down to 0.  (This probably turns off
>    "unused variable" warnings, but...)  That's trivial, and has
>    a pretty high return, because optimization is the expensive
>    part of many compilations anyway.  (Turn off profiling and
>    the like at the same time.)

That would have pretty much the same efffect as -fsyntax-only .

Re: `--syntax-only' after error

[Joern Rennecke]

> So, right now, I personally feel we should *not* change the
> default behavior, and also that there's just not enough call
> for a new option or two (for which I'll at least propose
> new names for: `-fdiagnose-faster' and `-fdiagnose-fast', the
> first turning on flag_syntax_only, the second calling `exit (FAILURE);',
> after issuing the first fatal diagnostic).

So fast is faster than faster?  That looks a bit like the start-up button
to shut down the system, doesn't it?

Re: `--syntax-only' after error

[Joe Buck]

> > Another alternative implementation of this, if it's concluded
> > that we can't afford to lose errors in a fatal compilation:

"fatal compilation" to me suggests something like an ICE, not an illegal
construct.

> > 1) Turn optimization level down to 0.  (This probably turns off
> >    "unused variable" warnings, but...)

But I don't want to lose them, in the very common case where there
is a recoverable syntax error in an interior block of the first function,
and there are n more functions.

Re: `--syntax-only' after error

[Kamil Iskra]

On 17 Feb 1999 craig@jcb-sc.com wrote:

> Finally, I think this would make for enough of a user-visible difference
> that, IMO, it should not be the default, but be enabled by an option,
> which, if it is indeed not on by default, I suggest be called
> something like `-ffail-faster'.

Don't get me wrong, buf I find the very idea of having such an option -
turned off by default - preposterous.

PERHAPS if gcc was not a command-line compiler, but some product with GUI,
global options etc. Than you would set this option once and forget about
it on the next day.

But dragging a command-line option for something as minor as this? What
for? So that, in case the compiler finds an error, it terminates faster? 
Options specify the expected behaviour of the compiler. Errors are
opposite: they are unexpected. What's the point in specifying the
compiler's behaviour in unexpected situations, if we can't guarantee
anything anyway?

Let's be serious. Either the feature should be on by default (and than
adding an option to turn it off makes sense) or it shouldn't be integrated
into the compiler at all.

/ Kamil Iskra    AmigaOS  Linux/i386  Linux/m68k               \
| GeekGadgets m68k-amigaos GCC maintainer                      |
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
\ kamil@dwd.interkom.pl   http://student.uci.agh.edu.pl/~iskra /

Re: `--syntax-only' after error

[Joe Buck]

> Joe, what do you think of my idea of making this not the default,
> but conditional on an option like `-ffail-faster' or something?
> Then, only people who really want just the first fatal diagnostic
> will be the only ones affected, as only they will use the option.

It wouldn't destabilize the compiler to have a way to exit on the first
error, so I wouldn't have a reason to object if the option were added.

Re: `--syntax-only' after error

[Marc Espie]

In article < Pine.LNX.3.96.990217222018.1697B-100000@jinks.home > you write:
>Don't get me wrong, buf I find the very idea of having such an option -
>turned off by default - preposterous.

Well, your default is not my default...

[...]

>But dragging a command-line option for something as minor as this? What
>for? So that, in case the compiler finds an error, it terminates faster? 
>Options specify the expected behaviour of the compiler. Errors are
>opposite: they are unexpected. What's the point in specifying the
>compiler's behaviour in unexpected situations, if we can't guarantee
>anything anyway?

IF we can get consensus about what the right way is, this option is
preposterous.

As it seems we can't, it's still better to have that behavior as an option.
People who want it by default can write aliases, scripts, Makefile, to
suit their own habits. And people who don't want it can live without it.

>Let's be serious. Either the feature should be on by default (and than
>adding an option to turn it off makes sense) or it shouldn't be integrated
>into the compiler at all.

You're trying to force the issue, one way or another. This is definitely 
cleaner, but it looks like it won't be please everyone. So the option may
get dropped completely. Why ? It looks to me like a user's choice.

Some people prefer getting all the errors in one bunch, whereas others
prefer to first fix one error, then re-run the compiler.  

I fail to see why one of these ways to work should be `better'.

Re: `--syntax-only' after error

[Kamil Iskra]

On Thu, 18 Feb 1999, Marc Espie wrote:

> >Let's be serious. Either the feature should be on by default (and than
> >adding an option to turn it off makes sense) or it shouldn't be integrated
> >into the compiler at all.
> You're trying to force the issue, one way or another. This is definitely 
> cleaner, but it looks like it won't be please everyone. So the option may
> get dropped completely. Why ? It looks to me like a user's choice.

I don't think users should be given choice on issues like this one.
Options should provide users with new, important features. This option
would not provide any feature at all, whether important or not. It would
be just a little tweak for wizards.

The issue is a minor one, therefore, it does not deserve an option. If
EGCS starts adding options for such issues, we will soon have hundreds of
them, as if we already didn't have too many. Many people dislike UNIX for
its dozens of cryptic, mostly useless command line options. Let's not make
the situation worse.

Basically, the reason some people are advocating for an option is that
there is no unanimity among the developers, "so let's make it an option".
Options should not be added on such basis. It is simply not fair to put
additional burden on plain users just because developers couldn't reach an
agreement.

> Some people prefer getting all the errors in one bunch, whereas others
> prefer to first fix one error, then re-run the compiler.  
> 
> I fail to see why one of these ways to work should be `better'.

I agree. But I wasn't talking about this option, but rather about the
syntax-only option. I do agree with you that having an option to abort
after the first error might be useful to have, even though I personally
will probably never use it.

/ Kamil Iskra    AmigaOS  Linux/i386  Linux/m68k               \
| GeekGadgets m68k-amigaos GCC maintainer                      |
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
\ kamil@dwd.interkom.pl   http://student.uci.agh.edu.pl/~iskra /

Re: `--syntax-only' after error

[craig]

>I agree. But I wasn't talking about this option, but rather about the
>syntax-only option. I do agree with you that having an option to abort
>after the first error might be useful to have, even though I personally
>will probably never use it.

The -fsyntax-only option already exists and is supported, though in
the current sources (1.2) it causes the compiler to crash for some
sources (on my to-do list to fix).  I think you might be confused
by the subject header -- which actually refers to the idea of
turning on -fsyntax-only (mispelled in the header) partway through
the compilation, when the first error message is printed, to do less
work during the rest of the compile (which also means not printing
certain kinds of diagnostics, including potentially useful warnings,
later on -- e.g. unitialized-variable and asm-related diagnostics).

The proposed change(s) and option(s) seem to have died for
lack of both interest and consensus.  I'm happy enough with that
-- well, personally, I'd probably never have used the different
behavior anyway, but I mean I think that's the best approach for
gcc at this time, to do nothing (except fix the -fsyntax-only bug).

        tq vm, (burley)

Re: `--syntax-only' after error

[Horst von Brand]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

Does this whole idea of setting optimization level to 0 make sense at all?
AFAIU, O1 and higher set inlining on, O0 turns it off.  This might lead to
nasty interactions if a function is set up to be inlined and the
non-inlining part of the compilation has to handle that later.

I don't see much use for this: If you just want to check for simple errors,
compile with -O0, after fixing them go for -Owhatever.

Just my 2 cents.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viña del Mar, Chile                               +56 32 672616

Re: `--syntax-only' after error

[Peter Gerwinski]

craig@jcb-sc.com wrote:
> [...] I think you might be confused
> by the subject header -- which actually refers to the idea of
> turning on -fsyntax-only (mispelled in the header)

It is not misspelled.  GCC accepts `--syntax-only' as a synonym
for `-fsyntax-only'.  I have chosen the `--' form because it is
more readable.

> partway through
> the compilation, when the first error message is printed, to do less
> work during the rest of the compile (which also means not printing
> certain kinds of diagnostics, including potentially useful warnings,
> later on -- e.g. unitialized-variable and asm-related diagnostics).

Those kinds of diagnostics might be of high importance for some
people; for me they are of rather low importance - at least as
long as the parser still finds errors.  I would definitely prefer
to have the proposed behaviour as the default - except with `-Wall'
where it should be off by default.

And again:  The proposal was *never* about exit(1)ing after
the first error!  I was always speaking about switching on
`--syntax-only' after the first error which will still find
other errors in the same source, but faster.

    Peter

-- 
Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118
  PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75
Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

Re: `--syntax-only' after error

[Gerald Pfeifer]

On Thu, 18 Feb 1999, Horst von Brand wrote:
> Does this whole idea of setting optimization level to 0 make sense at all?
> AFAIU, O1 and higher set inlining on, O0 turns it off.

That's not correct:

  `-O2' turns on all optional optimizations except for loop unrolling
     and function inlining. ...

  '-O3'
     Optimize yet more.  `-O3' turns on all optimizations specified by
     `-O2' and also turns on the `inline-functions' option.

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: `--syntax-only' after error

[Marc Espie]

In article < Pine.LNX.3.96.990217222018.1697B-100000@jinks.home > you write:
>Don't get me wrong, buf I find the very idea of having such an option -
>turned off by default - preposterous.

Well, your default is not my default...

[...]

>But dragging a command-line option for something as minor as this? What
>for? So that, in case the compiler finds an error, it terminates faster? 
>Options specify the expected behaviour of the compiler. Errors are
>opposite: they are unexpected. What's the point in specifying the
>compiler's behaviour in unexpected situations, if we can't guarantee
>anything anyway?

IF we can get consensus about what the right way is, this option is
preposterous.

As it seems we can't, it's still better to have that behavior as an option.
People who want it by default can write aliases, scripts, Makefile, to
suit their own habits. And people who don't want it can live without it.

>Let's be serious. Either the feature should be on by default (and than
>adding an option to turn it off makes sense) or it shouldn't be integrated
>into the compiler at all.

You're trying to force the issue, one way or another. This is definitely 
cleaner, but it looks like it won't be please everyone. So the option may
get dropped completely. Why ? It looks to me like a user's choice.

Some people prefer getting all the errors in one bunch, whereas others
prefer to first fix one error, then re-run the compiler.  

I fail to see why one of these ways to work should be `better'.

Re: `--syntax-only' after error

[Joe Buck]

> >    flag_syntax_only = 1;

> I don't mind taking care of this.  I still have reservations about
> it, e.g., it'll probably make *some* types of error detection
> stop working after the first error.

Yikes.  Let's be careful out there.

> errors/warnings stemming from RTL analysis, such as uninitialized-
> variable and such.

Exactly.  If I didn't see such errors and then saw new ones when I
recompiled, I'd be annoyed.  To me, the uninitialized variable warnings
are quite important; if I specify -Wall, I have asked for all warnings,
not just all warnings before the first error.

> Even a programmer who sees a fatal error in
> one routine might want to also see an uninit-var warning in a
> subsequent, distinct routine.

Yes, many programmers want to catch as many errors and warnings
as possible in one compile.  This is particularly important for large
projects.

Please let's consider the consequences carefully before making this
change.  Is it really that much of a performance win?

Re: `--syntax-only' after error

[Peter Gerwinski]

craig@jcb-sc.com wrote:
> [...] I think you might be confused
> by the subject header -- which actually refers to the idea of
> turning on -fsyntax-only (mispelled in the header)

It is not misspelled.  GCC accepts `--syntax-only' as a synonym
for `-fsyntax-only'.  I have chosen the `--' form because it is
more readable.

> partway through
> the compilation, when the first error message is printed, to do less
> work during the rest of the compile (which also means not printing
> certain kinds of diagnostics, including potentially useful warnings,
> later on -- e.g. unitialized-variable and asm-related diagnostics).

Those kinds of diagnostics might be of high importance for some
people; for me they are of rather low importance - at least as
long as the parser still finds errors.  I would definitely prefer
to have the proposed behaviour as the default - except with `-Wall'
where it should be off by default.

And again:  The proposal was *never* about exit(1)ing after
the first error!  I was always speaking about switching on
`--syntax-only' after the first error which will still find
other errors in the same source, but faster.

    Peter

-- 
Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118
  PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75
Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

Re: `--syntax-only' after error

[Mark Mitchell]

>>>>> "craig" == craig  <craig@jcb-sc.com> writes:

    craig> Finally, I think this would make for enough of a
    craig> user-visible difference that, IMO, it should not be the
    craig> default, but be enabled by an option.

Personally, I disagree.  I don't think the user-visible differences
will be sufficiently great.  And, we have so many options as it is.  I
think we should think very hard about adding additional ones, without
a compelling reason.  And, in the long term, we should make some of
the ones we have no-ops, even if we still accept them for
backwards-compatibility!

A friend once pointed out that to fully test a product with n options
requires exponentially many tests (in n).

I do think that you're right about various problems that require RTL
not being diagnosed, but I just don't see that as very important.

My two cents.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: `--syntax-only' after error

[Joern Rennecke]

> So, right now, I personally feel we should *not* change the
> default behavior, and also that there's just not enough call
> for a new option or two (for which I'll at least propose
> new names for: `-fdiagnose-faster' and `-fdiagnose-fast', the
> first turning on flag_syntax_only, the second calling `exit (FAILURE);',
> after issuing the first fatal diagnostic).

So fast is faster than faster?  That looks a bit like the start-up button
to shut down the system, doesn't it?

Re: `--syntax-only' after error

[Jeffrey A Law]

  In message < 199902170245.SAA01426@atrus.synopsys.com >you write:
  > 
  > > >    flag_syntax_only = 1;
  > 
  > > I don't mind taking care of this.  I still have reservations about
  > > it, e.g., it'll probably make *some* types of error detection
  > > stop working after the first error.
  > 
  > Yikes.  Let's be careful out there.
  > 
  > > errors/warnings stemming from RTL analysis, such as uninitialized-
  > > variable and such.
  > 
  > Exactly.  If I didn't see such errors and then saw new ones when I
  > recompiled, I'd be annoyed.  To me, the uninitialized variable warnings
  > are quite important; if I specify -Wall, I have asked for all warnings,
  > not just all warnings before the first error.
The behavior could be dependent on extra_warnings and/or specific warning
flags which depend on analysis done by optimization passes.

  > Please let's consider the consequences carefully before making this
  > change.  Is it really that much of a performance win?
In an optimizing compile?  Yes.  The amount of time spent in the front-end
up to initial rtl generation is dwarfed by the amount of time spent in the
optimizers.

For unoptimized compiles it's less of a win.

jeff

Re: `--syntax-only' after error

[craig]

>Thus, your option 2 is no good for me.

I don't particularly like it either.  (This is the exit-after-first-
fatal-diagnostic behavior, as the only behavior available.)

Seems to me the best answer is: leave the behavior as is, and
people who want faster compiles should just get a faster system,
or turn off optimization (or use `-fsyntax-only') until they know
they get a clean compile.  They could even hide the latter behind
a script, make rules, whatever.  Or they could just apply the one-line
patch to their own version of gcc (but make sure they don't report
any ICEs involving fatal-error-containing code without first checking
the same code against a pristine gcc, in case their patch exposes
latent bugs in the assumption that flag_syntax_only, or whatever
it changes, does not change during the compiler run).

That *really* is all we're ending up talking about here, it
seems: nobody seems to be actually advocating the position that,
given an infinitely fast compiler, at least some diagnostics
after the first fatal one should not be output.

So, right now, I personally feel we should *not* change the
default behavior, and also that there's just not enough call
for a new option or two (for which I'll at least propose
new names for: `-fdiagnose-faster' and `-fdiagnose-fast', the
first turning on flag_syntax_only, the second calling `exit (FAILURE);',
after issuing the first fatal diagnostic).

The tentative conclusion I reach is, there's no consensus on anything
except, perhaps, not changing the compiler at all in any of the proposed
ways.

        tq vm, (burley)

Re: `--syntax-only' after error

[Kamil Iskra]

On 17 Feb 1999 craig@jcb-sc.com wrote:

> Finally, I think this would make for enough of a user-visible difference
> that, IMO, it should not be the default, but be enabled by an option,
> which, if it is indeed not on by default, I suggest be called
> something like `-ffail-faster'.

Don't get me wrong, buf I find the very idea of having such an option -
turned off by default - preposterous.

PERHAPS if gcc was not a command-line compiler, but some product with GUI,
global options etc. Than you would set this option once and forget about
it on the next day.

But dragging a command-line option for something as minor as this? What
for? So that, in case the compiler finds an error, it terminates faster? 
Options specify the expected behaviour of the compiler. Errors are
opposite: they are unexpected. What's the point in specifying the
compiler's behaviour in unexpected situations, if we can't guarantee
anything anyway?

Let's be serious. Either the feature should be on by default (and than
adding an option to turn it off makes sense) or it shouldn't be integrated
into the compiler at all.

/ Kamil Iskra    AmigaOS  Linux/i386  Linux/m68k               \
| GeekGadgets m68k-amigaos GCC maintainer                      |
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
\ kamil@dwd.interkom.pl   http://student.uci.agh.edu.pl/~iskra /

Re: `--syntax-only' after error

[Per Bothner]

> Exactly.  If I didn't see such errors and then saw new ones when I
> recompiled, I'd be annoyed.

Heh?  But this happens all the time, anyway.  In many cases,
it is pointless to continue after an error, or at the least
the compiler may need to pop a few levels before it makes sense
to emit more messages.

After an error, it is better to suppress following error
messages, unless you are reasonably confident they are not
caused by earlier errors.

So if a few more errors are missed because we turn on
flag_syntax_only, I don't see that it's a big deal.

Not that I care much either way about this issue.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: `--syntax-only' after error

[Peter Gerwinski]

Joe Buck wrote:
> 
> Exactly.  If I didn't see such errors and then saw new ones when I
> recompiled, I'd be annoyed.  To me, the uninitialized variable warnings
> are quite important; if I specify -Wall, I have asked for all warnings,
> not just all warnings before the first error.

Then this must not be the default when `-Wall' is specified and
probably in some other cases, too.  This still leaves us with a
lot of cases where turning off optimization and code generation
after the first error is only benefical.

> Is it really that much of a performance win?

Yes.

craig@jcb-sc.com wrote:
>
> Joe, what do you think of my idea of making this not the default,
> but conditional on an option like `-ffail-faster' or something?

Such an option could be useful for someone who wants to force
the behaviour in question even with `-Wall'.  But in general one
should determine which sorts of warnings need the optimizers and
code generators to be run and switch `-ffail-faster' on if no
such warning is requested.

(In fact I do not like the option name `-ffail-faster' which
lets me think of compiler failures occuring faster ...)

> Then, only people who really want just the first fatal diagnostic
> will be the only ones affected, as only they will use the option.

This does not describe exactly the effect I proposed:  Even with
the option the parser will find all errors in the source, but
only those warnings that can only be generated while optimizing
or generating code will vanish.

    Peter

-- 
Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118
  PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75
Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

Re: `--syntax-only' after error

[Jeffrey A Law]

  In message < 19990214131426.12017.qmail@deer >you write:
  > Cool idea!  Us developers would need to be able to override it via a
  > command-line option (I propose `-fwrite-after-errors' or something
  > similar), because we sometimes want to look at the output that
  > happens after an error is detected.
  > 
  > I wonder if people would expect the whole file to be written,
  > though, if they specified `-S' or `-save-temps'....
I'm not sure we even need the write-after-errors flag.  In 10 years of hacking
gcc I can't think of an instance where I actually cared about the resulting
assembly file if the compilation had some kind of fatal error.

jeff

Re: `--syntax-only' after error

[Peter Gerwinski]

Hello again,

it seems that the idea is accepted.  The patch consists in
adding a single line

    flag_syntax_only = 1;

to the `v_error_...()' functions in `toplev.c' - or better to a
central place like `count_error()'.  Since I would have to
download a recent EGCS snapshot first (I only have egcs-1.1.1
here) and I am short of disk space and bandwidth, I would prefer
if someone else could do the actual change.

Greetings and thanks,

    Peter

-- 
Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118
  PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75
Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

Re: `--syntax-only' after error

[Marc Espie]

In article < 199902152204.WAA04856@phal.cygnus.co.uk > you write:

>> We noticed that if we set `flag_syntax_only' after the first
>> error, compilation of the remaining (errorneous) source file
>> speeds up significantly (and finds possible other errors in the
>> file much faster).

>But it won't find any semantic errors this way.

Looks like a good compromise anyway... I believe that, in the general
case, people are only looking at further errors in a file because 
compilation takes time, and so correcting more errors with one pass
is more useful. But what is the ratio of syntactic vs full semantic
analysis time in a compiler such as egcs ?

This also caters for the newer generation :) , who tend to use egcs on
fast machines, and get thru the error checking one bug at a time:
compile - fix first bug - compile again - and so on...

Re: `--syntax-only' after error

[Horst von Brand]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

Does this whole idea of setting optimization level to 0 make sense at all?
AFAIU, O1 and higher set inlining on, O0 turns it off.  This might lead to
nasty interactions if a function is set up to be inlined and the
non-inlining part of the compilation has to handle that later.

I don't see much use for this: If you just want to check for simple errors,
compile with -O0, after fixing them go for -Owhatever.

Just my 2 cents.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viña del Mar, Chile                               +56 32 672616

Re: `--syntax-only' after error

[Joern Rennecke]

> Hello, everybody!
> 
> We noticed that if we set `flag_syntax_only' after the first
> error, compilation of the remaining (errorneous) source file
> speeds up significantly (and finds possible other errors in the
> file much faster).

But it won't find any semantic errors this way.

Re: `--syntax-only' after error

[Joern Rennecke]

> Another alternative implementation of this, if it's concluded
> that we can't afford to lose errors in a fatal compilation:
> 
> 1) Turn optimization level down to 0.  (This probably turns off
>    "unused variable" warnings, but...)  That's trivial, and has
>    a pretty high return, because optimization is the expensive
>    part of many compilations anyway.  (Turn off profiling and
>    the like at the same time.)

That would have pretty much the same efffect as -fsyntax-only .

`--syntax-only' after error

[Peter Gerwinski]

Hello, everybody!

We noticed that if we set `flag_syntax_only' after the first
error, compilation of the remaining (errorneous) source file
speeds up significantly (and finds possible other errors in the
file much faster).

Since this is a rather trivial change I wonder why it is not
done in GCC (at least not in egcs-1.1.1).

(In fact parts of the effect of `flag_syntax_only' seem to be
done since compilation _does_ speed up a little after the first
error, but not as drastically as with `--syntax-only'.)

    Peter

-- 
Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118
  PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75
Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

Re: `--syntax-only' after error

[craig]

>We noticed that if we set `flag_syntax_only' after the first
>error, compilation of the remaining (errorneous) source file
>speeds up significantly (and finds possible other errors in the
>file much faster).

Cool idea!  Us developers would need to be able to override it via a
command-line option (I propose `-fwrite-after-errors' or something
similar), because we sometimes want to look at the output that
happens after an error is detected.

I wonder if people would expect the whole file to be written,
though, if they specified `-S' or `-save-temps'....

        tq vm, (burley)

Re: `--syntax-only' after error

[Mark Mitchell]

>>>>> "craig" == craig  <craig@jcb-sc.com> writes:

    >> I do think that you're right about various problems that
    >> require RTL not being diagnosed, but I just don't see that as
    >> very important.

    craig> It's funny -- some people say that they just want the first
    craig> error, others (like myself) *know* we've enjoyed making use
    craig> of multiple error messages from a single compile, probably
    craig> including cases where subsequent errors came from
    craig> code-generation and related analysis.

First, let me say that I don't feel to strongly about this issue.

Second, I think that your logic, while *always* well-reasoned,
sometimes lead you astray.  We're human, and we're talking about a
computer-human interface here, so logic isn't always the guiding
light.

    craig> So, IMO, the only two behaviors worth considering
    craig> *assuming* we don't introduce any new command-line options
    craig> (in other words, mandating a behavior, just like we do now)
    craig> are:

    craig>   1.  Continue all normal processing after an error
    craig> (current behavior), and, over time, improve error recovery
    craig> in various front ends and back ends to make subsequent
    craig> diagnostics more pertinent.

    craig>   2.  Exit (with appropriate failure exit code) after an
    craig> error, and, over time, eliminate error-recovery code in the
    craig> compiler.

I understand how you got here, but I don't agree with:

    craig> I don't see what the "middle ground" buys us, since, to
    craig> avoid ICEs generally, we have to continue to maintain and,
    craig> perhaps, improve error recovery anyway, but some of the
    craig> benefits of that will never be seen by users, because
    craig> diagnostics that depend on code-generation happening won't
    craig> trigger.

I don't think there are all that many diagnostics that depend on
code-generation.  I know that there are some.  I find that in my own
code, typos (syntax errors) are the most usual problem.  If I sit down
and right a thousand lines, and then compile the file, there will
probably be a bunch of syntax errors, and probably no RTL-based
errors.  (In particular, I'm usually not compiling -O, which disables
some unitializedness checks at present.) 

So, getting through the whole file (good error-recovery) *is*
important to me.  I want to fix the whole bunch of syntax errors
before recompiling.  Getting them all quickly is also very important;
C++ in particular has the odd behavior that after much compilation you
can get new syntax errors (essentially) from looking at the same
template in a different way.  Thus, your option 2 is no good for me.

I do think we should improve error-recovery, etc.  But, if the
original poster is correct in noting a 5x decrease in
compilation-time, I'm all for making the change.  I know of real
programs that I really compile where this could really save me a lot
of time, and I don't (frankly) remember any situations where I would
have been really peeved not to have seen an RTL-based error until the
next compilation pass.

I'm afraid that's about the total of my (possibly) useful input on
this topic...

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: `--syntax-only' after error

[Joe Buck]

> Joe, what do you think of my idea of making this not the default,
> but conditional on an option like `-ffail-faster' or something?
> Then, only people who really want just the first fatal diagnostic
> will be the only ones affected, as only they will use the option.

It wouldn't destabilize the compiler to have a way to exit on the first
error, so I wouldn't have a reason to object if the option were added.

Re: `--syntax-only' after error

[Geert Bosch]

On Tue, 16 Feb 1999, Mark Mitchell wrote:
|I do think that you're right about various problems that require RTL
|not being diagnosed, but I just don't see that as very important.

I agree with this, especially because syntax errors may very well lead
to wrong and confusing error messages later on. The GNAT (GNU Ada95)
compiler uses the approach of not doing semantic checking in the case of
syntax errors and not doing code generation in the case of any errors.
This approach has turned out to be very useful, both for speed and quality
of error messages.

Of course the situation in C may be different because of the preprocessing
of all header files that must be done before checking the source file that
is being compiled. 

Regards,
   Geert

Re: `--syntax-only' after error

[Peter Gerwinski]

Joern Rennecke wrote:
>
> > We noticed that if we set `flag_syntax_only' after the first
> > error, compilation of the remaining (errorneous) source file
> > speeds up significantly (and finds possible other errors in the
> > file much faster).
> 
> But it won't find any semantic errors this way.

With `--syntax-only', the parser still does its job, including
type definitions and checks.  It's just the actual code generation
that is switched off.

    Peter

-- 
Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118
  PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75
Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

Re: `--syntax-only' after error

[Gerald Pfeifer]

On Thu, 18 Feb 1999, Horst von Brand wrote:
> Does this whole idea of setting optimization level to 0 make sense at all?
> AFAIU, O1 and higher set inlining on, O0 turns it off.

That's not correct:

  `-O2' turns on all optional optimizations except for loop unrolling
     and function inlining. ...

  '-O3'
     Optimize yet more.  `-O3' turns on all optimizations specified by
     `-O2' and also turns on the `inline-functions' option.

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: `--syntax-only' after error

[Joern Rennecke]

> Please let's consider the consequences carefully before making this
> change.  Is it really that much of a performance win?

I don't think it is - if the compiler hasn't finished after you have fixed
as many bugs as you wanted, you can always kill and restart it...

Re: `--syntax-only' after error

[Donn Terry]

Another alternative implementation of this, if it's concluded
that we can't afford to lose errors in a fatal compilation:

1) Turn optimization level down to 0.  (This probably turns off
   "unused variable" warnings, but...)  That's trivial, and has
   a pretty high return, because optimization is the expensive
   part of many compilations anyway.  (Turn off profiling and
   the like at the same time.)
2) Not so trivial: turn off any remaining compilation stages
   in toplev that don't yield warnings/errors.  (Specifically,
   those that do the generation of the acutal assembler.)
   (Probably the code just below the comment:
     /* Now turn the rtl into assembler code.  */
   in toplev.c.)

This doesn't save as much as --syntax-only would, but it's a
viable intermediate position to leaving everything on.

(Don't count this as a vote for not doing --syntax-only after
an error; the reality is that you can never trust a compiler
to catch all errors after a syntax error anyway, so I don't see
the lossage as too significant.  I know others disagree.  I have
used compilers that appear to do this, and I never felt burdened
by the possible loss of a (subtle) error message or two.)

Thinking out loud... there are syntax errors (e.g. grammar) that
can cause the compiler to go crazy, and there are semantic errors
that make the program uncompilable, but which don't cascade
(e.g. undeclared variable).  Should they do different things?
(No opinion expressed, just a thought.)

Donn

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: `--syntax-only' after error

[craig]

>Personally, I disagree.  I don't think the user-visible differences
>will be sufficiently great.  And, we have so many options as it is.  I
>think we should think very hard about adding additional ones, without
>a compelling reason.  And, in the long term, we should make some of
>the ones we have no-ops, even if we still accept them for
>backwards-compatibility!

As you might recall, I agree wholeheartedly with what you say about
options in general.  In this case, I felt that both proposed options
made long-term sense and were easy enough to support in any batch-I/O-
based compiler like gcc, regardless of how it might be rewritten,
that'd they'd be "safe" in the long run.

>A friend once pointed out that to fully test a product with n options
>requires exponentially many tests (in n).

Yes, that was one of my concerns as well, which I thought I'd
expressed.  (In particular, I'd like to check first whether I can
see obvious reasons the proposed `-ffail-faster' option might
introduce ICEs.)

>I do think that you're right about various problems that require RTL
>not being diagnosed, but I just don't see that as very important.

It's funny -- some people say that they just want the first error,
others (like myself) *know* we've enjoyed making use of multiple
error messages from a single compile, probably including cases where
subsequent errors came from code-generation and related analysis.

So, the first group wants the current behavior to change, but, as I'm
suggesting, it's possible the compiler currently isn't actually
designed and coded to support this.  (For example, `-fsyntax-only'
has been broken in the 1.2 sources for a couple of months, though
I haven't gotten around to fixing it just yet...and I *do* test it
using my personal g77 test suite.  I've had to fix that option at
least once before, in gcc2, awhile ago.)

The second group is happy with the current behavior, and does *not*
want it to change.

Note that the current behavior is made more appropriate and reasonable
as the error recovery for a given front end (plus the back end) improves
over time.  If we decide to offer only the *proposed* behavior (stop
generating code after first error), we'll still have good reasons
to improve that error recovery, which makes the *current* behavior even
more useful to people (if it held sway) anyway.

If we decide, however, to simply `exit (FAILURE);' on the first error,
then we can, over time, eliminate all error-recovery code from the
compiler, including (perhaps) all sorts of code that tests ERROR_MARK
(aka error_mark_node).  This would make the compiler much more
maintainable over time.

Those are some things to consider, and suggest you have a point about
not introducing new options, but just picking one behavior and sticking
with it.

However, if we go *that* route, IMO, the proposed behavior (which I
call `-ffail-faster') is the least worthwhile, because it still
requires graceful error recovery, which in turn leads to more helpful
subsequent errors, some of which this behavior *also* decides will
never be produced after all, just to save some compile time.

So, IMO, the only two behaviors worth considering *assuming* we don't
introduce any new command-line options (in other words, mandating
a behavior, just like we do now) are:

  1.  Continue all normal processing after an error (current behavior),
      and, over time, improve error recovery in various front ends
      and back ends to make subsequent diagnostics more pertinent.

  2.  Exit (with appropriate failure exit code) after an error, and,
      over time, eliminate error-recovery code in the compiler.

I don't see what the "middle ground" buys us, since, to avoid ICEs
generally, we have to continue to maintain and, perhaps, improve
error recovery anyway, but some of the benefits of that will never
be seen by users, because diagnostics that depend on code-generation
happening won't trigger.

So if we *really want* that middle ground, where code generation is
turned off after the first error, I say it is not useful to do it
*except* via a command-line option (either to enable or disable it,
i.e. the default is not really important, in this particular context).

        tq vm, (burley)

Re: `--syntax-only' after error

[Nick Ing-Simmons]

<craig@jcb-sc.com> writes:
>>Exactly.  If I didn't see such errors and then saw new ones when I
>>recompiled, I'd be annoyed.  To me, the uninitialized variable warnings
>>are quite important; if I specify -Wall, I have asked for all warnings,
>>not just all warnings before the first error.
>
>That's a good point.

Maybe -Wall should turn it off ?

>
>>Please let's consider the consequences carefully before making this
>>change.  Is it really that much of a performance win?
>
>Joe, what do you think of my idea of making this not the default,
>but conditional on an option like `-ffail-faster' or something?

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: `--syntax-only' after error

[craig]

>it seems that the idea is accepted.  The patch consists in
>adding a single line
>
>    flag_syntax_only = 1;
>
>to the `v_error_...()' functions in `toplev.c' - or better to a
>central place like `count_error()'.  Since I would have to
>download a recent EGCS snapshot first (I only have egcs-1.1.1
>here) and I am short of disk space and bandwidth, I would prefer
>if someone else could do the actual change.

I don't mind taking care of this.  I still have reservations about
it, e.g., it'll probably make *some* types of error detection
stop working after the first error.  I believe those types include
errors/warnings stemming from RTL analysis, such as uninitialized-
variable and such.  Even a programmer who sees a fatal error in
one routine might want to also see an uninit-var warning in a
subsequent, distinct routine.

Also, I'd like to have some time to look over the pertinent bits
of code to see whether there might be a nesting problem that could
lead to compiler crashes in some cases.  (Not worth trying to explain
that here.)

Finally, I think this would make for enough of a user-visible difference
that, IMO, it should not be the default, but be enabled by an option,
which, if it is indeed not on by default, I suggest be called
something like `-ffail-faster'.  (Not `-ffail-fast'; that would
do something like call `exit(FAILURE);' upon seeing the first
fatal message, like my Mac's old Think C system used to do.)

Any feedback on the above would be appreciated, and there's quite a
bit of time, as I won't get to this until next week at the earliest,
barring some miracle.

        tq vm, (burley)

Re: `--syntax-only' after error

[craig]

>Exactly.  If I didn't see such errors and then saw new ones when I
>recompiled, I'd be annoyed.  To me, the uninitialized variable warnings
>are quite important; if I specify -Wall, I have asked for all warnings,
>not just all warnings before the first error.

That's a good point.

>Please let's consider the consequences carefully before making this
>change.  Is it really that much of a performance win?

Joe, what do you think of my idea of making this not the default,
but conditional on an option like `-ffail-faster' or something?
Then, only people who really want just the first fatal diagnostic
will be the only ones affected, as only they will use the option.

        tq vm, (burley)

Re: `--syntax-only' after error

[Joe Buck]

> > Another alternative implementation of this, if it's concluded
> > that we can't afford to lose errors in a fatal compilation:

"fatal compilation" to me suggests something like an ICE, not an illegal
construct.

> > 1) Turn optimization level down to 0.  (This probably turns off
> >    "unused variable" warnings, but...)

But I don't want to lose them, in the very common case where there
is a recoverable syntax error in an interior block of the first function,
and there are n more functions.

Re: `--syntax-only' after error

[craig]

>I agree. But I wasn't talking about this option, but rather about the
>syntax-only option. I do agree with you that having an option to abort
>after the first error might be useful to have, even though I personally
>will probably never use it.

The -fsyntax-only option already exists and is supported, though in
the current sources (1.2) it causes the compiler to crash for some
sources (on my to-do list to fix).  I think you might be confused
by the subject header -- which actually refers to the idea of
turning on -fsyntax-only (mispelled in the header) partway through
the compilation, when the first error message is printed, to do less
work during the rest of the compile (which also means not printing
certain kinds of diagnostics, including potentially useful warnings,
later on -- e.g. unitialized-variable and asm-related diagnostics).

The proposed change(s) and option(s) seem to have died for
lack of both interest and consensus.  I'm happy enough with that
-- well, personally, I'd probably never have used the different
behavior anyway, but I mean I think that's the best approach for
gcc at this time, to do nothing (except fix the -fsyntax-only bug).

        tq vm, (burley)

Re: `--syntax-only' after error

[Peter Gerwinski]

Jeffrey A Law wrote:
>   > Please let's consider the consequences carefully before making this
>   > change.  Is it really that much of a performance win?
> In an optimizing compile?  Yes.  The amount of time spent in the front-end
> up to initial rtl generation is dwarfed by the amount of time spent in the
> optimizers.
> 
> For unoptimized compiles it's less of a win.

Even in an unoptimized compile I noticed a factor of five
between compilation with and without `--syntax-only'.  The
change can be a significant win in a large project where there
is one error near the beginning and another one near the end.

    Peter

-- 
Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/
Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118
  PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75
Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

Re: `--syntax-only' after error

[Kamil Iskra]

On Thu, 18 Feb 1999, Marc Espie wrote:

> >Let's be serious. Either the feature should be on by default (and than
> >adding an option to turn it off makes sense) or it shouldn't be integrated
> >into the compiler at all.
> You're trying to force the issue, one way or another. This is definitely 
> cleaner, but it looks like it won't be please everyone. So the option may
> get dropped completely. Why ? It looks to me like a user's choice.

I don't think users should be given choice on issues like this one.
Options should provide users with new, important features. This option
would not provide any feature at all, whether important or not. It would
be just a little tweak for wizards.

The issue is a minor one, therefore, it does not deserve an option. If
EGCS starts adding options for such issues, we will soon have hundreds of
them, as if we already didn't have too many. Many people dislike UNIX for
its dozens of cryptic, mostly useless command line options. Let's not make
the situation worse.

Basically, the reason some people are advocating for an option is that
there is no unanimity among the developers, "so let's make it an option".
Options should not be added on such basis. It is simply not fair to put
additional burden on plain users just because developers couldn't reach an
agreement.

> Some people prefer getting all the errors in one bunch, whereas others
> prefer to first fix one error, then re-run the compiler.  
> 
> I fail to see why one of these ways to work should be `better'.

I agree. But I wasn't talking about this option, but rather about the
syntax-only option. I do agree with you that having an option to abort
after the first error might be useful to have, even though I personally
will probably never use it.

/ Kamil Iskra    AmigaOS  Linux/i386  Linux/m68k               \
| GeekGadgets m68k-amigaos GCC maintainer                      |
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
\ kamil@dwd.interkom.pl   http://student.uci.agh.edu.pl/~iskra /