How GCC treats ice-on-invalid-code?

[Richard Sandiford]

Hi,

Haoxin Tu via Gcc-bugs <gcc-bugs@gcc.gnu.org> writes:
> Hi, there,
>
> Our team just develop a c++ code generator tool to testing the compiler,
> and those days I have reported 13 ICE bugs in ice-on-invalid-bugs.
>
> Here are the bugs links:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95972
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95956
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95955
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95954
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95925
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95930
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95931
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95927
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95932
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95935
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95945
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95938
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95937
>
> Until now, only the last two cases are confirmed. So I am wondering that
> how GCC treats with those cases in ice-on-invalid-code? I mean, our team is
> focusing on improving the quality of the mature productive compilers. If
> those bugs are useless for GCC, maybe I should stop reporting similar
> issues.
>
> Waiting for your reply. Thank you very much!

Thanks for the work and for the bug reports.

There are really two categories of ICE on erroneous code: those in
which the compiler reports an ICE *after* reporting a sensible error
in the code and those in which the compiler reports an ICE *without*
first reporting a sensible error.

If the compiler encounters an ICE after reporting an error, production
builds will print:

    confused by earlier errors, bailing out

instead of reporting the ICE itself.  For example, for PR95937,
the production build would print something like:

bug.cc:1:6: error: variable or field ‘a’ declared void
    1 | void a { [].decltype(auto)::b
      |      ^
bug.cc: In lambda function:
bug.cc:1:12: error: expected ‘{’ before ‘.’ token
    1 | void a { [].decltype(auto)::b
      |            ^
bug.cc: At global scope:
bug.cc:1:29: confused by earlier errors, bailing out

Although this isn't ideal, it's not too bad in practice, since the
errors before the “bailing out” message tell the user what they
need to do to fix the problem.  In fact, there's a danger that if the
compiler is confused enough to hit (or almost hit) an ICE and continues
regardless, it could spew a lot of meaningless error messages and drown
out the useful information.  So in some cases, this “bailing out”
message can (accidentally) be a good thing. :-)

In bugzilla, this category of error is classified as “error-recovery”
rather than “ice-on-invalid-code”; see:

  https://gcc.gnu.org/bugs/management.html

for details.  Because the ICE doesn't show up as an ICE in production
builds, and because bailing out can sometimes even make the user
experience better, these bugs tend to have a very low priority.

In contrast, the second category of ICE above is much more serious.
If GCC encounters an ICE without first reporting a normal error message,
it will print that ICE even in production builds.  And this ICE message
will generally give the user no idea what's wrong or what they need
to do to fix the code.

These are the “true” ice-on-invalid-code bugs, i.e. those that are
meant to be classified as “ice-on-invalid-code” instead of “error-recovery”
in bugzilla.  They generally get much more attention than “error-recovery”
bugs.

So if your tool is finding a lot of ICEs in GCC (and I imagine it is),
then it might be worth concentrating on filing bugs for the cases in
which GCC fails to report a normal user-level error before reporting
an ICE.

Thanks,
Richard