From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id EC7BF3861020 for ; Tue, 30 Jun 2020 13:23:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EC7BF3861020 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=richard.sandiford@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 090881FB; Tue, 30 Jun 2020 06:23:00 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 813AA3F71E; Tue, 30 Jun 2020 06:22:59 -0700 (PDT) From: Richard Sandiford To: Haoxin Tu via Gcc-bugs Mail-Followup-To: Haoxin Tu via Gcc-bugs , Haoxin Tu , richard.sandiford@arm.com Cc: Haoxin Tu Subject: Re: How GCC treats ice-on-invalid-code? References: Date: Tue, 30 Jun 2020 14:22:57 +0100 In-Reply-To: (Haoxin Tu via Gcc-bugs's message of "Tue, 30 Jun 2020 10:32:18 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-9.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 13:23:03 -0000 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=3D95972 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95956 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95955 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95954 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95925 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95930 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95931 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95927 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95932 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95935 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95945 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95938 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95937 > > 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 =E2=80=98a=E2=80=99 declared void 1 | void a { [].decltype(auto)::b | ^ bug.cc: In lambda function: bug.cc:1:12: error: expected =E2=80=98{=E2=80=99 before =E2=80=98.=E2=80=99= 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 =E2=80=9Cbailing out=E2=80=9D 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 =E2=80=9Cbailing out=E2= =80=9D message can (accidentally) be a good thing. :-) In bugzilla, this category of error is classified as =E2=80=9Cerror-recover= y=E2=80=9D rather than =E2=80=9Cice-on-invalid-code=E2=80=9D; 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 =E2=80=9Ctrue=E2=80=9D ice-on-invalid-code bugs, i.e. those t= hat are meant to be classified as =E2=80=9Cice-on-invalid-code=E2=80=9D instead of = =E2=80=9Cerror-recovery=E2=80=9D in bugzilla. They generally get much more attention than =E2=80=9Cerror-re= covery=E2=80=9D 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