https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #23 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #14)
> So something like this, and then use it in containers instead of
> _Alloc_traits::destroy
>
> template
> _GLIBCXX20_CONSTEXPR
> void
> _Dest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #22 from GCC Commits ---
The master branch has been updated by Sam James :
https://gcc.gnu.org/g:21fc6d35f27cdf4c56e9f093894f6728c55ecb0e
commit r15-2440-g21fc6d35f27cdf4c56e9f093894f6728c55ecb0e
Author: Sam James
Date: Tue Jul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #21 from Jonathan Wakely ---
Yes, I think that's valid, so shouldn't be devirtualized.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #20 from user202729 ---
(In reply to Jonathan Wakely from comment #19)
> That's easily solved by accessing the new object through the pointer
> returned by the new expression:
>
> std::vector v(1);
> Base* p = v.data();
> p->~Base()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #19 from Jonathan Wakely ---
(In reply to user202729 from comment #18)
> (In reply to Jonathan Wakely from comment #17)
> The clause seems to apply just as well, you cannot access the newly
> constructed `Derived` object through `p`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #18 from user202729 ---
(In reply to Jonathan Wakely from comment #17)
> I don't think that optimization would be valid. Users could do disgusting
> things like this (as long as sizeof(Base) == sizeof(Derived)):
>
> std::vector v(1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #17 from Jonathan Wakely ---
(In reply to user202729 from comment #16)
> That sound like a good idea, thanks. I thought about this some time earlier
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115413#c3) but I did not know
> how
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #16 from user202729 ---
(In reply to Jonathan Wakely from comment #14)
> So something like this, and then use it in containers instead of
> _Alloc_traits::destroy
>
> template
> _GLIBCXX20_CONSTEXPR
> void
> _Destroy_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #15 from Jason Merrill ---
(In reply to Jonathan Wakely from comment #14)
LGTM.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #14 from Jonathan Wakely ---
So something like this, and then use it in containers instead of
_Alloc_traits::destroy
template
_GLIBCXX20_CONSTEXPR
void
_Destroy_static_type(_Tp* __p, _Allocator& __alloc)
{
#if __cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #13 from Jonathan Wakely ---
That would only be valid for std::allocator and other allocators where
std::allocator_traits::destroy uses std::destroy_at.
As it happens, I've just refactored std::allocator_traits today, which makes it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
user202729 changed:
What|Removed |Added
CC||user202729 at protonmail dot
com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #10 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:a47e615fbf9c6f4b24e5032df5d720b6bf9b63b5
commit r14-2853-ga47e615fbf9c6f4b24e5032df5d720b6bf9b63b5
Author: Ng YongXiang
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #9 from Ng YongXiang ---
Would anyone be willing to provide some feedback regarding the attachment
(https://gcc.gnu.org/bugzilla/attachment.cgi?id=55256&action=diff) that I have
created? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #8 from Ng YongXiang ---
Just added a patch to illustrate the array destruction issue. What do you
think?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
Ng YongXiang changed:
What|Removed |Added
CC||yongxiangng at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #6 from Ng YongXiang ---
That is interesting. Thanks for the reply.
However, I'd argue that the 2 bugs mentioned are different from what I am
proposing. The 2 bugs linked access virtual functions via ptr (delete p;
val->f();) and ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #4 from Ng YongXiang ---
Would anyone be able to direct me to which portion of the code is responsible
for this threshold between len 2 & 3 array? Is this the responsibility of the
c++ frontend? or is it still related to the optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #3 from Ng YongXiang ---
I'm giving the example of an array for now, because gcc treatment of the
destructor is inconsistent and depends on the length of the array. Clang on the
other hand is able to devirtualize the destructor in th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #2 from Andrew Pinski ---
I am not 100% sure the all of the objects in the vector has to be in type of
C. Because you could do some tricks dealing with inplacement new.
>if this applies to raw arrays
It does applies to raw arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #1 from Andrew Pinski ---
I don't think it should be checking ssa dump (which is the output right after
going into ssa mode) but rather optimized.
24 matches
Mail list logo
