Re: [PATCH] Fortran -- clean up KILL

[Steve Kargl]

On Mon, Mar 12, 2018 at 09:05:09PM +0200, Janne Blomqvist wrote:
> 
> Yes, I understand that -fdefault-integer-8 (or whatever the equivalent
> option was called on g77) is the original motivation. Like I said, I
> don't have any particular opinion on whether we should keep that
> restriction or not. On one hand, more recent versions of the standard
> has lifted restrictions that integer intrinsic arguments have to be of
> default kind in many cases, OTOH KILL is not a standard intrinsic but
> something inherited from g77. So, meh.

The Fortran standard specifically permits a Fortran processor to 
supply additional subprograms not contained in the Fortran standard.
I personally can't any person person using INTEGER(1) or even 
INTEGER(2) with KILL as pid_t on typical modern OS's exceeds HUGE()
in those types.  My original patch simply fixed KILL to actually
conform to its documentation.  But is this what you want

2018-03-12  Steven G. Kargl  

* check.c (gfc_check_kill_sub):  Remove check for INTEGER(4) or (8).
* intrinsic.c (add_functions): Remove reference to gfc_resolve_kill.
(add_subroutines): Remove reference to gfc_resolve_kill_sub.
* intrinsic.texi: Update documentation.
* iresolve.c (gfc_resolve_kill, gfc_resolve_kill_sub): Remove.
* trans-decl.c (gfc_build_intrinsic_function_decls):  Add 
gfor_fndecl_kill
and gfor_fndecl_kill_sub
* trans-intrinsic.c (conv_intrinsic_kill, conv_intrinsic_kill_sub): new
functions.
(gfc_conv_intrinsic_function): Use conv_intrinsic_kill.
(gfc_conv_intrinsic_subroutine): Use conv_intrinsic_kill_sub.
* trans.h: Declare gfor_fndecl_kill and gfor_fndecl_kill_sub.
 
2018-03-12  Steven G. Kargl  

* libgfortran/gfortran.map: Remove _gfortran_kill_i4, 
_gfortran_kill_i4_sub,
_gfortran_kill_i8, and _gfortran_kill_i8_sub.  Add _gfortran_kill and
_gfortran_kill_sub.
* libgfortran/intrinsics/kill.c: Eliminate _gfortran_kill_i4,
_gfortran_kill_i4_sub, _gfortran_kill_i8, and _gfortran_kill_i8_sub.
Add _gfortran_kill and _gfortran_kill_sub.

-- 
Steve
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c	(revision 258468)
+++ gcc/fortran/check.c	(working copy)
@@ -2783,20 +2783,13 @@ gfc_check_kill_sub (gfc_expr *pid, gfc_expr *sig, gfc_
   if (!scalar_check (sig, 1))
 return false;
 
-  if (status == NULL)
-return true;
-
-  if (!type_check (status, 2, BT_INTEGER))
-return false;
-
-  if (!scalar_check (status, 2))
-return false;
-
-  if (status->ts.kind != 4 && status->ts.kind != 8)
+  if (status)
 {
-  gfc_error ("Invalid kind type parameter for STATUS at %L",
-		 >where);
-  return false;
+  if (!type_check (status, 2, BT_INTEGER))
+	return false;
+
+  if (!scalar_check (status, 2))
+	return false;
 }
 
   return true;
Index: gcc/fortran/intrinsic.c
===
--- gcc/fortran/intrinsic.c	(revision 258468)
+++ gcc/fortran/intrinsic.c	(working copy)
@@ -2255,7 +2255,7 @@ add_functions (void)
   make_generic ("ishftc", GFC_ISYM_ISHFTC, GFC_STD_F95);
 
   add_sym_2 ("kill", GFC_ISYM_KILL, CLASS_IMPURE, ACTUAL_NO, BT_INTEGER,
-	 di, GFC_STD_GNU, gfc_check_kill, NULL, gfc_resolve_kill,
+	 di, GFC_STD_GNU, gfc_check_kill, NULL, NULL,
 	 pid, BT_INTEGER, di, REQUIRED, sig, BT_INTEGER, di, REQUIRED);
 
   make_generic ("kill", GFC_ISYM_KILL, GFC_STD_GNU);
@@ -3724,7 +3724,7 @@ add_subroutines (void)
 	  st, BT_INTEGER, di, OPTIONAL, INTENT_OUT);
 
   add_sym_3s ("kill", GFC_ISYM_KILL, CLASS_IMPURE, BT_UNKNOWN, 0, GFC_STD_GNU,
-	  gfc_check_kill_sub, NULL, gfc_resolve_kill_sub,
+	  gfc_check_kill_sub, NULL, NULL,
 	  pid, BT_INTEGER, di, REQUIRED, INTENT_IN,
 	  sig, BT_INTEGER, di, REQUIRED, INTENT_IN,
 	  st, BT_INTEGER, di, OPTIONAL, INTENT_OUT);
Index: gcc/fortran/intrinsic.texi
===
--- gcc/fortran/intrinsic.texi	(revision 258468)
+++ gcc/fortran/intrinsic.texi	(working copy)
@@ -8719,7 +8719,7 @@ Sends the signal specified by @var{SIG} to the process
 See @code{kill(2)}.
 
 This intrinsic is provided in both subroutine and function forms;
-however,  only one form can be used in any given program unit.
+however, only one form can be used in any given program unit.
 
 @item @emph{Class}:
 Subroutine, function
@@ -8732,16 +8732,13 @@ Subroutine, function
 
 @item @emph{Arguments}:
 @multitable @columnfractions .15 .70
-@item @var{PID} @tab Shall be a scalar @code{INTEGER} with
-@code{INTENT(IN)}
-@item @var{SIG} @tab Shall be a scalar @code{INTEGER} with
-@code{INTENT(IN)}
-@item @var{STATUS} @tab [Subroutine](Optional) status flag of type
-@code{INTEGER(4)} or @code{INTEGER(8)}.
+@item @var{PID} @tab Shall be a scalar @code{INTEGER} with 

[PATCH][PR target/84838] Minor grammar fixes for x86 options

[David H. Gutteridge]

This is a patch to correct some minor grammatical errors in the x86
options documentation. "Nor" isn't correct usage in these sentences,
and there was a missing definite article (in keeping with the style
used elsewhere for that same option).

Regards,

Dave

2018-03-12  David H. Gutteridge  

PR target/84838
* Minor grammar fixes for x86 options.

--- gcc/doc/invoke.texi.orig
+++ gcc/doc/invoke.texi
@@ -27877,9 +27877,9 @@
 function attribute @code{indirect_branch}.  @xref{Function Attributes}.
 
 Note that @option{-mcmodel=large} is incompatible with
-@option{-mindirect-branch=thunk} nor
+@option{-mindirect-branch=thunk} and
 @option{-mindirect-branch=thunk-extern} since the thunk function may
-not be reachable in large code model.
+not be reachable in the large code model.
 
 Note that @option{-mindirect-branch=thunk-extern} is incompatible with
 @option{-fcf-protection=branch} and @option{-fcheck-pointer-bounds}
@@ -27898,9 +27898,9 @@
 @xref{Function Attributes}.
 
 Note that @option{-mcmodel=large} is incompatible with
-@option{-mfunction-return=thunk} nor
+@option{-mfunction-return=thunk} and
 @option{-mfunction-return=thunk-extern} since the thunk function may
-not be reachable in large code model.
+not be reachable in the large code model.
 
 
 @item -mindirect-branch-register

Re: [PATCH] use attribute exclusion to reject naked vs target_clones conflicts (PR 84723)

[Martin Sebor]

Since Jakub has committed an alternate patch that fixes
the ICE (below) this change is no longer necessary for GCC 8.
It still is in my view the right way to address the main part
of the problem so I will resubmit it for GCC 9 in stage 1.

https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00285.html

Martin

On 03/06/2018 10:19 PM, Martin Sebor wrote:

PR 84723 is about an ICE caused by GCC accepting the mutually
exclusive attributes target_clones and naked during parsing,
only to then later crash while assuming such conflicts don't
happen.

The attached patch adds an exclusion for the two attributes
to detect when they're both specified on declarations of the
same function and avoid the ICE that way (there are other
problems with target_clones that are unrelated to other
interaction with other attributes).

As this is the first instance of an exclusion between a pair
of a front/middle-end and back-end attributes, testing the
straightforward solution of just adding an exclusion for them
exposed a restriction in the implementation that required more
extensive changes to make things work.  The current (unpatched)
code requires exclusions to be symmetric (e.g., when there is
an exclusion entry for target_clones and naked, there must also
be another exclusion entry the other way around).  This makes
sense for attributes in the same table (e.g., all C/C++
attributes, or all i386 back-end attributes) but not between
attributes in different tables.  The patch makes additional
changes to allow asymmetric exclusions without compromising
the detection of attribute conflicts.  This additional
enhancement allowed me to remove the self tests.

Since I started working on this last night Jakub has already
posted an alternate fix that doesn't make use of the exclusion
framework (plus it fixes the additional bugs/ICEs I referred
to above).  This patch is thus meant to apply on top of Jakub's
(the tests will need tweaking to adjust the expected diagnostics).
If my solution is considered too invasive at this stage I'm fine
holding off on it and re-posting it in stage 1.  While working
on it I noticed other opportunities for improvements in this
area that I would like to make then.

Martin

PR target/84743 adjust reassociation widths for power8/power9

[Aaron Sawdey]

Looking at CPU2017 results for different reassociation widths, things
have shifted since I last looked at this with CPU2006 in early gcc7
timeframe. Best thing to do seems to be to set reassociation width to 1
for all integer modes, which is what the attached patch does.

I also tried setting width to 1 for float modes PLUS_EXPR as this patch
did for aarch64 but this does not seem to be helpful for power8.
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01271.html


Results below are % performance improvement on power8 comparing trunk
with the attached patch vs trunk with --param tree-reassoc-width=1 to
disable parallel reassociation for everything (first column of results)
and trunk unmodified (second column of results). 

CPU2017 componentvs width=1   vs trunk
500.perlbench_r-0.36% -0.15%
502.gcc_r   0.06%  0.04%
505.mcf_r   0.32%  0.24%
520.omnetpp_r   0.57% -0.95%
523.xalancbmk_r 1.45%  1.04%
525.x264_r -0.05%  0.09%
531.deepsjeng_r 0.04%  0.09%
541.leela_r 0.10%  0.72%
548.exchange2_r 0.08%  0.73%
557.xz_r0.09%  2.12%
CPU2017 int geo mean0.23%  0.40%
503.bwaves_r0.00%  0.01%
507.cactuBSSN_r 0.05% -0.02%
508.namd_r  0.00%  0.00%
510.parest_r   -0.01%  0.20%
511.povray_r0.03% -0.24%
519.lbm_r  -0.04% -0.16%
521.wrf_r  -0.01% -0.56%
526.blender_r  -0.82% -0.47%
527.cam4_r -0.18%  0.06%
538.imagick_r  -0.02%  0.01%
544.nab_r   0.00%  0.23%
549.fotonik3d_r 0.24%  0.54%
554.roms_r -0.05%  0.03%
CPU2017 fp geo mean-0.06% -0.03%

Bottom line is net improvement for CPU2017 int compared with either
current trunk, or disabling parallel reassociation. For CPU2017 fp,
very small overall degradation. 

Currently doing regstrap on ppc64le, ok for trunk if results look good?

Thanks!
   Aaron

2018-03-12  Aaron Sawdey  

PR target/84743
* config/rs6000/rs6000.c (rs6000_reassociation_width): Disable parallel
reassociation for int modes.


-- 
Aaron Sawdey, Ph.D.  acsaw...@linux.vnet.ibm.com
050-2/C113  (507) 253-7520 home: 507/263-0782
IBM Linux Technology Center - PPC ToolchainIndex: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c	(revision 258101)
+++ gcc/config/rs6000/rs6000.c	(working copy)
@@ -10006,7 +10006,7 @@
   if (VECTOR_MODE_P (mode))
 	return 4;
   if (INTEGRAL_MODE_P (mode)) 
-	return opc == MULT_EXPR ? 4 : 6;
+	return 1;
   if (FLOAT_MODE_P (mode))
 	return 4;
   break;

Re: Patch ping

[Jason Merrill]

OK.

On Mon, Mar 12, 2018 at 10:22 AM, Jakub Jelinek  wrote:
> Hi!
>
> I'd like to ping the
>
> http://gcc.gnu.org/ml/gcc-patches/2018-03/msg00238.html
>   - PR84704 - ICE on a[({ 0; })] op= something with -g
>
> patch.  Thanks.
>
> Jakub

Re: [C++ PATCH] Fix constexpr.c find_array_ctor_elt (PR c++/84808)

[Jason Merrill]

OK.

On Mon, Mar 12, 2018 at 4:58 PM, Jakub Jelinek  wrote:
> Hi!
>
> The following testcase ICEs, because in code to break up a RANGE_EXPR
> we have a reference to a constructor element:
>   constructor_elt  = (*elts)[middle];
> and do conditionally:
>   vec_safe_insert (CONSTRUCTOR_ELTS (ary), middle, e);
> and later:
>   e.value = unshare_constructor (elt.value);
> vec_safe_insert can reallocate the array whose element elt references,
> and so  then points to uninitialized memory.
>
> Fixed by remembering elt.value before we adjust the CONSTRUCTOR_ELTS.
> Additionally, I've found that in the ctor where normally all indexes were
> sizetype ones suddenly some of them had integer_type_node type, the
> dindex = fold_convert (sizetype, dindex);
> line ought to fix that.  The rest is just formatting fix.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-03-12  Jakub Jelinek  
>
> PR c++/84808
> * constexpr.c (find_array_ctor_elt): Don't use elt reference after
> first potential CONSTRUCTOR_ELTS reallocation.  Convert dindex to
> sizetype.  Formatting fixes.
>
> * g++.dg/cpp1y/constexpr-84808.C: New test.
>
> --- gcc/cp/constexpr.c.jj   2018-03-07 22:52:02.0 +0100
> +++ gcc/cp/constexpr.c  2018-03-12 12:39:46.890321137 +0100
> @@ -2194,9 +2194,9 @@ find_array_ctor_elt (tree ary, tree dind
>   that the same is true of the other elements and index directly.  */
>if (end > 0)
>  {
> -  tree cindex = (*elts)[end-1].index;
> +  tree cindex = (*elts)[end - 1].index;
>if (TREE_CODE (cindex) == INTEGER_CST
> - && compare_tree_int (cindex, end-1) == 0)
> + && compare_tree_int (cindex, end - 1) == 0)
> {
>   if (i < end)
> return i;
> @@ -2225,6 +2225,8 @@ find_array_ctor_elt (tree ary, tree dind
>   constructor_elt e;
>   tree lo = TREE_OPERAND (idx, 0);
>   tree hi = TREE_OPERAND (idx, 1);
> + tree value = elt.value;
> + dindex = fold_convert (sizetype, dindex);
>   if (tree_int_cst_lt (lo, dindex))
> {
>   /* There are still some lower elts; shorten the range.  */
> @@ -2238,7 +2240,7 @@ find_array_ctor_elt (tree ary, tree dind
>   /* Append the element we want to insert.  */
>   ++middle;
>   e.index = dindex;
> - e.value = unshare_constructor (elt.value);
> + e.value = unshare_constructor (value);
>   vec_safe_insert (CONSTRUCTOR_ELTS (ary), middle, e);
> }
>   else
> @@ -2254,8 +2256,8 @@ find_array_ctor_elt (tree ary, tree dind
> e.index = hi;
>   else
> e.index = build2 (RANGE_EXPR, sizetype, new_lo, hi);
> - e.value = unshare_constructor (elt.value);
> - vec_safe_insert (CONSTRUCTOR_ELTS (ary), middle+1, e);
> + e.value = unshare_constructor (value);
> + vec_safe_insert (CONSTRUCTOR_ELTS (ary), middle + 1, e);
> }
> }
>   return middle;
> --- gcc/testsuite/g++.dg/cpp1y/constexpr-84808.C.jj 2018-03-12 
> 12:45:29.472374837 +0100
> +++ gcc/testsuite/g++.dg/cpp1y/constexpr-84808.C2018-03-12 
> 12:46:11.742381465 +0100
> @@ -0,0 +1,27 @@
> +// PR c++/84808
> +// { dg-do compile { target c++14 } }
> +
> +struct A { int i; constexpr A () : i() {} };
> +struct B { A a[24]; };
> +
> +constexpr int
> +foo (int n)
> +{
> +  B b;
> +  ++b.a[n + 20].i;
> +  ++b.a[n + 18].i;
> +  ++b.a[n + 16].i;
> +  ++b.a[n + 14].i;
> +  ++b.a[n + 12].i;
> +  ++b.a[n + 10].i;
> +  ++b.a[n + 8].i;
> +  ++b.a[n + 6].i;
> +  ++b.a[n + 4].i;
> +  ++b.a[n + 2].i;
> +  ++b.a[n].i;
> +  return b.a[2].i + b.a[4].i + b.a[6].i + b.a[8].i + b.a[10].i
> ++ b.a[12].i + b.a[14].i + b.a[16].i + b.a[18].i + b.a[20].i + 
> b.a[22].i;
> +}
> +
> +constexpr int i = foo (2);
> +static_assert (i == 11, "");
>
> Jakub

Re: [PATCH] accept attribute nonstring on all narrow characters (PR 84725)

[Jeff Law]

On 03/05/2018 01:54 PM, Martin Sebor wrote:
> Attribute nonstring is currently only allowed on arrays and
> pointers to plain char, but -Wstringop-truncation triggers
> even for strncpy calls whose arguments are arrays of signed
> or unsigned char (with or without a cast to char*).
> 
> To help deal with -Wstringop-truncation in the Linux kernel
> it was suggested to me that it would be useful to be able
> to make use of the attribute on all three narrow char types.
> Apparently, there are enough calls to strncpy in the Linux
> kernel with arguments of the other char types that trigger
> the new warning, and the warning is considered sufficiently
> useful that making use of the attribute to suppress
> the warning rather than changing it ignore the other
> two char types is preferable.
> 
> The attached patch relaxes the restriction and lets GCC
> accept attribute nonstring on all three narrow character
> types as well as their qualified forms.
> 
> Tested on x86_64-linux.
> 
> Martin
> 
> gcc-84725.diff
> 
> 
> PR tree-optimization/84725 - enable attribute nonstring for all narrow 
> character types
> 
> gcc/c-family/ChangeLog:
> 
>   PR tree-optimization/84725
>   * c-attribs.c (handle_nonstring_attribute): Allow attribute nonstring
>   with all three narrow character types, including their qualified forms.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/84725
>   * c-c++-common/Wstringop-truncation-4.c: New test.
>   * c-c++-common/attr-nonstring-5.c: New test.
While it's not a regression, I think getting this warning to a point
where it's usable by the linux kernel is a notable win.  So I'm going to
ACK it as an exception to the regression bugfixes only policy.

jeff

[patch] Fix PR lto/84805

[Eric Botcazou]

Hi,

this is an ICE in LTO mode on code violating the ODR rule: get_odr_type checks 
that there is a sensible internal order between base, type and derived types 
but this can be easily messed up by incomplete types.  Hence the attached 
fixlet (no testcase because the -Wodr warnings have a totally random order).

Tested on x86-64/Linux, OK for the mainline?


2018-03-12  Eric Botcazou  

PR lto/84805
* ipa-devirt.c (odr_subtypes_equivalent_p): Do not get the ODR type of
incomplete types.

-- 
Eric Botcazou
Index: ipa-devirt.c
===
--- ipa-devirt.c	(revision 258411)
+++ ipa-devirt.c	(working copy)
@@ -656,7 +656,7 @@ set_type_binfo (tree type, tree binfo)
   gcc_assert (!TYPE_BINFO (type));
 }
 
-/* Compare T2 and T2 based on name or structure.  */
+/* Compare T1 and T2 based on name or structure.  */
 
 static bool
 odr_subtypes_equivalent_p (tree t1, tree t2,
@@ -678,7 +678,7 @@ odr_subtypes_equivalent_p (tree t1, tree
 return false;
 
   /* For ODR types be sure to compare their names.
- To support -wno-odr-type-merging we allow one type to be non-ODR
+ To support -Wno-odr-type-merging we allow one type to be non-ODR
  and other ODR even though it is a violation.  */
   if (types_odr_comparable (t1, t2, true))
 {
@@ -690,6 +690,8 @@ odr_subtypes_equivalent_p (tree t1, tree
 	 therefore which call will report the ODR violation, if any.  */
 	 if (!odr_type_p (t1)
 	 || !odr_type_p (t2)
+	 || !COMPLETE_TYPE_P (t1)
+	 || !COMPLETE_TYPE_P (t2)
 	 || (!get_odr_type (t1, true)->odr_violated
 		 && !get_odr_type (t2, true)->odr_violated))
 return true;

[PATCH] PR libstdc++/84773 use aligned alloc functions for FreeBSD and MinGW cross-compilers

[Jonathan Wakely]

Cross-compilers for FreeBSD and MinGW do not currently check for
aligned_alloc, posix_memalign, _aligned_malloc etc which are used by
native compilers when available. This omission caused bootstrap failures
for FreeBSD cross-compilers, and caused ABI differences for MinGW due
to a different implementation of operator new(size_t, align_val_t).

Also add a using-declaration for aligned_alloc in namespace std for
C++17 support.

PR libstdc++/84773
PR libstdc++/83662
* crossconfig.m4: Check for aligned_alloc etc. on freebsd and mingw32.
* configure: Regenerate.
* include/c_global/cstdlib [_GLIBCXX_HAVE_ALIGNED_ALLOC]
(aligned_alloc): Add using-declaration.
* testsuite/18_support/aligned_alloc/aligned_alloc.cc: New test.

Tested powerpc64le-linux, and by building cross-compilers for
x86_64-unknown-freebsd11.0 and x86_64-w64-mingw32. Committed to trunk,
backport to gcc-7-branch to follow.
commit e06031f334cfffe11c5249f96e685d309c554306
Author: Jonathan Wakely 
Date:   Fri Mar 9 01:19:51 2018 +

PR libstdc++/84773 use aligned alloc functions for FreeBSD and MinGW 
cross-compilers

PR libstdc++/84773
PR libstdc++/83662
* crossconfig.m4: Check for aligned_alloc etc. on freebsd and 
mingw32.
* configure: Regenerate.
* include/c_global/cstdlib [_GLIBCXX_HAVE_ALIGNED_ALLOC]
(aligned_alloc): Add using-declaration.
* testsuite/18_support/aligned_alloc/aligned_alloc.cc: New test.

diff --git a/libstdc++-v3/crossconfig.m4 b/libstdc++-v3/crossconfig.m4
index a8b1da9a607..fa56795b25e 100644
--- a/libstdc++-v3/crossconfig.m4
+++ b/libstdc++-v3/crossconfig.m4
@@ -133,6 +133,7 @@ case "${host}" in
   AC_DEFINE(HAVE_ISNANL)
 fi
 AC_CHECK_FUNCS(__cxa_thread_atexit)
+AC_CHECK_FUNCS(aligned_alloc posix_memalign memalign _aligned_malloc)
 ;;
 
   *-fuchsia*)
@@ -197,6 +198,7 @@ case "${host}" in
 GLIBCXX_CHECK_LINKER_FEATURES
 GLIBCXX_CHECK_MATH_SUPPORT
 GLIBCXX_CHECK_STDLIB_SUPPORT
+AC_CHECK_FUNCS(aligned_alloc posix_memalign memalign _aligned_malloc)
 ;;
   *-netbsd*)
 SECTION_FLAGS='-ffunction-sections -fdata-sections'
diff --git a/libstdc++-v3/include/c_global/cstdlib 
b/libstdc++-v3/include/c_global/cstdlib
index a3b19f30b33..10335017f0c 100644
--- a/libstdc++-v3/include/c_global/cstdlib
+++ b/libstdc++-v3/include/c_global/cstdlib
@@ -78,6 +78,9 @@ namespace std
 
 // Get rid of those macros defined in  in lieu of real functions.
 #undef abort
+#if __cplusplus >= 201703L && defined(_GLIBCXX_HAVE_ALIGNED_ALLOC)
+# undef aligned_alloc
+#endif
 #undef atexit
 #if __cplusplus >= 201103L
 # ifdef _GLIBCXX_HAVE_AT_QUICK_EXIT
@@ -125,6 +128,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   using ::ldiv_t;
 
   using ::abort;
+#if __cplusplus >= 201703L && defined(_GLIBCXX_HAVE_ALIGNED_ALLOC)
+  using ::aligned_alloc;
+#endif
   using ::atexit;
 #if __cplusplus >= 201103L
 # ifdef _GLIBCXX_HAVE_AT_QUICK_EXIT
diff --git a/libstdc++-v3/testsuite/18_support/aligned_alloc/aligned_alloc.cc 
b/libstdc++-v3/testsuite/18_support/aligned_alloc/aligned_alloc.cc
new file mode 100644
index 000..8af9c723ad1
--- /dev/null
+++ b/libstdc++-v3/testsuite/18_support/aligned_alloc/aligned_alloc.cc
@@ -0,0 +1,42 @@
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++17" }
+// { dg-do run { target c++17 } }
+
+#include 
+#include 
+#include 
+
+void
+test01()
+{
+#ifdef _GLIBCXX_HAVE_ALIGNED_ALLOC
+  void* p = std::aligned_alloc(256, 1);
+  if (p)
+  {
+VERIFY( (reinterpret_cast(p) % 256) == 0 );
+std::free(p);
+  }
+#endif
+}
+
+int
+main()
+{
+  test01();
+}

[Ada] Fix PR ada/82813

[Eric Botcazou]

-Wstringop-overflow is supposed to be a C-family warning but it is somehow 
issued in Ada too and can warn on bogus cases so let's just kill it.

Tested on x86-64/Linux, applied on the mainline and 7 branch.


2018-03-12  Eric Botcazou  

PR ada/82813
* gcc-interface/misc.c (gnat_post_options): Disable string overflow
warnings.

-- 
Eric BotcazouIndex: gcc-interface/misc.c
===
--- gcc-interface/misc.c	(revision 258411)
+++ gcc-interface/misc.c	(working copy)
@@ -265,6 +265,9 @@ gnat_post_options (const char **pfilenam
   /* No return type warnings for Ada.  */
   warn_return_type = 0;
 
+  /* No string overflow warnings for Ada.  */
+  warn_stringop_overflow = 0;
+
   /* No caret by default for Ada.  */
   if (!global_options_set.x_flag_diagnostics_show_caret)
 global_dc->show_caret = false;

Re: [PATCH] Fix spelling of -mclflushopt in manual

[Jonathan Wakely]

On 12 March 2018 at 22:31, Jonathan Wakely wrote:
> Committed as obvious.

To trunk and the active branches.

[PATCH] Fix spelling of -mclflushopt in manual

[Jonathan Wakely]

Committed as obvious.
commit f242fcfe46b7bb82fcfe6cc536031d6d7af56c63
Author: Jonathan Wakely 
Date:   Mon Mar 12 22:28:47 2018 +

Fix spelling of -mclflushopt in manual

* doc/invoke.texi (-mclflushopt): Fix spelling of option.

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2492148b30f..5d383509797 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -27166,8 +27166,8 @@ preferred alignment to 
@option{-mpreferred-stack-boundary=2}.
 @itemx -mpclmul
 @opindex mpclmul
 @need 200
-@itemx -mclfushopt
-@opindex mclfushopt
+@itemx -mclflushopt
+@opindex mclflushopt
 @need 200
 @itemx -mfsgsbase
 @opindex mfsgsbase

[PATCH] Fix another CONSTRAINT_LEN related bug (PR middle-end/84831)

[Jakub Jelinek]

Hi!

I thought the vregs pass is the first one to analyze constraints,
but I was wrong, already before that parse_{output,input}_constraint
are called, already during GIMPLE passes.  They don't really fail miserably
if , appears in the middle of multi-letter constraint (unlike e.g. the RA),
which is what my previous patch was fixing, but care if '\0' appears
in the middle of multi-letter constraint, because then we continue walking
random characters after the constraint string.  parse_input_constraint
is actually fine, because it has c_len = strlen (constraint); and uses
j < c_len, but parse_output_constraint doesn't do that.  While doing it
is possible, I think it is needlessly slow (needs to walk the constraint
twice), so this patch instead makes sure there are no '\0's in the middle
of constraints, if there are, doesn't jump over it.

The patch is larger because of reindentation, here is diff -upbd for
easier understanding what has changed.

--- gcc/stmt.c.jj   2018-01-03 10:19:55.150533956 +0100
+++ gcc/stmt.c  2018-03-12 13:25:03.790733765 +0100
@@ -247,7 +247,8 @@ parse_output_constraint (const char **co
 }
 
   /* Loop through the constraint string.  */
-  for (p = constraint + 1; *p; p += CONSTRAINT_LEN (*p, p))
+  for (p = constraint + 1; *p; )
+{
 switch (*p)
   {
   case '+':
@@ -304,6 +305,11 @@ parse_output_constraint (const char **co
break;
   }
 
+  for (size_t len = CONSTRAINT_LEN (*p, p); len; len--, p++)
+   if (*p == '\0')
+ break;
+}
+
   return true;
 }
 
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-03-12  Jakub Jelinek  

PR middle-end/84831
* stmt.c (parse_output_constraint): If the CONSTRAINT_LEN (*p, p)
characters starting at p contain '\0' character, don't look beyond
that.

--- gcc/stmt.c.jj   2018-01-03 10:19:55.150533956 +0100
+++ gcc/stmt.c  2018-03-12 13:25:03.790733765 +0100
@@ -247,62 +247,68 @@ parse_output_constraint (const char **co
 }
 
   /* Loop through the constraint string.  */
-  for (p = constraint + 1; *p; p += CONSTRAINT_LEN (*p, p))
-switch (*p)
-  {
-  case '+':
-  case '=':
-   error ("operand constraint contains incorrectly positioned "
-  "%<+%> or %<=%>");
-   return false;
-
-  case '%':
-   if (operand_num + 1 == ninputs + noutputs)
- {
-   error ("%<%%%> constraint used with last operand");
-   return false;
- }
-   break;
-
-  case '?':  case '!':  case '*':  case '&':  case '#':
-  case '$':  case '^':
-  case 'E':  case 'F':  case 'G':  case 'H':
-  case 's':  case 'i':  case 'n':
-  case 'I':  case 'J':  case 'K':  case 'L':  case 'M':
-  case 'N':  case 'O':  case 'P':  case ',':
-   break;
-
-  case '0':  case '1':  case '2':  case '3':  case '4':
-  case '5':  case '6':  case '7':  case '8':  case '9':
-  case '[':
-   error ("matching constraint not valid in output operand");
-   return false;
-
-  case '<':  case '>':
-   /* ??? Before flow, auto inc/dec insns are not supposed to exist,
-  excepting those that expand_call created.  So match memory
-  and hope.  */
-   *allows_mem = true;
-   break;
-
-  case 'g':  case 'X':
-   *allows_reg = true;
-   *allows_mem = true;
-   break;
-
-  default:
-   if (!ISALPHA (*p))
- break;
-   enum constraint_num cn = lookup_constraint (p);
-   if (reg_class_for_constraint (cn) != NO_REGS
-   || insn_extra_address_constraint (cn))
+  for (p = constraint + 1; *p; )
+{
+  switch (*p)
+   {
+   case '+':
+   case '=':
+ error ("operand constraint contains incorrectly positioned "
+"%<+%> or %<=%>");
+ return false;
+
+   case '%':
+ if (operand_num + 1 == ninputs + noutputs)
+   {
+ error ("%<%%%> constraint used with last operand");
+ return false;
+   }
+ break;
+
+   case '?':  case '!':  case '*':  case '&':  case '#':
+   case '$':  case '^':
+   case 'E':  case 'F':  case 'G':  case 'H':
+   case 's':  case 'i':  case 'n':
+   case 'I':  case 'J':  case 'K':  case 'L':  case 'M':
+   case 'N':  case 'O':  case 'P':  case ',':
+ break;
+
+   case '0':  case '1':  case '2':  case '3':  case '4':
+   case '5':  case '6':  case '7':  case '8':  case '9':
+   case '[':
+ error ("matching constraint not valid in output operand");
+ return false;
+
+   case '<':  case '>':
+ /* ??? Before flow, auto inc/dec insns are not supposed to exist,
+excepting those that expand_call created.  So match memory
+and hope.  */
+ *allows_mem = true;
+ break;
+
+   case 'g':  case 'X':
  *allows_reg = true;
-   else if 

[C++ PATCH] Fix constexpr.c find_array_ctor_elt (PR c++/84808)

[Jakub Jelinek]

Hi!

The following testcase ICEs, because in code to break up a RANGE_EXPR
we have a reference to a constructor element:
  constructor_elt  = (*elts)[middle];
and do conditionally:
  vec_safe_insert (CONSTRUCTOR_ELTS (ary), middle, e);
and later:
  e.value = unshare_constructor (elt.value);
vec_safe_insert can reallocate the array whose element elt references,
and so  then points to uninitialized memory.

Fixed by remembering elt.value before we adjust the CONSTRUCTOR_ELTS.
Additionally, I've found that in the ctor where normally all indexes were
sizetype ones suddenly some of them had integer_type_node type, the
dindex = fold_convert (sizetype, dindex);
line ought to fix that.  The rest is just formatting fix.

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

2018-03-12  Jakub Jelinek  

PR c++/84808
* constexpr.c (find_array_ctor_elt): Don't use elt reference after
first potential CONSTRUCTOR_ELTS reallocation.  Convert dindex to
sizetype.  Formatting fixes.

* g++.dg/cpp1y/constexpr-84808.C: New test.

--- gcc/cp/constexpr.c.jj   2018-03-07 22:52:02.0 +0100
+++ gcc/cp/constexpr.c  2018-03-12 12:39:46.890321137 +0100
@@ -2194,9 +2194,9 @@ find_array_ctor_elt (tree ary, tree dind
  that the same is true of the other elements and index directly.  */
   if (end > 0)
 {
-  tree cindex = (*elts)[end-1].index;
+  tree cindex = (*elts)[end - 1].index;
   if (TREE_CODE (cindex) == INTEGER_CST
- && compare_tree_int (cindex, end-1) == 0)
+ && compare_tree_int (cindex, end - 1) == 0)
{
  if (i < end)
return i;
@@ -2225,6 +2225,8 @@ find_array_ctor_elt (tree ary, tree dind
  constructor_elt e;
  tree lo = TREE_OPERAND (idx, 0);
  tree hi = TREE_OPERAND (idx, 1);
+ tree value = elt.value;
+ dindex = fold_convert (sizetype, dindex);
  if (tree_int_cst_lt (lo, dindex))
{
  /* There are still some lower elts; shorten the range.  */
@@ -2238,7 +2240,7 @@ find_array_ctor_elt (tree ary, tree dind
  /* Append the element we want to insert.  */
  ++middle;
  e.index = dindex;
- e.value = unshare_constructor (elt.value);
+ e.value = unshare_constructor (value);
  vec_safe_insert (CONSTRUCTOR_ELTS (ary), middle, e);
}
  else
@@ -2254,8 +2256,8 @@ find_array_ctor_elt (tree ary, tree dind
e.index = hi;
  else
e.index = build2 (RANGE_EXPR, sizetype, new_lo, hi);
- e.value = unshare_constructor (elt.value);
- vec_safe_insert (CONSTRUCTOR_ELTS (ary), middle+1, e);
+ e.value = unshare_constructor (value);
+ vec_safe_insert (CONSTRUCTOR_ELTS (ary), middle + 1, e);
}
}
  return middle;
--- gcc/testsuite/g++.dg/cpp1y/constexpr-84808.C.jj 2018-03-12 
12:45:29.472374837 +0100
+++ gcc/testsuite/g++.dg/cpp1y/constexpr-84808.C2018-03-12 
12:46:11.742381465 +0100
@@ -0,0 +1,27 @@
+// PR c++/84808
+// { dg-do compile { target c++14 } }
+
+struct A { int i; constexpr A () : i() {} };
+struct B { A a[24]; };
+
+constexpr int
+foo (int n)
+{
+  B b;
+  ++b.a[n + 20].i;
+  ++b.a[n + 18].i;
+  ++b.a[n + 16].i;
+  ++b.a[n + 14].i;
+  ++b.a[n + 12].i;
+  ++b.a[n + 10].i;
+  ++b.a[n + 8].i;
+  ++b.a[n + 6].i;
+  ++b.a[n + 4].i;
+  ++b.a[n + 2].i;
+  ++b.a[n].i;
+  return b.a[2].i + b.a[4].i + b.a[6].i + b.a[8].i + b.a[10].i
++ b.a[12].i + b.a[14].i + b.a[16].i + b.a[18].i + b.a[20].i + 
b.a[22].i;
+}
+
+constexpr int i = foo (2);
+static_assert (i == 11, "");

Jakub

[PATCH] Fix -march=knl wrong-code (PR target/84786)

[Jakub Jelinek]

Hi!

For TARGET_AVX512F && !TARGET_AVX512VL, the RA ensures that
128-bit and 256-bit vectors aren't allocated in %xmm16+ registers,
but not so for scalar modes.  In that case we use avx512vl isa attribute,
or TARGET_AVX512VL guards, or Yv constraint.

The following patch does the last one for sse2_loadhpd pattern where the
last argument has DFmode and thus using v constraint for it is unsafe
and on the testcase we emit
vunpcklpd   %xmm18, %xmm0, %xmm0
instruction which needs avx512vl.  Bootstrapped/regtested on x86_64-linux
and i686-linux, ok for trunk?

2018-03-12  Jakub Jelinek  

PR target/84786
* config/i386/sse.md (sse2_loadhpd): Use Yv constraint rather than v
on the last operand.

* gcc.target/i386/avx512f-pr84786-1.c: New test.
* gcc.target/i386/avx512f-pr84786-2.c: New test.

--- gcc/config/i386/sse.md.jj   2018-03-05 17:00:24.568655800 +0100
+++ gcc/config/i386/sse.md  2018-03-12 11:05:48.917401886 +0100
@@ -9022,14 +9022,14 @@ (define_expand "sse2_loadhpd_exp"
 ;; see comment above inline_secondary_memory_needed function in i386.c
 (define_insn "sse2_loadhpd"
   [(set (match_operand:V2DF 0 "nonimmediate_operand"
- "=x,v,x,v,o,o ,o")
+ "=x,v,x,v ,o,o ,o")
(vec_concat:V2DF
  (vec_select:DF
(match_operand:V2DF 1 "nonimmediate_operand"
- " 0,v,0,v,0,0 ,0")
+ " 0,v,0,v ,0,0 ,0")
(parallel [(const_int 0)]))
  (match_operand:DF 2 "nonimmediate_operand"
- " m,m,x,v,x,*f,r")))]
+ " m,m,x,Yv,x,*f,r")))]
   "TARGET_SSE2 && !(MEM_P (operands[1]) && MEM_P (operands[2]))"
   "@
movhpd\t{%2, %0|%0, %2}
--- gcc/testsuite/gcc.target/i386/avx512f-pr84786-1.c.jj2018-03-12 
11:32:33.563665173 +0100
+++ gcc/testsuite/gcc.target/i386/avx512f-pr84786-1.c   2018-03-12 
11:35:33.964695384 +0100
@@ -0,0 +1,25 @@
+/* PR target/84786 */
+/* { dg-do run { target { ! ia32 } } } */
+/* { dg-options "-mavx512f -mno-avx512vl -O2" } */
+/* { dg-require-effective-target avx512f } */
+
+#include "avx512f-check.h"
+
+typedef double V __attribute__((vector_size (16)));
+
+__attribute__((noipa)) V
+foo (V x, double y)
+{
+  register double z __asm ("xmm18");
+  asm volatile ("" : "=v" (z) : "0" (y));
+  x[1] = z;
+  return x;
+}
+
+static void
+avx512f_test (void)
+{
+  V a = foo ((V) { 1.0, 2.0 }, 3.0);
+  if (a[0] != 1.0 || a[1] != 3.0)
+abort ();
+}
--- gcc/testsuite/gcc.target/i386/avx512f-pr84786-2.c.jj2018-03-12 
11:32:43.445666826 +0100
+++ gcc/testsuite/gcc.target/i386/avx512f-pr84786-2.c   2018-03-12 
11:35:45.260697279 +0100
@@ -0,0 +1,16 @@
+/* PR target/84786 */
+/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-options "-mavx512f -mno-avx512vl -O2" } */
+
+typedef double V __attribute__((vector_size (16)));
+
+__attribute__((noipa)) V
+foo (V x, double y)
+{
+  register double z __asm ("xmm18");
+  asm volatile ("" : "=v" (z) : "0" (y));
+  x[1] = z;
+  return x;
+}
+
+/* { dg-final { scan-assembler-not 
"vunpcklpd\[\^\n\r]*xmm(1\[6-9]|\[23]\[0-9])" } } */

Jakub

Re: [PATCH] S/390: Set ABI default based on uname

[Jakub Jelinek]

On Mon, Mar 12, 2018 at 06:42:15PM +0100, Andreas Krebbel wrote:
> On 03/12/2018 06:31 PM, Jakub Jelinek wrote:
> > On Mon, Mar 12, 2018 at 06:28:09PM +0100, Andreas Krebbel wrote:
> >> Currently the default ABI option for a GCC built on a 64 bit system is
> >> always -m64.  This is inconvenient when e.g. building 32 bit libraries
> >> on a 64 bit system.  The usual way to do this is to set the personality
> >> to s390 (32 bit) and let the configure script do the right thing.
> >> Having a GCC which defaults to -m64 also requires to get a -m31 somehow
> >> into the option list.
> >>
> >> With that patch the GCC driver checks the current personality setting in
> >> order to figure out at runtime what the default is supposed to be.
> >>
> >> Bootstrapped and regtested on s390x.
> >>
> >> I will commit the patch after waiting a few days for comments.
> > 
> > I don't like this, it is inconsistent with how it is handled on all other
> > targets and how it worked for years.  Having setarch magically change the
> > default is dangerous.
> 
> Wow, that was quick ;)
> 
> I didn't expect this to break things. Could you please elaborate where this 
> might cause trouble?

It is an unexpected major behavior change for environments that are this way
used for 1-2 decades.  When people want -m32 they just specify it, or if
they want a compiler that defaults to -m32 they configure it that way;
when gcc 7.x works one way and 8.x works differently, it will just mean
people will need to use -m32 or -m64 all the time, otherwise they won't be
sure what will happen.

Plus as I said, it is about consistency, why should s390x work in this
regard any differently in this regard from x86_64, powerpc64, sparc64,
mips64, which don't change the default even when setarch changes uname.

Jakub

Re: [patch][x86] Split-up march icelake on march=icelake-server and march=icelake-client

[Joseph Myers]

On Mon, 12 Mar 2018, Koval, Julia wrote:

> Hi,
> This patch introduces separate client and server arch options instead of 
> -march=icelake. Ok for trunk?

I don't see any invoke.texi updates here to document what these two 
options mean (including, presumably, different lists of features for 
them).

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

[PATCH] Fix match.pd ICEs on COMPLEX_CSTs (PR middle-end/84834)

[Jakub Jelinek]

Hi!

The following two match.pd spots assume that integer_pow2p will return
true only for INTEGER_CSTs (it uses wi::to_wide on it), but as the testcase
shows, that is not always the case, we can get there with COMPLEX_CSTs.

Fixed by requiring that it is both INTEGER_CST and integer_pow2p,
bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

I went through other spots where integer_pow2p is used in match.pd and think
all other spots should be safe, I don't think we e.g. allow BIT_AND_EXPR
with COMPLEX_CST operand etc.

2018-03-12  Jakub Jelinek  

PR middle-end/84834
* match.pd ((A & C) != 0 ? D : 0): Use INTEGER_CST@2 instead of
integer_pow2p@2 and test integer_pow2p in condition.
(A < 0 ? C : 0): Similarly for @1.

* gcc.dg/pr84834.c: New test.

--- gcc/match.pd.jj 2018-03-06 08:06:13.0 +0100
+++ gcc/match.pd2018-03-12 19:18:24.144577077 +0100
@@ -3566,16 +3566,18 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (simplify
  (cond
   (ne (bit_and @0 integer_pow2p@1) integer_zerop)
-  integer_pow2p@2 integer_zerop)
- (with {
-int shift = (wi::exact_log2 (wi::to_wide (@2))
-- wi::exact_log2 (wi::to_wide (@1)));
-  }
-  (if (shift > 0)
-   (bit_and
-(lshift (convert @0) { build_int_cst (integer_type_node, shift); }) @2)
-   (bit_and
-(convert (rshift @0 { build_int_cst (integer_type_node, -shift); })) @2
+  INTEGER_CST@2 integer_zerop)
+ (if (integer_pow2p (@2))
+  (with {
+ int shift = (wi::exact_log2 (wi::to_wide (@2))
+ - wi::exact_log2 (wi::to_wide (@1)));
+   }
+   (if (shift > 0)
+(bit_and
+ (lshift (convert @0) { build_int_cst (integer_type_node, shift); }) @2)
+(bit_and
+ (convert (rshift @0 { build_int_cst (integer_type_node, -shift); }))
+ @2)
 
 /* If we have (A & C) != 0 where C is the sign bit of A, convert
this into A < 0.  Similarly for (A & C) == 0 into A >= 0.  */
@@ -3595,8 +3597,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (simplify
  (cond
   (lt @0 integer_zerop)
-  integer_pow2p@1 integer_zerop)
- (if (!TYPE_UNSIGNED (TREE_TYPE (@0)))
+  INTEGER_CST@1 integer_zerop)
+ (if (integer_pow2p (@1)
+  && !TYPE_UNSIGNED (TREE_TYPE (@0)))
   (with {
 int shift = element_precision (@0) - wi::exact_log2 (wi::to_wide (@1)) - 1;
}
--- gcc/testsuite/gcc.dg/pr84834.c.jj   2018-03-12 19:21:15.677631881 +0100
+++ gcc/testsuite/gcc.dg/pr84834.c  2018-03-12 19:20:59.105626588 +0100
@@ -0,0 +1,15 @@
+/* PR middle-end/84834 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+_Complex int
+foo (int a)
+{
+  return a < 0;
+}
+
+_Complex int
+bar (int a)
+{
+  return (a & 8) ? (_Complex int) 16 : (_Complex int) 0;
+}

Jakub

[og7] Backport PR74048 and PR81352 nvptx fixes

[Cesar Philippidis]

I've applied this patch to openacc-gcc-7-branch which backports Tom's
nvptx bug fixes for PR74048 and PR81352. For some reason, I thought the
test case for pr84028 was triggering a new PTX JIT bug. But it turned
out to be failing because og7 is more verbose than trunk when it detects
unused parallelism (in this case, num_workers was being set but there
was no worker partitioned loop). That problem went away with an extra
dg-warning line.

Cesar
2018-03-12  Cesar Philippidis  

	Backport from trunk:
	2018-01-25  Tom de Vries  

	PR target/84028
	gcc/
	* config/nvptx/nvptx.c (nvptx_single): Add exit insn after noreturn call
	for neutered workers.
* testsuite/libgomp.oacc-fortran/pr84028.f90: New test.

	2018-01-24  Tom de Vries  

	PR target/81352
	gcc/
* config/nvptx/nvptx.c (nvptx_single): Add exit insn after noreturn call
	for neutered threads in warp.
	* config/nvptx/nvptx.md (define_insn "exit"): New insn.
	* testsuite/libgomp.oacc-fortran/pr81352.f90: New test.


diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index efc6161a6b0..070d236fa87 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -4128,7 +4128,12 @@ nvptx_single (unsigned mask, basic_block from, basic_block to)
 	if (tail_branch)
 	  before = emit_label_before (label, before);
 	else
-	  emit_label_after (label, tail);
+	  {
+	rtx_insn *label_insn = emit_label_after (label, tail);
+	if ((mode == GOMP_DIM_VECTOR || mode == GOMP_DIM_WORKER)
+		&& CALL_P (tail) && find_reg_note (tail, REG_NORETURN, NULL))
+	  emit_insn_after (gen_exit (), label_insn);
+	  }
   }
 
   /* Now deal with propagating the branch condition.  */
diff --git a/gcc/config/nvptx/nvptx.md b/gcc/config/nvptx/nvptx.md
index ac7b7cc8440..2b4bcb3a45b 100644
--- a/gcc/config/nvptx/nvptx.md
+++ b/gcc/config/nvptx/nvptx.md
@@ -972,6 +972,11 @@
   ""
   "")
 
+(define_insn "exit"
+  [(const_int 1)]
+  ""
+  "exit;")
+
 (define_insn "return"
   [(return)]
   ""
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/pr81352.f90 b/libgomp/testsuite/libgomp.oacc-fortran/pr81352.f90
new file mode 100644
index 000..f6969c8595d
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-fortran/pr81352.f90
@@ -0,0 +1,20 @@
+! { dg-do run }
+
+program foo
+  integer :: a(3,3), l, ll
+  a = 0
+
+  !$acc parallel num_gangs (1) num_workers(1)
+
+  do l=1,3
+ !$acc loop vector
+ do ll=1,3
+a(l,ll) = 2
+ enddo
+  enddo
+
+  if (any(a(1:3,1:3).ne.2)) call abort
+
+  !$acc end parallel
+
+end program foo
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/pr84028.f90 b/libgomp/testsuite/libgomp.oacc-fortran/pr84028.f90
new file mode 100644
index 000..693faa2214f
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-fortran/pr84028.f90
@@ -0,0 +1,25 @@
+! { dg-do run }
+
+program foo
+  integer :: a(3,3,3), ll, lll
+
+  a = 1
+
+  !$acc parallel num_gangs(1) num_workers(2) ! { dg-warning "region is worker partitioned" }
+
+  if (any(a(1:3,1:3,1:3).ne.1)) call abort
+
+  do ll=1,3
+
+ !$acc loop vector
+ do lll=1,3
+a(1,ll,lll) = 2
+ enddo
+
+  enddo
+
+  if (a(1,1,1).ne.2) call abort
+
+  !$acc end parallel
+
+end program foo

[PATCH] Fix another reg-stack recovery bug (PR target/84828)

[Jakub Jelinek]

Hi!

As Martin reported, the same testcase added recently ICEs differently
with different options on x86_64-linux, the problem is that we
sometimes emit insns before a CODE_LABEL of the next bb rather than after
the last insn in the previous bb, and expect we can just fix up BB_END
of the previous bb; fortunately that doesn't change BB_HEAD of the next
bb, but still we need to at least update INSN_BLOCK and make sure df knows
that too.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

The testcase still ICEs on i686-linux (preexisting bug, ICEs the same
without this patch or even before the previous patch), will handle that
tomorrow.

2018-03-12  Jakub Jelinek  

PR target/84828
* reg-stack.c (change_stack): Change update_end var from int to
rtx_insn *, if non-NULL don't update just BB_END (current_block), but
also call set_block_for_insn on the newly added insns and rescan.

* g++.dg/ext/pr84828.C: New test.

--- gcc/reg-stack.c.jj  2018-03-12 15:06:21.565800672 +0100
+++ gcc/reg-stack.c 2018-03-12 15:06:31.167802560 +0100
@@ -2489,7 +2489,7 @@ change_stack (rtx_insn *insn, stack_ptr
  enum emit_where where)
 {
   int reg;
-  int update_end = 0;
+  rtx_insn *update_end = NULL;
   int i;
 
   /* Stack adjustments for the first insn in a block update the
@@ -2511,7 +2511,7 @@ change_stack (rtx_insn *insn, stack_ptr
   if (where == EMIT_AFTER)
 {
   if (current_block && BB_END (current_block) == insn)
-   update_end = 1;
+   update_end = insn;
   insn = NEXT_INSN (insn);
 }
 
@@ -2686,7 +2686,16 @@ change_stack (rtx_insn *insn, stack_ptr
 }
 
   if (update_end)
-BB_END (current_block) = PREV_INSN (insn);
+{
+  for (update_end = NEXT_INSN (update_end); update_end != insn;
+  update_end = NEXT_INSN (update_end))
+   {
+ set_block_for_insn (update_end, current_block);
+ if (INSN_P (update_end))
+   df_insn_rescan (update_end);
+   }
+  BB_END (current_block) = PREV_INSN (insn);
+}
 }
 
 /* Print stack configuration.  */
--- gcc/testsuite/g++.dg/ext/pr84828.C.jj   2018-03-12 15:13:50.589882983 
+0100
+++ gcc/testsuite/g++.dg/ext/pr84828.C  2018-03-12 15:14:06.670885916 +0100
@@ -0,0 +1,13 @@
+// PR target/84828
+// { dg-do compile { target i?86-*-* x86_64-*-* } }
+// { dg-options "-Og -mno-sse2" }
+
+void
+foo (float b, double c)
+{
+  for (int e = 0; e < 2; e++)
+{
+  asm volatile ("" : "+f" (c));// { dg-error "must specify a single 
register" }
+  asm ("" : "+rm" (c = b));
+}
+}

Jakub

[patch][x86] Split-up march icelake on march=icelake-server and march=icelake-client

[Koval, Julia]

Hi,
This patch introduces separate client and server arch options instead of 
-march=icelake. Ok for trunk?

Thanks,
Julia


gcc/
* config.gcc (icelake-client, icelake-server): New.
(icelake): Remove.
* config/i386/i386.c (initial_ix86_tune_features): Extend to 64 bit.
(initial_ix86_arch_features): Ditto.
(ix86_option_override_internal): Split up icelake on icelake client and
icelake server.
(get_builtin_code_for_version): Ditto.
(fold_builtin_cpu): Ditto.
* config/i386/driver-i386.c (config/i386/driver-i386.c): Ditto.
* config/i386/i386-c.c (ix86_target_macros_internal): Ditto
* config/i386/i386.h (processor_type) Ditto.

gcc/testsuite/
* g++.dg/ext/mv16.C: Split up icelake on icelake client and
icelake-server.
* gcc.target/i386/funcspec-56.inc: Ditto.

libgcc/
* config/i386/cpuinfo.h (processor_subtypes): Split up icelake on 
icelake 
client and icelake-server.


0001-icelake-client.patch
Description: 0001-icelake-client.patch

Re: [PATCH] Fortran -- clean up KILL

[Janne Blomqvist]

On Mon, Mar 12, 2018 at 7:37 PM, Steve Kargl
 wrote:
> On Mon, Mar 12, 2018 at 06:56:24PM +0200, Janne Blomqvist wrote:
>> On Sun, Mar 11, 2018 at 10:42 PM, Steve Kargl
>> > I suppose we could remove the restriction to INTEGER(4) and
>> > INTEGER(8), but I don't see any reason to do so.  INTEGER(1)
>> > is too limited given that at least on FreeBSD the lower pid's
>> > correspond to system processes.  Using 'ps ax' suggests that
>> > the first 1000 or so processes are from system start up.
>> > INTEGER(16) (if supported) seems to be overkill in that I
>> > doubt any OS uses a 64-bit pid_t.
>>
>> I'm not sure there's any particular reason for the kind=4,8
>> restriction except that "it's the same restriction g77 had". And AFAIK
>> there are no systems with a 64-bit pid_t, so a plain int should be
>> enough. So it should suffice to have a single libgfortran function,
>> say with the prototype
>>
>> int _gfortran_kill (int pid, int sig);
>>
>> and the frontend would take care of whatever massaging to handle
>> whether it's called as a function or subroutine, and whatever
>> typecasting is necessary. Whether we want to limit it to kind=4,8 or
>> allow arbitrary kinds I don't have any particularly strong opinion on.
>>
>
> Keeping kind=4,8 simply makes life easier for people who
> use -fdefault-integer-8.

Yes, I understand that -fdefault-integer-8 (or whatever the equivalent
option was called on g77) is the original motivation. Like I said, I
don't have any particular opinion on whether we should keep that
restriction or not. On one hand, more recent versions of the standard
has lifted restrictions that integer intrinsic arguments have to be of
default kind in many cases, OTOH KILL is not a standard intrinsic but
something inherited from g77. So, meh.

> BTW, I'm not too familiar with all the nuances of symbol
> versioning, but I thought we needed to drag the 6 exported
> library symbols along forever.

No, when we bump the major .so version number, as we have already done
for GCC 8, the clock resets and we can remove unnecessary stuff. The
symbol versioning stuff is only useful as long as we keep the same
major .so version number.


-- 
Janne Blomqvist

[PATCHv2] PR libstdc++/84654 Do not use __float128 if it is disabled by the compiler

[Tulio Magno Quites Machado Filho]

Changes since v1:
 - Completely rewrite of the patch to set ENABLE_FLOAT128 at libstdc++
   build time and undef _GLIBCXX_USE_FLOAT128 when building user code.

--- 8< ---

In order to use __float128 in C++ it's necessary to check if the
compiler enabled its support too when building user code.
This patch changes the behavior at libstdc++ build by setting
ENABLE_FLOAT128, which is used to set the value of the exported macro
_GLIBCXX_USE_FLOAT128.

2018-03-12  Tulio Magno Quites Machado Filho  

PR libstdc++/84654
* acinclude.m4: Set ENABLE_FLOAT128 instead of _GLIBCXX_USE_FLOAT128.
* config.h.in: Remove references to _GLIBCXX_USE_FLOAT128.
* configure: Regenerate.
* include/Makefile.am: Replace the value of _GLIBCXX_USE_FLOAT128
based on ENABLE_FLOAT128.
* include/Makefile.in: Regenerate.
* include/bits/c++config: Define _GLIBCXX_USE_FLOAT128.
[!defined(__FLOAT128__) && !defined(__SIZEOF_FLOAT128__)]: Undefine
_GLIBCXX_USE_FLOAT128.
---
 libstdc++-v3/acinclude.m4   |  5 ++---
 libstdc++-v3/config.h.in|  3 ---
 libstdc++-v3/include/Makefile.am| 13 -
 libstdc++-v3/include/bits/c++config |  6 ++
 4 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 3bd669a..4f37b6a 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -3062,7 +3062,7 @@ dnl Note: also checks that the types aren't standard 
types.
 dnl
 dnl Defines:
 dnl  _GLIBCXX_USE_INT128
-dnl  _GLIBCXX_USE_FLOAT128
+dnl  ENABLE_FLOAT128
 dnl
 AC_DEFUN([GLIBCXX_ENABLE_INT128_FLOAT128], [
 
@@ -3117,13 +3117,12 @@ EOF
 
 AC_MSG_CHECKING([for __float128])
 if AC_TRY_EVAL(ac_compile); then
-  AC_DEFINE(_GLIBCXX_USE_FLOAT128, 1,
-  [Define if __float128 is supported on this host.])
   enable_float128=yes
 else
   enable_float128=no
 fi
 AC_MSG_RESULT($enable_float128)
+GLIBCXX_CONDITIONAL(ENABLE_FLOAT128, test $enable_float128 = yes)
 rm -f conftest*
 
   AC_LANG_RESTORE
diff --git a/libstdc++-v3/config.h.in b/libstdc++-v3/config.h.in
index 5a0f067..765cedc 100644
--- a/libstdc++-v3/config.h.in
+++ b/libstdc++-v3/config.h.in
@@ -918,9 +918,6 @@
 /* Define if fchmodat is available in . */
 #undef _GLIBCXX_USE_FCHMODAT
 
-/* Define if __float128 is supported on this host. */
-#undef _GLIBCXX_USE_FLOAT128
-
 /* Defined if gettimeofday is available. */
 #undef _GLIBCXX_USE_GETTIMEOFDAY
 
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 70a662f..ba5adda 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -1230,6 +1230,14 @@ stamp-allocator-new:
echo 0 > stamp-allocator-new
 endif
 
+if ENABLE_FLOAT128
+stamp-float128:
+   echo 1 > stamp-float128
+else
+stamp-float128:
+   echo 0 > stamp-float128
+endif
+
 # NB: The non-empty default ldbl_compat works around an AIX sed
 # oddity, see libstdc++/31957 for details.
 ${host_builddir}/c++config.h: ${CONFIG_HEADER} \
@@ -1241,7 +1249,8 @@ ${host_builddir}/c++config.h: ${CONFIG_HEADER} \
  stamp-extern-template \
  stamp-dual-abi \
  stamp-cxx11-abi \
- stamp-allocator-new
+ stamp-allocator-new \
+ stamp-float128
@date=`cat ${toplevel_srcdir}/gcc/DATESTAMP` ;\
release=`sed 's/^\([0-9]*\).*$$/\1/' ${toplevel_srcdir}/gcc/BASE-VER` ;\
ns_version=`cat stamp-namespace-version` ;\
@@ -1250,6 +1259,7 @@ ${host_builddir}/c++config.h: ${CONFIG_HEADER} \
dualabi=`cat stamp-dual-abi` ;\
cxx11abi=`cat stamp-cxx11-abi` ;\
allocatornew=`cat stamp-allocator-new` ;\
+   float128=`cat stamp-float128` ;\
ldbl_compat='s,g,g,' ;\
grep "^[ ]*#[]*define[   ][  
]*_GLIBCXX_LONG_DOUBLE_COMPAT[  ][  ]*1[]*$$" \
${CONFIG_HEADER} > /dev/null 2>&1 \
@@ -1262,6 +1272,7 @@ ${host_builddir}/c++config.h: ${CONFIG_HEADER} \
-e "s,define _GLIBCXX_USE_DUAL_ABI, define _GLIBCXX_USE_DUAL_ABI 
$$dualabi," \
-e "s,define _GLIBCXX_USE_CXX11_ABI, define _GLIBCXX_USE_CXX11_ABI 
$$cxx11abi," \
-e "s,define _GLIBCXX_USE_ALLOCATOR_NEW, define 
_GLIBCXX_USE_ALLOCATOR_NEW $$allocatornew," \
+   -e "s,define _GLIBCXX_USE_FLOAT128, define _GLIBCXX_USE_FLOAT128 
$$float128," \
-e "$$ldbl_compat" \
< ${glibcxx_srcdir}/include/bits/c++config > $@ ;\
sed -e 's/HAVE_/_GLIBCXX_HAVE_/g' \
diff --git a/libstdc++-v3/include/bits/c++config 
b/libstdc++-v3/include/bits/c++config
index 1eb4679..e345241 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -609,4 +609,10 @@ namespace std
 # endif
 #endif
 
+/* Define if __float128 is supported on this host. 

Re: [PATCH, rs6000] Fix PR83789: __builtin_altivec_lvx fails for powerpc for altivec-4.c

[Segher Boessenkool]

Hi!

On Sun, Mar 11, 2018 at 10:23:02AM -0500, Peter Bergner wrote:
> PR83789 shows a problem in the builtin expansion code not calling the correct
> define_insn, given the correct mode (32-bit versus 64-bit).  One could add
> tests in this code to call the correct pattern, but it's easier to create
> a common define_expand which everyone can call that does the right thing.
> This allows us to clean up all the callers, making for much simpler code.
> This also fixes the issue that Segher mentioned that this needs fixing for
> multiple other vector modes and not just the one mentioned in the bugzilla.

> P.S.  I will be away on vacation for the neek week, so if this is ok, I won't
>   be able to commit the patch until I return.  Unless you want to commit
>   it Segher and watch for fallout.  It's up to you.

There is no hurry I think?  And some changes are needed, so I'll leave
it to you.

> +; The following patterns embody what lvx should usually look like.
> +(define_expand "altivec_lvx_"
> +  [(set (match_operand:VM2 0 "register_operand" "")
> + (match_operand:VM2 1 "altivec_indexed_or_indirect_operand" ""))]

No "" please.  Expanders do not have constraints.

>  #ifdef HAVE_V8HFmode
> -  else if (mode == V8HFmode)
> - stvx = TARGET_64BIT
> -   ? gen_altivec_stvx_v8hf_1op (src_exp, memory_address)
> -   : gen_altivec_stvx_v8hf_1op_si (src_exp, memory_address);
> +  else if (mode == V8HFmode)
> +stvx = gen_altivec_stvx_v8hf (src_exp, dest_exp);
>  #endif

Btw, don't we always have V8HFmode these days?

The patch is fine with those trivialities fixed.  Okay for trunk.  Thanks!

Enjoy your vacation!


Segher

Re: [PATCH,rs6000] Add vec_permxor support.

[Segher Boessenkool]

Hi Carl,

On Mon, Mar 12, 2018 at 08:21:08AM -0700, Carl Love wrote:
> The following patch add support for the vec_permxor builtins.  
> 
> Note the change in file rs6000-p8swap.c is actually a fix for the
> existing define_insn "crypto_vpermxor in crypto.md.  The fix disables
> swap optimization for the vpermxor instruction.  Without this fix
> optimization with -O1 and above results in the upper and lower 64-bits
> of the three operands are swapped messing up the indexing specified by
> the third operand.  This change will need to be back ported to GCC 6
> and 7. 


> 2018-03-12  Carl Love  
> 
>   * config/rs6000/rs6000-c.c: Add macro definitions for
>   ALTIVEC_BUILTIN_VEC_PERM.

ALTIVEC_BUILTIN_VEC_PERMXOR.

>   * config/rs6000/rs6000.h: Add #define for vec_permxor builtin.
>   * config/rs6000/rs6000-builtin.def: Add macro expansions for VPERMXOR.
>   * config/rs6000/altivec.md: Add define_insn for altivec-vpermxor.

altivec_vpermxor.

Please write this like:
(altivec_vpermxor): New define_expand.

>   Add UNSPEC_VNOR, define_insn altivec_vnor_v16qi3.

There already is nor3 for BOOL_128 (so norv16qi3 for this).

But you probably want to use one_cmpl2 instead (which ends up as
*one_cmpl3_internal for BOOL_128, *one_cmplv16qi3_internal here
(the "3" is a misnomer), the expander is one_cmplv16qi2).

> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/builtins-7-runnable.c
> @@ -0,0 +1,112 @@
> +/* { dg-do run { target { powerpc*-*-* && { lp64 && p8vector_hw } } } } */
> +/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
> "-mcpu=power8" } } */
> +/* { dg-options "-mcpu=power8 -O2" } */

Does this need lp64?

Rest looks good.


Segher

Re: [PATCH] S/390: Set ABI default based on uname

[Andreas Krebbel]

On 03/12/2018 06:31 PM, Jakub Jelinek wrote:
> On Mon, Mar 12, 2018 at 06:28:09PM +0100, Andreas Krebbel wrote:
>> Currently the default ABI option for a GCC built on a 64 bit system is
>> always -m64.  This is inconvenient when e.g. building 32 bit libraries
>> on a 64 bit system.  The usual way to do this is to set the personality
>> to s390 (32 bit) and let the configure script do the right thing.
>> Having a GCC which defaults to -m64 also requires to get a -m31 somehow
>> into the option list.
>>
>> With that patch the GCC driver checks the current personality setting in
>> order to figure out at runtime what the default is supposed to be.
>>
>> Bootstrapped and regtested on s390x.
>>
>> I will commit the patch after waiting a few days for comments.
> 
> I don't like this, it is inconsistent with how it is handled on all other
> targets and how it worked for years.  Having setarch magically change the
> default is dangerous.

Wow, that was quick ;)

I didn't expect this to break things. Could you please elaborate where this 
might cause trouble?

-Andreas-


> 
>> 2018-03-12  Andreas Krebbel  
>>
>>  * config/s390/driver-native.c (s390_host_detect_target_bits): New
>>  function.
>>  * config/s390/s390.h: Invoke s390_host_detect_target_bits if
>>  neither -m31 nor -m64 has been specified.
> 
>   Jakub
> 

Re: [PATCH] Fortran -- clean up KILL

[Steve Kargl]

On Mon, Mar 12, 2018 at 06:56:24PM +0200, Janne Blomqvist wrote:
> On Sun, Mar 11, 2018 at 10:42 PM, Steve Kargl
> > I suppose we could remove the restriction to INTEGER(4) and
> > INTEGER(8), but I don't see any reason to do so.  INTEGER(1)
> > is too limited given that at least on FreeBSD the lower pid's
> > correspond to system processes.  Using 'ps ax' suggests that
> > the first 1000 or so processes are from system start up.
> > INTEGER(16) (if supported) seems to be overkill in that I
> > doubt any OS uses a 64-bit pid_t.
> 
> I'm not sure there's any particular reason for the kind=4,8
> restriction except that "it's the same restriction g77 had". And AFAIK
> there are no systems with a 64-bit pid_t, so a plain int should be
> enough. So it should suffice to have a single libgfortran function,
> say with the prototype
> 
> int _gfortran_kill (int pid, int sig);
> 
> and the frontend would take care of whatever massaging to handle
> whether it's called as a function or subroutine, and whatever
> typecasting is necessary. Whether we want to limit it to kind=4,8 or
> allow arbitrary kinds I don't have any particularly strong opinion on.
> 

Keeping kind=4,8 simply makes life easier for people who
use -fdefault-integer-8.  It also makes our life's easier.
Where do you want the conversion to occur?  We don't have
a conv_intrinsic_kill in trans-intrinsic.c.  The return type
is documented to be that of pid, so we need to convert pid
and sig to int and then convert the presumably returned int
to type of pid. 

BTW, I'm not too familiar with all the nuances of symbol
versioning, but I thought we needed to drag the 6 exported
library symbols along forever.

-- 
Steve

Re: [PATCH] S/390: Set ABI default based on uname

[Jakub Jelinek]

On Mon, Mar 12, 2018 at 06:28:09PM +0100, Andreas Krebbel wrote:
> Currently the default ABI option for a GCC built on a 64 bit system is
> always -m64.  This is inconvenient when e.g. building 32 bit libraries
> on a 64 bit system.  The usual way to do this is to set the personality
> to s390 (32 bit) and let the configure script do the right thing.
> Having a GCC which defaults to -m64 also requires to get a -m31 somehow
> into the option list.
> 
> With that patch the GCC driver checks the current personality setting in
> order to figure out at runtime what the default is supposed to be.
> 
> Bootstrapped and regtested on s390x.
> 
> I will commit the patch after waiting a few days for comments.

I don't like this, it is inconsistent with how it is handled on all other
targets and how it worked for years.  Having setarch magically change the
default is dangerous.

> 2018-03-12  Andreas Krebbel  
> 
>   * config/s390/driver-native.c (s390_host_detect_target_bits): New
>   function.
>   * config/s390/s390.h: Invoke s390_host_detect_target_bits if
>   neither -m31 nor -m64 has been specified.

Jakub

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping the

http://gcc.gnu.org/ml/gcc-patches/2018-03/msg00238.html
  - PR84704 - ICE on a[({ 0; })] op= something with -g

patch.  Thanks.

Jakub

[PATCH] S/390: Set ABI default based on uname

[Andreas Krebbel]

Currently the default ABI option for a GCC built on a 64 bit system is
always -m64.  This is inconvenient when e.g. building 32 bit libraries
on a 64 bit system.  The usual way to do this is to set the personality
to s390 (32 bit) and let the configure script do the right thing.
Having a GCC which defaults to -m64 also requires to get a -m31 somehow
into the option list.

With that patch the GCC driver checks the current personality setting in
order to figure out at runtime what the default is supposed to be.

Bootstrapped and regtested on s390x.

I will commit the patch after waiting a few days for comments.

gcc/ChangeLog:

2018-03-12  Andreas Krebbel  

* config/s390/driver-native.c (s390_host_detect_target_bits): New
function.
* config/s390/s390.h: Invoke s390_host_detect_target_bits if
neither -m31 nor -m64 has been specified.
---
 gcc/config/s390/driver-native.c | 26 ++
 gcc/config/s390/s390.h  | 14 +-
 2 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/gcc/config/s390/driver-native.c b/gcc/config/s390/driver-native.c
index 3793f8a..666ae48 100644
--- a/gcc/config/s390/driver-native.c
+++ b/gcc/config/s390/driver-native.c
@@ -19,6 +19,8 @@ along with GCC; see the file COPYING3.  If not see
 
 #define IN_TARGET_CODE 1
 
+#include 
+
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
@@ -184,3 +186,27 @@ s390_host_detect_local_cpu (int argc, const char **argv)
 
   return concat ("-m", argv[0], "=", cpu, options, NULL);
 }
+
+/* This function is invoked by the gcc spec parser via
+   target_bits_detect.  It returns either "64" or "31" depending on
+   the personality currently being used.  */
+
+const char *
+s390_host_detect_target_bits (int argc ATTRIBUTE_UNUSED,
+ const char **argv ATTRIBUTE_UNUSED)
+{
+  struct utsname uname_struct;
+
+  if (uname (_struct) == 0)
+{
+  if (strcmp (uname_struct.machine, "s390x") == 0)
+   return "64";
+  else if (strcmp (uname_struct.machine, "s390") == 0)
+   return "31";
+}
+#ifdef DEFAULT_TARGET_64BIT
+  return "64";
+#else
+  return "31";
+#endif
+}
diff --git a/gcc/config/s390/s390.h b/gcc/config/s390/s390.h
index de71fd9..eee6158 100644
--- a/gcc/config/s390/s390.h
+++ b/gcc/config/s390/s390.h
@@ -209,8 +209,10 @@ enum processor_flags
 
 #ifdef __s390__
 extern const char *s390_host_detect_local_cpu (int argc, const char **argv);
-# define EXTRA_SPEC_FUNCTIONS \
-  { "local_cpu_detect", s390_host_detect_local_cpu },
+extern const char *s390_host_detect_target_bits (int argc, const char **argv);
+# define EXTRA_SPEC_FUNCTIONS  \
+  { "local_cpu_detect", s390_host_detect_local_cpu },  \
+  { "target_bits_detect", s390_host_detect_target_bits },
 
 #define MARCH_MTUNE_NATIVE_SPECS   \
   

[PATCH] rs6000: sysv: Don't pass SFmode in varargs in FPRs

[Segher Boessenkool]

This makes the float32-basic.c testcase work on sysv (32-bit Linux).

"float" is promoted to "double" for varargs.  The ABI also only defines
the use of double precision in varargs.  But _Float32 is not promoted.
Since there is no way of passing single-precision float in FPRs we
should pass SFmode in GPRs (or memory) instead.  This is similar to
the 64-bit ABI.

Tested on powerpc64-linux {-m64,-m32}.  Committing to trunk.


Segher


2018-03-12  Segher Boessenkool  

* config/rs6000/rs6000.c (abi_v4_pass_in_fpr): Add bool "named"
parameter.  Use it for SFmode.
(rs6000_function_arg_advance_1): Adjust.
(rs6000_function_arg): Adjust.
(rs6000_gimplify_va_arg): Pass false for that new parameter.

---
 gcc/config/rs6000/rs6000.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 8c06651..5230997 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -11192,11 +11192,13 @@ is_complex_IBM_long_double (machine_mode mode)
registers.  */
 
 static bool
-abi_v4_pass_in_fpr (machine_mode mode)
+abi_v4_pass_in_fpr (machine_mode mode, bool named)
 {
   if (!TARGET_HARD_FLOAT)
 return false;
-  if (mode == SFmode || mode == DFmode)
+  if (mode == DFmode)
+return true;
+  if (mode == SFmode && named)
 return true;
   /* ABI_V4 passes complex IBM long double in 8 gprs.
  Stupid, but we can't change the ABI now.  */
@@ -11663,7 +11665,7 @@ rs6000_function_arg_advance_1 (CUMULATIVE_ARGS *cum, 
machine_mode mode,
 }
   else if (DEFAULT_ABI == ABI_V4)
 {
-  if (abi_v4_pass_in_fpr (mode))
+  if (abi_v4_pass_in_fpr (mode, named))
{
  /* _Decimal128 must use an even/odd register pair.  This assumes
 that the register number is odd when fregno is odd.  */
@@ -12215,7 +12217,7 @@ rs6000_function_arg (cumulative_args_t cum_v, 
machine_mode mode,
 
   else if (abi == ABI_V4)
 {
-  if (abi_v4_pass_in_fpr (mode))
+  if (abi_v4_pass_in_fpr (mode, named))
{
  /* _Decimal128 must use an even/odd register pair.  This assumes
 that the register number is odd when fregno is odd.  */
@@ -13136,7 +13138,7 @@ rs6000_gimplify_va_arg (tree valist, tree type, 
gimple_seq *pre_p,
   align = 1;
 
   machine_mode mode = TYPE_MODE (type);
-  if (abi_v4_pass_in_fpr (mode))
+  if (abi_v4_pass_in_fpr (mode, false))
 {
   /* FP args go in FP registers, if present.  */
   reg = fpr;
-- 
1.8.3.1

Re: [PATCH] Fortran -- clean up KILL

[Janne Blomqvist]

On Sun, Mar 11, 2018 at 10:42 PM, Steve Kargl
 wrote:
> On Sun, Mar 11, 2018 at 10:16:01PM +0200, Janne Blomqvist wrote:
>> On Sun, Mar 11, 2018 at 6:52 PM, Steve Kargl
>>  wrote:
>> > The attach patch cleans up KILL to match its
>> > documentation.  In doing so, I have changed
>> > the argument keywords to consistently use
>> > pid and sig.  If no one objects, I intend to
>> > commit this tomorrow.
>> >
>> > 2018-03-11  Steven G. Kargl  
>> >
>> > * check.c (gfc_check_kill):  Check pid and sig are scalar.
>> > (gfc_check_kill_sub): Restrict kind to 4 and 8.
>> > * intrinsic.c (add_function): Sort keyword list.  Add pid and sig
>> > keywords for KILL.  Remove redundant *back="back" in favor of the
>> > original *bck="back".
>> > (add_subroutines): Sort keyword list.  Add pid and sig keywords
>> > for KILL.
>> > * intrinsic.texi: Fix documentation to consistently use pid and 
>> > sig.
>> > * iresolve.c (gfc_resolve_kill): Kind can only be 4 or 8.  Choose 
>> > the
>> > correct function.
>> > (gfc_resolve_rename_sub): Add comment.
>>
>> The patch per se looks fine, but while you're at it, it would be nice
>> to get rid of all but one of the libgfortran entry points and do the
>> typecasting etc. in the frontend instead..
>>
>
> Thanks.  Note, the documentation specifically states that
> only INTEGER(4) and INTEGER(8) are supported, so there is
> only 2 entry points for the function and 4(?) for the
> subroutine version.  nm shows
>
>  T _gfortran_kill_i4
>  T _gfortran_kill_i4_sub
>  T _gfortran_kill_i8
>  T _gfortran_kill_i8_sub
>  T _gfortrani_kill_i4_sub
>  T _gfortrani_kill_i8_sub
>
> I don't recall what the difference is between _gfortran_
> and _gfortrani_.

IIRC, the "i" stands for internal, it's symbols called internally in
gfortran and are not externally visible in the .so (though you can
still see them in the .a). So we have 4 external symbols that are part
of the libgfortran API.

> I suppose we could remove the restriction to INTEGER(4) and
> INTEGER(8), but I don't see any reason to do so.  INTEGER(1)
> is too limited given that at least on FreeBSD the lower pid's
> correspond to system processes.  Using 'ps ax' suggests that
> the first 1000 or so processes are from system start up.
> INTEGER(16) (if supported) seems to be overkill in that I
> doubt any OS uses a 64-bit pid_t.

I'm not sure there's any particular reason for the kind=4,8
restriction except that "it's the same restriction g77 had". And AFAIK
there are no systems with a 64-bit pid_t, so a plain int should be
enough. So it should suffice to have a single libgfortran function,
say with the prototype

int _gfortran_kill (int pid, int sig);

and the frontend would take care of whatever massaging to handle
whether it's called as a function or subroutine, and whatever
typecasting is necessary. Whether we want to limit it to kind=4,8 or
allow arbitrary kinds I don't have any particularly strong opinion on.



-- 
Janne Blomqvist

[PATCH] combine: Fix PR84780 (more LOG_LINKS trouble)

[Segher Boessenkool]

There still are situations where we have stale LOG_LINKS.  This causes
combine to try two-insn combinations I2->I3 where the register set by
I2 is used before I3 as well.  Not good.

This patch fixes it by checking for this situation in can_combine_p
(similar to what we already do for three and four insn combinations).

Longer term we should make sure stale LOG_LINKS are removed (or moved),
or ideally we should use DF instead of LOG_LINKS.

I tested the patch on 31 architectures, no degradations seen.  Zdenek
tested it on the original testcase (thanks!)

Committing to trunk.


Segher


2018-03-12  Segher Boessenkool  

PR rtl-optimization/84169
PR rtl-optimization/84780
* combine.c (can_combine_p): Check for a 2-insn combination whether
the destination register is used between the two insns, too.

---
 gcc/combine.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/combine.c b/gcc/combine.c
index c9105ed..06a9ddd 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -1990,6 +1990,7 @@ can_combine_p (rtx_insn *insn, rtx_insn *i3, rtx_insn 
*pred ATTRIBUTE_UNUSED,
   && (reg_used_between_p (dest, succ2, i3)
   || reg_used_between_p (dest, succ, succ2)))
  || (!succ2 && succ && reg_used_between_p (dest, succ, i3))
+ || (!succ2 && !succ && reg_used_between_p (dest, insn, i3))
  || (succ
  /* SUCC and SUCC2 can be split halves from a PARALLEL; in
 that case SUCC is not in the insn stream, so use SUCC2
-- 
1.8.3.1

[PATCH,rs6000] Add vec_permxor support.

[Carl Love]

GCC maintainers:

The following patch add support for the vec_permxor builtins.  

Note the change in file rs6000-p8swap.c is actually a fix for the
existing define_insn "crypto_vpermxor in crypto.md.  The fix disables
swap optimization for the vpermxor instruction.  Without this fix
optimization with -O1 and above results in the upper and lower 64-bits
of the three operands are swapped messing up the indexing specified by
the third operand.  This change will need to be back ported to GCC 6
and 7. 

  powerpc64-unknown-linux-gnu (Power 8 BE)
  powerpc64le-unknown-linux-gnu (Power 8 LE)
  powerpc64le-unknown-linux-gnu (Power 9 LE)

with no regressions.

Let me know if the patch looks OK or not. Thanks.

   Carl Love

--

gcc/ChangeLog:

2018-03-12  Carl Love  

* config/rs6000/rs6000-c.c: Add macro definitions for
ALTIVEC_BUILTIN_VEC_PERM.
* config/rs6000/rs6000.h: Add #define for vec_permxor builtin.
* config/rs6000/rs6000-builtin.def: Add macro expansions for VPERMXOR.
* config/rs6000/altivec.md: Add define_insn for altivec-vpermxor.
Add UNSPEC_VNOR, define_insn altivec_vnor_v16qi3.
* config/rs6000/rs6000-p8swap.c (rtx_is_swappable_p): Add case
UNSPEC_VPERMXOR.
* config/doc/extend.texi: Add prototypes for vec_permxor.

gcc/testsuite/ChangeLog:

2018-03-12  Carl Love  
* gcc.target/powerpc/builtins-7-runnable.c: Add tests for vec_permxor.
---
 gcc/config/rs6000/altivec.h|   1 +
 gcc/config/rs6000/altivec.md   |  33 ++
 gcc/config/rs6000/rs6000-builtin.def   |   3 +
 gcc/config/rs6000/rs6000-c.c   |  10 ++
 gcc/config/rs6000/rs6000-p8swap.c  |   1 +
 gcc/doc/extend.texi|   6 ++
 .../gcc.target/powerpc/builtins-7-runnable.c   | 112 +
 7 files changed, 166 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/builtins-7-runnable.c

diff --git a/gcc/config/rs6000/altivec.h b/gcc/config/rs6000/altivec.h
index 1e495e6..5a34162 100644
--- a/gcc/config/rs6000/altivec.h
+++ b/gcc/config/rs6000/altivec.h
@@ -76,6 +76,7 @@
 #define vec_vor vec_or
 #define vec_vpkpx vec_packpx
 #define vec_vperm vec_perm
+#define vec_permxor __builtin_vec_vpermxor
 #define vec_vrefp vec_re
 #define vec_vrfin vec_round
 #define vec_vrsqrtefp vec_rsqrte
diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 2759f2d..7770743 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -44,6 +44,7 @@
UNSPEC_VMULOSH
UNSPEC_VMULOUW
UNSPEC_VMULOSW
+   UNSPEC_VNOR
UNSPEC_VPKPX
UNSPEC_VPACK_SIGN_SIGN_SAT
UNSPEC_VPACK_SIGN_UNS_SAT
@@ -3827,6 +3828,38 @@
   DONE;
 })
 
+(define_insn "altivec_vnor_v16qi3"
+  [(set (match_operand:V16QI 0 "register_operand" "=v")
+   (unspec:V16QI [(match_operand:V16QI 1 "register_operand" "v")
+ (match_operand:V16QI 2 "register_operand" "v")]
+UNSPEC_VNOR))]
+  ""
+  "vnor %0,%1,%2"
+  [(set_attr "type" "vecsimple")])
+
+(define_expand "altivec_vpermxor"
+  [(use (match_operand:V16QI 0 "register_operand"))
+   (use (match_operand:V16QI 1 "register_operand"))
+   (use (match_operand:V16QI 2 "register_operand"))
+   (use (match_operand:V16QI 3 "register_operand"))]
+  "TARGET_P8_VECTOR"
+{
+  if (!BYTES_BIG_ENDIAN)
+{
+  /* vpermxor indexes the bytes using Big Endian numbering.  If LE,
+change indexing in operand[3] to BE index.  */
+  rtx be_index = gen_reg_rtx (V16QImode);
+
+  emit_insn (gen_altivec_vnor_v16qi3 (be_index, operands[3], operands[3]));
+  emit_insn (gen_crypto_vpermxor_v16qi (operands[0], operands[1],
+   operands[2], be_index));
+}
+  else
+emit_insn (gen_crypto_vpermxor_v16qi (operands[0], operands[1],
+ operands[2], operands[3]));
+  DONE;
+})
+
 (define_expand "altivec_negv4sf2"
   [(use (match_operand:V4SF 0 "register_operand"))
(use (match_operand:V4SF 1 "register_operand"))]
diff --git a/gcc/config/rs6000/rs6000-builtin.def 
b/gcc/config/rs6000/rs6000-builtin.def
index f9548a0..25d45a9 100644
--- a/gcc/config/rs6000/rs6000-builtin.def
+++ b/gcc/config/rs6000/rs6000-builtin.def
@@ -2008,6 +2008,8 @@ BU_P8V_AV_P (VCMPEQUD_P,  "vcmpequd_p",   CONST,  
vector_eq_v2di_p)
 BU_P8V_AV_P (VCMPGTSD_P,   "vcmpgtsd_p",   CONST,  vector_gt_v2di_p)
 BU_P8V_AV_P (VCMPGTUD_P,   "vcmpgtud_p",   CONST,  vector_gtu_v2di_p)
 
+BU_P8V_AV_3 (VPERMXOR, "vpermxor", CONST,  altivec_vpermxor)
+
 /* ISA 2.05 overloaded 2 argument functions.  */
 BU_P6_OVERLOAD_2 (CMPB, "cmpb")
 
@@ -2069,6 +2071,7 @@ BU_P8V_OVERLOAD_3 (VADDECUQ,  "vaddecuq")
 BU_P8V_OVERLOAD_3 (VADDEUQM,   "vaddeuqm")
 BU_P8V_OVERLOAD_3 (VSUBECUQ,   "vsubecuq")

Re: [PATCH] replace ICE with error for failed template deduction (PR 84355)

[Jason Merrill]

On Mon, Mar 5, 2018 at 7:05 PM, Martin Sebor  wrote:
> On 02/23/2018 07:32 PM, Jason Merrill wrote:
>> On Sun, Feb 18, 2018 at 11:39 PM, Jason Merrill  wrote:
>>> On Fri, Feb 16, 2018 at 4:33 PM, Martin Sebor  wrote:
 On 02/16/2018 07:04 AM, Jason Merrill wrote:
>
> On Thu, Feb 15, 2018 at 6:36 PM, Martin Sebor  wrote:
>>
>>
>> A failed template deduction in template member of a template
>> triggers an ICE with -std=c++17 due to what seems like
>> a missing handling of invalid input.  Replacing
>> the gcc_unreachable() call that causes the ICE with a return
>> statement indicating the deduction failure eliminates the ICE
>> and restores sane diagnostics.
>
>
>
> Hmm, we really shouldn't have gotten there; that assert is checking
> that when we see a TEMPLATE_*_PARM node in the template signature, it
> corresponds to one of the actual parms of the template.  Sounds like
> something is going wrong in build_deduction_guide.



 Are you suggesting that build_deduction_guide should fail somehow
 (it's not expected to fail right now) or that the guide it creates
 is wrong?
>>>
>>>
>>> The latter.  Maybe we're handling T wrong somehow?  We shouldn't be
>>> trying to deduce it.  In fact, we probably shouldn't be trying to
>>> deduce arguments for 'b' until we instantiate A.
>>
>>
>> Looks like the problem is that when we substitute into the
>> TEMPLATE_TYPE_PARM representing 'B' in the function, we don't touch
>> CLASS_PLACEHOLDER_TEMPLATE:
>>
>> else if (tree pl = CLASS_PLACEHOLDER_TEMPLATE (t))
>>   {
>> if (DECL_TEMPLATE_TEMPLATE_PARM_P (pl))
>>   pl = tsubst (pl, args, complain, in_decl);
>> CLASS_PLACEHOLDER_TEMPLATE (r) = pl;
>>   }
>>
>> This code is failing to replace A::B with A::B.
>
> I don't know what to do here/what you're suggesting.  Before
> the call to tsubst() pl is a TEMPLATE_DECL of struct A::B.
> Calling tsubst() works and replaces the ICE with a reasonable
> error but then causes an ICE in cpp1z/class-deduction19.C.
> There, pl is also TEMPLATE_DECL, and I'm not sure how to
> differentiate between the two at this level.

The problem is that tsubst calls tsubst_decl, which tries to generate
a new instantiated declaration; since this is a use, we need to use
tsubst_copy instead.

Jason
commit 5e194d897e76c8a54a14a50b3a6cb94a21e6810d
Author: Jason Merrill 
Date:   Sun Mar 11 21:43:32 2018 -0400

PR c++/84355 - ICE with deduction for member class template.

* pt.c (tsubst) [TEMPLATE_TYPE_PARM]: Always substitute into
CLASS_PLACEHOLDER_TEMPLATE.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index a92b36a6031..4640ca08ce0 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -14125,8 +14125,7 @@ tsubst (tree t, tree args, tsubst_flags_t complain, tree in_decl)
 			= tsubst_constraint (constr, args, complain, in_decl);
 		else if (tree pl = CLASS_PLACEHOLDER_TEMPLATE (t))
 		  {
-			if (DECL_TEMPLATE_TEMPLATE_PARM_P (pl))
-			  pl = tsubst (pl, args, complain, in_decl);
+			pl = tsubst_copy (pl, args, complain, in_decl);
 			CLASS_PLACEHOLDER_TEMPLATE (r) = pl;
 		  }
 		  }
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction50.C b/gcc/testsuite/g++.dg/cpp1z/class-deduction50.C
new file mode 100644
index 000..e8cdd8c710f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction50.C
@@ -0,0 +1,22 @@
+// PR c++/84355
+// { dg-additional-options -std=c++17 }
+
+template  struct same;
+template  struct same {};
+
+template struct A
+{
+  template struct B
+  {
+B(U);
+  };
+
+  A() {
+B b(0);
+same{};
+  }
+};
+
+struct C {};
+
+A a;

Re: [PATCH] [Microblaze]: PIC Data Text Relative

[Michael Eager]

On 03/12/18 06:19, Andrew Sadek wrote:



On Mon, Mar 5, 2018 at 9:21 PM, Michael Eager > wrote:


On 03/02/2018 08:12 AM, Andrew Sadek wrote:

Hello Michael,

I tried running the whole GCC test suite on the current head
(without my patch) along with 'microblaze-qemu' but I have the
following problems:

1) The test is hanging at 'gcc.c-torture/string-large-1.c' , the
gcc is making a 100% CPU usage and the machine stucks.
I tried compiling the file alone, it generated a couple of
warnings than it hangs.
   warning: '__builtin_memchr' specified size 4294967295 exceeds
maximum object size 2147483647 [-Wstringop-overflow=]
     vp1 = __builtin_memchr (a, b, SIZE1);

Is it a bug? Is there something wrong with my configuration ?
GCC configured with options :  --with-newlib --enable-threads=no
--disable-shared --with-pkgversion='crosstool-NG
crosstool-ng-1.23.0-280-g01e3290' --enable-__cxa_atexit
--disable-libgomp --disable-libmudflap --disable-libmpx
--disable-libssp --disable-libquadmath
--disable-libquadmath-support --enable-lto
--with-host-libstdcxx='-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-target-optspace
--disable-nls --enable-multiarch --enable-languages=c,c++


Your configuration is more complex than my hard-metal target version,
but it looks reasonable.

The problem with string-large-1.c does appear to be a bug.  You can
add a line to the test case which will mark it as known failure for MB:

   /* { dg-xfail-if "exceeds maximum" { microblaze-*-* } } */

(I have not tested this, but it should work.  Compare with other
xfail's.)


Problem that the whole compile package is invoked with '-w' which 
inhibits all warnings and overrides ' -Werror' as well as ' 
-Wfatal-errors' .
As a result, the warning message does not appear when running 
compile.exp. Any suggestions ? Do I remove the '-w' ?




2) For running QEMU, I have no problem with elf execution. But I
do not know how to auto terminate the QEMU itself  as it remains
up even after program execution.
Is there some command to be passed to QEMU in order make system
shut down after program termination with its exit code ?


Yes, this is a problem.  For other targets using QEMU I have added dummy
HLT instructions to terminate QEMU, or used a wrapper around QEMU which
sets breakpoints at exit (or _exit) and stops the simulator when hit.

If you are running Linux on QEMU, instead of using QEMU's built-in gdb
interface you might use the Linux system as the target for the test
suite, running gdbserver on the target.


I have finally managed to fully run QEMU with test suite but had to make 
a local modification in the QEMU code itself.
In the translate function, I make a check if "bri 0" is reached which is 
the '_exit'. Then, abort the QEMU app with the exit code stored in 'r5'.


I've done essentially the same for other targets.


Here are the results below:
_Without Patch:_
=== gcc Summary ===

# of expected passes90776
# of unexpected failures        1317
# of unexpected successes3
# of expected failures207
# of unresolved testcases115
# of unsupported tests2828

_With Patch and after adding my test case:_
=== gcc Summary ===

# of expected passes90790
# of unexpected failures1317
# of unexpected successes3
# of expected failures207
# of unresolved testcases115
# of unsupported tests2828


This appears to be reasonable results.  It appears that there are no 
regressions.


Please send me the mb-gcc command line options for both of these test runs.



--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306

Re: [PATCH][AArch64] Remove aarch64_frame_pointer_required

[Richard Sandiford]

Wilco Dijkstra  writes:
> Richard Sandiford wrote:
>> But there's the third question of whether the frame pointer is available
>> for general allocation.  By removing frame_pointer_required, we're saying
>> that the frame pointer is always available for general use.  
>
> Unlike on ARM/Thumb-2, the frame pointer is unfortunately never available for
> general allocation on AArch64 - so we cannot use it for something
> actually useful.
> A while back there were mid-end patches proposed to allow general allocation
> of FP but those weren't accepted.

Ah, missed that, sorry.  So the asm example I gave probably is as far as
the "problem" goes, and the argument can be made that that's just doing
what the user asked for.

Sorry for the noise...

Richard

Re: [Patch] test_summary: handle single quotes

[Christophe Lyon]

ping?

On 28 February 2018 at 10:30, Christophe Lyon
 wrote:
> Hi,
>
> We happen to build GCC with '~' in the src and build dirs, leading to
> single quotes around the configure path in config.status. For example:
> [...]
> S["TOPLEVEL_CONFIGURE_ARGUMENTS"]="'/home/christophe.lyon/src/Linaro/abe/abe-contrib-summary/mybuild/snapshots/gcc.git~linaro~gcc-7-branch/configure'
> SHELL=/bin/bash --with-mpc=/home/"\
> [...]
>
> This confuses contrib/test_summary which matches "/configure .* in its
> awk script, which fails to match when we have "/configure' XXX"
> instead.
>
> This patch fixes that by adding matches for the optional single
> quotes. I use \047 to match the ascii "'", because I couldn't find how
> to quote this properly in the awk script.
>
> OK for trunk?
>
> Thanks,
>
> Christophe

Re: PATCH: Hurd port of go to gcc-8 (gcc-8-8-20180310+) 16 patches

[Svante Signell]

On Mon, 2018-03-12 at 13:29 +0100, Svante Signell wrote:


> The patches really changed are only four:
> src_libgo_runtime.diff
> src_libgo_go_go_build_syslist.go.diff
> src_libgo_go_runtime.diff
> src_libgo_build.diff

Correction: five:
add-gnu-to-libgo-headers.diff

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

[Jakub Jelinek]

On Mon, Mar 12, 2018 at 09:57:09AM +0100, Martin Liška wrote:
> Hi.
> 
> This is fix for the PR that introduces a new target macro. Using the macro
> one can say that a target has a fast mempcpy and thus it's preferred to be 
> used
> if possible.
> 
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> I also tested on x86_64-linux-gnu.

I think we shouldn't be adding new target macros, better would be a target
hook that returns this information.

Jakub

[PATCH] Add a testcase for PR 84821

[H.J. Lu]

This was introduced by r258390 and fixed by r258415.

I am checking in this to add a testcase for PR 84821.

H.J.
00
* g++.dg/pr84821.C: New test.
---
 gcc/testsuite/ChangeLog|  4 +++
 gcc/testsuite/g++.dg/pr84821.C | 55 ++
 2 files changed, 59 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/pr84821.C

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index c7193069550..5dead01586c 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2018-03-12  H.J. Lu  
+
+   * g++.dg/pr84821.C: New test.
+
 2018-03-12  H.J. Lu  
 
* gcc.dg/pr84799.c: New test.
diff --git a/gcc/testsuite/g++.dg/pr84821.C b/gcc/testsuite/g++.dg/pr84821.C
new file mode 100644
index 000..39da3671eec
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr84821.C
@@ -0,0 +1,55 @@
+// { dg-do compile }
+// { dg-options "-O2" }
+// { dg-additional-options "-fPIC" { target fpic } }
+
+typedef struct a *b;
+struct a {
+  int c;
+  unsigned d[];
+};
+int e, f, g, i, l, m;
+struct o {
+  long *h;
+  int c;
+  unsigned j;
+  int k;
+  long aa;
+};
+inline void p(o *r) { r->c = g; }
+int *n, *ab;
+inline bool s(o *r) {
+  for (; r->aa == 0; r->aa = r->h[r->j])
+if (r->j >= r->c)
+  return false;
+  r->aa >>= 1;
+  for (; r->aa;)
+r++;
+  *n = r->k;
+  return true;
+}
+class t {
+public:
+  t(int);
+  operator b() { return q; }
+  b q;
+};
+bool u, v, ac;
+void fn3() {
+  long w, x;
+  o ad;
+  bool ae;
+  t af(i), ag(i);
+  for (p(); s();) {
+a *ah = af, *ai = ah, *aj = ag;
+x = ai->d[e] >> f & 1;
+ae = x;
+ai = aj;
+w = ai->d[e] >> f & 1;
+ac = w;
+if (v && u && w && x)
+  ab[l] = ++m;
+u = x;
+  }
+  for (;;)
+;
+}
-- 
2.14.3

[PATCH] Add a testcase for PR 84799

[H.J. Lu]

This is introduced by r258390 and fixed by r258415.

I am checking in this patch to add a testcase for PR 84799.


H.J.
---
* gcc.dg/pr84799.c: New test.
---
 gcc/testsuite/ChangeLog|  4 
 gcc/testsuite/gcc.dg/pr84799.c | 29 +
 2 files changed, 33 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr84799.c

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index c13747ad1b6..c7193069550 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2018-03-12  H.J. Lu  
+
+   * gcc.dg/pr84799.c: New test.
+
 2018-03-12  Richard Biener  
 
PR tree-optimization/84803
diff --git a/gcc/testsuite/gcc.dg/pr84799.c b/gcc/testsuite/gcc.dg/pr84799.c
new file mode 100644
index 000..2b3a48f9e34
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr84799.c
@@ -0,0 +1,29 @@
+/* { dg-do compile } */
+/* { dg-options "-O" } */
+
+int a, g;
+long b, f;
+short c, d, e;
+
+static void fn1 ()
+{
+  if (a)
+{
+  long i = 5, j = b / i | c;
+  int k = b % (d % i) & j;
+  short l = ~f % (-d / j ^ -e), m = e << (d - l);
+  if (k)
+m = d;
+  i = d | (i & b);
+  g = (c | ~f) % i + l;
+  e = (c - f) & e;
+  d = m;
+}
+}
+
+int main ()
+{
+  b |= 1;
+  fn1 ();
+  return 0; 
+}
-- 
2.14.3

Re: [PATCH] [Microblaze]: PIC Data Text Relative

[Andrew Sadek]

On Mon, Mar 5, 2018 at 9:21 PM, Michael Eager  wrote:

> On 03/02/2018 08:12 AM, Andrew Sadek wrote:
>
>> Hello Michael,
>>
>> I tried running the whole GCC test suite on the current head (without my
>> patch) along with 'microblaze-qemu' but I have the following problems:
>>
>> 1) The test is hanging at 'gcc.c-torture/string-large-1.c' , the gcc is
>> making a 100% CPU usage and the machine stucks.
>> I tried compiling the file alone, it generated a couple of warnings than
>> it hangs.
>>   warning: '__builtin_memchr' specified size 4294967295 exceeds maximum
>> object size 2147483647 [-Wstringop-overflow=]
>> vp1 = __builtin_memchr (a, b, SIZE1);
>>
>> Is it a bug? Is there something wrong with my configuration ?
>> GCC configured with options :  --with-newlib --enable-threads=no
>> --disable-shared --with-pkgversion='crosstool-NG
>> crosstool-ng-1.23.0-280-g01e3290' --enable-__cxa_atexit
>> --disable-libgomp --disable-libmudflap --disable-libmpx --disable-libssp
>> --disable-libquadmath --disable-libquadmath-support --enable-lto
>> --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic
>> -lm' --enable-target-optspace --disable-nls --enable-multiarch
>> --enable-languages=c,c++
>>
>
> Your configuration is more complex than my hard-metal target version,
> but it looks reasonable.
>
> The problem with string-large-1.c does appear to be a bug.  You can
> add a line to the test case which will mark it as known failure for MB:
>
>   /* { dg-xfail-if "exceeds maximum" { microblaze-*-* } } */
>
> (I have not tested this, but it should work.  Compare with other
> xfail's.)


Problem that the whole compile package is invoked with '-w' which inhibits
all warnings and overrides ' -Werror' as well as ' -Wfatal-errors' .
As a result, the warning message does not appear when running compile.exp.
Any suggestions ? Do I remove the '-w' ?


>
>
> 2) For running QEMU, I have no problem with elf execution. But I do not
>> know how to auto terminate the QEMU itself  as it remains up even after
>> program execution.
>> Is there some command to be passed to QEMU in order make system shut down
>> after program termination with its exit code ?
>>
>
> Yes, this is a problem.  For other targets using QEMU I have added dummy
> HLT instructions to terminate QEMU, or used a wrapper around QEMU which
> sets breakpoints at exit (or _exit) and stops the simulator when hit.
>
> If you are running Linux on QEMU, instead of using QEMU's built-in gdb
> interface you might use the Linux system as the target for the test
> suite, running gdbserver on the target.
>

I have finally managed to fully run QEMU with test suite but had to make a
local modification in the QEMU code itself.
In the translate function, I make a check if "bri 0" is reached which is
the '_exit'. Then, abort the QEMU app with the exit code stored in 'r5'.

Here are the results below:
*Without Patch:*
=== gcc Summary ===

# of expected passes 90776
# of unexpected failures 1317
# of unexpected successes 3
# of expected failures 207
# of unresolved testcases 115
# of unsupported tests 2828

*With Patch and after adding my test case:*
=== gcc Summary ===

# of expected passes 90790
# of unexpected failures 1317
# of unexpected successes 3
# of expected failures 207
# of unresolved testcases 115
# of unsupported tests 2828

Most of failures are in gcc.dg/pch folder => 'undefined reference main',
and in 'gcc.dg/torture/stackalign/' folder => 'undefined reference to
`_GLOBAL_OFFSET_TABLE_'

Please tell me if testing is on the right track and if any further
adaptations are needed.
Thanks.


>
>
>>
>> On Tue, Feb 27, 2018 at 10:13 AM, Andrew Sadek > > wrote:
>>
>> Thanks Micheal for your response.
>> I shall re-submit patches separately after re-running the whole GCC
>> Test suite and re-checking code conventions.
>> For sending to gdb-patches, it was a conflict from my side as
>> actually I thought it is also for binutils.
>>
>> On Tue, Feb 27, 2018 at 2:07 AM, Michael Eager > > wrote:
>>
>> On 02/25/2018 11:44 PM, Andrew Guirguis wrote:
>>
>> Dears,
>>
>> Kindly find attached the patch bundle for Microblaze
>> '-mpic-data-text-relative' feature.
>>
>> Description of the feature in the following link:
>> https://github.com/andrewsadek/microblaze-pic-data-text-rel/
>> blob/pic_data_text_rel/README.md
>> > rel/blob/pic_data_text_rel/README.md>
>> > rel/blob/pic_data_text_rel/README.md
>> > rel/blob/pic_data_text_rel/README.md>>
>>
>> Bundle includes:
>> 1) Change logs for GCC, binutils
>>

C++ PATCH for c++/84802, ICE capturing uninstantiated class

[Jason Merrill]

If A isn't instantiated by the time we build the capture proxy
VAR_DECL, it gets no DECL_SIZE. So make sure it is.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit e979dc834d91e52c0c568f85c2b62ec67dac3cdc
Author: Jason Merrill 
Date:   Mon Mar 12 01:01:14 2018 -0400

PR c++/84802 - ICE capturing uninstantiated class.

* lambda.c (build_capture_proxy): Call complete_type.

diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index de064ffc85e..b3c75c84682 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -432,6 +432,8 @@ build_capture_proxy (tree member, tree init)
   object = convert (type, ptr);
 }
 
+  complete_type (type);
+
   var = build_decl (input_location, VAR_DECL, name, type);
   SET_DECL_VALUE_EXPR (var, object);
   DECL_HAS_VALUE_EXPR_P (var) = 1;
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-generic-ice9.C b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-ice9.C
new file mode 100644
index 000..a07acfff884
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-ice9.C
@@ -0,0 +1,11 @@
+// PR c++/84802
+// { dg-do compile { target c++14 } }
+
+template  struct A { };
+
+void f (A& ar)
+{
+  [](const auto& x)
+{ return [x]{}(); }
+  (ar);
+}

[PATCH] Fix PR84803

[Richard Biener]

The following fixes PR84803 where we have a memory reference 
data-reference analysis thought it's not worth handling.
This properly guards the access.

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

Richard.

2018-03-12  Richard Biener  

PR tree-optimization/84803
* tree-if-conv.c (ifcvt_memrefs_wont_trap): Don't do anything
for refs DR analysis didn't process.

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

Index: gcc/tree-if-conv.c
===
--- gcc/tree-if-conv.c  (revision 258445)
+++ gcc/tree-if-conv.c  (working copy)
@@ -864,6 +864,11 @@ base_object_writable (tree ref)
 static bool
 ifcvt_memrefs_wont_trap (gimple *stmt, vec drs)
 {
+  /* If DR didn't see a reference here we can't use it to tell
+ whether the ref traps or not.  */
+  if (gimple_uid (stmt) == 0)
+return false;
+
   data_reference_p *master_dr, *base_master_dr;
   data_reference_p a = drs[gimple_uid (stmt) - 1];
 
Index: gcc/testsuite/gcc.dg/torture/pr84803.c
===
--- gcc/testsuite/gcc.dg/torture/pr84803.c  (nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr84803.c  (working copy)
@@ -0,0 +1,30 @@
+/* { dg-do compile } */
+
+long a;
+long *b;
+void c ();
+void d ();
+void
+e (long f)
+{
+  if (a)
+*b = f;
+}
+void
+g ()
+{
+  c (g, e);
+}
+void
+c (int f, int h ())
+{
+  d (f, h, "");
+}
+void
+d (int f, int h (), char *i, char *k)
+{
+  int j;
+  d (f, h, i + 1, k);
+  while (--j)
+h (*i);
+}

Re: [parloops, PR83126], Use cached affine_ivs canonicalize_loop_ivs

[Richard Biener]

On Thu, 22 Feb 2018, Tom de Vries wrote:

> Hi,
> 
> this patch fixes an ICE in the parloops pass.
> 
> The ICE (when compiling the test-case in attached patch) follows from the fact
> that here in gen_parallel_loop the call to canonicalize_loop_ivs fails to
> "base all the induction variables in LOOP on a single control one":
> ...
>   /* Base all the induction variables in LOOP on a single control one.*/
>   canonicalize_loop_ivs (loop, , true);
> ...
> 
> This is caused by the fact that for one of the induction variables, simple_iv
> no longer returns true (as was the case at the start of gen_parallel_loop).
> This seems to be triggered by the fact that during loop_version we call
> scev_reset (although I'm not sure why when recalculating scev info we're not
> reaching the same conclusion as before).

I guess the real reason is that canonicalize_loop_ivs calls
create_iv first which in the parloop case with bump-in-latch true
and then incrementally re-writes PHIs, eventually wrecking other
PHIs SCEV.  In this case the 2nd PHIs evolution depends on the
first one but the rewritten ones depend on the new IV already.

So the better fix (maybe not 100% enough) would be to re-organize
canonicalize_loop_ivs to first do analysis of all PHIs and then
rewrite them all.

> 
> The patch fixes the ICE by caching the affine_ivs as calculated by simple_iv
> before calling loop_version, and reusing those in canonicalize_loop_ivs
> (instead of calling simple_iv again).
> 
> Bootstrapped and reg-tested on x86_64.
> 
> OK for stage1?

First of all please to not use std::map but instead our own hash_map,
the proper way of including  would be to define INCLUDE_MAP
before the system.h include.

But see above.

> I'm not sure if this is minimal/low-impact enough for stage4. If not, I can
> rework the bit of the patch that adds an assert after canonicalize_loop_ivs
> into a patch that aborts the optimization instead of ICE-ing.

I think that's something reasonable anyway.

Thanks,
Richard.

> Thanks,
> - Tom
> 

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

Re: [PATCH] Diagnose earlier invalid inline asm constraints (PR inline-asm/84742)

[H.J. Lu]

On Mon, Mar 12, 2018 at 4:18 AM, H.J. Lu  wrote:
> On Thu, Mar 8, 2018 at 10:19 AM, Jakub Jelinek  wrote:
>> Hi!
>>
>> We have many loops that use CONSTRAINT_LEN to skip over various constraint
>> characters, but we assume the constraints have valid length and don't walk
>> the individual characters to double check this.
>>
>> If that is not the case, when e.g. 2 character constraint starting letter
>> is followed by '\0', we'd reject it early (during vregs pass, through
>> asm_operand_ok).  The PR has different testcase (that fails randomly based
>> on ASLR), where a 2 character constraint starting letter is followed by ',',
>> and several spots expect that not to happen (they count number of
>> alternatives and then for each alternative walk with skipping CONSTRAINT_LEN
>> characters).
>>
>> This patch diagnoses this problematic case early as well.
>>
>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>>
>> 2018-03-08  Jakub Jelinek  
>>
>> PR inline-asm/84742
>> * recog.c (asm_operand_ok): Return 0 if multi-character constraint
>> has ',' character inside of it.
>>
>> * gcc.target/i386/pr84742-1.c: New test.
>> * gcc.target/i386/pr84742-2.c: New test.
>>
>> --- gcc/recog.c.jj  2018-01-16 09:53:47.0 +0100
>> +++ gcc/recog.c 2018-03-08 14:04:35.889274871 +0100
>> @@ -1825,7 +1825,7 @@ asm_operand_ok (rtx op, const char *cons
>>len = CONSTRAINT_LEN (c, constraint);
>>do
>> constraint++;
>> -  while (--len && *constraint);
>> +  while (--len && *constraint && *constraint != ',');
>>if (len)
>> return 0;
>>  }
>> --- gcc/testsuite/gcc.target/i386/pr84742-1.c.jj2018-03-08 
>> 14:11:20.155463943 +0100
>> +++ gcc/testsuite/gcc.target/i386/pr84742-1.c   2018-03-08 
>> 14:12:28.453495882 +0100
>> @@ -0,0 +1,10 @@
>> +/* PR inline-asm/84742 */
>> +/* { dg-do compile } */
>> +/* { dg-options "-O2" } */
>> +
>> +void
>> +foo ()
>> +{
>> +  char b = 1;
>> +  asm volatile ("" : "+T,Y" (b));  /* { dg-error "impossible constraint 
>> in 'asm'" } */
>> +}
>
> This test fails at random on 32-bit hosts (i686 and x32).  Sometimes I got
>
> spawn -ignore SIGHUP
> /export/build/gnu/gcc-32bit-all-test/build-i686-linux/gcc/xgcc
> -B/export/build/gnu/gcc-32bit-all-test/build-i686-linux/gcc/
> /export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr84742-1.c
> -m32 -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -S -o
> pr84742-1.s
> /export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr84742-1.c:
> In function 'foo':
> /export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr84742-1.c:9:3:
> error: matching constraint not valid in output operand
> /export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr84742-1.c:9:3:
> error: matching constraint not valid in output operand
> FAIL: gcc.target/i386/pr84742-1.c  (test for errors, line 9)
> FAIL: gcc.target/i386/pr84742-1.c (test for excess errors)
>
> But when I ran it by hand:
>
> [hjl@gnu-skx-1 gcc]$
> /export/build/gnu/gcc-32bit-all-test/build-i686-linux/gcc/xgcc
> -B/export/build/gnu/gcc-32bit-all-test/build-i686-linux/gcc/
> /export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr84742-1.c
> -m32 -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -S -o
> pr84742-1.s
> /export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr84742-1.c:
> In function \u2018foo\u2019:
> /export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr84742-1.c:9:3:
> error: impossible constraint in \u2018asm\u2019
> [hjl@gnu-skx-1 gcc]$
>
>

I opened;

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


-- 
H.J.

Re: [PATCH] Diagnose earlier invalid inline asm constraints (PR inline-asm/84742)

[H.J. Lu]

On Thu, Mar 8, 2018 at 10:19 AM, Jakub Jelinek  wrote:
> Hi!
>
> We have many loops that use CONSTRAINT_LEN to skip over various constraint
> characters, but we assume the constraints have valid length and don't walk
> the individual characters to double check this.
>
> If that is not the case, when e.g. 2 character constraint starting letter
> is followed by '\0', we'd reject it early (during vregs pass, through
> asm_operand_ok).  The PR has different testcase (that fails randomly based
> on ASLR), where a 2 character constraint starting letter is followed by ',',
> and several spots expect that not to happen (they count number of
> alternatives and then for each alternative walk with skipping CONSTRAINT_LEN
> characters).
>
> This patch diagnoses this problematic case early as well.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2018-03-08  Jakub Jelinek  
>
> PR inline-asm/84742
> * recog.c (asm_operand_ok): Return 0 if multi-character constraint
> has ',' character inside of it.
>
> * gcc.target/i386/pr84742-1.c: New test.
> * gcc.target/i386/pr84742-2.c: New test.
>
> --- gcc/recog.c.jj  2018-01-16 09:53:47.0 +0100
> +++ gcc/recog.c 2018-03-08 14:04:35.889274871 +0100
> @@ -1825,7 +1825,7 @@ asm_operand_ok (rtx op, const char *cons
>len = CONSTRAINT_LEN (c, constraint);
>do
> constraint++;
> -  while (--len && *constraint);
> +  while (--len && *constraint && *constraint != ',');
>if (len)
> return 0;
>  }
> --- gcc/testsuite/gcc.target/i386/pr84742-1.c.jj2018-03-08 
> 14:11:20.155463943 +0100
> +++ gcc/testsuite/gcc.target/i386/pr84742-1.c   2018-03-08 14:12:28.453495882 
> +0100
> @@ -0,0 +1,10 @@
> +/* PR inline-asm/84742 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +void
> +foo ()
> +{
> +  char b = 1;
> +  asm volatile ("" : "+T,Y" (b));  /* { dg-error "impossible constraint 
> in 'asm'" } */
> +}

This test fails at random on 32-bit hosts (i686 and x32).  Sometimes I got

spawn -ignore SIGHUP
/export/build/gnu/gcc-32bit-all-test/build-i686-linux/gcc/xgcc
-B/export/build/gnu/gcc-32bit-all-test/build-i686-linux/gcc/
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr84742-1.c
-m32 -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -S -o
pr84742-1.s
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr84742-1.c:
In function 'foo':
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr84742-1.c:9:3:
error: matching constraint not valid in output operand
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr84742-1.c:9:3:
error: matching constraint not valid in output operand
FAIL: gcc.target/i386/pr84742-1.c  (test for errors, line 9)
FAIL: gcc.target/i386/pr84742-1.c (test for excess errors)

But when I ran it by hand:

[hjl@gnu-skx-1 gcc]$
/export/build/gnu/gcc-32bit-all-test/build-i686-linux/gcc/xgcc
-B/export/build/gnu/gcc-32bit-all-test/build-i686-linux/gcc/
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr84742-1.c
-m32 -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -S -o
pr84742-1.s
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr84742-1.c:
In function \u2018foo\u2019:
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr84742-1.c:9:3:
error: impossible constraint in \u2018asm\u2019
[hjl@gnu-skx-1 gcc]$


-- 
H.J.

RE: [PATCH][GCC][ARM] Fix can_change_mode_class for big-endian

[Tamar Christina]

Ping

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Tamar Christina
> Sent: Monday, March 5, 2018 16:52
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Ramana Radhakrishnan
> ; Richard Earnshaw
> ; ni...@redhat.com; Kyrylo Tkachov
> 
> Subject: [PATCH][GCC][ARM] Fix can_change_mode_class for big-endian
> 
> Hi All,
> 
> Taking the subreg of a vector mode on big-endian may result in an infinite
> recursion and eventually a segfault once we run out of stack space.
> 
> As an example, taking a subreg of V4HF to SImode we end up in the following
> loop on big-endian:
> 
> #861 0x008462e9 in operand_subword_force src/gcc/gcc/emit-
> rtl.c:1787
> #862 0x00882a90 in emit_move_multi_word
> src/gcc/gcc/expr.c:3621
> #863 0x0087eea1 in emit_move_insn_1 src/gcc/gcc/expr.c:3698
> #864 0x0087f350 in emit_move_insn src/gcc/gcc/expr.c:3757
> #865 0x0085e326 in copy_to_reg src/gcc/gcc/explow.c:603
> #866 0x008462e9 in operand_subword_force src/gcc/gcc/emit-
> rtl.c:1787
> 
> The reason is that operand_subword_force will always fail. When the value is
> in a register that can't be accessed as a multi word the code tries to create 
> a
> new psuedo register and emit the value to it. Eventually you end up in
> simplify_gen_subreg which calls validate_subreg.
> 
> validate_subreg will however always fail because of the
> REG_CAN_CHANGE_MODE_P check.
> 
> On little endian this check always returns true. On big-endian this check is
> supposed to prevent values that have a size larger than word size, due to
> those being stored in VFP registers.
> 
> However we are only interested in a subreg of the vector mode, so we
> should be checking the unit size, not the size of the entire mode. Doing this
> fixes the problem.
> 
> Regtested on armeb-none-eabi and no regressions.
> Bootstrapped on arm-none-linux-gnueabihf and no issues.
> 
> Ok for trunk? and for backport to GCC 7?
> 
> Thanks,
> Tamar
> 
> gcc/
> 2018-03-05  Tamar Christina  
> 
>   PR target/84711
>   * config/arm/arm.c (arm_can_change_mode_class): Use
> GET_MODE_UNIT_SIZE
>   instead of GET_MODE_SIZE when comparing Units.
> 
> gcc/testsuite/
> 2018-03-05  Tamar Christina  
> 
>   PR target/84711
>   * gcc.target/arm/big-endian-subreg.c: New.
> 
> --

Re: [PR84682] disregard address constraints on non-addresses

[Bin.Cheng]

On Fri, Mar 9, 2018 at 6:45 AM, Alexandre Oliva  wrote:
> LRA gets very confused when non-addresses are passed as operands to
> asms with address contraints.  Even if other constraints are
> available, and the operand is a perfect fit for them, we'd still
> attempt to process the operand as an address, and fail miserably at
> that.
>
> Truth is, address constraints expect operands allowed by
> address_operand, and we make sure this is the case throughout the
> compiler, even in asm statements.  The problem was that, if multiple
> constraints were available, we wouldn't insist that the operand be
> allowed by address_operand, but we would proceed as if it was,
> regardless of any other constraints.
>
> To address this problem, I've arranged for LRA to attempt to deal with
> address-constrained operands as addresses only when the is_address
> flag is set, and to not set this flag in preprocess_constraints for
> asm operands that are not allowed by address_operand.
>
> Regstrapped on i686- and x86_64-linux-gnu.  Ok to install?
>
> for  gcc/ChangeLog
>
> PR rtl-optimization/84682
> * lra-constraints.c (process_address_1): Check is_address flag
> for address constraints.
> (process_alt_operands): Likewise.
> * lra.c (lra_set_insn_recog_data): Pass asm operand locs to
> preprocess_constraints.
> * recog.h (preprocess_constraints): Add oploc parameter.
> Adjust callers.
> * recog.c (preprocess_constraints): Test address_operand for
> CT_ADDRESS constraints.
>
> for  gcc/testsuite/ChangeLog
>
> PR rtl-optimization/84682
> * gcc.dg/torture/pr84682-1.c: New.
> * gcc.dg/torture/pr84682-2.c: New.
Hi Alexandre,
This test failed because of ICE on various aarch64 targets with below
error message:

Executing on host: /.../build/build-aarch64-none-elf/obj/gcc2/gcc/xgcc
-B/.../build/build-aarch64-none-elf/obj/gcc2/gcc/
/.../build/src/gcc/gcc/testsuite/gcc.dg/torture/pr84682-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never-O0   -S
-specs=aem-ve.specs-mcmodel=small  -o pr84682-2.s(timeout =
300)
spawn /.../build/build-aarch64-none-elf/obj/gcc2/gcc/xgcc
-B/.../build/build-aarch64-none-elf/obj/gcc2/gcc/
/.../build/src/gcc/gcc/testsuite/gcc.dg/torture/pr84682-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -S
-specs=aem-ve.specs -mcmodel=small -o pr84682-2.s
during RTL pass: expand
/.../build/src/gcc/gcc/testsuite/gcc.dg/torture/pr84682-2.c: In function 'b':
/.../build/src/gcc/gcc/testsuite/gcc.dg/torture/pr84682-2.c:9:3:
internal compiler error: in aarch64_classify_address, at
config/aarch64/aarch64.c:5678
0xfe3c29 aarch64_classify_address
/.../build/src/gcc/gcc/config/aarch64/aarch64.c:5677
0xfe8be8 aarch64_legitimate_address_hook_p
/.../build/src/gcc/gcc/config/aarch64/aarch64.c:5958
0xc0149e default_addr_space_legitimate_address_p(machine_mode,
rtx_def*, bool, unsigned char)
/.../build/src/gcc/gcc/targhooks.c:1476
0xb5b9f1 memory_address_addr_space_p(machine_mode, rtx_def*, unsigned char)
/.../build/src/gcc/gcc/recog.c:1334
0xb5d278 address_operand(rtx_def*, machine_mode)
/.../build/src/gcc/gcc/recog.c:1073
0xb5e186 asm_operand_ok(rtx_def*, char const*, char const**)
/.../build/src/gcc/gcc/recog.c:1816
0x73f440 expand_asm_stmt
/.../build/src/gcc/gcc/cfgexpand.c:3138
0x742d3c expand_gimple_stmt_1
/.../build/src/gcc/gcc/cfgexpand.c:3621
0x742d3c expand_gimple_stmt
/.../build/src/gcc/gcc/cfgexpand.c:3790
0x745c15 expand_gimple_basic_block
/.../build/src/gcc/gcc/cfgexpand.c:5819
0x749c2f execute
/.../build/src/gcc/gcc/cfgexpand.c:6425
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Not sure if it reveals latent bug or just inconsistent issue with
backend though.

Thanks,
bin
> * gcc.dg/torture/pr84682-3.c: New.
> ---
>  gcc/lra-constraints.c|   15 ++-
>  gcc/lra.c|3 ++-
>  gcc/recog.c  |   24 +---
>  gcc/recog.h  |2 +-
>  gcc/testsuite/gcc.dg/torture/pr84682-1.c |5 +
>  gcc/testsuite/gcc.dg/torture/pr84682-2.c |   10 ++
>  gcc/testsuite/gcc.dg/torture/pr84682-3.c |8 
>  7 files changed, 57 insertions(+), 10 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/torture/pr84682-1.c
>  create mode 100644 gcc/testsuite/gcc.dg/torture/pr84682-2.c
>  create mode 100644 gcc/testsuite/gcc.dg/torture/pr84682-3.c
>
> diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
> index 59b97540d98f..ae55c86f1777 100644
> --- a/gcc/lra-constraints.c
> +++ b/gcc/lra-constraints.c
> @@ -2276,6 +2276,12 @@ process_alt_operands (int only_alternative)
>   break;
>
> case CT_ADDRESS:
> +

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

[Richard Biener]

On Mon, Mar 12, 2018 at 9:57 AM, Martin Liška  wrote:
> Hi.
>
> This is fix for the PR that introduces a new target macro. Using the macro

Don't add new target macros, use target hooks.

> one can say that a target has a fast mempcpy and thus it's preferred to be 
> used
> if possible.
>
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> I also tested on x86_64-linux-gnu.
>
> Ready to be installed?
> Martin
>
> gcc/ChangeLog:
>
> 2018-03-08  Martin Liska  
>
> PR middle-end/81657
> * builtins.c (expand_builtin_memory_copy_args): Add new
> arguments.
> * config/i386/i386.h (TARGET_HAS_FAST_MEMPCPY_ROUTINE):
> New macro.
> * defaults.h (TARGET_HAS_FAST_MEMPCPY_ROUTINE): Likewise.
> * doc/tm.texi: Likewise.
> * doc/tm.texi.in: Likewise.
> * expr.c (compare_by_pieces): Add support for bail out.
> (emit_block_move_hints): Likewise.
> * expr.h (emit_block_move_hints): Add new arguments.
>
> gcc/testsuite/ChangeLog:
>
> 2018-03-09  Martin Liska  
>
> PR middle-end/81657
> * gcc.dg/string-opt-1.c: Adjust test to run only on non-x86
> target.
> ---
>  gcc/builtins.c  | 13 -
>  gcc/config/i386/i386.h  |  3 +++
>  gcc/defaults.h  |  7 +++
>  gcc/doc/tm.texi |  5 +
>  gcc/doc/tm.texi.in  |  5 +
>  gcc/expr.c  | 16 +++-
>  gcc/expr.h  |  4 +++-
>  gcc/testsuite/gcc.dg/string-opt-1.c |  4 ++--
>  8 files changed, 52 insertions(+), 5 deletions(-)
>
>

Re: [PATCH] Fix PTA info in IPA ICF (PR ipa/84658).

[Richard Biener]

On Mon, Mar 12, 2018 at 9:42 AM, Martin Liška  wrote:
> Hi.
>
> This is what I was recommended in 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658#c18.
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>
> Ready to be installed?

Please do not remove the DECL_PT_UID setting (set_alias_uids).   That's required
to make followup PTA runs compute correct points-to sets.

Otherwise...

+   /* The above get's us to 99% I guess, at least catching the
+ address compares.  Below also gets us aliasing correct
+ but as said we're giving leeway to the situation with
+ readonly vars anyway, so ... */
+   basic_block bb;
+   FOR_EACH_BB_FN (bb, DECL_STRUCT_FUNCTION (cnode->decl))
+   for (gimple_stmt_iterator gsi = gsi_start_bb (bb); !gsi_end_p (gsi);
+gsi_next ())

so if you want to keep this (as the comment says I think it's not
strictly necessary) then you can replace DECL_STRUCT_FUNCTION (cnode->decl)
with 'fn' you compute earlier.

Otherwise looks ok.

Thanks,
Richard.

> Martin
>
> gcc/ChangeLog:
>
> 2018-03-12  Martin Liska  
>
> PR ipa/84658.
> * ipa-icf.c (set_alias_uids): Remove.
> (sem_variable::merge): Remove usage.
> (sem_item_optimizer::sem_item_optimizer): Initialize new
> vector.
> (sem_item_optimizer::~sem_item_optimizer): Release it.
> (sem_item_optimizer::merge_classes): Register variable aliases.
> (sem_item_optimizer::fixup_pt_set): New function.
> (sem_item_optimizer::fixup_points_to_sets): Likewise.
> * ipa-icf.h: Declare new variables and functions.
>
> gcc/testsuite/ChangeLog:
>
> 2018-03-12  Martin Liska  
>
> PR ipa/84658.
> * g++.dg/ipa/pr84658.C: New test.
> ---
>  gcc/ipa-icf.c  | 88 
> +-
>  gcc/ipa-icf.h  | 10 +
>  gcc/testsuite/g++.dg/ipa/pr84658.C | 30 +
>  3 files changed, 108 insertions(+), 20 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/ipa/pr84658.C
>
>

Re: [PATCH] Fix bogus strncpy source length warning on source bound by constant

[Richard Biener]

On Sun, Mar 11, 2018 at 4:22 PM, Siddhesh Poyarekar
 wrote:
> Avoid issuing a bogus warning when the source of strncpy is bound by a
> constant and is known to be less than the size of the destination.
>
> Testsuite run is underway (not complete yet, but no new errors so far)
> and a bootstrap is also underway, I'll report status once they're both
> done.
>
> gcc/
>
> * gcc/tree-ssa-strlen.c (handle_builtin_stxncpy): Check bounds
> of source length if available.
>
> gcc/testsuite/
>
> * gcc.dg/builtin-stringop-chk-10.c: New test case.
> ---
>  gcc/testsuite/gcc.dg/builtin-stringop-chk-10.c | 17 +
>  gcc/tree-ssa-strlen.c  | 24 
>  2 files changed, 41 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.dg/builtin-stringop-chk-10.c
>
> diff --git a/gcc/testsuite/gcc.dg/builtin-stringop-chk-10.c 
> b/gcc/testsuite/gcc.dg/builtin-stringop-chk-10.c
> new file mode 100644
> index 000..13e4bd2f049
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/builtin-stringop-chk-10.c
> @@ -0,0 +1,17 @@
> +/* Bogus -Wstringop-overflow on strncpy when size is based on strlen but is
> +   bound by a constant.
> +   { dg-do compile }
> +   { dg-options "-O2 -Wstringop-overflow" } */
> +
> +char dst[1024];
> +
> +void
> +f1 (const char *src)
> +{
> +  unsigned long limit = 512;
> +  unsigned long len = __builtin_strlen (src);  /* { dg-bogus "length 
> computed here" } */
> +  if (len > limit)
> +len = limit;
> +
> +  __builtin_strncpy (dst, src, len);   /* { dg-bogus "specified bound 
> depends on the length of the source argument" } */
> +}
> diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
> index 72f6a17cd32..49a31a551f5 100644
> --- a/gcc/tree-ssa-strlen.c
> +++ b/gcc/tree-ssa-strlen.c
> @@ -2125,6 +2125,30 @@ handle_builtin_stxncpy (built_in_function, 
> gimple_stmt_iterator *gsi)
>return;
>  }
>
> +  /* When LEN is MIN_EXPR of strlen and a constant, then the copy is bound by
> + that constant.  If the destination size is also constant then compare 
> with
> + it to avoid a bogus warning.  */
> +  if (TREE_CODE (len) == SSA_NAME)
> +{
> +  gimple *def_stmt = SSA_NAME_DEF_STMT (len);
> +
> +  if (is_gimple_assign (def_stmt)
> + && gimple_assign_rhs_code (def_stmt) == MIN_EXPR)
> +   {
> + /* RHS1 is the strlen, so check if RHS2 and DSTSIZE are constant.  
> */
> + tree rhs2 = gimple_assign_rhs2 (def_stmt);
> + tree dstsize = compute_objsize (dst, 1);
> +
> + if (TREE_CODE (rhs2) == INTEGER_CST
> + && TREE_CODE (dstsize) == INTEGER_CST
> + && int_cst_value (rhs2) < int_cst_value (dstsize))

Please use tree_int_cst_lt (rhs1, dstsize) instead.

> +   {
> + gimple_set_no_warning (stmt, true);

Why this?  There's only a single bit -- where do we warn from if you
don't do this here?

I also wonder why this code doesn't use range-info given the
INTEGER_CST constraints
range-info should tell us more than just handling MIN_EXPR?

Richard.

> + return;
> +   }
> +   }
> +}
> +
>/* Retrieve the strinfo data for the string S that LEN was computed
>   from as some function F of strlen (S) (i.e., LEN need not be equal
>   to strlen(S)).  */
> --
> 2.14.3
>

Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

[Marc Glisse]

On Mon, 12 Mar 2018, Martin Liška wrote:


This is fix for the PR that introduces a new target macro. Using the macro
one can say that a target has a fast mempcpy and thus it's preferred to be used
if possible.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
I also tested on x86_64-linux-gnu.

Ready to be installed?
Martin

gcc/ChangeLog:

2018-03-08  Martin Liska  

PR middle-end/81657
* builtins.c (expand_builtin_memory_copy_args): Add new
arguments.
* config/i386/i386.h (TARGET_HAS_FAST_MEMPCPY_ROUTINE):
New macro.


Shouldn't the macro be defined in a more specific case, for instance glibc 
on x86? Or do all known libc on x86 happen to provide a fast mempcpy?



* defaults.h (TARGET_HAS_FAST_MEMPCPY_ROUTINE): Likewise.
* doc/tm.texi: Likewise.
* doc/tm.texi.in: Likewise.
* expr.c (compare_by_pieces): Add support for bail out.
(emit_block_move_hints): Likewise.
* expr.h (emit_block_move_hints): Add new arguments.


--
Marc Glisse

[committed] Add testcase for already fixed PR c++/84813

[Jakub Jelinek]

Hi!

This PR got fixed in r251433 which I'm afraid is not backportable,
we were trying to register local specialization during dwarf2out_type_decl.

I've committed the testcase as obvious to trunk, so that we don't regress
on it again:

2018-03-12  Jakub Jelinek  

PR c++/84813
* g++.dg/debug/pr84813.C: New test.

--- gcc/testsuite/g++.dg/debug/pr84813.C.jj 2018-03-12 09:57:50.197029595 
+0100
+++ gcc/testsuite/g++.dg/debug/pr84813.C2018-03-12 09:57:40.279028562 
+0100
@@ -0,0 +1,33 @@
+// PR c++/84813
+// { dg-do compile }
+// { dg-options "-g -std=c++14" }
+
+template 
+struct P {};
+
+template 
+struct F {
+  using type = int;
+};
+
+template 
+void
+apply ()
+{
+  constexpr int N = T::N;
+  [] (typename F::type)
+  {
+auto f = [] () {};
+P{};
+  };
+}
+
+struct A {
+  static constexpr int N = 1;
+};
+
+void
+instantiate ()
+{
+  apply ();
+}


Jakub

[PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657).

[Martin Liška]

Hi.

This is fix for the PR that introduces a new target macro. Using the macro
one can say that a target has a fast mempcpy and thus it's preferred to be used
if possible.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
I also tested on x86_64-linux-gnu.

Ready to be installed?
Martin

gcc/ChangeLog:

2018-03-08  Martin Liska  

PR middle-end/81657
* builtins.c (expand_builtin_memory_copy_args): Add new
arguments.
* config/i386/i386.h (TARGET_HAS_FAST_MEMPCPY_ROUTINE):
New macro.
* defaults.h (TARGET_HAS_FAST_MEMPCPY_ROUTINE): Likewise.
* doc/tm.texi: Likewise.
* doc/tm.texi.in: Likewise.
* expr.c (compare_by_pieces): Add support for bail out.
(emit_block_move_hints): Likewise.
* expr.h (emit_block_move_hints): Add new arguments.

gcc/testsuite/ChangeLog:

2018-03-09  Martin Liska  

PR middle-end/81657
* gcc.dg/string-opt-1.c: Adjust test to run only on non-x86
target.
---
 gcc/builtins.c  | 13 -
 gcc/config/i386/i386.h  |  3 +++
 gcc/defaults.h  |  7 +++
 gcc/doc/tm.texi |  5 +
 gcc/doc/tm.texi.in  |  5 +
 gcc/expr.c  | 16 +++-
 gcc/expr.h  |  4 +++-
 gcc/testsuite/gcc.dg/string-opt-1.c |  4 ++--
 8 files changed, 52 insertions(+), 5 deletions(-)


diff --git a/gcc/builtins.c b/gcc/builtins.c
index 85affa74510..c2ca36934f7 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -3651,13 +3651,24 @@ expand_builtin_memory_copy_args (tree dest, tree src, tree len,
   src_mem = get_memory_rtx (src, len);
   set_mem_align (src_mem, src_align);
 
+  bool is_move_done;
+
   /* Copy word part most expediently.  */
   dest_addr = emit_block_move_hints (dest_mem, src_mem, len_rtx,
  CALL_EXPR_TAILCALL (exp)
  && (endp == 0 || target == const0_rtx)
  ? BLOCK_OP_TAILCALL : BLOCK_OP_NORMAL,
  expected_align, expected_size,
- min_size, max_size, probable_max_size);
+ min_size, max_size, probable_max_size,
+ TARGET_HAS_FAST_MEMPCPY_ROUTINE
+ && endp == 1,
+ _move_done);
+
+  /* Bail out when a mempcpy call would be expanded as libcall and when
+ we have a target that provides a fast implementation
+ of mempcpy routine.  */
+  if (!is_move_done)
+return NULL_RTX;
 
   if (dest_addr == 0)
 {
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index e43edd77b56..8744d706fd7 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -1914,6 +1914,9 @@ typedef struct ix86_args {
 
 #define CLEAR_RATIO(speed) ((speed) ? MIN (6, ix86_cost->move_ratio) : 2)
 
+/* C library provides fast implementation of mempcpy function.  */
+#define TARGET_HAS_FAST_MEMPCPY_ROUTINE 1
+
 /* Define if shifts truncate the shift count which implies one can
omit a sign-extension or zero-extension of a shift count.
 
diff --git a/gcc/defaults.h b/gcc/defaults.h
index 78a08a33f12..2e5caac8dcd 100644
--- a/gcc/defaults.h
+++ b/gcc/defaults.h
@@ -1340,6 +1340,13 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #define SET_RATIO(speed) MOVE_RATIO (speed)
 #endif
 
+/* By default do not generate libcall to mempcpy and rather use
+   libcall to memcpy and adjustment of return value.  */
+
+#ifndef TARGET_HAS_FAST_MEMPCPY_ROUTINE
+#define TARGET_HAS_FAST_MEMPCPY_ROUTINE 0
+#endif
+
 /* Supply a default definition of STACK_SAVEAREA_MODE for emit_stack_save.
Normally move_insn, so Pmode stack pointer.  */
 
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index bd8b917ba82..0c8a3f3298c 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -6627,6 +6627,11 @@ optimized for speed rather than size.
 If you don't define this, it defaults to the value of @code{MOVE_RATIO}.
 @end defmac
 
+@defmac TARGET_HAS_FAST_MEMPCPY_ROUTINE
+By default do not generate libcall to mempcpy and rather use
+libcall to memcpy and adjustment of return value.
+@end defmac
+
 @defmac USE_LOAD_POST_INCREMENT (@var{mode})
 A C expression used to determine whether a load postincrement is a good
 thing to use for a given mode.  Defaults to the value of
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index b0207146e8c..e7ef85ab78e 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -4560,6 +4560,11 @@ optimized for speed rather than size.
 If you don't define this, it defaults to the value of @code{MOVE_RATIO}.
 @end defmac
 
+@defmac TARGET_HAS_FAST_MEMPCPY_ROUTINE
+By default do not generate libcall to mempcpy and rather use
+libcall to memcpy and adjustment of return value.
+@end defmac
+
 @defmac USE_LOAD_POST_INCREMENT (@var{mode})
 A C expression used to determine whether a load postincrement is a good
 thing to use for a given mode.  Defaults to the value of
diff --git a/gcc/expr.c b/gcc/expr.c

[PATCH] Fix PTA info in IPA ICF (PR ipa/84658).

[Martin Liška]

Hi.

This is what I was recommended in 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658#c18.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin

gcc/ChangeLog:

2018-03-12  Martin Liska  

PR ipa/84658.
* ipa-icf.c (set_alias_uids): Remove.
(sem_variable::merge): Remove usage.
(sem_item_optimizer::sem_item_optimizer): Initialize new
vector.
(sem_item_optimizer::~sem_item_optimizer): Release it.
(sem_item_optimizer::merge_classes): Register variable aliases.
(sem_item_optimizer::fixup_pt_set): New function.
(sem_item_optimizer::fixup_points_to_sets): Likewise.
* ipa-icf.h: Declare new variables and functions.

gcc/testsuite/ChangeLog:

2018-03-12  Martin Liska  

PR ipa/84658.
* g++.dg/ipa/pr84658.C: New test.
---
 gcc/ipa-icf.c  | 88 +-
 gcc/ipa-icf.h  | 10 +
 gcc/testsuite/g++.dg/ipa/pr84658.C | 30 +
 3 files changed, 108 insertions(+), 20 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/ipa/pr84658.C


diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
index b9f2bf30744..4145e7e8440 100644
--- a/gcc/ipa-icf.c
+++ b/gcc/ipa-icf.c
@@ -2133,23 +2133,6 @@ sem_variable::get_hash (void)
   return m_hash;
 }
 
-/* Set all points-to UIDs of aliases pointing to node N as UID.  */
-
-static void
-set_alias_uids (symtab_node *n, int uid)
-{
-  ipa_ref *ref;
-  FOR_EACH_ALIAS (n, ref)
-{
-  if (dump_file)
-	fprintf (dump_file, "  Setting points-to UID of [%s] as %d\n",
-		 xstrdup_for_dump (ref->referring->asm_name ()), uid);
-
-  SET_DECL_PT_UID (ref->referring->decl, uid);
-  set_alias_uids (ref->referring, uid);
-}
-}
-
 /* Merges instance with an ALIAS_ITEM, where alias, thunk or redirection can
be applied.  */
 
@@ -2276,7 +2259,6 @@ sem_variable::merge (sem_item *alias_item)
   if (dump_file)
 	fprintf (dump_file, "Unified; Variable alias has been created.\n");
 
-  set_alias_uids (original, DECL_UID (original->decl));
   return true;
 }
 }
@@ -2296,7 +2278,7 @@ unsigned int sem_item_optimizer::class_id = 0;
 
 sem_item_optimizer::sem_item_optimizer ()
 : worklist (0), m_classes (0), m_classes_count (0), m_cgraph_node_hooks (NULL),
-  m_varpool_node_hooks (NULL)
+  m_varpool_node_hooks (NULL), m_merged_variables ()
 {
   m_items.create (0);
   bitmap_obstack_initialize (_bmstack);
@@ -2321,6 +2303,7 @@ sem_item_optimizer::~sem_item_optimizer ()
   m_items.release ();
 
   bitmap_obstack_release (_bmstack);
+  m_merged_variables.release ();
 }
 
 /* Write IPA ICF summary for symbols.  */
@@ -3572,13 +3555,78 @@ sem_item_optimizer::merge_classes (unsigned int prev_class_count)
 	  }
 
 	if (dbg_cnt (merged_ipa_icf))
-	  merged_p |= source->merge (alias);
+	  {
+		bool merged = source->merge (alias);
+		merged_p |= merged;
+
+		if (merged && alias->type == VAR)
+		  m_merged_variables.safe_push (std::pair
+		  (source->decl, alias->decl));
+	  }
 	  }
   }
 
+  if (!m_merged_variables.is_empty ())
+fixup_points_to_sets ();
+
   return merged_p;
 }
 
+/* Fixup points to set PT.  */
+
+void
+sem_item_optimizer::fixup_pt_set (struct pt_solution *pt)
+{
+  if (pt->vars == NULL)
+return;
+
+  unsigned i;
+  std::pair *item;
+  FOR_EACH_VEC_ELT (m_merged_variables, i, item)
+if (bitmap_bit_p (pt->vars, DECL_UID (item->second)))
+  bitmap_set_bit (pt->vars, DECL_UID (item->first));
+}
+
+/* Fixup points to analysis info.  */
+
+void
+sem_item_optimizer::fixup_points_to_sets (void)
+{
+  /* TODO: remove in GCC 9 and trigger PTA re-creation after IPA passes.  */
+
+  cgraph_node *cnode;
+  return;
+
+  FOR_EACH_DEFINED_FUNCTION (cnode)
+{
+  tree name;
+  unsigned i;
+  function *fn = DECL_STRUCT_FUNCTION (cnode->decl);
+  FOR_EACH_SSA_NAME (i, name, fn)
+	if (POINTER_TYPE_P (TREE_TYPE (name))
+	&& SSA_NAME_PTR_INFO (name))
+	  fixup_pt_set (_NAME_PTR_INFO (name)->pt);
+  fixup_pt_set (>gimple_df->escaped);
+
+   /* The above get's us to 99% I guess, at least catching the
+	  address compares.  Below also gets us aliasing correct
+	  but as said we're giving leeway to the situation with
+	  readonly vars anyway, so ... */
+   basic_block bb;
+   FOR_EACH_BB_FN (bb, DECL_STRUCT_FUNCTION (cnode->decl))
+	for (gimple_stmt_iterator gsi = gsi_start_bb (bb); !gsi_end_p (gsi);
+	 gsi_next ())
+	  {
+	gcall *call = dyn_cast (gsi_stmt (gsi));
+	if (call)
+	  {
+		fixup_pt_set (gimple_call_use_set (call));
+		fixup_pt_set (gimple_call_clobber_set (call));
+	  }
+	  }
+}
+}
+
 /* Dump function prints all class members to a FILE with an INDENT.  */
 
 void
diff --git a/gcc/ipa-icf.h b/gcc/ipa-icf.h
index e3dcde2b4d1..9ac4f37eb1f 100644
--- a/gcc/ipa-icf.h
+++ b/gcc/ipa-icf.h
@@ -563,6 +563,12