public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
@ 2017-01-27 16:35 Jakub Jelinek
  2017-01-27 16:36 ` Kyrill Tkachov
                   ` (2 more replies)
  0 siblings, 3 replies; 20+ messages in thread
From: Jakub Jelinek @ 2017-01-27 16:35 UTC (permalink / raw)
  To: gcc-patches
  Cc: Richard Biener, Uros Bizjak, Andrew Senkevich, Segher Boessenkool

Hi!

This patch attempts to document some new features (without warnings,
those are partially covered by Marek's patch, C++ FE (would be nice
to document -faligned-new, -fnew-inheriting-ctors, -fnew-ttp-matching,
-fstrong-eval-order and what from C++ is supported) and the BRIG FE).

Ok for wwwdocs?

Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.44
diff -u -p -r1.44 changes.html
--- changes.html	27 Jan 2017 09:54:32 -0000	1.44
+++ changes.html	27 Jan 2017 16:23:03 -0000
@@ -45,8 +45,39 @@ a work-in-progress.</h2>
   <li>A new store merging pass has been added.  It merges constant stores to
   adjacent memory locations into fewer, wider, stores.
   It can be enabled by using the <code>-fstore-merging</code> option and is
-  enabled by default at <code>-Os</code> and the <code>-O2</code> optimization
-  level or higher.</li>
+  enabled by default at the <code>-O2</code> optimization
+  level or higher (including <code>-Os</code>).</li>
+
+  <li>A new code hoisting optimization has been added to the partial
+  redundancy elimination pass.  It attempts to move evaluation of
+  expressions executed on all paths to the function exit as early as
+  possible, which helps primarily for code size, but can be useful for
+  speed of generated code as well.  It can be enabled by using the
+  <code>-fcode-hoisting</code> option and is enabled by default at
+  the <code>-O2</code> optimization level or higher.</li>
+
+  <li>A new interprocedural bitwise constant propagation optimization
+  has been added, which propagates knowledge about which bits of variables
+  are known to be zero (including pointer alignment information) across
+  the call graph.  It can be enabled by using the <code>-fipa-bit-cp</code>
+  option if <code>-fipa-cp</code> is enabled as well, and is enabled by
+  default at the <code>-O2</code> optimization level and higher.</li>
+
+  <li>A new interprocedural value range propagation optimization has been
+  added, which propagates integral ranges that variable values can be proven
+  to be within across the call graph.  It can be enabled by using the
+  <code>-fipa-vrp</code> option and is enabled by default at the
+  <code>-O2</code> optimization level and higher.</li>
+
+  <li>A new loop splitting optimization pass has been added.  It splits
+  certain loops if they contain a condition that is always true on one
+  side of the iteration space and always false on the other into two
+  loops where each of the new two loops iterates just on one of the sides
+  of the iteration space and the condition does not need to be checked
+  inside of the loop.  It can be enabled by using the
+  <code>-fsplit-loops</code> option and is enabled by default at the
+  <code>-O3</code> optimization level or higher.</li>
+
   <li>AddressSanitizer gained a new sanitization option, <code>-fsanitize-address-use-after-scope</code>,
       which enables sanitization of variables whose address is taken and used after a scope where the
       variable is defined:
@@ -64,17 +95,17 @@ main (int argc, char **argv)
   return *ptr;
 }
 
-==28882==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffb8dba990 at pc 0x0000004006d5 bp 0x7fffb8dba960 sp 0x7fffb8dba958
-WRITE of size 1 at 0x7fffb8dba990 thread T0
+<span class="boldred">==28882==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffb8dba990 at pc 0x0000004006d5 bp 0x7fffb8dba960 sp 0x7fffb8dba958</span>
+<span class="boldblue">WRITE of size 1 at 0x7fffb8dba990 thread T0</span>
     #0 0x4006d4 in main /tmp/use-after-scope-1.c:10
     #1 0x7f9c71943290 in __libc_start_main (/lib64/libc.so.6+0x20290)
     #2 0x400739 in _start (/tmp/a.out+0x400739)
 
-Address 0x7fffb8dba990 is located in stack of thread T0 at offset 32 in frame
+<span class="boldlime">Address 0x7fffb8dba990 is located in stack of thread T0 at offset 32 in frame</span>
     #0 0x40067f in main /tmp/use-after-scope-1.c:3
 
   This frame has 1 object(s):
-    [32, 33) 'my_char' &lt;== Memory access at offset 32 is inside this variable
+    [32, 33) 'my_char' <span class="boldlime">&lt;== Memory access at offset 32 is inside this variable</span>
   </pre></blockquote>
 
   The option is enabled by default with <code>-fsanitize=address</code> and disabled
@@ -92,6 +123,16 @@ Address 0x7fffb8dba990 is located in sta
 
   </li>
 
+  <li>The <code>-fsanitize=signed-integer-overflow</code> suboption of the
+  UndefinedBehavior Sanitizer now diagnose arithmetic overflows even on
+  arithmetic operations with generic vectors.</li>
+
+  <li>The upcoming version 5 of the <a
+  href="http://www.dwarfstd.org/Download.php">DWARF</a> debugging
+  information standard is supported through the <code>-gdwarf-5</code>
+  option.  The DWARF version 4 debugging information remains the
+  default until debugging information consumers are adjusted.</li>
+
 </ul>
 
 <!-- .................................................................. -->
@@ -255,6 +296,14 @@ of the global declaration:</p>
   currently has the value of <code>UINTMAX_MAX</code> on all systems,
   reflecting that GCC's compile-time conversions are correctly rounded
   for any number of digits.</li>
+<li>New <code>__builtin_add_overflow_p</code>,
+  <code>__builtin_sub_overflow_p</code>,
+  <code>__builtin_mul_overflow_p</code> built-in functions have been added.
+  These work similarly to earlier added built-in functions without the
+  <code>_p</code> suffix, but don't actually store the result of the
+  arithmetics anywhere, just return whether the operation would overflow.
+  These builtins allow easy checking for overflows e.g. in C++
+  <code>constexpr</code> contexts.</li>
 </ul>
 
 <h3 id="c">C</h3>
@@ -291,6 +340,8 @@ of the global declaration:</p>
   (suffixed <code>f<i>N</i></code> or <code>f<i>N</i>x</code>) for the
   new
   types: <code>__builtin_copysign</code>, <code>__builtin_fabs</code>, <code>__builtin_huge_val</code>, <code>__builtin_inf</code>, <code>__builtin_nan</code>, <code>__builtin_nans</code>.</p></li>
+  <li>Compilation with <code>-fopenmp</code> is now compatible with
+  C11 <code>_Atomic</code> keyword.</li>
 </ul>
 
 <h3 id="cxx">C++</h3>
@@ -428,11 +479,17 @@ Fortran runtime error: Loop iterates inf
     </pre></blockquote>
   </li>
 
+  <li>Version 4.5 of the <a href="http://www.openmp.org/specifications/"
+      >OpenMP specification</a> is now partially supported also in the
+      Fortran compilers, largest missing support in the Fortran frontend
+      is structure element mapping .</li>
 </ul>
 
 <!-- <h3 id="go">Go</h3> -->
 
-<!-- <h3 id="java">Java (GCJ)</h3> -->
+<h3 id="java">Java (GCJ)</h3>
+<p>The GCC Java frontend and associated libjava runtime library have been
+removed from GCC.</p>
 
 <!-- .................................................................. -->
 <h2 id="jit">libgccjit</h2>
@@ -561,7 +618,13 @@ const int* get_address (unsigned idx)
 
 <!-- <h3 id="hsa">Heterogeneous Systems Architecture</h3> -->
 
-<!-- <h3 id="x86">IA-32/x86-64</h3> -->
+<h3 id="x86">IA-32/x86-64</h3>
+<ul>
+  <li>Support for the AVX-512 Fused Multiply Accumulation Packed Single precision
+  (4FMAPS), AVX-512 Vector Neural Network Instructions Word variable precision
+  (4VNNIW), AVX-512 Vector Population Count (VPOPCNTDQ) and Software
+  Guard Extensions (SGX) ISA extensions has been added.</li>
+</ul>
 
 <!-- <h3 id="mips">MIPS</h3> -->
 
@@ -571,12 +634,23 @@ const int* get_address (unsigned idx)
 
 <!-- <h3 id="nds32">NDS32</h3> -->
 
+<h3 id="nvptx">NVPTX</h3>
+<ul>
+  <li>OpenMP target regions can now be offloaded to NVidia PTX GPGPUs.
+      See https://gcc.gnu.org/wiki/Offloading on how to configure it.</li>
+</ul>
+
 <h3 id="powerpc">PowerPC / PowerPC64 / RS6000</h3>
 <ul>
   <li>The PowerPC port now uses LRA by default.</li>
   <li>GCC now diagnoses inline assembly that clobbers register r2.
     This has always been invalid code, and is no longer quietly
     tolerated.</li>
+  <li>Shrink-wrapping optimization can now separate portions of
+    prologues and epilogues to improve performance if some of the
+    work done traditionally by prologues and epilogues is not needed
+    on certain paths.  This is controlled by the
+    <code>-fshrink-wrap-separate</code> option, enabled by default.</li>
 </ul>
 
 <!-- <h3 id="s390">S/390, System z, IBM z Systems</h3> -->

	Jakub

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-01-27 16:35 [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc Jakub Jelinek
@ 2017-01-27 16:36 ` Kyrill Tkachov
  2017-01-27 16:43   ` Jakub Jelinek
  2017-01-29 12:38 ` Richard Biener
  2017-01-29 13:51 ` Prathamesh Kulkarni
  2 siblings, 1 reply; 20+ messages in thread
From: Kyrill Tkachov @ 2017-01-27 16:36 UTC (permalink / raw)
  To: Jakub Jelinek, gcc-patches
  Cc: Richard Biener, Uros Bizjak, Andrew Senkevich, Segher Boessenkool

Hi Jakub,

On 27/01/17 16:30, Jakub Jelinek wrote:
> Hi!
>
> This patch attempts to document some new features (without warnings,
> those are partially covered by Marek's patch, C++ FE (would be nice
> to document -faligned-new, -fnew-inheriting-ctors, -fnew-ttp-matching,
> -fstrong-eval-order and what from C++ is supported) and the BRIG FE).
>
> Ok for wwwdocs?
>

<snip>

> +
>   <h3 id="powerpc">PowerPC / PowerPC64 / RS6000</h3>
>   <ul>
>     <li>The PowerPC port now uses LRA by default.</li>
>     <li>GCC now diagnoses inline assembly that clobbers register r2.
>       This has always been invalid code, and is no longer quietly
>       tolerated.</li>
> +  <li>Shrink-wrapping optimization can now separate portions of
> +    prologues and epilogues to improve performance if some of the
> +    work done traditionally by prologues and epilogues is not needed
> +    on certain paths.  This is controlled by the
> +    <code>-fshrink-wrap-separate</code> option, enabled by default.</li>
>   </ul>
>   

AArch64 also implements these hooks and so benefits from the optimisation as well.
Perhaps move this to the general optimizer improvements section and mention it's only
enabled for powerpc and aarch64 for the moment?

Kyrill

>   <!-- <h3 id="s390">S/390, System z, IBM z Systems</h3> -->
>
> 	Jakub

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-01-27 16:36 ` Kyrill Tkachov
@ 2017-01-27 16:43   ` Jakub Jelinek
  2017-01-27 20:32     ` Segher Boessenkool
  0 siblings, 1 reply; 20+ messages in thread
From: Jakub Jelinek @ 2017-01-27 16:43 UTC (permalink / raw)
  To: Kyrill Tkachov
  Cc: gcc-patches, Richard Biener, Uros Bizjak, Andrew Senkevich,
	Segher Boessenkool

On Fri, Jan 27, 2017 at 04:34:53PM +0000, Kyrill Tkachov wrote:
> > +
> >   <h3 id="powerpc">PowerPC / PowerPC64 / RS6000</h3>
> >   <ul>
> >     <li>The PowerPC port now uses LRA by default.</li>
> >     <li>GCC now diagnoses inline assembly that clobbers register r2.
> >       This has always been invalid code, and is no longer quietly
> >       tolerated.</li>
> > +  <li>Shrink-wrapping optimization can now separate portions of
> > +    prologues and epilogues to improve performance if some of the
> > +    work done traditionally by prologues and epilogues is not needed
> > +    on certain paths.  This is controlled by the
> > +    <code>-fshrink-wrap-separate</code> option, enabled by default.</li>
> >   </ul>
> 
> AArch64 also implements these hooks and so benefits from the optimisation as well.
> Perhaps move this to the general optimizer improvements section and mention it's only
> enabled for powerpc and aarch64 for the moment?

Yeah, I've also noticed that, but not sure what is better, as it is only 2
targets that support it, so it is not really generic enough.  It is unclear what
is better.

	Jakub

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-01-27 16:43   ` Jakub Jelinek
@ 2017-01-27 20:32     ` Segher Boessenkool
  2017-01-27 21:28       ` Jakub Jelinek
  0 siblings, 1 reply; 20+ messages in thread
From: Segher Boessenkool @ 2017-01-27 20:32 UTC (permalink / raw)
  To: Jakub Jelinek
  Cc: Kyrill Tkachov, gcc-patches, Richard Biener, Uros Bizjak,
	Andrew Senkevich

On Fri, Jan 27, 2017 at 05:38:17PM +0100, Jakub Jelinek wrote:
> On Fri, Jan 27, 2017 at 04:34:53PM +0000, Kyrill Tkachov wrote:
> > > +
> > >   <h3 id="powerpc">PowerPC / PowerPC64 / RS6000</h3>
> > >   <ul>
> > >     <li>The PowerPC port now uses LRA by default.</li>
> > >     <li>GCC now diagnoses inline assembly that clobbers register r2.
> > >       This has always been invalid code, and is no longer quietly
> > >       tolerated.</li>
> > > +  <li>Shrink-wrapping optimization can now separate portions of
> > > +    prologues and epilogues to improve performance if some of the
> > > +    work done traditionally by prologues and epilogues is not needed
> > > +    on certain paths.  This is controlled by the
> > > +    <code>-fshrink-wrap-separate</code> option, enabled by default.</li>
> > >   </ul>

Thanks for doing this.  It was still on my todo list :-/

> > AArch64 also implements these hooks and so benefits from the optimisation as well.
> > Perhaps move this to the general optimizer improvements section and mention it's only
> > enabled for powerpc and aarch64 for the moment?
> 
> Yeah, I've also noticed that, but not sure what is better, as it is only 2
> targets that support it, so it is not really generic enough.  It is unclear what
> is better.

The subpass _is_ generic, I would move it like Kyrill says.


Segher

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-01-27 20:32     ` Segher Boessenkool
@ 2017-01-27 21:28       ` Jakub Jelinek
  2017-01-27 22:17         ` Segher Boessenkool
  2017-02-20  5:19         ` Gerald Pfeifer
  0 siblings, 2 replies; 20+ messages in thread
From: Jakub Jelinek @ 2017-01-27 21:28 UTC (permalink / raw)
  To: Segher Boessenkool
  Cc: Kyrill Tkachov, gcc-patches, Richard Biener, Uros Bizjak,
	Andrew Senkevich

On Fri, Jan 27, 2017 at 02:05:40PM -0600, Segher Boessenkool wrote:
> On Fri, Jan 27, 2017 at 05:38:17PM +0100, Jakub Jelinek wrote:
> > On Fri, Jan 27, 2017 at 04:34:53PM +0000, Kyrill Tkachov wrote:
> > > > +
> > > >   <h3 id="powerpc">PowerPC / PowerPC64 / RS6000</h3>
> > > >   <ul>
> > > >     <li>The PowerPC port now uses LRA by default.</li>
> > > >     <li>GCC now diagnoses inline assembly that clobbers register r2.
> > > >       This has always been invalid code, and is no longer quietly
> > > >       tolerated.</li>
> > > > +  <li>Shrink-wrapping optimization can now separate portions of
> > > > +    prologues and epilogues to improve performance if some of the
> > > > +    work done traditionally by prologues and epilogues is not needed
> > > > +    on certain paths.  This is controlled by the
> > > > +    <code>-fshrink-wrap-separate</code> option, enabled by default.</li>
> > > >   </ul>
> 
> Thanks for doing this.  It was still on my todo list :-/
> 
> > > AArch64 also implements these hooks and so benefits from the optimisation as well.
> > > Perhaps move this to the general optimizer improvements section and mention it's only
> > > enabled for powerpc and aarch64 for the moment?
> > 
> > Yeah, I've also noticed that, but not sure what is better, as it is only 2
> > targets that support it, so it is not really generic enough.  It is unclear what
> > is better.
> 
> The subpass _is_ generic, I would move it like Kyrill says.

Ok, so like this?

Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.44
diff -u -p -r1.44 changes.html
--- changes.html	27 Jan 2017 09:54:32 -0000	1.44
+++ changes.html	27 Jan 2017 21:14:50 -0000
@@ -45,8 +45,47 @@ a work-in-progress.</h2>
   <li>A new store merging pass has been added.  It merges constant stores to
   adjacent memory locations into fewer, wider, stores.
   It can be enabled by using the <code>-fstore-merging</code> option and is
-  enabled by default at <code>-Os</code> and the <code>-O2</code> optimization
-  level or higher.</li>
+  enabled by default at the <code>-O2</code> optimization
+  level or higher (including <code>-Os</code>).</li>
+
+  <li>A new code hoisting optimization has been added to the partial
+  redundancy elimination pass.  It attempts to move evaluation of
+  expressions executed on all paths to the function exit as early as
+  possible, which helps primarily for code size, but can be useful for
+  speed of generated code as well.  It can be enabled by using the
+  <code>-fcode-hoisting</code> option and is enabled by default at
+  the <code>-O2</code> optimization level or higher.</li>
+
+  <li>A new interprocedural bitwise constant propagation optimization
+  has been added, which propagates knowledge about which bits of variables
+  are known to be zero (including pointer alignment information) across
+  the call graph.  It can be enabled by using the <code>-fipa-bit-cp</code>
+  option if <code>-fipa-cp</code> is enabled as well, and is enabled by
+  default at the <code>-O2</code> optimization level and higher.</li>
+
+  <li>A new interprocedural value range propagation optimization has been
+  added, which propagates integral ranges that variable values can be proven
+  to be within across the call graph.  It can be enabled by using the
+  <code>-fipa-vrp</code> option and is enabled by default at the
+  <code>-O2</code> optimization level and higher.</li>
+
+  <li>A new loop splitting optimization pass has been added.  It splits
+  certain loops if they contain a condition that is always true on one
+  side of the iteration space and always false on the other into two
+  loops where each of the new two loops iterates just on one of the sides
+  of the iteration space and the condition does not need to be checked
+  inside of the loop.  It can be enabled by using the
+  <code>-fsplit-loops</code> option and is enabled by default at the
+  <code>-O3</code> optimization level or higher.</li>
+
+  <li>Shrink-wrapping optimization can now separate portions of
+  prologues and epilogues to improve performance if some of the
+  work done traditionally by prologues and epilogues is not needed
+  on certain paths.  This is controlled by the
+  <code>-fshrink-wrap-separate</code> option, enabled by default.
+  It requires target support, which is currently only implemented in the
+  PowerPC and AArch64 ports.</li>
+
   <li>AddressSanitizer gained a new sanitization option, <code>-fsanitize-address-use-after-scope</code>,
       which enables sanitization of variables whose address is taken and used after a scope where the
       variable is defined:
@@ -64,17 +103,17 @@ main (int argc, char **argv)
   return *ptr;
 }
 
-==28882==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffb8dba990 at pc 0x0000004006d5 bp 0x7fffb8dba960 sp 0x7fffb8dba958
-WRITE of size 1 at 0x7fffb8dba990 thread T0
+<span class="boldred">==28882==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffb8dba990 at pc 0x0000004006d5 bp 0x7fffb8dba960 sp 0x7fffb8dba958</span>
+<span class="boldblue">WRITE of size 1 at 0x7fffb8dba990 thread T0</span>
     #0 0x4006d4 in main /tmp/use-after-scope-1.c:10
     #1 0x7f9c71943290 in __libc_start_main (/lib64/libc.so.6+0x20290)
     #2 0x400739 in _start (/tmp/a.out+0x400739)
 
-Address 0x7fffb8dba990 is located in stack of thread T0 at offset 32 in frame
+<span class="boldlime">Address 0x7fffb8dba990 is located in stack of thread T0 at offset 32 in frame</span>
     #0 0x40067f in main /tmp/use-after-scope-1.c:3
 
   This frame has 1 object(s):
-    [32, 33) 'my_char' &lt;== Memory access at offset 32 is inside this variable
+    [32, 33) 'my_char' <span class="boldlime">&lt;== Memory access at offset 32 is inside this variable</span>
   </pre></blockquote>
 
   The option is enabled by default with <code>-fsanitize=address</code> and disabled
@@ -92,6 +131,16 @@ Address 0x7fffb8dba990 is located in sta
 
   </li>
 
+  <li>The <code>-fsanitize=signed-integer-overflow</code> suboption of the
+  UndefinedBehavior Sanitizer now diagnose arithmetic overflows even on
+  arithmetic operations with generic vectors.</li>
+
+  <li>The upcoming version 5 of the <a
+  href="http://www.dwarfstd.org/Download.php">DWARF</a> debugging
+  information standard is supported through the <code>-gdwarf-5</code>
+  option.  The DWARF version 4 debugging information remains the
+  default until debugging information consumers are adjusted.</li>
+
 </ul>
 
 <!-- .................................................................. -->
@@ -255,6 +304,14 @@ of the global declaration:</p>
   currently has the value of <code>UINTMAX_MAX</code> on all systems,
   reflecting that GCC's compile-time conversions are correctly rounded
   for any number of digits.</li>
+<li>New <code>__builtin_add_overflow_p</code>,
+  <code>__builtin_sub_overflow_p</code>,
+  <code>__builtin_mul_overflow_p</code> built-in functions have been added.
+  These work similarly to earlier added built-in functions without the
+  <code>_p</code> suffix, but don't actually store the result of the
+  arithmetics anywhere, just return whether the operation would overflow.
+  These builtins allow easy checking for overflows e.g. in C++
+  <code>constexpr</code> contexts.</li>
 </ul>
 
 <h3 id="c">C</h3>
@@ -291,6 +348,8 @@ of the global declaration:</p>
   (suffixed <code>f<i>N</i></code> or <code>f<i>N</i>x</code>) for the
   new
   types: <code>__builtin_copysign</code>, <code>__builtin_fabs</code>, <code>__builtin_huge_val</code>, <code>__builtin_inf</code>, <code>__builtin_nan</code>, <code>__builtin_nans</code>.</p></li>
+  <li>Compilation with <code>-fopenmp</code> is now compatible with
+  C11 <code>_Atomic</code> keyword.</li>
 </ul>
 
 <h3 id="cxx">C++</h3>
@@ -428,11 +487,17 @@ Fortran runtime error: Loop iterates inf
     </pre></blockquote>
   </li>
 
+  <li>Version 4.5 of the <a href="http://www.openmp.org/specifications/"
+      >OpenMP specification</a> is now partially supported also in the
+      Fortran compilers, largest missing support in the Fortran frontend
+      is structure element mapping .</li>
 </ul>
 
 <!-- <h3 id="go">Go</h3> -->
 
-<!-- <h3 id="java">Java (GCJ)</h3> -->
+<h3 id="java">Java (GCJ)</h3>
+<p>The GCC Java frontend and associated libjava runtime library have been
+removed from GCC.</p>
 
 <!-- .................................................................. -->
 <h2 id="jit">libgccjit</h2>
@@ -561,7 +626,13 @@ const int* get_address (unsigned idx)
 
 <!-- <h3 id="hsa">Heterogeneous Systems Architecture</h3> -->
 
-<!-- <h3 id="x86">IA-32/x86-64</h3> -->
+<h3 id="x86">IA-32/x86-64</h3>
+<ul>
+  <li>Support for the AVX-512 Fused Multiply Accumulation Packed Single precision
+  (4FMAPS), AVX-512 Vector Neural Network Instructions Word variable precision
+  (4VNNIW), AVX-512 Vector Population Count (VPOPCNTDQ) and Software
+  Guard Extensions (SGX) ISA extensions has been added.</li>
+</ul>
 
 <!-- <h3 id="mips">MIPS</h3> -->
 
@@ -571,6 +642,12 @@ const int* get_address (unsigned idx)
 
 <!-- <h3 id="nds32">NDS32</h3> -->
 
+<h3 id="nvptx">NVPTX</h3>
+<ul>
+  <li>OpenMP target regions can now be offloaded to NVidia PTX GPGPUs.
+      See https://gcc.gnu.org/wiki/Offloading on how to configure it.</li>
+</ul>
+
 <h3 id="powerpc">PowerPC / PowerPC64 / RS6000</h3>
 <ul>
   <li>The PowerPC port now uses LRA by default.</li>


	Jakub

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-01-27 21:28       ` Jakub Jelinek
@ 2017-01-27 22:17         ` Segher Boessenkool
  2017-02-20  5:19         ` Gerald Pfeifer
  1 sibling, 0 replies; 20+ messages in thread
From: Segher Boessenkool @ 2017-01-27 22:17 UTC (permalink / raw)
  To: Jakub Jelinek
  Cc: Kyrill Tkachov, gcc-patches, Richard Biener, Uros Bizjak,
	Andrew Senkevich

On Fri, Jan 27, 2017 at 10:15:37PM +0100, Jakub Jelinek wrote:
> > > > AArch64 also implements these hooks and so benefits from the optimisation as well.
> > > > Perhaps move this to the general optimizer improvements section and mention it's only
> > > > enabled for powerpc and aarch64 for the moment?
> > > 
> > > Yeah, I've also noticed that, but not sure what is better, as it is only 2
> > > targets that support it, so it is not really generic enough.  It is unclear what
> > > is better.
> > 
> > The subpass _is_ generic, I would move it like Kyrill says.
> 
> Ok, so like this?

That looks great, thanks again!


Segher

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-01-27 16:35 [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc Jakub Jelinek
  2017-01-27 16:36 ` Kyrill Tkachov
@ 2017-01-29 12:38 ` Richard Biener
  2017-01-29 13:51 ` Prathamesh Kulkarni
  2 siblings, 0 replies; 20+ messages in thread
From: Richard Biener @ 2017-01-29 12:38 UTC (permalink / raw)
  To: Jakub Jelinek, gcc-patches
  Cc: Uros Bizjak, Andrew Senkevich, Segher Boessenkool

On January 27, 2017 5:30:51 PM GMT+01:00, Jakub Jelinek <jakub@redhat.com> wrote:
>Hi!
>
>This patch attempts to document some new features (without warnings,
>those are partially covered by Marek's patch, C++ FE (would be nice
>to document -faligned-new, -fnew-inheriting-ctors, -fnew-ttp-matching,
>-fstrong-eval-order and what from C++ is supported) and the BRIG FE).
>
>Ok for wwwdocs?

LGTM.

Richard.

>Index: changes.html
>===================================================================
>RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
>retrieving revision 1.44
>diff -u -p -r1.44 changes.html
>--- changes.html	27 Jan 2017 09:54:32 -0000	1.44
>+++ changes.html	27 Jan 2017 16:23:03 -0000
>@@ -45,8 +45,39 @@ a work-in-progress.</h2>
><li>A new store merging pass has been added.  It merges constant stores
>to
>   adjacent memory locations into fewer, wider, stores.
>It can be enabled by using the <code>-fstore-merging</code> option and
>is
>-  enabled by default at <code>-Os</code> and the <code>-O2</code>
>optimization
>-  level or higher.</li>
>+  enabled by default at the <code>-O2</code> optimization
>+  level or higher (including <code>-Os</code>).</li>
>+
>+  <li>A new code hoisting optimization has been added to the partial
>+  redundancy elimination pass.  It attempts to move evaluation of
>+  expressions executed on all paths to the function exit as early as
>+  possible, which helps primarily for code size, but can be useful for
>+  speed of generated code as well.  It can be enabled by using the
>+  <code>-fcode-hoisting</code> option and is enabled by default at
>+  the <code>-O2</code> optimization level or higher.</li>
>+
>+  <li>A new interprocedural bitwise constant propagation optimization
>+  has been added, which propagates knowledge about which bits of
>variables
>+  are known to be zero (including pointer alignment information)
>across
>+  the call graph.  It can be enabled by using the
><code>-fipa-bit-cp</code>
>+  option if <code>-fipa-cp</code> is enabled as well, and is enabled
>by
>+  default at the <code>-O2</code> optimization level and higher.</li>
>+
>+  <li>A new interprocedural value range propagation optimization has
>been
>+  added, which propagates integral ranges that variable values can be
>proven
>+  to be within across the call graph.  It can be enabled by using the
>+  <code>-fipa-vrp</code> option and is enabled by default at the
>+  <code>-O2</code> optimization level and higher.</li>
>+
>+  <li>A new loop splitting optimization pass has been added.  It
>splits
>+  certain loops if they contain a condition that is always true on one
>+  side of the iteration space and always false on the other into two
>+  loops where each of the new two loops iterates just on one of the
>sides
>+  of the iteration space and the condition does not need to be checked
>+  inside of the loop.  It can be enabled by using the
>+  <code>-fsplit-loops</code> option and is enabled by default at the
>+  <code>-O3</code> optimization level or higher.</li>
>+
><li>AddressSanitizer gained a new sanitization option,
><code>-fsanitize-address-use-after-scope</code>,
>which enables sanitization of variables whose address is taken and used
>after a scope where the
>       variable is defined:
>@@ -64,17 +95,17 @@ main (int argc, char **argv)
>   return *ptr;
> }
> 
>-==28882==ERROR: AddressSanitizer: stack-use-after-scope on address
>0x7fffb8dba990 at pc 0x0000004006d5 bp 0x7fffb8dba960 sp 0x7fffb8dba958
>-WRITE of size 1 at 0x7fffb8dba990 thread T0
>+<span class="boldred">==28882==ERROR: AddressSanitizer:
>stack-use-after-scope on address 0x7fffb8dba990 at pc 0x0000004006d5 bp
>0x7fffb8dba960 sp 0x7fffb8dba958</span>
>+<span class="boldblue">WRITE of size 1 at 0x7fffb8dba990 thread
>T0</span>
>     #0 0x4006d4 in main /tmp/use-after-scope-1.c:10
>     #1 0x7f9c71943290 in __libc_start_main (/lib64/libc.so.6+0x20290)
>     #2 0x400739 in _start (/tmp/a.out+0x400739)
> 
>-Address 0x7fffb8dba990 is located in stack of thread T0 at offset 32
>in frame
>+<span class="boldlime">Address 0x7fffb8dba990 is located in stack of
>thread T0 at offset 32 in frame</span>
>     #0 0x40067f in main /tmp/use-after-scope-1.c:3
> 
>   This frame has 1 object(s):
>-    [32, 33) 'my_char' &lt;== Memory access at offset 32 is inside
>this variable
>+    [32, 33) 'my_char' <span class="boldlime">&lt;== Memory access at
>offset 32 is inside this variable</span>
>   </pre></blockquote>
> 
>The option is enabled by default with <code>-fsanitize=address</code>
>and disabled
>@@ -92,6 +123,16 @@ Address 0x7fffb8dba990 is located in sta
> 
>   </li>
> 
>+  <li>The <code>-fsanitize=signed-integer-overflow</code> suboption of
>the
>+  UndefinedBehavior Sanitizer now diagnose arithmetic overflows even
>on
>+  arithmetic operations with generic vectors.</li>
>+
>+  <li>The upcoming version 5 of the <a
>+  href="http://www.dwarfstd.org/Download.php">DWARF</a> debugging
>+  information standard is supported through the <code>-gdwarf-5</code>
>+  option.  The DWARF version 4 debugging information remains the
>+  default until debugging information consumers are adjusted.</li>
>+
> </ul>
> 
><!-- ..................................................................
>-->
>@@ -255,6 +296,14 @@ of the global declaration:</p>
>   currently has the value of <code>UINTMAX_MAX</code> on all systems,
>   reflecting that GCC's compile-time conversions are correctly rounded
>   for any number of digits.</li>
>+<li>New <code>__builtin_add_overflow_p</code>,
>+  <code>__builtin_sub_overflow_p</code>,
>+  <code>__builtin_mul_overflow_p</code> built-in functions have been
>added.
>+  These work similarly to earlier added built-in functions without the
>+  <code>_p</code> suffix, but don't actually store the result of the
>+  arithmetics anywhere, just return whether the operation would
>overflow.
>+  These builtins allow easy checking for overflows e.g. in C++
>+  <code>constexpr</code> contexts.</li>
> </ul>
> 
> <h3 id="c">C</h3>
>@@ -291,6 +340,8 @@ of the global declaration:</p>
>   (suffixed <code>f<i>N</i></code> or <code>f<i>N</i>x</code>) for the
>   new
>types: <code>__builtin_copysign</code>, <code>__builtin_fabs</code>,
><code>__builtin_huge_val</code>, <code>__builtin_inf</code>,
><code>__builtin_nan</code>, <code>__builtin_nans</code>.</p></li>
>+  <li>Compilation with <code>-fopenmp</code> is now compatible with
>+  C11 <code>_Atomic</code> keyword.</li>
> </ul>
> 
> <h3 id="cxx">C++</h3>
>@@ -428,11 +479,17 @@ Fortran runtime error: Loop iterates inf
>     </pre></blockquote>
>   </li>
> 
>+  <li>Version 4.5 of the <a
>href="http://www.openmp.org/specifications/"
>+      >OpenMP specification</a> is now partially supported also in the
>+      Fortran compilers, largest missing support in the Fortran
>frontend
>+      is structure element mapping .</li>
> </ul>
> 
> <!-- <h3 id="go">Go</h3> -->
> 
>-<!-- <h3 id="java">Java (GCJ)</h3> -->
>+<h3 id="java">Java (GCJ)</h3>
>+<p>The GCC Java frontend and associated libjava runtime library have
>been
>+removed from GCC.</p>
> 
><!-- ..................................................................
>-->
> <h2 id="jit">libgccjit</h2>
>@@ -561,7 +618,13 @@ const int* get_address (unsigned idx)
> 
> <!-- <h3 id="hsa">Heterogeneous Systems Architecture</h3> -->
> 
>-<!-- <h3 id="x86">IA-32/x86-64</h3> -->
>+<h3 id="x86">IA-32/x86-64</h3>
>+<ul>
>+  <li>Support for the AVX-512 Fused Multiply Accumulation Packed
>Single precision
>+  (4FMAPS), AVX-512 Vector Neural Network Instructions Word variable
>precision
>+  (4VNNIW), AVX-512 Vector Population Count (VPOPCNTDQ) and Software
>+  Guard Extensions (SGX) ISA extensions has been added.</li>
>+</ul>
> 
> <!-- <h3 id="mips">MIPS</h3> -->
> 
>@@ -571,12 +634,23 @@ const int* get_address (unsigned idx)
> 
> <!-- <h3 id="nds32">NDS32</h3> -->
> 
>+<h3 id="nvptx">NVPTX</h3>
>+<ul>
>+  <li>OpenMP target regions can now be offloaded to NVidia PTX GPGPUs.
>+      See https://gcc.gnu.org/wiki/Offloading on how to configure
>it.</li>
>+</ul>
>+
> <h3 id="powerpc">PowerPC / PowerPC64 / RS6000</h3>
> <ul>
>   <li>The PowerPC port now uses LRA by default.</li>
>   <li>GCC now diagnoses inline assembly that clobbers register r2.
>     This has always been invalid code, and is no longer quietly
>     tolerated.</li>
>+  <li>Shrink-wrapping optimization can now separate portions of
>+    prologues and epilogues to improve performance if some of the
>+    work done traditionally by prologues and epilogues is not needed
>+    on certain paths.  This is controlled by the
>+    <code>-fshrink-wrap-separate</code> option, enabled by
>default.</li>
> </ul>
> 
> <!-- <h3 id="s390">S/390, System z, IBM z Systems</h3> -->
>
>	Jakub

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-01-27 16:35 [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc Jakub Jelinek
  2017-01-27 16:36 ` Kyrill Tkachov
  2017-01-29 12:38 ` Richard Biener
@ 2017-01-29 13:51 ` Prathamesh Kulkarni
  2017-01-29 19:28   ` Jakub Jelinek
  2 siblings, 1 reply; 20+ messages in thread
From: Prathamesh Kulkarni @ 2017-01-29 13:51 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: gcc Patches

On 27 January 2017 at 22:00, Jakub Jelinek <jakub@redhat.com> wrote:
> Hi!
>
> This patch attempts to document some new features (without warnings,
> those are partially covered by Marek's patch, C++ FE (would be nice
> to document -faligned-new, -fnew-inheriting-ctors, -fnew-ttp-matching,
> -fstrong-eval-order and what from C++ is supported) and the BRIG FE).
>
> Ok for wwwdocs?
>
> Index: changes.html
> ===================================================================
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
> retrieving revision 1.44
> diff -u -p -r1.44 changes.html
> --- changes.html        27 Jan 2017 09:54:32 -0000      1.44
> +++ changes.html        27 Jan 2017 16:23:03 -0000
> @@ -45,8 +45,39 @@ a work-in-progress.</h2>
>    <li>A new store merging pass has been added.  It merges constant stores to
>    adjacent memory locations into fewer, wider, stores.
>    It can be enabled by using the <code>-fstore-merging</code> option and is
> -  enabled by default at <code>-Os</code> and the <code>-O2</code> optimization
> -  level or higher.</li>
> +  enabled by default at the <code>-O2</code> optimization
> +  level or higher (including <code>-Os</code>).</li>
> +
> +  <li>A new code hoisting optimization has been added to the partial
> +  redundancy elimination pass.  It attempts to move evaluation of
> +  expressions executed on all paths to the function exit as early as
> +  possible, which helps primarily for code size, but can be useful for
> +  speed of generated code as well.  It can be enabled by using the
> +  <code>-fcode-hoisting</code> option and is enabled by default at
> +  the <code>-O2</code> optimization level or higher.</li>
> +
> +  <li>A new interprocedural bitwise constant propagation optimization
> +  has been added, which propagates knowledge about which bits of variables
> +  are known to be zero (including pointer alignment information) across
> +  the call graph.  It can be enabled by using the <code>-fipa-bit-cp</code>
> +  option if <code>-fipa-cp</code> is enabled as well, and is enabled by
> +  default at the <code>-O2</code> optimization level and higher.</li>
Hi,
Just a small comment:  -fipa-bit-cp makes -fipa-cp-alignment deprecated.
Sorry for not documenting this option myself and thanks for writing it up!

Regards,
Prathamesh
> +
> +  <li>A new interprocedural value range propagation optimization has been
> +  added, which propagates integral ranges that variable values can be proven
> +  to be within across the call graph.  It can be enabled by using the
> +  <code>-fipa-vrp</code> option and is enabled by default at the
> +  <code>-O2</code> optimization level and higher.</li>
> +
> +  <li>A new loop splitting optimization pass has been added.  It splits
> +  certain loops if they contain a condition that is always true on one
> +  side of the iteration space and always false on the other into two
> +  loops where each of the new two loops iterates just on one of the sides
> +  of the iteration space and the condition does not need to be checked
> +  inside of the loop.  It can be enabled by using the
> +  <code>-fsplit-loops</code> option and is enabled by default at the
> +  <code>-O3</code> optimization level or higher.</li>
> +
>    <li>AddressSanitizer gained a new sanitization option, <code>-fsanitize-address-use-after-scope</code>,
>        which enables sanitization of variables whose address is taken and used after a scope where the
>        variable is defined:
> @@ -64,17 +95,17 @@ main (int argc, char **argv)
>    return *ptr;
>  }
>
> -==28882==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffb8dba990 at pc 0x0000004006d5 bp 0x7fffb8dba960 sp 0x7fffb8dba958
> -WRITE of size 1 at 0x7fffb8dba990 thread T0
> +<span class="boldred">==28882==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffb8dba990 at pc 0x0000004006d5 bp 0x7fffb8dba960 sp 0x7fffb8dba958</span>
> +<span class="boldblue">WRITE of size 1 at 0x7fffb8dba990 thread T0</span>
>      #0 0x4006d4 in main /tmp/use-after-scope-1.c:10
>      #1 0x7f9c71943290 in __libc_start_main (/lib64/libc.so.6+0x20290)
>      #2 0x400739 in _start (/tmp/a.out+0x400739)
>
> -Address 0x7fffb8dba990 is located in stack of thread T0 at offset 32 in frame
> +<span class="boldlime">Address 0x7fffb8dba990 is located in stack of thread T0 at offset 32 in frame</span>
>      #0 0x40067f in main /tmp/use-after-scope-1.c:3
>
>    This frame has 1 object(s):
> -    [32, 33) 'my_char' &lt;== Memory access at offset 32 is inside this variable
> +    [32, 33) 'my_char' <span class="boldlime">&lt;== Memory access at offset 32 is inside this variable</span>
>    </pre></blockquote>
>
>    The option is enabled by default with <code>-fsanitize=address</code> and disabled
> @@ -92,6 +123,16 @@ Address 0x7fffb8dba990 is located in sta
>
>    </li>
>
> +  <li>The <code>-fsanitize=signed-integer-overflow</code> suboption of the
> +  UndefinedBehavior Sanitizer now diagnose arithmetic overflows even on
> +  arithmetic operations with generic vectors.</li>
> +
> +  <li>The upcoming version 5 of the <a
> +  href="http://www.dwarfstd.org/Download.php">DWARF</a> debugging
> +  information standard is supported through the <code>-gdwarf-5</code>
> +  option.  The DWARF version 4 debugging information remains the
> +  default until debugging information consumers are adjusted.</li>
> +
>  </ul>
>
>  <!-- .................................................................. -->
> @@ -255,6 +296,14 @@ of the global declaration:</p>
>    currently has the value of <code>UINTMAX_MAX</code> on all systems,
>    reflecting that GCC's compile-time conversions are correctly rounded
>    for any number of digits.</li>
> +<li>New <code>__builtin_add_overflow_p</code>,
> +  <code>__builtin_sub_overflow_p</code>,
> +  <code>__builtin_mul_overflow_p</code> built-in functions have been added.
> +  These work similarly to earlier added built-in functions without the
> +  <code>_p</code> suffix, but don't actually store the result of the
> +  arithmetics anywhere, just return whether the operation would overflow.
> +  These builtins allow easy checking for overflows e.g. in C++
> +  <code>constexpr</code> contexts.</li>
>  </ul>
>
>  <h3 id="c">C</h3>
> @@ -291,6 +340,8 @@ of the global declaration:</p>
>    (suffixed <code>f<i>N</i></code> or <code>f<i>N</i>x</code>) for the
>    new
>    types: <code>__builtin_copysign</code>, <code>__builtin_fabs</code>, <code>__builtin_huge_val</code>, <code>__builtin_inf</code>, <code>__builtin_nan</code>, <code>__builtin_nans</code>.</p></li>
> +  <li>Compilation with <code>-fopenmp</code> is now compatible with
> +  C11 <code>_Atomic</code> keyword.</li>
>  </ul>
>
>  <h3 id="cxx">C++</h3>
> @@ -428,11 +479,17 @@ Fortran runtime error: Loop iterates inf
>      </pre></blockquote>
>    </li>
>
> +  <li>Version 4.5 of the <a href="http://www.openmp.org/specifications/"
> +      >OpenMP specification</a> is now partially supported also in the
> +      Fortran compilers, largest missing support in the Fortran frontend
> +      is structure element mapping .</li>
>  </ul>
>
>  <!-- <h3 id="go">Go</h3> -->
>
> -<!-- <h3 id="java">Java (GCJ)</h3> -->
> +<h3 id="java">Java (GCJ)</h3>
> +<p>The GCC Java frontend and associated libjava runtime library have been
> +removed from GCC.</p>
>
>  <!-- .................................................................. -->
>  <h2 id="jit">libgccjit</h2>
> @@ -561,7 +618,13 @@ const int* get_address (unsigned idx)
>
>  <!-- <h3 id="hsa">Heterogeneous Systems Architecture</h3> -->
>
> -<!-- <h3 id="x86">IA-32/x86-64</h3> -->
> +<h3 id="x86">IA-32/x86-64</h3>
> +<ul>
> +  <li>Support for the AVX-512 Fused Multiply Accumulation Packed Single precision
> +  (4FMAPS), AVX-512 Vector Neural Network Instructions Word variable precision
> +  (4VNNIW), AVX-512 Vector Population Count (VPOPCNTDQ) and Software
> +  Guard Extensions (SGX) ISA extensions has been added.</li>
> +</ul>
>
>  <!-- <h3 id="mips">MIPS</h3> -->
>
> @@ -571,12 +634,23 @@ const int* get_address (unsigned idx)
>
>  <!-- <h3 id="nds32">NDS32</h3> -->
>
> +<h3 id="nvptx">NVPTX</h3>
> +<ul>
> +  <li>OpenMP target regions can now be offloaded to NVidia PTX GPGPUs.
> +      See https://gcc.gnu.org/wiki/Offloading on how to configure it.</li>
> +</ul>
> +
>  <h3 id="powerpc">PowerPC / PowerPC64 / RS6000</h3>
>  <ul>
>    <li>The PowerPC port now uses LRA by default.</li>
>    <li>GCC now diagnoses inline assembly that clobbers register r2.
>      This has always been invalid code, and is no longer quietly
>      tolerated.</li>
> +  <li>Shrink-wrapping optimization can now separate portions of
> +    prologues and epilogues to improve performance if some of the
> +    work done traditionally by prologues and epilogues is not needed
> +    on certain paths.  This is controlled by the
> +    <code>-fshrink-wrap-separate</code> option, enabled by default.</li>
>  </ul>
>
>  <!-- <h3 id="s390">S/390, System z, IBM z Systems</h3> -->
>
>         Jakub

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-01-29 13:51 ` Prathamesh Kulkarni
@ 2017-01-29 19:28   ` Jakub Jelinek
  2017-01-31 11:41     ` Martin Jambor
  0 siblings, 1 reply; 20+ messages in thread
From: Jakub Jelinek @ 2017-01-29 19:28 UTC (permalink / raw)
  To: Prathamesh Kulkarni; +Cc: gcc Patches

On Sun, Jan 29, 2017 at 06:08:32PM +0530, Prathamesh Kulkarni wrote:
> > +  <li>A new interprocedural bitwise constant propagation optimization
> > +  has been added, which propagates knowledge about which bits of variables
> > +  are known to be zero (including pointer alignment information) across
> > +  the call graph.  It can be enabled by using the <code>-fipa-bit-cp</code>
> > +  option if <code>-fipa-cp</code> is enabled as well, and is enabled by
> > +  default at the <code>-O2</code> optimization level and higher.</li>
> Hi,
> Just a small comment:  -fipa-bit-cp makes -fipa-cp-alignment deprecated.

I've committed it as is, feel free to propose changes.  But before that, we
should figure out what to do with -fipa-cp-alignment.  Should it have
Ignore flag and
Does nothing. Preserved for backward compatibility.
description in common.opt, and

@item -fipa-cp-alignment
@opindex -fipa-cp-alignment
When enabled, this optimization propagates alignment of function
parameters to support better vectorization and string operations.

This flag is enabled by default at @option{-O2} and @option{-Os}.  It
requires that @option{-fipa-cp} is enabled.
@option{-fipa-cp-alignment} is obsolete, use @option{-fipa-bit-cp} instead.

removed altogether, or should it say be alias for -fipa-bit-cp?
The documentation certainly doesn't document what it does, because nothing
ever looks at that flag, so it is effectively ignored, not just obsolete.

	Jakub

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-01-29 19:28   ` Jakub Jelinek
@ 2017-01-31 11:41     ` Martin Jambor
  2017-01-31 16:41       ` Jakub Jelinek
  0 siblings, 1 reply; 20+ messages in thread
From: Martin Jambor @ 2017-01-31 11:41 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Prathamesh Kulkarni, gcc Patches

Hi,

On Sun, Jan 29, 2017 at 07:55:18PM +0100, Jakub Jelinek wrote:
> On Sun, Jan 29, 2017 at 06:08:32PM +0530, Prathamesh Kulkarni wrote:
> > > +  <li>A new interprocedural bitwise constant propagation optimization
> > > +  has been added, which propagates knowledge about which bits of variables
> > > +  are known to be zero (including pointer alignment information) across
> > > +  the call graph.  It can be enabled by using the <code>-fipa-bit-cp</code>
> > > +  option if <code>-fipa-cp</code> is enabled as well, and is enabled by
> > > +  default at the <code>-O2</code> optimization level and higher.</li>
> > Hi,
> > Just a small comment:  -fipa-bit-cp makes -fipa-cp-alignment deprecated.
> 
> I've committed it as is, feel free to propose changes.  But before that, we
> should figure out what to do with -fipa-cp-alignment.  Should it have
> Ignore flag and
> Does nothing. Preserved for backward compatibility.
> description in common.opt, and
> 
> @item -fipa-cp-alignment
> @opindex -fipa-cp-alignment
> When enabled, this optimization propagates alignment of function
> parameters to support better vectorization and string operations.
> 
> This flag is enabled by default at @option{-O2} and @option{-Os}.  It
> requires that @option{-fipa-cp} is enabled.
> @option{-fipa-cp-alignment} is obsolete, use @option{-fipa-bit-cp} instead.
> 
> removed altogether, or should it say be alias for -fipa-bit-cp?

Well, -fipa-bit-cp is a superset of the old -fipa-cp-alignment in the
sense that the latter worked only for pointers whereas the former now
also operates on integers.

We could still refuse to store results of the analysis to pointers if
user provided -fno-ipa-cp-alignment, but I do not think it is
reasonable.  My preference would be to mark it obsolete and document
that -fipa-bit-cp should be used instead.

> The documentation certainly doesn't document what it does, because nothing
> ever looks at that flag, so it is effectively ignored, not just obsolete.

I'm not sure I understand, it was used by gcc 6 and the documentation
describes what it did.  The documentation of course should be updated.

Martin

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-01-31 11:41     ` Martin Jambor
@ 2017-01-31 16:41       ` Jakub Jelinek
  2017-01-31 17:30         ` Martin Jambor
  0 siblings, 1 reply; 20+ messages in thread
From: Jakub Jelinek @ 2017-01-31 16:41 UTC (permalink / raw)
  To: Prathamesh Kulkarni, gcc Patches

On Tue, Jan 31, 2017 at 12:15:36PM +0100, Martin Jambor wrote:
> > I've committed it as is, feel free to propose changes.  But before that, we
> > should figure out what to do with -fipa-cp-alignment.  Should it have
> > Ignore flag and
> > Does nothing. Preserved for backward compatibility.
> > description in common.opt, and
> > 
> > @item -fipa-cp-alignment
> > @opindex -fipa-cp-alignment
> > When enabled, this optimization propagates alignment of function
> > parameters to support better vectorization and string operations.
> > 
> > This flag is enabled by default at @option{-O2} and @option{-Os}.  It
> > requires that @option{-fipa-cp} is enabled.
> > @option{-fipa-cp-alignment} is obsolete, use @option{-fipa-bit-cp} instead.
> > 
> > removed altogether, or should it say be alias for -fipa-bit-cp?
> 
> Well, -fipa-bit-cp is a superset of the old -fipa-cp-alignment in the
> sense that the latter worked only for pointers whereas the former now
> also operates on integers.
> 
> We could still refuse to store results of the analysis to pointers if
> user provided -fno-ipa-cp-alignment, but I do not think it is
> reasonable.  My preference would be to mark it obsolete and document
> that -fipa-bit-cp should be used instead.

What are obsolete options?  Do you mean deprecated or removed?
We have ignored options retained just for compatibility that do nothing.
-fipa-cp-alignment does nothing right now (nothing ever checks it), but
it isn't declared as Ignore and is documented (ignored options aren't
documented).  The current state is that e.g. x_flag_ipa_cp_alignment is
still a field in global_options* etc.

	Jakub

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-01-31 16:41       ` Jakub Jelinek
@ 2017-01-31 17:30         ` Martin Jambor
  0 siblings, 0 replies; 20+ messages in thread
From: Martin Jambor @ 2017-01-31 17:30 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Prathamesh Kulkarni, gcc Patches

On Tue, Jan 31, 2017 at 05:31:41PM +0100, Jakub Jelinek wrote:
> On Tue, Jan 31, 2017 at 12:15:36PM +0100, Martin Jambor wrote:
> > > I've committed it as is, feel free to propose changes.  But before that, we
> > > should figure out what to do with -fipa-cp-alignment.  Should it have
> > > Ignore flag and
> > > Does nothing. Preserved for backward compatibility.
> > > description in common.opt, and
> > > 
> > > @item -fipa-cp-alignment
> > > @opindex -fipa-cp-alignment
> > > When enabled, this optimization propagates alignment of function
> > > parameters to support better vectorization and string operations.
> > > 
> > > This flag is enabled by default at @option{-O2} and @option{-Os}.  It
> > > requires that @option{-fipa-cp} is enabled.
> > > @option{-fipa-cp-alignment} is obsolete, use @option{-fipa-bit-cp} instead.
> > > 
> > > removed altogether, or should it say be alias for -fipa-bit-cp?
> > 
> > Well, -fipa-bit-cp is a superset of the old -fipa-cp-alignment in the
> > sense that the latter worked only for pointers whereas the former now
> > also operates on integers.
> > 
> > We could still refuse to store results of the analysis to pointers if
> > user provided -fno-ipa-cp-alignment, but I do not think it is
> > reasonable.  My preference would be to mark it obsolete and document
> > that -fipa-bit-cp should be used instead.
> 
> What are obsolete options?  Do you mean deprecated or removed?

I am sorry, I got confused by the mail I was quoting.  I meant
deprecated, because I thought that was the appropriate thing to do.
However, I personally will not object if we remove it.

> We have ignored options retained just for compatibility that do nothing.

I'll have a look at how it is done and prepare a patch, it may take a
few days though because I am traveling now.

Martin

> -fipa-cp-alignment does nothing right now (nothing ever checks it), but
> it isn't declared as Ignore and is documented (ignored options aren't
> documented).  The current state is that e.g. x_flag_ipa_cp_alignment is
> still a field in global_options* etc.
> 
> 	Jakub

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-01-27 21:28       ` Jakub Jelinek
  2017-01-27 22:17         ` Segher Boessenkool
@ 2017-02-20  5:19         ` Gerald Pfeifer
  2017-02-26 14:35           ` Gerald Pfeifer
  1 sibling, 1 reply; 20+ messages in thread
From: Gerald Pfeifer @ 2017-02-20  5:19 UTC (permalink / raw)
  To: Jakub Jelinek
  Cc: Segher Boessenkool, Kyrill Tkachov, gcc-patches, Richard Biener,
	Uros Bizjak, Andrew Senkevich

That was quite a bit; thanks for doing that, Jakub!

In the patch below I try to streamline language a bit, document options 
being implied by -Os (in addition to -O2 or higher), fix grammar in a few 
places, and change a textual link to being a real one.

I have _not_ applied this yet, and would appreciate your feedback.

Gerald

Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.65
diff -u -r1.65 changes.html
--- changes.html	19 Feb 2017 21:55:56 -0000	1.65
+++ changes.html	19 Feb 2017 22:00:59 -0000
@@ -50,41 +50,44 @@
     <code>-fprintf-return-value</code> option.</li>
   <li>A new store merging pass has been added.  It merges constant stores to
   adjacent memory locations into fewer, wider, stores.
-  It can be enabled by using the <code>-fstore-merging</code> option and is
+  It is enabled by the <code>-fstore-merging</code> option and is
   enabled by default at the <code>-O2</code> optimization
-  level or higher (including <code>-Os</code>).</li>
+  level or higher (and <code>-Os</code>).</li>
 
   <li>A new code hoisting optimization has been added to the partial
   redundancy elimination pass.  It attempts to move evaluation of
   expressions executed on all paths to the function exit as early as
   possible, which helps primarily for code size, but can be useful for
-  speed of generated code as well.  It can be enabled by using the
+  speed of generated code as well.  It is enabled by the
   <code>-fcode-hoisting</code> option and is enabled by default at
-  the <code>-O2</code> optimization level or higher.</li>
+  the <code>-O2</code> optimization level or higher (and
+  <code>-Os</code>).</li>
 
   <li>A new interprocedural bitwise constant propagation optimization
   has been added, which propagates knowledge about which bits of variables
   are known to be zero (including pointer alignment information) across
-  the call graph.  It can be enabled by using the <code>-fipa-bit-cp</code>
+  the call graph.  It is enabled by the <code>-fipa-bit-cp</code>
   option if <code>-fipa-cp</code> is enabled as well, and is enabled by
-  default at the <code>-O2</code> optimization level and higher.</li>
+  default at the <code>-O2</code> optimization level and higher (and
+  <code>-Os</code>).</li>
 
   <li>A new interprocedural value range propagation optimization has been
   added, which propagates integral ranges that variable values can be proven
-  to be within across the call graph.  It can be enabled by using the
+  to be within across the call graph.  It is enabled by the
   <code>-fipa-vrp</code> option and is enabled by default at the
-  <code>-O2</code> optimization level and higher.</li>
+  <code>-O2</code> optimization level and higher (and
+  <code>-Os</code>).</li>
 
   <li>A new loop splitting optimization pass has been added.  It splits
   certain loops if they contain a condition that is always true on one
   side of the iteration space and always false on the other into two
   loops where each of the new two loops iterates just on one of the sides
   of the iteration space and the condition does not need to be checked
-  inside of the loop.  It can be enabled by using the
+  inside of the loop.  It is enabled by the
   <code>-fsplit-loops</code> option and is enabled by default at the
   <code>-O3</code> optimization level or higher.</li>
 
-  <li>Shrink-wrapping optimization can now separate portions of
+  <li>The shrink-wrapping optimization can now separate portions of
   prologues and epilogues to improve performance if some of the
   work done traditionally by prologues and epilogues is not needed
   on certain paths.  This is controlled by the
@@ -138,7 +141,7 @@
   </li>
 
   <li>The <code>-fsanitize=signed-integer-overflow</code> suboption of the
-  UndefinedBehavior Sanitizer now diagnose arithmetic overflows even on
+  UndefinedBehavior Sanitizer now diagnoses arithmetic overflows even on
   arithmetic operations with generic vectors.</li>
 
   <li>Version 5 of the <a
@@ -525,8 +528,8 @@
 <li>New <code>__builtin_add_overflow_p</code>,
   <code>__builtin_sub_overflow_p</code>,
   <code>__builtin_mul_overflow_p</code> built-in functions have been added.
-  These work similarly to earlier added built-in functions without the
-  <code>_p</code> suffix, but don't actually store the result of the
+  These work similarly to their siblings without the
+  <code>_p</code> suffix, but do not actually store the result of the
   arithmetics anywhere, just return whether the operation would overflow.
   These builtins allow easy checking for overflows e.g. in C++
   <code>constexpr</code> contexts.</li>
@@ -566,7 +569,7 @@
   (suffixed <code>f<i>N</i></code> or <code>f<i>N</i>x</code>) for the
   new
   types: <code>__builtin_copysign</code>, <code>__builtin_fabs</code>, <code>__builtin_huge_val</code>, <code>__builtin_inf</code>, <code>__builtin_nan</code>, <code>__builtin_nans</code>.</p></li>
-  <li>Compilation with <code>-fopenmp</code> is now compatible with
+  <li>Compilation with <code>-fopenmp</code> is now compatible with the
   C11 <code>_Atomic</code> keyword.</li>
 </ul>
 
@@ -730,8 +733,8 @@
   </li>
   <li>Version 4.5 of the <a href="http://www.openmp.org/specifications/"
       >OpenMP specification</a> is now partially supported also in the
-      Fortran compilers, largest missing support in the Fortran frontend
-      is structure element mapping.</li>
+      Fortran compiler; the largest missing item is structure element
+      mapping.</li>
       
   <li>User-defined derived-type input/output (UDTIO) is added.</li>
   
@@ -752,11 +755,13 @@
 <!-- <h3 id="go">Go</h3> -->
 
 <h3 id="java">Java (GCJ)</h3>
+
 <p>The GCC Java frontend and associated libjava runtime library have been
 removed from GCC.</p>
 
 <!-- .................................................................. -->
 <h2 id="jit">libgccjit</h2>
+
 <p>The libgccjit API gained support for marking calls as requiring
 tail-call optimization via a new entrypoint:
 <a href="https://gcc.gnu.org/onlinedocs/jit/topics/expressions.html#gcc_jit_rvalue_set_bool_require_tail_call">gcc_jit_rvalue_set_bool_require_tail_call</a>.</p>
@@ -933,7 +938,8 @@
 <h3 id="nvptx">NVPTX</h3>
 <ul>
   <li>OpenMP target regions can now be offloaded to NVidia PTX GPGPUs.
-      See https://gcc.gnu.org/wiki/Offloading on how to configure it.</li>
+    See the <a href="https://gcc.gnu.org/wiki/Offloading">Wiki on how
+    to configure it</a>.</li>
 </ul>
 
 <h3 id="powerpc">PowerPC / PowerPC64 / RS6000</h3>

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-02-20  5:19         ` Gerald Pfeifer
@ 2017-02-26 14:35           ` Gerald Pfeifer
  2017-02-27 16:39             ` Martin Sebor
  2017-02-27 17:17             ` Martin Jambor
  0 siblings, 2 replies; 20+ messages in thread
From: Gerald Pfeifer @ 2017-02-26 14:35 UTC (permalink / raw)
  To: Jakub Jelinek
  Cc: Segher Boessenkool, Kyrill Tkachov, gcc-patches, Richard Biener,
	Uros Bizjak, Andrew Senkevich

On Sun, 19 Feb 2017, Gerald Pfeifer wrote:
> That was quite a bit; thanks for doing that, Jakub!
> 
> In the patch below I try to streamline language a bit, document options 
> being implied by -Os (in addition to -O2 or higher), fix grammar in a few 
> places, and change a textual link to being a real one.
> 
> I have _not_ applied this yet, and would appreciate your feedback.

I did another two passes through this, making a few more simplifications
and changes, and committed it.

If you see anything beyond it, or changes you disagree with, let me know!

Gerald

Index: gcc-7/changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.66
diff -u -r1.66 changes.html
--- gcc-7/changes.html	24 Feb 2017 05:19:19 -0000	1.66
+++ gcc-7/changes.html	26 Feb 2017 14:19:09 -0000
@@ -50,41 +50,40 @@
     <code>-fprintf-return-value</code> option.</li>
   <li>A new store merging pass has been added.  It merges constant stores to
   adjacent memory locations into fewer, wider, stores.
-  It can be enabled by using the <code>-fstore-merging</code> option and is
-  enabled by default at the <code>-O2</code> optimization
-  level or higher (including <code>-Os</code>).</li>
+  It is enabled by the <code>-fstore-merging</code> option and at the
+  <code>-O2</code> optimization level or higher (and <code>-Os</code>).</li>
 
   <li>A new code hoisting optimization has been added to the partial
   redundancy elimination pass.  It attempts to move evaluation of
   expressions executed on all paths to the function exit as early as
   possible, which helps primarily for code size, but can be useful for
-  speed of generated code as well.  It can be enabled by using the
-  <code>-fcode-hoisting</code> option and is enabled by default at
-  the <code>-O2</code> optimization level or higher.</li>
+  speed of generated code as well.  It is enabled by the
+  <code>-fcode-hoisting</code> option and at the <code>-O2</code>
+  optimization level or higher (and <code>-Os</code>).</li>
 
   <li>A new interprocedural bitwise constant propagation optimization
   has been added, which propagates knowledge about which bits of variables
   are known to be zero (including pointer alignment information) across
-  the call graph.  It can be enabled by using the <code>-fipa-bit-cp</code>
-  option if <code>-fipa-cp</code> is enabled as well, and is enabled by
-  default at the <code>-O2</code> optimization level and higher.</li>
+  the call graph.  It is enabled by the <code>-fipa-bit-cp</code>
+  option if <code>-fipa-cp</code> is enabled as well, and is enabled
+  at the <code>-O2</code> optimization level and higher (and
+  <code>-Os</code>).</li>
 
   <li>A new interprocedural value range propagation optimization has been
   added, which propagates integral ranges that variable values can be proven
-  to be within across the call graph.  It can be enabled by using the
-  <code>-fipa-vrp</code> option and is enabled by default at the
-  <code>-O2</code> optimization level and higher.</li>
+  to be within across the call graph.  It is enabled by the
+  <code>-fipa-vrp</code> option and at the <code>-O2</code> optimization
+  level and higher (and <code>-Os</code>).</li>
 
   <li>A new loop splitting optimization pass has been added.  It splits
   certain loops if they contain a condition that is always true on one
   side of the iteration space and always false on the other into two
   loops where each of the new two loops iterates just on one of the sides
   of the iteration space and the condition does not need to be checked
-  inside of the loop.  It can be enabled by using the
-  <code>-fsplit-loops</code> option and is enabled by default at the
-  <code>-O3</code> optimization level or higher.</li>
+  inside of the loop.  It is enabled by the <code>-fsplit-loops</code>
+  option and at the <code>-O3</code> optimization level or higher.</li>
 
-  <li>Shrink-wrapping optimization can now separate portions of
+  <li>The shrink-wrapping optimization can now separate portions of
   prologues and epilogues to improve performance if some of the
   work done traditionally by prologues and epilogues is not needed
   on certain paths.  This is controlled by the
@@ -138,7 +137,7 @@
   </li>
 
   <li>The <code>-fsanitize=signed-integer-overflow</code> suboption of the
-  UndefinedBehavior Sanitizer now diagnose arithmetic overflows even on
+  UndefinedBehavior Sanitizer now diagnoses arithmetic overflows even on
   arithmetic operations with generic vectors.</li>
 
   <li>Version 5 of the <a
@@ -525,8 +524,8 @@
 <li>New <code>__builtin_add_overflow_p</code>,
   <code>__builtin_sub_overflow_p</code>,
   <code>__builtin_mul_overflow_p</code> built-in functions have been added.
-  These work similarly to earlier added built-in functions without the
-  <code>_p</code> suffix, but don't actually store the result of the
+  These work similarly to their siblings without the
+  <code>_p</code> suffix, but do not actually store the result of the
   arithmetics anywhere, just return whether the operation would overflow.
   These builtins allow easy checking for overflows e.g. in C++
   <code>constexpr</code> contexts.</li>
@@ -566,7 +565,7 @@
   (suffixed <code>f<i>N</i></code> or <code>f<i>N</i>x</code>) for the
   new
   types: <code>__builtin_copysign</code>, <code>__builtin_fabs</code>, <code>__builtin_huge_val</code>, <code>__builtin_inf</code>, <code>__builtin_nan</code>, <code>__builtin_nans</code>.</p></li>
-  <li>Compilation with <code>-fopenmp</code> is now compatible with
+  <li>Compilation with <code>-fopenmp</code> is now compatible with the
   C11 <code>_Atomic</code> keyword.</li>
 </ul>
 
@@ -730,8 +729,8 @@
   </li>
   <li>Version 4.5 of the <a href="http://www.openmp.org/specifications/"
       >OpenMP specification</a> is now partially supported also in the
-      Fortran compilers, largest missing support in the Fortran frontend
-      is structure element mapping.</li>
+      Fortran compiler; the largest missing item is structure element
+      mapping.</li>
       
   <li>User-defined derived-type input/output (UDTIO) is added.</li>
   
@@ -765,11 +764,13 @@
 </ul>
 
 <h3 id="java">Java (GCJ)</h3>
+
 <p>The GCC Java frontend and associated libjava runtime library have been
 removed from GCC.</p>
 
 <!-- .................................................................. -->
 <h2 id="jit">libgccjit</h2>
+
 <p>The libgccjit API gained support for marking calls as requiring
 tail-call optimization via a new entrypoint:
 <a href="https://gcc.gnu.org/onlinedocs/jit/topics/expressions.html#gcc_jit_rvalue_set_bool_require_tail_call">gcc_jit_rvalue_set_bool_require_tail_call</a>.</p>
@@ -946,7 +947,8 @@
 <h3 id="nvptx">NVPTX</h3>
 <ul>
   <li>OpenMP target regions can now be offloaded to NVidia PTX GPGPUs.
-      See https://gcc.gnu.org/wiki/Offloading on how to configure it.</li>
+  See the <a href="https://gcc.gnu.org/wiki/Offloading">Offloading Wiki</a>
+  on how to configure it.</li>
 </ul>
 
 <h3 id="powerpc">PowerPC / PowerPC64 / RS6000</h3>

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-02-26 14:35           ` Gerald Pfeifer
@ 2017-02-27 16:39             ` Martin Sebor
  2017-03-12 23:23               ` Gerald Pfeifer
  2017-02-27 17:17             ` Martin Jambor
  1 sibling, 1 reply; 20+ messages in thread
From: Martin Sebor @ 2017-02-27 16:39 UTC (permalink / raw)
  To: Gerald Pfeifer, Jakub Jelinek
  Cc: Segher Boessenkool, Kyrill Tkachov, gcc-patches, Richard Biener,
	Uros Bizjak, Andrew Senkevich

On 02/26/2017 07:21 AM, Gerald Pfeifer wrote:
> On Sun, 19 Feb 2017, Gerald Pfeifer wrote:
>> That was quite a bit; thanks for doing that, Jakub!
>>
>> In the patch below I try to streamline language a bit, document options
>> being implied by -Os (in addition to -O2 or higher), fix grammar in a few
>> places, and change a textual link to being a real one.
>>
>> I have _not_ applied this yet, and would appreciate your feedback.
>
> I did another two passes through this, making a few more simplifications
> and changes, and committed it.
>
> If you see anything beyond it, or changes you disagree with, let me know!
>
> @@ -525,8 +524,8 @@
>  <li>New <code>__builtin_add_overflow_p</code>,
>    <code>__builtin_sub_overflow_p</code>,
>    <code>__builtin_mul_overflow_p</code> built-in functions have been added.
> -  These work similarly to earlier added built-in functions without the
> -  <code>_p</code> suffix, but don't actually store the result of the
> +  These work similarly to their siblings without the
> +  <code>_p</code> suffix, but do not actually store the result of the
>    arithmetics anywhere, just return whether the operation would overflow.
>    These builtins allow easy checking for overflows e.g. in C++
>    <code>constexpr</code> contexts.</li>

Sorry to be jumping in so late. I only noticed this bit now.

I would suggest to say that these new built-ins evaluate to integer
constant expressions when their arguments do.  Not all C programmers
are familiar with C++ constexpr so they may not understand the use
use case.  The request for these built-ins also came from a C user
and was specifically motivated by avoiding -Woverflow warnings so
adding an example demonstrating that might be helpful as well.
Something like this:

   ... Calls to these built-ins with integer constant arguments
   evaluate to integer constants expressions.</p>
   <p>For example, in the following, <code>c</code> is assigned
   the result of <code>a * b</code> only if the multiplication
   does not overflow, otherwise it is assigned the value zero.
   The multiplication is performed at compile-time and without
   triggering a <code>-Woverflow</code> warning.
   <blockquote>
     <pre>enum {
   a = 12345678,
   b = 87654321,
   c = __builtin_mul_overflow_p (a, b, a) ? 0 : a * b
};</pre>
   </blockquote></li>

Martin

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-02-26 14:35           ` Gerald Pfeifer
  2017-02-27 16:39             ` Martin Sebor
@ 2017-02-27 17:17             ` Martin Jambor
  2017-02-27 22:44               ` Gerald Pfeifer
  1 sibling, 1 reply; 20+ messages in thread
From: Martin Jambor @ 2017-02-27 17:17 UTC (permalink / raw)
  To: Gerald Pfeifer
  Cc: Jakub Jelinek, Segher Boessenkool, Kyrill Tkachov, gcc-patches,
	Richard Biener, Uros Bizjak, Andrew Senkevich

Hello,

On Sun, Feb 26, 2017 at 03:21:20PM +0100, Gerald Pfeifer wrote:
> On Sun, 19 Feb 2017, Gerald Pfeifer wrote:
> > That was quite a bit; thanks for doing that, Jakub!
> > 
> > In the patch below I try to streamline language a bit, document options 
> > being implied by -Os (in addition to -O2 or higher), fix grammar in a few 
> > places, and change a textual link to being a real one.
> > 
> > I have _not_ applied this yet, and would appreciate your feedback.
> 
> I did another two passes through this, making a few more simplifications
> and changes, and committed it.
> 
> If you see anything beyond it, or changes you disagree with, let me know!
> 

on top of your patch, I would like to propose the following.  What do
you think?

Martin


Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.67
diff -u -r1.67 changes.html
--- changes.html	26 Feb 2017 14:21:15 -0000	1.67
+++ changes.html	27 Feb 2017 16:55:31 -0000
@@ -67,7 +67,10 @@
   the call graph.  It is enabled by the <code>-fipa-bit-cp</code>
   option if <code>-fipa-cp</code> is enabled as well, and is enabled
   at the <code>-O2</code> optimization level and higher (and
-  <code>-Os</code>).</li>
+  <code>-Os</code>).  This optimization and its option supersede
+  interprocedural alignment propagation of gcc 6, and therefore the
+  option <code>-fipa-cp-alignment</code> is now deprecated and
+  ignored.</li>
 
   <li>A new interprocedural value range propagation optimization has been
   added, which propagates integral ranges that variable values can be proven

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-02-27 17:17             ` Martin Jambor
@ 2017-02-27 22:44               ` Gerald Pfeifer
  2017-02-28  9:54                 ` Martin Jambor
  0 siblings, 1 reply; 20+ messages in thread
From: Gerald Pfeifer @ 2017-02-27 22:44 UTC (permalink / raw)
  To: Martin Jambor
  Cc: Jakub Jelinek, Segher Boessenkool, Kyrill Tkachov, gcc-patches,
	Richard Biener, Uros Bizjak, Andrew Senkevich

Hi Martin,

at first I was surprised to see two suggestions from -- until I
realized those came from the two (Martins) of you. ;-)

On Mon, 27 Feb 2017, Martin Jambor wrote:
> on top of your patch, I would like to propose the following.  What do 
> you think?
> 
> Index: changes.html
> ===================================================================
> +  <code>-Os</code>).  This optimization and its option supersede
> +  interprocedural alignment propagation of gcc 6, and therefore the
> +  option <code>-fipa-cp-alignment</code> is now deprecated and
> +  ignored.</li>

Make it "GCC 6" (all uppercase) and consider just saying "This
supersedes" or "This optimization supersedes", and I'll think I
like it. :-)

Thanks,
Gerald

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-02-27 22:44               ` Gerald Pfeifer
@ 2017-02-28  9:54                 ` Martin Jambor
  0 siblings, 0 replies; 20+ messages in thread
From: Martin Jambor @ 2017-02-28  9:54 UTC (permalink / raw)
  To: gcc-patches

Hi,

On Mon, Feb 27, 2017 at 02:42:58PM -0800, Gerald Pfeifer wrote:
> Hi Martin,
> 
> at first I was surprised to see two suggestions from -- until I
> realized those came from the two (Martins) of you. ;-)
> 
> On Mon, 27 Feb 2017, Martin Jambor wrote:
> > on top of your patch, I would like to propose the following.  What do 
> > you think?
> > 
> > Index: changes.html
> > ===================================================================
> > +  <code>-Os</code>).  This optimization and its option supersede
> > +  interprocedural alignment propagation of gcc 6, and therefore the
> > +  option <code>-fipa-cp-alignment</code> is now deprecated and
> > +  ignored.</li>
> 
> Make it "GCC 6" (all uppercase) and consider just saying "This
> supersedes" or "This optimization supersedes", and I'll think I
> like it. :-)
> 

thanks for the review, I have committed the following then.

Martin


Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.69
diff -u -r1.69 changes.html
--- changes.html	28 Feb 2017 08:11:56 -0000	1.69
+++ changes.html	28 Feb 2017 09:50:20 -0000
@@ -67,7 +67,10 @@
   the call graph.  It is enabled by the <code>-fipa-bit-cp</code>
   option if <code>-fipa-cp</code> is enabled as well, and is enabled
   at the <code>-O2</code> optimization level and higher (and
-  <code>-Os</code>).</li>
+  <code>-Os</code>).  This optimization supersedes interprocedural
+  alignment propagation of GCC 6, and therefore the
+  option <code>-fipa-cp-alignment</code> is now deprecated and
+  ignored.</li>
 
   <li>A new interprocedural value range propagation optimization has been
   added, which propagates integral ranges that variable values can be proven

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-02-27 16:39             ` Martin Sebor
@ 2017-03-12 23:23               ` Gerald Pfeifer
  2017-03-14 19:43                 ` Martin Sebor
  0 siblings, 1 reply; 20+ messages in thread
From: Gerald Pfeifer @ 2017-03-12 23:23 UTC (permalink / raw)
  To: Martin Sebor
  Cc: Jakub Jelinek, Segher Boessenkool, Kyrill Tkachov, gcc-patches,
	Richard Biener, Uros Bizjak, Andrew Senkevich

Hi Martin,

On Mon, 27 Feb 2017, Martin Sebor wrote:
> Sorry to be jumping in so late. I only noticed this bit now.
> 
> I would suggest to say that these new built-ins evaluate to integer
> constant expressions when their arguments do.  Not all C programmers
> are familiar with C++ constexpr so they may not understand the use
> use case.  The request for these built-ins also came from a C user
> and was specifically motivated by avoiding -Woverflow warnings so
> adding an example demonstrating that might be helpful as well.
> Something like this:
> 
>   ... Calls to these built-ins with integer constant arguments
>   evaluate to integer constants expressions.</p>
>   <p>For example, in the following, <code>c</code> is assigned
>   the result of <code>a * b</code> only if the multiplication
>   does not overflow, otherwise it is assigned the value zero.
>   The multiplication is performed at compile-time and without
>   triggering a <code>-Woverflow</code> warning.

</p>

>   <blockquote>
>     <pre>enum {
>   a = 12345678,
>   b = 87654321,
>   c = __builtin_mul_overflow_p (a, b, a) ? 0 : a * b
> };</pre>
>   </blockquote></li>

this works for me, modulo the closing </p> which I believe will be
necessary.  Were you seeing approval for this from someone?  (If so,
that may not have been me. ;-)

Gerald

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
  2017-03-12 23:23               ` Gerald Pfeifer
@ 2017-03-14 19:43                 ` Martin Sebor
  0 siblings, 0 replies; 20+ messages in thread
From: Martin Sebor @ 2017-03-14 19:43 UTC (permalink / raw)
  To: Gerald Pfeifer
  Cc: Jakub Jelinek, Segher Boessenkool, Kyrill Tkachov, gcc-patches,
	Richard Biener, Uros Bizjak, Andrew Senkevich

On 03/12/2017 05:23 PM, Gerald Pfeifer wrote:
> Hi Martin,
>
> On Mon, 27 Feb 2017, Martin Sebor wrote:
>> Sorry to be jumping in so late. I only noticed this bit now.
>>
>> I would suggest to say that these new built-ins evaluate to integer
>> constant expressions when their arguments do.  Not all C programmers
>> are familiar with C++ constexpr so they may not understand the use
>> use case.  The request for these built-ins also came from a C user
>> and was specifically motivated by avoiding -Woverflow warnings so
>> adding an example demonstrating that might be helpful as well.
>> Something like this:
>>
>>   ... Calls to these built-ins with integer constant arguments
>>   evaluate to integer constants expressions.</p>
>>   <p>For example, in the following, <code>c</code> is assigned
>>   the result of <code>a * b</code> only if the multiplication
>>   does not overflow, otherwise it is assigned the value zero.
>>   The multiplication is performed at compile-time and without
>>   triggering a <code>-Woverflow</code> warning.
>
> </p>
>
>>   <blockquote>
>>     <pre>enum {
>>   a = 12345678,
>>   b = 87654321,
>>   c = __builtin_mul_overflow_p (a, b, a) ? 0 : a * b
>> };</pre>
>>   </blockquote></li>
>
> this works for me, modulo the closing </p> which I believe will be
> necessary.  Were you seeing approval for this from someone?  (If so,
> that may not have been me. ;-)

Thanks.  I just committed it.

Martin

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2017-03-14 19:43 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-27 16:35 [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc Jakub Jelinek
2017-01-27 16:36 ` Kyrill Tkachov
2017-01-27 16:43   ` Jakub Jelinek
2017-01-27 20:32     ` Segher Boessenkool
2017-01-27 21:28       ` Jakub Jelinek
2017-01-27 22:17         ` Segher Boessenkool
2017-02-20  5:19         ` Gerald Pfeifer
2017-02-26 14:35           ` Gerald Pfeifer
2017-02-27 16:39             ` Martin Sebor
2017-03-12 23:23               ` Gerald Pfeifer
2017-03-14 19:43                 ` Martin Sebor
2017-02-27 17:17             ` Martin Jambor
2017-02-27 22:44               ` Gerald Pfeifer
2017-02-28  9:54                 ` Martin Jambor
2017-01-29 12:38 ` Richard Biener
2017-01-29 13:51 ` Prathamesh Kulkarni
2017-01-29 19:28   ` Jakub Jelinek
2017-01-31 11:41     ` Martin Jambor
2017-01-31 16:41       ` Jakub Jelinek
2017-01-31 17:30         ` Martin Jambor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).