libstdc++: Implement std::unreachable() for C++23 (P0627R6)

  This is a tiny C++23 feature that I plan to add for GCC 12. Does anybody
have any comments on the choices below in terms of when to make reaching
std::unreachable do an assert/trap/unreachable?

My thoughts on avoiding the overhead in the _GLIBCXX_ASSERTIONS case is
that this differs from e.g. assertions in operator[] where we want to
catch accidental bad indices. A std::unreachable() call should not be
reached accidentally. I hope it will only be used for conditions that
really are unreachable, and probably quite often where performance
matters. If using std::unreachable() increased code size significantly
then it would make it much less useful for guiding optimizations.


-- >8 --

This defines std::unreachable as an assertion for debug mode, a trap
when _GLIBCXX_ASSERTIONS is defined, and __builtin_unreachable()
otherwise.

The reason for only using __builtin_trap() in the second case is to
avoid the overhead of setting up a call to __glibcxx_assert_fail that
should never happen.

While thinking about what the debug assertion failure should print, I
noticed that the __glibcxx_assert_fail function doesn't check for null
pointers. This adds a check so we don't try to print them if null.

libstdc++-v3/ChangeLog:

	* include/std/utility (unreachable): Define for C++23.
	* include/std/version (__cpp_lib_unreachable): Define.
	* src/c++11/debug.cc (__glibcxx_assert_fail): Check for valid
	arguments.
	* testsuite/20_util/unreachable/1.cc: New test.
	* testsuite/20_util/unreachable/version.cc: New test.
---
 libstdc++-v3/include/std/utility                | 15 +++++++++++++++
 libstdc++-v3/include/std/version                |  1 +
 libstdc++-v3/src/c++11/debug.cc                 |  5 +++--
 libstdc++-v3/testsuite/20_util/unreachable/1.cc | 17 +++++++++++++++++
 .../testsuite/20_util/unreachable/version.cc    | 10 ++++++++++
 5 files changed, 46 insertions(+), 2 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/20_util/unreachable/1.cc
 create mode 100644 libstdc++-v3/testsuite/20_util/unreachable/version.cc
  

I like it. But I'd like it even more if we could have

#elif defined _UBSAN
    __ubsan_invoke_ub("reached std::unreachable()");

But to my knowledge UBSAN has no hooks for the library like this (yet).

and...

On Thursday, 31 March 2022 17:30:29 CEST Jonathan Wakely via Gcc-patches 
wrote:
> diff --git a/libstdc++-v3/include/std/utility
> b/libstdc++-v3/include/std/utility index 0d7f8954c5a..e5b5212381d 100644
> --- a/libstdc++-v3/include/std/utility
> +++ b/libstdc++-v3/include/std/utility
> @@ -186,6 +186,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>      constexpr underlying_type_t<_Tp>
>      to_underlying(_Tp __value) noexcept
>      { return static_cast<underlying_type_t<_Tp>>(__value); }
> +
> +#define __cpp_lib_unreachable 202202L
> +  [[noreturn,__gnu__::__always_inline__]]
> +  void
> +  unreachable()
> +  {
> +#ifdef _GLIBCXX_DEBUG
> +    std::__glibcxx_assert_fail("<utility>", 0, "std::unreachable()",
> +                              "inconceivable!");

Funny message, but it should be more helpful, IMHO. :)

-Matthias

> +#elif defined _GLIBCXX_ASSERTIONS
> +    __builtin_trap();
> +#else
> +    __builtin_unreachable();
> +#endif
> +  }
  

On Thu, 2022-03-31 at 17:50 +0200, Matthias Kretz via Gcc-patches wrote:
> I like it. But I'd like it even more if we could have
> 
> #elif defined _UBSAN
>     __ubsan_invoke_ub("reached std::unreachable()");
> 
> But to my knowledge UBSAN has no hooks for the library like this
> (yet).

UBSAN can catch __builtin_unreachable() and print a message "execution
reached an unreachable program point".
  

On Thu, 31 Mar 2022, Matthias Kretz via Gcc-patches wrote:

> I like it. But I'd like it even more if we could have
>
> #elif defined _UBSAN
>    __ubsan_invoke_ub("reached std::unreachable()");
>
> But to my knowledge UBSAN has no hooks for the library like this (yet).

-fsanitize=undefined already replaces __builtin_unreachable with its own 
thing, so I was indeed going to ask if the assertion / trap provide a 
better debugging experience compared to plain __builtin_unreachable, with 
the possibility to get a stack trace (UBSAN_OPTIONS=print_stacktrace=1), 
etc? Detecting if (the right subset of) ubsan is enabled sounds like a 
good idea.
  

On Thu, 31 Mar 2022 at 16:51, Matthias Kretz via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
>
> I like it. But I'd like it even more if we could have
>
> #elif defined _UBSAN
>     __ubsan_invoke_ub("reached std::unreachable()");
>
> But to my knowledge UBSAN has no hooks for the library like this (yet).

As far as I know, that's correct.


> > +#ifdef _GLIBCXX_DEBUG
> > +    std::__glibcxx_assert_fail("<utility>", 0, "std::unreachable()",
> > +                              "inconceivable!");
>
> Funny message, but it should be more helpful, IMHO. :)

We're currently limited to some string that can go inside "Assertion
'...' failed."

I also considered changing __glibcxx_assert_fail like so:

--- a/libstdc++-v3/src/c++11/debug.cc
+++ b/libstdc++-v3/src/c++11/debug.cc
@@ -55,6 +55,8 @@ namespace std
    if (file && function && condition)
      fprintf(stderr, "%s:%d: %s: Assertion '%s' failed.\n",
             file, line, function, condition);
+    else if (function)
+      fprintf(stderr, "%s called.\n", function);
    abort();
  }
}

And then making std::unreachable() call __glibcxx_assert_fail(0, 0,
"std::unreachable()", 0).
  

On Thu, 31 Mar 2022 at 17:03, Marc Glisse via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
>
> On Thu, 31 Mar 2022, Matthias Kretz via Gcc-patches wrote:
>
> > I like it. But I'd like it even more if we could have
> >
> > #elif defined _UBSAN
> >    __ubsan_invoke_ub("reached std::unreachable()");
> >
> > But to my knowledge UBSAN has no hooks for the library like this (yet).
>
> -fsanitize=undefined already replaces __builtin_unreachable with its own
> thing, so I was indeed going to ask if the assertion / trap provide a
> better debugging experience compared to plain __builtin_unreachable, with
> the possibility to get a stack trace (UBSAN_OPTIONS=print_stacktrace=1),
> etc? Detecting if (the right subset of) ubsan is enabled sounds like a
> good idea.

Does UBsan define a macro that we can use to detect it?
  

On Thu, 31 Mar 2022, Jonathan Wakely wrote:

> On Thu, 31 Mar 2022 at 17:03, Marc Glisse via Libstdc++
> <libstdc++@gcc.gnu.org> wrote:
>>
>> On Thu, 31 Mar 2022, Matthias Kretz via Gcc-patches wrote:
>>
>>> I like it. But I'd like it even more if we could have
>>>
>>> #elif defined _UBSAN
>>>    __ubsan_invoke_ub("reached std::unreachable()");
>>>
>>> But to my knowledge UBSAN has no hooks for the library like this (yet).
>>
>> -fsanitize=undefined already replaces __builtin_unreachable with its own
>> thing, so I was indeed going to ask if the assertion / trap provide a
>> better debugging experience compared to plain __builtin_unreachable, with
>> the possibility to get a stack trace (UBSAN_OPTIONS=print_stacktrace=1),
>> etc? Detecting if (the right subset of) ubsan is enabled sounds like a
>> good idea.
>
> Does UBsan define a macro that we can use to detect it?

https://github.com/google/sanitizers/issues/765 seems to say no (it could 
be outdated though), but they were asking for use cases to motivate adding 
one. Apparently there is a macro for clang, although I don't think it is 
fine-grained.

Adding one to cppbuiltin.cc testing SANITIZE_UNREACHABLE looks easy, maybe 
we can do just this one, we don't need to go overboard and define macros 
for all possible suboptions of ubsan right now.

I don't think any of that prevents from pushing your patch as is for 
gcc-12.
  

On Thu, 31 Mar 2022 at 19:21, Marc Glisse wrote:
>
> On Thu, 31 Mar 2022, Jonathan Wakely wrote:
>
> > On Thu, 31 Mar 2022 at 17:03, Marc Glisse via Libstdc++
> > <libstdc++@gcc.gnu.org> wrote:
> >>
> >> On Thu, 31 Mar 2022, Matthias Kretz via Gcc-patches wrote:
> >>
> >>> I like it. But I'd like it even more if we could have
> >>>
> >>> #elif defined _UBSAN
> >>>    __ubsan_invoke_ub("reached std::unreachable()");
> >>>
> >>> But to my knowledge UBSAN has no hooks for the library like this (yet).
> >>
> >> -fsanitize=undefined already replaces __builtin_unreachable with its own
> >> thing, so I was indeed going to ask if the assertion / trap provide a
> >> better debugging experience compared to plain __builtin_unreachable, with
> >> the possibility to get a stack trace (UBSAN_OPTIONS=print_stacktrace=1),
> >> etc? Detecting if (the right subset of) ubsan is enabled sounds like a
> >> good idea.
> >
> > Does UBsan define a macro that we can use to detect it?
>
> https://github.com/google/sanitizers/issues/765 seems to say no (it could
> be outdated though), but they were asking for use cases to motivate adding
> one. Apparently there is a macro for clang, although I don't think it is
> fine-grained.
>
> Adding one to cppbuiltin.cc testing SANITIZE_UNREACHABLE looks easy, maybe
> we can do just this one, we don't need to go overboard and define macros
> for all possible suboptions of ubsan right now.

Yes, we should only add what there's a use case for.

> I don't think any of that prevents from pushing your patch as is for
> gcc-12.

Matthias didn't like my Princess Bride easter egg :-)
Would the attached be better?
commit e2b2cf6319406bc9cb9361962cf7c31b1848ebe8
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Fri Apr 1 12:25:02 2022

    libstdc++: Implement std::unreachable() for C++23 (P0627R6)
    
    This defines std::unreachable as an assertion for debug mode, a trap
    when _GLIBCXX_ASSERTIONS is defined, and __builtin_unreachable()
    otherwise.
    
    The reason for only using __builtin_trap() in the second case is to
    avoid the overhead of setting up a call to __glibcxx_assert_fail that
    should never happen.
    
    UBsan can detect if __builtin_unreachable() is executed, so if a feature
    test macro for that sanitizer is added, we could change just use
    __builtin_unreachable() when the sanitizer is enabled.
    
    While thinking about what the debug assertion failure should print, I
    noticed that the __glibcxx_assert_fail function doesn't check for null
    pointers. This adds a check so we don't try to print them if null.
    
    libstdc++-v3/ChangeLog:
    
            * include/std/utility (unreachable): Define for C++23.
            * include/std/version (__cpp_lib_unreachable): Define.
            * src/c++11/debug.cc (__glibcxx_assert_fail): Check for valid
            arguments. Handle only the function being given.
            * testsuite/20_util/unreachable/1.cc: New test.
            * testsuite/20_util/unreachable/version.cc: New test.

diff --git a/libstdc++-v3/include/std/utility b/libstdc++-v3/include/std/utility
index 0d7f8954c5a..ad5faa50f57 100644
--- a/libstdc++-v3/include/std/utility
+++ b/libstdc++-v3/include/std/utility
@@ -186,6 +186,32 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
     constexpr underlying_type_t<_Tp>
     to_underlying(_Tp __value) noexcept
     { return static_cast<underlying_type_t<_Tp>>(__value); }
+
+#define __cpp_lib_unreachable 202202L
+  /// Informs the compiler that program control flow never reaches this point.
+  /**
+   * Evaluating a call to this function results in undefined behaviour.
+   * This can be used as an assertion informing the compiler that certain
+   * conditions are impossible, for when the compiler is unable to determine
+   * that by itself.
+   *
+   * For example, it can be used to prevent warnings about reaching the
+   * end of a non-void function without returning.
+   *
+   * @since C++23
+   */
+  [[noreturn,__gnu__::__always_inline__]]
+  inline void
+  unreachable()
+  {
+#ifdef _GLIBCXX_DEBUG
+    std::__glibcxx_assert_fail(nullptr, 0, "std::unreachable()", nullptr);
+#elif defined _GLIBCXX_ASSERTIONS
+    __builtin_trap();
+#else
+    __builtin_unreachable();
+#endif
+  }
 #endif // C++23
 #endif // C++20
 #endif // C++17
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 44b8a9f88b5..51f2110b68e 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -326,6 +326,7 @@
 # define __cpp_lib_string_resize_and_overwrite 202110L
 #endif
 #define __cpp_lib_to_underlying 202102L
+#define __cpp_lib_unreachable 202202L
 #endif
 #endif // C++2b
 #endif // C++20
diff --git a/libstdc++-v3/src/c++11/debug.cc b/libstdc++-v3/src/c++11/debug.cc
index 98fe2dcc153..4706defedf1 100644
--- a/libstdc++-v3/src/c++11/debug.cc
+++ b/libstdc++-v3/src/c++11/debug.cc
@@ -52,8 +52,11 @@ namespace std
   __glibcxx_assert_fail(const char* file, int line,
 			const char* function, const char* condition) noexcept
   {
-    fprintf(stderr, "%s:%d: %s: Assertion '%s' failed.\n",
-		      file, line, function, condition);
+    if (file && function && condition)
+      fprintf(stderr, "%s:%d: %s: Assertion '%s' failed.\n",
+	      file, line, function, condition);
+    else if (function)
+      fprintf(stderr, "%s: Undefined behavior detected.\n", function);
     abort();
   }
 }
diff --git a/libstdc++-v3/testsuite/20_util/unreachable/1.cc b/libstdc++-v3/testsuite/20_util/unreachable/1.cc
new file mode 100644
index 00000000000..0c463d52a48
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/unreachable/1.cc
@@ -0,0 +1,17 @@
+// { dg-options "-std=gnu++23" }
+// { dg-do compile { target c++23 } }
+
+#include <utility>
+
+#ifndef __cpp_lib_unreachable
+# error "Feature-test macro for unreachable missing in <utility>"
+#elif __cpp_lib_unreachable != 202202L
+# error "Feature-test macro for unreachable has wrong value in <utility>"
+#endif
+
+bool test01(int i)
+{
+  if (i == 4)
+    return true;
+  std::unreachable();
+} // { dg-bogus "control reaches end of non-void function" }
diff --git a/libstdc++-v3/testsuite/20_util/unreachable/version.cc b/libstdc++-v3/testsuite/20_util/unreachable/version.cc
new file mode 100644
index 00000000000..c7795900c30
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/unreachable/version.cc
@@ -0,0 +1,10 @@
+// { dg-options "-std=gnu++23" }
+// { dg-do preprocess { target c++23 } }
+
+#include <version>
+
+#ifndef __cpp_lib_unreachable
+# error "Feature-test macro for unreachable missing in <version>"
+#elif __cpp_lib_unreachable != 202202L
+# error "Feature-test macro for unreachable has wrong value in <version>"
+#endif
  

On Friday, 1 April 2022 13:33:42 CEST Jonathan Wakely wrote:
> Matthias didn't like my Princess Bride easter egg :-)
> Would the attached be better?

LGTM.
  

On Fri, 1 Apr 2022 at 12:56, Matthias Kretz wrote:
>
> On Friday, 1 April 2022 13:33:42 CEST Jonathan Wakely wrote:
> > Matthias didn't like my Princess Bride easter egg :-)
> > Would the attached be better?
>
> LGTM.

OK, thanks to everybody who commented. I've pushed that to trunk now.