public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/100676] New: Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA
@ 2021-05-19 11:13 joachim at joameyer dot de
  2021-05-19 11:57 ` [Bug libstdc++/100676] " redi at gcc dot gnu.org
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: joachim at joameyer dot de @ 2021-05-19 11:13 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100676

            Bug ID: 100676
           Summary: Redeclaring __failed_assertion() at every point of use
                    of __glibcxx_assert breaks Clang CUDA
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: joachim at joameyer dot de
  Target Milestone: ---

As noted in https://bugs.llvm.org/show_bug.cgi?id=50383 the use of
__glibcxx_assert in the complex functions breaks using the complex header with
Clang CUDA. The way Clang CUDA handles that might not be ideal, but the
libstdc++ issue seems to be present anyways:

In every use of __glibcxx_assert the function __failed_assertion is redeclared
and btw. never defined, which might break other projects as well, and then is
used as an assertion in constant evaluated contexts, as it is a non constexpr
function.

I wasn't able to come up with an entirely better approach so far, but I guess
most of the issues, that I could think of so far, would be solved by moving the
void __failed_assertion(); declaration out of the macro.

This would fix the issues with Clang CUDA for example:
https://cuda.godbolt.org/z/GTMnxez7j

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libstdc++/100676] Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA
  2021-05-19 11:13 [Bug libstdc++/100676] New: Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA joachim at joameyer dot de
@ 2021-05-19 11:57 ` redi at gcc dot gnu.org
  2021-05-20 10:10 ` redi at gcc dot gnu.org
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2021-05-19 11:57 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100676

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-05-19
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to J.M. from comment #0)
> In every use of __glibcxx_assert the function __failed_assertion is
> redeclared and btw. never defined,

By design.

> which might break other projects as well,

How?

> and then is used as an assertion in constant evaluated contexts, as it is a
> non constexpr function.

Right, it's only ever used when we want compilation to fail. So it's never
odr-used, so no call to it is ever emitted in the generated assembly, so no
definition is needed.

> I wasn't able to come up with an entirely better approach so far,

Which is why this "awful" construct is used.

> but I
> guess most of the issues, that I could think of so far, would be solved by
> moving the void __failed_assertion(); declaration out of the macro.

The idea was to not pollute the namespace with a declaration of a function that
will never exist.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libstdc++/100676] Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA
  2021-05-19 11:13 [Bug libstdc++/100676] New: Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA joachim at joameyer dot de
  2021-05-19 11:57 ` [Bug libstdc++/100676] " redi at gcc dot gnu.org
@ 2021-05-20 10:10 ` redi at gcc dot gnu.org
  2021-05-20 20:49 ` cvs-commit at gcc dot gnu.org
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2021-05-20 10:10 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100676

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.2

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Using __builtin_unreachable works, and the diagnostic seems acceptable:

In file included from /home/jwakely/gcc/12/include/c++/12.0.0/iosfwd:38,
                 from /home/jwakely/gcc/12/include/c++/12.0.0/string_view:40,
                 from sv.C:1:
sv.C:5:21:   in 'constexpr' expansion of 'f()'
sv.C:3:56:   in 'constexpr' expansion of
's.std::basic_string_view<char>::front()'
/home/jwakely/gcc/12/include/c++/12.0.0/string_view:251:9: error:
'__builtin_unreachable()' is not a constant expression
  251 |         __glibcxx_assert(this->_M_len > 0);
      |         ^~~~~~~~~~~~~~~~

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libstdc++/100676] Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA
  2021-05-19 11:13 [Bug libstdc++/100676] New: Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA joachim at joameyer dot de
  2021-05-19 11:57 ` [Bug libstdc++/100676] " redi at gcc dot gnu.org
  2021-05-20 10:10 ` redi at gcc dot gnu.org
@ 2021-05-20 20:49 ` cvs-commit at gcc dot gnu.org
  2021-06-02 13:43 ` cvs-commit at gcc dot gnu.org
  2021-06-02 13:45 ` redi at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-05-20 20:49 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100676

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:6b42b5a8a207de5e021a2916281f46bcd60b20d2

commit r12-952-g6b42b5a8a207de5e021a2916281f46bcd60b20d2
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu May 20 16:39:06 2021 +0100

    libstdc++: Use __builtin_unreachable for constexpr assertions [PR 100676]

    The current implementation of compile-time precondition checks causes
    compilation to fail by calling a non-constexpr function declared at
    block scope. This breaks the CUDA compiler, which wraps some libstdc++
    headers in a pragma that declares everything as a __host__ __device__
    function, but others are not wrapped and so everything is a __host__
    function. The local declaration thus gets redeclared as two different
    types of function, which doesn't work.

    Just use __builtin_unreachable to make constant evaluation fail, instead
    of the local function declaration. Also simplify the assertion macros,
    which has the side effect of giving simpler compilation errors when
    using Clang.

    libstdc++-v3/ChangeLog:

            PR libstdc++/100676
            * include/bits/c++config (__glibcxx_assert_1): Rename to ...
            (__glibcxx_constexpr_assert): ... this.
            (__glibcxx_assert_impl): Use __glibcxx_constexpr_assert.
            (__glibcxx_assert): Define as either __glibcxx_constexpr_assert
            or __glibcxx_assert_impl.
            (__glibcxx_assert_2): Remove
            * include/debug/macros.h (_GLIBCXX_DEBUG_VERIFY_AT_F): Use
            __glibcxx_constexpr_assert instead of __glibcxx_assert_1.
            *
testsuite/21_strings/basic_string_view/element_access/char/back_constexpr_neg.cc:
            Adjust expected error.
            *
testsuite/21_strings/basic_string_view/element_access/char/constexpr_neg.cc:
            Likewise.
            *
testsuite/21_strings/basic_string_view/element_access/char/front_constexpr_neg.cc:
            Likewise.
            Likewise.
            *
testsuite/21_strings/basic_string_view/element_access/wchar_t/back_constexpr_neg.cc:
            Likewise.
            *
testsuite/21_strings/basic_string_view/element_access/wchar_t/constexpr_neg.cc:
            Likewise.
            *
testsuite/21_strings/basic_string_view/element_access/wchar_t/front_constexpr_neg.cc:
            Likewise.
            * testsuite/23_containers/span/back_neg.cc: Likewise.
            * testsuite/23_containers/span/front_neg.cc: Likewise.
            * testsuite/23_containers/span/index_op_neg.cc: Likewise.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libstdc++/100676] Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA
  2021-05-19 11:13 [Bug libstdc++/100676] New: Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA joachim at joameyer dot de
                   ` (2 preceding siblings ...)
  2021-05-20 20:49 ` cvs-commit at gcc dot gnu.org
@ 2021-06-02 13:43 ` cvs-commit at gcc dot gnu.org
  2021-06-02 13:45 ` redi at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-06-02 13:43 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100676

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:10c58754a862470484eca81623b71e6851470bb6

commit r11-8503-g10c58754a862470484eca81623b71e6851470bb6
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu May 20 16:39:06 2021 +0100

    libstdc++: Use __builtin_unreachable for constexpr assertions [PR 100676]

    The current implementation of compile-time precondition checks causes
    compilation to fail by calling a non-constexpr function declared at
    block scope. This breaks the CUDA compiler, which wraps some libstdc++
    headers in a pragma that declares everything as a __host__ __device__
    function, but others are not wrapped and so everything is a __host__
    function. The local declaration thus gets redeclared as two different
    types of function, which doesn't work.

    Just use __builtin_unreachable to make constant evaluation fail, instead
    of the local function declaration. Also simplify the assertion macros,
    which has the side effect of giving simpler compilation errors when
    using Clang.

    libstdc++-v3/ChangeLog:

            PR libstdc++/100676
            * include/bits/c++config (__glibcxx_assert_1): Rename to ...
            (__glibcxx_constexpr_assert): ... this.
            (__glibcxx_assert_impl): Use __glibcxx_constexpr_assert.
            (__glibcxx_assert): Define as either __glibcxx_constexpr_assert
            or __glibcxx_assert_impl.
            (__glibcxx_assert_2): Remove
            * include/debug/macros.h (_GLIBCXX_DEBUG_VERIFY_AT_F): Use
            __glibcxx_constexpr_assert instead of __glibcxx_assert_1.
            *
testsuite/21_strings/basic_string_view/element_access/char/back_constexpr_neg.cc:
            Adjust expected error.
            *
testsuite/21_strings/basic_string_view/element_access/char/constexpr_neg.cc:
            Likewise.
            *
testsuite/21_strings/basic_string_view/element_access/char/front_constexpr_neg.cc:
            Likewise.
            Likewise.
            *
testsuite/21_strings/basic_string_view/element_access/wchar_t/back_constexpr_neg.cc:
            Likewise.
            *
testsuite/21_strings/basic_string_view/element_access/wchar_t/constexpr_neg.cc:
            Likewise.
            *
testsuite/21_strings/basic_string_view/element_access/wchar_t/front_constexpr_neg.cc:
            Likewise.
            * testsuite/23_containers/span/back_neg.cc: Likewise.
            * testsuite/23_containers/span/front_neg.cc: Likewise.
            * testsuite/23_containers/span/index_op_neg.cc: Likewise.

    (cherry picked from commit 6b42b5a8a207de5e021a2916281f46bcd60b20d2)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libstdc++/100676] Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA
  2021-05-19 11:13 [Bug libstdc++/100676] New: Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA joachim at joameyer dot de
                   ` (3 preceding siblings ...)
  2021-06-02 13:43 ` cvs-commit at gcc dot gnu.org
@ 2021-06-02 13:45 ` redi at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2021-06-02 13:45 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100676

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for 11.2

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-06-02 13:45 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-19 11:13 [Bug libstdc++/100676] New: Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA joachim at joameyer dot de
2021-05-19 11:57 ` [Bug libstdc++/100676] " redi at gcc dot gnu.org
2021-05-20 10:10 ` redi at gcc dot gnu.org
2021-05-20 20:49 ` cvs-commit at gcc dot gnu.org
2021-06-02 13:43 ` cvs-commit at gcc dot gnu.org
2021-06-02 13:45 ` redi at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).