public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/114940] New: std::generator relies on an optional overload of operator delete
@ 2024-05-03 19:39 liuxf19 at 163 dot com
  2024-05-03 19:56 ` [Bug libstdc++/114940] " liuxf19 at 163 dot com
                   ` (12 more replies)
  0 siblings, 13 replies; 14+ messages in thread
From: liuxf19 at 163 dot com @ 2024-05-03 19:39 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 114940
           Summary: std::generator relies on an optional overload of
                    operator delete
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: liuxf19 at 163 dot com
  Target Milestone: ---

The bug report #114891 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891
discussed the impact of is_pointer_interconvertible_base_of_v on using
std::generator with clang++ and libstdc++. There's another issue when
std::generator in libstdc++ is used by other compilers such as clang++.

In the header <generator>, an overload of operator delete:
void operator delete  ( void* ptr, std::size_t sz ) noexcept;

However, this is an OPTIONAL feature whose feature test macro is
__cpp_sized_deallocation macro. Some compilers especially clang++, even the
newest  clang trunk (which is avaiable at https://godbolt.org, and the version
is 19.0.0) didn't implement this macro. For example, the code below:

#include <new>

int main() {
#ifndef __cpp_sized_deallocation
    static_assert(false, "no __cpp_sized_deallocation");
#endif
}

compiled with: clang++ -std=c++23 -stdlib=libstdc++
will cause the following errors:

<source>:5:19: error: static assertion failed: no __cpp_sized_deallocation
    5 |     static_assert(false, "no __cpp_sized_deallocation");
      |                   ^~~~~
1 error generated.
ASM generation compiler returned: 1
<source>:5:19: error: static assertion failed: no __cpp_sized_deallocation
    5 |     static_assert(false, "no __cpp_sized_deallocation");
      |                   ^~~~~
1 error generated.

See https://gcc.godbolt.org/z/MocWxMKz6 for details.

And thus there's no this overload with clang++.
But the std::generator in libstdc++ relies on this overload, which also causes
clang++ cannot use std::generator in libstdc++ (even after clang++ 19 provided
is_pointer_interconvertible_base_of discussed in #114891).

The following code:

#include <new>
#include <generator>

std::generator<int> iota(int n) {
    for (int i = 0; i < n; ++i) {
        co_yield i;
    }
}

int main() {
    for (auto i : iota(10)) {
    }
    return 0;
}

compiled with: clang++ -std=c++23 -stdlib=libstdc++
And the compilation errors:

In file included from main.cpp:16:
/usr/bin/../lib/gcc/x86_64-linux-gnu/14/../../../../include/c++/14/generator:606:6:
error: no matching function for call to 'operator delete'
  606 |             ::operator delete(__ptr, _M_alloc_size<void>(__sz));
      |             ^~~~~~~~~~~~~~~~~


See https://gcc.godbolt.org/z/xjMGaq36a for details.

Note that there's no restrictions that std::generator must depends on this
overload of operator delete in ISO C++. This may cause clang++ or other
compilers cannot use std::generator in libstdc++.

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

* [Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
  2024-05-03 19:39 [Bug libstdc++/114940] New: std::generator relies on an optional overload of operator delete liuxf19 at 163 dot com
@ 2024-05-03 19:56 ` liuxf19 at 163 dot com
  2024-05-03 19:57 ` redi at gcc dot gnu.org
                   ` (11 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: liuxf19 at 163 dot com @ 2024-05-03 19:56 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from Timothy Liu Xuefeng <liuxf19 at 163 dot com> ---
It seems that passing -fsized-deallocation to clang++ can resolve this problem.
But it seems that it's not the default behavior.

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

* [Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
  2024-05-03 19:39 [Bug libstdc++/114940] New: std::generator relies on an optional overload of operator delete liuxf19 at 163 dot com
  2024-05-03 19:56 ` [Bug libstdc++/114940] " liuxf19 at 163 dot com
@ 2024-05-03 19:57 ` redi at gcc dot gnu.org
  2024-05-03 19:57 ` redi at gcc dot gnu.org
                   ` (10 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2024-05-03 19:57 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-05-03
                 CC|                            |arsen at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It's not optional, it's a required feature in C++14 and later. Failing to
provide it is non-conforming, although GCC can be requested to be
non-conforming the same way with -fno-sized-deallocation. Using that, the same
error happens with GCC.

We should either disable __cpp_lib_generator when __cpp_sized_deallocation is
not defined, or change <generator> to not depend on it unconditionally.

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

* [Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
  2024-05-03 19:39 [Bug libstdc++/114940] New: std::generator relies on an optional overload of operator delete liuxf19 at 163 dot com
  2024-05-03 19:56 ` [Bug libstdc++/114940] " liuxf19 at 163 dot com
  2024-05-03 19:57 ` redi at gcc dot gnu.org
@ 2024-05-03 19:57 ` redi at gcc dot gnu.org
  2024-05-03 20:08 ` liuxf19 at 163 dot com
                   ` (9 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2024-05-03 19:57 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
P.S. what's optional is whether the compiler chooses to use that overload or
not. But its presence is required for conformance.

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

* [Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
  2024-05-03 19:39 [Bug libstdc++/114940] New: std::generator relies on an optional overload of operator delete liuxf19 at 163 dot com
                   ` (2 preceding siblings ...)
  2024-05-03 19:57 ` redi at gcc dot gnu.org
@ 2024-05-03 20:08 ` liuxf19 at 163 dot com
  2024-05-04  8:47 ` arsen at gcc dot gnu.org
                   ` (8 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: liuxf19 at 163 dot com @ 2024-05-03 20:08 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Timothy Liu Xuefeng <liuxf19 at 163 dot com> ---
(In reply to Jonathan Wakely from comment #2)
> It's not optional, it's a required feature in C++14 and later. Failing to
> provide it is non-conforming, although GCC can be requested to be
> non-conforming the same way with -fno-sized-deallocation. Using that, the
> same error happens with GCC.
> 
> We should either disable __cpp_lib_generator when __cpp_sized_deallocation
> is not defined, or change <generator> to not depend on it unconditionally.

Yeah, I agree. Since -fsized-deallocation is not the default behavior of
clang++, reporting errors in <generator> seems strange.

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

* [Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
  2024-05-03 19:39 [Bug libstdc++/114940] New: std::generator relies on an optional overload of operator delete liuxf19 at 163 dot com
                   ` (3 preceding siblings ...)
  2024-05-03 20:08 ` liuxf19 at 163 dot com
@ 2024-05-04  8:47 ` arsen at gcc dot gnu.org
  2024-05-04 11:02 ` redi at gcc dot gnu.org
                   ` (7 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: arsen at gcc dot gnu.org @ 2024-05-04  8:47 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
imo, creating a divergent code path for this case isn't worth it, especially
for something that isn't trivial.  I'd opt for checking for sized dealloc in
version.def.

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

* [Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
  2024-05-03 19:39 [Bug libstdc++/114940] New: std::generator relies on an optional overload of operator delete liuxf19 at 163 dot com
                   ` (4 preceding siblings ...)
  2024-05-04  8:47 ` arsen at gcc dot gnu.org
@ 2024-05-04 11:02 ` redi at gcc dot gnu.org
  2024-05-04 12:10 ` arsen at gcc dot gnu.org
                   ` (6 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2024-05-04 11:02 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
What would be needed to work without it? It looks like the allocation would
have to be larger so the size could be stored as a cookie at the start of the
allocated block?

Tangentially, could _M_alloc_size use __ba - 1 instead of __ba?

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

* [Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
  2024-05-03 19:39 [Bug libstdc++/114940] New: std::generator relies on an optional overload of operator delete liuxf19 at 163 dot com
                   ` (5 preceding siblings ...)
  2024-05-04 11:02 ` redi at gcc dot gnu.org
@ 2024-05-04 12:10 ` arsen at gcc dot gnu.org
  2024-05-22  9:30 ` redi at gcc dot gnu.org
                   ` (5 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: arsen at gcc dot gnu.org @ 2024-05-04 12:10 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #6)
> What would be needed to work without it? It looks like the allocation would
> have to be larger so the size could be stored as a cookie at the start of
> the allocated block?
> 
> Tangentially, could _M_alloc_size use __ba - 1 instead of __ba?

would it even require that?  AIUI, that flag only affects global sized dealloc
functions, so it'd only require changing the ::operator new/delete dealloc fn
in the _Promise_alloc<void> case.  but, clang appears to intend to flip the
default soon: https://github.com/llvm/llvm-project/pull/90373 so I'm not sure
it's worth it anyway

re _M_alloc_size, do you mean _Promise_alloc<void> case or the non-void one? 
in the void case, I think so (but haven't ensured it by doing the math on paper
yet; reasoning through it, it seems fine).

in the non-void case, it might even be possible to do -2 (same disclaimer goes)

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

* [Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
  2024-05-03 19:39 [Bug libstdc++/114940] New: std::generator relies on an optional overload of operator delete liuxf19 at 163 dot com
                   ` (6 preceding siblings ...)
  2024-05-04 12:10 ` arsen at gcc dot gnu.org
@ 2024-05-22  9:30 ` redi at gcc dot gnu.org
  2024-05-22  9:37 ` redi at gcc dot gnu.org
                   ` (4 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2024-05-22  9:30 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
We have the same problem in <stacktrace>

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

* [Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
  2024-05-03 19:39 [Bug libstdc++/114940] New: std::generator relies on an optional overload of operator delete liuxf19 at 163 dot com
                   ` (7 preceding siblings ...)
  2024-05-22  9:30 ` redi at gcc dot gnu.org
@ 2024-05-22  9:37 ` redi at gcc dot gnu.org
  2024-05-22 22:30 ` cvs-commit at gcc dot gnu.org
                   ` (3 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2024-05-22  9:37 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.4
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

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

* [Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
  2024-05-03 19:39 [Bug libstdc++/114940] New: std::generator relies on an optional overload of operator delete liuxf19 at 163 dot com
                   ` (8 preceding siblings ...)
  2024-05-22  9:37 ` redi at gcc dot gnu.org
@ 2024-05-22 22:30 ` cvs-commit at gcc dot gnu.org
  2024-05-28  9:20 ` cvs-commit at gcc dot gnu.org
                   ` (2 subsequent siblings)
  12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-05-22 22:30 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #9 from GCC 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:b2fdd508d7e63158e9d2a6dd04f901d02900def3

commit r15-780-gb2fdd508d7e63158e9d2a6dd04f901d02900def3
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed May 22 10:32:43 2024 +0100

    libstdc++: Guard use of sized deallocation [PR114940]

    Clang does not enable -fsized-deallocation by default, which means it
    can't compile our <stacktrace> and <generator> headers.

    Make the __cpp_lib_generator macro depend on the compiler-defined
    __cpp_sized_deallocation macro, and change <stacktrace> to use unsized
    deallocation when __cpp_sized_deallocation isn't defined.

    libstdc++-v3/ChangeLog:

            PR libstdc++/114940
            * include/bits/version.def (generator): Depend on
            __cpp_sized_deallocation.
            * include/bits/version.h: Regenerate.
            * include/std/stacktrace (_GLIBCXX_SIZED_DELETE): New macro.
            (basic_stacktrace::_Impl::_M_deallocate): Use it.

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

* [Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
  2024-05-03 19:39 [Bug libstdc++/114940] New: std::generator relies on an optional overload of operator delete liuxf19 at 163 dot com
                   ` (9 preceding siblings ...)
  2024-05-22 22:30 ` cvs-commit at gcc dot gnu.org
@ 2024-05-28  9:20 ` cvs-commit at gcc dot gnu.org
  2024-05-28 11:08 ` cvs-commit at gcc dot gnu.org
  2024-05-28 11:09 ` redi at gcc dot gnu.org
  12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-05-28  9:20 UTC (permalink / raw)
  To: gcc-bugs

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

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

https://gcc.gnu.org/g:89dff1488ef3fde11f6451e5f9817e14bcd6a873

commit r14-10250-g89dff1488ef3fde11f6451e5f9817e14bcd6a873
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed May 22 10:32:43 2024 +0100

    libstdc++: Guard use of sized deallocation [PR114940]

    Clang does not enable -fsized-deallocation by default, which means it
    can't compile our <stacktrace> and <generator> headers.

    Make the __cpp_lib_generator macro depend on the compiler-defined
    __cpp_sized_deallocation macro, and change <stacktrace> to use unsized
    deallocation when __cpp_sized_deallocation isn't defined.

    libstdc++-v3/ChangeLog:

            PR libstdc++/114940
            * include/bits/version.def (generator): Depend on
            __cpp_sized_deallocation.
            * include/bits/version.h: Regenerate.
            * include/std/stacktrace (_GLIBCXX_SIZED_DELETE): New macro.
            (basic_stacktrace::_Impl::_M_deallocate): Use it.

    (cherry picked from commit b2fdd508d7e63158e9d2a6dd04f901d02900def3)

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

* [Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
  2024-05-03 19:39 [Bug libstdc++/114940] New: std::generator relies on an optional overload of operator delete liuxf19 at 163 dot com
                   ` (10 preceding siblings ...)
  2024-05-28  9:20 ` cvs-commit at gcc dot gnu.org
@ 2024-05-28 11:08 ` cvs-commit at gcc dot gnu.org
  2024-05-28 11:09 ` redi at gcc dot gnu.org
  12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-05-28 11:08 UTC (permalink / raw)
  To: gcc-bugs

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

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

https://gcc.gnu.org/g:67434fec24bef0faeec0eb402f82ca7e43a4a112

commit r13-8804-g67434fec24bef0faeec0eb402f82ca7e43a4a112
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Wed May 22 10:32:43 2024 +0100

    libstdc++: Guard use of sized deallocation [PR114940]

    Clang does not enable -fsized-deallocation by default, which means it
    can't compile our <stacktrace> header.

    Make the __cpp_lib_generator macro depend on the compiler-defined
    __cpp_sized_deallocation macro, and change <stacktrace> to use unsized
    deallocation when __cpp_sized_deallocation isn't defined.

    libstdc++-v3/ChangeLog:

            PR libstdc++/114940
            * include/std/stacktrace (_GLIBCXX_SIZED_DELETE): New macro.
            (basic_stacktrace::_Impl::_M_deallocate): Use it.

    (cherry picked from commit b2fdd508d7e63158e9d2a6dd04f901d02900def3)

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

* [Bug libstdc++/114940] std::generator relies on an optional overload of operator delete
  2024-05-03 19:39 [Bug libstdc++/114940] New: std::generator relies on an optional overload of operator delete liuxf19 at 163 dot com
                   ` (11 preceding siblings ...)
  2024-05-28 11:08 ` cvs-commit at gcc dot gnu.org
@ 2024-05-28 11:09 ` redi at gcc dot gnu.org
  12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2024-05-28 11:09 UTC (permalink / raw)
  To: gcc-bugs

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

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

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

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for 13.4 and 14.2

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

end of thread, other threads:[~2024-05-28 11:09 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-05-03 19:39 [Bug libstdc++/114940] New: std::generator relies on an optional overload of operator delete liuxf19 at 163 dot com
2024-05-03 19:56 ` [Bug libstdc++/114940] " liuxf19 at 163 dot com
2024-05-03 19:57 ` redi at gcc dot gnu.org
2024-05-03 19:57 ` redi at gcc dot gnu.org
2024-05-03 20:08 ` liuxf19 at 163 dot com
2024-05-04  8:47 ` arsen at gcc dot gnu.org
2024-05-04 11:02 ` redi at gcc dot gnu.org
2024-05-04 12:10 ` arsen at gcc dot gnu.org
2024-05-22  9:30 ` redi at gcc dot gnu.org
2024-05-22  9:37 ` redi at gcc dot gnu.org
2024-05-22 22:30 ` cvs-commit at gcc dot gnu.org
2024-05-28  9:20 ` cvs-commit at gcc dot gnu.org
2024-05-28 11:08 ` cvs-commit at gcc dot gnu.org
2024-05-28 11:09 ` 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).