This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Missed optimization with const member


On 07/05/2017 01:26 PM, Geza Herman wrote:
On 07/05/2017 01:14 PM, Jonathan Wakely wrote:
I think the reason it's not optimized away is for this case:

void somefunction(const Object& object);
{
   void* p = &object;
   object.~Object();
   new(p) Object();
}

This means that after calling someFunction there could be a different
object at the same location (with a possibly different value for that
member).

https://stackoverflow.com/questions/39382501/what-is-the-purpose-of-stdlaunder

I don't know whether the anwser at stackoverflow is right, but: the compiler can assume that m_initType doesn't change, if I don't launder it. (in this case, though, I don't know how would I tell the compiler that it must call the destructor "laundered".)

Have a look at this doc: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0532r0.pdf

It explitly says that after "new(p) Object();", it is UB to access object (even the mutable members!) via p. If you want to access it, you have to use the pointer which "new" returned. Or, std::launder must be used (c++17 proposal).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]