[PATCH] For broken exception handling in GDB on AIX platform

[Nitish Kumar Mishra]

Hi,
The patch is for the broken exception handling in GDB on AIX platform.
When linked statically with libstdc++ and libgcc on AIX platform, GDB
is facing broken exception handling issues.
Following is the error output when GDB is linked statically with
mentioned libraries: (GDB-7.12.1, built with GCC-6.2, 64 bit mode, AIX
platform):

# ./gdb
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "powerpc64-ibm-aix7.2.0.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) kill
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
IOT/Abort trap (core dumped)


The issue has been discussed here:
https://sourceware.org/ml/gdb/2017-02/msg00047.html

I have manually built and tested GDB-7.12.1 with this patch on AIX-7.2
and Ubuntu-16.04 with GCC-6.2 and GCC-4.8.5. On both operating system
GDB is working fine with the patch. I generated configure file using
autoconf-2.64.

The attached patch is for configure.ac file in binutils-gdb, in which
one more option "--disable-staticlib" is implemented to link libstdc++
and libgcc dynamically.
I believe this issue is specific to AIX platform.

Please find the attachment for patch file, and ChangeLog file.

Thanks and Regards,
Nitish K Mishra
2016-03-01  Nitish K Mishra  

* configure.ac: Include one more option "--disable-staticlib"
to link libstdc++ and libgcc dynamically.diff --git a/configure.ac b/configure.ac
index 3ec86c1..9bbb024 100644
--- a/configure.ac
+++ b/configure.ac
@@ -471,6 +471,13 @@ ENABLE_LIBSTDCXX=default)
   noconfigdirs="$noconfigdirs target-libstdc++-v3"
 fi]
 
+AC_ARG_ENABLE(staticlib,
+AS_HELP_STRING([--disable-staticlib],
+  [do not link libstdc++ and libgcc library statically]),
+have_static_lib=$enableval,
+have_static_lib=yes)
+
+
 # If this is accelerator compiler and its target is intelmic we enable
 # target liboffloadmic by default.  If this is compiler with offloading
 # for intelmic we enable host liboffloadmic by default.  Otherwise
@@ -1406,9 +1413,10 @@ if test -z "$LD"; then
   fi
 fi
 
-# Check whether -static-libstdc++ -static-libgcc is supported.
-have_static_libs=no
-if test "$GCC" = yes; then
+# If enable_staticlib is set for configuration, check whether -static-libstdc++ -static-libgcc is supported
+
+if test "$have_static_lib" = yes; then
+ if test "$GCC" = yes; then
   saved_LDFLAGS="$LDFLAGS"
 
   LDFLAGS="$LDFLAGS -static-libstdc++ -static-libgcc"
@@ -1424,6 +1432,7 @@ int main() {}],
   AC_LANG_POP(C++)
 
   LDFLAGS="$saved_LDFLAGS"
+ fi
 fi
 
 ACX_PROG_GNAT
@@ -1741,6 +1750,9 @@ AC_ARG_WITH(stage1-ldflags,
  # trust that they are doing what they want.
  if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then
stage1_ldflags="-static-libstdc++ -static-libgcc"
+   else
+  # If static lib is disabled.
+   stage1_ldflags=""
  fi])
 AC_SUBST(stage1_ldflags)
 
@@ -1768,8 +1780,11 @@ AC_ARG_WITH(boot-ldflags,
  # In stages 2 and 3, default to linking libstdc++ and libgcc
  # statically.  But if the user explicitly specified the libraries to
  # use, trust that they are doing what they want.
- if test "$poststage1_libs" = ""; then
+ if test "$poststage1_libs" = "" -a "$have_static_lib" = yes; then
poststage1_ldflags="-static-libstdc++ -static-libgcc"
+   else
+   # If static lib is disabled.
+   poststage1_ldflags=""
  fi])
 AC_SUBST(poststage1_ldflags)
 

Re: PR79715: Special case strcpy/strncpy for dse

[Richard Biener]

On Tue, 28 Feb 2017, Jeff Law wrote:

> On 02/28/2017 05:59 AM, Prathamesh Kulkarni wrote:
> > On 28 February 2017 at 15:40, Jakub Jelinek  wrote:
> > > On Tue, Feb 28, 2017 at 03:33:11PM +0530, Prathamesh Kulkarni wrote:
> > > > Hi,
> > > > The attached patch adds special-casing for strcpy/strncpy to dse pass.
> > > > Bootstrapped+tested on x86_64-unknown-linux-gnu.
> > > > OK for GCC 8 ?
> > > 
> > > What is special on strcpy/strncpy?  Unlike memcpy/memmove/memset, you
> > > don't
> > > know the length they store (at least not in general), you don't know the
> > > value, all you know is that they are for the first argument plain store
> > > without remembering the pointer or anything based on it anywhere except in
> > > the return value.
> > > I believe stpcpy, stpncpy, strcat, strncat at least have the same
> > > behavior.
> > > On the other side, without knowing the length of the store, you can't
> > > treat
> > > it as killing something (ok, some calls like strcpy or stpcpy store at
> > > least
> > > the first byte).
> > Well, I assumed a store to dest by strcpy (and friends), which gets
> > immediately freed would count
> > as a dead store since free would kill the whole memory block pointed
> > to by dest ?
> Yes.  But does it happen often in practice?  I wouldn't mind exploring this
> for gcc-8, but I'd like to see real-world code where this happens.

Actually I don't mind for "real-world code" - the important part is
that I believe it's reasonable to assume it can happen from some C++
abstraction and optimization.

Richard.

Re: [PATCH] Fix vector lowering of VEC_COND_EXPR with VECTOR_BOOLEAN_TYPE_P with scalar mode (PR tree-optimization/79734)

[Richard Biener]

On Tue, 28 Feb 2017, Jakub Jelinek wrote:

> Hi!
> 
> This patch fixes ICE during lowering of VEC_COND_EXPR which has the
> AVX512-ish [QHSD]Imode VECTOR_BOOLEAN_TYPE_P type (where the TYPE_SIZE
> of the comp_inner_type and inner_type are different).
> In addition, it attempts to expand it into efficient code when possible
> (by performing the comparison if any into a [QHSD]Imode VECTOR_BOOLEAN_TYPE_P
> type temporary and then performing bitwise arithmetics).
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok.

Thanks,
Richard.

> 2017-02-28  Jakub Jelinek  
> 
>   PR tree-optimization/79734
>   * tree-vect-generic.c (expand_vector_condition): Optimize
>   AVX512 vector boolean VEC_COND_EXPRs into bitwise operations.
>   Handle VEC_COND_EXPR where comparison has different inner width from
>   type's inner width.
> 
>   * g++.dg/opt/pr79734.C: New test.
> 
> --- gcc/tree-vect-generic.c.jj2017-01-01 12:45:37.0 +0100
> +++ gcc/tree-vect-generic.c   2017-02-28 19:45:26.916621857 +0100
> @@ -865,6 +865,8 @@ expand_vector_condition (gimple_stmt_ite
>tree comp_inner_type = cond_type;
>tree width = TYPE_SIZE (inner_type);
>tree index = bitsize_int (0);
> +  tree comp_width = width;
> +  tree comp_index = index;
>int nunits = TYPE_VECTOR_SUBPARTS (type);
>int i;
>location_t loc = gimple_location (gsi_stmt (*gsi));
> @@ -876,27 +878,60 @@ expand_vector_condition (gimple_stmt_ite
>a1 = TREE_OPERAND (a, 0);
>a2 = TREE_OPERAND (a, 1);
>comp_inner_type = TREE_TYPE (TREE_TYPE (a1));
> +  comp_width = TYPE_SIZE (comp_inner_type);
>  }
>  
>if (expand_vec_cond_expr_p (type, TREE_TYPE (a1), TREE_CODE (a)))
>  return;
>  
> +  /* Handle vector boolean types with bitmasks.  If there is a comparison
> + and we can expand the comparison into the vector boolean bitmask,
> + or otherwise if it is compatible with type, we can transform
> +  vbfld_1 = x_2 < y_3 ? vbfld_4 : vbfld_5;
> + into
> +  tmp_6 = x_2 < y_3;
> +  tmp_7 = tmp_6 & vbfld_4;
> +  tmp_8 = ~tmp_6;
> +  tmp_9 = tmp_8 & vbfld_5;
> +  vbfld_1 = tmp_7 | tmp_9;
> + Similarly for vbfld_10 instead of x_2 < y_3.  */
> +  if (VECTOR_BOOLEAN_TYPE_P (type)
> +  && SCALAR_INT_MODE_P (TYPE_MODE (type))
> +  && (GET_MODE_BITSIZE (TYPE_MODE (type))
> +   < (TYPE_VECTOR_SUBPARTS (type)
> +  * GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (type)
> +  && (a_is_comparison
> +   ? useless_type_conversion_p (type, TREE_TYPE (a))
> +   : expand_vec_cmp_expr_p (TREE_TYPE (a1), type, TREE_CODE (a
> +{
> +  if (a_is_comparison)
> + a = gimplify_build2 (gsi, TREE_CODE (a), type, a1, a2);
> +  a1 = gimplify_build2 (gsi, BIT_AND_EXPR, type, a, b);
> +  a2 = gimplify_build1 (gsi, BIT_NOT_EXPR, type, a);
> +  a2 = gimplify_build2 (gsi, BIT_AND_EXPR, type, a2, c);
> +  a = gimplify_build2 (gsi, BIT_IOR_EXPR, type, a1, a2);
> +  gimple_assign_set_rhs_from_tree (gsi, a);
> +  update_stmt (gsi_stmt (*gsi));
> +  return;
> +}
> +
>/* TODO: try and find a smaller vector type.  */
>  
>warning_at (loc, OPT_Wvector_operation_performance,
> "vector condition will be expanded piecewise");
>  
>vec_alloc (v, nunits);
> -  for (i = 0; i < nunits;
> -   i++, index = int_const_binop (PLUS_EXPR, index, width))
> +  for (i = 0; i < nunits; i++)
>  {
>tree aa, result;
>tree bb = tree_vec_extract (gsi, inner_type, b, width, index);
>tree cc = tree_vec_extract (gsi, inner_type, c, width, index);
>if (a_is_comparison)
>   {
> -   tree aa1 = tree_vec_extract (gsi, comp_inner_type, a1, width, index);
> -   tree aa2 = tree_vec_extract (gsi, comp_inner_type, a2, width, index);
> +   tree aa1 = tree_vec_extract (gsi, comp_inner_type, a1,
> +comp_width, comp_index);
> +   tree aa2 = tree_vec_extract (gsi, comp_inner_type, a2,
> +comp_width, comp_index);
> aa = fold_build2 (TREE_CODE (a), cond_type, aa1, aa2);
>   }
>else
> @@ -904,6 +939,11 @@ expand_vector_condition (gimple_stmt_ite
>result = gimplify_build3 (gsi, COND_EXPR, inner_type, aa, bb, cc);
>constructor_elt ce = {NULL_TREE, result};
>v->quick_push (ce);
> +  index = int_const_binop (PLUS_EXPR, index, width);
> +  if (width == comp_width)
> + comp_index = index;
> +  else
> + comp_index = int_const_binop (PLUS_EXPR, comp_index, comp_width);
>  }
>  
>constr = build_constructor (type, v);
> --- gcc/testsuite/g++.dg/opt/pr79734.C.jj 2017-02-28 19:51:08.123171705 
> +0100
> +++ gcc/testsuite/g++.dg/opt/pr79734.C2017-02-28 19:50:21.0 
> +0100
> @@ -0,0 +1,12 @@
> +// PR tree-optimization/79734
> +// { dg-do compile }
> +// { dg-options "-O2" }
> +// { 

Re: [PATCH docs] remove Java from GCC 7 release criteria

[Richard Biener]

On March 1, 2017 3:34:46 AM GMT+01:00, Martin Sebor  wrote:
>On 02/28/2017 01:41 PM, Richard Biener wrote:
>> On February 28, 2017 7:00:39 PM GMT+01:00, Jeff Law 
>wrote:
>>> On 02/28/2017 10:54 AM, Martin Sebor wrote:
 The GCC 7 release criteria page mentions Java even though
 the front end has been removed.  The attached patch removes Java
 from the criteria page.  While reviewing the rest of the text I
 noticed a few minor typos that I corrected in the patch as well.

 Btw., as an aside, I read the page to see if I could find out more
 about the "magic" bug counts that are being aimed for to decide
>when
 to cut the release.  Can someone say what those are and where to
 find them?  I understand from the document that they're not exact
 but even ballpark numbers would be useful.
>>>
>>> OK.
>>>
>>> WRT the bug counts.  0 P1 regressions, < 100 P1-P3 regressions.  I'm
>>> not
>>> sure if that's documented anywhere though.
>>
>> Actually the only criteria is zero P1 regressions.  Those are
>documented to block a release.
>
>Yes, that is mentioned in the document.  Would it be fair to say
>that the number of P2 bugs (or regressions) or their nature plays
>into the decision in some way as well?  If so, what can the release
>criteria say about it?

Ultimatively P2 bugs do not play a role and 'time' will trump them.  OTOH we 
never were in an uncomfortable situation with P2s at the desired point of 
release.

Also note that important P2 bugs can be promoted to P1 and not important P1 to 
P2.

>I'm trying to get a better idea which bugs to work on and where
>my help might have the biggest impact.  I think having better
>visibility into the bug triage process (such as bug priorities
>and how they impact the release schedule) might help others
>focus too.

In order of importance:
- P1
- wrong-code, rejects-valid, ice-on-valid (even if not regressions, regressions 
more important)
- P2 regressions, more recent ones first (newest working version)
 
Richard.

>Martin

[PATCH], PR target/79434, fix PowerPC recursive calls that can replaced at runtime

[Michael Meissner]

This patch fixes PR target/79439, which is a recursive call when the 64-bit
code is compiled with -fpic doesn't have the NOP after the call.  It is
possible for the function to be overriden at link time.  In such a case, the
call should call the module that is overriding the call, rather than itself.

The following patch was tested on a little endian Power8 Linux system (64-bit
only), a big endian Power8 Linux system (both 32-bit and 64-bit), and a big
endian Power7 Linux system (both 32-bit and 64-bit).  There were no regressions
in the test suite, and I verified that the new test ran successfully in 64-bit
mode.  Can I check this patch into the trunk?

Since the bug was reported against GCC 6, can I apply the patch to GCC 6
assuming the patch applies cleanly and has no regressions after a burn in
period on the GCC 7 trunk?

[gcc]
2017-02-28  Michael Meissner  

PR target/79439
* config/rs6000/predicates.md (current_file_function_operand): Do
not allow self calls to be local if the function is replaceable.

[gcc/testsuite]
2017-02-28  Michael Meissner  

PR target/79439
* gcc.target/powerpc/pr79439.c: New test.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 245787)
+++ gcc/config/rs6000/predicates.md (working copy)
@@ -1110,7 +1110,8 @@ (define_predicate "current_file_function
   (and (match_code "symbol_ref")
(match_test "(DEFAULT_ABI != ABI_AIX || SYMBOL_REF_FUNCTION_P (op))
&& (SYMBOL_REF_LOCAL_P (op)
-   || op == XEXP (DECL_RTL (current_function_decl), 0))
+   || (op == XEXP (DECL_RTL (current_function_decl), 0)
+   && !decl_replaceable_p (current_function_decl)))
&& !((DEFAULT_ABI == ABI_AIX
  || DEFAULT_ABI == ABI_ELFv2)
 && (SYMBOL_REF_EXTERNAL_P (op)
Index: gcc/testsuite/gcc.target/powerpc/pr79439.c
===
--- gcc/testsuite/gcc.target/powerpc/pr79439.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr79439.c  (revision 0)
@@ -0,0 +1,26 @@
+/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-options "-O2 -fpic" } */
+
+/* Bug 79439 -- we should not eliminate NOP in 'rec' call because it can be
+   interposed at link time for 64-bit ABIs.  We need -fpic to tell the compiler
+   functions may be interposed.  */
+
+int f (void);
+
+void
+g (void)
+{
+}
+
+int
+rec (int a)
+{
+  int ret = 0;
+  if (a > 10 && f ())
+ret += rec (a - 1);
+  g ();
+  return a + ret;
+}
+
+/* { dg-final { scan-assembler-times {\mnop\M} 3 } } */

Re: ARC options documentation questions

[Sandra Loosemore]

On 02/24/2017 12:20 PM, Claudiu Zissulescu wrote:

Hi,

Indeed, we are not up to speed regarding updating and cleaning the
documentation.

On 12/02/2017 05:18, Sandra Loosemore wrote:

I noticed a bunch of copy-editing issues in the "ARC Options" section of
invoke.texi.  I'm willing to take a stab at fixing them, but I need some
technical assistance since I'm not familiar with the details of this
architecture myself.

* In e.g. "Compile for ARC 600 cpu with norm instruction enabled." is
"norm" literally the name of an instruction, GCC implementor jargon, or
a term that is used and capitalized like that in the processor
documentation?  Ditto for "mul32x16", "mul64", "LR", "SR", "mpy", "mac",
"mulu64", "swap", "DIV/REM", "MPY", "MPYU", "MPYW", "MPYUW", "MPY_S",
"MPYM", "MPYMU".  For other targets, literal names of instructions are
usually marked up with @code{}, and it would be good to be consistent


All those names are additional instructions support which are not
available in the base ARC configurations. Indeed, we should be
consistent here.


* In "FPX: Generate Double Precision FPX instructions", is "Double
Precision FPX" a proper name literally capitalized like that, or is this
a mistake for "double-precision FPX instructions"?  Likewise for "Single
Precision FPX"?


It is a mistake, we should use lower letters.



* In e.g. the discussion of fpuda_div, is "simple precision" a typo for
"single precision"?  Likewise is "multiple and add" a typo for "multiply
and add"?


Here are typos.


Thanks for the additional clarifications.

I've committed the attached patch, which has a few more cleanups beyond 
the version I posted a couple weeks ago.  It's not perfect, but I think 
it's at least an incremental improvement overall.


-Sandra

2017-02-28  Sandra Loosemore  

	gcc/
	* doc/invoke.texi (ARC Options): Copy-edit to fix punctuation,
	markup, and similar issues.  Remove @opindex entries for things
	that aren't options.  Add missing -mmpy-option entries.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 245794)
+++ gcc/doc/invoke.texi	(working copy)
@@ -14248,70 +14248,58 @@ Compile for ARC EM.
 Compile for ARC HS.
 
 @item em
-@opindex em
-Compile for ARC EM cpu with no hardware extension.
+Compile for ARC EM CPU with no hardware extensions.
 
 @item em4
-@opindex em4
-Compile for ARC EM4 cpu.
+Compile for ARC EM4 CPU.
 
 @item em4_dmips
-@opindex em4_dmips
-Compile for ARC EM4 DMIPS cpu.
+Compile for ARC EM4 DMIPS CPU.
 
 @item em4_fpus
-@opindex em4_fpus
-Compile for ARC EM4 DMIPS cpu with single precision floating point
+Compile for ARC EM4 DMIPS CPU with the single-precision floating-point
 extension.
 
 @item em4_fpuda
-@opindex em4_fpuda
-Compile for ARC EM4 DMIPS cpu with single precision floating point and
-double assists instructions.
+Compile for ARC EM4 DMIPS CPU with single-precision floating-point and
+double assist instructions.
 
 @item hs
-@opindex hs
-Compile for ARC HS cpu with no hardware extension, except the atomic
+Compile for ARC HS CPU with no hardware extensions except the atomic
 instructions.
 
 @item hs34
-@opindex hs34
-Compile for ARC HS34 cpu.
+Compile for ARC HS34 CPU.
 
 @item hs38
-@opindex hs38
-Compile for ARC HS38 cpu.
+Compile for ARC HS38 CPU.
 
 @item hs38_linux
-@opindex hs38_linux
-Compile for ARC HS38 cpu with all hardware extensions on.
+Compile for ARC HS38 CPU with all hardware extensions on.
 
 @item arc600_norm
-@opindex arc600_norm
-Compile for ARC 600 cpu with norm instruction enabled.
+Compile for ARC 600 CPU with @code{norm} instructions enabled.
 
 @item arc600_mul32x16
-@opindex arc600_mul32x16
-Compile for ARC 600 cpu with norm and mul32x16 instructions enabled.
+Compile for ARC 600 CPU with @code{norm} and 32x16-bit multiply 
+instructions enabled.
 
 @item arc600_mul64
-@opindex arc600_mul64
-Compile for ARC 600 cpu with norm and mul64 instructions enabled.
+Compile for ARC 600 CPU with @code{norm} and @code{mul64}-family 
+instructions enabled.
 
 @item arc601_norm
-@opindex arc601_norm
-Compile for ARC 601 cpu with norm instruction enabled.
+Compile for ARC 601 CPU with @code{norm} instructions enabled.
 
 @item arc601_mul32x16
-@opindex arc601_mul32x16
-Compile for ARC 601 cpu with norm and mul32x16 instructions enabled.
+Compile for ARC 601 CPU with @code{norm} and 32x16-bit multiply
+instructions enabled.
 
 @item arc601_mul64
-@opindex arc601_mul64
-Compile for ARC 601 cpu with norm and mul64 instructions enabled.
+Compile for ARC 601 CPU with @code{norm} and @code{mul64}-family
+instructions enabled.
 
 @item nps400
-@opindex nps400
 Compile for ARC 700 on NPS400 chip.
 
 @end table
@@ -14320,52 +14308,54 @@ Compile for ARC 700 on NPS400 chip.
 @opindex mdpfp
 @itemx -mdpfp-compact
 @opindex mdpfp-compact
-FPX: Generate Double Precision FPX instructions, tuned for the compact
+Generate double-precision FPX instructions, tuned for the 

Re: [PATCH docs] remove Java from GCC 7 release criteria

[Martin Sebor]

On 02/28/2017 01:41 PM, Richard Biener wrote:

On February 28, 2017 7:00:39 PM GMT+01:00, Jeff Law  wrote:

On 02/28/2017 10:54 AM, Martin Sebor wrote:

The GCC 7 release criteria page mentions Java even though
the front end has been removed.  The attached patch removes Java
from the criteria page.  While reviewing the rest of the text I
noticed a few minor typos that I corrected in the patch as well.

Btw., as an aside, I read the page to see if I could find out more
about the "magic" bug counts that are being aimed for to decide when
to cut the release.  Can someone say what those are and where to
find them?  I understand from the document that they're not exact
but even ballpark numbers would be useful.


OK.

WRT the bug counts.  0 P1 regressions, < 100 P1-P3 regressions.  I'm
not
sure if that's documented anywhere though.


Actually the only criteria is zero P1 regressions.  Those are documented to 
block a release.


Yes, that is mentioned in the document.  Would it be fair to say
that the number of P2 bugs (or regressions) or their nature plays
into the decision in some way as well?  If so, what can the release
criteria say about it?

I'm trying to get a better idea which bugs to work on and where
my help might have the biggest impact.  I think having better
visibility into the bug triage process (such as bug priorities
and how they impact the release schedule) might help others
focus too.

Martin

Re: [PATCH,rs6000] PR79395: Fix compile error with -mcpu=power9 and -mno-vsx and __builtin_vec_cmpne_p

[Segher Boessenkool]

Hi Kelvin,

On Tue, Feb 28, 2017 at 03:46:20PM -0700, Kelvin Nilsen wrote:
> PR 79395 reports a problem that arises when the preprocessor believes
> that the target supports Power9 but the gcc compiler believes that
> Power9 is not supported.
> 
> This patch addresses this inconsistency by introducing a new
> preprocessor macro named __POWER9_VECTOR__ which is automatically
> defined if the current gcc configuration, as adjusted by gcc command
> line options, supports Power9.  Previously, certain macro definitions
> that were supplied in altivec.h were conditioned upon the _ARCH_PWR9
> macro, which represents statically whether the compiler can support
> Power9, but ignores any command-line options that might disable the
> Power9 support in this run of the compiler.  Also addressed in this
> patch is elimination of the xvcmpnesp and xvcmpnedp instructions, which
> are not currently supported.  

I don't like this much at all.  We should not have command line options
to disable random instructions.  In a sane world we could just test for
_ARCH_PWR9 and VSX instead of having this error-prone combinatorial
explosion of macros.

> This patch has been demonstrated to fix the problems identified in the
> test case mentioned in the PR 79395 report.
> 
> This patch has been bootstrapped and tested on
> powerpc64le-unknown-linux with no regressions.
> 
> Is this ok for trunk?

Okay.  Some trivial comments:


>   PR target/79395
>   * config/rs6000/altivec.h (vec_ctz and others): Change the
>   preprocessor macro that controls conditional compilation from
>   _ARCH_PWR9 to __POWER9_VECTOR.

It is __POWER9_VECTOR__.

>   (vec_all_ne): Change macro definition to use a power9-specific
>   expansion under #ifdef __POWER9_VECTOR CONTROL (instead of
>   _ARCH_PWR9 control).

Same; and you don't want to SHOUT control I think ;-)

>   * config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Add
>   support for predefined __POWER9_VECTOR__ macro to indicate that
>   Power9 instruction selection is enabled.
>   (altivec_overloaded_builtins): Remove extraneous
>   ALTIVEC_BUILTIN_VEC_CMPNE entry for overloaded 

Trailing space.

>   Power9 for impelmentations of vec_cmpne.  Change the signature for

s/impel/imple/

> @@ -521,9 +521,9 @@ __altivec_scalar_pred(vec_all_nez,
>  __altivec_scalar_pred(vec_any_eqz,
>__builtin_vec_vcmpnez_p (__CR6_LT_REV, a1, a2))
>  __altivec_scalar_pred(vec_all_ne,
> -  __builtin_vec_vcmpne_p (__CR6_LT, a1, a2))
> +   __builtin_vec_allne_p (a1, a2))
>  __altivec_scalar_pred(vec_any_eq,
> -  __builtin_vec_vcmpne_p (__CR6_LT_REV, a1, a2))
> +   __builtin_vec_anyeq_p (a1, a2))
>  #endif

Please indent these the same as the surrounding code.

Thanks,


Segher

Re: [C++ PATCH] Fix -Wunused-but-set-parameter in ctors of some abstract classes (PR c++/79746)

[Nathan Sidwell]

On 02/28/2017 02:41 PM, Jason Merrill wrote:

On Tue, Feb 28, 2017 at 12:48 PM, Jakub Jelinek  wrote:

The DR1659/DR1611 changes result in construct_virtual_base not being called,
but unfortunately the call generated in there was the spot that caused
mark_exp_read on the arguments passed to the vbase construction (TREE_USED
is set on these earlier already during parsing them).  That results
in false positive -Wunused-but-set-parameter warnings.

The following patch tries to avoid the warning in that case by marking
the arguments as read (essentially pretending they were read in the omitted
call).  Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?


I believe there's some question still about whether the DR1659/11
changes are what we want; I'll defer to Nathan on this patch.


Jakub's patch is OK.  The defect I've reported is how 1658 interacts with 
virtual destructors. (bug 79393)


nathan
--
Nathan Sidwell

Re: [C++ PATCH] Fix -Wunused-but-set-parameter in ctors of some abstract classes (PR c++/79746)

[Jason Merrill]

On Tue, Feb 28, 2017 at 12:48 PM, Jakub Jelinek  wrote:
> The DR1659/DR1611 changes result in construct_virtual_base not being called,
> but unfortunately the call generated in there was the spot that caused
> mark_exp_read on the arguments passed to the vbase construction (TREE_USED
> is set on these earlier already during parsing them).  That results
> in false positive -Wunused-but-set-parameter warnings.
>
> The following patch tries to avoid the warning in that case by marking
> the arguments as read (essentially pretending they were read in the omitted
> call).  Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

I believe there's some question still about whether the DR1659/11
changes are what we want; I'll defer to Nathan on this patch.

Jason

> 2017-02-28  Jakub Jelinek  
>
> PR c++/79746
> * init.c (emit_mem_initializers): When not constructing vbases of
> abstract classes, mark arguments as read for
> -Wunused-but-set-parameter.
>
> * g++.dg/warn/Wunused-parm-9.C: New test.
>
> --- gcc/cp/init.c.jj2017-02-28 16:24:05.0 +0100
> +++ gcc/cp/init.c   2017-02-28 21:08:29.158380881 +0100
> @@ -1217,6 +1217,12 @@ emit_mem_initializers (tree mem_inits)
> /* C++14 DR1658 Means we do not have to construct vbases of
>abstract classes.  */
> construct_virtual_base (subobject, arguments);
> +  else
> +   /* When not constructing vbases of abstract classes, at least mark
> +  the arguments expressions as read to avoid
> +  -Wunused-but-set-parameter false positives.  */
> +   for (tree arg = arguments; arg; arg = TREE_CHAIN (arg))
> + mark_exp_read (TREE_VALUE (arg));
>
>if (inherited_base)
> pop_deferring_access_checks ();
> --- gcc/testsuite/g++.dg/warn/Wunused-parm-9.C.jj   2017-02-28 
> 21:11:44.989820368 +0100
> +++ gcc/testsuite/g++.dg/warn/Wunused-parm-9.C  2017-02-28 21:10:43.0 
> +0100
> @@ -0,0 +1,12 @@
> +// PR c++/79746
> +// { dg-do compile }
> +// { dg-options "-Wunused-but-set-parameter" }
> +
> +struct A {
> +  A (const char *x) : a(x) {}  // { dg-bogus "set but not used" }
> +  virtual int foo () = 0;
> +  const char *a;
> +};
> +struct B : public virtual A {
> +  B (const char *x) : A(x) {}  // { dg-bogus "set but not used" }
> +};
>
> Jakub

Re: [PATCH][PR target/79752] fix rs6000 power9 peephole2 for udiv/umod

[Segher Boessenkool]

On Tue, Feb 28, 2017 at 04:02:00PM -0600, Aaron Sawdey wrote:
> This showed up in power9 code for __divkf3 software float support and
> caused a divd to be emitted where we needed a divdu. OK for trunk if
> bootstrap/regtest passes?

Yes, certainly.  Thanks!


Segher


> --- ../trunk/gcc/config/rs6000/rs6000.md(revision 245787)
> +++ ../trunk/gcc/config/rs6000/rs6000.md(working copy)
> @@ -3161,7 +3161,7 @@
> && ! reg_mentioned_p (operands[3], operands[1])
> && ! reg_mentioned_p (operands[3], operands[2])"
>    [(set (match_dup 0)
> -   (div:GPR (match_dup 1)
> +   (udiv:GPR (match_dup 1)
>  (match_dup 2)))
> (set (match_dup 3)
> (mult:GPR (match_dup 0)
> 
> 2017-02-28  Aaron Sawdey  
> 
>   PR target/79752
>   * config/rs6000/rs6000.md (peephole2 for udiv/umod): Should emit
>   udiv rather than div since input pattern is unsigned.

C++ PATCH for C++17 class template argument deduction issues

[Jason Merrill]

This patch implements some proposed resolutions to open issues with
C++17 class template argument deduction.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 5486547c53bf6e83bcdd822b2f9cdce171d115b0
Author: Jason Merrill 
Date:   Tue Feb 28 07:45:04 2017 -1000

Class template argument deduction refinements

* call.c (joust): Move deduction guide tiebreaker down.
* decl.c (start_decl_1, cp_finish_decl, grokdeclarator): Allow class
deduction with no initializer.
* pt.c (build_deduction_guide): Handle implicit default/copy ctor.
(do_class_deduction): Use that rather than special case.
(do_auto_deduction): Handle null initializer.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 560804a..babab00 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -9670,18 +9670,6 @@ joust (struct z_candidate *cand1, struct z_candidate 
*cand2, bool warn,
return winner;
 }
 
-  /* F1 is generated from a deduction-guide (13.3.1.8) and F2 is not */
-  if (deduction_guide_p (cand1->fn))
-{
-  gcc_assert (deduction_guide_p (cand2->fn));
-  /* We distinguish between candidates from an explicit deduction guide and
-candidates built from a constructor based on DECL_ARTIFICIAL.  */
-  int art1 = DECL_ARTIFICIAL (cand1->fn);
-  int art2 = DECL_ARTIFICIAL (cand2->fn);
-  if (art1 != art2)
-   return art2 - art1;
-}
-
   /* or, if not that,
  F1 is a non-template function and F2 is a template function
  specialization.  */
@@ -9719,6 +9707,18 @@ joust (struct z_candidate *cand1, struct z_candidate 
*cand2, bool warn,
return winner;
 }
 
+  /* F1 is generated from a deduction-guide (13.3.1.8) and F2 is not */
+  if (deduction_guide_p (cand1->fn))
+{
+  gcc_assert (deduction_guide_p (cand2->fn));
+  /* We distinguish between candidates from an explicit deduction guide and
+candidates built from a constructor based on DECL_ARTIFICIAL.  */
+  int art1 = DECL_ARTIFICIAL (cand1->fn);
+  int art2 = DECL_ARTIFICIAL (cand2->fn);
+  if (art1 != art2)
+   return art2 - art1;
+}
+
   /* or, if not that, F2 is from a using-declaration, F1 is not, and the
  conversion sequences are equivalent.
  (proposed in http://lists.isocpp.org/core/2016/10/1142.php) */
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 54cbbb7..3e7316f 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -5238,13 +5238,15 @@ start_decl_1 (tree decl, bool initialized)
   else if (aggregate_definition_p && !complete_p)
 {
   if (type_uses_auto (type))
-   gcc_unreachable ();
+   gcc_assert (CLASS_PLACEHOLDER_TEMPLATE (type));
   else
-   error ("aggregate %q#D has incomplete type and cannot be defined",
-  decl);
-  /* Change the type so that assemble_variable will give
-DECL an rtl we can live with: (mem (const_int 0)).  */
-  type = TREE_TYPE (decl) = error_mark_node;
+   {
+ error ("aggregate %q#D has incomplete type and cannot be defined",
+decl);
+ /* Change the type so that assemble_variable will give
+DECL an rtl we can live with: (mem (const_int 0)).  */
+ type = TREE_TYPE (decl) = error_mark_node;
+   }
 }
 
   /* Create a new scope to hold this declaration if necessary.
@@ -6816,14 +6818,17 @@ cp_finish_decl (tree decl, tree init, bool 
init_const_expr_p,
  return;
}
 
- gcc_unreachable ();
+ gcc_assert (CLASS_PLACEHOLDER_TEMPLATE (auto_node));
}
   d_init = init;
-  if (TREE_CODE (d_init) == TREE_LIST
- && !CLASS_PLACEHOLDER_TEMPLATE (auto_node))
-   d_init = build_x_compound_expr_from_list (d_init, ELK_INIT,
- tf_warning_or_error);
-  d_init = resolve_nondeduced_context (d_init, tf_warning_or_error);
+  if (d_init)
+   {
+ if (TREE_CODE (d_init) == TREE_LIST
+ && !CLASS_PLACEHOLDER_TEMPLATE (auto_node))
+   d_init = build_x_compound_expr_from_list (d_init, ELK_INIT,
+ tf_warning_or_error);
+ d_init = resolve_nondeduced_context (d_init, tf_warning_or_error);
+   }
   enum auto_deduction_context adc = adc_variable_type;
   if (VAR_P (decl) && DECL_DECOMPOSITION_P (decl))
adc = adc_decomp_type;
@@ -12323,19 +12328,12 @@ grokdeclarator (const cp_declarator *declarator,
 
 if (VAR_P (decl) && !initialized)
   if (tree auto_node = type_uses_auto (type))
-   {
- location_t loc = declspecs->locations[ds_type_spec];
- if (tree tmpl = CLASS_PLACEHOLDER_TEMPLATE (auto_node))
-   {
- error_at (loc, "invalid use of template-name %qE without an "
-   "argument list", tmpl);
- inform (loc, "class template argument deduction "
- 

Re: C++ PATCH to fix wrong-code with pointer-to-data-members (PR c++/79687)

[Jason Merrill]

On Tue, Feb 28, 2017 at 10:10 AM, Marek Polacek  wrote:
> On Fri, Feb 24, 2017 at 11:11:05AM -0800, Jason Merrill wrote:
>> On Fri, Feb 24, 2017 at 8:22 AM, Marek Polacek  wrote:
>> > I had an interesting time tracking down some of the problems with this 
>> > code.
>> > Hopefully I've sussed out now how this stuff works.
>> >
>> > We've got
>> >
>> > struct A { char c; };
>> > char A::*p = ::c;
>> > static char A::*const q = p;
>> > and then
>> > &(a.*q) - 
>> > which should evaluate to 0.  Here "p" will be 0, that's the offset from the
>> > start of the struct to "c".  "q" is const-qualified and static and 
>> > initialized
>> > with "p", so we get to cp_fold_maybe_rvalue -> decl_constant_value ->
>> > constant_value_1.  Now, NULL pointer-to-data-members are represented by 
>> > -1, so
>> > that a null pointer is distinguishable from an offset of the first member 
>> > of a
>> > struct (0).  So constant_value_1 looks at the DECL_INITIAL of "q", which 
>> > is -1,
>> > a constant, we fold "q" to -1, and sadness ensues.  I believe the -1 value 
>> > is
>> > only an internal representation and shouldn't be used like that.
>>
>> Since q is initialized from p, it shouldn't have a DECL_INITIAL of -1;
>> that sounds like the bug.
>
> The DECL_INITIAL of -1 comes from cp_finish_decl:
>  7038  The memory occupied by any object of static storage
>  7039  duration is zero-initialized at program startup before
>  7040  any other initialization takes place.
>  7041
>  7042  We cannot create an appropriate initializer until after
>  7043  the type of DECL is finalized.  If DECL_INITIAL is set,
>  7044  then the DECL is statically initialized, and any
>  7045  necessary zero-initialization has already been performed.  
> */
>  7046   if (TREE_STATIC (decl) && !DECL_INITIAL (decl))
>  7047 DECL_INITIAL (decl) = build_zero_init (TREE_TYPE (decl),
>  7048/*nelts=*/NULL_TREE,
>  7049
> /*static_storage_p=*/true);

Ah, that makes sense.  We do want to do constant-initialization with
-1 before we do dynamic initialization with p.

So we need to detect in constant_value_1 that the variable has a
dynamic initializer and therefore return the variable rather than -1.
DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P seems useful, perhaps in
combination with DECL_NONTRIVIALLY_INITIALIZED.

Jason

[C++ PATCH] Fix -Wunused-but-set-parameter in ctors of some abstract classes (PR c++/79746)

[Jakub Jelinek]

Hi!

The DR1659/DR1611 changes result in construct_virtual_base not being called,
but unfortunately the call generated in there was the spot that caused
mark_exp_read on the arguments passed to the vbase construction (TREE_USED
is set on these earlier already during parsing them).  That results
in false positive -Wunused-but-set-parameter warnings.

The following patch tries to avoid the warning in that case by marking
the arguments as read (essentially pretending they were read in the omitted
call).  Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2017-02-28  Jakub Jelinek  

PR c++/79746
* init.c (emit_mem_initializers): When not constructing vbases of
abstract classes, mark arguments as read for
-Wunused-but-set-parameter.

* g++.dg/warn/Wunused-parm-9.C: New test.

--- gcc/cp/init.c.jj2017-02-28 16:24:05.0 +0100
+++ gcc/cp/init.c   2017-02-28 21:08:29.158380881 +0100
@@ -1217,6 +1217,12 @@ emit_mem_initializers (tree mem_inits)
/* C++14 DR1658 Means we do not have to construct vbases of
   abstract classes.  */
construct_virtual_base (subobject, arguments);
+  else
+   /* When not constructing vbases of abstract classes, at least mark
+  the arguments expressions as read to avoid
+  -Wunused-but-set-parameter false positives.  */
+   for (tree arg = arguments; arg; arg = TREE_CHAIN (arg))
+ mark_exp_read (TREE_VALUE (arg));
 
   if (inherited_base)
pop_deferring_access_checks ();
--- gcc/testsuite/g++.dg/warn/Wunused-parm-9.C.jj   2017-02-28 
21:11:44.989820368 +0100
+++ gcc/testsuite/g++.dg/warn/Wunused-parm-9.C  2017-02-28 21:10:43.0 
+0100
@@ -0,0 +1,12 @@
+// PR c++/79746
+// { dg-do compile }
+// { dg-options "-Wunused-but-set-parameter" }
+
+struct A {
+  A (const char *x) : a(x) {}  // { dg-bogus "set but not used" }
+  virtual int foo () = 0;
+  const char *a;
+};
+struct B : public virtual A {
+  B (const char *x) : A(x) {}  // { dg-bogus "set but not used" }
+};

Jakub

[PATCH,rs6000] PR79395: Fix compile error with -mcpu=power9 and -mno-vsx and __builtin_vec_cmpne_p

[Kelvin Nilsen]

PR 79395 reports a problem that arises when the preprocessor believes
that the target supports Power9 but the gcc compiler believes that
Power9 is not supported.

This patch addresses this inconsistency by introducing a new
preprocessor macro named __POWER9_VECTOR__ which is automatically
defined if the current gcc configuration, as adjusted by gcc command
line options, supports Power9.  Previously, certain macro definitions
that were supplied in altivec.h were conditioned upon the _ARCH_PWR9
macro, which represents statically whether the compiler can support
Power9, but ignores any command-line options that might disable the
Power9 support in this run of the compiler.  Also addressed in this
patch is elimination of the xvcmpnesp and xvcmpnedp instructions, which
are not currently supported.  

This patch has been demonstrated to fix the problems identified in the
test case mentioned in the PR 79395 report.

This patch has been bootstrapped and tested on
powerpc64le-unknown-linux with no regressions.

Is this ok for trunk?

gcc/ChangeLog:

2017-02-28  Kelvin Nilsen  

PR target/79395
* config/rs6000/altivec.h (vec_ctz and others): Change the
preprocessor macro that controls conditional compilation from
_ARCH_PWR9 to __POWER9_VECTOR.
(vec_all_ne): Change parameterization of __altivec_scalar_pred
macro expansion under preprocessor #ifdef __POWER9_VECTOR__
control (instead of _ARCH_PWR9 control) so that template
definition uses power9-specific function.
(vec_any_eq): Likewise.
(vec_all_ne): Change macro definition to use a power9-specific
expansion under #ifdef __POWER9_VECTOR CONTROL (instead of
_ARCH_PWR9 control).
(vec_any_eq) Likewise.
* config/rs6000/rs6000-builtin.def (CMPNEF): Remove BU_P9V_AV_2
expansion for CMPNEF to remove support for xvcmpnesp instruction.
(CMPNED): Remove BU_P9V_AV2 expansion for CMPNED to remove
support for xvcmpnedp instruction.
(VCMPNEB_P): Replace BU_P9V_AV_P macro expansion with BU_P9V_AV_2
macro expansion so that Power9 implementation of vec_all_ne does
not use the AltiVec predicate framework.
(VCMPNEH_P): Likewise.
(VCMPNEW_P): Likewise.
(VCMPNED_P): Likewise.
(VCMPNEFP_P): Likewise.
(VCMPNEDP_P): Likewise.
(VCMPAEB_P): Add BU_P9V_AV_2 macro expansion to change
implementation of vec_any_eq to not use AltiVec predicate
framework.
(VCMPAEH_P): Likewise.
(VCMPAEW_P): Likewise.
(VCMPAED_P): Likewise.
(VCMPAEFP_P): Likewise.
(VCMPAEDP_P): Likewise.
(VCMPNE_P): Replace BU_P9V_OVERLOAD_P macro expansion with
BU_P9V_OVERLOAD_2 so that Power9 implementation of vec_all_ne does
not use the AltiVec predicate framework.
(VCMPAE_P): Add BU_P9V_OVERLOAD_2 macro to change implementation
of vec_any_eq to not use AltiVec predicate framework.
* config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Add
support for predefined __POWER9_VECTOR__ macro to indicate that
Power9 instruction selection is enabled.
(altivec_overloaded_builtins): Remove extraneous
ALTIVEC_BUILTIN_VEC_CMPNE entry for overloaded 
function argument types RS6000_BTI_bool_V16QI and
RS6000_BTI_bool_V16QI.  Remove erroneous ALTIVEC_BUILTIN_VEC_CMPNE
entry for overloaded function argument types RS6000_BTI_bool_V4SI
andRS6000_BTI_bool_V4SI, mapping to P9V_BUILTIN_CMPNEB.  Remove
two entries mapping to P9V_BUITIN_CMPNED and one entry mapping to
P9V_BUILTIN_CMPNEF to force use of instructions not specific to
Power9 for impelmentations of vec_cmpne.  Change the signature for
all definitions of the overloaded P9V_BUILTIN_VEC_CMPNE_P function
(representing vec_all_ne) to remove the previously described first
argument of type RS6000_BTI_INTSI, as this was an artifact of
reliance on the AltiVec predicate framework, which is no longer
used in the implementation of these functions.  Add
P9V_BUILTIN_VEC_VCMPAE_P entries (representing the vec_anyeq
function) to match all of the P9V_BUILTIN_VEC_VCMNE_P entries
since, unlike the AltiVec predicate framework implementation, we
do not share function descriptors between vec_alle and vec_anyeq.
(altivec_resolve_overloaded_builtin): Add SFmode and DFmode to the
set of modes that receive special treatment even when
TARGET_P9_VECTOR is true.  The special treatment emits code that
does not depend on Power9 instructions.
* config/rs6000/vector.md (vector_ne__p): Change this
define_expand to not rely on AltiVec predicate framework.
(vector_ae_p): New define_expand to represent vec_any_eq
function.
(vector_ne_v2di_p): Change this define_expand to 

[PATCH] Fix vector lowering of VEC_COND_EXPR with VECTOR_BOOLEAN_TYPE_P with scalar mode (PR tree-optimization/79734)

[Jakub Jelinek]

Hi!

This patch fixes ICE during lowering of VEC_COND_EXPR which has the
AVX512-ish [QHSD]Imode VECTOR_BOOLEAN_TYPE_P type (where the TYPE_SIZE
of the comp_inner_type and inner_type are different).
In addition, it attempts to expand it into efficient code when possible
(by performing the comparison if any into a [QHSD]Imode VECTOR_BOOLEAN_TYPE_P
type temporary and then performing bitwise arithmetics).

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2017-02-28  Jakub Jelinek  

PR tree-optimization/79734
* tree-vect-generic.c (expand_vector_condition): Optimize
AVX512 vector boolean VEC_COND_EXPRs into bitwise operations.
Handle VEC_COND_EXPR where comparison has different inner width from
type's inner width.

* g++.dg/opt/pr79734.C: New test.

--- gcc/tree-vect-generic.c.jj  2017-01-01 12:45:37.0 +0100
+++ gcc/tree-vect-generic.c 2017-02-28 19:45:26.916621857 +0100
@@ -865,6 +865,8 @@ expand_vector_condition (gimple_stmt_ite
   tree comp_inner_type = cond_type;
   tree width = TYPE_SIZE (inner_type);
   tree index = bitsize_int (0);
+  tree comp_width = width;
+  tree comp_index = index;
   int nunits = TYPE_VECTOR_SUBPARTS (type);
   int i;
   location_t loc = gimple_location (gsi_stmt (*gsi));
@@ -876,27 +878,60 @@ expand_vector_condition (gimple_stmt_ite
   a1 = TREE_OPERAND (a, 0);
   a2 = TREE_OPERAND (a, 1);
   comp_inner_type = TREE_TYPE (TREE_TYPE (a1));
+  comp_width = TYPE_SIZE (comp_inner_type);
 }
 
   if (expand_vec_cond_expr_p (type, TREE_TYPE (a1), TREE_CODE (a)))
 return;
 
+  /* Handle vector boolean types with bitmasks.  If there is a comparison
+ and we can expand the comparison into the vector boolean bitmask,
+ or otherwise if it is compatible with type, we can transform
+  vbfld_1 = x_2 < y_3 ? vbfld_4 : vbfld_5;
+ into
+  tmp_6 = x_2 < y_3;
+  tmp_7 = tmp_6 & vbfld_4;
+  tmp_8 = ~tmp_6;
+  tmp_9 = tmp_8 & vbfld_5;
+  vbfld_1 = tmp_7 | tmp_9;
+ Similarly for vbfld_10 instead of x_2 < y_3.  */
+  if (VECTOR_BOOLEAN_TYPE_P (type)
+  && SCALAR_INT_MODE_P (TYPE_MODE (type))
+  && (GET_MODE_BITSIZE (TYPE_MODE (type))
+ < (TYPE_VECTOR_SUBPARTS (type)
+* GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (type)
+  && (a_is_comparison
+ ? useless_type_conversion_p (type, TREE_TYPE (a))
+ : expand_vec_cmp_expr_p (TREE_TYPE (a1), type, TREE_CODE (a
+{
+  if (a_is_comparison)
+   a = gimplify_build2 (gsi, TREE_CODE (a), type, a1, a2);
+  a1 = gimplify_build2 (gsi, BIT_AND_EXPR, type, a, b);
+  a2 = gimplify_build1 (gsi, BIT_NOT_EXPR, type, a);
+  a2 = gimplify_build2 (gsi, BIT_AND_EXPR, type, a2, c);
+  a = gimplify_build2 (gsi, BIT_IOR_EXPR, type, a1, a2);
+  gimple_assign_set_rhs_from_tree (gsi, a);
+  update_stmt (gsi_stmt (*gsi));
+  return;
+}
+
   /* TODO: try and find a smaller vector type.  */
 
   warning_at (loc, OPT_Wvector_operation_performance,
  "vector condition will be expanded piecewise");
 
   vec_alloc (v, nunits);
-  for (i = 0; i < nunits;
-   i++, index = int_const_binop (PLUS_EXPR, index, width))
+  for (i = 0; i < nunits; i++)
 {
   tree aa, result;
   tree bb = tree_vec_extract (gsi, inner_type, b, width, index);
   tree cc = tree_vec_extract (gsi, inner_type, c, width, index);
   if (a_is_comparison)
{
- tree aa1 = tree_vec_extract (gsi, comp_inner_type, a1, width, index);
- tree aa2 = tree_vec_extract (gsi, comp_inner_type, a2, width, index);
+ tree aa1 = tree_vec_extract (gsi, comp_inner_type, a1,
+  comp_width, comp_index);
+ tree aa2 = tree_vec_extract (gsi, comp_inner_type, a2,
+  comp_width, comp_index);
  aa = fold_build2 (TREE_CODE (a), cond_type, aa1, aa2);
}
   else
@@ -904,6 +939,11 @@ expand_vector_condition (gimple_stmt_ite
   result = gimplify_build3 (gsi, COND_EXPR, inner_type, aa, bb, cc);
   constructor_elt ce = {NULL_TREE, result};
   v->quick_push (ce);
+  index = int_const_binop (PLUS_EXPR, index, width);
+  if (width == comp_width)
+   comp_index = index;
+  else
+   comp_index = int_const_binop (PLUS_EXPR, comp_index, comp_width);
 }
 
   constr = build_constructor (type, v);
--- gcc/testsuite/g++.dg/opt/pr79734.C.jj   2017-02-28 19:51:08.123171705 
+0100
+++ gcc/testsuite/g++.dg/opt/pr79734.C  2017-02-28 19:50:21.0 +0100
@@ -0,0 +1,12 @@
+// PR tree-optimization/79734
+// { dg-do compile }
+// { dg-options "-O2" }
+// { dg-additional-options "-mavx512vl" { target i?86-*-* x86_64-*-* } }
+
+typedef float V __attribute__ ((vector_size (4 * sizeof (float;
+
+void
+foo (V *a, V *b)
+{
+  *a = (*a < 1 && !(*b > 2)) ? *a + *b : 3;
+}

Jakub

Re: libgo patch committed: Fix quoting in mksigtab.sh

[Ian Lance Taylor]

On Tue, Feb 28, 2017 at 12:08 PM, Rainer Orth
 wrote:
> Hi Ian,
>
>> I goofed on the shell quoting in mksigtab.sh, causing various
>> system-specific signals to be entered incorrectly in the runtime
>> signal table.  This patch fixes the problem.  The test for this is
>> misc/cgo/testcarchive in the master repo, which
>> we don't yet run for gccgo.  Bootstrapped and ran Go testsuite on
>> x86_64-pc-linux-gnu.  Committed to mainline.
>
> this broke Solaris bootstrap:
>
> sigtab.go:38:2: error: duplicate value for index 22
>   _SIGPOLL:{_SigNotify, "SIGPOLL: pollable event occurred"},
>   ^
> /vol/gcc/src/hg/trunk/local/libgo/go/runtime/signal_unix.go:395:3: error: 
> range clause must have array, slice, string, map, or channel type
>for i := range sigtable {
>^
> /vol/gcc/src/hg/trunk/local/libgo/go/runtime/signal_unix.go:591:2: error: 
> range clause must have array, slice, string, map, or channel type
>   for i := range sigtable {
>   ^
> /vol/gcc/src/hg/trunk/local/libgo/go/runtime/signal_unix.go:395:7: error: 
> invalid type for range clause
>for i := range sigtable {
>^
> /vol/gcc/src/hg/trunk/local/libgo/go/runtime/signal_unix.go:591:6: error: 
> invalid type for range clause
>   for i := range sigtable {
>   ^
> Makefile:: recipe for target 'runtime.lo' failed
> make[4]: *** [runtime.lo] Error 1
>
>  has
>
> #define SIGPOLL 22  /* pollable event occurred */
> #define SIGIO   SIGPOLL /* socket I/O possible (SIGPOLL alias) */
>
> this leads to
>
> const _SIGIO = _SIGPOLL
>
> and similarly
>
> const _SIGLWP = _SIGAIOCANCEL
>
> in gen-sysinfo.go.
>
> Fixed like this, which allows runtime.lo to compile.

Thanks.

Committed to mainline.

Ian

[Ada] PR target/79749

[Eric Botcazou]

This fixes the wrong code generated at -O0 with -fomit-frame-pointer in cases 
when the leaf function optimization could be applied (but is never at -O0).

Tested on SPARC/Solaris, applied on all active branches.

2017-02-28  Eric Botcazou  <ebotca...@adacore.com>

PR target/79749
* config/sparc/sparc.c (sparc_frame_pointer_required): Add missing
condition on optimize for the leaf function test.


2017-02-28  Eric Botcazou  <ebotca...@adacore.com>

* gcc.target/sparc/20170228-1.c: New test.

-- 
Eric Botcazou/* PR target/79749 */
/* Reported by Rainer Orth <r...@gcc.gnu.org> */

/* { dg-do run } */
/* { dg-options "-fomit-frame-pointer" } */

extern void abort (void);

int foo (int x1, int x2, int x3, int x4, int x5, int x6, int x7)
{
  return x7;
}

int main (void)
{
  if (foo (100, 200, 300, 400, 500, 600, 700) != 700)
abort ();

  return 0;
}
Index: config/sparc/sparc.c
===
--- config/sparc/sparc.c	(revision 245767)
+++ config/sparc/sparc.c	(working copy)
@@ -12180,8 +12180,9 @@ sparc_frame_pointer_required (void)
   if (TARGET_FLAT)
 return false;
 
-  /* Otherwise, the frame pointer is required if the function isn't leaf.  */
-  return !(crtl->is_leaf && only_leaf_regs_used ());
+  /* Otherwise, the frame pointer is required if the function isn't leaf, but
+ we cannot use sparc_leaf_function_p since it hasn't been computed yet.  */
+  return !(optimize > 0 && crtl->is_leaf && only_leaf_regs_used ());
 }
 
 /* The way this is structured, we can't eliminate SFP in favor of SP

[PATCH][PR target/79752] fix rs6000 power9 peephole2 for udiv/umod

[Aaron Sawdey]

This showed up in power9 code for __divkf3 software float support and
caused a divd to be emitted where we needed a divdu. OK for trunk if
bootstrap/regtest passes?

Index: ../trunk/gcc/config/rs6000/rs6000.md
===
--- ../trunk/gcc/config/rs6000/rs6000.md(revision 245787)
+++ ../trunk/gcc/config/rs6000/rs6000.md(working copy)
@@ -3161,7 +3161,7 @@
&& ! reg_mentioned_p (operands[3], operands[1])
&& ! reg_mentioned_p (operands[3], operands[2])"
   [(set (match_dup 0)
-   (div:GPR (match_dup 1)
+   (udiv:GPR (match_dup 1)
 (match_dup 2)))
(set (match_dup 3)
(mult:GPR (match_dup 0)

2017-02-28  Aaron Sawdey  

PR target/79752
* config/rs6000/rs6000.md (peephole2 for udiv/umod): Should emit
udiv rather than div since input pattern is unsigned.

-- 
Aaron Sawdey, Ph.D.  acsaw...@linux.vnet.ibm.com
050-2/C113  (507) 253-7520 home: 507/263-0782
IBM Linux Technology Center - PPC Toolchain

Re: PR79697: Delete calls to strdup, strndup, realloc if there is no lhs

[Peter Bergner]

On 2/28/17 12:49 PM, Peter Bergner wrote:
> On 2/25/17 2:40 AM, Prathamesh Kulkarni wrote:
>> The attached patch deletes calls to strdup, strndup if it's
>> return-value is unused,
>> and same for realloc if the first arg is NULL.
> 
> Why limit ourselves to strdup and strndup?  Can't we do the same
> for all functions that are marked as const/pure since we know
> they have no side effects other than their return value?

Nevermind.  Marc reminded me in the PR that these are not const/pure
functions.

Peter

Re: [PATCH docs] remove Java from GCC 7 release criteria

[Richard Biener]

On February 28, 2017 7:00:39 PM GMT+01:00, Jeff Law  wrote:
>On 02/28/2017 10:54 AM, Martin Sebor wrote:
>> The GCC 7 release criteria page mentions Java even though
>> the front end has been removed.  The attached patch removes Java
>> from the criteria page.  While reviewing the rest of the text I
>> noticed a few minor typos that I corrected in the patch as well.
>>
>> Btw., as an aside, I read the page to see if I could find out more
>> about the "magic" bug counts that are being aimed for to decide when
>> to cut the release.  Can someone say what those are and where to
>> find them?  I understand from the document that they're not exact
>> but even ballpark numbers would be useful.
>
>OK.
>
>WRT the bug counts.  0 P1 regressions, < 100 P1-P3 regressions.  I'm
>not 
>sure if that's documented anywhere though.

Actually the only criteria is zero P1 regressions.  Those are documented to 
block a release.

Richard.

>jeff

Re: C++ PATCH to fix wrong-code with pointer-to-data-members (PR c++/79687)

[Marek Polacek]

On Fri, Feb 24, 2017 at 11:11:05AM -0800, Jason Merrill wrote:
> On Fri, Feb 24, 2017 at 8:22 AM, Marek Polacek  wrote:
> > I had an interesting time tracking down some of the problems with this code.
> > Hopefully I've sussed out now how this stuff works.
> >
> > We've got
> >
> > struct A { char c; };
> > char A::*p = ::c;
> > static char A::*const q = p;
> > and then
> > &(a.*q) - 
> > which should evaluate to 0.  Here "p" will be 0, that's the offset from the
> > start of the struct to "c".  "q" is const-qualified and static and 
> > initialized
> > with "p", so we get to cp_fold_maybe_rvalue -> decl_constant_value ->
> > constant_value_1.  Now, NULL pointer-to-data-members are represented by -1, 
> > so
> > that a null pointer is distinguishable from an offset of the first member 
> > of a
> > struct (0).  So constant_value_1 looks at the DECL_INITIAL of "q", which is 
> > -1,
> > a constant, we fold "q" to -1, and sadness ensues.  I believe the -1 value 
> > is
> > only an internal representation and shouldn't be used like that.
> 
> Since q is initialized from p, it shouldn't have a DECL_INITIAL of -1;
> that sounds like the bug.

The DECL_INITIAL of -1 comes from cp_finish_decl:
 7038  The memory occupied by any object of static storage
 7039  duration is zero-initialized at program startup before
 7040  any other initialization takes place.
 7041 
 7042  We cannot create an appropriate initializer until after
 7043  the type of DECL is finalized.  If DECL_INITIAL is set,
 7044  then the DECL is statically initialized, and any
 7045  necessary zero-initialization has already been performed.  */
 7046   if (TREE_STATIC (decl) && !DECL_INITIAL (decl))
 7047 DECL_INITIAL (decl) = build_zero_init (TREE_TYPE (decl),
 7048/*nelts=*/NULL_TREE,
 7049
/*static_storage_p=*/true);

Later on, we reach expand_static_init which creates an initializer for q (to
set it to p) guarded with __cxa_guard_acquire, but that DECL_INITIAL is left
untouched.  My first attempts to clear the DECL_INITIAL had flopped and I
decided to do just this, but I can't see how this could be correct :(.
Any better ideas?

Bootstrapped/regtested on x86_64-linux.

2017-02-28  Marek Polacek  

PR c++/79687
* decl.c (expand_static_init): Clear DECL_INITIAL for
static pointer-to-data-members.

* g++.dg/expr/ptrmem8.C: New test.
* g++.dg/expr/ptrmem9.C: New test.

diff --git gcc/cp/decl.c gcc/cp/decl.c
index 828359f..9cfeaa1d 100644
--- gcc/cp/decl.c
+++ gcc/cp/decl.c
@@ -8139,6 +8139,14 @@ expand_static_init (tree decl, tree init)
 
   finish_expr_stmt (init);
 
+  /* A static pointer-to-data-member had been initialized to -1,
+and then initialized again with INIT.  Remove its DECL_INITIAL
+so that it won't confuse us later when folding.  */
+  if (TYPE_PTRDATAMEM_P (TREE_TYPE (decl))
+ && DECL_INITIAL (decl)
+ && null_member_pointer_value_p (DECL_INITIAL (decl)))
+   DECL_INITIAL (decl) = NULL_TREE;
+
   if (thread_guard)
{
  finish_compound_stmt (inner_then_clause);
diff --git gcc/testsuite/g++.dg/expr/ptrmem8.C 
gcc/testsuite/g++.dg/expr/ptrmem8.C
index e69de29..c5a766a 100644
--- gcc/testsuite/g++.dg/expr/ptrmem8.C
+++ gcc/testsuite/g++.dg/expr/ptrmem8.C
@@ -0,0 +1,15 @@
+// PR c++/79687
+// { dg-do run }
+
+struct A
+{
+  char c;
+};
+
+int main()
+{
+  char A::* p = ::c;
+  static char A::* const q = p;
+  A a;
+  return &(a.*q) - 
+}
diff --git gcc/testsuite/g++.dg/expr/ptrmem9.C 
gcc/testsuite/g++.dg/expr/ptrmem9.C
index e69de29..32ce777 100644
--- gcc/testsuite/g++.dg/expr/ptrmem9.C
+++ gcc/testsuite/g++.dg/expr/ptrmem9.C
@@ -0,0 +1,19 @@
+// PR c++/79687
+// { dg-do run }
+
+struct A
+{
+  char c;
+};
+
+int main()
+{
+  static char A::* p1 = ::c;
+  char A::* const q1 = p1;
+
+  char A::* p2 = ::c;
+  static char A::* const q2 = p2;
+
+  A a;
+  return (&(a.*q1) - ) || (&(a.*q2) - );
+}

Marek

Re: libgo patch committed: Fix quoting in mksigtab.sh

[Rainer Orth]

Hi Ian,

> I goofed on the shell quoting in mksigtab.sh, causing various
> system-specific signals to be entered incorrectly in the runtime
> signal table.  This patch fixes the problem.  The test for this is
> misc/cgo/testcarchive in the master repo, which
> we don't yet run for gccgo.  Bootstrapped and ran Go testsuite on
> x86_64-pc-linux-gnu.  Committed to mainline.

this broke Solaris bootstrap:

sigtab.go:38:2: error: duplicate value for index 22
  _SIGPOLL:{_SigNotify, "SIGPOLL: pollable event occurred"},
  ^
/vol/gcc/src/hg/trunk/local/libgo/go/runtime/signal_unix.go:395:3: error: range 
clause must have array, slice, string, map, or channel type
   for i := range sigtable {
   ^
/vol/gcc/src/hg/trunk/local/libgo/go/runtime/signal_unix.go:591:2: error: range 
clause must have array, slice, string, map, or channel type
  for i := range sigtable {
  ^
/vol/gcc/src/hg/trunk/local/libgo/go/runtime/signal_unix.go:395:7: error: 
invalid type for range clause
   for i := range sigtable {
   ^
/vol/gcc/src/hg/trunk/local/libgo/go/runtime/signal_unix.go:591:6: error: 
invalid type for range clause
  for i := range sigtable {
  ^
Makefile:: recipe for target 'runtime.lo' failed
make[4]: *** [runtime.lo] Error 1

 has

#define SIGPOLL 22  /* pollable event occurred */
#define SIGIO   SIGPOLL /* socket I/O possible (SIGPOLL alias) */

this leads to

const _SIGIO = _SIGPOLL

and similarly

const _SIGLWP = _SIGAIOCANCEL

in gen-sysinfo.go.

Fixed like this, which allows runtime.lo to compile.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


diff --git a/libgo/mksigtab.sh b/libgo/mksigtab.sh
--- a/libgo/mksigtab.sh
+++ b/libgo/mksigtab.sh
@@ -56,7 +56,8 @@ echo '	_SIGSYS:{_SigThrow, "SIGSYS: 
 # Handle signals that are not supported on all systems.
 
 checksig() {
-if grep "const $1 = " gen-sysinfo.go >/dev/null 2>&1; then
+if grep "const $1 = " gen-sysinfo.go >/dev/null 2>&1 \
+	&& ! grep "const $1 = _SIG" gen-sysinfo.go > /dev/null 2>&1; then
 	echo "	$1: $2,"
 fi
 }

Fwd: [Bug fortran/79739] [7 Regression] ICE with some interesting code

[Paul Richard Thomas]

Patch committed as obvious/trivial. I didn't think that it warranted a
testcase since there is no way that this one will come back.

Thanks for the report.

Paul



-- Forwarded message --
From: pault at gcc dot gnu.org 
Date: 28 February 2017 at 19:32
Subject: [Bug fortran/79739] [7 Regression] ICE with some interesting code
To: pa...@gcc.gnu.org


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79739

--- Comment #6 from Paul Thomas  ---
Author: pault
Date: Tue Feb 28 19:32:02 2017
New Revision: 245787

URL: https://gcc.gnu.org/viewcvs?rev=245787=gcc=rev
Log:
2017-02-28  Paul Thomas  

PR fortran/79739
* resolve.c (resolve_fl_procedure): Deal with the case where
'submodule_name' is NULL so that gfc_error does not ICE.
Reformat the error message to make it more consistent.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c

--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.


-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Merge from trunk to gccgo branch

[Ian Lance Taylor]

I've merged trunk revision 245784 to the gccgo branch.

Ian

Re: PR79697: Delete calls to strdup, strndup, realloc if there is no lhs

[Peter Bergner]

On 2/25/17 2:40 AM, Prathamesh Kulkarni wrote:
> The attached patch deletes calls to strdup, strndup if it's
> return-value is unused,
> and same for realloc if the first arg is NULL.

Why limit ourselves to strdup and strndup?  Can't we do the same
for all functions that are marked as const/pure since we know
they have no side effects other than their return value?

Peter

Re: [PATCH docs] remove Java from GCC 7 release criteria

[Jeff Law]

On 02/28/2017 11:09 AM, Martin Sebor wrote:

On 02/28/2017 11:00 AM, Jeff Law wrote:

On 02/28/2017 10:54 AM, Martin Sebor wrote:

The GCC 7 release criteria page mentions Java even though
the front end has been removed.  The attached patch removes Java
from the criteria page.  While reviewing the rest of the text I
noticed a few minor typos that I corrected in the patch as well.

Btw., as an aside, I read the page to see if I could find out more
about the "magic" bug counts that are being aimed for to decide when
to cut the release.  Can someone say what those are and where to
find them?  I understand from the document that they're not exact
but even ballpark numbers would be useful.


OK.

WRT the bug counts.  0 P1 regressions, < 100 P1-P3 regressions.  I'm not
sure if that's documented anywhere though.


Thanks.  Would it make sense to mention these numbers in the criteria?
E.g., like so (assuming those apply to primary platforms):
For non-primary platforms BZs get put into the P4/P5 priority buckets, 
so it's a non-issue.


OK.

jeff

Re: [PATCH 2/3] Introduce = for couple of options.

[Joseph Myers]

On Tue, 28 Feb 2017, Martin Liška wrote:

> Hello.
> 
> This is second patch, where I add '=' for some of options.

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Add tabulars for options with enum values.

[Joseph Myers]

On Tue, 28 Feb 2017, Martin Liška wrote:

> Ready to be installed after regression tests?

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH docs] remove Java from GCC 7 release criteria

[Martin Sebor]

On 02/28/2017 11:00 AM, Jeff Law wrote:

On 02/28/2017 10:54 AM, Martin Sebor wrote:

The GCC 7 release criteria page mentions Java even though
the front end has been removed.  The attached patch removes Java
from the criteria page.  While reviewing the rest of the text I
noticed a few minor typos that I corrected in the patch as well.

Btw., as an aside, I read the page to see if I could find out more
about the "magic" bug counts that are being aimed for to decide when
to cut the release.  Can someone say what those are and where to
find them?  I understand from the document that they're not exact
but even ballpark numbers would be useful.


OK.

WRT the bug counts.  0 P1 regressions, < 100 P1-P3 regressions.  I'm not
sure if that's documented anywhere though.


Thanks.  Would it make sense to mention these numbers in the criteria?
E.g., like so (assuming those apply to primary platforms):

-Our release criteria for primary platforms is:
+Our release criteria for primary platforms are:
 

 
+No open P1 regressions in Bugzilla and no more than 100 open P2
+and P3 regressions.
+
+
+

Martin

Re: [PATCH docs] remove Java from GCC 7 release criteria

[Jeff Law]

On 02/28/2017 10:54 AM, Martin Sebor wrote:

The GCC 7 release criteria page mentions Java even though
the front end has been removed.  The attached patch removes Java
from the criteria page.  While reviewing the rest of the text I
noticed a few minor typos that I corrected in the patch as well.

Btw., as an aside, I read the page to see if I could find out more
about the "magic" bug counts that are being aimed for to decide when
to cut the release.  Can someone say what those are and where to
find them?  I understand from the document that they're not exact
but even ballpark numbers would be useful.


OK.

WRT the bug counts.  0 P1 regressions, < 100 P1-P3 regressions.  I'm not 
sure if that's documented anywhere though.


jeff

Re: PR79715: Special case strcpy/strncpy for dse

[Jeff Law]

On 02/28/2017 05:59 AM, Prathamesh Kulkarni wrote:

On 28 February 2017 at 15:40, Jakub Jelinek  wrote:

On Tue, Feb 28, 2017 at 03:33:11PM +0530, Prathamesh Kulkarni wrote:

Hi,
The attached patch adds special-casing for strcpy/strncpy to dse pass.
Bootstrapped+tested on x86_64-unknown-linux-gnu.
OK for GCC 8 ?


What is special on strcpy/strncpy?  Unlike memcpy/memmove/memset, you don't
know the length they store (at least not in general), you don't know the
value, all you know is that they are for the first argument plain store
without remembering the pointer or anything based on it anywhere except in
the return value.
I believe stpcpy, stpncpy, strcat, strncat at least have the same behavior.
On the other side, without knowing the length of the store, you can't treat
it as killing something (ok, some calls like strcpy or stpcpy store at least
the first byte).

Well, I assumed a store to dest by strcpy (and friends), which gets
immediately freed would count
as a dead store since free would kill the whole memory block pointed
to by dest ?
Yes.  But does it happen often in practice?  I wouldn't mind exploring 
this for gcc-8, but I'd like to see real-world code where this happens.


jeff

[PATCH docs] remove Java from GCC 7 release criteria

[Martin Sebor]

The GCC 7 release criteria page mentions Java even though
the front end has been removed.  The attached patch removes Java
from the criteria page.  While reviewing the rest of the text I
noticed a few minor typos that I corrected in the patch as well.

Btw., as an aside, I read the page to see if I could find out more
about the "magic" bug counts that are being aimed for to decide when
to cut the release.  Can someone say what those are and where to
find them?  I understand from the document that they're not exact
but even ballpark numbers would be useful.

Thanks
Martin
Index: criteria.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/criteria.html,v
retrieving revision 1.1
diff -u -r1.1 criteria.html
--- criteria.html	23 May 2016 09:16:41 -	1.1
+++ criteria.html	28 Feb 2017 17:41:00 -
@@ -7,7 +7,7 @@
 
 GCC 7 Release Criteria
 
-This page provides the release criteria for GCC 7.  
+This page provides the release criteria for GCC 7.
 
 The GCC team (and, in particular, the Release Managers) will attempt
 to meet these criteria before the release of GCC 7.
@@ -18,7 +18,7 @@
 candidate will probably not become the eventual release.  However, a
 release candidate that does meet these criteria may not necessarily
 become the official release; there may be other unforeseen issues that
-prevent release.  For example, if support for the Intel Pentium II is
+prevent the release.  For example, if support for the Intel Pentium II is
 required by the release criteria, it is nevertheless unlikely that GCC
 would be released even though it did not support the Intel Pentium.
 
@@ -32,10 +32,10 @@
 Languages
 
 GCC supports several programming languages, including Ada, C, C++,
-Fortran, Objective-C, Objective-C++, Go and Java.
+Fortran, Objective-C, Objective-C++, and Go.
 For the purposes of making releases,
 however, we will consider primarily C and C++, as those are the
-languages used by the vast majority of users.  Therefore, if, below,
+languages used by the vast majority of users.  Therefore, if below
 the criteria indicate, for example, that there should be no DejaGNU
 regressions on a particular platform, that criteria should be read as
 applying only to DejaGNU regressions within the C, C++, and C++
@@ -53,12 +53,12 @@
 All platforms that are neither primary nor secondary are tertiary
 platforms.
 
-Our release criteria for primary platforms is:
+Our release criteria for primary platforms are:
 
 
 
 All regressions open in Bugzilla have been analyzed, and all are
-deemed as either unlikely to affect most users, or are determined to
+deemed either unlikely to affect most users, or are determined to
 have a minimal impact on affected users.  For example, a
 typographical error in a diagnostic might be relatively common, but
 also has minimal impact on users.
@@ -67,14 +67,14 @@
 code, or refuses to compile a valid program, will be considered to
 be sufficiently severe to block the release, unless there are
 substantial mitigating factors.
-  
+
 
 The DejaGNU testsuite has been run, and compared with a run of
 the testsuite on the previous release of GCC, and no regressions are
 observed.
 
 
-Our release criteria for the secondary platforms is:
+Our release criteria for the secondary platforms are:
 
 The compiler bootstraps successfully, and the C++ runtime library
 builds.
@@ -92,7 +92,7 @@
 explicit application testing.  It is our experience that, with the
 resources available, it is very difficult to methodically carry out
 such testing. However, we expect that interested users will submit
-bug reports for problems encountered building and using popular
+bug reports for problems encountered while building and using popular
 packages.  Therefore, we do not intend the elimination of application
 testing from our criteria to imply that we will not pay attention to
 application testing.
@@ -142,7 +142,7 @@
 superior code on other test cases.  Therefore, the Release Manager, or
 parties to whom he or she delegates responsibility, will make
 determinations on a case-by-case basis as to whether or not a code
-quality or compilation time regression is sufficiently severe as to
+quality or compilation time regression is sufficiently severe to
 merit blocking the release.
 
 

OpenACC 2.5 Profiling Interface (incomplete)

[Thomas Schwinge]

Hi!

The 2.5 versions of the OpenACC standard added a new chapter "Profiling
Interface".  In r245784, I committed incomplete support to
gomp-4_0-branch.  I plan to continue working on this, but wanted to
synchronize at this point.

commit b22a85fe7f3daeb48460e7aa28606d0cdb799f69
Author: tschwinge 
Date:   Tue Feb 28 17:36:03 2017 +

OpenACC 2.5 Profiling Interface (incomplete)

libgomp/
* acc_prof.h: New file.
* oacc-profiling-acc_register_library.c: Likewise.
* oacc-profiling.c: Likewise.
* Makefile.am (nodist_libsubinclude_HEADERS, libgomp_la_SOURCES):
Add these, respectively.
* Makefile.in: Regenerate.
* libgomp/config/nvptx/oacc-profiling-acc_register_library.c:
New empty file.
* libgomp/config/nvptx/oacc-profiling.c: Likewise.
* env.c (initialize_env): Call goacc_profiling_initialize.
* libgomp-plugin.c: New function
GOMP_PLUGIN_goacc_profiling_dispatch.
* libgomp-plugin.h: Declare function
GOMP_PLUGIN_goacc_profiling_dispatch.
* oacc-plugin.c: New function GOMP_PLUGIN_goacc_thread.
* oacc-plugin.h: Declare function GOMP_PLUGIN_goacc_thread.
* libgomp.map (OACC_2.5): Add acc_prof_lookup, acc_prof_register,
acc_prof_unregister, and acc_register_library.
Add GOMP_PLUGIN_goacc_profiling_dispatch, and
GOMP_PLUGIN_goacc_thread with new GOMP_PLUGIN_1.3 symbol version.
* oacc-int.h (struct goacc_thread): Add "acc_prof_info
*prof_info", "acc_api_info *api_info", and "bool
prof_callbacks_enabled" members.
Declare functions goacc_profiling_initialize,
goacc_profiling_dispatch_p, and goacc_profiling_dispatch.
* oacc-init.c (acc_init_1): Add "acc_construct_t", and "int"
formal parameters.  Adjust all users.
(acc_init_1, goacc_attach_host_thread_to_device, acc_init)
(goacc_lazy_initialize): Update for OpenACC Profiling Interface.
* oacc-parallel.c (GOACC_parallel_keyed): Likewise.
* plugin/plugin-nvptx.c (cuda_map_create, cuda_map_destroy)
(map_init, map_fini, map_pop, map_push): Add "struct goacc_thread
*" formal parameter.  Adjust all users.
(select_stream_for_async, event_gc, nvptx_exec, nvptx_host2dev)
(nvptx_dev2host, nvptx_set_cuda_stream): Call
GOMP_PLUGIN_goacc_thread instead of nvptx_thread.
(cuda_map_create, cuda_map_destroy, nvptx_exec, nvptx_alloc)
(nvptx_free, nvptx_host2dev, nvptx_dev2host): Update for OpenACC
Profiling Interface.
* libgomp.texi: New chapter "OpenACC Profiling Interface".
* testsuite/libgomp.oacc-c-c++-common/acc_prof-dispatch-1.c: New
file.
* testsuite/libgomp.oacc-c-c++-common/acc_prof-init-1.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/acc_prof-parallel-1.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/acc_prof-valid_bytes-1.c:
Likewise.
* testsuite/libgomp.oacc-c-c++-common/acc_prof-version-1.c:
Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@245784 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgomp/ChangeLog.gomp |  50 ++
 libgomp/Makefile.am|   5 +-
 libgomp/Makefile.in|  10 +-
 libgomp/acc_prof.h | 237 +++
 .../nvptx/oacc-profiling-acc_register_library.c|   0
 libgomp/config/nvptx/oacc-profiling.c  |   0
 libgomp/env.c  |   3 +-
 libgomp/libgomp-plugin.c   |   9 +
 libgomp/libgomp-plugin.h   |   6 +
 libgomp/libgomp.map|  11 +
 libgomp/libgomp.texi   | 246 +++
 libgomp/oacc-init.c|  68 +-
 libgomp/oacc-int.h |  12 +
 libgomp/oacc-parallel.c| 126 +++-
 libgomp/oacc-plugin.c  |  13 +
 libgomp/oacc-plugin.h  |   3 +
 ...gin.h => oacc-profiling-acc_register_library.c} |  19 +-
 libgomp/oacc-profiling.c   | 576 +
 libgomp/plugin/plugin-nvptx.c  | 315 -
 .../acc_prof-dispatch-1.c  | 344 ++
 .../libgomp.oacc-c-c++-common/acc_prof-init-1.c| 306 +
 .../acc_prof-parallel-1.c  | 703 +
 .../acc_prof-valid_bytes-1.c   | 172 +
 .../libgomp.oacc-c-c++-common/acc_prof-version-1.c |  55 ++
 

libgomp, OpenACC: Fix locking of cached_base_dev (guarded by acc_device_lock)

[Thomas Schwinge]

Hi!

We'd noticed before some locking issues in libgomp; in r245783 I just
committed the following to gomp-4_0-branch:

commit 921620f947485002e56f736d4ca18bd2ae33e05b
Author: tschwinge 
Date:   Tue Feb 28 17:35:49 2017 +

libgomp, OpenACC: Fix locking of cached_base_dev (guarded by 
acc_device_lock)

libgomp/
* oacc-init.c (goacc_register, acc_init, goacc_lazy_initialize):
Fix locking of cached_base_dev (guarded by acc_device_lock).
(goacc_lazy_initialize): Don't call acc_init; copy code here,
instead.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@245783 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgomp/ChangeLog.gomp |  7 +++
 libgomp/oacc-init.c| 25 +
 2 files changed, 20 insertions(+), 12 deletions(-)

diff --git libgomp/ChangeLog.gomp libgomp/ChangeLog.gomp
index 637be06..af6a28b 100644
--- libgomp/ChangeLog.gomp
+++ libgomp/ChangeLog.gomp
@@ -1,3 +1,10 @@
+2017-02-28  Thomas Schwinge  
+
+   * oacc-init.c (goacc_register, acc_init, goacc_lazy_initialize):
+   Fix locking of cached_base_dev (guarded by acc_device_lock).
+   (goacc_lazy_initialize): Don't call acc_init; copy code here,
+   instead.
+
 2017-02-27  Chung-Lin Tang  
 
* testsuite/libgomp.oacc-c-c++-common/gang-private-1.c: New test.
diff --git libgomp/oacc-init.c libgomp/oacc-init.c
index 71e9ccf..05bb663 100644
--- libgomp/oacc-init.c
+++ libgomp/oacc-init.c
@@ -64,6 +64,10 @@ static gomp_mutex_t goacc_thread_lock;
grouped by device in target.c:devices).  */
 static struct gomp_device_descr *dispatchers[_ACC_device_hwm] = { 0 };
 
+/* Register a device.
+
+   ACC_DEVICE_LOCK must be held before calling this function.  */
+
 attribute_hidden void
 goacc_register (struct gomp_device_descr *disp)
 {
@@ -71,15 +75,11 @@ goacc_register (struct gomp_device_descr *disp)
   if (disp->target_id != 0)
 return;
 
-  gomp_mutex_lock (_device_lock);
-
   assert (acc_device_type (disp->type) != acc_device_none
  && acc_device_type (disp->type) != acc_device_default
  && acc_device_type (disp->type) != acc_device_not_host);
   assert (!dispatchers[disp->type]);
   dispatchers[disp->type] = disp;
-
-  gomp_mutex_unlock (_device_lock);
 }
 
 /* OpenACC names some things a little differently.  */
@@ -449,13 +449,10 @@ goacc_attach_host_thread_to_device (int ord)
 void
 acc_init (acc_device_t d)
 {
+  gomp_mutex_lock (_device_lock);
   if (!cached_base_dev)
 gomp_init_targets_once ();
-
-  gomp_mutex_lock (_device_lock);
-
   cached_base_dev = acc_init_1 (d);
-
   gomp_mutex_unlock (_device_lock);
   
   goacc_attach_host_thread_to_device (-1);
@@ -704,12 +701,16 @@ attribute_hidden void
 goacc_lazy_initialize (void)
 {
   struct goacc_thread *thr = goacc_thread ();
-
   if (thr && thr->dev)
 return;
 
+  gomp_mutex_lock (_device_lock);
   if (!cached_base_dev)
-acc_init (acc_device_default);
-  else
-goacc_attach_host_thread_to_device (-1);
+{
+  gomp_init_targets_once ();
+  cached_base_dev = acc_init_1 (acc_device_default);
+}
+  gomp_mutex_unlock (_device_lock);
+
+  goacc_attach_host_thread_to_device (-1);
 }


Grüße
 Thomas

Re: [RFC PATCH 2/3] Use call_summary in ipa-prop and ipa-cp

[Martin Jambor]

Hi,

On Tue, Feb 28, 2017 at 11:50:01AM +0100, jh wrote:
> Dne 2017-02-27 17:35, Martin Jambor napsal:
> > Hello,
> > 
> > this is patch is afairly straightforward conversion from use of a
> > vector indexed by edge->uid to use of the new call_summary from the
> > previous patch.
> > 
> > The patch is generally a cleanup, hashing is a nicer method of keeping
> > call-site related information than a gigantic vector that we never
> > shrink during its lifetime.  Moreover, it should allow further
> > cleanups and of course is a nice way of testing that the previous
> > patch works.
> > 
> > Any comments and/or suggestions are welcome,
> > 
> > Martin
> > 
> > 2017-02-27  Martin Jambor  
> > 
> > * ipa-prop.h (ipa_edge_args): Make a class.  Mark with for_user GTY
> > tag.  Added a default constructor and a destructor.
> > (ipa_edge_args_sum_t): New class;
> > (ipa_edge_args_sum): Declare.
> > (ipa_edge_args_vector): Remove declaration.
> > (IPA_EDGE_REF): Use ipa_edge_args_sum.
> > (ipa_free_edge_args_substructures): Remove declaration.
> > (ipa_check_create_edge_args): Use ipa_edge_args_sum.
> > (ipa_edge_args_info_available_for_edge_p): Likewise.
> > * ipa-prop.c (ipa_edge_args_vector): Removed.
> > (edge_removal_hook_holder): Likewise.
> > (edge_duplication_hook_holder): Likewise.
> > (ipa_edge_args_sum): New variable.
> > (ipa_propagate_indirect_call_infos): Test ipa_edge_args_sum instead of
> > ipa_edge_args_vector.
> > (ipa_free_edge_args_substructures): Likewise.
> > (ipa_free_all_edge_args): Free ipa_edge_args_sum instead of
> > ipa_edge_args_vector.
> > (ipa_edge_removal_hook): Turned into method
> > ipa_edge_args_sum_t::remove.
> > (ipa_edge_duplication_hook): Turned into method
> > ipa_edge_args_sum_t::duplicate.
> > (ipa_register_cgraph_hooks): Create ipa_edge_args_sum instead of
> > registering edge hooks.
> > (ipa_unregister_cgraph_hooks): Do not unregister edge hooks.
> > * ipa-inline-analysis.c (estimate_function_body_sizes): Test
> > ipa_edge_args_sum instead of ipa_edge_args_vector.
> > * ipa-profile.c (ipa_profile): Likewise.
> OK
> Did you check what memory consumption consquences it have for Firefox?

There is no noticeable difference, unfortunately.

Martin

Re: [PATCH] Fix gimple-ssa-store-merging.c on little-endian (PR tree-optimization/79737)

[Kyrill Tkachov]

On 28/02/17 16:29, Richard Biener wrote:

On February 28, 2017 5:00:41 PM GMT+01:00, Jakub Jelinek  
wrote:

Hi!

The following testcases are miscompiled on little endian targets.
The bug occurs if we are merging bitfield stores, there is a signed
bitfield
with bitlen multiple of BITS_PER_UNIT but not equal to the bitsize of
the
corresponding mode, the bitfield doesn't start on multiple of
BITS_PER_UNIT,
we store negative constant to it and store to field overlapping 7 bits
above
this bitfield is done before store to this bitfield.

In particular in the testcases, we have bitfield with bitpos 19, bitlen
24
and store value -5 to it.
That means we use byte_size of 5 (SImode bytesize + 1 extra byte for
shifting), and we end up with 0xfb, 0xff, 0xff, 0xff, 0x00 bytes in
tmpbuf.
Next, we find out that there is padding of 1 byte, so decrement
byte_size to
4 (again, real byte size of the non-shifted bitfield is 3, but 1 extra
byte
for shifting), but as bitlen is a multiple of BITS_PER_UNIT, we don't
clear
anything after those 0xfb, 0xff, 0xff bytes.  And then
shift_bytes_in_array
just shifts all bytes left and we end up with 0xd8, 0xff, 0xff, 0xff
when we want 0xd8, 0xff, 0xff, 0x07.
Finally these bytes are ored into the real buffer where we've
previously
cleared the bitrange (which is why having 0xff in the last byte is
harmful).

Now, if bitlen is not a multiple of BITS_PER_UNIT, we already clear
that
extra byte plus some bits:
- else
-   clear_bit_region (tmpbuf, bitlen,
- byte_size * BITS_PER_UNIT - bitlen);
Here byte_size is still the actual byte size + 1 and thus say if
instead of
bitlen 24 we had bitlen 23, we would have cleared 0xfb, 0xff, 0xff,
0xff,
0x00 tmpbuf to 0xfb, 0xff, 0x7f, 0x00, 0x00.

For big endian, my understanding is that we also rely on
tmpbuf[byte_size - 1]
being 0, but we should not suffer from this problem, we clear it first
everywhere, then
  if (native_encode_expr (expr, tmpbuf, byte_size, 0) == 0)
should really just write byte_size - 1 bytes due to the mode (though,
I'd
say it would be much clearer if we called
  if (native_encode_expr (expr, tmpbuf, byte_size - 1, 0) == 0)
because that is what we want (ok to make this change?).  Then the
padding
adjustment for big-endian is actually tmpbuf += padding, so we move the
start of the buffer, and for obvious reason don't want to access any
bytes
before tmpbuf during shifting.

The following patch fixes that, bootstrapped/regtested on x86_64-linux
and i686-linux, ok for trunk (without or with the above
native_encode_expr
call change)?

With the native encode change is fine with me.


Ok with me as well FWIW. That part of the pass is quite tricky to get right
when negative numbers (that are sign-extended) get involved.

Thanks,
Kyrill


Richard.


Other options would be to do there tmpbuf[byte_size - 1] = '\0';
unconditionally (we rely on it everywhere, just in other cases it
should
be already cleared), or do such clearing inside of the two
shift_bytes_in_array* functions.

2017-02-28  Jakub Jelinek  

PR tree-optimization/79737
* gimple-ssa-store-merging.c (encode_tree_to_bitpos): If bitlen is
a multiple of BITS_PER_UNIT and !BYTES_BIG_ENDIAN, clear
tmpbuf[byte_size - 1].  Formatting fix.
(shift_bytes_in_array_right): Formatting fix.

* gcc.c-torture/execute/pr79737-1.c: New test.
* gcc.c-torture/execute/pr79737-2.c: New test.

--- gcc/gimple-ssa-store-merging.c.jj   2017-01-01 12:45:38.0
+0100
+++ gcc/gimple-ssa-store-merging.c  2017-02-28 10:34:05.848174576 +0100
@@ -253,9 +253,9 @@ shift_bytes_in_array_right (unsigned cha
   unsigned prev_carry_over = carry_over;
   carry_over = ptr[i] & carry_mask;

- carry_over <<= (unsigned char) BITS_PER_UNIT - amnt;
- ptr[i] >>= amnt;
- ptr[i] |= prev_carry_over;
+  carry_over <<= (unsigned char) BITS_PER_UNIT - amnt;
+  ptr[i] >>= amnt;
+  ptr[i] |= prev_carry_over;
 }
}

@@ -352,8 +352,9 @@ encode_tree_to_bitpos (tree expr, unsign
{
   unsigned int first_byte = bitpos / BITS_PER_UNIT;
   tree tmp_int = expr;
-  bool sub_byte_op_p = (bitlen % BITS_PER_UNIT) || (bitpos %
BITS_PER_UNIT)
-   || mode_for_size (bitlen, MODE_INT, 0) == BLKmode;
+  bool sub_byte_op_p = ((bitlen % BITS_PER_UNIT)
+   || (bitpos % BITS_PER_UNIT)
+   || mode_for_size (bitlen, MODE_INT, 0) == BLKmode);

   if (!sub_byte_op_p)
return (native_encode_expr (tmp_int, ptr + first_byte, total_bytes, 0)
@@ -418,25 +419,27 @@ encode_tree_to_bitpos (tree expr, unsign
  contain a sign bit due to sign-extension).  */
   unsigned int padding
= byte_size - ROUND_UP (bitlen, BITS_PER_UNIT) / BITS_PER_UNIT - 1;
-  if (padding != 0
-  || bitlen % BITS_PER_UNIT != 0)
+  /* On big-endian the padding is at the 'front' so just skip the
initial
+ bytes.  */
+  if (BYTES_BIG_ENDIAN)
+

Re: [PATCH] Workaround premature bitfield folding (PR c++/79681)

[Jakub Jelinek]

On Tue, Feb 28, 2017 at 04:43:19PM +0100, Richard Biener wrote:
> > This patch just attempts to reuse as much as possible from orig_inner and
> > only use adjusted BIT_FIELD_REF on that when in GENERIC (first I've tried to
> > use instead COMPONENT_REF with DECL_BIT_FIELD_REPRESENTATIVE, but that isn't
> > handled by constexpr.c either).
> > Bootstrapped/regtested on x86_64/i686-linux, ok for trunk?
> 
> Hmm, I'd rather not do anything is_gimple_form specific.

I think doing what the patch for TREE_CODE (orig_inner) == COMPONENT_REF
is probably fine as well, at least assuming say SCCVN uses
get_inner_reference or something similar to query to ultimate bases and
offsets for CSE purposes.  Though, for non-bitfield refs we still use
in various places x.foo.bar.baz and in other places MEM_REF[ + xyz],
so I think SCCVN needs to deal with those already anyway.

>  Can't we
> restrict this transform to work on the outermost handled-component only?

That is essentially what the patch does; get_inner_reference returns
the ultimate base and the patch re-adds the handled-components other than
the outermost one back if it yields the same positions/sizes.
Perhaps an alternative would be not to call get_inner_reference at all,
just something that does handle only the outermost handled component
(or add get_inner_reference argument to do that).

> Ideally we'd want to find a common base of course.
> 
> The folding is also guarded with optimize != 0 so maybe simply disable
> it from the FEs?  (but yes, you say it does a bad job on GIMPLE

No, I'm afraid we wouldn't fold it at all then.

> which is quite understandable as there's no TRUTH_*, but we can
> eventually call it from gimplification instead?)

The optimize_bit_field_compare perhaps can work in some cases on GIMPLE,
the truth_fold_andor* I think would need something like tree-ssa-reassoc.c
infrastructure or something similar to gather many comparisons from multiple
basic blocks.

Jakub

Re: [PATCH] Fix gimple-ssa-store-merging.c on little-endian (PR tree-optimization/79737)

[Richard Biener]

On February 28, 2017 5:00:41 PM GMT+01:00, Jakub Jelinek  
wrote:
>Hi!
>
>The following testcases are miscompiled on little endian targets.
>The bug occurs if we are merging bitfield stores, there is a signed
>bitfield
>with bitlen multiple of BITS_PER_UNIT but not equal to the bitsize of
>the
>corresponding mode, the bitfield doesn't start on multiple of
>BITS_PER_UNIT,
>we store negative constant to it and store to field overlapping 7 bits
>above
>this bitfield is done before store to this bitfield.
>
>In particular in the testcases, we have bitfield with bitpos 19, bitlen
>24
>and store value -5 to it.
>That means we use byte_size of 5 (SImode bytesize + 1 extra byte for
>shifting), and we end up with 0xfb, 0xff, 0xff, 0xff, 0x00 bytes in
>tmpbuf.
>Next, we find out that there is padding of 1 byte, so decrement
>byte_size to
>4 (again, real byte size of the non-shifted bitfield is 3, but 1 extra
>byte
>for shifting), but as bitlen is a multiple of BITS_PER_UNIT, we don't
>clear
>anything after those 0xfb, 0xff, 0xff bytes.  And then
>shift_bytes_in_array
>just shifts all bytes left and we end up with 0xd8, 0xff, 0xff, 0xff
>when we want 0xd8, 0xff, 0xff, 0x07.
>Finally these bytes are ored into the real buffer where we've
>previously
>cleared the bitrange (which is why having 0xff in the last byte is
>harmful).
>
>Now, if bitlen is not a multiple of BITS_PER_UNIT, we already clear
>that
>extra byte plus some bits:
>- else
>-   clear_bit_region (tmpbuf, bitlen,
>- byte_size * BITS_PER_UNIT - bitlen);
>Here byte_size is still the actual byte size + 1 and thus say if
>instead of
>bitlen 24 we had bitlen 23, we would have cleared 0xfb, 0xff, 0xff,
>0xff,
>0x00 tmpbuf to 0xfb, 0xff, 0x7f, 0x00, 0x00.
>
>For big endian, my understanding is that we also rely on
>tmpbuf[byte_size - 1]
>being 0, but we should not suffer from this problem, we clear it first
>everywhere, then
>  if (native_encode_expr (expr, tmpbuf, byte_size, 0) == 0)
>should really just write byte_size - 1 bytes due to the mode (though,
>I'd
>say it would be much clearer if we called
>  if (native_encode_expr (expr, tmpbuf, byte_size - 1, 0) == 0)
>because that is what we want (ok to make this change?).  Then the
>padding
>adjustment for big-endian is actually tmpbuf += padding, so we move the
>start of the buffer, and for obvious reason don't want to access any
>bytes
>before tmpbuf during shifting.
>
>The following patch fixes that, bootstrapped/regtested on x86_64-linux
>and i686-linux, ok for trunk (without or with the above
>native_encode_expr
>call change)?

With the native encode change is fine with me.

Richard.

>Other options would be to do there tmpbuf[byte_size - 1] = '\0';
>unconditionally (we rely on it everywhere, just in other cases it
>should
>be already cleared), or do such clearing inside of the two
>shift_bytes_in_array* functions.
>
>2017-02-28  Jakub Jelinek  
>
>   PR tree-optimization/79737
>   * gimple-ssa-store-merging.c (encode_tree_to_bitpos): If bitlen is
>   a multiple of BITS_PER_UNIT and !BYTES_BIG_ENDIAN, clear
>   tmpbuf[byte_size - 1].  Formatting fix.
>   (shift_bytes_in_array_right): Formatting fix.
>
>   * gcc.c-torture/execute/pr79737-1.c: New test.
>   * gcc.c-torture/execute/pr79737-2.c: New test.
>
>--- gcc/gimple-ssa-store-merging.c.jj  2017-01-01 12:45:38.0
>+0100
>+++ gcc/gimple-ssa-store-merging.c 2017-02-28 10:34:05.848174576 +0100
>@@ -253,9 +253,9 @@ shift_bytes_in_array_right (unsigned cha
>   unsigned prev_carry_over = carry_over;
>   carry_over = ptr[i] & carry_mask;
> 
>- carry_over <<= (unsigned char) BITS_PER_UNIT - amnt;
>- ptr[i] >>= amnt;
>- ptr[i] |= prev_carry_over;
>+  carry_over <<= (unsigned char) BITS_PER_UNIT - amnt;
>+  ptr[i] >>= amnt;
>+  ptr[i] |= prev_carry_over;
> }
> }
> 
>@@ -352,8 +352,9 @@ encode_tree_to_bitpos (tree expr, unsign
> {
>   unsigned int first_byte = bitpos / BITS_PER_UNIT;
>   tree tmp_int = expr;
>-  bool sub_byte_op_p = (bitlen % BITS_PER_UNIT) || (bitpos %
>BITS_PER_UNIT)
>-  || mode_for_size (bitlen, MODE_INT, 0) == BLKmode;
>+  bool sub_byte_op_p = ((bitlen % BITS_PER_UNIT)
>+  || (bitpos % BITS_PER_UNIT)
>+  || mode_for_size (bitlen, MODE_INT, 0) == BLKmode);
> 
>   if (!sub_byte_op_p)
> return (native_encode_expr (tmp_int, ptr + first_byte, total_bytes, 0)
>@@ -418,25 +419,27 @@ encode_tree_to_bitpos (tree expr, unsign
>  contain a sign bit due to sign-extension).  */
>   unsigned int padding
>= byte_size - ROUND_UP (bitlen, BITS_PER_UNIT) / BITS_PER_UNIT - 1;
>-  if (padding != 0
>-  || bitlen % BITS_PER_UNIT != 0)
>+  /* On big-endian the padding is at the 'front' so just skip the
>initial
>+ bytes.  */
>+  if (BYTES_BIG_ENDIAN)
>+tmpbuf += padding;
>+
>+  byte_size -= padding;
>+
>+  if (bitlen % BITS_PER_UNIT != 0)

Re: [PATCH] Another x86 output_operand_lossage fix (PR target/79729)

[Uros Bizjak]

On Tue, Feb 28, 2017 at 5:04 PM, Jakub Jelinek  wrote:
> Hi!
>
> Apparently when fixing these issues earlier I've missed one spot with
> gcc_unreachable () dependent on the value that could be provided by user
> in bogus inline asm.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2017-02-28  Jakub Jelinek  
>
> PR target/79729
> * config/i386/i386.c (ix86_print_operand) : Replace
> gcc_unreachable with output_operand_lossage.
>
> * gcc.target/i386/pr79729.c: New test.

OK.

Thanks,
Uros.

> --- gcc/config/i386/i386.c.jj   2017-02-28 07:49:33.0 +0100
> +++ gcc/config/i386/i386.c  2017-02-28 07:56:38.536106025 +0100
> @@ -18228,7 +18228,8 @@ ix86_print_operand (FILE *file, rtx x, i
>   fputs ("{rz-sae}", file);
>   break;
> default:
> - gcc_unreachable ();
> + output_operand_lossage ("operand is not a specific integer, "
> + "invalid operand code 'R'");
> }
>
>   if (ASSEMBLER_DIALECT == ASM_ATT)
> --- gcc/testsuite/gcc.target/i386/pr79729.c.jj  2017-02-28 07:58:11.168862088 
> +0100
> +++ gcc/testsuite/gcc.target/i386/pr79729.c 2017-02-28 07:58:31.401590388 
> +0100
> @@ -0,0 +1,8 @@
> +/* PR target/79729 */
> +/* { dg-do compile } */
> +
> +void
> +foo (int x)
> +{
> +  __asm__ volatile ("# %R0" : : "n" (129));/* { dg-error "invalid 
> operand code" } */
> +}
>
> Jakub

[PATCH] Another x86 output_operand_lossage fix (PR target/79729)

[Jakub Jelinek]

Hi!

Apparently when fixing these issues earlier I've missed one spot with
gcc_unreachable () dependent on the value that could be provided by user
in bogus inline asm.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2017-02-28  Jakub Jelinek  

PR target/79729
* config/i386/i386.c (ix86_print_operand) : Replace
gcc_unreachable with output_operand_lossage.

* gcc.target/i386/pr79729.c: New test.

--- gcc/config/i386/i386.c.jj   2017-02-28 07:49:33.0 +0100
+++ gcc/config/i386/i386.c  2017-02-28 07:56:38.536106025 +0100
@@ -18228,7 +18228,8 @@ ix86_print_operand (FILE *file, rtx x, i
  fputs ("{rz-sae}", file);
  break;
default:
- gcc_unreachable ();
+ output_operand_lossage ("operand is not a specific integer, "
+ "invalid operand code 'R'");
}
 
  if (ASSEMBLER_DIALECT == ASM_ATT)
--- gcc/testsuite/gcc.target/i386/pr79729.c.jj  2017-02-28 07:58:11.168862088 
+0100
+++ gcc/testsuite/gcc.target/i386/pr79729.c 2017-02-28 07:58:31.401590388 
+0100
@@ -0,0 +1,8 @@
+/* PR target/79729 */
+/* { dg-do compile } */
+
+void
+foo (int x)
+{
+  __asm__ volatile ("# %R0" : : "n" (129));/* { dg-error "invalid operand 
code" } */
+}

Jakub

[PATCH] [ARC] Handle complex PIC move patterns.

[Claudiu Zissulescu]

Hi,

fwprop step is placing in the REG_EQUIV notes constant pic unspecs
expressions.  Then, loop may use these notes for optimizations
rezulting in complex patterns that are not supported by the current
implementation.

The patch adds handling of complex PIC addresses having MINUS or UNARY
operations.

Ok to apply?
Claudiu

gcc/
2017-02-28  Claudiu Zissulescu  

* config/arc/arc.c (arc_legitimize_pic_address): Handle PIC
expressions with MINUS and UNARY ops.

gcc/testsuite
2017-02-28  Claudiu Zissulescu  

* gcc.target/arc/pr9001090948.c: New file.
---
 gcc/config/arc/arc.c| 49 -
 gcc/testsuite/gcc.target/arc/pr9001090948.c | 25 +++
 2 files changed, 73 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/arc/pr9001090948.c

diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index 508a9a6..3b94d7c 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -5024,8 +5024,55 @@ arc_legitimize_pic_address (rtx orig, rtx oldx)
  /* Check that the unspec is one of the ones we generate?  */
  return orig;
}
+ /* fwprop is placing in the REG_EQUIV notes constant pic
+unspecs expressions.  Then, loop may use these notes for
+optimizations rezulting in complex patterns that are not
+supported by the current implementation. The following
+two if-cases are simplifying the complex patters in
+simpler ones.  */
+ else if (GET_CODE (addr) == MINUS)
+   {
+ rtx op0 = XEXP (addr, 0);
+ rtx op1 = XEXP (addr, 1);
+ gcc_assert (oldx);
+ gcc_assert (GET_CODE (op1) == UNSPEC);
+
+ emit_move_insn (oldx,
+ gen_rtx_CONST (SImode,
+arc_legitimize_pic_address (op1,
+
NULL_RTX)));
+ emit_insn (gen_rtx_SET (oldx, gen_rtx_MINUS (SImode, op0, oldx)));
+ return oldx;
+
+   }
+ else if (GET_CODE (addr) != PLUS)
+   {
+ rtx tmp = XEXP (addr, 0);
+ enum rtx_code code = GET_CODE (addr);
+
+ /* It only works for UNARY operations.  */
+ gcc_assert (UNARY_P (addr));
+ gcc_assert (GET_CODE (tmp) == UNSPEC);
+ gcc_assert (oldx);
+
+ emit_move_insn
+   (oldx,
+gen_rtx_CONST (SImode,
+   arc_legitimize_pic_address (tmp,
+   NULL_RTX)));
+
+ emit_insn (gen_rtx_SET (oldx,
+ gen_rtx_fmt_ee (code, SImode,
+ oldx, const0_rtx)));
+
+ return oldx;
+   }
  else
-   gcc_assert (GET_CODE (addr) == PLUS);
+   {
+ gcc_assert (GET_CODE (addr) == PLUS);
+ if (GET_CODE (XEXP (addr, 0)) == UNSPEC)
+   return orig;
+   }
}
 
   if (GET_CODE (addr) == PLUS)
diff --git a/gcc/testsuite/gcc.target/arc/pr9001090948.c 
b/gcc/testsuite/gcc.target/arc/pr9001090948.c
new file mode 100644
index 000..103f4ae
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arc/pr9001090948.c
@@ -0,0 +1,25 @@
+/* { dg-do compile } */
+/* { dg-skip-if "ARC600 doesn't support pic" { arc6xx } } */
+/* { dg-options "-Os -fPIC" } */
+#include 
+#include 
+
+char *
+strip_trail (const char str[], size_t n)
+{
+  static char buf[1025];
+  int j;
+
+  strncpy (buf, str, n);
+  buf[n] = '\0';
+
+  for (j = strlen (buf) - 1; j >= 0; j--)
+{
+  if (buf[j] != ' ')
+break;
+
+  buf[j] = '\0';
+}
+
+  return buf;
+}
-- 
1.9.1

[PATCH] Fix gimple-ssa-store-merging.c on little-endian (PR tree-optimization/79737)

[Jakub Jelinek]

Hi!

The following testcases are miscompiled on little endian targets.
The bug occurs if we are merging bitfield stores, there is a signed bitfield
with bitlen multiple of BITS_PER_UNIT but not equal to the bitsize of the
corresponding mode, the bitfield doesn't start on multiple of BITS_PER_UNIT,
we store negative constant to it and store to field overlapping 7 bits above
this bitfield is done before store to this bitfield.

In particular in the testcases, we have bitfield with bitpos 19, bitlen 24
and store value -5 to it.
That means we use byte_size of 5 (SImode bytesize + 1 extra byte for
shifting), and we end up with 0xfb, 0xff, 0xff, 0xff, 0x00 bytes in tmpbuf.
Next, we find out that there is padding of 1 byte, so decrement byte_size to
4 (again, real byte size of the non-shifted bitfield is 3, but 1 extra byte
for shifting), but as bitlen is a multiple of BITS_PER_UNIT, we don't clear
anything after those 0xfb, 0xff, 0xff bytes.  And then shift_bytes_in_array
just shifts all bytes left and we end up with 0xd8, 0xff, 0xff, 0xff
when we want 0xd8, 0xff, 0xff, 0x07.
Finally these bytes are ored into the real buffer where we've previously
cleared the bitrange (which is why having 0xff in the last byte is harmful).

Now, if bitlen is not a multiple of BITS_PER_UNIT, we already clear that
extra byte plus some bits:
- else
-   clear_bit_region (tmpbuf, bitlen,
- byte_size * BITS_PER_UNIT - bitlen);
Here byte_size is still the actual byte size + 1 and thus say if instead of
bitlen 24 we had bitlen 23, we would have cleared 0xfb, 0xff, 0xff, 0xff,
0x00 tmpbuf to 0xfb, 0xff, 0x7f, 0x00, 0x00.

For big endian, my understanding is that we also rely on tmpbuf[byte_size - 1]
being 0, but we should not suffer from this problem, we clear it first
everywhere, then
  if (native_encode_expr (expr, tmpbuf, byte_size, 0) == 0)
should really just write byte_size - 1 bytes due to the mode (though, I'd
say it would be much clearer if we called
  if (native_encode_expr (expr, tmpbuf, byte_size - 1, 0) == 0)
because that is what we want (ok to make this change?).  Then the padding
adjustment for big-endian is actually tmpbuf += padding, so we move the
start of the buffer, and for obvious reason don't want to access any bytes
before tmpbuf during shifting.

The following patch fixes that, bootstrapped/regtested on x86_64-linux
and i686-linux, ok for trunk (without or with the above native_encode_expr
call change)?
Other options would be to do there tmpbuf[byte_size - 1] = '\0';
unconditionally (we rely on it everywhere, just in other cases it should
be already cleared), or do such clearing inside of the two
shift_bytes_in_array* functions.

2017-02-28  Jakub Jelinek  

PR tree-optimization/79737
* gimple-ssa-store-merging.c (encode_tree_to_bitpos): If bitlen is
a multiple of BITS_PER_UNIT and !BYTES_BIG_ENDIAN, clear
tmpbuf[byte_size - 1].  Formatting fix.
(shift_bytes_in_array_right): Formatting fix.

* gcc.c-torture/execute/pr79737-1.c: New test.
* gcc.c-torture/execute/pr79737-2.c: New test.

--- gcc/gimple-ssa-store-merging.c.jj   2017-01-01 12:45:38.0 +0100
+++ gcc/gimple-ssa-store-merging.c  2017-02-28 10:34:05.848174576 +0100
@@ -253,9 +253,9 @@ shift_bytes_in_array_right (unsigned cha
   unsigned prev_carry_over = carry_over;
   carry_over = ptr[i] & carry_mask;
 
- carry_over <<= (unsigned char) BITS_PER_UNIT - amnt;
- ptr[i] >>= amnt;
- ptr[i] |= prev_carry_over;
+  carry_over <<= (unsigned char) BITS_PER_UNIT - amnt;
+  ptr[i] >>= amnt;
+  ptr[i] |= prev_carry_over;
 }
 }
 
@@ -352,8 +352,9 @@ encode_tree_to_bitpos (tree expr, unsign
 {
   unsigned int first_byte = bitpos / BITS_PER_UNIT;
   tree tmp_int = expr;
-  bool sub_byte_op_p = (bitlen % BITS_PER_UNIT) || (bitpos % BITS_PER_UNIT)
-   || mode_for_size (bitlen, MODE_INT, 0) == BLKmode;
+  bool sub_byte_op_p = ((bitlen % BITS_PER_UNIT)
+   || (bitpos % BITS_PER_UNIT)
+   || mode_for_size (bitlen, MODE_INT, 0) == BLKmode);
 
   if (!sub_byte_op_p)
 return (native_encode_expr (tmp_int, ptr + first_byte, total_bytes, 0)
@@ -418,25 +419,27 @@ encode_tree_to_bitpos (tree expr, unsign
  contain a sign bit due to sign-extension).  */
   unsigned int padding
 = byte_size - ROUND_UP (bitlen, BITS_PER_UNIT) / BITS_PER_UNIT - 1;
-  if (padding != 0
-  || bitlen % BITS_PER_UNIT != 0)
+  /* On big-endian the padding is at the 'front' so just skip the initial
+ bytes.  */
+  if (BYTES_BIG_ENDIAN)
+tmpbuf += padding;
+
+  byte_size -= padding;
+
+  if (bitlen % BITS_PER_UNIT != 0)
 {
-  /* On big-endian the padding is at the 'front' so just skip the initial
-bytes.  */
   if (BYTES_BIG_ENDIAN)
-   tmpbuf += padding;
-
-  byte_size -= padding;
-  if (bitlen % BITS_PER_UNIT != 0)
-   {
- 

[PATCH 0/2] [ARC] Code size mods.

[Claudiu Zissulescu]

Hi,

This series of two patches adds new ARCv2 code-density instructions to
our backend (patch 1). And improves the size figures by using section
anchors and different register allocation order (patch 2).

OK to apply?
Claudiu

Claudiu Zissulescu (2):
  [ARC] Add code density instructions.
  [ARC] Code size modifications.

 gcc/common/config/arc/arc-common.c |   1 +
 gcc/config/arc/arc.c   |  67 +++
 gcc/config/arc/arc.md  | 130 +
 3 files changed, 127 insertions(+), 71 deletions(-)

-- 
1.9.1

[PATCH 1/2] [ARC] Add code density instructions.

[Claudiu Zissulescu]

gcc/
2016-09-16  Claudiu Zissulescu  

* config/arc/arc.c (arc_output_addsi): Emit code density adds.
* config/arc/arc.md (cpu_facility): Add cd variant.
(*movqi_insn): Add code density variant.
(*movhi_insn): Likewise.
(*movqi_insn): Likewise.
(*addsi3_mixed): Likewise.
(subsi3_insn): Likewise.
---
 gcc/config/arc/arc.c  |  11 +
 gcc/config/arc/arc.md | 130 --
 2 files changed, 84 insertions(+), 57 deletions(-)

diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index 3b94d7c..1c929ff 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -7468,6 +7468,17 @@ arc_output_addsi (rtx *operands, bool cond_p, bool 
output_p)
  || (REGNO (operands[0]) == STACK_POINTER_REGNUM
  && match && !(neg_intval & ~124)))
ADDSI_OUTPUT1 ("sub%? %0,%1,%n2");
+
+  if (REG_P(operands[0]) && REG_P(operands[1])
+ && (REGNO(operands[0]) <= 31) && (REGNO(operands[0]) == 
REGNO(operands[1]))
+ && CONST_INT_P (operands[2]) && ( (intval>= -1) && (intval <= 6)))
+   ADDSI_OUTPUT1 ("add%? %0,%1,%2");
+
+  if (TARGET_CODE_DENSITY && REG_P(operands[0]) && REG_P(operands[1])
+ && ((REGNO(operands[0]) == 0) || (REGNO(operands[0]) == 1))
+ && satisfies_constraint_Rcq (operands[1])
+ && satisfies_constraint_L (operands[2]))
+   ADDSI_OUTPUT1 ("add%? %0,%1,%2 ;3");
 }
 
   /* Now try to emit a 32 bit insn without long immediate.  */
diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
index 6c1e167..a06c2ed 100644
--- a/gcc/config/arc/arc.md
+++ b/gcc/config/arc/arc.md
@@ -261,7 +261,7 @@
 - get_attr_length (insn)")))
 
 ; for ARCv2 we need to disable/enable different instruction alternatives
-(define_attr "cpu_facility" "std,av1,av2,fpx"
+(define_attr "cpu_facility" "std,av1,av2,fpx,cd"
   (const_string "std"))
 
 ; We should consider all the instructions enabled until otherwise
@@ -277,6 +277,11 @@
 (and (eq_attr "cpu_facility" "fpx")
  (match_test "TARGET_FP_DP_AX"))
 (const_string "no")
+
+(and (eq_attr "cpu_facility" "cd")
+ (not (and (match_test "TARGET_V2")
+   (match_test "TARGET_CODE_DENSITY"
+(const_string "no")
 ]
(const_string "yes")))
 
@@ -611,8 +616,8 @@
 ; The iscompact attribute allows the epilogue expander to know for which
 ; insns it should lengthen the return insn.
 (define_insn "*movqi_insn"
-  [(set (match_operand:QI 0 "move_dest_operand" "=Rcq,Rcq#q,w,   h, 
w,w,???w, w,Rcq,  S,!*x,  r,r, Ucm,m,???m")
-   (match_operand:QI 1 "move_src_operand"  "  cL,   
cP,Rcq#q,hCm1,cL,I,?Rac,?i,  T,Rcq,Usd,Ucm,m,?Rac,c,?Rac"))]
+  [(set (match_operand:QI 0 "move_dest_operand" "=Rcq,Rcq#q,w,Rcq#q,   h, 
w,w,???w,h, w,Rcq,  S,!*x,  r,r, Ucm,m,???m,Usc")
+   (match_operand:QI 1 "move_src_operand"  "  cL,   cP,Rcq#q,
P,hCm1,cL,I,?Rac,i,?i,  T,Rcq,Usd,Ucm,m,?Rac,c,?Rac,Cm3"))]
   "register_operand (operands[0], QImode)
|| register_operand (operands[1], QImode)"
   "@
@@ -620,6 +625,8 @@
mov%? %0,%1%&
mov%? %0,%1%&
mov%? %0,%1%&
+   mov%? %0,%1%&
+   mov%? %0,%1
mov%? %0,%1
mov%? %0,%1
mov%? %0,%1
@@ -631,11 +638,12 @@
ldb%U1%V1 %0,%1
xstb%U0 %1,%0
stb%U0%V0 %1,%0
+   stb%U0%V0 %1,%0
stb%U0%V0 %1,%0"
-  [(set_attr "type" 
"move,move,move,move,move,move,move,move,load,store,load,load,load,store,store,store")
-   (set_attr "iscompact" 
"maybe,maybe,maybe,true,false,false,false,false,true,true,true,false,false,false,false,false")
-   (set_attr "predicable" 
"yes,no,yes,no,yes,no,yes,yes,no,no,no,no,no,no,no,no")
-   (set_attr "cpu_facility" "*,*,av1,av2,*,*,*,*,*,*,*,*,*,*,*,*")])
+  [(set_attr "type" 
"move,move,move,move,move,move,move,move,move,move,load,store,load,load,load,store,store,store,store")
+   (set_attr "iscompact" 
"maybe,maybe,maybe,true,true,false,false,false,maybe_limm,false,true,true,true,false,false,false,false,false,false")
+   (set_attr "predicable" 
"yes,no,yes,no,no,yes,no,yes,yes,yes,no,no,no,no,no,no,no,no,no")
+   (set_attr "cpu_facility" 
"av1,av1,av1,av2,av2,*,*,*,*,*,*,*,*,*,*,*,*,*,*")])
 
 (define_expand "movhi"
   [(set (match_operand:HI 0 "move_dest_operand" "")
@@ -644,8 +652,8 @@
   "if (prepare_move_operands (operands, HImode)) DONE;")
 
 (define_insn "*movhi_insn"
-  [(set (match_operand:HI 0 "move_dest_operand" "=Rcq,Rcq#q,w,   h, 
w,w,???w,Rcq#q, w,Rcq,  S,  r,r, Ucm,m,???m,VUsc,VUsc")
-   (match_operand:HI 1 "move_src_operand" "   cL,   
cP,Rcq#q,hCm1,cL,I,?Rac,   ?i,?i,  T,Rcq,Ucm,m,?Rac,c,?Rac, Cm3,i"))]
+  [(set (match_operand:HI 0 "move_dest_operand" "=Rcq,Rcq#q,w,Rcq#q,   h, 
w,w,???w,Rcq#q,h, w,Rcq,  S,  r,r, Ucm,m,???m,VUsc,VUsc")
+   (match_operand:HI 1 "move_src_operand" "   cL,   cP,Rcq#q,
P,hCm1,cL,I,?Rac,i,i,?i,  T,Rcq,Ucm,m,?Rac,c,?Rac, Cm3,i"))]
   

[PATCH 2/2] [ARC] Code size modifications.

[Claudiu Zissulescu]

gcc/
2016-09-20  Claudiu Zissulescu  

* config/arc/arc.c (arc_init): Use multiplier whenever we have it.
(arc_conditional_register_usage): Use a different allocation order
when optimizing for size.
* common/config/arc/arc-common.c (arc_option_optimization_table):
Section anchors default on when optimizing for size.
---
 gcc/common/config/arc/arc-common.c |  1 +
 gcc/config/arc/arc.c   | 56 --
 2 files changed, 43 insertions(+), 14 deletions(-)

diff --git a/gcc/common/config/arc/arc-common.c 
b/gcc/common/config/arc/arc-common.c
index 88bfec6..82e0dd3 100644
--- a/gcc/common/config/arc/arc-common.c
+++ b/gcc/common/config/arc/arc-common.c
@@ -46,6 +46,7 @@ arc_option_init_struct (struct gcc_options *opts)
 #define OPT_LEVELS_3_PLUS_SPEED_ONLY OPT_LEVELS_3_PLUS
 static const struct default_options arc_option_optimization_table[] =
   {
+{ OPT_LEVELS_SIZE, OPT_fsection_anchors, NULL, 1 },
 { OPT_LEVELS_1_PLUS, OPT_fomit_frame_pointer, NULL, 1 },
 { OPT_LEVELS_ALL, OPT_mRcq, NULL, 1 },
 { OPT_LEVELS_ALL, OPT_mRcw, NULL, 1 },
diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index 1c929ff..bde3c30 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -679,6 +679,12 @@ make_pass_arc_predicate_delay_insns (gcc::context *ctxt)
 static void
 arc_init (void)
 {
+  if (TARGET_V2)
+{
+  /* I have the multiplier, then use it*/
+  if (TARGET_MPYW || TARGET_MULTI)
+ arc_multcost = COSTS_N_INSNS (1);
+}
   /* Note: arc_multcost is only used in rtx_cost if speed is true.  */
   if (arc_multcost < 0)
 switch (arc_tune)
@@ -1377,20 +1383,42 @@ arc_conditional_register_usage (void)
 }
   if (TARGET_Q_CLASS)
 {
-  reg_alloc_order[2] = 12;
-  reg_alloc_order[3] = 13;
-  reg_alloc_order[4] = 14;
-  reg_alloc_order[5] = 15;
-  reg_alloc_order[6] = 1;
-  reg_alloc_order[7] = 0;
-  reg_alloc_order[8] = 4;
-  reg_alloc_order[9] = 5;
-  reg_alloc_order[10] = 6;
-  reg_alloc_order[11] = 7;
-  reg_alloc_order[12] = 8;
-  reg_alloc_order[13] = 9;
-  reg_alloc_order[14] = 10;
-  reg_alloc_order[15] = 11;
+  if (optimize_size)
+   {
+ reg_alloc_order[0] = 0;
+ reg_alloc_order[1] = 1;
+ reg_alloc_order[2] = 2;
+ reg_alloc_order[3] = 3;
+ reg_alloc_order[4] = 12;
+ reg_alloc_order[5] = 13;
+ reg_alloc_order[6] = 14;
+ reg_alloc_order[7] = 15;
+ reg_alloc_order[8] = 4;
+ reg_alloc_order[9] = 5;
+ reg_alloc_order[10] = 6;
+ reg_alloc_order[11] = 7;
+ reg_alloc_order[12] = 8;
+ reg_alloc_order[13] = 9;
+ reg_alloc_order[14] = 10;
+ reg_alloc_order[15] = 11;
+   }
+  else
+   {
+ reg_alloc_order[2] = 12;
+ reg_alloc_order[3] = 13;
+ reg_alloc_order[4] = 14;
+ reg_alloc_order[5] = 15;
+ reg_alloc_order[6] = 1;
+ reg_alloc_order[7] = 0;
+ reg_alloc_order[8] = 4;
+ reg_alloc_order[9] = 5;
+ reg_alloc_order[10] = 6;
+ reg_alloc_order[11] = 7;
+ reg_alloc_order[12] = 8;
+ reg_alloc_order[13] = 9;
+ reg_alloc_order[14] = 10;
+ reg_alloc_order[15] = 11;
+   }
 }
   if (TARGET_SIMD_SET)
 {
-- 
1.9.1

Re: [PATCH] Do not allow to run GIMPLE or RTL test-cases w/ LTO (PR lto/79625).

[Richard Biener]

On Tue, Feb 28, 2017 at 4:39 PM, Martin Liška  wrote:
> On 02/28/2017 04:36 PM, Richard Biener wrote:
>> On Tue, Feb 28, 2017 at 4:15 PM, Martin Liška  wrote:
>>> On 02/28/2017 03:45 PM, Richard Biener wrote:
 On Tue, Feb 28, 2017 at 2:51 PM, Martin Liška  wrote:
> Hello.
>
> As mentioned in the PR, I hope rejecting -flto option with both GIMPLE 
> and RTL can
> work for the issue.
>
> Ready after it finishes regression tests?

 Actually GIMPLE should work fine if you make sure to start compilation
 before LTO streaming,
 if you don't it also won't ICE, will it?
>>>
>>> Hm, can't find startwith value that will cause that. Btw. why choosing an 
>>> invalid startwith
>>> option does not display an error message? Should I report that?
>>>
>>> Do you have a candidate option that can possibly trigger an ICE ("stdarg" 
>>> works for me).
>>
>> I think it'll never ICE but it will just eventually fail to link
>> (because the function is not streamed).
>
> Thus it's fine for me. May I install just the RTL hunk after my tests will 
> finish?

Yes.

> M.
>
>>
>> Richard.
>>
>>> Martin
>>>

 Richard.

> Thanks,
> Martin
>>>
>

Re: [PATCH] Workaround premature bitfield folding (PR c++/79681)

[Richard Biener]

On Tue, 28 Feb 2017, Jakub Jelinek wrote:

> Hi!
> 
> make_bit_field_ref and its callers are invoked not just during GIMPLE (where
> at least fold_truth_andor* isn't really effective; but from what I've tested
> it doesn't do a good job in many cases at GENERIC either, because we
> fold x.btfld == y.btfld too early into ((BIT_FIELD_REF ^ BIT_FIELD_REF) & 
> cst) == 0
> or similar and fold_truth_andor* can't handle that), but also during GENERIC
> and strip away the whole component access path if there are only constant
> offsets (various nested COMPONENT_REFs as well as ARRAY_REFs).  That is not
> really good for constexpr evaluation (we should evaluate constexpr on saved
> fn trees before folding, but that is not GCC7 material), which then can't
> locate where to look for the value.
> 
> This patch just attempts to reuse as much as possible from orig_inner and
> only use adjusted BIT_FIELD_REF on that when in GENERIC (first I've tried to
> use instead COMPONENT_REF with DECL_BIT_FIELD_REPRESENTATIVE, but that isn't
> handled by constexpr.c either).
> Bootstrapped/regtested on x86_64/i686-linux, ok for trunk?

Hmm, I'd rather not do anything is_gimple_form specific.  Can't we
restrict this transform to work on the outermost handled-component only?
Ideally we'd want to find a common base of course.

The folding is also guarded with optimize != 0 so maybe simply disable
it from the FEs?  (but yes, you say it does a bad job on GIMPLE
which is quite understandable as there's no TRUTH_*, but we can
eventually call it from gimplification instead?)

Bah, just not really liking these kind of "hacks"...

Richaard.

> 2017-02-28  Jakub Jelinek  
> 
>   PR c++/79681
>   * fold-const.c (make_bit_field_ref): During FE parsing if orig_inner
>   is COMPONENT_REF, attempt to use its first operand as BIT_FIELD_REF
>   base.
> 
>   * g++.dg/cpp1y/constexpr-79681-1.C: New test.
>   * g++.dg/cpp1y/constexpr-79681-2.C: New test.
> 
> --- gcc/fold-const.c.jj   2017-02-17 18:29:24.0 +0100
> +++ gcc/fold-const.c  2017-02-27 15:05:43.743266260 +0100
> @@ -3862,6 +3862,31 @@ make_bit_field_ref (location_t loc, tree
>  {
>tree result, bftype;
>  
> +  /* Attempt not to lose access path if possible during FE folding.  */
> +  if (!in_gimple_form && TREE_CODE (orig_inner) == COMPONENT_REF)
> +{
> +  tree ninner = TREE_OPERAND (orig_inner, 0);
> +  machine_mode nmode;
> +  HOST_WIDE_INT nbitsize, nbitpos;
> +  tree noffset;
> +  int nunsignedp, nreversep, nvolatilep = 0;
> +  tree base = get_inner_reference (ninner, , ,
> +, , ,
> +, );
> +  if (base == inner
> +   && noffset == NULL_TREE
> +   && nbitsize >= bitsize
> +   && nbitpos <= bitpos
> +   && bitpos + bitsize <= nbitpos + nbitsize
> +   && !reversep
> +   && !nreversep
> +   && !nvolatilep)
> + {
> +   inner = ninner;
> +   bitpos -= nbitpos;
> + }
> +}
> +
>alias_set_type iset = get_alias_set (orig_inner);
>if (iset == 0 && get_alias_set (inner) != iset)
>  inner = fold_build2 (MEM_REF, TREE_TYPE (inner),
> --- gcc/testsuite/g++.dg/cpp1y/constexpr-79681-1.C.jj 2017-02-27 
> 15:11:39.177589060 +0100
> +++ gcc/testsuite/g++.dg/cpp1y/constexpr-79681-1.C2017-02-27 
> 15:11:28.0 +0100
> @@ -0,0 +1,17 @@
> +// PR c++/79681
> +// { dg-do compile { target c++14 } }
> +// { dg-options "-O2" }
> +
> +struct A
> +{
> +  int i : 4;
> +};
> +
> +constexpr bool
> +foo ()
> +{
> +  A x[] = { 1 };
> +  return x[0].i;
> +}
> +
> +static_assert (foo(), "");
> --- gcc/testsuite/g++.dg/cpp1y/constexpr-79681-2.C.jj 2017-02-27 
> 15:11:42.252548562 +0100
> +++ gcc/testsuite/g++.dg/cpp1y/constexpr-79681-2.C2017-02-27 
> 15:10:13.0 +0100
> @@ -0,0 +1,39 @@
> +// PR c++/79681
> +// { dg-do compile { target c++14 } }
> +// { dg-options "-O2" }
> +
> +struct A
> +{
> +  char i : 4;
> +  char k : 1;
> +  char l : 3;
> +};
> +struct B
> +{
> +  char j : 4;
> +};
> +struct C
> +{
> +  long long u;
> +  A a[1];
> +  B b[1];
> +};
> +
> +constexpr bool
> +foo ()
> +{
> +  C c = { 0, { { 5, 0, 2 } }, { { 6 } } };
> +  C d = { 0, { { 6, 0, 1 } }, { { 5 } } };
> +  return c.a[0].i == d.a[0].i && c.b[0].j == d.b[0].j;
> +}
> +
> +constexpr bool
> +bar ()
> +{
> +  C c = { 0, { { 5, 0, 2 } }, { { 6 } } };
> +  C d = { 0, { { 6, 0, 1 } }, { { 5 } } };
> +  return c.a[0].i == d.a[0].i && c.a[0].l == d.a[0].l;
> +}
> +
> +static_assert (foo () == false, "");
> +static_assert (bar () == false, "");
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: [PATCH] Do not allow to run GIMPLE or RTL test-cases w/ LTO (PR lto/79625).

[Martin Liška]

On 02/28/2017 04:36 PM, Richard Biener wrote:
> On Tue, Feb 28, 2017 at 4:15 PM, Martin Liška  wrote:
>> On 02/28/2017 03:45 PM, Richard Biener wrote:
>>> On Tue, Feb 28, 2017 at 2:51 PM, Martin Liška  wrote:
 Hello.

 As mentioned in the PR, I hope rejecting -flto option with both GIMPLE and 
 RTL can
 work for the issue.

 Ready after it finishes regression tests?
>>>
>>> Actually GIMPLE should work fine if you make sure to start compilation
>>> before LTO streaming,
>>> if you don't it also won't ICE, will it?
>>
>> Hm, can't find startwith value that will cause that. Btw. why choosing an 
>> invalid startwith
>> option does not display an error message? Should I report that?
>>
>> Do you have a candidate option that can possibly trigger an ICE ("stdarg" 
>> works for me).
> 
> I think it'll never ICE but it will just eventually fail to link
> (because the function is not streamed).

Thus it's fine for me. May I install just the RTL hunk after my tests will 
finish?

M.

> 
> Richard.
> 
>> Martin
>>
>>>
>>> Richard.
>>>
 Thanks,
 Martin
>>

Re: [RFA PATCH, i386]: Warn for 64-bit values in general-reg asm operands and error out for 8-bit values in invalid GR asm operand

[Jakub Jelinek]

On Tue, Feb 28, 2017 at 04:34:20PM +0100, Uros Bizjak wrote:
> > Have you tried to build say Linux kernel or firefox or similar large
> > codebase with lots of inline asm with that?
> 
> No...
> 
> > What constraint should people use for long long vars in 32-bit code?
> > "A" constraint is used a lot in 32-bit code (say for inline asm with
> > rdtsc), but what if you need more than one long long input?
> 
> Hm, we don't guarantee DImode register pairs other that "A"
> constraint. But you are right, we have to allow "A" for 64bit eax/edx
> pair.
> 
> Please consider the 64bit warning part dropped.

The 8-bit error is fine, unless the operand isn't used, it would hopefully
fail to assemble anyway.

Jakub

Re: [PATCH] Do not allow to run GIMPLE or RTL test-cases w/ LTO (PR lto/79625).

[Richard Biener]

On Tue, Feb 28, 2017 at 4:15 PM, Martin Liška  wrote:
> On 02/28/2017 03:45 PM, Richard Biener wrote:
>> On Tue, Feb 28, 2017 at 2:51 PM, Martin Liška  wrote:
>>> Hello.
>>>
>>> As mentioned in the PR, I hope rejecting -flto option with both GIMPLE and 
>>> RTL can
>>> work for the issue.
>>>
>>> Ready after it finishes regression tests?
>>
>> Actually GIMPLE should work fine if you make sure to start compilation
>> before LTO streaming,
>> if you don't it also won't ICE, will it?
>
> Hm, can't find startwith value that will cause that. Btw. why choosing an 
> invalid startwith
> option does not display an error message? Should I report that?
>
> Do you have a candidate option that can possibly trigger an ICE ("stdarg" 
> works for me).

I think it'll never ICE but it will just eventually fail to link
(because the function is not streamed).

Richard.

> Martin
>
>>
>> Richard.
>>
>>> Thanks,
>>> Martin
>

[PATCH] Workaround premature bitfield folding (PR c++/79681)

[Jakub Jelinek]

Hi!

make_bit_field_ref and its callers are invoked not just during GIMPLE (where
at least fold_truth_andor* isn't really effective; but from what I've tested
it doesn't do a good job in many cases at GENERIC either, because we
fold x.btfld == y.btfld too early into ((BIT_FIELD_REF ^ BIT_FIELD_REF) & cst) 
== 0
or similar and fold_truth_andor* can't handle that), but also during GENERIC
and strip away the whole component access path if there are only constant
offsets (various nested COMPONENT_REFs as well as ARRAY_REFs).  That is not
really good for constexpr evaluation (we should evaluate constexpr on saved
fn trees before folding, but that is not GCC7 material), which then can't
locate where to look for the value.

This patch just attempts to reuse as much as possible from orig_inner and
only use adjusted BIT_FIELD_REF on that when in GENERIC (first I've tried to
use instead COMPONENT_REF with DECL_BIT_FIELD_REPRESENTATIVE, but that isn't
handled by constexpr.c either).
Bootstrapped/regtested on x86_64/i686-linux, ok for trunk?

2017-02-28  Jakub Jelinek  

PR c++/79681
* fold-const.c (make_bit_field_ref): During FE parsing if orig_inner
is COMPONENT_REF, attempt to use its first operand as BIT_FIELD_REF
base.

* g++.dg/cpp1y/constexpr-79681-1.C: New test.
* g++.dg/cpp1y/constexpr-79681-2.C: New test.

--- gcc/fold-const.c.jj 2017-02-17 18:29:24.0 +0100
+++ gcc/fold-const.c2017-02-27 15:05:43.743266260 +0100
@@ -3862,6 +3862,31 @@ make_bit_field_ref (location_t loc, tree
 {
   tree result, bftype;
 
+  /* Attempt not to lose access path if possible during FE folding.  */
+  if (!in_gimple_form && TREE_CODE (orig_inner) == COMPONENT_REF)
+{
+  tree ninner = TREE_OPERAND (orig_inner, 0);
+  machine_mode nmode;
+  HOST_WIDE_INT nbitsize, nbitpos;
+  tree noffset;
+  int nunsignedp, nreversep, nvolatilep = 0;
+  tree base = get_inner_reference (ninner, , ,
+  , , ,
+  , );
+  if (base == inner
+ && noffset == NULL_TREE
+ && nbitsize >= bitsize
+ && nbitpos <= bitpos
+ && bitpos + bitsize <= nbitpos + nbitsize
+ && !reversep
+ && !nreversep
+ && !nvolatilep)
+   {
+ inner = ninner;
+ bitpos -= nbitpos;
+   }
+}
+
   alias_set_type iset = get_alias_set (orig_inner);
   if (iset == 0 && get_alias_set (inner) != iset)
 inner = fold_build2 (MEM_REF, TREE_TYPE (inner),
--- gcc/testsuite/g++.dg/cpp1y/constexpr-79681-1.C.jj   2017-02-27 
15:11:39.177589060 +0100
+++ gcc/testsuite/g++.dg/cpp1y/constexpr-79681-1.C  2017-02-27 
15:11:28.0 +0100
@@ -0,0 +1,17 @@
+// PR c++/79681
+// { dg-do compile { target c++14 } }
+// { dg-options "-O2" }
+
+struct A
+{
+  int i : 4;
+};
+
+constexpr bool
+foo ()
+{
+  A x[] = { 1 };
+  return x[0].i;
+}
+
+static_assert (foo(), "");
--- gcc/testsuite/g++.dg/cpp1y/constexpr-79681-2.C.jj   2017-02-27 
15:11:42.252548562 +0100
+++ gcc/testsuite/g++.dg/cpp1y/constexpr-79681-2.C  2017-02-27 
15:10:13.0 +0100
@@ -0,0 +1,39 @@
+// PR c++/79681
+// { dg-do compile { target c++14 } }
+// { dg-options "-O2" }
+
+struct A
+{
+  char i : 4;
+  char k : 1;
+  char l : 3;
+};
+struct B
+{
+  char j : 4;
+};
+struct C
+{
+  long long u;
+  A a[1];
+  B b[1];
+};
+
+constexpr bool
+foo ()
+{
+  C c = { 0, { { 5, 0, 2 } }, { { 6 } } };
+  C d = { 0, { { 6, 0, 1 } }, { { 5 } } };
+  return c.a[0].i == d.a[0].i && c.b[0].j == d.b[0].j;
+}
+
+constexpr bool
+bar ()
+{
+  C c = { 0, { { 5, 0, 2 } }, { { 6 } } };
+  C d = { 0, { { 6, 0, 1 } }, { { 5 } } };
+  return c.a[0].i == d.a[0].i && c.a[0].l == d.a[0].l;
+}
+
+static_assert (foo () == false, "");
+static_assert (bar () == false, "");

Jakub

[PATCH] Fix PR79721

[Richard Biener]

The following fixes final value replacement introducing undefined 
overflow.  The issue is in how we compute Newtons interpolating
formula which really needs to be done in a type that has well-defined
overflow behavior.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Eventually the hack in value-replacement to rewrite stuff to unsigned
arithmetic can go away after this but this is for GCC 8.

Richard.

2017-02-28  Richard Biener  

PR middle-end/79721
* tree-chrec.c (chrec_evaluate): Perform computation of Newtons
interpolating formula in wrapping arithmetic.
(chrec_apply): Convert chrec_evaluate return value to wanted type.

* gcc.dg/torture/pr79721.c: New testcase.

Index: gcc/tree-chrec.c
===
*** gcc/tree-chrec.c(revision 245772)
--- gcc/tree-chrec.c(working copy)
*** tree_fold_binomial (tree type, tree n, u
*** 536,542 
  }
  
  /* Helper function.  Use the Newton's interpolating formula for
!evaluating the value of the evolution function.  */
  
  static tree
  chrec_evaluate (unsigned var, tree chrec, tree n, unsigned int k)
--- 536,543 
  }
  
  /* Helper function.  Use the Newton's interpolating formula for
!evaluating the value of the evolution function.
!The result may be in an unsigned type of CHREC.  */
  
  static tree
  chrec_evaluate (unsigned var, tree chrec, tree n, unsigned int k)
*** chrec_evaluate (unsigned var, tree chrec
*** 549,573 
 && flow_loop_nested_p (var_loop, get_chrec_loop (chrec)))
  chrec = CHREC_LEFT (chrec);
  
if (TREE_CODE (chrec) == POLYNOMIAL_CHREC
&& CHREC_VARIABLE (chrec) == var)
  {
arg1 = chrec_evaluate (var, CHREC_RIGHT (chrec), n, k + 1);
if (arg1 == chrec_dont_know)
return chrec_dont_know;
!   binomial_n_k = tree_fold_binomial (type, n, k);
if (!binomial_n_k)
return chrec_dont_know;
!   arg0 = fold_build2 (MULT_EXPR, type,
! CHREC_LEFT (chrec), binomial_n_k);
!   return chrec_fold_plus (type, arg0, arg1);
  }
  
!   binomial_n_k = tree_fold_binomial (type, n, k);
if (!binomial_n_k)
  return chrec_dont_know;
  
!   return fold_build2 (MULT_EXPR, type, chrec, binomial_n_k);
  }
  
  /* Evaluates "CHREC (X)" when the varying variable is VAR.
--- 550,582 
 && flow_loop_nested_p (var_loop, get_chrec_loop (chrec)))
  chrec = CHREC_LEFT (chrec);
  
+   /* The formula associates the expression and thus we have to make
+  sure to not introduce undefined overflow.  */
+   tree ctype = type;
+   if (INTEGRAL_TYPE_P (type)
+   && ! TYPE_OVERFLOW_WRAPS (type))
+ ctype = unsigned_type_for (type);
+ 
if (TREE_CODE (chrec) == POLYNOMIAL_CHREC
&& CHREC_VARIABLE (chrec) == var)
  {
arg1 = chrec_evaluate (var, CHREC_RIGHT (chrec), n, k + 1);
if (arg1 == chrec_dont_know)
return chrec_dont_know;
!   binomial_n_k = tree_fold_binomial (ctype, n, k);
if (!binomial_n_k)
return chrec_dont_know;
!   tree l = chrec_convert (ctype, CHREC_LEFT (chrec), NULL);
!   arg0 = fold_build2 (MULT_EXPR, ctype, l, binomial_n_k);
!   return chrec_fold_plus (ctype, arg0, arg1);
  }
  
!   binomial_n_k = tree_fold_binomial (ctype, n, k);
if (!binomial_n_k)
  return chrec_dont_know;
  
!   return fold_build2 (MULT_EXPR, ctype,
! chrec_convert (ctype, chrec, NULL), binomial_n_k);
  }
  
  /* Evaluates "CHREC (X)" when the varying variable is VAR.
*** chrec_apply (unsigned var,
*** 623,629 
else if (TREE_CODE (x) == INTEGER_CST
   && tree_int_cst_sgn (x) == 1)
/* testsuite/.../ssa-chrec-38.c.  */
!   res = chrec_evaluate (var, chrec, x, 0);
else
res = chrec_dont_know;
break;
--- 632,638 
else if (TREE_CODE (x) == INTEGER_CST
   && tree_int_cst_sgn (x) == 1)
/* testsuite/.../ssa-chrec-38.c.  */
!   res = chrec_convert (type, chrec_evaluate (var, chrec, x, 0), NULL);
else
res = chrec_dont_know;
break;
Index: gcc/testsuite/gcc.dg/torture/pr79721.c
===
*** gcc/testsuite/gcc.dg/torture/pr79721.c  (nonexistent)
--- gcc/testsuite/gcc.dg/torture/pr79721.c  (working copy)
***
*** 0 
--- 1,21 
+ /* { dg-do run }  */
+ /* { dg-require-effective-target int32plus } */
+ /* We use -ftrapv so that when SCEV final value replacement introduces
+undefined overflow we trap.  UBSAN inhibits final value replacement.  */
+ /* { dg-additional-options "-ftrapv" } */
+ 
+ int __attribute__((noclone,noinline))
+ foo(int a, int b)
+ {
+   int sum = 0;
+   for (int i = 0; i < 6; i++)
+ sum += a + i * b;
+   return sum;
+ }
+ 
+ int main(int argc, char **argv)
+ {
+  

Re: [RFA PATCH, i386]: Warn for 64-bit values in general-reg asm operands and error out for 8-bit values in invalid GR asm operand

[Uros Bizjak]

On Tue, Feb 28, 2017 at 12:06 PM, Jakub Jelinek  wrote:
> On Tue, Feb 28, 2017 at 11:41:56AM +0100, Richard Biener wrote:
>> > 2017-02-28  Uros Bizjak  
>> >
>> > * config/i386/i386.c (print_reg): Warn for values of 64-bit size
>> > in integer register on 32-bit targets.  Error out for values of
>> > 8-bit size in invalid integer register.
>> >
>> > testsuite/ChangeLog:
>> >
>> > 2017-02-28  Uros Bizjak  
>> >
>> > * gcc.target/i386/invsize-1.c: New test.
>> > * gcc.target/i386/invsize-2.c: Ditto.
>> >
>> > OK for mainline in stage 4?
>>
>> Yes.
>
> Have you tried to build say Linux kernel or firefox or similar large
> codebase with lots of inline asm with that?

No...

> What constraint should people use for long long vars in 32-bit code?
> "A" constraint is used a lot in 32-bit code (say for inline asm with
> rdtsc), but what if you need more than one long long input?

Hm, we don't guarantee DImode register pairs other that "A"
constraint. But you are right, we have to allow "A" for 64bit eax/edx
pair.

Please consider the 64bit warning part dropped.

Uros.

[PATCH 1/2] [ARC] Fix conditional move contstraint

[Claudiu Zissulescu]

Move pattern (movsi_insn) allows predicated instructions to be
instructions which can hold all registers.  However, the conditional
variant doesn't.  This patch fixes this problem.

2017-02-28  Claudiu Zissulescu  

* config/arc/arc.md (movsi_cond_exec): Update constraint.
---
 gcc/config/arc/arc.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
index f01a1ba..3aaedd2 100644
--- a/gcc/config/arc/arc.md
+++ b/gcc/config/arc/arc.md
@@ -3646,7 +3646,7 @@
  (match_operator 3 "proper_comparison_operator"
[(match_operand 2 "cc_register" "Rcc,Rcc") (const_int 0)])
  (set (match_operand:SI 0 "dest_reg_operand" "=w,w")
- (match_operand:SI 1 "nonmemory_operand" "Lc,?Cal")))]
+ (match_operand:SI 1 "nonmemory_operand" "LRac,?Cal")))]
   ""
   "mov.%d3 %0,%S1"
   [(set_attr "type" "cmove")
-- 
1.9.1

[PATCH 0/2] [ARC] Two small patches to fix faulty instruction patterns.

[Claudiu Zissulescu]

Hi,

This series of two patches fixes a typo in tst instruction, and a faulty mov 
conditional instruction.

Ok to apply?
Claudiu

Claudiu Zissulescu (2):
  [ARC] Fix conditional move contstraint
  Fix tst_bitfield_tst pattern.

 gcc/config/arc/arc.md   |  4 ++--
 gcc/testsuite/gcc.target/arc/bitfield.c | 28 
 2 files changed, 30 insertions(+), 2 deletions(-)
 create mode 100755 gcc/testsuite/gcc.target/arc/bitfield.c

-- 
1.9.1

[PATCH 2/2] [ARC] Fix tst_bitfield_tst pattern.

[Claudiu Zissulescu]

Fixes a typo, adds a test.

gcc/
2017-02-28  Claudiu Zissulescu  

* config/arc/arc.md (*tst_bitfield_tst): Fix pattern.

gcc/testsuite
2017-02-28  Claudiu Zissulescu  

* gcc.target/arc/bitfield.c: New file.
---
 gcc/config/arc/arc.md   |  2 +-
 gcc/testsuite/gcc.target/arc/bitfield.c | 28 
 2 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100755 gcc/testsuite/gcc.target/arc/bitfield.c

diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
index 3aaedd2..6c1e167 100644
--- a/gcc/config/arc/arc.md
+++ b/gcc/config/arc/arc.md
@@ -888,7 +888,7 @@
&& (INTVAL (operands[3]) + INTVAL (operands[2]) <= 11
|| (INTVAL (operands[3]) <= 11
   && INTVAL (operands[3]) + INTVAL (operands[2]) == 32))"
-  "tst %1,(1<<%2)-1<<%3"
+  "tst %1,((1<<%2)-1)<<%3"
   [(set_attr "type" "compare")
(set_attr "cond" "set_zn")
(set_attr "length" "4")])
diff --git a/gcc/testsuite/gcc.target/arc/bitfield.c 
b/gcc/testsuite/gcc.target/arc/bitfield.c
new file mode 100755
index 000..187cd1d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arc/bitfield.c
@@ -0,0 +1,28 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+#include 
+
+struct ubifs_budget_req {
+  unsigned int fast:7;
+  unsigned int new_ino_d:13;
+};
+
+int printf(const char *format, ...);
+
+void __attribute__ ((noinline))
+fff(struct ubifs_budget_req *req)
+{
+  if (req->new_ino_d & 7)
+abort ();
+}
+
+int main (void)
+{
+  struct ubifs_budget_req req = {
+.fast = 8,
+.new_ino_d = 0,
+  };
+  fff();
+  return 0;
+}
-- 
1.9.1

Re: [PATCH] Fix PR79740

[Richard Biener]

On Tue, 28 Feb 2017, Richard Biener wrote:

> 
> Bootstrap / regtest running on x86_64-unknown-linux-gnu.
> 
> Richard.

The following is what I committed.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

Richard.

2017-02-28  Richard Biener  

PR tree-optimization/79740
* tree-ssa-sccvn.c (vn_nary_op_insert_into): Allow redundant
inserts.
(visit_nary_op): Insert the nary into the hashtable if we
pattern-matched sth.
* tree-ssa-pre.c (eliminate_insert): Robustify.

* gcc.dg/torture/pr79740.c: New testcase.

Index: gcc/tree-ssa-sccvn.c
===
*** gcc/tree-ssa-sccvn.c(revision 245772)
--- gcc/tree-ssa-sccvn.c(working copy)
*** vn_nary_op_insert_into (vn_nary_op_t vno
*** 2820,2825 
--- 2820,2834 
  vno->hashcode = vn_nary_op_compute_hash (vno);
  
slot = table->find_slot_with_hash (vno, vno->hashcode, INSERT);
+   /* While we do not want to insert things twice it's awkward to
+  avoid it in the case where visit_nary_op pattern-matches stuff
+  and ends up simplifying the replacement to itself.  We then
+  get two inserts, one from visit_nary_op and one from
+  vn_nary_build_or_lookup.
+  So allow inserts with the same value number.  */
+   if (*slot && (*slot)->result == vno->result)
+ return *slot;
+ 
gcc_assert (!*slot);
  
*slot = vno;
*** visit_nary_op (tree lhs, gassign *stmt)
*** 3544,3550 
  result = vn_nary_build_or_lookup (NOP_EXPR,
type, ops);
  if (result)
!   return set_ssa_val_to (lhs, result);
}
  else
{
--- 3553,3563 
  result = vn_nary_build_or_lookup (NOP_EXPR,
type, ops);
  if (result)
!   {
! bool changed = set_ssa_val_to (lhs, result);
! vn_nary_op_insert_stmt (stmt, result);
! return changed;
!   }
}
  else
{
*** visit_nary_op (tree lhs, gassign *stmt)
*** 3555,3561 
TREE_TYPE (lhs),
ops);
  if (result)
!   return set_ssa_val_to (lhs, result);
}
}
}
--- 3568,3578 
TREE_TYPE (lhs),
ops);
  if (result)
!   {
! bool changed = set_ssa_val_to (lhs, result);
! vn_nary_op_insert_stmt (stmt, result);
! return changed;
!   }
}
}
}
Index: gcc/tree-ssa-pre.c
===
*** gcc/tree-ssa-pre.c  (revision 245772)
--- gcc/tree-ssa-pre.c  (working copy)
*** eliminate_push_avail (tree op)
*** 4099,4106 
  static tree
  eliminate_insert (gimple_stmt_iterator *gsi, tree val)
  {
!   gimple *stmt = gimple_seq_first_stmt (VN_INFO (val)->expr);
!   if (!is_gimple_assign (stmt)
|| (!CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (stmt))
  && gimple_assign_rhs_code (stmt) != VIEW_CONVERT_EXPR
  && gimple_assign_rhs_code (stmt) != BIT_FIELD_REF
--- 4099,4110 
  static tree
  eliminate_insert (gimple_stmt_iterator *gsi, tree val)
  {
!   /* We can insert a sequence with a single assignment only.  */
!   gimple_seq stmts = VN_INFO (val)->expr;
!   if (!gimple_seq_singleton_p (stmts))
! return NULL_TREE;
!   gassign *stmt = dyn_cast  (gimple_seq_first_stmt (stmts));
!   if (!stmt
|| (!CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (stmt))
  && gimple_assign_rhs_code (stmt) != VIEW_CONVERT_EXPR
  && gimple_assign_rhs_code (stmt) != BIT_FIELD_REF
*** eliminate_insert (gimple_stmt_iterator *
*** 4116,4123 
if (!leader)
  return NULL_TREE;
  
-   gimple_seq stmts = NULL;
tree res;
if (gimple_assign_rhs_code (stmt) == BIT_FIELD_REF)
  res = gimple_build (, BIT_FIELD_REF,
TREE_TYPE (val), leader,
--- 4120,4127 
if (!leader)
  return NULL_TREE;
  
tree res;
+   stmts = NULL;
if (gimple_assign_rhs_code (stmt) == BIT_FIELD_REF)
  res = gimple_build (, BIT_FIELD_REF,
TREE_TYPE (val), leader,

Re: [PATCH] Fix PR79731

[Richard Biener]

On Tue, 28 Feb 2017, Richard Biener wrote:

> 
> Bootstrap / regtest running on x86_64-unknown-linux-gnu.

The following is what I committed.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

Richard.

2017-02-28  Richard Biener  

PR middle-end/79731
* fold-const.c (decode_field_reference): Reject out-of-bound
accesses.

* c-c++-common/torture/pr79731.c: New testcase.

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 245772)
+++ gcc/fold-const.c(working copy)
@@ -4133,7 +4133,10 @@ decode_field_reference (location_t loc,
   punsignedp, preversep, pvolatilep);
   if ((inner == exp && and_mask == 0)
   || *pbitsize < 0 || offset != 0
-  || TREE_CODE (inner) == PLACEHOLDER_EXPR)
+  || TREE_CODE (inner) == PLACEHOLDER_EXPR
+  /* Reject out-of-bound accesses (PR79731).  */
+  || compare_tree_int (TYPE_SIZE (TREE_TYPE (inner)),
+  *pbitpos + *pbitsize) < 0)
 return 0;
 
   *exp_ = exp;
Index: gcc/testsuite/c-c++-common/torture/pr79731.c
===
--- gcc/testsuite/c-c++-common/torture/pr79731.c(nonexistent)
+++ gcc/testsuite/c-c++-common/torture/pr79731.c(working copy)
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-Wno-psabi -w" } */
+
+typedef unsigned V __attribute__ ((vector_size (8)));
+V
+foo (unsigned x, V v)
+{
+  do {
+  v %= x;
+  x = 1;
+  } while (v[1]);
+  return v;
+}
+void fn2 ()
+{
+  V x = foo (5, (V) { 0, 1 });
+  if (x[0] || x[1] || x[2] || x[3]);
+}

RE: [PATCH,testsuite] Skip gcc.dg/lto/pr60449_0.c for mips*-*-elf* targets.

[Moore, Catherine]

> -Original Message-
> From: Toma Tabacu [mailto:toma.tab...@imgtec.com]
> Sent: Tuesday, February 28, 2017 9:32 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Matthew Fortune ; Moore,
> Catherine 
> Subject: [PATCH,testsuite] Skip gcc.dg/lto/pr60449_0.c for mips*-*-elf*
> targets.
> 
> Hi,
> 
> The gcc.dg/lto/pr60449_0.c is failing for mips*-*-elf* targets because
> they do
> not support gettimeofday, which is used in this test case.
> 
> This patch changes the test so that it is skipped for mips*-*-elf* targets.
> 

Hi Toma, 
There are some MIPS ELF targets that do support gettimeofday.   Perhaps you 
could handle this with a dg_require_effective_target entry for gettimeofday.
Thanks,
Catherine

> 
> gcc/testsuite/
> 
>   * gcc.dg/lto/pr60449_0.c (dg-skip-if): Skip for mips*-*-elf*.
> 
> diff --git a/gcc/testsuite/gcc.dg/lto/pr60449_0.c
> b/gcc/testsuite/gcc.dg/lto/pr60449_0.c
> index 5b878a6..6f3eccb 100644
> --- a/gcc/testsuite/gcc.dg/lto/pr60449_0.c
> +++ b/gcc/testsuite/gcc.dg/lto/pr60449_0.c
> @@ -1,5 +1,5 @@
>  /* { dg-lto-do link } */
> -/* { dg-skip-if "Needs gettimeofday" { "avr-*-*" } } */
> +/* { dg-skip-if "Needs gettimeofday" { "avr-*-*" mips*-*-elf* } } */
> 
>  extern int printf (const char *__restrict __format, ...);
>  typedef long int __time_t;

Re: [PATCH] Do not allow to run GIMPLE or RTL test-cases w/ LTO (PR lto/79625).

[Martin Liška]

On 02/28/2017 03:45 PM, Richard Biener wrote:
> On Tue, Feb 28, 2017 at 2:51 PM, Martin Liška  wrote:
>> Hello.
>>
>> As mentioned in the PR, I hope rejecting -flto option with both GIMPLE and 
>> RTL can
>> work for the issue.
>>
>> Ready after it finishes regression tests?
> 
> Actually GIMPLE should work fine if you make sure to start compilation
> before LTO streaming,
> if you don't it also won't ICE, will it?

Hm, can't find startwith value that will cause that. Btw. why choosing an 
invalid startwith
option does not display an error message? Should I report that?

Do you have a candidate option that can possibly trigger an ICE ("stdarg" works 
for me).

Martin

> 
> Richard.
> 
>> Thanks,
>> Martin

libgo patch committed: Fix sigfwd to not allocate memory

[Ian Lance Taylor]

This patch to libgo fixes sigfwd to not allocate memory.  The use of
&[1]uintptr{fn} was causing memory allocation, even though it is being
compiled for the runtime package.  That is a bad idea for this
function, which is invoked by a signal handler.  Rewrite it to use
only constructs that do not allocate memory when compiled for the
runtime package.

The test for this is misc/cgo/testcarchive in the main repo, which we
don't yet test.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 245776)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-0bcc1bc98dca48af40d9f54f4eacbbafaa30beb1
+e1502234b5011a1ab859519f1f217dbf4369ec9b
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/runtime/signal_gccgo.go
===
--- libgo/go/runtime/signal_gccgo.go(revision 245745)
+++ libgo/go/runtime/signal_gccgo.go(working copy)
@@ -127,9 +127,10 @@ func raiseproc(sig uint32) {
 //go:nosplit
 //go:nowritebarrierrec
 func sigfwd(fn uintptr, sig uint32, info *_siginfo_t, ctx unsafe.Pointer) {
-   f1 := &[1]uintptr{fn}
-   f2 := *(*func(uint32, *_siginfo_t, unsafe.Pointer))(unsafe.Pointer())
-   f2(sig, info, ctx)
+   f1 := [1]uintptr{fn}
+   f2 := 
+   f3 := *(*func(uint32, *_siginfo_t, unsafe.Pointer))(unsafe.Pointer())
+   f3(sig, info, ctx)
 }
 
 //go:nosplit

libgo patch committed: Fix quoting in mksigtab.sh

[Ian Lance Taylor]

I goofed on the shell quoting in mksigtab.sh, causing various
system-specific signals to be entered incorrectly in the runtime
signal table.  This patch fixes the problem.  The test for this is
misc/cgo/testcarchive in the master repo, which
we don't yet run for gccgo.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 245745)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-893f0e4a707c6f10eb14842b18954486042f0fb3
+0bcc1bc98dca48af40d9f54f4eacbbafaa30beb1
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/mksigtab.sh
===
--- libgo/mksigtab.sh   (revision 245745)
+++ libgo/mksigtab.sh   (working copy)
@@ -56,7 +56,7 @@ echo '_SIGSYS:{_SigThrow, "SIGSYS:
 # Handle signals that are not supported on all systems.
 
 checksig() {
-if grep 'const $1 = ' gen-sysinfo.go >/dev/null 2>&1; then
+if grep "const $1 = " gen-sysinfo.go >/dev/null 2>&1; then
echo "  $1: $2,"
 fi
 }

Re: [PR 78140] Reuse same IPA bits and VR info

[Richard Biener]

On Tue, Feb 28, 2017 at 3:08 PM, Martin Jambor  wrote:
> Hi,
>
> On Mon, Feb 27, 2017 at 10:34:38AM +0100, Richard Biener wrote:
>> On Wed, Feb 22, 2017 at 11:11 AM, Martin Jambor  wrote:
>> > Hello,
>> >
>> > this is a fix for PR 78140 which is about LTO WPA of Firefox taking
>> > 1GB memory more than gcc 6.
>> >
>> > It works by reusing the ipa_bits and value_range that we previously
>> > had directly in jump functions and which are just too big to be
>> > allocated for each actual argument in all of Firefox.  Reusing is
>> > achieved by two hash table traits derived from ggc_cache_remove which
>> > apparently has been created just for this purpose and once I
>> > understood them they made my life a lot easier.  In future, I will
>> > have a look at applying this method to other parts of jump functions
>> > as well.
>> >
>> > According to my measurements, the patch saves about 1.2 GB of memory.
>> > The problem is that some change last week (between revision 245382 and
>> > 245595) has more than invalidated this:
>> >
>> >   | compiler| WPA mem (GB) |
>> >   |-+--|
>> >   | gcc 6 branch| 3.86 |
>> >   | trunk rev. 245382   | 5.21 |
>> >   | patched rev. 245382 | 4.06 |
>> >   | trunk rev. 245595   | 6.59 |
>> >   | patched rev. 245595 | 5.25 |
>> >
>> > (I have verified this by Martin's way of measuring things.)  I will
>> > try to bisect what commit has caused the increase.  Still, the patch
>> > helps a lot.
>> >
>> > There is one thing in the patch that intrigues me, I do not understand
>> > why I had to mark value_range with GTY((for_user)) - as opposed to
>> > just GTY(()) that was there before - whereas ipa_bits does not need
>> > it.  If anyone could enlighten me, that would be great.  But I suppose
>> > this is not an indication of anything being wrong under the hood.
>> >
>> > I have bootstrapped and LTO-bootstrapped the patch on x86_64-linux and
>> > also bootstrapped (C, C++ and Fortran) on an aarch64 and i686 cfarm
>> > machine.  I have also LTO-built Firefox with the patch and used it to
>> > browse for a while and it seemed fine.
>> >
>> > OK for trunk?
>>
>> The idea looks good to me.  I wonder what a statistic over ranges
>> would look like (do they mostly look useful?).
>>
>
> So, at the jump function level (on trunk from last week), we have:
>
> no. of  callsites:   1064109
> no. of actual arguments: 2465511 (of all types)
> no. of unknown VRs:  1628727 (not too bad, considering that we only
>   track them for integers and non-NULL
>   for pointers)
> no. of known VRs: 836784
> no. of distinct VRs:1746
> the 20 most popular VRs with their frequencies are:
>
>  706245  VR  ~[0, 0]
>   59691  VR  [0, 1]
>   32660  VR  [0, -1]
>   14039  VR  [0, 4294967295]
>1607  VR  [0, 255]
>1351  VR  [0, 2147483647]
>1350  VR  ~[2147483648, -2147483649]
>1285  VR  [0, 65535]
>1259  VR  [1, 4294967296]
>1241  VR  [0, 31]
> 903  VR  [-2147483648, 2147483647]
> 853  VR  [-32768, 32767]
> 827  VR  [1, -1]
> 806  VR  [0, -2]
> 794  VR  [1, -2]
> 696  VR  [-128, 127]
> 662  VR  [0, 7]
> 654  VR  [0, 4294967294]
> 601  VR  [0, 15]
> 475  VR  [0, 4611686018427387903]
>
>
> At the other end of the propagation we store value ranges of 165010
> formal parameters out of the total of 678762 (but again, of all
> types).  The 20 most popular ones are:
>
>  119319 Storing VR ~[0, 0]
>   13169 Storing VR [0, -1]
>8781 Storing VR [0, 0]
>3181 Storing VR [1, 1]
>3081 Storing VR [0, 4294967295]
>2089 Storing VR [0, 1]
> 918 Storing VR [-1, -1]
> 870 Storing VR [2147483647, 2147483647]
> 697 Storing VR [2, 2]
> 554 Storing VR [0, 2]
> 527 Storing VR [1, -1]
> 491 Storing VR [0, 3]
> 361 Storing VR [1, 2]
> 350 Storing VR [0, 255]
> 323 Storing VR [0, 31]
> 300 Storing VR [-32768, 32767]
> 285 Storing VR [0, 2147483647]
> 260 Storing VR [0, 65535]
> 240 Storing VR [5, 5]
> 220 Storing VR [8, 8]
>
> I haven't had a look at how this translated to the final code, but it
> is safe to say that the propagation itself does something.

Nice.

Thanks,
Richard.

> Martin

Re: [PATCH] Do not allow to run GIMPLE or RTL test-cases w/ LTO (PR lto/79625).

[Richard Biener]

On Tue, Feb 28, 2017 at 2:51 PM, Martin Liška  wrote:
> Hello.
>
> As mentioned in the PR, I hope rejecting -flto option with both GIMPLE and 
> RTL can
> work for the issue.
>
> Ready after it finishes regression tests?

Actually GIMPLE should work fine if you make sure to start compilation
before LTO streaming,
if you don't it also won't ICE, will it?

Richard.

> Thanks,
> Martin

[PATCH,testsuite] Skip gcc.dg/lto/pr60449_0.c for mips*-*-elf* targets.

[Toma Tabacu]

Hi,

The gcc.dg/lto/pr60449_0.c is failing for mips*-*-elf* targets because they do
not support gettimeofday, which is used in this test case.

This patch changes the test so that it is skipped for mips*-*-elf* targets.

Regards,
Toma

gcc/testsuite/

* gcc.dg/lto/pr60449_0.c (dg-skip-if): Skip for mips*-*-elf*.

diff --git a/gcc/testsuite/gcc.dg/lto/pr60449_0.c 
b/gcc/testsuite/gcc.dg/lto/pr60449_0.c
index 5b878a6..6f3eccb 100644
--- a/gcc/testsuite/gcc.dg/lto/pr60449_0.c
+++ b/gcc/testsuite/gcc.dg/lto/pr60449_0.c
@@ -1,5 +1,5 @@
 /* { dg-lto-do link } */
-/* { dg-skip-if "Needs gettimeofday" { "avr-*-*" } } */
+/* { dg-skip-if "Needs gettimeofday" { "avr-*-*" mips*-*-elf* } } */
 
 extern int printf (const char *__restrict __format, ...);
 typedef long int __time_t;

[PATCH, ARM] Fix PR79742 incorrect scheduler choice.

[Richard Earnshaw (lists)]

Due to an oversight, the changes to use the new CPU generation tables
forgot to handle selecting a scheduler for a CPU other than the named
CPU target.  This meant that if, say, cortex-a12 was used, the null
scheduler was chosen rather than cortex-a17's scheduler as intended.
The fix is to correctly use the 'tune for' field when generating the
target-specific data files.

This revealed a spelling mistake in the name of the tune target in
cortex-m0.small-multiply.

PR target/79742
* config/arm/parsecpu.awk (gen_data): Set tuning target to 'tune for'
entry, if present.
* config/arm/arm-cpus.in (cortex-m0plus.small-multiply): Correct
'tune for' CPU name.
* config/arm/arm-cpu-data.h: Regenerated.

diff --git a/gcc/config/arm/arm-cpu-data.h b/gcc/config/arm/arm-cpu-data.h
index 
d6200f9bdc09a9d0c973853b0152a2800eaf2fe5..8d47e7c74929da5e7ac8eb41c2e1caa127b3b04d
 100644
--- a/gcc/config/arm/arm-cpu-data.h
+++ b/gcc/config/arm/arm-cpu-data.h
@@ -23,7 +23,8 @@
 static const struct processors all_cores[] =
 {
   {
-"arm2", TARGET_CPU_arm2,
+"arm2",
+TARGET_CPU_arm2,
 (TF_CO_PROC | TF_NO_MODE32),
 "2", BASE_ARCH_2,
 {
@@ -33,7 +34,8 @@ static const struct processors all_cores[] =
 _slowmul_tune
   },
   {
-"arm250", TARGET_CPU_arm250,
+"arm250",
+TARGET_CPU_arm250,
 (TF_CO_PROC | TF_NO_MODE32),
 "2", BASE_ARCH_2,
 {
@@ -43,7 +45,8 @@ static const struct processors all_cores[] =
 _slowmul_tune
   },
   {
-"arm3", TARGET_CPU_arm3,
+"arm3",
+TARGET_CPU_arm3,
 (TF_CO_PROC | TF_NO_MODE32),
 "2", BASE_ARCH_2,
 {
@@ -53,7 +56,8 @@ static const struct processors all_cores[] =
 _slowmul_tune
   },
   {
-"arm6", TARGET_CPU_arm6,
+"arm6",
+TARGET_CPU_arm6,
 (TF_CO_PROC),
 "3", BASE_ARCH_3,
 {
@@ -63,7 +67,8 @@ static const struct processors all_cores[] =
 _slowmul_tune
   },
   {
-"arm60", TARGET_CPU_arm60,
+"arm60",
+TARGET_CPU_arm60,
 (TF_CO_PROC),
 "3", BASE_ARCH_3,
 {
@@ -73,7 +78,8 @@ static const struct processors all_cores[] =
 _slowmul_tune
   },
   {
-"arm600", TARGET_CPU_arm600,
+"arm600",
+TARGET_CPU_arm600,
 (TF_CO_PROC | TF_WBUF),
 "3", BASE_ARCH_3,
 {
@@ -83,7 +89,8 @@ static const struct processors all_cores[] =
 _slowmul_tune
   },
   {
-"arm610", TARGET_CPU_arm610,
+"arm610",
+TARGET_CPU_arm610,
 (TF_WBUF),
 "3", BASE_ARCH_3,
 {
@@ -93,7 +100,8 @@ static const struct processors all_cores[] =
 _slowmul_tune
   },
   {
-"arm620", TARGET_CPU_arm620,
+"arm620",
+TARGET_CPU_arm620,
 (TF_CO_PROC | TF_WBUF),
 "3", BASE_ARCH_3,
 {
@@ -103,7 +111,8 @@ static const struct processors all_cores[] =
 _slowmul_tune
   },
   {
-"arm7", TARGET_CPU_arm7,
+"arm7",
+TARGET_CPU_arm7,
 (TF_CO_PROC),
 "3", BASE_ARCH_3,
 {
@@ -113,7 +122,8 @@ static const struct processors all_cores[] =
 _slowmul_tune
   },
   {
-"arm7d", TARGET_CPU_arm7d,
+"arm7d",
+TARGET_CPU_arm7d,
 (TF_CO_PROC),
 "3", BASE_ARCH_3,
 {
@@ -123,7 +133,8 @@ static const struct processors all_cores[] =
 _slowmul_tune
   },
   {
-"arm7di", TARGET_CPU_arm7di,
+"arm7di",
+TARGET_CPU_arm7di,
 (TF_CO_PROC),
 "3", BASE_ARCH_3,
 {
@@ -133,7 +144,8 @@ static const struct processors all_cores[] =
 _slowmul_tune
   },
   {
-"arm70", TARGET_CPU_arm70,
+"arm70",
+TARGET_CPU_arm70,
 (TF_CO_PROC),
 "3", BASE_ARCH_3,
 {
@@ -143,7 +155,8 @@ static const struct processors all_cores[] =
 _slowmul_tune
   },
   {
-"arm700", TARGET_CPU_arm700,
+"arm700",
+TARGET_CPU_arm700,
 (TF_CO_PROC | TF_WBUF),
 "3", BASE_ARCH_3,
 {
@@ -153,7 +166,8 @@ static const struct processors all_cores[] =
 _slowmul_tune
   },
   {
-"arm700i", TARGET_CPU_arm700i,
+"arm700i",
+TARGET_CPU_arm700i,
 (TF_CO_PROC | TF_WBUF),
 "3", BASE_ARCH_3,
 {
@@ -163,7 +177,8 @@ static const struct processors all_cores[] =
 _slowmul_tune
   },
   {
-"arm710", TARGET_CPU_arm710,
+"arm710",
+TARGET_CPU_arm710,
 (TF_WBUF),
 "3", BASE_ARCH_3,
 {
@@ -173,7 +188,8 @@ static const struct processors all_cores[] =
 _slowmul_tune
   },
   {
-"arm720", TARGET_CPU_arm720,
+"arm720",
+TARGET_CPU_arm720,
 (TF_WBUF),
 "3", BASE_ARCH_3,
 {
@@ -183,7 +199,8 @@ static const struct processors all_cores[] =
 _slowmul_tune
   },
   {
-"arm710c", TARGET_CPU_arm710c,
+"arm710c",
+TARGET_CPU_arm710c,
 (TF_WBUF),
 "3", BASE_ARCH_3,
 {
@@ -193,7 +210,8 @@ static const struct processors all_cores[] =
 _slowmul_tune
   },
   {
-"arm7100", TARGET_CPU_arm7100,
+"arm7100",
+TARGET_CPU_arm7100,
 (TF_WBUF),
 "3", BASE_ARCH_3,
 {
@@ -203,7 +221,8 @@ static const struct processors all_cores[] =
 _slowmul_tune
   },
   {
-"arm7500", TARGET_CPU_arm7500,
+

Re: [PR 78140] Reuse same IPA bits and VR info

[Martin Jambor]

Hi,

On Mon, Feb 27, 2017 at 10:34:38AM +0100, Richard Biener wrote:
> On Wed, Feb 22, 2017 at 11:11 AM, Martin Jambor  wrote:
> > Hello,
> >
> > this is a fix for PR 78140 which is about LTO WPA of Firefox taking
> > 1GB memory more than gcc 6.
> >
> > It works by reusing the ipa_bits and value_range that we previously
> > had directly in jump functions and which are just too big to be
> > allocated for each actual argument in all of Firefox.  Reusing is
> > achieved by two hash table traits derived from ggc_cache_remove which
> > apparently has been created just for this purpose and once I
> > understood them they made my life a lot easier.  In future, I will
> > have a look at applying this method to other parts of jump functions
> > as well.
> >
> > According to my measurements, the patch saves about 1.2 GB of memory.
> > The problem is that some change last week (between revision 245382 and
> > 245595) has more than invalidated this:
> >
> >   | compiler| WPA mem (GB) |
> >   |-+--|
> >   | gcc 6 branch| 3.86 |
> >   | trunk rev. 245382   | 5.21 |
> >   | patched rev. 245382 | 4.06 |
> >   | trunk rev. 245595   | 6.59 |
> >   | patched rev. 245595 | 5.25 |
> >
> > (I have verified this by Martin's way of measuring things.)  I will
> > try to bisect what commit has caused the increase.  Still, the patch
> > helps a lot.
> >
> > There is one thing in the patch that intrigues me, I do not understand
> > why I had to mark value_range with GTY((for_user)) - as opposed to
> > just GTY(()) that was there before - whereas ipa_bits does not need
> > it.  If anyone could enlighten me, that would be great.  But I suppose
> > this is not an indication of anything being wrong under the hood.
> >
> > I have bootstrapped and LTO-bootstrapped the patch on x86_64-linux and
> > also bootstrapped (C, C++ and Fortran) on an aarch64 and i686 cfarm
> > machine.  I have also LTO-built Firefox with the patch and used it to
> > browse for a while and it seemed fine.
> >
> > OK for trunk?
> 
> The idea looks good to me.  I wonder what a statistic over ranges
> would look like (do they mostly look useful?).
> 

So, at the jump function level (on trunk from last week), we have:

no. of  callsites:   1064109
no. of actual arguments: 2465511 (of all types)
no. of unknown VRs:  1628727 (not too bad, considering that we only
  track them for integers and non-NULL
  for pointers)
no. of known VRs: 836784
no. of distinct VRs:1746 
the 20 most popular VRs with their frequencies are:

 706245  VR  ~[0, 0]
  59691  VR  [0, 1]
  32660  VR  [0, -1]
  14039  VR  [0, 4294967295]
   1607  VR  [0, 255]
   1351  VR  [0, 2147483647]
   1350  VR  ~[2147483648, -2147483649]
   1285  VR  [0, 65535]
   1259  VR  [1, 4294967296]
   1241  VR  [0, 31]
903  VR  [-2147483648, 2147483647]
853  VR  [-32768, 32767]
827  VR  [1, -1]
806  VR  [0, -2]
794  VR  [1, -2]
696  VR  [-128, 127]
662  VR  [0, 7]
654  VR  [0, 4294967294]
601  VR  [0, 15]
475  VR  [0, 4611686018427387903]


At the other end of the propagation we store value ranges of 165010
formal parameters out of the total of 678762 (but again, of all
types).  The 20 most popular ones are:

 119319 Storing VR ~[0, 0]
  13169 Storing VR [0, -1]
   8781 Storing VR [0, 0]
   3181 Storing VR [1, 1]
   3081 Storing VR [0, 4294967295]
   2089 Storing VR [0, 1]
918 Storing VR [-1, -1]
870 Storing VR [2147483647, 2147483647]
697 Storing VR [2, 2]
554 Storing VR [0, 2]
527 Storing VR [1, -1]
491 Storing VR [0, 3]
361 Storing VR [1, 2]
350 Storing VR [0, 255]
323 Storing VR [0, 31]
300 Storing VR [-32768, 32767]
285 Storing VR [0, 2147483647]
260 Storing VR [0, 65535]
240 Storing VR [5, 5]
220 Storing VR [8, 8]

I haven't had a look at how this translated to the final code, but it
is safe to say that the propagation itself does something.

Martin

[PATCH] Do not allow to run GIMPLE or RTL test-cases w/ LTO (PR lto/79625).

[Martin Liška]

Hello.

As mentioned in the PR, I hope rejecting -flto option with both GIMPLE and RTL 
can
work for the issue.

Ready after it finishes regression tests?
Thanks,
Martin
>From 3c26a29821b52d4e90fa05686a473b565ddf5ba9 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 21 Feb 2017 10:35:39 +0100
Subject: [PATCH] Do not allow to run GIMPLE or RTL test-cases w/ LTO (PR
 lto/79625).

gcc/ChangeLog:

2017-02-28  Martin Liska  

	PR lto/79625
	* read-rtl-function.c (function_reader::handle_unknown_directive):
	Bail out when one uses -flto.

gcc/c/ChangeLog:

2017-02-28  Martin Liska  

	PR lto/79625
	* gimple-parser.c (c_parser_parse_gimple_body):
	Bail out when one uses -flto.
---
 gcc/c/gimple-parser.c   | 3 +++
 gcc/read-rtl-function.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/gcc/c/gimple-parser.c b/gcc/c/gimple-parser.c
index 0d6384b55c2..c56a2a4ac48 100644
--- a/gcc/c/gimple-parser.c
+++ b/gcc/c/gimple-parser.c
@@ -81,6 +81,9 @@ static void c_parser_gimple_expr_list (c_parser *, vec *);
 void
 c_parser_parse_gimple_body (c_parser *parser)
 {
+  if (flag_lto)
+error ("%<__GIMPLE%> function cannot be compiled with %<-flto%>");
+
   gimple_seq seq = NULL;
   gimple_seq body = NULL;
   tree stmt = push_stmt_list ();
diff --git a/gcc/read-rtl-function.c b/gcc/read-rtl-function.c
index bead85811e6..8552cd2ae8c 100644
--- a/gcc/read-rtl-function.c
+++ b/gcc/read-rtl-function.c
@@ -405,6 +405,9 @@ function_reader::handle_unknown_directive (file_location start_loc,
   if (strcmp (name, "function"))
 fatal_at (start_loc, "expected 'function'");
 
+  if (flag_lto)
+error ("%<__RTL%> function cannot be compiled with %<-flto%>");
+
   parse_function ();
 }
 
-- 
2.11.1

maintainer-scripts/update_web_docs_svn

[Gerald Pfeifer]

While debugging an issue with our online documentation at 
https://gcc.gnu.org/onlinedocs (which I traced down to a bug 
with the old version of makeinfo on that host) I noticed WWWBASE 
was hardcoded without a way to override without changing the script.

That's obviously not too helpful when running on a local system,
and I addressed it by the patch below, also adding a comment on
the way.

Tested on my notebook (modulo jit) and gcc.gnu.org, and committed.

Gerald

2017-02-28  Gerald Pfeifer  

* update_web_docs_svn: Remove a reference to GCC 3.1.  Describe
settings to tweak if running on a host different from gcc.gnu.org.
(WWWBASE): Allow override via the environment.  Also check for
existance.

Index: update_web_docs_svn
===
--- update_web_docs_svn (revision 245750)
+++ update_web_docs_svn (working copy)
@@ -1,7 +1,10 @@
 #!/bin/sh
 
 # Generate HTML documentation from GCC Texinfo docs.
-# This version is for GCC 3.1 and later versions.
+#
+# If you want to run this on a machine different from gcc.gnu.org, you
+# may need to adjust SVNROOT and WWWBASE below (or override them via the
+# environment).
 
 set -e
 
@@ -31,7 +34,7 @@
 
 CSS=/gcc.css
 
-WWWBASE=/www/gcc/htdocs
+WWWBASE=${WWWBASE:-"/www/gcc/htdocs"}
 WWWBASE_PREFORMATTED=/www/gcc/htdocs-preformatted
 WWWPREPROCESS='/www/gcc/bin/preprocess -r'
 
@@ -90,6 +93,11 @@
   DOCSDIR=$WWWBASE/onlinedocs/$SUBDIR
 fi
 
+if [ ! -d $WWWBASE ]; then
+  echo "WWW base directory \"$WWWBASE\" does not exist." >&2
+  exit 1
+fi
+
 if [ ! -d $DOCSDIR ]; then
   mkdir $DOCSDIR
   chmod g+w $DOCSDIR

[PATCH 3/3] Introduce IntegerRange for options (PR driver/79659).

[Martin Liška]

Hi.

Last patch from the mini-series fixes the PR mentioned in subject. I'm not sure 
whether it's stage4 material,
or should I postpone it to next stage1?

Thanks for review.
Martin

[PATCH 2/3] Introduce = for couple of options.

[Martin Liška]

Hello.

This is second patch, where I add '=' for some of options.

Thanks,
Martin
>From add261f1fdf40b90d1a74dd7183923123943ba5e Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 27 Feb 2017 15:27:54 +0100
Subject: [PATCH 2/3] Introduce = for couple of options.

gcc/c-family/ChangeLog:

2017-02-28  Martin Liska  

	* c.opt: Replace space with tabular for options of 
	type.

gcc/ChangeLog:

2017-02-28  Martin Liska  

	* common.opt: Replace space with tabular for options of 
	type.
	* config/i386/i386.opt: Show  value for
	-mlarge-data-threshold.
	* opts.c (print_filtered_help): Do not display number in hexadecimal
	format.
---
 gcc/c-family/c.opt   | 4 ++--
 gcc/common.opt   | 6 +++---
 gcc/config/i386/i386.opt | 2 +-
 gcc/opts.c   | 2 +-
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 9b9aab44810..cf459ab4427 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -314,7 +314,7 @@ C ObjC C++ ObjC++ Var(warn_alloc_zero) Warning
 
 Walloca-larger-than=
 C ObjC C++ LTO ObjC++ Var(warn_alloca_limit) Warning Joined RejectNegative UInteger
--Walloca-larger-than= Warn on unbounded uses of
+-Walloca-larger-than=	Warn on unbounded uses of
 alloca, and on bounded uses of alloca whose bound can be larger than
  bytes.
 
@@ -1097,7 +1097,7 @@ Warn if a variable length array is used.
 
 Wvla-larger-than=
 C ObjC C++ ObjC++ Var(warn_vla_limit) Warning Joined RejectNegative UInteger
--Wvla-larger-than= Warn on unbounded uses of variable-length arrays, and
+-Wvla-larger-than=	Warn on unbounded uses of variable-length arrays, and
 on bounded uses of variable-length arrays whose bound can be
 larger than  bytes.
 
diff --git a/gcc/common.opt b/gcc/common.opt
index 1a19847fe44..4021622cf5c 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -689,8 +689,8 @@ Common Var(warn_stack_protect) Warning
 Warn when not issuing stack smashing protection for some reason.
 
 Wstack-usage=
-Common Joined RejectNegative UInteger Var(warn_stack_usage) Init(-1) Warning
-Warn if stack usage might be larger than specified amount.
+Common Joined RejectNegative UInteger Var(warn_stack_usage) Warning
+-Wstack-usage=	Warn if stack usage might be larger than specified amount.
 
 Wstrict-aliasing
 Common Warning
@@ -2523,7 +2523,7 @@ Enable loop optimizations on tree level.
 
 ftree-parallelize-loops=
 Common Report Joined RejectNegative UInteger Var(flag_tree_parallelize_loops) Init(1) Optimization
-Enable automatic parallelization of loops.
+-ftree-parallelize-loops=	Enable automatic parallelization of loops.
 
 ftree-phiprop
 Common Report Var(flag_tree_phiprop) Init(1) Optimization
diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
index 36251abfeb5..9384e29b1de 100644
--- a/gcc/config/i386/i386.opt
+++ b/gcc/config/i386/i386.opt
@@ -272,7 +272,7 @@ Branches are this expensive (1-5, arbitrary units).
 
 mlarge-data-threshold=
 Target RejectNegative Joined UInteger Var(ix86_section_threshold) Init(DEFAULT_LARGE_SECTION_THRESHOLD)
-Data greater than given threshold will go into .ldata section in x86-64 medium model.
+-mlarge-data-threshold=	Data greater than given threshold will go into .ldata section in x86-64 medium model.
 
 mcmodel=
 Target RejectNegative Joined Enum(cmodel) Var(ix86_cmodel) Init(CM_32)
diff --git a/gcc/opts.c b/gcc/opts.c
index c4768603ec9..8274fab6661 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -1246,7 +1246,7 @@ print_filtered_help (unsigned int include_flags,
 		}
 		  else
 		sprintf (new_help + strlen (new_help),
-			 "%#x", * (int *) flag_var);
+			 "%d", * (int *) flag_var);
 		}
 	  else
 		strcat (new_help, option_enabled (i, opts)
-- 
2.11.1

[PATCH] Add tabulars for options with enum values.

[Martin Liška]

Hello.

We have various enum options that do not properly display options with --help=*:
Apart from that, some of them are not separated by tabular, but with a space.

Using the suggested patch, --help=common will get:

--- /tmp/before 2017-02-28 10:41:12.107024945 +0100
+++ /tmp/after  2017-02-28 10:41:32.615415978 +0100
@@ -193,7 +193,7 @@
   -ffloat-store[disabled]
   -fforce-addr 
   -fforward-propagate  [disabled]
-  -ffp-contract=   fast
+  -ffp-contract=[off|on|fast]  fast
   -ffp-int-builtin-inexact [enabled]
   -ffunction-cse   [enabled]
   -ffunction-sections  [disabled]
@@ -242,10 +242,10 @@
   -fipa-sra[disabled]
   -fipa-struct-reorg   
   -fipa-vrp[disabled]
-  -fira-algorithm= CB
+  -fira-algorithm=[CB|priority]CB
   -fira-hoist-pressure [enabled]
   -fira-loop-pressure  [disabled]
-  -fira-region=[default]
+  -fira-region=[one|all|mixed] [default]
   -fira-share-save-slots   [enabled]
   -fira-share-spill-slots  [enabled]
   -fira-verbose=   0x5
@@ -336,7 +336,7 @@
   -fregmove
   -frename-registers   [enabled]
   -freorder-blocks [disabled]
-  -freorder-blocks-algorithm=  simple
+  -freorder-blocks-algorithm=[simple|stc]  simple
   -freorder-blocks-and-partition   [disabled]
   -freorder-functions  [disabled]
   -freport-bug [disabled]
@@ -386,7 +386,7 @@
   -fshrink-wrap-separate   [enabled]
   -fsignaling-nans [disabled]
   -fsigned-zeros   [enabled]
-  -fsimd-cost-model=   unlimited
+  -fsimd-cost-model=[unlimited|dynamic|cheap]  unlimited
   -fsingle-precision-constant  [disabled]
   -fsplit-ivs-in-unroller  [enabled]
   -fsplit-loops[disabled]
@@ -404,7 +404,7 @@
   -fstack-protector-all[disabled]
   -fstack-protector-explicit   [disabled]
   -fstack-protector-strong [disabled]
-  -fstack-reuse=   all
+  -fstack-reuse=[all|named_vars|none]  all
   -fstack-usage[disabled]
   -fstdarg-opt [enabled]
   -fstore-merging  [disabled]
@@ -489,7 +489,7 @@
   -fvar-tracking-uninit[disabled]
   -fvariable-expansion-in-unroller [disabled]
   -fvect-cost-model
-  -fvect-cost-model=   [default]
+  Specifies the cost model for vectorization. 
-fvect-cost-model=[unlimited|dynamic|cheap]  [default]
   -fverbose-asm[disabled]
   -fversion
   -fvisibility=[default|internal|hidden|protected] default

Ready to be installed after regression tests?
Thanks,
Martin
>From 13f710c2487fbd74d6b8a01dab7d33b9e0614727 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Sun, 26 Feb 2017 23:00:02 +0100
Subject: [PATCH 1/3] Add tabulars for options with enum values.

gcc/ChangeLog:

2017-02-28  Martin Liska  

	* common.opt: Fix --help=option -Q for options which are of
	an enum type.

gcc/c-family/ChangeLog:

2017-02-28  Martin Liska  

	* c.opt: Fix --help=option -Q for options which are of
	an enum type.
---
 gcc/c-family/c.opt |  2 +-
 gcc/common.opt | 13 +++--
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index a863471da7f..9b9aab44810 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -293,7 +293,7 @@ Warn about 'new' of type with extended alignment without -faligned-new.
 
 Waligned-new=
 C++ ObjC++ Var(warn_aligned_new) Enum(warn_aligned_new_level) Joined RejectNegative Warning LangEnabledBy(C++ ObjC++,Wall,1,0)
--Waligned-new=all Warn even if 'new' uses a class member allocation function.
+-Waligned-new=[none|global|all]	Warn even if 'new' uses a class member allocation function.
 
 Wall
 C ObjC C++ ObjC++ Warning
diff --git a/gcc/common.opt b/gcc/common.opt
index e5ae364abd9..1a19847fe44 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1376,7 +1376,7 @@ Perform a forward propagation pass on RTL.
 
 ffp-contract=
 Common Joined RejectNegative Enum(fp_contract_mode) Var(flag_fp_contract_mode) Init(FP_CONTRACT_FAST) Optimization
--ffp-contract=[off|on|fast] Perform floating-point expression contraction.
+-ffp-contract=[off|on|fast]	Perform floating-point expression contraction.
 
 Enum
 Name(fp_contract_mode) Type(enum fp_contract_mode) UnknownError(unknown floating point contraction style %qs)
@@ -1528,7 +1528,7 @@ Perform conversion of conditional jumps to conditional execution.
 
 

Re: PR79715: Special case strcpy/strncpy for dse

[Prathamesh Kulkarni]

On 28 February 2017 at 15:40, Jakub Jelinek  wrote:
> On Tue, Feb 28, 2017 at 03:33:11PM +0530, Prathamesh Kulkarni wrote:
>> Hi,
>> The attached patch adds special-casing for strcpy/strncpy to dse pass.
>> Bootstrapped+tested on x86_64-unknown-linux-gnu.
>> OK for GCC 8 ?
>
> What is special on strcpy/strncpy?  Unlike memcpy/memmove/memset, you don't
> know the length they store (at least not in general), you don't know the
> value, all you know is that they are for the first argument plain store
> without remembering the pointer or anything based on it anywhere except in
> the return value.
> I believe stpcpy, stpncpy, strcat, strncat at least have the same behavior.
> On the other side, without knowing the length of the store, you can't treat
> it as killing something (ok, some calls like strcpy or stpcpy store at least
> the first byte).
Well, I assumed a store to dest by strcpy (and friends), which gets
immediately freed would count
as a dead store since free would kill the whole memory block pointed
to by dest ?

For the test-case:
void f (unsigned n, char *s2)
{
  char *p = __builtin_malloc (n);
  __builtin_strcpy (p, s2);
  __builtin_free (p);
}

With patch, similar to memcpy, in dse_classify_store when temp equals
__builtin_free (p),
stmt_kills_ref_p (temp, ref) returns true (the condition for case
BUILT_IN_FREE) which causes the loop to break
and dse_classify_store returns DSE_STORE_DEAD.

Thanks,
Prathamesh
>
>> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr79715.c 
>> b/gcc/testsuite/gcc.dg/tree-ssa/pr79715.c
>> new file mode 100644
>> index 000..1a832ca
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr79715.c
>> @@ -0,0 +1,12 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-O2 -fdump-tree-dse-details" } */
>> +
>> +void f(const char *s)
>> +{
>> +  unsigned n = __builtin_strlen (s) + 1;
>> +  char *p = __builtin_malloc (n);
>> +  __builtin_strcpy (p, s);
>> +  __builtin_free (p);
>> +}
>> +
>> +/* { dg-final { scan-tree-dump "Deleted dead call: __builtin_strcpy" "dse1" 
>> } } */
>> diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
>> index 53feaf3..6d3c3c3 100644
>> --- a/gcc/tree-ssa-dse.c
>> +++ b/gcc/tree-ssa-dse.c
>> @@ -97,6 +97,8 @@ initialize_ao_ref_for_dse (gimple *stmt, ao_ref *write)
>> case BUILT_IN_MEMCPY:
>> case BUILT_IN_MEMMOVE:
>> case BUILT_IN_MEMSET:
>> +   case BUILT_IN_STRNCPY:
>> +   case BUILT_IN_STRCPY:
>>   {
>> tree size = NULL_TREE;
>> if (gimple_call_num_args (stmt) == 3)
>> @@ -395,6 +397,8 @@ maybe_trim_memstar_call (ao_ref *ref, sbitmap live, 
>> gimple *stmt)
>>  {
>>  case BUILT_IN_MEMCPY:
>>  case BUILT_IN_MEMMOVE:
>> +case BUILT_IN_STRNCPY:
>> +case BUILT_IN_STRCPY:
>>{
>>   int head_trim, tail_trim;
>>   compute_trims (ref, live, _trim, _trim, stmt);
>> @@ -713,6 +717,7 @@ dse_dom_walker::dse_optimize_stmt (gimple_stmt_iterator 
>> *gsi)
>> case BUILT_IN_MEMCPY:
>> case BUILT_IN_MEMMOVE:
>> case BUILT_IN_MEMSET:
>> +   case BUILT_IN_STRNCPY:
>>   {
>> /* Occasionally calls with an explicit length of zero
>>show up in the IL.  It's pointless to do analysis
>> @@ -723,7 +728,10 @@ dse_dom_walker::dse_optimize_stmt (gimple_stmt_iterator 
>> *gsi)
>> delete_dead_call (gsi);
>> return;
>>   }
>> -
>> + }
>> +   /* fallthru  */
>> +   case BUILT_IN_STRCPY:
>> + {
>> gimple *use_stmt;
>> enum dse_store_status store_status;
>> m_byte_tracking_enabled
>
>
> Jakub

[PATCH][AArch64] Allow const0_rtx operand for atomic compare-exchange patterns

[Kyrill Tkachov]

Hi all,

For the testcase in this patch we currently generate:
foo:
mov w1, 0
ldaxr   w2, [x0]
cmp w2, 3
bne .L2
stxrw3, w1, [x0]
cmp w3, 0
.L2:
csetw0, eq
ret

Note that the STXR could have been storing the WZR register instead of moving 
zero into w1.
This is due to overly strict predicates and constraints in the store exclusive 
pattern and the
atomic compare exchange expanders and splitters.
This simple patch fixes that in the patterns concerned and with it we can 
generate:
foo:
ldaxr   w1, [x0]
cmp w1, 3
bne .L2
stxrw2, wzr, [x0]
cmp w2, 0
.L2:
csetw0, eq
ret


Bootstrapped and tested on aarch64-none-linux-gnu.
Ok for GCC 8?

Thanks,
Kyrill

2017-02-28  Kyrylo Tkachov  

* config/aarch64/atomics.md (atomic_compare_and_swap expander):
Use aarch64_reg_or_zero predicate for operand 4.
(aarch64_compare_and_swap define_insn_and_split):
Use aarch64_reg_or_zero predicate for operand 3.  Add 'Z' constraint.
(aarch64_store_exclusive): Likewise for operand 2.

2017-02-28  Kyrylo Tkachov  

* gcc.target/aarch64/atomic_cmp_exchange_zero_reg_1.c: New test.
diff --git a/gcc/config/aarch64/atomics.md b/gcc/config/aarch64/atomics.md
index 09d441075f0383420d26b7d3ccb62da2a3c44422..27fc1933ce39b6eddde9c092fa849e5f6645bea3 100644
--- a/gcc/config/aarch64/atomics.md
+++ b/gcc/config/aarch64/atomics.md
@@ -25,7 +25,7 @@ (define_expand "atomic_compare_and_swap"
(match_operand:ALLI 1 "register_operand" "")			;; val out
(match_operand:ALLI 2 "aarch64_sync_memory_operand" "")	;; memory
(match_operand:ALLI 3 "general_operand" "")			;; expected
-   (match_operand:ALLI 4 "register_operand" "")			;; desired
+   (match_operand:ALLI 4 "aarch64_reg_or_zero" "")			;; desired
(match_operand:SI 5 "const_int_operand")			;; is_weak
(match_operand:SI 6 "const_int_operand")			;; mod_s
(match_operand:SI 7 "const_int_operand")]			;; mod_f
@@ -45,7 +45,7 @@ (define_insn_and_split "aarch64_compare_and_swap"
(set (match_dup 1)
 (unspec_volatile:SHORT
   [(match_operand:SI 2 "aarch64_plus_operand" "rI")	;; expected
-   (match_operand:SHORT 3 "register_operand" "r")	;; desired
+   (match_operand:SHORT 3 "aarch64_reg_or_zero" "rZ")	;; desired
(match_operand:SI 4 "const_int_operand")		;; is_weak
(match_operand:SI 5 "const_int_operand")		;; mod_s
(match_operand:SI 6 "const_int_operand")]	;; mod_f
@@ -69,7 +69,7 @@ (define_insn_and_split "aarch64_compare_and_swap"
(set (match_dup 1)
 (unspec_volatile:GPI
   [(match_operand:GPI 2 "aarch64_plus_operand" "rI")	;; expect
-   (match_operand:GPI 3 "register_operand" "r")		;; desired
+   (match_operand:GPI 3 "aarch64_reg_or_zero" "rZ")		;; desired
(match_operand:SI 4 "const_int_operand")			;; is_weak
(match_operand:SI 5 "const_int_operand")			;; mod_s
(match_operand:SI 6 "const_int_operand")]		;; mod_f
@@ -534,7 +534,7 @@ (define_insn "aarch64_store_exclusive"
 (unspec_volatile:SI [(const_int 0)] UNSPECV_SX))
(set (match_operand:ALLI 1 "aarch64_sync_memory_operand" "=Q")
 (unspec_volatile:ALLI
-  [(match_operand:ALLI 2 "register_operand" "r")
+  [(match_operand:ALLI 2 "aarch64_reg_or_zero" "rZ")
(match_operand:SI 3 "const_int_operand")]
   UNSPECV_SX))]
   ""
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic_cmp_exchange_zero_reg_1.c b/gcc/testsuite/gcc.target/aarch64/atomic_cmp_exchange_zero_reg_1.c
new file mode 100644
index ..15606b6899012dcb6616e0313d343b77249e1b24
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/atomic_cmp_exchange_zero_reg_1.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int
+foo (int *a)
+{
+  int x = 3;
+  return __atomic_compare_exchange_n (a, , 0, 1, __ATOMIC_ACQUIRE, __ATOMIC_ACQUIRE);
+}
+
+/* { dg-final { scan-assembler "stxr\\tw\[0-9\]+, wzr,.*" } } */
+/* { dg-final { scan-assembler-not "mov\\tw\[0-9\]+, 0" } } */

[FYI] Various SMS (modulo scheduling) patches

[Roman Zhuykov]

Hello,

We at ISPRAS still have some SMS patches floating around from the time
we have been actively working on them.  At the time they were not
committed because either of lack of interest or approval but they
might be still useful as PR69252 discussion shows.  We don’t have much
resource now for preparing the patches for approval with changelogs
and everything, so we have posted them on github at
https://github.com/ispras/gcc-sms.  There are also branches with
almost the same changes for gcc branches starting from 4.9 (sms-4_9,
sms-5, sms-6 branches).  Most of fixes there are useful even without
applying the non-doloop support patch that was the main goal.

The first ML discussion regarding the patches starts at
https://gcc.gnu.org/ml/gcc-patches/2011-07/msg01807.html (below there
are many other mail list archive links).  Since that time I have
rebased patches several times, made minor changes and ran some tests,
at least bootstrapping and regtest plus compiling my own gentoo server
installation on x86-64.  Also, sometimes source were regstrapped on
arm and aarch64 under qemu.

There are no miscompilations right now known to me but the last few
years I didn't run any performance testing.  Here in mailing lists
only Shiva Chen
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00591.html was
interested in modulo scheduler.  His interest means he may have some
tests which gain profit with his patches, maybe he can also try my
patches.

Of course we are ready to answer questions and discuss any patch ideas
if needed.

For reference, here I briefly discuss all patches (in the order they
appear on sms* branches at the aforementioned github repo) with a lot
of links to old emails:

1) Make find_simple_exit static
Minor obvious fix.

2) Remove strange CPU_NONE with all zero costs
Previously discussed
https://gcc.gnu.org/ml/gcc-patches/2012-04/msg01004.html
Having all zero costs seems very strange for modulo scheduling and other passes.

3) Correct extracting loop exit condition
Previously discussed, was approved but not committed.
https://gcc.gnu.org/ml/gcc-patches/2011-07/msg01803.html
https://gcc.gnu.org/ml/gcc-patches/2011-09/msg02049.html
https://gcc.gnu.org/ml/gcc-patches/2012-02/msg00479.html

4) Eliminate redundant edges from DDG
Previously discussed
https://gcc.gnu.org/ml/gcc-patches/2011-07/msg01804.html
https://gcc.gnu.org/ml/gcc/2012-07/msg00162.html
Unfortunately, the example where this caused failures for me was lost
in history, but I suppose this should be obvious with all other
patches applied and reg-strapping on several platforms like x86-64,
ARM and ia64.  Five or six years ago I tested modulo-scheduling
changes mostly using regstrap on these platforms.

5) Add additional DDG edges to instructions with clobbers
Previous description
https://gcc.gnu.org/ml/gcc-patches/2011-12/msg00505.html

6) Correctly delete anti-dep ddg edges for renaming
Previous description
https://gcc.gnu.org/ml/gcc-patches/2011-12/msg00506.html

7) Add some assertions
One assert described https://gcc.gnu.org/ml/gcc-patches/2011-07/msg01808.html
Another assert helps to catch wrong schedule when regmoves are
disabled, but we try to create them.

8) Extend simple_rhs_p
Previous description
https://gcc.gnu.org/ml/gcc-patches/2011-07/msg01810.html

9) Revert part of commit 84486 - do not prevent copy propagation in niter_expr
This allows to optimize runtime calculations for loop versioning condition.

10)  Add new loop pattern support to modulo scheduler
Links to almost all emails in the previous discussion.
https://gcc.gnu.org/ml/gcc-patches/2011-07/msg01806.html
https://gcc.gnu.org/ml/gcc-patches/2011-09/msg02051.html
https://gcc.gnu.org/ml/gcc-patches/2011-10/msg00938.html
https://gcc.gnu.org/ml/gcc-patches/2011-12/msg00495.html
https://gcc.gnu.org/ml/gcc-patches/2011-12/msg01801.html
https://gcc.gnu.org/ml/gcc-patches/2012-02/msg00483.html
https://gcc.gnu.org/ml/gcc-patches/2012-03/msg01859.html
https://gcc.gnu.org/ml/gcc-patches/2012-04/msg00478.html

11) Remove artificial doloop_end pattern for ARM
Previously discussed
https://gcc.gnu.org/ml/gcc-patches/2011-07/msg01812.html
https://gcc.gnu.org/ml/gcc-patches/2012-01/msg00195.html
Now it eliminates fake doloop_end pattern for both 32bit and 64bit arm
platforms.
The problem with such a pattern is that it slows down the loop when
SMS doesn't create good schedule.  So, I suppose fake pattern is no
longer needed with new loop forms supported.

12) Enable SMS by default, also allow regmoves
Only for bootstrap and regtest.

--
Roman Zhuykov
zhr...@ispras.ru

Re: [RFA PATCH, i386]: Warn for 64-bit values in general-reg asm operands and error out for 8-bit values in invalid GR asm operand

[Jakub Jelinek]

On Tue, Feb 28, 2017 at 11:41:56AM +0100, Richard Biener wrote:
> > 2017-02-28  Uros Bizjak  
> > 
> > * config/i386/i386.c (print_reg): Warn for values of 64-bit size
> > in integer register on 32-bit targets.  Error out for values of
> > 8-bit size in invalid integer register.
> > 
> > testsuite/ChangeLog:
> > 
> > 2017-02-28  Uros Bizjak  
> > 
> > * gcc.target/i386/invsize-1.c: New test.
> > * gcc.target/i386/invsize-2.c: Ditto.
> > 
> > OK for mainline in stage 4?
> 
> Yes.

Have you tried to build say Linux kernel or firefox or similar large
codebase with lots of inline asm with that?
What constraint should people use for long long vars in 32-bit code?
"A" constraint is used a lot in 32-bit code (say for inline asm with
rdtsc), but what if you need more than one long long input?

Jakub

Re: [RFC PATCH 2/3] Use call_summary in ipa-prop and ipa-cp

[jh]

Dne 2017-02-27 17:35, Martin Jambor napsal:

Hello,

this is patch is afairly straightforward conversion from use of a
vector indexed by edge->uid to use of the new call_summary from the
previous patch.

The patch is generally a cleanup, hashing is a nicer method of keeping
call-site related information than a gigantic vector that we never
shrink during its lifetime.  Moreover, it should allow further
cleanups and of course is a nice way of testing that the previous
patch works.

Any comments and/or suggestions are welcome,

Martin

2017-02-27  Martin Jambor  

* ipa-prop.h (ipa_edge_args): Make a class.  Mark with for_user GTY
tag.  Added a default constructor and a destructor.
(ipa_edge_args_sum_t): New class;
(ipa_edge_args_sum): Declare.
(ipa_edge_args_vector): Remove declaration.
(IPA_EDGE_REF): Use ipa_edge_args_sum.
(ipa_free_edge_args_substructures): Remove declaration.
(ipa_check_create_edge_args): Use ipa_edge_args_sum.
(ipa_edge_args_info_available_for_edge_p): Likewise.
* ipa-prop.c (ipa_edge_args_vector): Removed.
(edge_removal_hook_holder): Likewise.
(edge_duplication_hook_holder): Likewise.
(ipa_edge_args_sum): New variable.
(ipa_propagate_indirect_call_infos): Test ipa_edge_args_sum instead of
ipa_edge_args_vector.
(ipa_free_edge_args_substructures): Likewise.
(ipa_free_all_edge_args): Free ipa_edge_args_sum instead of
ipa_edge_args_vector.
(ipa_edge_removal_hook): Turned into method
ipa_edge_args_sum_t::remove.
(ipa_edge_duplication_hook): Turned into method
ipa_edge_args_sum_t::duplicate.
(ipa_register_cgraph_hooks): Create ipa_edge_args_sum instead of
registering edge hooks.
(ipa_unregister_cgraph_hooks): Do not unregister edge hooks.
* ipa-inline-analysis.c (estimate_function_body_sizes): Test
ipa_edge_args_sum instead of ipa_edge_args_vector.
* ipa-profile.c (ipa_profile): Likewise.

OK
Did you check what memory consumption consquences it have for Firefox?
Honza

Re: [RFC PATCH 3/3] Remove ipa_update_after_lto_read

[jh]

Dne 2017-02-27 17:35, Martin Jambor napsal:

Hello,

when working on call summaries, I have found a weird function
ipa_update_after_lto_read which currently only makes sure that IPA-CP
function and edge summaries exist, at times when they already have to
exist.

So I did some digging in history and found out that originally the
function was meant for setting a called_with_var_arguments flags where
appropriate after LTO stream-in.  We have however removed that flag in
2011 and the function is basically useless since then (although only
with call summaries it is definitely a no-OP).  Thus, I'll propose to
remove it next stage1.

Thanks,

Martin

2017-02-27  Martin Jambor  

* ipa-prop.c (ipa_update_after_lto_read): Removed.
* ipa-prop.h (ipa_update_after_lto_read): Remove declaration.
* ipa-cp.c (ipcp_propagate_stage): Do not call
ipa_update_after_lto_read.
* ipa-inline.c (ipa_inline): Likewise.


OK, thanks!
Whole streaming infrastructure would deserve major cleanups next stage1 
:)


Honza

Re: [RFC PATCH 1/3] call_summary to keep info about cgraph_edges

[jh]

Dne 2017-02-27 17:35, Martin Jambor napsal:

Hello,

this patch is an actual implementation of the call_summary class (I
hope the name is a good analogy to the function_summary we have, I am
opened to other suggestions).  I have kept the implementation close to
the existing one of function-summary, there are I think only two
notable differences:

  - there is no call_graph hook for new edge creation, which is in
fact quite natural, so there is no virtual function for that
event, and

  - edge UIDs start with zero, and the inliner does use it to index a
vector, so not only did I need to remove asserts that UIDs are
non-zero, I also had to actually increment them before using them
because apparently our hash-map does not like zero hashes.

Apart from that, I have introduced a predicate method exists to both
summaries, in order to figure out whether a summary for a given
node/edge already exists.  This is useful for example for dumping,
there is no need for dumping to allocate new stuff by querying.

Moreover, I have also spotted what I think is a bug in
function_summary::symtab_removal which does not call the destructor of
the item it holds when a function is removed and the item is
garbage-collecotr allocated.  Fixed in a simple hunk below.

I'll be grateful for any comments and/or suggestions,

Martin

2017-02-24  Martin Jambor  

* symbol-summary.h (function_summary): New method exists.
(function_summary::symtab_removal): Deallocate through release.
(call_summary): New class.
(gt_ggc_mx): New overload.
(gt_pch_nx): Likewise.
(gt_pch_nx): Likewise.


I like this - the way summaries was managed in ipa-prop was always bit 
twisty.
path is OK for next stage1. I guess we may consider putting 
cgraph_indirect_call_info into a summary too
and probably break it into multiple summaries (for example polymorhic 
call info can probably go separately)


Honza

---
 gcc/symbol-summary.h | 214 
++-

 1 file changed, 210 insertions(+), 4 deletions(-)

diff --git a/gcc/symbol-summary.h b/gcc/symbol-summary.h
index 3bcd14522c8..313082d7d5d 100644
--- a/gcc/symbol-summary.h
+++ b/gcc/symbol-summary.h
@@ -126,6 +126,12 @@ public:
 return m_map.elements ();
   }

+  /* Return true if a summary for the given NODE already exists.  */
+  bool exists (cgraph_node *node)
+  {
+return m_map.get (node->summary_uid) != NULL;
+  }
+
   /* Enable insertion hook invocation.  */
   void enable_insertion_hook ()
   {
@@ -160,10 +166,7 @@ public:
 if (v)
   {
summary->remove (node, *v);
-
-   if (!summary->m_ggc)
- delete (*v);
-
+   summary->release (*v);
summary->m_map.remove (summary_uid);
   }
   }
@@ -251,4 +254,207 @@ gt_pch_nx(function_summary* const& summary,
gt_pointer_operator op,
   gt_pch_nx (>m_map, op, cookie);
 }

+/* An impossible class templated by non-pointers so, which makes sure 
that only

+   summaries gathering pointers can be created.  */
+
+template 
+class call_summary
+{
+private:
+  call_summary();
+};
+
+/* Class to store auxiliary information about call graph edges.  */
+
+template 
+class GTY((user)) call_summary 
+{
+public:
+  /* Default construction takes SYMTAB as an argument.  */
+  call_summary (symbol_table *symtab, bool ggc = false): m_ggc (ggc),
+m_map (13, ggc), m_released (false), m_symtab (symtab)
+  {
+m_symtab_removal_hook =
+  symtab->add_edge_removal_hook
+  (call_summary::symtab_removal, this);
+m_symtab_duplication_hook =
+  symtab->add_edge_duplication_hook
+  (call_summary::symtab_duplication, this);
+  }
+
+  /* Destructor.  */
+  virtual ~call_summary ()
+  {
+release ();
+  }
+
+  /* Destruction method that can be called for GGT purpose.  */
+  void release ()
+  {
+if (m_released)
+  return;
+
+m_symtab->remove_edge_removal_hook (m_symtab_removal_hook);
+m_symtab->remove_edge_duplication_hook 
(m_symtab_duplication_hook);

+
+/* Release all summaries.  */
+typedef typename hash_map ::iterator map_iterator;
+for (map_iterator it = m_map.begin (); it != m_map.end (); ++it)
+  release ((*it).second);
+
+m_released = true;
+  }
+
+  /* Traverses all summarys with a function F called with
+ ARG as argument.  */
+  template
+  void traverse (Arg a) const
+  {
+m_map.traverse  (a);
+  }
+
+  /* Basic implementation of removal operation.  */
+  virtual void remove (cgraph_edge *, T *) {}
+
+  /* Basic implementation of duplication operation.  */
+  virtual void duplicate (cgraph_edge *, cgraph_edge *, T *, T *) {}
+
+  /* Allocates new data that are stored within map.  */
+  T* allocate_new ()
+  {
+/* Call gcc_internal_because we do not want to call finalizer for
+   a type T.  We call dtor explicitly.  */
+return m_ggc ? new (ggc_internal_alloc (sizeof (T))) T () : new T 
() ;

+  }
+
+  /* Release an item 

Re: [RFA PATCH, i386]: Warn for 64-bit values in general-reg asm operands and error out for 8-bit values in invalid GR asm operand

[Richard Biener]

On Tue, 28 Feb 2017, Uros Bizjak wrote:

> Hello!
> 
> Attached patch:
> 
> a) warns for 64-bit values in GR asm operand on 32bit targets
> 
> It is impossible to pass 64-bit (long long) value in 32bit register.
> We should warn for this situation, since only 32bit lowpart value is
> passed. The warning can be omitted by explicitly casting asm operand
> to int.
> 
> b) errors out for 8-bit values in invalid GR asm operand
> 
> We can detect invalid %sil, %dil and %bpl asm operands early, and
> terminate compilation in the compiler, not later in the assembler.
> 
> 2017-02-28  Uros Bizjak  
> 
> * config/i386/i386.c (print_reg): Warn for values of 64-bit size
> in integer register on 32-bit targets.  Error out for values of
> 8-bit size in invalid integer register.
> 
> testsuite/ChangeLog:
> 
> 2017-02-28  Uros Bizjak  
> 
> * gcc.target/i386/invsize-1.c: New test.
> * gcc.target/i386/invsize-2.c: Ditto.
> 
> OK for mainline in stage 4?

Yes.

Richard.

> Uros.
> 
> --cut here--
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 14ac189..e64bbe7 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -17641,6 +17641,9 @@ print_reg (rtx x, int code, FILE *file)
>switch (msize)
>  {
>  case 8:
> +  if (LEGACY_INT_REGNO_P (regno) && !TARGET_64BIT)
> +   warning (0, "unsupported size for integer register in 32-bit mode");
> +  /* FALLTHRU */
>  case 4:
>if (LEGACY_INT_REGNO_P (regno))
> putc (msize == 8 && TARGET_64BIT ? 'r' : 'e', file);
> @@ -17654,6 +17657,8 @@ print_reg (rtx x, int code, FILE *file)
>  case 1:
>if (regno >= ARRAY_SIZE (qi_reg_name))
> goto normal;
> +  if (!ANY_QI_REGNO_P (regno))
> +   error ("unsupported size for integer register in 32-bit mode");
>reg = qi_reg_name[regno];
>break;
>  case 0:
> --cut here--
> 
> /* { dg-do compile { target ia32 } } */
> 
> void foo (long long x)
> {
>   __asm__ volatile ("# %0" : : "r" (x));   /* { dg-warning
> "unsupported size" }  */
> }
> 
> /* { dg-do compile { target ia32 } } */
> 
> void foo (char x)
> {
>   register char rx  __asm ("si") = x;
> 
>   __asm__ volatile ("# %0" : : "r" (rx));   /* { dg-error "unsupported
> size" }  */
> }
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

[RFA PATCH, i386]: Warn for 64-bit values in general-reg asm operands and error out for 8-bit values in invalid GR asm operand

[Uros Bizjak]

Hello!

Attached patch:

a) warns for 64-bit values in GR asm operand on 32bit targets

It is impossible to pass 64-bit (long long) value in 32bit register.
We should warn for this situation, since only 32bit lowpart value is
passed. The warning can be omitted by explicitly casting asm operand
to int.

b) errors out for 8-bit values in invalid GR asm operand

We can detect invalid %sil, %dil and %bpl asm operands early, and
terminate compilation in the compiler, not later in the assembler.

2017-02-28  Uros Bizjak  

* config/i386/i386.c (print_reg): Warn for values of 64-bit size
in integer register on 32-bit targets.  Error out for values of
8-bit size in invalid integer register.

testsuite/ChangeLog:

2017-02-28  Uros Bizjak  

* gcc.target/i386/invsize-1.c: New test.
* gcc.target/i386/invsize-2.c: Ditto.

OK for mainline in stage 4?

Uros.

--cut here--
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 14ac189..e64bbe7 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -17641,6 +17641,9 @@ print_reg (rtx x, int code, FILE *file)
   switch (msize)
 {
 case 8:
+  if (LEGACY_INT_REGNO_P (regno) && !TARGET_64BIT)
+   warning (0, "unsupported size for integer register in 32-bit mode");
+  /* FALLTHRU */
 case 4:
   if (LEGACY_INT_REGNO_P (regno))
putc (msize == 8 && TARGET_64BIT ? 'r' : 'e', file);
@@ -17654,6 +17657,8 @@ print_reg (rtx x, int code, FILE *file)
 case 1:
   if (regno >= ARRAY_SIZE (qi_reg_name))
goto normal;
+  if (!ANY_QI_REGNO_P (regno))
+   error ("unsupported size for integer register in 32-bit mode");
   reg = qi_reg_name[regno];
   break;
 case 0:
--cut here--

/* { dg-do compile { target ia32 } } */

void foo (long long x)
{
  __asm__ volatile ("# %0" : : "r" (x));   /* { dg-warning
"unsupported size" }  */
}

/* { dg-do compile { target ia32 } } */

void foo (char x)
{
  register char rx  __asm ("si") = x;

  __asm__ volatile ("# %0" : : "r" (rx));   /* { dg-error "unsupported
size" }  */
}

Re: [BUILDROBOT] arm-netbsdelf: Error during -fself-test (was: [PATCH] TS_OPTIMIZATION/TS_TARGET_OPTION need no chain/type)

[Jan-Benedict Glaw]

On Mon, 2017-02-27 09:19:51 +0100, Richard Biener  wrote:
> On Mon, 27 Feb 2017, Jan-Benedict Glaw wrote:
> > On Wed, 2017-01-11 16:28:33 +0100, Richard Biener  wrote:
> > > On Wed, 11 Jan 2017, Richard Biener wrote:
> > > > LTO bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> > > > 
> > > > (most "gross" are still TS_LIST having a type and TS_VEC having type
> > > > and chain, but that's been hard to fix with the C++ FE in place)
> > > 
> > > Forgot the tree-core.h part.
> > > 
> > > Re-bootstrapping testing on x86_64-unknown-linux-gnu.
> > > 
> > > Richard.
> > > 
> > > 2017-01-11  Richard Biener  
> > > 
> > >   * tree.c (initialize_tree_contains_struct): Make TS_OPTIMIZATION
> > >   and TS_TARGET_OPTION directly derive from TS_BASE.
> > >   * tree-core.h (tree_optimization_option): Derive from tree_base.
> > >   (tree_target_option): Likewise.
> > 
> > This caused (or uncovered) a self-test issue on arm-netbsdelf (as run
> > by config-list.mk), like in this build:
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=696565
[...]
> > Reverting your patch from current HEAD lets the self-test pass. Do you
> > spot something obvious?
> 
> No, can you see which collect call in the self-test is involved?
> That is, a better backtrace, eventually when compiling the testcase
> with -O0?

Starting with selftest::run_tests(), these tests need to be run to
trigger it, all others can be omitted:

ggc_tests_c_tests ();
input_c_tests ();
gimple_c_tests ();
rtl_tests_c_tests ();
read_rtl_function_c_tests ();
--> forcibly_ggc_collect ();

In this constellation, we have on the stack:

(gdb) bt full
#0  0x008aad77 in lookup_page_table_entry (p=0x7) at 
../../gcc/gcc/ggc-page.c:635
base = 0x23649c0
L1 = 246
L2 = 320
table = 0x0
high_bits = 0
#1  0x008abe72 in ggc_set_mark (p=0x7) at ../../gcc/gcc/ggc-page.c:1532
entry = 0x76140228
bit = 23
word = 0
mask = 7730548
__FUNCTION__ = "ggc_set_mark"
#2  0x00782d27 in gt_ggc_mx_lang_tree_node (x_p=0x76140228) at 
./gt-c-c-decl.h:49
x = 0x76140228
xlimit = 0x7
__FUNCTION__ = "gt_ggc_mx_lang_tree_node"
#3  0x00784b7a in gt_ggc_mx_lang_tree_node (x_p=0x76472000) at 
./gt-c-c-decl.h:401
i1 = 8
l1 = 252
x = 0x76472000
xlimit = 0x0
__FUNCTION__ = "gt_ggc_mx_lang_tree_node"
#4  0x007849e2 in gt_ggc_mx_lang_tree_node (x_p=0x764695e8) at 
./gt-c-c-decl.h:382
x = 0x764695e8
xlimit = 0x0
__FUNCTION__ = "gt_ggc_mx_lang_tree_node"
#5  0x00782e29 in gt_ggc_mx_lang_tree_node (x_p=0x7646b6c0) at 
./gt-c-c-decl.h:68
x = 0x7646b6c0
xlimit = 0x0
__FUNCTION__ = "gt_ggc_mx_lang_tree_node"
#6  0x00af4520 in ggc_mark_root_tab (rt=0x1a19c40 
) at ../../gcc/gcc/ggc-common.c:77
i = 0
#7  0x00af45b1 in ggc_mark_roots () at ../../gcc/gcc/ggc-common.c:94
rt = 0x1990db8 
rtp = 0x0
rti = 0x1998850 
i = 360777445376
#8  0x008ad064 in ggc_collect () at ../../gcc/gcc/ggc-page.c:2202
allocated_last_gc = 4194304
min_expand = 1258291.25
#9  0x00afa314 in selftest::forcibly_ggc_collect () at 
../../gcc/gcc/ggc-tests.c:36
No locals.
#10 0x0181357d in selftest::run_tests () at 
../../gcc/gcc/selftest-run-tests.c:103
start_time = 28000
finish_time = 0
elapsed_time = 9164999
#11 0x00ea352c in toplev::run_self_tests (this=0x7fffe190) at 
../../gcc/gcc/toplev.c:2048
No locals.
#12 0x00ea36d3 in toplev::main (this=0x7fffe190, argc=20, 
argv=0x7fffe298)
at ../../gcc/gcc/toplev.c:2125
__FUNCTION__ = "main"
#13 0x018565b2 in main (argc=20, argv=0x7fffe298) at 
../../gcc/gcc/main.c:39
toplev = {m_use_TV_TOTAL = true, m_init_signals = true}

Just for the moment, maybe more tonight.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
  Signature of:   Wenn ich wach bin, träume ich.
  the second  :


signature.asc
Description: Digital signature

Re: [PR 78140] Reuse same IPA bits and VR info

[jh]

According to my measurements, the patch saves about 1.2 GB of memory.
The problem is that some change last week (between revision 245382 and
245595) has more than invalidated this:

  | compiler| WPA mem (GB) |
  |-+--|
  | gcc 6 branch| 3.86 |
  | trunk rev. 245382   | 5.21 |
  | patched rev. 245382 | 4.06 |


This looks good indeed!

2017-02-20  Martin Jambor  

PR lto/78140
* ipa-prop.h (ipa_bits): Removed field known.
(ipa_jump_func): Removed field vr_known.  Changed fields bits and m_vr
to pointers.  Adjusted their comments to warn about their sharing.
(ipcp_transformation_summary): Change bits to a vector of pointers.
(ipa_check_create_edge_args): Moved to ipa-prop.c, declare.
(ipa_get_ipa_bits_for_value): Declare.
* tree-vrp.h (value_range): Mark as GTY((for_user)).
* ipa-prop.c (ipa_bit_ggc_hash_traits): New.
(ipa_bits_hash_table): Likewise.
(ipa_vr_ggc_hash_traits): Likewise.
(ipa_vr_hash_table): Likewise.
(ipa_print_node_jump_functions_for_edge): Adjust for bits and m_vr
being pointers and vr_known being removed.
(ipa_set_jf_unknown): Likewise.
(ipa_get_ipa_bits_for_value): New function.
(ipa_set_jfunc_bits): Likewise.
(ipa_get_value_range): New overloaded functions.
(ipa_set_jfunc_vr): Likewise.
(ipa_compute_jump_functions_for_edge): Use the above functions to
construct bits and vr parts of jump functions.
(ipa_check_create_edge_args): Move here from ipa-prop.h, also allocate
ipa_bits_hash_table and ipa_vr_hash_table if they do not already
exist.
(ipcp_grow_transformations_if_necessary): Also allocate
ipa_bits_hash_table and ipa_vr_hash_table if they do not already
exist.
(ipa_node_params_t::duplicate): Do not copy bits, just pointers to
them.  Fix too long lines.
(ipa_write_jump_function): Adjust for bits and m_vr being pointers and
vr_known being removed.
(ipa_read_jump_function): Use new setter functions to construct bits
and vr parts of jump functions or set them to NULL.
(write_ipcp_transformation_info): Adjust for bits being pointers.
(read_ipcp_transformation_info): Likewise.
(ipcp_update_bits): Likewise.  Fix excessively long lines a trailing
space.
Include gt-ipa-prop.h.
* ipa-cp.c (propagate_bits_across_jump_function): Adjust for bits
being pointers.
(ipcp_store_bits_results): Likewise.
(propagate_vr_across_jump_function): Adjust for m_vr being a pointer.
Do not write to existing jump functions but use a temporary instead.


OK,
thanks!
Honza

Re: PR79715: Special case strcpy/strncpy for dse

[Jakub Jelinek]

On Tue, Feb 28, 2017 at 03:33:11PM +0530, Prathamesh Kulkarni wrote:
> Hi,
> The attached patch adds special-casing for strcpy/strncpy to dse pass.
> Bootstrapped+tested on x86_64-unknown-linux-gnu.
> OK for GCC 8 ?

What is special on strcpy/strncpy?  Unlike memcpy/memmove/memset, you don't
know the length they store (at least not in general), you don't know the
value, all you know is that they are for the first argument plain store
without remembering the pointer or anything based on it anywhere except in
the return value.
I believe stpcpy, stpncpy, strcat, strncat at least have the same behavior.
On the other side, without knowing the length of the store, you can't treat
it as killing something (ok, some calls like strcpy or stpcpy store at least
the first byte).

> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr79715.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/pr79715.c
> new file mode 100644
> index 000..1a832ca
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr79715.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-dse-details" } */
> +
> +void f(const char *s)
> +{
> +  unsigned n = __builtin_strlen (s) + 1;
> +  char *p = __builtin_malloc (n);
> +  __builtin_strcpy (p, s);
> +  __builtin_free (p);
> +}
> +
> +/* { dg-final { scan-tree-dump "Deleted dead call: __builtin_strcpy" "dse1" 
> } } */
> diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
> index 53feaf3..6d3c3c3 100644
> --- a/gcc/tree-ssa-dse.c
> +++ b/gcc/tree-ssa-dse.c
> @@ -97,6 +97,8 @@ initialize_ao_ref_for_dse (gimple *stmt, ao_ref *write)
> case BUILT_IN_MEMCPY:
> case BUILT_IN_MEMMOVE:
> case BUILT_IN_MEMSET:
> +   case BUILT_IN_STRNCPY:
> +   case BUILT_IN_STRCPY:
>   {
> tree size = NULL_TREE;
> if (gimple_call_num_args (stmt) == 3)
> @@ -395,6 +397,8 @@ maybe_trim_memstar_call (ao_ref *ref, sbitmap live, 
> gimple *stmt)
>  {
>  case BUILT_IN_MEMCPY:
>  case BUILT_IN_MEMMOVE:
> +case BUILT_IN_STRNCPY:
> +case BUILT_IN_STRCPY:
>{
>   int head_trim, tail_trim;
>   compute_trims (ref, live, _trim, _trim, stmt);
> @@ -713,6 +717,7 @@ dse_dom_walker::dse_optimize_stmt (gimple_stmt_iterator 
> *gsi)
> case BUILT_IN_MEMCPY:
> case BUILT_IN_MEMMOVE:
> case BUILT_IN_MEMSET:
> +   case BUILT_IN_STRNCPY:
>   {
> /* Occasionally calls with an explicit length of zero
>show up in the IL.  It's pointless to do analysis
> @@ -723,7 +728,10 @@ dse_dom_walker::dse_optimize_stmt (gimple_stmt_iterator 
> *gsi)
> delete_dead_call (gsi);
> return;
>   }
> -
> + }
> +   /* fallthru  */
> +   case BUILT_IN_STRCPY:
> + {
> gimple *use_stmt;
> enum dse_store_status store_status;
> m_byte_tracking_enabled


Jakub

Re: Documentation patch related to PR42376

[Gerald Pfeifer]

On Mon, 27 Feb 2017, Sandra Loosemore wrote:
> E  I would have written "more slowly" (since this is an adverb
> modifying "run"), but apparently both usages are correct.
> 
> https://www.grammarly.com/answers/questions/79959-comparing-with-adverbs/

Thank you, Sandra!

Since both are viable, and you prefer "more slowly", and so did
Martin by submitting his patch, I went ahead and committed this
change.

Ger "learned something new" ald

[PATCH] Fix PR79731

[Richard Biener]

Bootstrap / regtest running on x86_64-unknown-linux-gnu.

Richard.

2017-02-28  Richard Biener  

PR middle-end/79731
* fold-const.c (decode_field_reference): Reject out-of-bound
accesses.

* c-c++-common/torture/pr79731.c: New testcase.

Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 245772)
+++ gcc/fold-const.c(working copy)
@@ -4133,7 +4133,10 @@ decode_field_reference (location_t loc,
   punsignedp, preversep, pvolatilep);
   if ((inner == exp && and_mask == 0)
   || *pbitsize < 0 || offset != 0
-  || TREE_CODE (inner) == PLACEHOLDER_EXPR)
+  || TREE_CODE (inner) == PLACEHOLDER_EXPR
+  /* Reject out-of-bound accesses (PR79731).  */
+  || compare_tree_int (TYPE_SIZE (TREE_TYPE (exp)),
+  *pbitpos + *pbitsize) < 0)
 return 0;
 
   *exp_ = exp;
Index: gcc/testsuite/c-c++-common/torture/pr79731.c
===
--- gcc/testsuite/c-c++-common/torture/pr79731.c(nonexistent)
+++ gcc/testsuite/c-c++-common/torture/pr79731.c(working copy)
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-Wno-psabi -w" } */
+
+typedef unsigned V __attribute__ ((vector_size (8)));
+V
+foo (unsigned x, V v)
+{
+  do {
+  v %= x;
+  x = 1;
+  } while (v[1]);
+  return v;
+}
+void fn2 ()
+{
+  V x = foo (5, (V) { 0, 1 });
+  if (x[0] || x[1] || x[2] || x[3]);
+}

[PATCH] Fix PR79740

[Richard Biener]

Bootstrap / regtest running on x86_64-unknown-linux-gnu.

Richard.

2017-02-28  Richard Biener  

PR tree-optimization/79740
* tree-ssa-sccvn.c (visit_nary_op): Insert the nary into the
hashtable if we pattern-matched sth.
* tree-ssa-pre.c (eliminate_insert): Robustify.

* gcc.dg/torture/pr79740.c: New testcase.

Index: gcc/tree-ssa-sccvn.c
===
*** gcc/tree-ssa-sccvn.c(revision 245772)
--- gcc/tree-ssa-sccvn.c(working copy)
*** visit_nary_op (tree lhs, gassign *stmt)
*** 3544,3550 
  result = vn_nary_build_or_lookup (NOP_EXPR,
type, ops);
  if (result)
!   return set_ssa_val_to (lhs, result);
}
  else
{
--- 3544,3554 
  result = vn_nary_build_or_lookup (NOP_EXPR,
type, ops);
  if (result)
!   {
! bool changed = set_ssa_val_to (lhs, result);
! vn_nary_op_insert_stmt (stmt, result);
! return changed;
!   }
}
  else
{
*** visit_nary_op (tree lhs, gassign *stmt)
*** 3555,3561 
TREE_TYPE (lhs),
ops);
  if (result)
!   return set_ssa_val_to (lhs, result);
}
}
}
--- 3559,3569 
TREE_TYPE (lhs),
ops);
  if (result)
!   {
! bool changed = set_ssa_val_to (lhs, result);
! vn_nary_op_insert_stmt (stmt, result);
! return changed;
!   }
}
}
}
Index: gcc/tree-ssa-pre.c
===
*** gcc/tree-ssa-pre.c  (revision 245772)
--- gcc/tree-ssa-pre.c  (working copy)
*** eliminate_push_avail (tree op)
*** 4099,4106 
  static tree
  eliminate_insert (gimple_stmt_iterator *gsi, tree val)
  {
!   gimple *stmt = gimple_seq_first_stmt (VN_INFO (val)->expr);
!   if (!is_gimple_assign (stmt)
|| (!CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (stmt))
  && gimple_assign_rhs_code (stmt) != VIEW_CONVERT_EXPR
  && gimple_assign_rhs_code (stmt) != BIT_FIELD_REF
--- 4099,4110 
  static tree
  eliminate_insert (gimple_stmt_iterator *gsi, tree val)
  {
!   /* We can insert a sequence with a single assignment only.  */
!   gimple_seq stmts = VN_INFO (val)->expr;
!   if (!gimple_seq_singleton_p (stmts))
! return NULL_TREE;
!   gassign *stmt = dyn_cast  (gimple_seq_first_stmt (stmts));
!   if (!stmt
|| (!CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (stmt))
  && gimple_assign_rhs_code (stmt) != VIEW_CONVERT_EXPR
  && gimple_assign_rhs_code (stmt) != BIT_FIELD_REF
*** eliminate_insert (gimple_stmt_iterator *
*** 4116,4123 
if (!leader)
  return NULL_TREE;
  
-   gimple_seq stmts = NULL;
tree res;
if (gimple_assign_rhs_code (stmt) == BIT_FIELD_REF)
  res = gimple_build (, BIT_FIELD_REF,
TREE_TYPE (val), leader,
--- 4120,4127 
if (!leader)
  return NULL_TREE;
  
tree res;
+   stmts = NULL;
if (gimple_assign_rhs_code (stmt) == BIT_FIELD_REF)
  res = gimple_build (, BIT_FIELD_REF,
TREE_TYPE (val), leader,
Index: gcc/testsuite/gcc.dg/torture/pr79740.c
===
*** gcc/testsuite/gcc.dg/torture/pr79740.c  (nonexistent)
--- gcc/testsuite/gcc.dg/torture/pr79740.c  (working copy)
***
*** 0 
--- 1,19 
+ /* { dg-do compile } */
+ 
+ int a;
+ short b;
+ short fn1(unsigned short p1) { return p1 << a; }
+ 
+ int main()
+ {
+   short c;
+   int d = 4;
+   for (; b;)
+ {
+   c = d + 1;
+   fn1(c);
+   d = 0;
+ }
+   d++;
+   return 0;
+ }

[PATCH] Fix PR79732

[Richard Biener]

Bootstrap / regtest running on x86_64-unknown-linux-gnu.

Richard.

2017-02-28  Richard Biener  

PR tree-optimization/79732
* tree-inline.c (expand_call_inline): Do not shadow var.

* gcc.dg/torture/pr79732.c: New testcase.

Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c   (revision 245753)
+++ gcc/tree-inline.c   (working copy)
@@ -4782,7 +4782,7 @@ expand_call_inline (basic_block bb, gimp
{
  if (!var)
{
- tree var = create_tmp_reg_fn (cfun, TREE_TYPE (name), NULL);
+ var = create_tmp_reg_fn (cfun, TREE_TYPE (name), NULL);
  SET_SSA_NAME_VAR_OR_IDENTIFIER (name, var);
}
  /* Otherwise make this variable undefined.  */
Index: gcc/testsuite/gcc.dg/torture/pr79732.c
===
--- gcc/testsuite/gcc.dg/torture/pr79732.c  (nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr79732.c  (working copy)
@@ -0,0 +1,5 @@
+/* { dg-do link } */
+
+int bar () __attribute__ ((alias ("foo")));
+void foo () { }
+int main () { return bar(); }

PR79715: Special case strcpy/strncpy for dse

[Prathamesh Kulkarni]

Hi,
The attached patch adds special-casing for strcpy/strncpy to dse pass.
Bootstrapped+tested on x86_64-unknown-linux-gnu.
OK for GCC 8 ?

Thanks,
Prathamesh
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr79715.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr79715.c
new file mode 100644
index 000..1a832ca
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr79715.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-dse-details" } */
+
+void f(const char *s)
+{
+  unsigned n = __builtin_strlen (s) + 1;
+  char *p = __builtin_malloc (n);
+  __builtin_strcpy (p, s);
+  __builtin_free (p);
+}
+
+/* { dg-final { scan-tree-dump "Deleted dead call: __builtin_strcpy" "dse1" } 
} */
diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
index 53feaf3..6d3c3c3 100644
--- a/gcc/tree-ssa-dse.c
+++ b/gcc/tree-ssa-dse.c
@@ -97,6 +97,8 @@ initialize_ao_ref_for_dse (gimple *stmt, ao_ref *write)
  case BUILT_IN_MEMCPY:
  case BUILT_IN_MEMMOVE:
  case BUILT_IN_MEMSET:
+ case BUILT_IN_STRNCPY:
+ case BUILT_IN_STRCPY:
{
  tree size = NULL_TREE;
  if (gimple_call_num_args (stmt) == 3)
@@ -395,6 +397,8 @@ maybe_trim_memstar_call (ao_ref *ref, sbitmap live, gimple 
*stmt)
 {
 case BUILT_IN_MEMCPY:
 case BUILT_IN_MEMMOVE:
+case BUILT_IN_STRNCPY:
+case BUILT_IN_STRCPY:
   {
int head_trim, tail_trim;
compute_trims (ref, live, _trim, _trim, stmt);
@@ -713,6 +717,7 @@ dse_dom_walker::dse_optimize_stmt (gimple_stmt_iterator 
*gsi)
  case BUILT_IN_MEMCPY:
  case BUILT_IN_MEMMOVE:
  case BUILT_IN_MEMSET:
+ case BUILT_IN_STRNCPY:
{
  /* Occasionally calls with an explicit length of zero
 show up in the IL.  It's pointless to do analysis
@@ -723,7 +728,10 @@ dse_dom_walker::dse_optimize_stmt (gimple_stmt_iterator 
*gsi)
  delete_dead_call (gsi);
  return;
}
-
+   }
+ /* fallthru  */
+ case BUILT_IN_STRCPY:
+   {
  gimple *use_stmt;
  enum dse_store_status store_status;
  m_byte_tracking_enabled

Re: [PATCH 0/6] Improve -fprefetch-loop-arrays in general and for AArch64 in particular

[Maxim Kuvyrkov]

> On Feb 20, 2017, at 5:38 PM, Kyrill Tkachov  
> wrote:
> 
> Hi Maxim,
> 
> On 30/01/17 11:24, Maxim Kuvyrkov wrote:
>> This patch series improves -fprefetch-loop-arrays pass through small fixes 
>> and tweaks, and then enables it for several AArch64 cores.
>> 
>> My tunings were done on and for Qualcomm hardware, with results varying 
>> between +0.5-1.9% for SPEC2006 INT and +0.25%-1.0% for SPEC2006 FP at -O3, 
>> depending on hardware revision.
>> 
>> This patch series enables restricted -fprefetch-loop-arrays at -O2, which 
>> also improves SPEC2006 numbers
>> 
>> Biggest progressions are on 419.mcf and 437.leslie3d, with no serious 
>> regressions on other benchmarks.
>> 
>> I'm now investigating making -fprefetch-loop-arrays more aggressive for 
>> Qualcomm hardware, which improves performance on most benchmarks, but also 
>> causes big regressions on 454.calculix and 462.libquantum.  If I can fix 
>> these two regressions, prefetching will give another boost to AArch64.
>> 
>> Andrew just posted similar prefetching tunings for Cavium's cores, and the 
>> two patches have trivial conflicts.  I'll post mine as-is, since it address 
>> one of the comments on Andrew's review (adding a stand-alone struct for 
>> tuning parameters).
>> 
>> Andrew, feel free to just copy-paste it to your patch, since it is just a 
>> mechanical change.
>> 
>> All patches were bootstrapped and regtested on x86_64-linux-gnu and 
>> aarch64-linux-gnu.
>>  
> 
> I've tried these patches out on Cortex-A72 and Cortex-A53, with the tuning 
> structs entries appropriately
> modified to enable the changes on those cores.
> I'm seeing the mcf and leslie3d improvements as well on Cortex-A72 and 
> Cortex-A53 and no noticeable regressions.
> I've also verified that the improvements are due to the prefetch instructions 
> rather than just the unrolling that
> the pass does.
> So I'm in favor of enabling this for the cores that benefit from it.
> 
> Do you plan to get this in for GCC 8?

Hi Kyrill,

My hope was to push them in time for GCC 7, but it seems to late now.  I'll 
return to these patches at the beginning of Stage 1.

--
Maxim Kuvyrkov
www.linaro.org

Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.

[Martin Jambor]

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
> > ===
> > +  -Os).  This optimization and its option supersede
> > +  interprocedural alignment propagation of gcc 6, and therefore the
> > +  option -fipa-cp-alignment is now deprecated and
> > +  ignored.
> 
> 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.html28 Feb 2017 08:11:56 -  1.69
+++ changes.html28 Feb 2017 09:50:20 -
@@ -67,7 +67,10 @@
   the call graph.  It is enabled by the -fipa-bit-cp
   option if -fipa-cp is enabled as well, and is enabled
   at the -O2 optimization level and higher (and
-  -Os).
+  -Os).  This optimization supersedes interprocedural
+  alignment propagation of GCC 6, and therefore the
+  option -fipa-cp-alignment is now deprecated and
+  ignored.
 
   A new interprocedural value range propagation optimization has been
   added, which propagates integral ranges that variable values can be proven

Re: [wwwdocs] Update changes.html for LTO and IPA

[Jan Hubicka]

> On Wed, 20 Jan 2016, Jan Hubicka wrote:
> > this is updated patch.  I tried to explain better the situation WRT
> > incremental linking.
> 
> Thank you, Jan.  I had a couple of editorial changes on top of
> this, which I finally managed to commit.  (See the patch below.)
> 
> And one question: "declaration linking" is used in the description
> of Link-time optimization improvements, alas that string does not 
> appear anywhere in either the source tree or documentation?

It is my own name indeed. lto-symtab.c does merge declarations
when they refer to same symbol name. Newly we do not merge when the
symbol names does not appear semantically similar enough.
We can also call it declaration merging, but it is internal name anyway
and most link-time optimization papers reffer to these merging processes
as linking.

Honza
> 
> On Wed, 3 Feb 2016, Jonathan Wakely wrote:
> > s/of C++ methods/in C++ member functions/
> 
> This one got changed only partially in the patch applied last year, 
> and I have adjusted this now to read "in C++ member functions" as 
> opposed to "of C++ member functions".
> 
> Gerald
> 
> Index: changes.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
> retrieving revision 1.95
> diff -u -r1.95 changes.html
> --- changes.html  25 Feb 2017 17:46:38 -  1.95
> +++ changes.html  27 Feb 2017 22:29:33 -
> @@ -59,12 +59,12 @@
>   on higher-level C++ programs. Programs doing invalid type punning
>   of pointer types may now need -fno-strict-aliasing
>   to work correctly.
> -Alias analysis now correctly supports weakref and
> - alias attributes. This makes it possible to access
> +Alias analysis now correctly supports the weakref and
> + alias attributes. This allows accessing
>   both a variable and its alias in one translation unit which is common
>   with link-time optimization.
>  Value range propagation now assumes that the this 
> pointer
> - of C++ member functions is non-null.  This eliminates
> + in C++ member functions is non-null.  This eliminates
>   common null pointer checks
>   but also breaks some non-conforming code-bases (such as Qt-5, Chromium,
>   KDevelop). As a temporary work-around
> @@ -74,7 +74,8 @@
>  
>warning and error attributes are now
> correctly preserved by declaration linking and thus
> -   -D_FORTIFY_SOURCE=2 is now supported with 
> -flto.
> +   -D_FORTIFY_SOURCE=2 is now supported with
> +   -flto.
>Type merging was fixed to handle C and Fortran interoperability
> rules as defined by the Fortran 2008 language standard.
> 
> @@ -83,10 +84,10 @@
> char is scalar.
> INTEGER(KIND=C_SIGNED_CHAR) should be used instead.
> In general, this inter-operability cannot be implemented, for
> -   example, on targets where function passing conventions of arrays
> -   differs from scalars.
> -  More type information is now preserved at link time reducing
> -   the loss of accuracy of the type based alias analysis compared
> +   example on targets where the argument passing convention for
> +   arrays differs from scalars.
> +  More type information is now preserved at link time, reducing
> +   the loss of accuracy of the type-based alias analysis compared
> to builds without link-time optimization.
>Invalid type punning on global variables and declarations is now
> reported with -Wodr-type-mismatch.
> @@ -96,30 +97,35 @@
> was significantly improved by decreasing the size of streamed
> data when partitioning programs.  The size of streamed
> IL while compiling Firefox 46.0 was reduced by 66%.
> -  The linker plugin was extended to pass information about type of
> -   binary produced to GCC back end (that can be also manually controlled
> -   by -flinker-output).  This makes it possible to
> +  The linker plugin was extended to pass information about the
> +   type of binary produced to the GCC back end. (That can also be
> +   controlled manually by -flinker-output.)
> +   This makes it possible to
> properly configure the code generator and support incremental
> -   linking. Incremental linking of LTO objects by gcc -r is
> -   now supported on plugin-enabled setups.
> +   linking. Incremental linking of LTO objects by gcc -r
> +   is now supported for plugin-enabled setups.
> There are two ways to perform incremental linking:
> 
>Linking by ld -r will result in an object file
>with all sections from individual object files mechanically merged.
> -  This delays the actual link time optimization to final linking step
> -  and thus permits whole program optimization.  Linking final binary
> +  This delays the actual link-time optimization to 

Miscellaneous optimization group fixes

[Thomas Schwinge]

Hi!

On Wed, 22 Feb 2017 10:38:02 +0100, Martin Jambor  wrote:
> On Wed, Feb 22, 2017 at 08:58:06AM +0100, Thomas Schwinge wrote:
> > On top of [...], OK to commit the following (not yet tested) -- these all
> > look like oversights to me, but please verify?
> 
> The missing documentation is an oversight.  Thanks for spotting it.

Committed to trunk in r245769:

commit 7246f4462796dfc937c203ba651d5d7ec4c7c89e
Author: tschwinge 
Date:   Tue Feb 28 08:42:06 2017 +

Miscellaneous optimization group fixes

gcc/
* doc/optinfo.texi (Optimization groups): Fix option used for
OPTGROUP_ALL.
* doc/invoke.texi (-fopt-info): Document "omp".
* dumpfile.h: Sort OPTGROUP_OMP before OPTGROUP_VEC.
(OPTGROUP_ALL): Add OPTGROUP_OMP.
* hsa-gen.c (pass_data_gen_hsail): Use OPTGROUP_OMP.
* ipa-hsa.c (pass_data_ipa_hsa): Likewise.
* omp-simd-clone.c (pass_data_omp_simd_clone): Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@245769 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog| 9 +
 gcc/doc/invoke.texi  | 2 ++
 gcc/doc/optinfo.texi | 2 +-
 gcc/dumpfile.h   | 6 +++---
 gcc/hsa-gen.c| 2 +-
 gcc/ipa-hsa.c| 2 +-
 gcc/omp-simd-clone.c | 2 +-
 7 files changed, 18 insertions(+), 7 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index b699944..cd95521 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,5 +1,14 @@
 2017-02-28  Thomas Schwinge  
 
+   * doc/optinfo.texi (Optimization groups): Fix option used for
+   OPTGROUP_ALL.
+   * doc/invoke.texi (-fopt-info): Document "omp".
+   * dumpfile.h: Sort OPTGROUP_OMP before OPTGROUP_VEC.
+   (OPTGROUP_ALL): Add OPTGROUP_OMP.
+   * hsa-gen.c (pass_data_gen_hsail): Use OPTGROUP_OMP.
+   * ipa-hsa.c (pass_data_ipa_hsa): Likewise.
+   * omp-simd-clone.c (pass_data_omp_simd_clone): Likewise.
+
* dumpfile.h (OPTGROUP_OPENMP): Rename to OPTGROUP_OMP.  Adjust
all users.
* dumpfile.c (optgroup_options): Instead of "openmp", associate
diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
index 1b9fdfe..d90c95c 100644
--- gcc/doc/invoke.texi
+++ gcc/doc/invoke.texi
@@ -13155,6 +13155,8 @@ Enable dumps from all interprocedural optimizations.
 Enable dumps from all loop optimizations.
 @item inline
 Enable dumps from all inlining optimizations.
+@item omp
+Enable dumps from all OMP (Offloading and Multi Processing) optimizations.
 @item vec
 Enable dumps from all vectorization optimizations.
 @item optall
diff --git gcc/doc/optinfo.texi gcc/doc/optinfo.texi
index cf6ce00..e17cb37 100644
--- gcc/doc/optinfo.texi
+++ gcc/doc/optinfo.texi
@@ -70,7 +70,7 @@ Vectorization passes. Enabled by @option{-vec}.
 All other optimization passes which do not fall into one of the above.
 
 @item OPTGROUP_ALL
-All optimization passes. Enabled by @option{-all}.
+All optimization passes. Enabled by @option{-optall}.
 
 @end ftable
 
diff --git gcc/dumpfile.h gcc/dumpfile.h
index 3886f98..fef58f5 100644
--- gcc/dumpfile.h
+++ gcc/dumpfile.h
@@ -98,12 +98,12 @@ enum tree_dump_index
 #define OPTGROUP_IPA (1 << 1)   /* IPA optimization passes */
 #define OPTGROUP_LOOP(1 << 2)   /* Loop optimization passes */
 #define OPTGROUP_INLINE  (1 << 3)   /* Inlining passes */
-#define OPTGROUP_VEC (1 << 4)   /* Vectorization passes */
-#define OPTGROUP_OMP (1 << 5)   /* OMP (Offloading and Multi
+#define OPTGROUP_OMP (1 << 4)   /* OMP (Offloading and Multi
   Processing) transformations */
+#define OPTGROUP_VEC (1 << 5)   /* Vectorization passes */
 #define OPTGROUP_OTHER   (1 << 6)   /* All other passes */
 #define OPTGROUP_ALL(OPTGROUP_IPA | OPTGROUP_LOOP | OPTGROUP_INLINE \
-  | OPTGROUP_VEC | OPTGROUP_OTHER)
+  | OPTGROUP_OMP | OPTGROUP_VEC | OPTGROUP_OTHER)
 
 /* Define a tree dump switch.  */
 struct dump_file_info
diff --git gcc/hsa-gen.c gcc/hsa-gen.c
index 7721fcc..7b69d64 100644
--- gcc/hsa-gen.c
+++ gcc/hsa-gen.c
@@ -6474,7 +6474,7 @@ const pass_data pass_data_gen_hsail =
 {
   GIMPLE_PASS,
   "hsagen",/* name */
-  OPTGROUP_NONE,   /* optinfo_flags */
+  OPTGROUP_OMP,/* optinfo_flags */
   TV_NONE, /* tv_id */
   PROP_cfg | PROP_ssa, /* properties_required */
   0,   /* properties_provided */
diff --git gcc/ipa-hsa.c gcc/ipa-hsa.c
index af70b0a..c02dada 100644
--- gcc/ipa-hsa.c
+++ gcc/ipa-hsa.c
@@ -289,7 +289,7 @@ const pass_data pass_data_ipa_hsa =
 {
   IPA_PASS, /* type */
   "hsa", /* name */
-  OPTGROUP_NONE, /* optinfo_flags */
+  OPTGROUP_OMP, /* optinfo_flags */
   TV_IPA_HSA, /* 

Rename the "openmp" group of optimizations to "omp" (was: Miscellaneous optimization group fixes)

[Thomas Schwinge]

Hi!

On Wed, 22 Feb 2017 10:38:02 +0100, Martin Jambor  wrote:
> On Wed, Feb 22, 2017 at 08:58:06AM +0100, Thomas Schwinge wrote:
> > > 
> > > Rename the "openmp" group of optimizations to "omp"
> > > 
> > > gcc/
> > > * dumpfile.h (OPTGROUP_OPENMP): Rename to OPTGROUP_OMP.  
> > > Adjust
> > > all users.
> > > * dumpfile.c (optgroup_options): Instead of "openmp", 
> > > associate
> > > OPTGROUP_OMP with "omp".
> 
> 
> I am of course fine with OPTGROUP_OMP.

Committed to trunk in r245768:

commit f57c8178d89b6b428853767657590c4fb907d1b8
Author: tschwinge 
Date:   Tue Feb 28 08:41:55 2017 +

Rename the "openmp" group of optimizations to "omp"

gcc/
* dumpfile.h (OPTGROUP_OPENMP): Rename to OPTGROUP_OMP.  Adjust
all users.
* dumpfile.c (optgroup_options): Instead of "openmp", associate
OPTGROUP_OMP with "omp".

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@245768 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog| 7 +++
 gcc/doc/optinfo.texi | 5 +++--
 gcc/dumpfile.c   | 2 +-
 gcc/dumpfile.h   | 3 ++-
 gcc/omp-expand.c | 4 ++--
 gcc/omp-low.c| 4 ++--
 gcc/omp-offload.c| 6 +++---
 7 files changed, 20 insertions(+), 11 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index 9c1025d..b699944 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,10 @@
+2017-02-28  Thomas Schwinge  
+
+   * dumpfile.h (OPTGROUP_OPENMP): Rename to OPTGROUP_OMP.  Adjust
+   all users.
+   * dumpfile.c (optgroup_options): Instead of "openmp", associate
+   OPTGROUP_OMP with "omp".
+
 2017-02-27  Pat Haugen  
 
PR target/79544
diff --git gcc/doc/optinfo.texi gcc/doc/optinfo.texi
index 415e9a9..cf6ce00 100644
--- gcc/doc/optinfo.texi
+++ gcc/doc/optinfo.texi
@@ -59,8 +59,9 @@ Loop optimization passes. Enabled by @option{-loop}.
 @item OPTGROUP_INLINE
 Inlining passes. Enabled by @option{-inline}.
 
-@item OPTGROUP_OPENMP
-OpenMP passes. Enabled by @option{-openmp}.
+@item OPTGROUP_OMP
+OMP (Offloading and Multi Processing) passes. Enabled by
+@option{-omp}.
 
 @item OPTGROUP_VEC
 Vectorization passes. Enabled by @option{-vec}.
diff --git gcc/dumpfile.c gcc/dumpfile.c
index 2c5dce2..6b9a47c 100644
--- gcc/dumpfile.c
+++ gcc/dumpfile.c
@@ -140,7 +140,7 @@ static const struct dump_option_value_info 
optgroup_options[] =
   {"ipa", OPTGROUP_IPA},
   {"loop", OPTGROUP_LOOP},
   {"inline", OPTGROUP_INLINE},
-  {"openmp", OPTGROUP_OPENMP},
+  {"omp", OPTGROUP_OMP},
   {"vec", OPTGROUP_VEC},
   {"optall", OPTGROUP_ALL},
   {NULL, 0}
diff --git gcc/dumpfile.h gcc/dumpfile.h
index 7c8f7a2..3886f98 100644
--- gcc/dumpfile.h
+++ gcc/dumpfile.h
@@ -99,7 +99,8 @@ enum tree_dump_index
 #define OPTGROUP_LOOP(1 << 2)   /* Loop optimization passes */
 #define OPTGROUP_INLINE  (1 << 3)   /* Inlining passes */
 #define OPTGROUP_VEC (1 << 4)   /* Vectorization passes */
-#define OPTGROUP_OPENMP  (1 << 5)  /* OpenMP specific transformations */
+#define OPTGROUP_OMP (1 << 5)   /* OMP (Offloading and Multi
+  Processing) transformations */
 #define OPTGROUP_OTHER   (1 << 6)   /* All other passes */
 #define OPTGROUP_ALL(OPTGROUP_IPA | OPTGROUP_LOOP | OPTGROUP_INLINE \
   | OPTGROUP_VEC | OPTGROUP_OTHER)
diff --git gcc/omp-expand.c gcc/omp-expand.c
index 55e54e4..ea951d6 100644
--- gcc/omp-expand.c
+++ gcc/omp-expand.c
@@ -8134,7 +8134,7 @@ const pass_data pass_data_expand_omp =
 {
   GIMPLE_PASS, /* type */
   "ompexp", /* name */
-  OPTGROUP_OPENMP, /* optinfo_flags */
+  OPTGROUP_OMP, /* optinfo_flags */
   TV_NONE, /* tv_id */
   PROP_gimple_any, /* properties_required */
   PROP_gimple_eomp, /* properties_provided */
@@ -8181,7 +8181,7 @@ const pass_data pass_data_expand_omp_ssa =
 {
   GIMPLE_PASS, /* type */
   "ompexpssa", /* name */
-  OPTGROUP_OPENMP, /* optinfo_flags */
+  OPTGROUP_OMP, /* optinfo_flags */
   TV_NONE, /* tv_id */
   PROP_cfg | PROP_ssa, /* properties_required */
   PROP_gimple_eomp, /* properties_provided */
diff --git gcc/omp-low.c gcc/omp-low.c
index 35df02c..c2c69cb 100644
--- gcc/omp-low.c
+++ gcc/omp-low.c
@@ -8920,7 +8920,7 @@ const pass_data pass_data_lower_omp =
 {
   GIMPLE_PASS, /* type */
   "omplower", /* name */
-  OPTGROUP_OPENMP, /* optinfo_flags */
+  OPTGROUP_OMP, /* optinfo_flags */
   TV_NONE, /* tv_id */
   PROP_gimple_any, /* properties_required */
   PROP_gimple_lomp | PROP_gimple_lomp_dev, /* properties_provided */
@@ -9232,7 +9232,7 @@ const pass_data pass_data_diagnose_omp_blocks =
 {
   GIMPLE_PASS, /* type */
   "*diagnose_omp_blocks", /* name */
-  OPTGROUP_OPENMP, /* optinfo_flags */
+  OPTGROUP_OMP, /* optinfo_flags */
   TV_NONE, /* tv_id */
   PROP_gimple_any, /*