How GCC treats ice-on-invalid-code?

How GCC treats ice-on-invalid-code?

[Haoxin Tu]

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!


Best regrades,
Haoxin

Re: How GCC treats ice-on-invalid-code?

[Haoxin Tu]

I am sorry maybe I send this in a wrong place, I have sent this again in
gcc-bug-request@gcc.gun.org.

Haoxin Tu <haoxintu@gmail.com> 于2020年6月30日周二 上午10:32写道：

> 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!
>
>
> Best regrades,
> Haoxin
>

Re: 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

Re: How GCC treats ice-on-invalid-code?

[Jonathan Wakely]

> I am sorry maybe I send this in a wrong place, I have sent this again in
> gcc-bug-request@gcc.gun.org.

Well that's even more wrong. gcc@gcc.gnu.org would be the right place.

Re: How GCC treats ice-on-invalid-code?

[Jonathan Wakely]

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

And even those are lower priority than ice-on-valid bugs, and IMHO
lower priority than rejects-valid bugs.

It's fine to file these ice-on-invalid bugs, but don't be surprised if
nobody has time to work on bugs that are only triggered by unrealistic
garbage input.

Re: How GCC treats ice-on-invalid-code?

[Eric Botcazou]

> It's fine to file these ice-on-invalid bugs, but don't be surprised if
> nobody has time to work on bugs that are only triggered by unrealistic
> garbage input.

Right, an ICE is a perfectly valid outcome for garbage input and there are 
hundreds of assertions in the compiler precisely for this purpose.

-- 
Eric Botcazou

Re: How GCC treats ice-on-invalid-code?

[Richard Sandiford]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:
>> It's fine to file these ice-on-invalid bugs, but don't be surprised if
>> nobody has time to work on bugs that are only triggered by unrealistic
>> garbage input.
>
> Right, an ICE is a perfectly valid outcome for garbage input and there are 
> hundreds of assertions in the compiler precisely for this purpose.

You mean, an ICE is perfectly valid as the first (and obviously then
only) error diagnostic the compiler prints for “garbage input”?
If so, I don't think that's true.  What counts as “garbage” seems
a bit too subjective for that anyway.

E.g. deleting a chunk of lines from a file creates something that makes
no sense and might be considered garbage, but that can easily happen
with a botched resolution to a merge conflict (or being too trigger-happy
with git rerere :-)).  I don't think it's OK for the compiler simply to
crash without first giving the user an idea of what's wrong.

I agree ICEs are mostly OK as a downstream effect of an error that has
already been reported, but in the context of the quote above, those cases
are error-recovery rather than ice-on-invalid-code.

Thanks,
Richard

Re: How GCC treats ice-on-invalid-code?

[Eric Botcazou]

> You mean, an ICE is perfectly valid as the first (and obviously then
> only) error diagnostic the compiler prints for “garbage input”?
> If so, I don't think that's true.  What counts as “garbage” seems
> a bit too subjective for that anyway.

When the input is totally nonsensical, e.g. generated by a machine for the 
sole purpose of torturing the compiler, an ICE is good enough and IMO the bug 
report should essentially be ignored.  We have hundreds of open bug reports 
for perfectly sensible code and any of them should have higher priority.

> E.g. deleting a chunk of lines from a file creates something that makes
> no sense and might be considered garbage, but that can easily happen
> with a botched resolution to a merge conflict (or being too trigger-happy
> with git rerere :-)).  I don't think it's OK for the compiler simply to
> crash without first giving the user an idea of what's wrong.

Sure, if the input originally comes from a real program, it's not garbage.

-- 
Eric Botcazou