https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112480
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112480
--- Comment #10 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:866870c51d58881819db6db76dcdfe3f43d89903
commit r13-8132-g866870c51d58881819db6db76dcdfe3f43d89903
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112480
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:2c492f99fc1fcb5f598286c3f3a21a05bca69d9e
commit r14-5421-g2c492f99fc1fcb5f598286c3f3a21a05bca69d9e
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112480
--- Comment #8 from Jonathan Wakely ---
Good point, it looks like we get the same codegen improvement for ~T(){} even
at -O1 if we don't restrict it to trivially destructible types.
There seems to be no difference in codegen for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112480
--- Comment #7 from Ivan Sorokin ---
(In reply to Jonathan Wakely from comment #6)
> + // The following seems redundant but improves codegen, see PR 112480.
> + if constexpr (is_trivially_destructible_v<_Tp>)
> +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112480
--- Comment #6 from Jonathan Wakely ---
I think I prefer:
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -311,6 +311,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
if (this->_M_engaged)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112480
Ivan Sorokin changed:
What|Removed |Added
CC||vanyacpp at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112480
--- Comment #4 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #3)
> I think that is because that transformation would violate the memory model
> of C++.
Ah yes. It would be safe for another thread to read the same memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112480
--- Comment #3 from Andrew Pinski ---
(In reply to Corey Kosak from comment #2)
> Thanks for the reply and the correction about illegally running the
> destructor.
>
> As for why the compiler can't do the optimization itself, I don't know, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112480
--- Comment #2 from Corey Kosak ---
Thanks for the reply and the correction about illegally running the destructor.
As for why the compiler can't do the optimization itself, I don't know, but the
optimization isn't applied here either:
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112480
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-11-10
11 matches
Mail list logo
