I'm committing this patch to improve the wording of the -flifetime-dse docs at https://gcc.gnu.org/gcc-6/porting_to.html#flifetime-dse and to add a new paragraph explaining what the problem is and how to fix it. The current text doesn't actually say where the UB is, and talks about a placement new operator, but the example doesn't use placement new.
Committed to CVS. In a later patch I'd also like to simplify the example to remove the build(void) function and just do A* a = new A; in main(), because the build function doesn't seem to serve any purpose. The assertion in the example doesn't fail, so it doesn't demonstrate the problem, and so the attribute((noinline)) is just noise. Am I missing something? I'd also like to replace the GNU coding style with more idiomatic C++. This is meant to be documentation for end-users writing C++, who don't typically put spaces before the argument list of a function, or use (void) for functions with no arguments. Writing (void) is redundant in C++, and even sometimes considered an abomination.
Index: gcc-6/porting_to.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v retrieving revision 1.23 diff -u -r1.23 porting_to.html --- gcc-6/porting_to.html 23 May 2016 14:23:23 -0000 1.23 +++ gcc-6/porting_to.html 15 Aug 2016 17:27:21 -0000 @@ -343,11 +343,11 @@ <h3 id="flifetime-dse">More aggressive optimization of <code>-flifetime-dse</code></h3> <p> -The C++ compiler (with enabled <code>-flifetime-dse</code>) -is more aggressive in dead-store elimination in situations where -a memory store to a location precedes a constructor to the -memory location. Described situation can be commonly found in programs -which zero a memory that is eventually passed to a placement new operator: +The C++ compiler (with <code>-flifetime-dse</code> enabled) +is more aggressive about dead-store elimination in situations where +a memory store to a location precedes the construction of an object at +that memory location. Such situations are commonly found in programs +which zero memory in a custom <code>new</code> operator: </p> <pre><code> @@ -384,6 +384,14 @@ </code></pre> <p> +An object's constructor begins the lifetime of a new object at the relevant +memory location, so any stores to that memory location which happen before +the constructor are considered "dead stores" and so can be optimized away. +If the memory needs to be initialized to specific values then that should be +done by the constructor, not by code that happens before the constructor. +</p> + +<p> If the program cannot be fixed to remove the undefined behavior then the option <code>-flifetime-dse=1</code> can be used to disable this optimization.
