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 indeterminate values. That ends the lifetime of the X (without > calling the destructor). Then you call the destructor on an object that > already ended its lifetime, which is undefined. Then you reuse it as an > array of unsigned char again, and it still has indeterminate values. No, this is wrong. [basic.life] says (I'm using N4741): "The lifetime of an object of type T begins when: — storage with the proper alignment and size for type T is obtained..." A call to memcmp does not "obtain storage" and therefore cannot begin the lifetime of an object. More to the point, this is obviously wrong because the standard permits copying out the bytes of an object (it gives examples using memcpy in [basic.types]), and by your thesis, doing so would end the lifetime of the copied object. > the value representation of the X cannot be inspected > by memcmp, because X is not trivially copyable, and since the values are > indeterminate there is no requirement for the values written by the > destructor to be observable. I suppose. The storage itself can be inspected, though, per [basic.life]: "...after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any pointer that represents the address of the storage location... Indirection through such a pointer is permitted... when the conversion is to ... pointer to cv void and subsequently to pointer to ... cv unsigned char ...". Per [intro.execution], modifying an object is a side effect, and to me it is surprising that a compiler would choose to eliminate the effect of a side effect on storage when that effect would be observable, although I don't see the standard saying anything about how modifying objects affects their storage, so I suppose it may be permitted. As a matter of personal taste, I am extremely against a compiler eliminating code that a programmer has written unless the compiler can prove that the effects cannot be observed. I call this a fetish for optimizationism, a desire to make isolated code snippets faster by disregarding the intent of the programmer.
