Re: How GCC treats ice-on-invalid-code?
> 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
Re: How GCC treats ice-on-invalid-code?
Eric Botcazou 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?
> 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?
> 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?
> I am sorry maybe I send this in a wrong place, I have sent this again in > gcc-bug-requ...@gcc.gun.org. Well that's even more wrong. g...@gcc.gnu.org would be the right place.
Re: How GCC treats ice-on-invalid-code?
Hi,
Haoxin Tu via Gcc-bugs 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?
I am sorry maybe I send this in a wrong place, I have sent this again in gcc-bug-requ...@gcc.gun.org. Haoxin Tu 于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 >
How GCC treats ice-on-invalid-code?
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
