https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #17 from AK ---
With recent changes in libc++ (https://reviews.llvm.org/D147741) clang
optimizes away the new-delete pair. https://godbolt.org/z/a6PG54Pvb
$ clang++ -O3 -stdlib=libc++ -fno-exceptions
vat1(std::__1::vector >): #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #16 from Richard Smith
---
(In reply to Richard Biener from comment #15)
> I was specifically looking at C++20 7.6.2.7/10 to /14 (but maybe also
> others and of course the relevant parts of the delete expression). In
> particular
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #15 from Richard Biener ---
(In reply to Richard Smith from comment #14)
> If I understand correctly, you're looking for documentation that
>
> __builtin_operator_new(size)
>
> has the exact same semantics and permits the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #14 from Richard Smith
---
If I understand correctly, you're looking for documentation that
__builtin_operator_new(size)
has the exact same semantics and permits the same optimizations as `::new T`
for a trivially-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
Jonathan Wakely changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #12 from rguenther at suse dot de ---
On Wed, 12 Apr 2023, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
>
> --- Comment #11 from Jonathan Wakely ---
> (In reply to Jonathan Wakely from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #10)
> I would prefer if we don't deviate, and get Clang to clarify things instead
> of reinventing something that looks similar but isn't.
I suppose as long as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #10 from Jonathan Wakely ---
(In reply to Richard Biener from comment #9)
> Yep, looking at that link this is exactly what would be needed. Note
> that in the middle-end we already see the calls to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #9 from Richard Biener ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Jonathan Wakely from comment #7)
> > I think it's valid in theory. I don't know if it's possible for GCC to do it
> > in practice. There doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #8 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #7)
> I think it's valid in theory. I don't know if it's possible for GCC to do it
> in practice. There doesn't seem to be anything the library can do to help,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #7 from Jonathan Wakely ---
(In reply to Richard Biener from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > (In reply to Richard Biener from comment #4)
> > > (In reply to Jonathan Wakely from comment #3)
> > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
Richard Biener changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |libstdc++
--- Comment #4 from Richard
14 matches
Mail list logo
