diff mbox

[wwwdocs] Improve example at https://gcc.gnu.org/gcc-6/porting_to.html#flifetime-dse

Message ID 20160815173145.GF13084@redhat.com
State New
Headers show

Commit Message

Jonathan Wakely Aug. 15, 2016, 5:31 p.m. UTC 
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.

Comments

Jonathan Wakely Aug. 15, 2016, 5:43 p.m. UTC | #1 
On 15/08/16 18:31 +0100, Jonathan Wakely wrote:
>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.

I think this would be an improvement, although I still can't get the
assertion to fail:

#include <stdlib.h>
#include <string.h>
#include <assert.h>

struct A
{
  A() {}

  void* operator new(size_t s)
  {
    void* ptr = malloc(s);
    memset(ptr, 0, s);
    return ptr;
  }

  void operator delete(void* ptr) { free(ptr); }

  int value;
};

int main()
{
  A* a =  new A;
  assert(a->value == 0); /* Use of uninitialized value */
  delete a;
}
diff mbox

Patch

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.