[wwwdocs] Describe behavior of -flifetime-dse in class constructors

Hello.

As I finally hunted issue in Firefox that was responsible for start-up segfault, I would like
to describe a new behavior of the compiler that emits clobbers to class constructors (w/ -flifetime-dse).
As also Richi spotted quite similar issue in openjade package, I think it worth for mentioning in porting:

Ok?
Thanks,
Martin

On 16/02/16 14:55, Martin Liška wrote:
> Hello.
>
> As I finally hunted issue in Firefox that was responsible for start-up segfault, I would like
> to describe a new behavior of the compiler that emits clobbers to class constructors (w/ -flifetime-dse).
> As also Richi spotted quite similar issue in openjade package, I think it worth for mentioning in porting:
>
> Ok?
> Thanks,
> Martin

  <p>
-Finally, the type and mangling of flexible array members has changed
+Furthermore, the type and mangling of flexible array members has changed
  from previous releases.  While in GCC 5 and prior the type of a flexible
  array member is an array of zero elements (a GCC extension), in GCC 6 it
  is that of an array of an unspecified bound (i.e., <tt>T[]</tt> as opposed
@@ -324,6 +324,50 @@
  <tt>-fabi-version</tt> or <tt>-Wabi</tt> option to disable or warn about.
  </p>
  
+<p>
+Finally, the C++ compiler (with enabled <code>-flifetime-dse</code>)
+has been 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:

Minor nit, but I notice we have a different "Finally" point now ;).
Perhaps we shouldn't bother saying "finally" as we keep finding new entries for this list.

Thanks,
Kyrill

On 02/16/2016 07:55 AM, Martin Liška wrote:
> Hello.
>
> As I finally hunted issue in Firefox that was responsible for start-up segfault, I would like
> to describe a new behavior of the compiler that emits clobbers to class constructors (w/ -flifetime-dse).
> As also Richi spotted quite similar issue in openjade package, I think it worth for mentioning in porting:

I think the new text deserves a new heading of its own rather than
being added under the existing "Stricter flexible array member rules."
(The "Finally..." part changed by the patch still applies to the
flexible array members.)

Martin

> Hello.
> 
> As I finally hunted issue in Firefox that was responsible for start-up segfault, I would like
> to describe a new behavior of the compiler that emits clobbers to class constructors (w/ -flifetime-dse).
> As also Richi spotted quite similar issue in openjade package, I think it worth for mentioning in porting:

Hi,
thank you for working this out and writting summary. I think in a shorter form this would make
excellent entry for changes.html, too.  We tell about the new feature and warn users about fallout
that is always good.

Honza
> 
> Ok?
> Thanks,
> Martin

> Index: htdocs/gcc-6/porting_to.html
> ===================================================================
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
> retrieving revision 1.14
> diff --unified -r1.14 porting_to.html
> --- htdocs/gcc-6/porting_to.html	14 Feb 2016 13:13:43 -0000	1.14
> +++ htdocs/gcc-6/porting_to.html	16 Feb 2016 14:41:10 -0000
> @@ -316,7 +316,7 @@
>  </code></pre>
>  
>  <p>
> -Finally, the type and mangling of flexible array members has changed
> +Furthermore, the type and mangling of flexible array members has changed
>  from previous releases.  While in GCC 5 and prior the type of a flexible
>  array member is an array of zero elements (a GCC extension), in GCC 6 it
>  is that of an array of an unspecified bound (i.e., <tt>T[]</tt> as opposed
> @@ -324,6 +324,50 @@
>  <tt>-fabi-version</tt> or <tt>-Wabi</tt> option to disable or warn about.
>  </p>
>  
> +<p>
> +Finally, the C++ compiler (with enabled <code>-flifetime-dse</code>)
> +has been 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:
> +
> +<pre><code>
> +#include &lt;stdlib.h&gt;
> +#include &lt;string.h&gt;
> +#include &lt;assert.h&gt;
> +
> +struct A
> +{
> +  A () {}
> +  void *operator new (size_t s)
> +  {
> +    void *ptr = malloc (s);
> +    memset (ptr, 0, s);
> +    return ptr;
> +  }
> +
> +  int value;
> +};
> +
> +A *
> +__attribute__ ((noinline))
> +build (void)
> +{
> +  return new A ();
> +}
> +
> +int main()
> +{
> +  A *a =  build ();
> +  assert (a-&gt;value == 0); /* Use of uninitialized value */
> +  free (a);
> +}
> +</code></pre>
> +
> +If the program cannot be fixed to remove the undefined behavior then
> +the option <code>-fno-lifetime-dse</code> can be used to disable
> +this optimization.
> +
>  <h2>-Wmisleading-indentation</h2>
>  <p>
>  A new warning <code>-Wmisleading-indentation</code> was added