https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #18 from Jason Merrill ---
Author: jason
Date: Mon Apr 30 15:21:01 2018
New Revision: 259772
URL: https://gcc.gnu.org/viewcvs?rev=259772&root=gcc&view=rev
Log:
PR c++/61982 - dead stores to destroyed objects.
gcc/cp/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #17 from Jakub Jelinek ---
And, GCC offers the -fno-lifetime-dse option which will not eliminate the
stores:
-fno-lifetime-dse
In C++ the value of an object is only affected by changes within its lifetime:
when the constructor begins,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #16 from Avi Kivity ---
Sorry, of course the stores are not illegal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #15 from Jakub Jelinek ---
The stores aren't illegal, just can't be observed in a valid program, because
after the destruction the bits have indeterminate values.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #14 from Avi Kivity ---
This is a common missed optimization. A container is cleared as part of
destruction, but the stores are not eliminated, even though they are illegal.
If you want to access members of an object, don't destroy i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #13 from hyrosen at mail dot com ---
(In reply to Jonathan Wakely from comment #12)
> The C++ standard. Specifically, [basic.life].
>
> So the first memcmp call reuses the storage to create an array of unsigned
> char with indetermina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #12 from Jonathan Wakely ---
The C++ standard. Specifically, [basic.life].
After the constructor runs and before the destructor runs, that memory location
contains an object of type X. After the destructor finishes you can reuse the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #11 from hyrosen at mail dot com ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to hyrosen from comment #9)
> > The storage for an object can still be accessible after the object is
> > destroyed. Therefore, writes in th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #10 from Jakub Jelinek ---
(In reply to hyrosen from comment #9)
> The storage for an object can still be accessible after the object is
> destroyed. Therefore, writes in the destructor should not be eliminated
> unless they are prov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
hyrosen at mail dot com changed:
What|Removed |Added
CC||hyrosen at mail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #8 from Avi Kivity ---
Still unfixed in trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #7 from Jakub Jelinek ---
(In reply to Daniel Krügler from comment #6)
> (In reply to Avi Kivity from comment #5)
> > Ah, I see that non-trivial destructors were fixed in gcc 4.9.
>
> I'm not sure whether I can agree with "fixed" her
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #6 from Daniel Krügler ---
(In reply to Avi Kivity from comment #5)
> Ah, I see that non-trivial destructors were fixed in gcc 4.9.
I'm not sure whether I can agree with "fixed" here. A related (yet unresolved)
core-language issue is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #5 from Avi Kivity ---
Ah, I see that non-trivial destructors were fixed in gcc 4.9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #4 from Marc Glisse ---
(In reply to Avi Kivity from comment #3)
> I observed this with non-trivial destructors as well.
>
> In fact, something like:
>
> X::~X() { i = 3; }
>
> also emits a store.
Not for me, at least at -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #3 from Avi Kivity ---
I observed this with non-trivial destructors as well.
In fact, something like:
X::~X() { i = 3; }
also emits a store.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #2 from Jakub Jelinek ---
The CLOBBER for non-decl expressions is added in the destructors, here we have
trivial destructor, so it is "inlined" already by the frontend and thus not
emitted. Perhaps we could emit it in the places wher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
20 matches
Mail list logo
