[PING] Advise to call 'internal_error' instead of 'abort' or 'fancy_abort'

Message ID 87h75opirb.fsf@dem-tschwing-1.ger.mentorg.com
State Committed
Headers
Series [PING] Advise to call 'internal_error' instead of 'abort' or 'fancy_abort' |

Commit Message

Thomas Schwinge May 17, 2022, 10:15 a.m. UTC
  Hi!

Ping.


Grüße
 Thomas


On 2022-05-10T16:03:12+0200, I wrote:
> Hi!
>
> On 2022-05-03T15:46:43+0200, Richard Biener <richard.guenther@gmail.com> wrote:
>> On Tue, May 3, 2022 at 2:29 PM Thomas Schwinge <thomas@codesourcery.com> wrote:
>>> On 2022-05-03T12:53:50+0200, Richard Biener <richard.guenther@gmail.com> wrote:
>>> > On Tue, May 3, 2022 at 10:16 AM Thomas Schwinge <thomas@codesourcery.com> wrote:
>>> >> On 2022-05-03T09:17:52+0200, Richard Biener <richard.guenther@gmail.com> wrote:
>>> >> > On Mon, May 2, 2022 at 4:01 PM Thomas Schwinge <thomas@codesourcery.com> wrote:
>>> >> > +#if 0
>>> >> >        gcc_unreachable ();
>>> >> > +#else
>>> >> > +      /* ..., but due to bugs (PR100400), we may actually come here.
>>> >> > +        Reliably catch this, regardless of checking level.  */
>>> >> > +      abort ();
>>> >> > +#endif
>>> >> >
>>> >> > this doesn't look correct.  If you want a reliable diagnostic here please [...]
>>> >> > call internal_error () manually (the IL verifiers do this).
>>> >>
>>> >> Hmm, I feel I'm going in circles...  ;-)
>
>>> >> I first had this as 'internal_error', but then saw the following source
>>> >> code comment, 'gcc/diagnostic.cc':
>>> >>
>>> >>     /* An internal consistency check has failed.  We make no attempt to
>>> >>        continue.  Note that unless there is debugging value to be had from
>>> >>        a more specific message, or some other good reason, you should use
>>> >>        abort () instead of calling this function directly.  */
>>> >>     void
>>> >>     internal_error (const char *gmsgid, ...)
>>> >>     {
>>> >>
>>> >> Here, there's no "debugging value to be had from a more specific
>>> >> message", and I couldn't think of "some other good reason", so decided to
>>> >> "use abort () instead of calling this function directly".
>>> >
>>> > I think that is misguided.
>>>
>>> So that I know which one to fix/reconsider: does your "that" refer to the
>>> 'gcc/diagnostic.cc:internal_error' source code comment cited above, or my
>>> interpretation of it?
>>
>> The comment to "use abort ()".
>
> Does the attached
> "Advise to call 'internal_error' instead of 'abort' or 'fancy_abort'"
> capture what you had in mind?
>
> (This is, obviously, not updating any of the many 'abort' or even a few
> 'fancy_abort' calls that we currently have.)
>
>
> Grüße
>  Thomas


-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
  

Comments

Richard Biener May 17, 2022, 2:13 p.m. UTC | #1
On Tue, May 17, 2022 at 12:15 PM Thomas Schwinge
<thomas@codesourcery.com> wrote:
>
> Hi!
>
> Ping.

OK.

>
> Grüße
>  Thomas
>
>
> On 2022-05-10T16:03:12+0200, I wrote:
> > Hi!
> >
> > On 2022-05-03T15:46:43+0200, Richard Biener <richard.guenther@gmail.com> wrote:
> >> On Tue, May 3, 2022 at 2:29 PM Thomas Schwinge <thomas@codesourcery.com> wrote:
> >>> On 2022-05-03T12:53:50+0200, Richard Biener <richard.guenther@gmail.com> wrote:
> >>> > On Tue, May 3, 2022 at 10:16 AM Thomas Schwinge <thomas@codesourcery.com> wrote:
> >>> >> On 2022-05-03T09:17:52+0200, Richard Biener <richard.guenther@gmail.com> wrote:
> >>> >> > On Mon, May 2, 2022 at 4:01 PM Thomas Schwinge <thomas@codesourcery.com> wrote:
> >>> >> > +#if 0
> >>> >> >        gcc_unreachable ();
> >>> >> > +#else
> >>> >> > +      /* ..., but due to bugs (PR100400), we may actually come here.
> >>> >> > +        Reliably catch this, regardless of checking level.  */
> >>> >> > +      abort ();
> >>> >> > +#endif
> >>> >> >
> >>> >> > this doesn't look correct.  If you want a reliable diagnostic here please [...]
> >>> >> > call internal_error () manually (the IL verifiers do this).
> >>> >>
> >>> >> Hmm, I feel I'm going in circles...  ;-)
> >
> >>> >> I first had this as 'internal_error', but then saw the following source
> >>> >> code comment, 'gcc/diagnostic.cc':
> >>> >>
> >>> >>     /* An internal consistency check has failed.  We make no attempt to
> >>> >>        continue.  Note that unless there is debugging value to be had from
> >>> >>        a more specific message, or some other good reason, you should use
> >>> >>        abort () instead of calling this function directly.  */
> >>> >>     void
> >>> >>     internal_error (const char *gmsgid, ...)
> >>> >>     {
> >>> >>
> >>> >> Here, there's no "debugging value to be had from a more specific
> >>> >> message", and I couldn't think of "some other good reason", so decided to
> >>> >> "use abort () instead of calling this function directly".
> >>> >
> >>> > I think that is misguided.
> >>>
> >>> So that I know which one to fix/reconsider: does your "that" refer to the
> >>> 'gcc/diagnostic.cc:internal_error' source code comment cited above, or my
> >>> interpretation of it?
> >>
> >> The comment to "use abort ()".
> >
> > Does the attached
> > "Advise to call 'internal_error' instead of 'abort' or 'fancy_abort'"
> > capture what you had in mind?
> >
> > (This is, obviously, not updating any of the many 'abort' or even a few
> > 'fancy_abort' calls that we currently have.)
> >
> >
> > Grüße
> >  Thomas
>
>
> -----------------
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
  

Patch

From a8017c7b5fa7b5e8210b6446acf7dd09989a7517 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@codesourcery.com>
Date: Tue, 10 May 2022 15:56:08 +0200
Subject: [PATCH] Advise to call 'internal_error' instead of 'abort' or
 'fancy_abort'

	gcc/
	* diagnostic.cc: Don't advise to call 'abort' instead of
	'internal_error'.
	* system.h: Advise to call 'internal_error' instead of 'abort' or
	'fancy_abort'.

Suggested-by: Richard Biener <richard.guenther@gmail.com>
---
 gcc/diagnostic.cc | 4 +---
 gcc/system.h      | 6 ++++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
index 73324a728fe..fef11467b6f 100644
--- a/gcc/diagnostic.cc
+++ b/gcc/diagnostic.cc
@@ -1935,9 +1935,7 @@  fatal_error (location_t loc, const char *gmsgid, ...)
 }
 
 /* An internal consistency check has failed.  We make no attempt to
-   continue.  Note that unless there is debugging value to be had from
-   a more specific message, or some other good reason, you should use
-   abort () instead of calling this function directly.  */
+   continue.  */
 void
 internal_error (const char *gmsgid, ...)
 {
diff --git a/gcc/system.h b/gcc/system.h
index c25cd64366f..187763efcd6 100644
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -770,8 +770,10 @@  extern int vsnprintf (char *, size_t, const char *, va_list);
 #endif
 #endif
 
-/* Redefine abort to report an internal error w/o coredump, and
-   reporting the location of the error in the source file.  */
+/* Redefine 'abort' to report an internal error w/o coredump, and
+   reporting the location of the error in the source file.
+   Instead of directly calling 'abort' or 'fancy_abort', GCC code
+   should normally call 'internal_error' with a specific message.  */
 extern void fancy_abort (const char *, int, const char *)
 					 ATTRIBUTE_NORETURN ATTRIBUTE_COLD;
 #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
-- 
2.25.1