Re: [PATCH][vect]PR92347: Don't overwrite safelen for epilogues

[Richard Biener]

On Mon, 11 Nov 2019, Andre Vieira (lists) wrote:

> Hi,
> 
> After during my investigation into the first testcase in PR92347 I noticed
> that the ICE was arising because the vectorizer was under the assumption it
> knew how to vectorize the zp call for both the main and epilogues.  By the
> time it got to transform the epilogue vectorizable_simd_clone_call would fail,
> leading to the eventual ICE. The reason was because the main loop's safelen
> was set to MAX_INT at time of analysis, but 0 for the epilogue at the time of
> its transformation.  This was because we were copying the loop's safelen to
> the epilogue after vectorizing the main loop and we set safelen to 0 when we
> are done vectorizing.  This resulted in the epilogue always having safelen set
> to 0 at transformation time.
> 
> I believe its safe to assume that if the main loop can assume that it is safe
> to vectorize between 0 and safelen then so is the epilogue in this context.
> 
> Bootstrapped x86_64 and aarch64 and ran libgomp.
> 
> Is this OK for trunk? (If approved can someone commit on my behalf as I'll be
> away for two weeks?)

OK (and committed).

Richard.

> Cheers,
> Andre
> 
> gcc/ChangeLog:
> 2019-11-11  Andre Vieira  
> 
> * tree-vect-loop.c (vect_transform_loop): Don't overwrite epilogues
> safelen with 0.
> 
> gcc/testsuite/ChangeLog:
> 2019-11-11  Andre Vieira  
> 
> * gcc.dg/vect/pr92347.c: New test.
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: [PATCH] Sort debug counter names.

[Martin Liška]

On 11/11/19 3:20 PM, Richard Biener wrote:

On Mon, Nov 11, 2019 at 9:23 AM Martin Liška  wrote:


Hi.

The small patch is about sorting of debug counter
values.

Ready to be installed?


OK


Thanks,
Martin


Hi.

There's a small follow up where I enforce the sorting via a selftest.

Ready for trunk?
Thanks,
Martin
>From 18c70fd6cce1764ae7fa0860937b6f7360f4b78e Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 11 Nov 2019 20:37:57 +0100
Subject: [PATCH] Come up with selftests for dbgcnt.

gcc/ChangeLog:

2019-11-12  Martin Liska  

	* dbgcnt.c (test_sorted_dbg_counters): New.
	(dbgcnt_c_tests): Likewise.
	* selftest-run-tests.c (selftest::run_tests): Likewise.
	* selftest.h (dbgcnt_c_tests): Likewise.
---
 gcc/dbgcnt.c | 24 
 gcc/selftest-run-tests.c |  1 +
 gcc/selftest.h   |  1 +
 3 files changed, 26 insertions(+)

diff --git a/gcc/dbgcnt.c b/gcc/dbgcnt.c
index 711ecc23619..a77bcf50124 100644
--- a/gcc/dbgcnt.c
+++ b/gcc/dbgcnt.c
@@ -24,6 +24,7 @@ See dbgcnt.def for usage information.  */
 #include "coretypes.h"
 #include "diagnostic-core.h"
 #include "dumpfile.h"
+#include "selftest.h"
 
 #include "dbgcnt.h"
 
@@ -249,3 +250,26 @@ dbg_cnt_list_all_counters (void)
 }
   printf ("\n");
 }
+
+#if CHECKING_P
+
+namespace selftest {
+
+/* Selftests.  */
+
+static void
+test_sorted_dbg_counters ()
+{
+  for (unsigned i = 0; i < debug_counter_number_of_counters - 1; i++)
+ASSERT_LT (strcmp (map[i].name, map[i + 1].name), 0);
+}
+
+void
+dbgcnt_c_tests ()
+{
+  test_sorted_dbg_counters ();
+}
+
+} // namespace selftest
+
+#endif /* #if CHECKING_P */
diff --git a/gcc/selftest-run-tests.c b/gcc/selftest-run-tests.c
index 6ed7d82beeb..a35452caf48 100644
--- a/gcc/selftest-run-tests.c
+++ b/gcc/selftest-run-tests.c
@@ -108,6 +108,7 @@ selftest::run_tests ()
   store_merging_c_tests ();
   predict_c_tests ();
   simplify_rtx_c_tests ();
+  dbgcnt_c_tests ();
 
   /* Run any lang-specific selftests.  */
   lang_hooks.run_lang_selftests ();
diff --git a/gcc/selftest.h b/gcc/selftest.h
index 933c0aab539..cc7212317c3 100644
--- a/gcc/selftest.h
+++ b/gcc/selftest.h
@@ -254,6 +254,7 @@ extern void vec_c_tests ();
 extern void vec_perm_indices_c_tests ();
 extern void wide_int_cc_tests ();
 extern void opt_proposer_c_tests ();
+extern void dbgcnt_c_tests ();
 
 extern int num_passes;
 
-- 
2.24.0

Re: [PATCH] Enhance syntax of -fdbg-cnt.

[Martin Liška]

On 11/11/19 4:25 PM, Martin Liška wrote:


I'm going to test the patch.
Martin


There's one more version where I use more references to mitigate
indirection of 'counter' vectors.

Martin
>From e3b8b3edfed1b5ba320d0fe85686908c5c37c22a Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Fri, 8 Nov 2019 16:05:00 +0100
Subject: [PATCH] Enhance syntax of -fdbg-cnt.

gcc/ChangeLog:

2019-11-08  Martin Liska  

	* common.opt: Document change of -fdbg-cnt option.
	* dbgcnt.c (DEBUG_COUNTER): Remove.
	(dbg_cnt_is_enabled): Remove.
	(dbg_cnt): Work with new intervals.
	(dbg_cnt_set_limit_by_index): Set to new
	list of intervals.
	(dbg_cnt_set_limit_by_name): Likewise.
	(dbg_cnt_process_single_pair): Process new format.
	(dbg_cnt_process_opt): Likewise.
	(dbg_cnt_list_all_counters): Likewise.
	* doc/invoke.texi: Document change of -fdbg-cnt option.
	(cmp_tuples): New.

gcc/testsuite/ChangeLog:

2019-11-08  Martin Liska  

	* gcc.dg/ipa/ipa-icf-39.c: Update -fdbg-cnt to the new format.
	* gcc.dg/pr68766.c: Likewise.
---
 gcc/common.opt|   2 +-
 gcc/dbgcnt.c  | 170 --
 gcc/doc/invoke.texi   |  15 ++-
 gcc/testsuite/gcc.dg/ipa/ipa-icf-39.c |   3 +-
 gcc/testsuite/gcc.dg/pr68766.c|   1 -
 5 files changed, 117 insertions(+), 74 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index 12c0083964e..d4442565c73 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1198,7 +1198,7 @@ List all available debugging counters with their limits and counts.
 
 fdbg-cnt=
 Common RejectNegative Joined Var(common_deferred_options) Defer
--fdbg-cnt=[:]:[,:...]	Set the debug counter limit.
+-fdbg-cnt=[:-][:-:...][,:...]	Set the debug counter limit.
 
 fdebug-prefix-map=
 Common Joined RejectNegative Var(common_deferred_options) Defer
diff --git a/gcc/dbgcnt.c b/gcc/dbgcnt.c
index 15ffe115a4f..711ecc23619 100644
--- a/gcc/dbgcnt.c
+++ b/gcc/dbgcnt.c
@@ -40,24 +40,12 @@ static struct string2counter_map map[debug_counter_number_of_counters] =
 };
 #undef DEBUG_COUNTER
 
-#define DEBUG_COUNTER(a) UINT_MAX,
-static unsigned int limit_high[debug_counter_number_of_counters] =
-{
-#include "dbgcnt.def"
-};
-#undef DEBUG_COUNTER
+typedef std::pair limit_tuple;
 
-static unsigned int limit_low[debug_counter_number_of_counters];
+static auto_vec *limits[debug_counter_number_of_counters] = {NULL};
 
 static unsigned int count[debug_counter_number_of_counters];
 
-bool
-dbg_cnt_is_enabled (enum debug_counter index)
-{
-  unsigned v = count[index];
-  return v > limit_low[index] && v <= limit_high[index];
-}
-
 static void
 print_limit_reach (const char *counter, int limit, bool upper_p)
 {
@@ -72,47 +60,89 @@ print_limit_reach (const char *counter, int limit, bool upper_p)
 bool
 dbg_cnt (enum debug_counter index)
 {
-  count[index]++;
+  unsigned v = ++count[index];
+
+  if (limits[index] == NULL)
+return true;
+
+  auto_vec  = *limits[index];
+  if (intervals.is_empty ())
+return false;
 
-  /* Do not print the info for default lower limit.  */
-  if (count[index] == limit_low[index] && limit_low[index] > 0)
-print_limit_reach (map[index].name, limit_low[index], false);
-  else if (count[index] == limit_high[index])
-print_limit_reach (map[index].name, limit_high[index], true);
+  unsigned last = intervals.length () - 1;
+  unsigned int min = intervals[last].first;
+  unsigned int max = intervals[last].second;
 
-  return dbg_cnt_is_enabled (index);
+  if (v < min)
+return false;
+  else if (v == min)
+{
+  print_limit_reach (map[index].name, v, false);
+  if (min == max)
+	intervals.pop ();
+  return true;
+}
+  else if (v < max)
+return true;
+  else if (v == max)
+{
+  print_limit_reach (map[index].name, v, true);
+  intervals.pop ();
+  return true;
+}
+  else
+return false;
 }
 
-static void
-dbg_cnt_set_limit_by_index (enum debug_counter index, int low, int high)
-{
-  limit_low[index] = low;
-  limit_high[index] = high;
+/* Compare limit_tuple intervals by first item in descending order.  */
 
-  fprintf (stderr, "dbg_cnt '%s' set to %d-%d\n", map[index].name, low, high);
+static int
+cmp_tuples (const void *ptr1, const void *ptr2)
+{
+  const limit_tuple *p1 = (const limit_tuple *)ptr1;
+  const limit_tuple *p2 = (const limit_tuple *)ptr2;
+
+  if (p1->first < p2->first)
+return 1;
+  else if (p1->first > p2->first)
+return -1;
+  return 0;
 }
 
 static bool
-dbg_cnt_set_limit_by_name (const char *name, int low, int high)
+dbg_cnt_set_limit_by_index (enum debug_counter index, const char *name,
+			unsigned int low, unsigned int high)
 {
-  if (high < low)
-{
-  error ("%<-fdbg-cnt=%s:%d:%d%> has smaller upper limit than the lower",
-	 name, low, high);
-  return false;
-}
+  if (limits[index] == NULL)
+limits[index] = new auto_vec ();
+
+  auto_vec  = *(limits[index]);
+  intervals.safe_push (limit_tuple (low, high));
+  intervals.qsort 

Re: [PATCH] Avoid *ORDERED_EXPRs in the IL if !HONOR_NANS (PR target/92449)

[Richard Biener]

On Tue, 12 Nov 2019, Jakub Jelinek wrote:

> Hi!
> 
> The testcase from the PR ICEs on rs6000.  For __builtin_isunordered etc.
> the folding makes sure that there is no *ORDERED_EXPR etc. in the IL
> if !HONOR_NANS, but the complex multiplication can emit it when mixing
> -Ofast with -fno-cx-limited-range.
> The following patch makes sure we don't emit it even in that case.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK, but IMHO it is not a good idea to assert UNORDERED_EXPR cannot
appear with !HONOR_NANS, is it?

Richard.

> I'll defer the addition of the testcase and rs6000 changes to Segher.
> 
> 2019-11-11  Jakub Jelinek  
> 
>   PR target/92449
>   * tree-complex.c (expand_complex_multiplication): If !HONOR_NANS,
>   don't emit UNORDERED_EXPR guarded libcall.  Formatting fixes.
> 
> --- gcc/tree-complex.c.jj 2019-01-10 11:43:02.252577041 +0100
> +++ gcc/tree-complex.c2019-11-11 20:26:28.585315282 +0100
> @@ -1144,6 +1144,16 @@ expand_complex_multiplication (gimple_st
> return;
>   }
>  
> +   if (!HONOR_NANS (inner_type))
> + {
> +   /* If we are not worrying about NaNs expand to
> +  (ar*br - ai*bi) + i(ar*bi + br*ai) directly.  */
> +   expand_complex_multiplication_components (gsi, inner_type,
> + ar, ai, br, bi,
> + , );
> +   break;
> + }
> +
> /* Else, expand x = a * b into
>x = (ar*br - ai*bi) + i(ar*bi + br*ai);
>if (isunordered (__real__ x, __imag__ x))
> @@ -1151,7 +1161,7 @@ expand_complex_multiplication (gimple_st
>  
> tree tmpr, tmpi;
> expand_complex_multiplication_components (gsi, inner_type, ar, ai,
> -  br, bi, , );
> + br, bi, , );
>  
> gimple *check
>   = gimple_build_cond (UNORDERED_EXPR, tmpr, tmpi,
> @@ -1167,13 +1177,12 @@ expand_complex_multiplication (gimple_st
>   = insert_cond_bb (gsi_bb (*gsi), gsi_stmt (*gsi), check,
> profile_probability::very_unlikely ());
>  
> -
> gimple_stmt_iterator cond_bb_gsi = gsi_last_bb (cond_bb);
> gsi_insert_after (_bb_gsi, gimple_build_nop (), GSI_NEW_STMT);
>  
> tree libcall_res
>   = expand_complex_libcall (_bb_gsi, type, ar, ai, br,
> -bi, MULT_EXPR, false);
> +   bi, MULT_EXPR, false);
> tree cond_real = gimplify_build1 (_bb_gsi, REALPART_EXPR,
>   inner_type, libcall_res);
> tree cond_imag = gimplify_build1 (_bb_gsi, IMAGPART_EXPR,
> @@ -1190,20 +1199,18 @@ expand_complex_multiplication (gimple_st
> edge orig_to_join = find_edge (orig_bb, join_bb);
>  
> gphi *real_phi = create_phi_node (rr, gsi_bb (*gsi));
> -   add_phi_arg (real_phi, cond_real, cond_to_join,
> - UNKNOWN_LOCATION);
> +   add_phi_arg (real_phi, cond_real, cond_to_join, UNKNOWN_LOCATION);
> add_phi_arg (real_phi, tmpr, orig_to_join, UNKNOWN_LOCATION);
>  
> gphi *imag_phi = create_phi_node (ri, gsi_bb (*gsi));
> -   add_phi_arg (imag_phi, cond_imag, cond_to_join,
> - UNKNOWN_LOCATION);
> +   add_phi_arg (imag_phi, cond_imag, cond_to_join, UNKNOWN_LOCATION);
> add_phi_arg (imag_phi, tmpi, orig_to_join, UNKNOWN_LOCATION);
>   }
>else
>   /* If we are not worrying about NaNs expand to
> (ar*br - ai*bi) + i(ar*bi + br*ai) directly.  */
>   expand_complex_multiplication_components (gsi, inner_type, ar, ai,
> -   br, bi, , );
> +   br, bi, , );
>break;
>  
>  default:
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: [patch, fortran] Load scalar intent-in variables at the beginning of procedures

[Janne Blomqvist]

On Tue, Nov 12, 2019 at 12:53 AM Thomas König  wrote:
>
> Hi Janne,
>
> > Wouldn't it be even better to pass scalar intent(in) variables by
> > value? The obvious objection of course is ABI, but for procedures with
> > an explicit interface we're not following any particular ABI anyways?
>
> The problem with that is that we don't know when we compile a procedure
> if it will be called with an explicit interface or not.
>
> The user can always add an interface block for a stand-alone procedure.

Ah, of course. I should have said module procedures. Or even module
procedures without bind(C)?

That being said, I've seen examples where people have figured out the
symbol mangling and are calling module procedures directly from C, so
will breaking such code (even if not officially supported) be an
issue?


-- 
Janne Blomqvist

Re: [PATCH] Fix ICE in vrp on aarch64 (PR tree-optimization/92452)

[Richard Biener]

On Mon, 11 Nov 2019, Jakub Jelinek wrote:

> Hi!
> 
> The following testcase ICEs on aarch64-linux.  The problem is that maxbound
> is POLY_INT_CST, eltsize is INTEGER_CST, but int_const_binop for
> TRUNC_DIV_EXPR returns NULL_TREE as it can't simplify it to something
> usable and we later try to MINUS_EXPR the NULL_TREE.
> 
> Fixed thusly, tested using cross to aarch64-linux, bootstrapped/regtested on
> powerpc64le-linux, ok for trunk?

OK.

Richard.

> 2019-11-11  Jakub Jelinek  
> 
>   PR tree-optimization/92452
>   * tree-vrp.c (vrp_prop::check_array_ref): If TRUNC_DIV_EXPR folds
>   into NULL_TREE, set up_bound to NULL_TREE instead of computing
>   MINUS_EXPR on it.
> 
>   * c-c++-common/pr92452.c: New test.
> 
> --- gcc/tree-vrp.c.jj 2019-11-09 00:41:09.022921760 +0100
> +++ gcc/tree-vrp.c2019-11-11 17:03:36.844669691 +0100
> @@ -4150,8 +4150,11 @@ vrp_prop::check_array_ref (location_t lo
>  
> up_bound_p1 = int_const_binop (TRUNC_DIV_EXPR, maxbound, eltsize);
>  
> -   up_bound = int_const_binop (MINUS_EXPR, up_bound_p1,
> -   build_int_cst (ptrdiff_type_node, 1));
> +   if (up_bound_p1 != NULL_TREE)
> + up_bound = int_const_binop (MINUS_EXPR, up_bound_p1,
> + build_int_cst (ptrdiff_type_node, 1));
> +   else
> + up_bound = NULL_TREE;
>   }
>  }
>else
> --- gcc/testsuite/c-c++-common/pr92452.c.jj   2019-11-11 17:06:01.525495277 
> +0100
> +++ gcc/testsuite/c-c++-common/pr92452.c  2019-11-11 17:05:31.256950180 
> +0100
> @@ -0,0 +1,5 @@
> +/* PR tree-optimization/92452 */
> +/* { dg-do compile } */
> +/* { dg-options "-Os -Warray-bounds=1" } */
> +
> +#include "pr60101.c"
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: [PATCH] Bump minimum MPFR version to 3.1.0

[Janne Blomqvist]

On Tue, Nov 12, 2019 at 6:59 AM Jeff Law  wrote:
>
> On 11/10/19 4:05 AM, Janne Blomqvist wrote:
> > On Sun, Nov 10, 2019 at 11:43 AM Thomas Koenig  
> > wrote:
> >>
> >> Hi Janne,
> >>
> >>> Bump the minimum MPFR version to 3.1.0, released 2011-10-03. With this
> >>> requirement one can still build GCC with the operating system provided
> >>> MPFR on old but still supported operating systems like SLES 12 (MPFR
> >>> 3.1.2) or RHEL/CentOS 7.x (MPFR 3.1.1).
> >>>
> >>
> >> OK for trunk.
> >
> > Thanks, I'll take that as an Ok for the Fortran part. I believe I
> > still need an Ok by a global or build machinery reviewer for the
> > global and docs parts.
> Seems reasonable to me, particularly since 3.1.0 is covered by SLES 12
> and RHEL/CentOS 7.  Give others a couple day to object though.

Richard Biener already Ok'd it and I committed the patch yesterday.

-- 
Janne Blomqvist

[PATCH] Set AVX128_OPTIMAL for all avx targets.

[Hongtao Liu]

Hi:
  This patch is about to set X86_TUNE_AVX128_OPTIMAL as default for
all AVX target because we found there's still performance gap between
128-bit auto-vectorization and 256-bit auto-vectorization even with
epilog vectorized.
  The performance influence of setting avx128_optimal as default on
SPEC2017 with option `-march=native -funroll-loops -Ofast -flto" on
CLX is as bellow:

INT rate
500.perlbench_r -0.32%
502.gcc_r   -1.32%
505.mcf_r   -0.12%
520.omnetpp_r   -0.34%
523.xalancbmk_r -0.65%
525.x264_r  2.23%
531.deepsjeng_r 0.81%
541.leela_r -0.02%
548.exchange2_r 10.89%  --> big improvement
557.xz_r0.38%
geomean for intrate 1.10%

FP rate
503.bwaves_r1.41%
507.cactuBSSN_r -0.14%
508.namd_r  1.54%
510.parest_r-0.87%
511.povray_r0.28%
519.lbm_r   0.32%
521.wrf_r   -0.54%
526.blender_r   0.59%
527.cam4_r  -2.70%
538.imagick_r   3.92%
544.nab_r   0.59%
549.fotonik3d_r -5.44%  -> regression
554.roms_r  -2.34%
geomean for fprate  -0.28%

The 10% improvement of 548.exchange_r is because there is 9-layer
nested loop, and the loop count for innermost layer is small(enough
for 128-bit vectorization, but not for 256-bit vectorization).
Since loop count is not statically analyzed out, vectorizer will
choose 256-bit vectorization which would never never be triggered. The
vectorization of epilog will introduced some extra instructions,
normally it will bring back some performance, but since it's 9-layer
nested loop, costs of extra instructions will cover the gain.

The 5.44% regression of 549.fotonik3d_r is because 256-bit
vectorization is better than 128-bit vectorization. Generally when
enabling 256-bit or 512-bit vectorization, there will be instruction
clocksticks reduction also with frequency reduction. when frequency
reduction is less than instructions clocksticks reduction, long vector
width vectorization would be better than shorter one, otherwise the
opposite. The regression of 549.fotonik3d_r is due to this, similar
for 554.roms_r, 528.cam4_r, for those 3 benchmarks, 512-bit
vectorization is best.

Bootstrap and regression test on i386 is ok.
Ok for trunk?

Changelog
gcc/
* config/i386/i386-option.c (m_CORE_AVX): New macro.
* config/i386/x86-tune.def: Enable 128_optimal for avx and
replace m_SANDYBRIDGE | m_CORE_AVX2 with m_CORE_AVX.
* testsuite/gcc.target/i386/pr84413-1.c: Adjust testcase.
* testsuite/gcc.target/i386/pr84413-2.c: Ditto.
* testsuite/gcc.target/i386/pr84413-3.c: Ditto.
* testsuite/gcc.target/i386/pr70021.c: Ditto.
* testsuite/gcc.target/i386/pr90579.c: New test.


-- 
BR,
Hongtao
From a02d5c896600c4c80765f375d531c5412a778145 Mon Sep 17 00:00:00 2001
From: liuhongt 
Date: Wed, 6 Nov 2019 09:36:57 +0800
Subject: [PATCH] Enbale 128-bit auto-vectorization for avx

Performance impact test on CLX8280 with best perf option
-Ofast -march=native -funroll-loops -flto -mfpmath=sse.

INT rate
500.perlbench_r		-0.32%
502.gcc_r			-1.32%
505.mcf_r			-0.12%
520.omnetpp_r			-0.34%
523.xalancbmk_r		-0.65%
525.x264_r			2.23%
531.deepsjeng_r		0.81%
541.leela_r			-0.02%
548.exchange2_r		10.89%
557.xz_r			0.38%
geomean for intrate		1.10%

FP rate
503.bwaves_r			1.41%
507.cactuBSSN_r		-0.14%
508.namd_r			1.54%
510.parest_r			-0.87%
511.povray_r			0.28%
519.lbm_r			0.32%
521.wrf_r			-0.54%
526.blender_r			0.59%
527.cam4_r			-2.70%
538.imagick_r			3.92%
544.nab_r			0.59%
549.fotonik3d_r		-5.44%
554.roms_r			-2.34%
geomean for fprate		-0.28%

Changelog
gcc/
	* config/i386/i386-option.c (m_CORE_AVX): New macro.
	* config/i386/x86-tune.def: Enable 128_optimal for avx and
	replace m_SANDYBRIDGE | m_CORE_AVX2 with m_CORE_AVX.
	* testsuite/gcc.target/i386/pr84413-1.c: Adjust testcase.
	* testsuite/gcc.target/i386/pr84413-2.c: Ditto.
	* testsuite/gcc.target/i386/pr84413-3.c: Ditto.
	* testsuite/gcc.target/i386/pr70021.c: Ditto.
	* testsuite/gcc.target/i386/pr90579.c: New test.
---
 gcc/config/i386/i386-options.c|  1 +
 gcc/config/i386/x86-tune.def  | 24 +++
 gcc/testsuite/gcc.target/i386/pr70021.c   |  2 +-
 gcc/testsuite/gcc.target/i386/pr84413-1.c |  4 ++--
 gcc/testsuite/gcc.target/i386/pr84413-2.c |  4 ++--
 gcc/testsuite/gcc.target/i386/pr84413-3.c |  4 ++--
 gcc/testsuite/gcc.target/i386/pr90579.c   | 20 +++
 7 files changed, 40 insertions(+), 19 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr90579.c

diff --git 

Re: [PATCH] include size and offset in -Wstringop-overflow

[Jeff Law]

On 11/6/19 3:34 PM, Martin Sebor wrote:
> On 11/6/19 2:06 PM, Martin Sebor wrote:
>> On 11/6/19 1:39 PM, Jeff Law wrote:
>>> On 11/6/19 1:27 PM, Martin Sebor wrote:
 On 11/6/19 11:55 AM, Jeff Law wrote:
> On 11/6/19 11:00 AM, Martin Sebor wrote:
>> The -Wstringop-overflow warnings for single-byte and multi-byte
>> stores mention the amount of data being stored and the amount of
>> space remaining in the destination, such as:
>>
>> warning: writing 4 bytes into a region of size 0 [-Wstringop-overflow=]
>>
>> 123 |   *p = 0;
>> |   ~~~^~~
>> note: destination object declared here
>>  45 |   char b[N];
>> |^
>>
>> A warning like this can take some time to analyze.  First, the size
>> of the destination isn't mentioned and may not be easy to tell from
>> the sources.  In the note above, when N's value is the result of
>> some non-trivial computation, chasing it down may be a small project
>> in and of itself.  Second, it's also not clear why the region size
>> is zero.  It could be because the offset is exactly N, or because
>> it's negative, or because it's in some range greater than N.
>>
>> Mentioning both the size of the destination object and the offset
>> makes the existing messages clearer, are will become essential when
>> GCC starts diagnosing overflow into allocated buffers (as my
>> follow-on patch does).
>>
>> The attached patch enhances -Wstringop-overflow to do this by
>> letting compute_objsize return the offset to its caller, doing
>> something similar in get_stridx, and adding a new function to
>> the strlen pass to issue this enhanced warning (eventually, I'd
>> like the function to replace the -Wstringop-overflow handler in
>> builtins.c).  With the change, the note above might read something
>> like:
>>
>> note: at offset 11 to object ‘b’ with size 8 declared here
>>  45 |   char b[N];
>> |^
>>
>> Tested on x86_64-linux.
>>
>> Martin
>>
>> gcc-store-offset.diff
>>
>> gcc/ChangeLog:
>>
>>  * builtins.c (compute_objsize): Add an argument and set it to
>> offset
>>  into destination.
>>  * builtins.h (compute_objsize): Add an argument.
>>  * tree-object-size.c (addr_object_size): Add an argument and
>> set it
>>  to offset into destination.
>>  (compute_builtin_object_size): Same.
>>  * tree-object-size.h (compute_builtin_object_size): Add an
>> argument.
>>  * tree-ssa-strlen.c (get_addr_stridx): Add an argument and
>> set it
>>  to offset into destination.
>>  (maybe_warn_overflow): New function.
>>  (handle_store): Call maybe_warn_overflow to issue warnings.
>>
>> gcc/testsuite/ChangeLog:
>>
>>  * c-c++-common/Wstringop-overflow-2.c: Adjust text of expected
>> messages.
>>  * g++.dg/warn/Wstringop-overflow-3.C: Same.
>>  * gcc.dg/Wstringop-overflow-17.c: Same.
>>
>
>> Index: gcc/tree-ssa-strlen.c
>> ===
>> --- gcc/tree-ssa-strlen.c    (revision 277886)
>> +++ gcc/tree-ssa-strlen.c    (working copy)
>> @@ -189,6 +189,52 @@ struct laststmt_struct
>>    static int get_stridx_plus_constant (strinfo *, unsigned
>> HOST_WIDE_INT, tree);
>>    static void handle_builtin_stxncpy (built_in_function,
>> gimple_stmt_iterator *);
>>    +/* Sets MINMAX to either the constant value or the range VAL
>> is in
>> +   and returns true on success.  */
>> +
>> +static bool
>> +get_range (tree val, wide_int minmax[2], const vr_values *rvals =
>> NULL)
>> +{
>> +  if (tree_fits_uhwi_p (val))
>> +    {
>> +  minmax[0] = minmax[1] = wi::to_wide (val);
>> +  return true;
>> +    }
>> +
>> +  if (TREE_CODE (val) != SSA_NAME)
>> +    return false;
>> +
>> +  if (rvals)
>> +    {
>> +  gimple *def = SSA_NAME_DEF_STMT (val);
>> +  if (gimple_assign_single_p (def)
>> +  && gimple_assign_rhs_code (def) == INTEGER_CST)
>> +    {
>> +  /* get_value_range returns [0, N] for constant
>> assignments.  */
>> +  val = gimple_assign_rhs1 (def);
>> +  minmax[0] = minmax[1] = wi::to_wide (val);
>> +  return true;
>> +    }
> Umm, something seems really off with this hunk.  If the SSA_NAME is
> set
> via a simple constant assignment, then the range ought to be a
> singleton
> ie [CONST,CONST].   Is there are particular test were this is not
> true?
>
> The only way offhand I could see this happening is if originally
> the RHS
> wasn't a constant, but due to optimizations it either simplified
> into a
> constant or a constant was propagated into an 

Re: [PATCH] Enable libsanitizer build on riscv64

[Jim Wilson]

On Mon, Nov 11, 2019 at 3:45 AM Andreas Schwab  wrote:
> Only ubsan is supported so far.  This has been tested on openSUSE
> Tumbleweed, there are no testsuite failures.
>
> * configure.tgt (riscv64-*-linux*): Enable build.

I tried this on my riscv64 Fedora system, and I get a build error.

In file included from
../../../../gcc-git/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:167:
../../../../gcc-git/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:342:72:
error: narrowing conversion of ‘-1’ from ‘int’ to ‘long unsigned int’
[-Wnarrowing]
  342 | typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
  |^
...
../../../../gcc-git/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:1136:1:
note: in expansion of macro ‘CHECK_SIZE_AND_OFFSET’
 1136 | CHECK_SIZE_AND_OFFSET(ipc_perm, mode);
  | ^

It appears that the problem is that my system defines the icp_perm
mode field as __mode_t whereas the sanitizer assumes it will be
unsigned short, followed by an unsigned short pad field.  I haven't
looked at the full history yet, but there were apparently similar
problems with the aarch64 port, so maybe we need some special code for
riscv to make this work?  I don't know why it worked for you.  Maybe a
different glibc or kernel version?

Incidentally, the
libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h file
has an obvious problem in the struct __sanitizer_ipc_perm definition,
because it has an ifdef for __aarch64__ inside an ifdef for __sparc__,
and there is no way the __aarch64__ test can ever succeed there.
There is a second __aarch64__ test a little farther down that looks
OK.  Maybe a patch merge error?

Jim

Re: [PATCH] include size and offset in -Wstringop-overflow

[Jeff Law]

On 11/6/19 2:06 PM, Martin Sebor wrote:
> On 11/6/19 1:39 PM, Jeff Law wrote:
>> On 11/6/19 1:27 PM, Martin Sebor wrote:
>>> On 11/6/19 11:55 AM, Jeff Law wrote:
 On 11/6/19 11:00 AM, Martin Sebor wrote:
> The -Wstringop-overflow warnings for single-byte and multi-byte
> stores mention the amount of data being stored and the amount of
> space remaining in the destination, such as:
>
> warning: writing 4 bytes into a region of size 0 [-Wstringop-overflow=]
>
> 123 |   *p = 0;
> |   ~~~^~~
> note: destination object declared here
>  45 |   char b[N];
> |^
>
> A warning like this can take some time to analyze.  First, the size
> of the destination isn't mentioned and may not be easy to tell from
> the sources.  In the note above, when N's value is the result of
> some non-trivial computation, chasing it down may be a small project
> in and of itself.  Second, it's also not clear why the region size
> is zero.  It could be because the offset is exactly N, or because
> it's negative, or because it's in some range greater than N.
>
> Mentioning both the size of the destination object and the offset
> makes the existing messages clearer, are will become essential when
> GCC starts diagnosing overflow into allocated buffers (as my
> follow-on patch does).
>
> The attached patch enhances -Wstringop-overflow to do this by
> letting compute_objsize return the offset to its caller, doing
> something similar in get_stridx, and adding a new function to
> the strlen pass to issue this enhanced warning (eventually, I'd
> like the function to replace the -Wstringop-overflow handler in
> builtins.c).  With the change, the note above might read something
> like:
>
> note: at offset 11 to object ‘b’ with size 8 declared here
>  45 |   char b[N];
> |^
>
> Tested on x86_64-linux.
>
> Martin
>
> gcc-store-offset.diff
>
> gcc/ChangeLog:
>
>  * builtins.c (compute_objsize): Add an argument and set it to
> offset
>  into destination.
>  * builtins.h (compute_objsize): Add an argument.
>  * tree-object-size.c (addr_object_size): Add an argument and
> set it
>  to offset into destination.
>  (compute_builtin_object_size): Same.
>  * tree-object-size.h (compute_builtin_object_size): Add an
> argument.
>  * tree-ssa-strlen.c (get_addr_stridx): Add an argument and set it
>  to offset into destination.
>  (maybe_warn_overflow): New function.
>  (handle_store): Call maybe_warn_overflow to issue warnings.
>
> gcc/testsuite/ChangeLog:
>
>  * c-c++-common/Wstringop-overflow-2.c: Adjust text of expected
> messages.
>  * g++.dg/warn/Wstringop-overflow-3.C: Same.
>  * gcc.dg/Wstringop-overflow-17.c: Same.
>

> Index: gcc/tree-ssa-strlen.c
> ===
> --- gcc/tree-ssa-strlen.c    (revision 277886)
> +++ gcc/tree-ssa-strlen.c    (working copy)
> @@ -189,6 +189,52 @@ struct laststmt_struct
>    static int get_stridx_plus_constant (strinfo *, unsigned
> HOST_WIDE_INT, tree);
>    static void handle_builtin_stxncpy (built_in_function,
> gimple_stmt_iterator *);
>    +/* Sets MINMAX to either the constant value or the range VAL is in
> +   and returns true on success.  */
> +
> +static bool
> +get_range (tree val, wide_int minmax[2], const vr_values *rvals =
> NULL)
> +{
> +  if (tree_fits_uhwi_p (val))
> +    {
> +  minmax[0] = minmax[1] = wi::to_wide (val);
> +  return true;
> +    }
> +
> +  if (TREE_CODE (val) != SSA_NAME)
> +    return false;
> +
> +  if (rvals)
> +    {
> +  gimple *def = SSA_NAME_DEF_STMT (val);
> +  if (gimple_assign_single_p (def)
> +  && gimple_assign_rhs_code (def) == INTEGER_CST)
> +    {
> +  /* get_value_range returns [0, N] for constant assignments.  */
> +  val = gimple_assign_rhs1 (def);
> +  minmax[0] = minmax[1] = wi::to_wide (val);
> +  return true;
> +    }
 Umm, something seems really off with this hunk.  If the SSA_NAME is set
 via a simple constant assignment, then the range ought to be a
 singleton
 ie [CONST,CONST].   Is there are particular test were this is not true?

 The only way offhand I could see this happening is if originally the
 RHS
 wasn't a constant, but due to optimizations it either simplified into a
 constant or a constant was propagated into an SSA_NAME appearing on the
 RHS.  This would have to happen between the last range analysis and the
 point where you're making this query.
>>>
>>> Yes, I think that's right.  Here's an example 

Re: [PATCH] Bump minimum MPFR version to 3.1.0

[Jeff Law]

On 11/10/19 4:05 AM, Janne Blomqvist wrote:
> On Sun, Nov 10, 2019 at 11:43 AM Thomas Koenig  wrote:
>>
>> Hi Janne,
>>
>>> Bump the minimum MPFR version to 3.1.0, released 2011-10-03. With this
>>> requirement one can still build GCC with the operating system provided
>>> MPFR on old but still supported operating systems like SLES 12 (MPFR
>>> 3.1.2) or RHEL/CentOS 7.x (MPFR 3.1.1).
>>>
>>
>> OK for trunk.
> 
> Thanks, I'll take that as an Ok for the Fortran part. I believe I
> still need an Ok by a global or build machinery reviewer for the
> global and docs parts.
Seems reasonable to me, particularly since 3.1.0 is covered by SLES 12
and RHEL/CentOS 7.  Give others a couple day to object though.

jeff

Re: [C++ PATCH] Implement P1946R0 - Allow defaulting comparisons by value

[Jason Merrill]

On 11/11/19 8:07 AM, Jakub Jelinek wrote:

Hi!

 From 
https://www.reddit.com/r/cpp/comments/dtuov8/201911_belfast_iso_c_committee_trip_report/
I understood P1946R0 made it into C++20, so here is my attempt at
implementing it, you had most of it implemented anyway because
in system headers
 friend constexpr bool
 operator==(partial_ordering, partial_ordering) noexcept = default;
etc. has been already accepted.


And I implemented it the rest of the way at the meeting, I just hadn't 
committed it yet.  Thanks for the additional tests, though.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 0cbd94b2731032f1e0ec0a576f7b59cbcfded735
Author: Jason Merrill 
Date:   Fri Nov 8 21:57:44 2019 +

Implement P1946R0, Allow defaulting comparisons by value.

* method.c (early_check_defaulted_comparison): Accept by-value,
reject mixed by-value and by-reference parms.
* decl.c (grokdeclarator): Set funcdef_flag for defaulted friend.
* decl2.c (grokfield): Don't SET_DECL_FRIEND_CONTEXT.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index caa04afe805..86e38f4af69 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -13202,6 +13202,11 @@ grokdeclarator (const cp_declarator *declarator,
 	  ;  /* We already issued a permerror.  */
 	else if (decl && DECL_NAME (decl))
 	  {
+		if (initialized)
+		  /* Kludge: We need funcdef_flag to be true in do_friend for
+		 in-class defaulted functions, but that breaks grokfndecl.
+		 So set it here.  */
+		  funcdef_flag = true;
 		if (template_class_depth (current_class_type) == 0)
 		  {
 		decl = check_explicit_specialization
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 4f0b2161db1..f164494afdc 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -927,10 +927,6 @@ grokfield (const cp_declarator *declarator,
 	}
 	  else if (init == ridpointers[(int)RID_DEFAULT])
 	{
-	  if (friendp)
-		/* ??? do_friend doesn't set this because funcdef_flag is false
-		   for in-class defaulted functions.  So set it here.  */
-		SET_DECL_FRIEND_CONTEXT (value, current_class_type);
 	  if (defaultable_fn_check (value))
 		{
 		  DECL_DEFAULTED_FN (value) = 1;
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 47441c10c52..acba6c6da8c 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1094,38 +1094,54 @@ early_check_defaulted_comparison (tree fn)
   if (!DECL_OVERLOADED_OPERATOR_IS (fn, SPACESHIP_EXPR)
   && !same_type_p (TREE_TYPE (TREE_TYPE (fn)), boolean_type_node))
 {
-  error_at (loc, "defaulted %qD must return %", fn);
-  ok = false;
+  diagnostic_t kind = DK_UNSPECIFIED;
+  int opt = 0;
+  if (is_auto (TREE_TYPE (fn)))
+	kind = DK_PEDWARN;
+  else
+	kind = DK_ERROR;
+  emit_diagnostic (kind, loc, opt,
+		   "defaulted %qD must return %", fn);
+  if (kind == DK_ERROR)
+	ok = false;
 }
 
-  int i = DECL_NONSTATIC_MEMBER_FUNCTION_P (fn);
-  if (i && type_memfn_quals (TREE_TYPE (fn)) != TYPE_QUAL_CONST)
+  bool mem = DECL_NONSTATIC_MEMBER_FUNCTION_P (fn);
+  if (mem && type_memfn_quals (TREE_TYPE (fn)) != TYPE_QUAL_CONST)
 {
   error_at (loc, "defaulted %qD must be %", fn);
   ok = false;
 }
   tree parmnode = FUNCTION_FIRST_USER_PARMTYPE (fn);
+  bool saw_byval = false;
+  bool saw_byref = mem;
+  bool saw_bad = false;
   for (; parmnode != void_list_node; parmnode = TREE_CHAIN (parmnode))
 {
-  ++i;
   tree parmtype = TREE_VALUE (parmnode);
-  diagnostic_t kind = DK_UNSPECIFIED;
-  int opt = 0;
   if (same_type_p (parmtype, ctx))
-	/* The draft specifies const reference, but let's also allow by-value
-	   unless -Wpedantic, hopefully it will be added soon. */
-	kind = DK_PEDWARN,
-	  opt = OPT_Wpedantic;
+	saw_byval = true;
   else if (TREE_CODE (parmtype) != REFERENCE_TYPE
 	   || TYPE_QUALS (TREE_TYPE (parmtype)) != TYPE_QUAL_CONST
 	   || !(same_type_ignoring_top_level_qualifiers_p
 		(TREE_TYPE (parmtype), ctx)))
-	kind = DK_ERROR;
-  if (kind)
-	emit_diagnostic (kind, loc, opt, "defaulted %qD must have "
-			 "parameter type %", fn, ctx);
-  if (kind == DK_ERROR)
-	ok = false;
+	saw_bad = true;
+  else
+	saw_byref = true;
+}
+
+  if (saw_bad || (saw_byval && saw_byref))
+{
+  if (DECL_NONSTATIC_MEMBER_FUNCTION_P (fn))
+	error_at (loc, "defaulted member %qD must have parameter type "
+		  "%", fn, ctx);
+  else if (saw_bad)
+	error_at (loc, "defaulted %qD must have parameters of either type "
+		  "% or %qT", fn, ctx, ctx);
+  else
+	error_at (loc, "defaulted %qD must have parameters of either type "
+		  "% or %qT, not both", fn, ctx, ctx);
+  ok = false;
 }
 
   /* We still need to deduce deleted/constexpr/noexcept and maybe return. */
diff --git a/gcc/testsuite/g++.dg/cpp2a/spaceship-synth-neg1.C b/gcc/testsuite/g++.dg/cpp2a/spaceship-synth-neg1.C
new file mode 100644
index 000..f9b2dc449e2
--- /dev/null
+++ 

[C++ PATCH] Sorry about <=> on VECTOR_TYPE.

[Jason Merrill]

I'm not sure what semantics we might eventually want for vector <=>, but let's
give a sorry for now.

Tested x86_64-pc-linux-gnu, applying to trunk.

---
 gcc/cp/typeck.c |  7 +++
 gcc/testsuite/g++.dg/cpp2a/spaceship-vec1.C | 11 +++
 2 files changed, 18 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/spaceship-vec1.C

diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 124d16a31fb..ff603f3d8d9 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -5224,6 +5224,13 @@ cp_build_binary_op (const op_location_t ,
  "types %qT and %qT", type0, type1);
}
 
+ if (resultcode == SPACESHIP_EXPR)
+   {
+ if (complain & tf_error)
+   sorry_at (location, "three-way comparison of vectors");
+ return error_mark_node;
+   }
+
  /* Always construct signed integer vector type.  */
  intt = c_common_type_for_size
(GET_MODE_BITSIZE (SCALAR_TYPE_MODE (TREE_TYPE (type0))), 0);
diff --git a/gcc/testsuite/g++.dg/cpp2a/spaceship-vec1.C 
b/gcc/testsuite/g++.dg/cpp2a/spaceship-vec1.C
new file mode 100644
index 000..83547691118
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/spaceship-vec1.C
@@ -0,0 +1,11 @@
+// { dg-do compile { target c++2a } }
+
+#include 
+
+#define vector __attribute__((vector_size(4*sizeof(int)) ))
+
+int main()
+{
+  vector int a, b;
+  a <=> b;  // { dg-message "three-way comparison of vector" }
+}

base-commit: f15dc29a9734e360497f5bb40be6b25dcbc11645
-- 
2.18.1

[PATCH] track dynamic allocation in strlen (PR 91582)

[Martin Sebor]

The attached patch extends the strlen pass to detect out-of-bounds
accesses to memory allocated by calls to other allocation functions
besides calloc and malloc, as well as VLAs, and user-defined
functions declared with attribute alloc_size.  There is some
overlap with the _FORTIFY_SOURCE detection but thanks to
the extensive use of ranges, this enhancement detects many more
cases of overflow.

The solution primarily improves warnings but some of the changes
also improve codegen in some cases as a side-effect.  I hope to
take better advantage of the optimization opportunities the dynamic
memory tracking opens up (and also better buffer overflow and array
out-of-bounds detection) in GCC 11.

Although the strlen pass already tracks some dynamic memory calls
(calloc and malloc) rather than extending the same infrastructure
(strinfo::stmt) to others I took the approach of adding a separate
data member for the other calls (strinfo::alloc) and tracking those
independently.  I did this to keep the changes only minimally
intrusive.  In the future (post GCC 10) it might be worth
considering merging both.

Besides introducing the new member and making use of it, the rest
of the changes were prompted by weaknesses exposed by test cases
involving dynamically allocated objects.

The patch is intended to apply on top of the two related patches
posted last week ([1] and [2]).  For all tests to pass also expects
the fix for PR 92412 posted earlier today ([3]).

Martin

[1] https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00429.html
[2] https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00652.html
[3] https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00800.html
PR middle-end/91582 - missing heap overflow detection for strcpy

gcc/ChangeLog:

	PR middle-end/91582
	* builtins.c (gimple_call_alloc_size): Add argument.
	* builtins.h (gimple_call_alloc_size): Same.
	* tree-object-size.c (compute_builtin_object_size): Clear argument.
	* tree-ssa-strlen.c (strinfo::alloc): New member.
	(get_addr_stridx): Add argument.
	(get_stridx): Use ptrdiff_t.  Add argument.
	(new_strinfo): Set new member.
	(get_string_length): Handle alloca and VLA.
	(dump_strlen_info): Dump more state.
	(maybe_invalidate): Print more info.  Decrease indentation.
	(unshare_strinfo): Set new member.
	(valid_builtin_call): Handle alloca and VLA.
	(maybe_warn_overflow): Check and set no-warning bit.  Improve
	handling of offsets.  Print allocated objects.
	(handle_builtin_strlen): Handle strinfo records with null lengths.
	(handle_builtin_strcpy): Call maybe_warn_overflow.
	(is_strlen_related_p): Handle dynamically allocated objects.
	(get_range): Add argument.
	(handle_builtin_malloc): Rename...
	(handle_aalloc): ...to this and handle all allocation functions.
	(handle_builtin_memset): Call maybe_warn_overflow.
	(count_nonzero_bytes): Handle more MEM_REF forms.
	(strlen_check_and_optimize_call): Call handle_alloc_call.  Pass
	arguments to more callees.
	(handle_integral_assign): Add argument.  Create strinfo entries
	for MEM_REF assignments.
	(check_and_optimize_stmt): Handle more MEM_REF forms.

gcc/testsuite/ChangeLog:

	PR middle-end/91582
	* c-c++-common/Wrestrict.c: Adjust expected warnings.
	* g++.dg/warn/Wstringop-overflow-3.C: Adjust text of expected messages.
	* gcc.dg/Warray-bounds-46.c: Disable -Wstringop-overflow.
	* gcc.dg/Warray-bounds-47.c: Same.
	* gcc.dg/Warray-bounds-52.c: New test.
	* gcc.dg/Warray-bounds-56.c: New test.
	* gcc.dg/Wstringop-overflow-23.c: New test.
	* gcc.dg/Wstringop-overflow-24.c: New test.
	* gcc.dg/Wstringop-overflow-25.c: New test.
	* gcc.dg/attr-alloc_size.c (test): Disable -Warray-bounds.
	* gcc.dg/attr-copy-2.c: Adjust expected warnings.
	* gcc.dg/builtin-stringop-chk-5.c: Adjust text of expected messages.
	* gcc.dg/strlenopt-86.c: Relax test.
	* gcc.dg/strlenopt-91.c: New test.
	* gcc.dg/strlenopt-92.c: New test.
	* gcc.target/i386/pr82002-1.c: Prune expected warnings.
	* gcc.target/i386/pr82002-2a.c: Same.
	* gcc.target/i386/pr82002-2b.c: Same.

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 8565fd007e5..ed7bdffa2b2 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -3565,10 +3565,11 @@ check_access (tree exp, tree, tree, tree dstwrite,
 }
 
 /* If STMT is a call to an allocation function, returns the size
-   of the object allocated by the call.  */
+   of the object allocated by the call.  If nonnull, set RNG1[]
+   to the range of the size.  */
 
 tree
-gimple_call_alloc_size (gimple *stmt)
+gimple_call_alloc_size (gimple *stmt, wide_int rng1[2] /* = NULL */)
 {
   if (!stmt)
 return NULL_TREE;
@@ -3615,7 +3616,11 @@ gimple_call_alloc_size (gimple *stmt)
 
   tree size = gimple_call_arg (stmt, argidx1);
 
-  wide_int rng1[2];
+  wide_int rng1_buf[2];
+  /* If RNG1 is not set, use the buffer.  */
+  if (!rng1)
+rng1 = rng1_buf;
+
   if (!get_range (size, rng1))
 return NULL_TREE;
 
@@ -3641,7 +3646,10 @@ gimple_call_alloc_size (gimple *stmt)
   rng1[1] = rng1[1] * rng2[1];
   tree size_max = TYPE_MAX_VALUE 

Re: [patch, fortran] PR92123 - [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in pro

[Vipul Parekh]

On Sun, Nov 3, 2019 at 1:37 PM Paul Richard Thomas
 wrote:
>
> The attached patch is verging on the obvious. Thanks to Tobias for
> spotting Vipul's messages on the J3 list.
>
> Regtests on FC30/x86_64 - OK for trunk and 9-branch?
>
> Paul

Paul,

Thanks for your follow-up on this issue.  Would you be interested in
taking a look at the problem I run into with gfortran with CFI_address
function?  See this link at the new GitHub site for Fortran proposals:
https://github.com/j3-fortran/fortran_proposals/issues/57#issuecomment-552680503

Thanks and Best Regards,
Vipul Parekh

C++ PATCH for c++/88337 - P1327R1: Allow polymorphic typeid in constexpr

[Marek Polacek]

Part of P1327R1 is to allow typeid with an operand of polymorphic type in
constexpr.  I found that we pretty much support it already, the only tweak
was to allow TYPEID_EXPR (only created in a template) in constexpr in C++20.

I also noticed this in build_typeid:
  /* FIXME when integrating with c_fully_fold, mark
 resolves_to_fixed_type_p case as a non-constant expression.  */
  if (TYPE_POLYMORPHIC_P (TREE_TYPE (exp))
  && ! resolves_to_fixed_type_p (exp, )
  && ! nonnull)
but I'm not quite sure what to do with it.

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

2019-11-11  Marek Polacek  

PR c++/88337 - P1327R1: Allow polymorphic typeid in constexpr.
* constexpr.c (potential_constant_expression_1): Allow a typeid
expression whose operand is of polymorphic type in constexpr in
C++20.

* g++.dg/cpp2a/constexpr-typeid1.C: New test.
* g++.dg/cpp2a/constexpr-typeid2.C: New test.
* g++.dg/cpp2a/constexpr-typeid3.C: New test.
* g++.dg/cpp2a/constexpr-typeid4.C: New test.

diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index 20fddc57825..430c65694b7 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -7018,11 +7018,13 @@ potential_constant_expression_1 (tree t, bool 
want_rval, bool strict, bool now,
   return false;
 
 case TYPEID_EXPR:
-  /* -- a typeid expression whose operand is of polymorphic
-class type;  */
+  /* In C++20, a typeid expression whose operand is of polymorphic
+class type can be constexpr.  */
   {
 tree e = TREE_OPERAND (t, 0);
-if (!TYPE_P (e) && !type_dependent_expression_p (e)
+   if (cxx_dialect < cxx2a
+   && !TYPE_P (e)
+   && !type_dependent_expression_p (e)
&& TYPE_POLYMORPHIC_P (TREE_TYPE (e)))
   {
 if (flags & tf_error)
diff --git gcc/testsuite/g++.dg/cpp2a/constexpr-typeid1.C 
gcc/testsuite/g++.dg/cpp2a/constexpr-typeid1.C
new file mode 100644
index 000..a81f649b44b
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/constexpr-typeid1.C
@@ -0,0 +1,47 @@
+// PR c++/88337 - Implement P1327R1: Allow dynamic_cast/typeid in constexpr.
+// { dg-do compile { target c++2a } }
+// Test non-polymorphic type.
+
+#include 
+
+struct B {
+  const std::type_info  = typeid (*this);
+};
+
+struct D : B { };
+
+constexpr B b;
+constexpr D d;
+
+static_assert ( ==  (B));
+static_assert ({}.ti ==  (B));
+static_assert (().ti ==  (B));
+static_assert ( ((B())) ==  (B));
+static_assert ( ((B{})) ==  (B));
+
+static_assert ( ==  (B));
+static_assert ({}.ti ==  (B));
+static_assert (().ti ==  (B));
+static_assert ( ((D())) ==  (D));
+static_assert ( ((D{})) ==  (D));
+
+extern D ed;
+static_assert ( (ed) ==  (D));
+
+constexpr const B  = d;
+static_assert ( (r) ==  (B));
+
+constexpr bool
+test ()
+{
+  // If expression is not a glvalue expression of polymorphic type,
+  // typeid does not evaluate the expression
+  bool ok = true;
+  (void) typeid (ok = false, D());
+  (void) typeid (ok = false, B());
+  (void) typeid (ok = false, b);
+  (void) typeid (ok = false, d);
+  return ok;
+}
+
+static_assert (test ());
diff --git gcc/testsuite/g++.dg/cpp2a/constexpr-typeid2.C 
gcc/testsuite/g++.dg/cpp2a/constexpr-typeid2.C
new file mode 100644
index 000..51c8fb451b8
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/constexpr-typeid2.C
@@ -0,0 +1,60 @@
+// PR c++/88337 - Implement P1327R1: Allow dynamic_cast/typeid in constexpr.
+// { dg-do compile { target c++2a } }
+// Test polymorphic type.
+
+#include 
+
+struct B {
+  virtual void foo ();
+  const std::type_info _base = typeid (*this);
+};
+
+struct D : B {
+  const std::type_info  = typeid (*this);
+};
+
+constexpr B b;
+constexpr D d;
+
+static_assert (_base ==  (B));
+static_assert ({}.ti_base ==  (B));
+static_assert (().ti_base ==  (B));
+static_assert ( ((B())) ==  (B));
+static_assert ( ((B{})) ==  (B));
+
+static_assert ( ==  (D));
+static_assert ({}.ti ==  (D));
+static_assert (().ti ==  (D));
+static_assert ( ((D())) ==  (D));
+static_assert ( ((D{})) ==  (D));
+
+extern D ed;
+// ??? Should this succeed?
+static_assert ( (ed) ==  (D));
+
+constexpr const B  = d;
+static_assert ( (r) ==  (D));
+
+constexpr bool
+test ()
+{
+  // If expression is a glvalue expression that identifies an object
+  // of a polymorphic type, the typeid expression evaluates the expression.
+  bool ok = true;
+  // Not a glvalue.
+  (void) typeid (ok = false, D());
+  (void) typeid (ok = false, B());
+  if (!ok)
+return false;
+
+  // Polymorphic glvalue -- this needs to be evaluated.
+  ok = false;
+  (void) typeid (ok = true, b);
+  if (!ok)
+return false;
+  ok = false;
+  (void) typeid (ok = true, d);
+  return ok;
+}
+
+static_assert (test ());
diff --git gcc/testsuite/g++.dg/cpp2a/constexpr-typeid3.C 
gcc/testsuite/g++.dg/cpp2a/constexpr-typeid3.C
new file mode 100644
index 000..38b9e609a9f
--- /dev/null
+++ 

[PATCH] Avoid *ORDERED_EXPRs in the IL if !HONOR_NANS (PR target/92449)

[Jakub Jelinek]

Hi!

The testcase from the PR ICEs on rs6000.  For __builtin_isunordered etc.
the folding makes sure that there is no *ORDERED_EXPR etc. in the IL
if !HONOR_NANS, but the complex multiplication can emit it when mixing
-Ofast with -fno-cx-limited-range.
The following patch makes sure we don't emit it even in that case.

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

I'll defer the addition of the testcase and rs6000 changes to Segher.

2019-11-11  Jakub Jelinek  

PR target/92449
* tree-complex.c (expand_complex_multiplication): If !HONOR_NANS,
don't emit UNORDERED_EXPR guarded libcall.  Formatting fixes.

--- gcc/tree-complex.c.jj   2019-01-10 11:43:02.252577041 +0100
+++ gcc/tree-complex.c  2019-11-11 20:26:28.585315282 +0100
@@ -1144,6 +1144,16 @@ expand_complex_multiplication (gimple_st
  return;
}
 
+ if (!HONOR_NANS (inner_type))
+   {
+ /* If we are not worrying about NaNs expand to
+(ar*br - ai*bi) + i(ar*bi + br*ai) directly.  */
+ expand_complex_multiplication_components (gsi, inner_type,
+   ar, ai, br, bi,
+   , );
+ break;
+   }
+
  /* Else, expand x = a * b into
 x = (ar*br - ai*bi) + i(ar*bi + br*ai);
 if (isunordered (__real__ x, __imag__ x))
@@ -1151,7 +1161,7 @@ expand_complex_multiplication (gimple_st
 
  tree tmpr, tmpi;
  expand_complex_multiplication_components (gsi, inner_type, ar, ai,
-br, bi, , );
+   br, bi, , );
 
  gimple *check
= gimple_build_cond (UNORDERED_EXPR, tmpr, tmpi,
@@ -1167,13 +1177,12 @@ expand_complex_multiplication (gimple_st
= insert_cond_bb (gsi_bb (*gsi), gsi_stmt (*gsi), check,
  profile_probability::very_unlikely ());
 
-
  gimple_stmt_iterator cond_bb_gsi = gsi_last_bb (cond_bb);
  gsi_insert_after (_bb_gsi, gimple_build_nop (), GSI_NEW_STMT);
 
  tree libcall_res
= expand_complex_libcall (_bb_gsi, type, ar, ai, br,
-  bi, MULT_EXPR, false);
+ bi, MULT_EXPR, false);
  tree cond_real = gimplify_build1 (_bb_gsi, REALPART_EXPR,
inner_type, libcall_res);
  tree cond_imag = gimplify_build1 (_bb_gsi, IMAGPART_EXPR,
@@ -1190,20 +1199,18 @@ expand_complex_multiplication (gimple_st
  edge orig_to_join = find_edge (orig_bb, join_bb);
 
  gphi *real_phi = create_phi_node (rr, gsi_bb (*gsi));
- add_phi_arg (real_phi, cond_real, cond_to_join,
-   UNKNOWN_LOCATION);
+ add_phi_arg (real_phi, cond_real, cond_to_join, UNKNOWN_LOCATION);
  add_phi_arg (real_phi, tmpr, orig_to_join, UNKNOWN_LOCATION);
 
  gphi *imag_phi = create_phi_node (ri, gsi_bb (*gsi));
- add_phi_arg (imag_phi, cond_imag, cond_to_join,
-   UNKNOWN_LOCATION);
+ add_phi_arg (imag_phi, cond_imag, cond_to_join, UNKNOWN_LOCATION);
  add_phi_arg (imag_phi, tmpi, orig_to_join, UNKNOWN_LOCATION);
}
   else
/* If we are not worrying about NaNs expand to
  (ar*br - ai*bi) + i(ar*bi + br*ai) directly.  */
expand_complex_multiplication_components (gsi, inner_type, ar, ai,
- br, bi, , );
+ br, bi, , );
   break;
 
 default:

Jakub

[C++ PATCH] Fix concepts vs. PCH (PR c++/92458)

[Jakub Jelinek]

Hi!

PCH remaps object addresses, so hash tables that use pointer hashing
don't work well across PCH, because the hash values can change and without
rehashing the hash tbales values might not be found.

The following patch fixes it by using DECL_UID as hash function instead,
which is stable across PCH save/restore.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2019-11-11  Jakub Jelinek  

PR c++/92458
* constraint.cc: Include tree-hash-traits.h.
(decl_tree_cache_traits): New type.
(decl_tree_cache_map): New typedef.
(decl_constraints): Change type to decl_tree_cache_map *
from tree_cache_map *.

* g++.dg/pch/pr92458.C: New test.
* g++.dg/pch/pr92458.Hs: New test.

--- gcc/cp/constraint.cc.jj 2019-11-07 09:50:51.755239234 +0100
+++ gcc/cp/constraint.cc2019-11-11 19:04:03.231862024 +0100
@@ -45,6 +45,7 @@ along with GCC; see the file COPYING3.
 #include "decl.h"
 #include "toplev.h"
 #include "type-utils.h"
+#include "tree-hash-traits.h"
 
 static tree satisfaction_value (tree t);
 
@@ -1113,7 +1114,10 @@ build_constraints (tree tr, tree dr)
 
 /* A mapping from declarations to constraint information.  */
 
-static GTY ((cache)) tree_cache_map *decl_constraints;
+struct decl_tree_cache_traits
+  : simple_cache_map_traits { };
+typedef hash_map decl_tree_cache_map;
+static GTY ((cache)) decl_tree_cache_map *decl_constraints;
 
 /* Returns the template constraints of declaration T. If T is not
constrained, return NULL_TREE. Note that T must be non-null. */
--- gcc/testsuite/g++.dg/pch/pr92458.C.jj   2019-11-11 19:09:51.547614022 
+0100
+++ gcc/testsuite/g++.dg/pch/pr92458.C  2019-11-11 19:12:39.164088578 +0100
@@ -0,0 +1,5 @@
+// PR c++/92458
+// { dg-options "-std=c++2a" }
+
+#include "pr92458.H"
+S s;
--- gcc/testsuite/g++.dg/pch/pr92458.Hs.jj  2019-11-11 19:09:25.091012637 
+0100
+++ gcc/testsuite/g++.dg/pch/pr92458.Hs 2019-11-11 19:12:47.626961060 +0100
@@ -0,0 +1,7 @@
+// PR c++/92458
+// { dg-options "-std=c++2a" }
+
+template concept C = sizeof(T) > 1;
+template struct S { };
+template requires C struct S { };
+template requires (!C) struct S { };

Jakub

Ping: [PATCH] Fix multibyte-related issues in pretty-print.c (PR 91843)

[Lewis Hyatt]

Hello-

Would it be appropriate to ping this patch at this point? It would be
great if someone can review it please, it's relatively short and it
fixes one of the two noticeable issues with extended identifier
diagnostics. Thanks very much!

https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00766.html

-Lewis

On Thu, Oct 10, 2019 at 4:27 PM Lewis Hyatt  wrote:
>
> Hello-
>
> This short patch addresses https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91843
> by adding the needed multibyte awareness to pretty-print.c.
> Together with my other patch awaiting review
> (https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01627.html), this fixes all
> issues that I am aware of regarding printing diagnostics with multibyte
> characters in UTF-8 locales. Would you please have a look and see if it's OK?
> Thanks very much.
>
> bootstrapped and tested on x86-64 Linux, all test results were identical 
> before
> and after:
> 34 XPASS
> 109 FAIL
> 1490 XFAIL
> 9470 UNSUPPORTED
> 332971 PASS
>
> -Lewis

Re: [golang-dev] [PATCH] libgo/test: Add flags to find libgcc_s in build-tree testing

[Ian Lance Taylor]

[ moving from golang-dev to gofrontend-dev ]

On Mon, Nov 11, 2019 at 7:48 AM Maciej W. Rozycki  wrote:
>
> Add a setting for the dynamic loader to find the shared libgcc_s library
> in build-tree testing, fixing a catastrophic libgo testsuite failure in
> cross-compilation where the library cannot be found by the loader at run
> time and consequently no test case executes, producing output (here with
> the `x86_64-linux-gnu' host and the `riscv64-linux-gnu' target, with
> RISC-V QEMU in the Linux user emulation mode as the target board) like:
>
> spawn qemu-riscv64 -E 
> LD_LIBRARY_PATH=.:.../riscv64-linux-gnu/lib64/lp64d/libgo/.libs ./a.exe
> ./a.exe: error while loading shared libraries: libgcc_s.so.1: cannot open 
> shared object file: No such file or directory
> FAIL: archive/tar
>
> Use the `ld_library_path' TCL variable to propagate the setting obtained
> from where GCC finds the library at link time, making test output look
> like:
>
> spawn qemu-riscv64 -E 
> LD_LIBRARY_PATH=.:..././gcc/lib64/lp64d:.../riscv64-linux-gnu/lib64/lp64d/libgo/.libs
>  ./a.exe
> PASS
> PASS: archive/tar
>
> No summary comparison, because the libgo testsuite does not provide one
> in this configuration for some reason, however this change improves
> overall results from 0 PASSes and 159 FAILs to 133 PASSes and 26 FAILs.
>
> gcc/testsuite/
> * lib/go.exp (go_link_flags): Add `ld_library_path' setting to
> find shared `libgcc_s' library at run time in build-tree
> testing.

Is there similar code for other languages, such as Fortran?  I don't
see why Go would be different here.



>  Regression-tested with `make check-go' with the `x86_64-linux-gnu' native
> system as well as the `x86_64-linux-gnu' host and the `riscv64-linux-gnu'
> target, with RISC-V QEMU in the Linux user emulation mode as the target
> board.
>
>  NB as a heads-up numerous tests fail quietly (i.e. with no FAIL report
> and no name of the test case given either) to link due to unsatisfied
> symbol references, such as:
>
> .../bin/riscv64-linux-gnu-ld: _gotest_.o: in function 
> `cmd..z2fgo..z2finternal..z2fcache.Cache.get':
> .../riscv64-linux-gnu/libgo/gotest24771/test/cache.go:182: undefined 
> reference to `cmd..z2fgo..z2finternal..z2frenameio.ReadFile'
>
> which I take is due to a reference to `libgotool.a' -- which is where the
> required symbols are defined -- missing from the linker invocation.  I
> don't know what's supposed to supply the library to the linker or whether
> this indeed the actual cause; I find the way libgo tests have been wired
> unusual and consequently hard to follow, so maybe someone more familiar
> with this stuff will be able to tell what is going on here.  I'll be happy
> to push any patches through testing.

(That is, of course, a libgo test failure, and as such is not affected
by your patch to go.exp.)

In normal usage, that test is linked against libgotool.a because of
the variable extra_check_libs_cmd_go_internal_cache in
libgo/Makefile.am.  That variable is added to GOLIBS in the CHECK
variable in libgo/Makefile.am.  Maybe the fix is for
libgo/testsuite/lib/libgo.exp to use GOLIBS.

Ian

Re: [golang-dev] [PATCH 3/4] libgo/test: Fix compilation for build sysroot

[Ian Lance Taylor]

On Mon, Nov 11, 2019 at 10:12 AM Maciej W. Rozycki  wrote:
>
> Fix a problem with the libgo testsuite using a method to determine the
> compiler to use resulting in the tool being different from one the
> library has been built with, and causing a catastrophic failure from the
> lack of a suitable `--sysroot=' option where the `--with-build-sysroot='
> configuration option has been used to build the compiler resulting in
> the inability to link executables.
>
> Address this problem by providing a DejaGNU configuration file defining
> the compiler to use, via the GOC_UNDER_TEST TCL variable, set from $GOC
> by autoconf, which will have all the required options set for the target
> compiler to build executables in the environment configured, removing
> failures like:
>
> .../bin/riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory
> .../bin/riscv64-linux-gnu-ld: cannot find -lm
> .../bin/riscv64-linux-gnu-ld: cannot find -lc
> collect2: error: ld returned 1 exit status
> compiler exited with status 1
>
> No summary comparison, because the libgo testsuite does not provide one
> in this configuration for some reason, however this change improves
> overall test results for the `riscv64-linux-gnu' target (here with the
> `x86_64-linux-gnu' host and RISC-V QEMU in the Linux user emulation mode
> as the target board) from 0 PASSes and 159 FAILs to 133 PASSes and 26
> FAILs.
>
> libgo/
> * configure.ac: Add testsuite/libgo-test-support.exp to output
> files.
> * configure: Regenerate.
> * testsuite/libgo-test-support.exp.in: New file.
> * testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New
> variable.
> * testsuite/Makefile.in: Regenerate.
> * testsuite/lib/libgo.exp: Don't override GOC_UNDER_TEST
> previously set.

Thanks.

Committed to mainline.

Ian

Re: [golang-dev] [PATCH 0/4] Fix library testsuite compilation for build sysroot

[Ian Lance Taylor]

On Mon, Nov 11, 2019 at 10:44 AM Maciej W. Rozycki  wrote:
>
> On Mon, 11 Nov 2019, Ian Lance Taylor wrote:
>
> > > Go's project doesn't take mail patches for changes. Please use gerrit ( 
> > > https://go-review.googlesource.com/ ).
> >
> > These patches are for gccgo, not the gc toolchain.  They should
> > probably have been sent to gofrontend-dev rather than golang-dev.  The
> > gccgo repo does take patches via e-mail; I route them through Gerrit
> > as needed.
>
>  I may have misinterpreted this paragraph[1]:
>
> "Submitting Changes
>
>Changes to the Go frontend should follow the same process as for the
>main Go repository, only for the gofrontend project and the
>gofrontend-...@googlegroups.com mailing list rather than the go project
>and the golang-...@googlegroups.com mailing list. Those changes will
>then be merged into the GCC sources."
>
> Sorry about that; I think it might benefit from a rewrite for clarity
> though.
>
> References:
>
> [1] "Contributing to the gccgo frontend - The Go Programming Language",
> 


The paragraph seems reasonable clear to me, so I'm obviously missing
something.  Can you suggest a clearer rewrite?  Thanks.

Ian

Re: [PATCH] V6, #4 of 17: Add prefixed instruction support to stack protect insns

[Michael Meissner]

On Fri, Nov 01, 2019 at 10:22:03PM -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Wed, Oct 16, 2019 at 09:47:41AM -0400, Michael Meissner wrote:
> > This patch fixes the stack protection insns to support stacks larger than
> > 16-bits on the 'future' system using prefixed loads and stores.
> 
> > +;; We can't use the prefixed attribute here because there are two memory
> > +;; instructions.  We can't split the insn due to the fact that this 
> > operation
> > +;; needs to be done in one piece.
> >  (define_insn "stack_protect_setdi"
> >[(set (match_operand:DI 0 "memory_operand" "=Y")
> > (unspec:DI [(match_operand:DI 1 "memory_operand" "Y")] UNSPEC_SP_SET))
> > (set (match_scratch:DI 2 "=") (const_int 0))]
> >"TARGET_64BIT"
> > -  "ld%U1%X1 %2,%1\;std%U0%X0 %2,%0\;li %2,0"
> > +{
> > +  if (prefixed_memory (operands[1], DImode))
> > +output_asm_insn ("pld %2,%1", operands);
> > +  else
> > +output_asm_insn ("ld%U1%X1 %2,%1", operands);
> > +
> > +  if (prefixed_memory (operands[0], DImode))
> > +output_asm_insn ("pstd %2,%0", operands);
> > +  else
> > +output_asm_insn ("std%U0%X0 %2,%0", operands);
> 
> We could make %pN mean 'p' for prefixed, for memory as operands[N]?  Are
> there more places than this that could use that?  How about inline asm?

At the moment, I did not add this.  We can revisit it later.

> > +   (set (attr "length")
> > +   (cond [(and (match_operand 0 "prefixed_memory")
> > +   (match_operand 1 "prefixed_memory"))
> > +  (const_string "24")
> > +
> > +  (ior (match_operand 0 "prefixed_memory")
> > +   (match_operand 1 "prefixed_memory"))
> > +  (const_string "20")]
> > +
> > + (const_string "12")))])
> 
> You can use const_int instead of const_string here, I think?  Please do
> that if it works.
> 
> Quite a simple expression, phew :-)

Const_int works.

> > +  if (which_alternative == 0)
> > +output_asm_insn ("xor. %3,%3,%4", operands);
> > +  else
> > +output_asm_insn ("cmpld %0,%3,%4\;li %3,0", operands);
> 
> That doesn't work: the backslash is treated like the escape character, in
> a C block.  I think doubling it will work?  Check the generated insn-output.c,
> it should be translated to \t\n in there.
> 
> Okay for trunk with those things taken care of.  Thanks!

As we discussed, this does work.

Here is the patch committed.  I did a bootstrap and did make check.  There were
no regressions.

2019-11-11  Michael Meissner  

* config/rs6000/predicates.md (prefixed_memory): New predicate.
* config/rs6000/rs6000.md (stack_protect_setdi): Deal with either
address being a prefixed load/store.
(stack_protect_testdi): Deal with either address being a prefixed
load.

Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 278062)
+++ gcc/config/rs6000/predicates.md (working copy)
@@ -1828,3 +1828,10 @@ (define_predicate "pcrel_external_addres
 (define_predicate "pcrel_local_or_external_address"
   (ior (match_operand 0 "pcrel_local_address")
(match_operand 0 "pcrel_external_address")))
+
+;; Return true if the operand is a memory address that uses a prefixed address.
+(define_predicate "prefixed_memory"
+  (match_code "mem")
+{
+  return address_is_prefixed (XEXP (op, 0), mode, NON_PREFIXED_DEFAULT);
+})
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 278062)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -11536,14 +11536,44 @@ (define_insn "stack_protect_setsi"
   [(set_attr "type" "three")
(set_attr "length" "12")])
 
+;; We can't use the prefixed attribute here because there are two memory
+;; instructions.  We can't split the insn due to the fact that this operation
+;; needs to be done in one piece.
 (define_insn "stack_protect_setdi"
   [(set (match_operand:DI 0 "memory_operand" "=Y")
(unspec:DI [(match_operand:DI 1 "memory_operand" "Y")] UNSPEC_SP_SET))
(set (match_scratch:DI 2 "=") (const_int 0))]
   "TARGET_64BIT"
-  "ld%U1%X1 %2,%1\;std%U0%X0 %2,%0\;li %2,0"
+{
+  if (prefixed_memory (operands[1], DImode))
+output_asm_insn ("pld %2,%1", operands);
+  else
+output_asm_insn ("ld%U1%X1 %2,%1", operands);
+
+  if (prefixed_memory (operands[0], DImode))
+output_asm_insn ("pstd %2,%0", operands);
+  else
+output_asm_insn ("std%U0%X0 %2,%0", operands);
+
+  return "li %2,0";
+}
   [(set_attr "type" "three")
-   (set_attr "length" "12")])
+
+  ;; Back to back prefixed memory instructions take 20 bytes (8 bytes for each
+  ;; prefixed instruction + 4 bytes for the possible NOP).  Add in 4 bytes for
+  ;; the LI 0 at the end.
+   (set_attr "prefixed" "no")
+   (set_attr "num_insns" "3")
+   (set (attr "length")
+   (cond [(and (match_operand 0 "prefixed_memory")
+   (match_operand 1 

Re: [patch, fortran] Load scalar intent-in variables at the beginning of procedures

[Thomas König]

Hi Janne,


Wouldn't it be even better to pass scalar intent(in) variables by
value? The obvious objection of course is ABI, but for procedures with
an explicit interface we're not following any particular ABI anyways?


The problem with that is that we don't know when we compile a procedure
if it will be called with an explicit interface or not.

The user can always add an interface block for a stand-alone procedure.

Regards

Thomas

Re: [patch, fortran] Load scalar intent-in variables at the beginning of procedures

[Janne Blomqvist]

On Mon, Nov 11, 2019 at 11:56 PM Thomas König  wrote:
>
> Hello world,
>
> the attached patch loads scalar INTENT(IN) variables to a local
> variable at the start of a procedure, as suggested in PR 67202, in
> order to aid optimization.  This is controlled by front-end
> optimization so it is easier to catch if any bugs should turn up :-)
>
> This is done to make optimization by the middle-end easier.
>
> I left in the parts for debugging that I added for this patch.
> Seeing the difference between EXEC_INIT_ASSIGN and EXEC_ASSIGN was
> particularly instructive.
>
> Regression-tested. OK for trunk?

Wouldn't it be even better to pass scalar intent(in) variables by
value? The obvious objection of course is ABI, but for procedures with
an explicit interface we're not following any particular ABI anyways?


-- 
Janne Blomqvist

[PATCH] errno can't alias locals (PR 92412)

[Martin Sebor]

The conditional in default_ref_may_alias_errno has the function
return true even for local variables, implying that locals must
be assumed not to have been changed across calls to errno-setting
functions like malloc.  This leads to both worse code and also
false negatives in the strlen pass' detection of buffer overflow
across such calls.

The attached patch constrains the conditional to only consider
external declarations.

Tested on x86_64-linux.

Martin
PR tree-optimization/92412 - excessive errno aliasing assumption defeats optimization

gcc/ChangeLog:

	PR tree-optimization/92412
	* targhooks.c (default_ref_may_alias_errno): Errono can only alias
	extern variables.

gcc/testsuite/ChangeLog:

	PR tree-optimization/92412
	* gcc.dg/strlenopt-91.c: New test.

Index: gcc/targhooks.c
===
--- gcc/targhooks.c	(revision 278066)
+++ gcc/targhooks.c	(working copy)
@@ -1415,9 +1415,11 @@ default_ref_may_alias_errno (ao_ref *ref)
   if (TYPE_UNSIGNED (TREE_TYPE (base))
   || TYPE_MODE (TREE_TYPE (base)) != TYPE_MODE (integer_type_node))
 return false;
-  /* The default implementation assumes an errno location
- declaration is never defined in the current compilation unit.  */
+  /* The default implementation assumes an errno location declaration
+ is never defined in the current compilation unit and may not be
+ aliased by a local variable.  */
   if (DECL_P (base)
+  && DECL_EXTERNAL (base)
   && !TREE_STATIC (base))
 return true;
   else if (TREE_CODE (base) == MEM_REF
Index: gcc/testsuite/gcc.dg/strlenopt-91.c
===
--- gcc/testsuite/gcc.dg/strlenopt-91.c	(nonexistent)
+++ gcc/testsuite/gcc.dg/strlenopt-91.c	(working copy)
@@ -0,0 +1,124 @@
+/* PR tree-optimization/92412 - excessive errno aliasing assumption defeats
+   optimization
+   { dg-do compile }
+   { dg-options "-O1 -Wall -fdump-tree-optimized" } */
+
+typedef __SIZE_TYPE__ size_t;
+
+extern void* alloca (size_t);
+extern void* calloc (size_t, size_t);
+extern void* malloc (size_t);
+
+extern const char exta[4];
+static char stata[] = "123";
+
+void sink (const void*, ...);
+
+#define T(ptr, alloc) do {		\
+const char *p = ptr;		\
+if (p[0] != '1' || p[1] != '2' || p[2] != '3' || p[3] != '\0'	\
+	|| __builtin_strlen (p) != 3)	\
+  return;\
+	\
+void *q = alloc;			\
+__builtin_strcpy (q, p);		\
+	\
+if (p[0] != '1' || p[1] != '2' || p[2] != '3' || p[3] != '\0'	\
+	|| __builtin_strlen (p) != 3	\
+	|| __builtin_strlen (q) != 3)	\
+  __builtin_abort ();		\
+	\
+sink (p, q);			\
+  } while (0)
+
+
+void alloca_test_local (unsigned n)
+{
+  char loca[] = "123";
+  T (loca, alloca (n));
+}
+
+void alloca_test_extern_const (unsigned n)
+{
+  T (exta, alloca (n));
+}
+
+void alloca_test_static (unsigned n)
+{
+  T (stata, alloca (n));
+}
+
+
+// Verify fix for PR tree-optimization/92412.
+void calloc_test_local (unsigned m, unsigned n)
+{
+  char loca[] = "123";
+  T (loca, calloc (m, n));
+}
+
+void calloc_test_extern_const (unsigned m, unsigned n)
+{
+  T (exta, calloc (m, n));
+}
+
+void calloc_test_static (unsigned m, unsigned n)
+{
+  T (stata, calloc (m, n));
+}
+
+
+// Verify fix for PR tree-optimization/92412.
+void malloc_test_local (unsigned n)
+{
+  char loca[] = "123";
+  T (loca, malloc (n));
+}
+
+void malloc_test_extern_const (unsigned n)
+{
+  T (exta, malloc (n));
+}
+
+void malloc_test_static (unsigned n)
+{
+  T (stata, malloc (n));
+}
+
+
+#undef T
+#define T(ptr, n) do {			\
+const char *p = ptr;		\
+if (p[0] != '1' || p[1] != '2' || p[2] != '3' || p[3] != '\0'	\
+	|| __builtin_strlen (p) != 3)	\
+  return;\
+	\
+char vla[n];			\
+char *q = vla;			\
+__builtin_strcpy (q, p);		\
+	\
+if (p[0] != '1' || p[1] != '2' || p[2] != '3' || p[3] != '\0'	\
+	|| __builtin_strlen (p) != 3	\
+	|| __builtin_strlen (q) != 3)	\
+  __builtin_abort ();		\
+	\
+sink (p, vla);			\
+  } while (0)
+
+
+void vla_test_local (unsigned n)
+{
+  char loca[] = "123";
+  T (loca, n);
+}
+
+void vla_test_extern_const (unsigned n)
+{
+  T (exta, n);
+}
+
+void vla_test_static (unsigned n)
+{
+  T (stata, n);
+}
+
+/* { dg-final { scan-tree-dump-not "abort" "optimized" } } */

Re: [Patch, RFC] PR81651/Fortran - Enhancement request: have f951 print out fully qualified module file name

[Janne Blomqvist]

On Mon, Nov 11, 2019 at 11:54 PM Harald Anlauf  wrote:
>
> Dear all,
>
> the attached patch prints the fully qualified path if an error occurs
> during module read.  E.g., instead of a less helpful error message,
>
> pr81651.f90:2:6:
>
> 2 |   use netcdf
>   |  1
> Fatal Error: File 'netcdf.mod' opened at (1) is not a GNU Fortran module
> file
>
> gfortran will print
>
> pr81651.f90:2:7:
>
> 2 |   use netcdf
>   |   1
> Fatal Error: File '/opt/pgi/pkg/netcdf/include/netcdf.mod' opened at (1)
> is not a GNU Fortran module file
>
> Regtested on x86_64-pc-linux-gnu.
>
> I couldn't think of a sensible test for the testsuite, thus no testcase
> provided.
>
> OK for trunk?
>
> Thanks,
> Harald
>
> 2019-11-11  Harald Anlauf  
>
> PR fortran/81651
> * module.c (gzopen_included_file, gzopen_included_file_1)
> (gzopen_intrinsic_module, bad_module, gfc_use_module): Use fully
> qualified module path for error reporting.

Ok.


-- 
Janne Blomqvist

Re: [RFC] Only warn for maybe-uninitialized SRAed bits in -Wextra (PR 80635)

[Martin Jambor]

Hi,

On Mon, Nov 11 2019, Martin Sebor wrote:
> On 11/11/19 10:29 AM, Martin Jambor wrote:
>> On Mon, Nov 11 2019, Martin Sebor wrote:
>>> On 11/8/19 5:41 AM, Martin Jambor wrote:
 Hi,

 this patch is an attempt to implement my idea from a previous thread
 about moving -Wmaybe-uninitialized to -Wextra:

 https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00220.html

 Specifically, it attempts to split -Wmaybe-uninitialized into those that
 are about SRA DECLs and those which are not, and move to -Wextra only
 the former ones.  The main idea is that false -Wmaybe-uninitialized
 warings about values that are scalar in user's code are easy to silence
 by initializing them to zero or something, as opposed to bits of
 aggregates such as a value in std::optional which are not.  Therefore,
 the warnings about user-scalars can remain in -Wall but warnings about
 SRAed pieces should be moved to -Wextra.


...

 +This option enables the same warning like @option{-Wmaybe-uninitialized} 
 but
 +for parts of aggregates (i.g.@: structures, arrays or unions) that GCC
 +optimizers can track.  These warnings are only possible in optimizing
 +compilation, because otherwise GCC does not keep track of the state of
 +variables.  This warning is enabled by @option{-Wextra}.
 +
>>>
>>> Let me ask a question.  Suppose I have code like this:
>>>
>>> struct S { char a[4], b[4]; };
>>>
>>> void* g (void)
>>> {
>>>   struct S *p = malloc (sizeof *p);
>>>   strcpy (p->a + 1, p->b + 1);
>>>   return p;
>>> }
>>>
>>> (I include the offsets only because they make an interesting
>>> difference in the internal representation.  My question is
>>> the same even without them.)
>>>
>>> With this new warning, would the appropriate diagnostic to
>>> issue be -Wmaybe-uninitialized-aggregates or -Wuninitialized?
>> 
>> The patch should not change the behavior of -Wuninitialized so that if
>> an uninitialized value use is detected on a spot which is always
>> executed, a warning should be emitted regardless if the underpinning
>> DECL is a result of SRA or not - the user should fix their code, not
>> silence a spurious warning because it is not spurious.
>> 
>> It's the tricky maybe-uninitialized cases where I wanted to mitigate a
>> common source of false positives which are difficult to silence.
>
> Understood.
>
>> 
>> As far as the strcpy example is concerned, ideally it would be emitted
>> as part of both -Wuninitialized and -Wmaybe-uninitialized-aggregates
>> depending on whether it is a maybe warning or not, but not with only
>> -Wmaybe-uninitialized.
>
> I see.  This makes sense for the simple example above.
>
>> 
>>>
>>> The description makes it sound like the former but I'm not
>>> sure that's what I would want, either as an implementer of
>>> the uninitialized strcpy warning (I plan to add one) or as
>>> its user.
>> 
>> What are the problems for the user?  I think that the distinction
>> between maybe uninitialized and always uninitialized is genuinely useful
>> one.  And as an implementor of a new similar warning, don't you need to
>> distinguish between them even now?
>
> Yes, the distinction between the "maybe" and "definitely" kinds
> of warnings is useful and (IMO) clear, and not my concern. (Sorry,
> I think my example may not have been as helpful as I wanted it to
> be.)
>
> To be useful, the I think the distinction between -Wmaybe-
> uninitialized and -Wmaybe-uninitialized-aggregates will need
> to be made also very clear.  But I'm not sure that it will be
> possible.  In the strcpy example, the GIMPLE looks like this:
>
>_1 =   [(void *)p_5 + 5B];
>_2 =   [(void *)p_5 + 1B];
>strcpy (_2, _1);
>
> i.e., it's clear the accesses are to distinct parts of the same
> object, but it's not not necessarily as clear whether they are
> to distinct subobjects of the same aggregate.

In my simple world, anything that is not an outright scalar is an
aggregate (well, naked complex numbers and vectors are perhaps in the
grey area).  I would say that once you look at MEM_REF, it is an
aggregate.

>
> It becomes even less clear if one or both offsets are non-constant
> (but in a known range), or when only parts of the larger objects
> are initialized (e.g., just some members, or some initial bytes
> of a chunk of memory allocated by malloc as often happens with
> string functions).  It's also unclear when the access involves
> a PHI node some of whose operands are aggregates and the others
> are not.
>
> I haven't had time to think about it very hard but it seems that
> the answer in each of these cases might come down to a judgment
> call.  That will blur the distinction between the two and make
> the new warning option less useful.
>
>>> On the other hand, if the answer is the latter (or that it
>>> depends) then introducing an option for it would seem like
>>> exposing an interface to an internal detail (limitation)

Re: [patch, fortran] Load scalar intent-in variables at the beginning of procedures

[Thomas Koenig]

Am 11.11.19 um 22:55 schrieb Thomas König:

Regression-tested. OK for trunk?


Of course, better with a ChangeLog entry.

2019-11-11  Thomas Koenig  

PR fortran/67202
* dump-parse-tree.c (debug): Add for gfc_namespace.
(show_code_node): Add INIT_ on dumping EXEC_INIT_ASSIGN.
* frontent-passes.c (replace_intent_in): Add prototype.  New function.
(optimize_namespace): Call it.
(sym_replacement): New struct.
(replace_symbol_in_expr): New function.

2019-11-11  Thomas Koenig  

PR fortran/67202
* gfortran.dg/intent_optimize_3.f90: New test.

[patch, fortran] Load scalar intent-in variables at the beginning of procedures

[Thomas König]

Hello world,

the attached patch loads scalar INTENT(IN) variables to a local
variable at the start of a procedure, as suggested in PR 67202, in
order to aid optimization.  This is controlled by front-end
optimization so it is easier to catch if any bugs should turn up :-)

This is done to make optimization by the middle-end easier.

I left in the parts for debugging that I added for this patch.
Seeing the difference between EXEC_INIT_ASSIGN and EXEC_ASSIGN was
particularly instructive.

Regression-tested. OK for trunk?

Regards

Thomas
Index: dump-parse-tree.c
===
--- dump-parse-tree.c	(Revision 278025)
+++ dump-parse-tree.c	(Arbeitskopie)
@@ -57,6 +57,15 @@ static void show_attr (symbol_attribute *, const c
 /* Allow dumping of an expression in the debugger.  */
 void gfc_debug_expr (gfc_expr *);
 
+void debug (gfc_namespace *ns)
+{
+  FILE *tmp = dumpfile;
+  dumpfile = stderr;
+  show_namespace (ns);
+  fputc ('\n', dumpfile);
+  dumpfile = tmp;
+}
+
 void debug (symbol_attribute *attr)
 {
   FILE *tmp = dumpfile;
@@ -1889,6 +1898,9 @@ show_code_node (int level, gfc_code *c)
   break;
 
 case EXEC_INIT_ASSIGN:
+  fputs ("INIT_", dumpfile);
+  /* Fallthrough */
+
 case EXEC_ASSIGN:
   fputs ("ASSIGN ", dumpfile);
   show_expr (c->expr1);
Index: frontend-passes.c
===
--- frontend-passes.c	(Revision 278025)
+++ frontend-passes.c	(Arbeitskopie)
@@ -57,6 +57,7 @@ static int call_external_blas (gfc_code **, int *,
 static int matmul_temp_args (gfc_code **, int *,void *data);
 static int index_interchange (gfc_code **, int*, void *);
 static bool is_fe_temp (gfc_expr *e);
+static void replace_intent_in (gfc_namespace *);
 
 #ifdef CHECKING_P
 static void check_locus (gfc_namespace *);
@@ -1467,6 +1468,7 @@ optimize_namespace (gfc_namespace *ns)
 
   if (flag_frontend_optimize)
 {
+  replace_intent_in (ns);
   gfc_code_walker (>code, simplify_io_impl_do, dummy_expr_callback, NULL);
   gfc_code_walker (>code, convert_do_while, dummy_expr_callback, NULL);
   gfc_code_walker (>code, convert_elseif, dummy_expr_callback, NULL);
@@ -5503,3 +5505,132 @@ gfc_check_externals (gfc_namespace *ns)
 
   gfc_errors_to_warnings (false);
 }
+
+/*  For scalar INTENT(IN) variables or for variables where we know
+their value is not changed, we can replace them by an auxiliary
+variable whose value is set on procedure entry.  */
+
+typedef struct sym_replacement
+{
+  gfc_symbol *original;
+  gfc_symtree *replacement_symtree;
+  bool referenced;
+
+} sym_replace;
+
+/* Callback function - replace expression if possible, and set
+   sr->referenced if this was done (so we know we need to generate
+   the assignment statement).  */
+
+static int
+replace_symbol_in_expr (gfc_expr **e, int *walk_subtrees ATTRIBUTE_UNUSED,
+			void *data)
+{
+  gfc_expr *expr = *e;
+  sym_replacement *sr;
+
+  if (expr->expr_type != EXPR_VARIABLE || expr->symtree == NULL)
+return 0;
+
+  sr = (sym_replacement *) data;
+
+  if (expr->symtree->n.sym == sr->original)
+{
+  expr->symtree = sr->replacement_symtree;
+  sr->referenced = true;
+}
+
+  return 0;
+}
+
+/* Replace INTENT(IN) scalar variables by assigning their values to
+   temporary variables.  We really only want to use this for the
+   simplest cases, all the fancy stuff is excluded.  */
+
+static void
+replace_intent_in (gfc_namespace *ns)
+{
+  gfc_formal_arglist *f;
+  gfc_namespace *ns_c;
+
+  if (ns == NULL || ns->proc_name == NULL || gfc_elemental (ns->proc_name)
+  || ns->proc_name->attr.entry_master)
+return;
+
+  for (f = ns->proc_name->formal; f; f = f->next)
+{
+  if (f->sym == NULL || f->sym->attr.dimension || f->sym->attr.allocatable
+	  || f->sym->attr.optional || f->sym->attr.pointer
+	  || f->sym->attr.codimension || f->sym->attr.value
+	  || f->sym->attr.proc_pointer || f->sym->attr.target
+	  || f->sym->attr.asynchronous
+	  || f->sym->ts.type == BT_CHARACTER || f->sym->ts.type == BT_DERIVED
+	  || f->sym->ts.type == BT_CLASS)
+	continue;
+
+  /* TODO: It could also be possible to check if the variable can
+	 actually not be changed by appearing in a variable
+	 definition context or by being passed as an argument to a
+	 procedure where it could be changed.  */
+
+  if (f->sym->attr.intent == INTENT_IN)
+	{
+	  gfc_symtree *symtree;
+	  gfc_symbol *replacement;
+	  sym_replace sr;
+
+	  char name[GFC_MAX_SYMBOL_LEN + 1];
+	  snprintf (name, GFC_MAX_SYMBOL_LEN, "__dummy_%d_%s", var_num++,
+		f->sym->name);
+
+	  if (gfc_get_sym_tree (name, ns, , false) != 0)
+	gcc_unreachable ();
+
+	  replacement = symtree->n.sym;
+	  replacement->ts = f->sym->ts;
+	  replacement->attr.flavor = FL_VARIABLE;
+	  replacement->attr.fe_temp = 1;
+	  replacement->attr.referenced = 1;
+	  replacement->declared_at = f->sym->declared_at;
+	  

[Patch, RFC] PR81651/Fortran - Enhancement request: have f951 print out fully qualified module file name

[Harald Anlauf]

Dear all,

the attached patch prints the fully qualified path if an error occurs
during module read.  E.g., instead of a less helpful error message,

pr81651.f90:2:6:

2 |   use netcdf
  |  1
Fatal Error: File 'netcdf.mod' opened at (1) is not a GNU Fortran module
file

gfortran will print

pr81651.f90:2:7:

2 |   use netcdf
  |   1
Fatal Error: File '/opt/pgi/pkg/netcdf/include/netcdf.mod' opened at (1)
is not a GNU Fortran module file

Regtested on x86_64-pc-linux-gnu.

I couldn't think of a sensible test for the testsuite, thus no testcase
provided.

OK for trunk?

Thanks,
Harald

2019-11-11  Harald Anlauf  

PR fortran/81651
* module.c (gzopen_included_file, gzopen_included_file_1)
(gzopen_intrinsic_module, bad_module, gfc_use_module): Use fully
qualified module path for error reporting.
Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c(revision 278064)
+++ gcc/fortran/module.c(working copy)
@@ -187,6 +187,8 @@
 /* The gzFile for the module we're reading or writing.  */
 static gzFile module_fp;

+/* Fully qualified module path */
+static char *module_fullpath = NULL;

 /* The name of the module we're reading (USE'ing) or writing.  */
 static const char *module_name;
@@ -1101,6 +1103,8 @@
  if (gfc_cpp_makedep ())
gfc_cpp_add_dep (fullname, system);

+free (module_fullpath);
+module_fullpath = xstrdup (fullname);
  return f;
}
 }
@@ -1116,8 +1120,14 @@
   if (IS_ABSOLUTE_PATH (name) || include_cwd)
 {
   f = gzopen (name, "r");
-  if (f && gfc_cpp_makedep ())
-   gfc_cpp_add_dep (name, false);
+  if (f)
+   {
+ if (gfc_cpp_makedep ())
+   gfc_cpp_add_dep (name, false);
+
+ free (module_fullpath);
+ module_fullpath = xstrdup (name);
+   }
 }

   if (!f)
@@ -1134,8 +1144,14 @@
   if (IS_ABSOLUTE_PATH (name))
 {
   f = gzopen (name, "r");
-  if (f && gfc_cpp_makedep ())
-gfc_cpp_add_dep (name, true);
+  if (f)
+   {
+ if (gfc_cpp_makedep ())
+   gfc_cpp_add_dep (name, true);
+
+ free (module_fullpath);
+ module_fullpath = xstrdup (name);
+   }
 }

   if (!f)
@@ -1181,7 +1197,7 @@
 {
 case IO_INPUT:
   gfc_fatal_error ("Reading module %qs at line %d column %d: %s",
-  module_name, module_line, module_column, msgid);
+  module_fullpath, module_line, module_column, msgid);
   break;
 case IO_OUTPUT:
   gfc_fatal_error ("Writing module %qs at line %d column %d: %s",
@@ -7141,7 +7157,7 @@
   if ((start == 1 && strcmp (atom_name, "GFORTRAN") != 0)
  || (start == 2 && strcmp (atom_name, " module") != 0))
gfc_fatal_error ("File %qs opened at %C is not a GNU Fortran"
-" module file", filename);
+" module file", module_fullpath);
   if (start == 3)
{
  if (strcmp (atom_name, " version") != 0
@@ -7150,7 +7166,7 @@
  || strcmp (atom_string, MOD_VERSION))
gfc_fatal_error ("Cannot read module file %qs opened at %C,"
 " because it was created by a different"
-" version of GNU Fortran", filename);
+" version of GNU Fortran", module_fullpath);

  free (atom_string);
}

Re: [C++ PATCH] Fix deleted fn handling (PR c++/92447)

[Jason Merrill]

OK, thanks.

On Mon, Nov 11, 2019 at 3:14 PM Jakub Jelinek  wrote:

> Hi!
>
> The finish_function change to goto cleanup; on DECL_DELETED_FN added
> in the spaceship commit broke the following testcase.
> The problem is that during start_preparsed_function push_nested_class
> pushes a scope, but as ctype is kept NULL when goto cleanup; crosses
> the setting of ctype to something else, pop_nested_class isn't called
> anymore and callers get upset they are in current_binding_level
> of sk_class instead of what they expected.
>
> Fixed thusly, bootstrapped/regtested on powerpc64le-linux, ok for trunk?
>
> 2019-11-11  Jakub Jelinek  
>
> PR c++/92447
> * decl.c (finish_function): Move ctype initialization before
> DECL_DELETED_FN handling.
>
> * g++.dg/cpp0x/pr92447.C: New test.
>
> --- gcc/cp/decl.c.jj2019-11-07 09:50:51.0 +0100
> +++ gcc/cp/decl.c   2019-11-11 15:29:17.610112820 +0100
> @@ -16803,6 +16803,10 @@ finish_function (bool inline_p)
> }
>  }
>
> +  /* Remember that we were in class scope.  */
> +  if (current_class_name)
> +ctype = current_class_type;
> +
>if (DECL_DELETED_FN (fndecl))
>  {
>DECL_INITIAL (fndecl) = error_mark_node;
> @@ -16861,10 +16865,6 @@ finish_function (bool inline_p)
>current_function_return_value = NULL_TREE;
>  }
>
> -  /* Remember that we were in class scope.  */
> -  if (current_class_name)
> -ctype = current_class_type;
> -
>/* Must mark the RESULT_DECL as being in this function.  */
>DECL_CONTEXT (DECL_RESULT (fndecl)) = fndecl;
>
> --- gcc/testsuite/g++.dg/cpp0x/pr92447.C.jj 2019-11-11
> 15:31:28.208138229 +0100
> +++ gcc/testsuite/g++.dg/cpp0x/pr92447.C2019-11-11
> 15:30:29.314028624 +0100
> @@ -0,0 +1,14 @@
> +// PR c++/92447
> +// { dg-do compile { target c++11 } }
> +
> +template 
> +void
> +foo ()
> +{
> +  struct S { S =(S &) = default; const T s{}; };
> +}
> +
> +void bar ()
> +{
> +  foo();
> +}
>
> Jakub
>
>

[PATCH] Fix ICE in vrp on aarch64 (PR tree-optimization/92452)

[Jakub Jelinek]

Hi!

The following testcase ICEs on aarch64-linux.  The problem is that maxbound
is POLY_INT_CST, eltsize is INTEGER_CST, but int_const_binop for
TRUNC_DIV_EXPR returns NULL_TREE as it can't simplify it to something
usable and we later try to MINUS_EXPR the NULL_TREE.

Fixed thusly, tested using cross to aarch64-linux, bootstrapped/regtested on
powerpc64le-linux, ok for trunk?

2019-11-11  Jakub Jelinek  

PR tree-optimization/92452
* tree-vrp.c (vrp_prop::check_array_ref): If TRUNC_DIV_EXPR folds
into NULL_TREE, set up_bound to NULL_TREE instead of computing
MINUS_EXPR on it.

* c-c++-common/pr92452.c: New test.

--- gcc/tree-vrp.c.jj   2019-11-09 00:41:09.022921760 +0100
+++ gcc/tree-vrp.c  2019-11-11 17:03:36.844669691 +0100
@@ -4150,8 +4150,11 @@ vrp_prop::check_array_ref (location_t lo
 
  up_bound_p1 = int_const_binop (TRUNC_DIV_EXPR, maxbound, eltsize);
 
- up_bound = int_const_binop (MINUS_EXPR, up_bound_p1,
- build_int_cst (ptrdiff_type_node, 1));
+ if (up_bound_p1 != NULL_TREE)
+   up_bound = int_const_binop (MINUS_EXPR, up_bound_p1,
+   build_int_cst (ptrdiff_type_node, 1));
+ else
+   up_bound = NULL_TREE;
}
 }
   else
--- gcc/testsuite/c-c++-common/pr92452.c.jj 2019-11-11 17:06:01.525495277 
+0100
+++ gcc/testsuite/c-c++-common/pr92452.c2019-11-11 17:05:31.256950180 
+0100
@@ -0,0 +1,5 @@
+/* PR tree-optimization/92452 */
+/* { dg-do compile } */
+/* { dg-options "-Os -Warray-bounds=1" } */
+
+#include "pr60101.c"

Jakub

[C++ PATCH] Fix deleted fn handling (PR c++/92447)

[Jakub Jelinek]

Hi!

The finish_function change to goto cleanup; on DECL_DELETED_FN added
in the spaceship commit broke the following testcase.
The problem is that during start_preparsed_function push_nested_class
pushes a scope, but as ctype is kept NULL when goto cleanup; crosses
the setting of ctype to something else, pop_nested_class isn't called
anymore and callers get upset they are in current_binding_level
of sk_class instead of what they expected.

Fixed thusly, bootstrapped/regtested on powerpc64le-linux, ok for trunk?

2019-11-11  Jakub Jelinek  

PR c++/92447
* decl.c (finish_function): Move ctype initialization before
DECL_DELETED_FN handling.

* g++.dg/cpp0x/pr92447.C: New test.

--- gcc/cp/decl.c.jj2019-11-07 09:50:51.0 +0100
+++ gcc/cp/decl.c   2019-11-11 15:29:17.610112820 +0100
@@ -16803,6 +16803,10 @@ finish_function (bool inline_p)
}
 }
 
+  /* Remember that we were in class scope.  */
+  if (current_class_name)
+ctype = current_class_type;
+
   if (DECL_DELETED_FN (fndecl))
 {
   DECL_INITIAL (fndecl) = error_mark_node;
@@ -16861,10 +16865,6 @@ finish_function (bool inline_p)
   current_function_return_value = NULL_TREE;
 }
 
-  /* Remember that we were in class scope.  */
-  if (current_class_name)
-ctype = current_class_type;
-
   /* Must mark the RESULT_DECL as being in this function.  */
   DECL_CONTEXT (DECL_RESULT (fndecl)) = fndecl;
 
--- gcc/testsuite/g++.dg/cpp0x/pr92447.C.jj 2019-11-11 15:31:28.208138229 
+0100
+++ gcc/testsuite/g++.dg/cpp0x/pr92447.C2019-11-11 15:30:29.314028624 
+0100
@@ -0,0 +1,14 @@
+// PR c++/92447
+// { dg-do compile { target c++11 } }
+
+template 
+void
+foo ()
+{
+  struct S { S =(S &) = default; const T s{}; };
+}
+
+void bar ()
+{
+  foo();
+}

Jakub

[committed] Unbreak powerpc* bootstrap (PR bootstrap/92433)

[Jakub Jelinek]

Hi!

A recent unroller change results in the arg_types array initializing
loop in altivec_build_resolved_builtin being completely unrolled.
The callers ensure that for ALTIVEC_BUILTIN_VEC_VCMPGE_P all the 3
arguments are provided (i.e. n == 3), but the compiler doesn't know that
and emits -Wmaybe-uninitialized warning.

Fixed thusly, additionally simplified the code/made it more readable
with std::swap.  Bootstrapped/regtested on powerpc64le-linux, preapproved by
Segher on IRC, committed to trunk.

2019-11-11  Jakub Jelinek  

PR bootstrap/92433
* config/rs6000/rs6000-c.c (altivec_build_resolved_builtin): Guard
ALTIVEC_BUILTIN_VEC_VCMPGE_P argument swapping with n == 3 check.  Use
std::swap.

--- gcc/config/rs6000/rs6000-c.c.jj 2019-08-27 12:26:30.115019661 +0200
+++ gcc/config/rs6000/rs6000-c.c2019-11-11 10:12:00.954282097 +0100
@@ -6076,14 +6076,14 @@ altivec_build_resolved_builtin (tree *ar
  condition (LT vs. EQ, which is recognizable by bit 1 of the first
  argument) is reversed.  Patch the arguments here before building
  the resolved CALL_EXPR.  */
-  if (desc->code == ALTIVEC_BUILTIN_VEC_VCMPGE_P
+  if (n == 3
+  && desc->code == ALTIVEC_BUILTIN_VEC_VCMPGE_P
   && desc->overloaded_code != ALTIVEC_BUILTIN_VCMPGEFP_P
   && desc->overloaded_code != VSX_BUILTIN_XVCMPGEDP_P)
 {
-  tree t;
-  t = args[2], args[2] = args[1], args[1] = t;
-  t = arg_type[2], arg_type[2] = arg_type[1], arg_type[1] = t;
-  
+  std::swap (args[1], args[2]);
+  std::swap (arg_type[1], arg_type[2]);
+
   args[0] = fold_build2 (BIT_XOR_EXPR, TREE_TYPE (args[0]), args[0],
 build_int_cst (NULL_TREE, 2));
 }

Jakub

[committed] Diagnose #pragma omp declare target without corresponding #pragma omp end declare target

[Jakub Jelinek]

Hi!

I found a bug in OpenMP 5.0 examples that GCC didn't flag as an error.
The following patch implements the missing diagnostics.

Bootstrapped/regtested on powerpc64le-linux, committed to trunk.

2019-11-11  Jakub Jelinek  

* c-parser.c (c_parser_translation_unit): Diagnose declare target
without corresponding end declare target.

* semantics.c (finish_translation_unit): Diagnose declare target
without corresponding end declare target.

* c-c++-common/gomp/declare-target-5.c: New test.

--- gcc/c/c-parser.c.jj 2019-11-08 09:03:56.271250390 +0100
+++ gcc/c/c-parser.c2019-11-11 11:09:46.910702347 +0100
@@ -1554,6 +1554,14 @@ c_parser_translation_unit (c_parser *par
   FOR_EACH_VEC_ELT (incomplete_record_decls, i, decl)
 if (DECL_SIZE (decl) == NULL_TREE && TREE_TYPE (decl) != error_mark_node)
   error ("storage size of %q+D isn%'t known", decl);
+
+  if (current_omp_declare_target_attribute)
+{
+  if (!errorcount)
+error ("%<#pragma omp declare target%> without corresponding "
+  "%<#pragma omp end declare target%>");
+  current_omp_declare_target_attribute = 0;
+}
 }
 
 /* Parse an external declaration (C90 6.7, C99 6.9, C11 6.9).
--- gcc/cp/semantics.c.jj   2019-11-02 00:26:48.932847353 +0100
+++ gcc/cp/semantics.c  2019-11-11 11:29:55.009396475 +0100
@@ -3048,6 +3048,14 @@ finish_translation_unit (void)
 
   /* Do file scope __FUNCTION__ et al.  */
   finish_fname_decls ();
+
+  if (scope_chain->omp_declare_target_attribute)
+{
+  if (!errorcount)
+   error ("%<#pragma omp declare target%> without corresponding "
+  "%<#pragma omp end declare target%>");
+  scope_chain->omp_declare_target_attribute = 0;
+}
 }
 
 /* Finish a template type parameter, specified as AGGR IDENTIFIER.
--- gcc/testsuite/c-c++-common/gomp/declare-target-5.c.jj   2019-11-11 
11:11:04.577524594 +0100
+++ gcc/testsuite/c-c++-common/gomp/declare-target-5.c  2019-11-11 
11:18:40.289619051 +0100
@@ -0,0 +1,2 @@
+#pragma omp declare target
+void foo (void);   /* { dg-error "'#pragma omp declare target' without 
corresponding '#pragma omp end declare target'" } */

Jakub

Re: [C++ PATCH] Implement P1946R0 - Allow defaulting comparisons by value

[Jakub Jelinek]

On Mon, Nov 11, 2019 at 09:07:08AM +0100, Jakub Jelinek wrote:
> From 
> https://www.reddit.com/r/cpp/comments/dtuov8/201911_belfast_iso_c_committee_trip_report/
> I understood P1946R0 made it into C++20, so here is my attempt at
> implementing it, you had most of it implemented anyway because
> in system headers
> friend constexpr bool
> operator==(partial_ordering, partial_ordering) noexcept = default;
> etc. has been already accepted.
> 
> Tested so far with make check-c++-all RUNTESTFLAGS=dg.exp=spaceship*
> and make check-target-libstdc++-v3 
> RUNTESTFLAGS=conformance.exp=18_support/comparisons/common/1.cc
> Ok for trunk if it passes full bootstrap/regtest?

Bootstrapped/regtested successfully on powerpc64le-linux.

> 2019-11-11  Jakub Jelinek  
> 
>   Implement P1946R0 - Allow defaulting comparisons by value
>   * method.c (early_check_defaulted_comparison): Remove unused
>   variable i.  For non-static data members always require argument
>   type to be const C &, for friends allow either both arguments
>   to be const C &, or both to be C.
> 
>   * g++.dg/cpp2a/spaceship-synth1-neg.C: New test.
>   * g++.dg/cpp2a/spaceship-synth4.C: New test.
>   * g++.dg/cpp2a/spaceship-synth5.C: New test.

Jakub

Re: [PATCH] Bump minimum MPFR version to 3.1.0

[Janne Blomqvist]

On Mon, Nov 11, 2019 at 8:29 PM Joseph Myers  wrote:
>
> On Sat, 9 Nov 2019, Janne Blomqvist wrote:
>
> > Bump the minimum MPFR version to 3.1.0, released 2011-10-03. With this
> > requirement one can still build GCC with the operating system provided
> > MPFR on old but still supported operating systems like SLES 12 (MPFR
> > 3.1.2) or RHEL/CentOS 7.x (MPFR 3.1.1).
> >
> > This allows removing some code in the Fortran frontend, as well as
> > fixing PR 91828.
>
> As a remark, beyond the cases where this allows conditional code to be
> removed, there are also possible cleanups where GCC is currently using
> MPFR constants / types that are documented as obsolescent
> .
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Yes, good idea. I filed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92463 to keep track of
this.

-- 
Janne Blomqvist

[8/8] Optimise WAR and WAW alias checks

[Richard Sandiford]

For:

  void
  f1 (int *x, int *y)
  {
for (int i = 0; i < 32; ++i)
  x[i] += y[i];
  }

we checked at runtime whether one vector at x would overlap one vector
at y.  But in cases like this, the vector code would handle x <= y just
fine, since any write to address A still happens after any read from
address A.  The only problem is if x is ahead of y by less than a
vector.

The same is true for two writes:

  void
  f2 (int *x, int *y)
  {
for (int i = 0; i < 32; ++i)
  {
x[i] = i;
y[i] = 2;
  }
  }

if y <= x then a vector write at y after a vector write at x would
have the same net effect as the original scalar writes.

This patch optimises the alias checks for these two cases.  E.g.,
before the patch, f1 used:

add x2, x0, 15
sub x2, x2, x1
cmp x2, 30
bls .L2

whereas after the patch it uses:

add x2, x1, 4
sub x2, x0, x2
cmp x2, 8
bls .L2

Read-after-write cases like:

  int
  f3 (int *x, int *y)
  {
int res = 0;
for (int i = 0; i < 32; ++i)
  {
x[i] = i;
res += y[i];
  }
return res;
  }

can cope with x == y, but otherwise don't allow overlap in either
direction.  Since checking for x == y at runtime would require extra
code, we're probably better off sticking with the current overlap test.

An overlap test is also needed if the scalar or vector accesses covered
by the alias check are mixed together, rather than all statements for
the second access following all statements for the first access.

The new code for gcc.target/aarch64/sve/var_strict_[135].c is slightly
better than before.


2019-11-11  Richard Sandiford  

gcc/
* tree-data-ref.c (create_intersect_range_checks_index): If the
alias pair describes simple WAW and WAR dependencies, just check
whether the first B access overlaps later A accesses.
(create_waw_or_war_checks): New function that performs the same
optimization on addresses.
(create_intersect_range_checks): Call it.

gcc/testsuite/
* gcc.dg/vect/vect-alias-check-8.c: Expect WAR/WAW checks to be used.
* gcc.dg/vect/vect-alias-check-14.c: Likewise.
* gcc.dg/vect/vect-alias-check-15.c: Likewise.
* gcc.dg/vect/vect-alias-check-18.c: Likewise.
* gcc.dg/vect/vect-alias-check-19.c: Likewise.
* gcc.target/aarch64/sve/var_stride_1.c: Update expected sequence.
* gcc.target/aarch64/sve/var_stride_2.c: Likewise.
* gcc.target/aarch64/sve/var_stride_3.c: Likewise.
* gcc.target/aarch64/sve/var_stride_5.c: Likewise.

Index: gcc/tree-data-ref.c
===
--- gcc/tree-data-ref.c 2019-11-11 18:32:12.0 +
+++ gcc/tree-data-ref.c 2019-11-11 18:32:13.186616541 +
@@ -1806,6 +1806,8 @@ create_intersect_range_checks_index (cla
   abs_step, _access2))
 return false;
 
+  bool waw_or_war_p = (alias_pair.flags & ~(DR_ALIAS_WAR | DR_ALIAS_WAW)) == 0;
+
   unsigned int i;
   for (i = 0; i < DR_NUM_DIMENSIONS (dr_a.dr); i++)
 {
@@ -1907,16 +1909,57 @@ create_intersect_range_checks_index (cla
 
 Combining the tests requires limit to be computable in an unsigned
 form of the index type; if it isn't, we fall back to the usual
-pointer-based checks.  */
-  poly_offset_int limit = (idx_len1 + idx_access1 - 1
-  + idx_len2 + idx_access2 - 1);
+pointer-based checks.
+
+We can do better if DR_B is a write and if DR_A and DR_B are
+well-ordered in both the original and the new code (see the
+comment above the DR_ALIAS_* flags for details).  In this case
+we know that for each i in [0, n-1], the write performed by
+access i of DR_B occurs after access numbers j<=i of DR_A in
+both the original and the new code.  Any write or anti
+dependencies wrt those DR_A accesses are therefore maintained.
+
+We just need to make sure that each individual write in DR_B does not
+overlap any higher-indexed access in DR_A; such DR_A accesses happen
+after the DR_B access in the original code but happen before it in
+the new code.
+
+We know the steps for both accesses are equal, so by induction, we
+just need to test whether the first write of DR_B overlaps a later
+access of DR_A.  In other words, we need to move min1 along by
+one iteration:
+
+  min1' = min1 + idx_step
+
+and use the ranges:
+
+  [min1' + low_offset1', min1' + high_offset1' + idx_access1 - 1]
+
+and:
+
+  [min2, min2 + idx_access2 - 1]
+
+where:
+
+   low_offset1' = +ve step ? 0 : -(idx_len1 - |idx_step|)
+  high_offset1' = +ve_step ? idx_len1 - |idx_step| : 0.  */
+  if (waw_or_war_p)
+   idx_len1 -= abs_idx_step;
+
+  

[7/8] Use a single comparison for index-based alias checks

[Richard Sandiford]

This patch rewrites the index-based alias checks to use conditions
of the form:

  (unsigned T) (a - b + bias) <= limit

E.g. before the patch:

  struct s { int x[100]; };

  void
  f1 (struct s *s1, int a, int b)
  {
for (int i = 0; i < 32; ++i)
  s1->x[i + a] += s1->x[i + b];
  }

used:

add w3, w1, 3
cmp w3, w2
add w3, w2, 3
ccmpw1, w3, 0, ge
ble .L2

whereas after the patch it uses:

sub w3, w1, w2
add w3, w3, 3
cmp w3, 6
bls .L2

The patch also fixes the seg_len1 and seg_len2 negation for cases in
which seg_len is a "negative unsigned" value narrower than 64 bits,
like it is for 32-bit targets.  Previously we'd end up with values
like 0x1 instead of 1.


2019-11-11  Richard Sandiford  

gcc/
* tree-data-ref.c (create_intersect_range_checks_index): Rewrite
the index tests to have the form (unsigned T) (B - A + bias) <= limit.

gcc/testsuite/
* gcc.dg/vect/vect-alias-check-18.c: New test.
* gcc.dg/vect/vect-alias-check-19.c: Likewise.
* gcc.dg/vect/vect-alias-check-20.c: Likewise.

Index: gcc/tree-data-ref.c
===
--- gcc/tree-data-ref.c 2019-11-11 18:31:01.263118514 +
+++ gcc/tree-data-ref.c 2019-11-11 18:31:05.099091743 +
@@ -1744,7 +1744,9 @@ prune_runtime_alias_test_list (vec
+ <--- A: -ve step --->
+ +-+---+-+---+-+
+ | n-1 | . |  0  | . | n-1 |
+ +-+---+-+---+-+
+   <--- B: +ve step --->
+   <-- idx_len -->
+   |
+  min
+
+where "n" is the number of scalar iterations covered by the segment
+and where each access spans idx_access units.
+
+A is the range of bytes accessed when the step is negative,
+B is the range when the step is positive.
+
+When checking for general overlap, we need to test whether
+the range:
+
+  [min1 + low_offset1, min2 + high_offset1 + idx_access1 - 1]
+
+overlaps:
+
+  [min2 + low_offset2, min2 + high_offset2 + idx_access2 - 1]
+
+where:
+
+   low_offsetN = +ve step ? 0 : -idx_lenN;
+  high_offsetN = +ve step ? idx_lenN : 0;
+
+This is equivalent to testing whether:
+
+  min1 + low_offset1 <= min2 + high_offset2 + idx_access2 - 1
+  && min2 + low_offset2 <= min1 + high_offset1 + idx_access1 - 1
+
+Converting this into a single test, there is an overlap if:
+
+  0 <= min2 - min1 + bias <= limit
+
+where  bias = high_offset2 + idx_access2 - 1 - low_offset1
+  limit = (high_offset1 - low_offset1 + idx_access1 - 1)
++ (high_offset2 - low_offset2 + idx_access2 - 1)
+ i.e. limit = idx_len1 + idx_access1 - 1 + idx_len2 + idx_access2 - 1
+
+Combining the tests requires limit to be computable in an unsigned
+form of the index type; if it isn't, we fall back to the usual
+pointer-based checks.  */
+  poly_offset_int limit = (idx_len1 + idx_access1 - 1
+  + idx_len2 + idx_access2 - 1);
+  tree utype = unsigned_type_for (TREE_TYPE (min1));
+  if (!wi::fits_to_tree_p (limit, utype))
+   return false;
+
+  poly_offset_int low_offset1 = neg_step ? -idx_len1 : 0;
+  poly_offset_int high_offset2 = neg_step ? 0 : idx_len2;
+  poly_offset_int bias = high_offset2 + idx_access2 - 1 - low_offset1;
+
+  tree subject = fold_build2 (MINUS_EXPR, utype,
+ fold_convert (utype, min2),
+ fold_convert (utype, min1));
+  subject = fold_build2 (PLUS_EXPR, utype, subject,
+wide_int_to_tree (utype, bias));
+  tree part_cond_expr = fold_build2 (GT_EXPR, boolean_type_node, subject,
+wide_int_to_tree (utype, limit));
   if (*cond_expr)
*cond_expr = fold_build2 (TRUTH_AND_EXPR, boolean_type_node,
  *cond_expr, part_cond_expr);
Index: gcc/testsuite/gcc.dg/vect/vect-alias-check-18.c
===
--- /dev/null   2019-09-17 11:41:18.176664108 +0100
+++ gcc/testsuite/gcc.dg/vect/vect-alias-check-18.c 2019-11-11 
18:31:05.099091743 +
@@ -0,0 +1,64 @@
+#define N 200
+#define DIST 32
+
+typedef signed char sc;
+typedef unsigned char uc;
+typedef signed short ss;
+typedef unsigned short us;
+typedef int si;
+typedef unsigned int ui;
+typedef signed long long sll;
+typedef unsigned long long ull;
+
+#define FOR_EACH_TYPE(M) \
+  M (sc) M (uc) \
+  M (ss) M (us) \
+  M (si) M (ui) \
+  M (sll) M (ull) \
+  M (float) M (double)
+
+#define TEST_VALUE(I) ((I) * 11 / 2)
+
+#define 

[6/8] Print the type of alias check in a dump message

[Richard Sandiford]

This patch prints a message to say how an alias check is being
implemented.


2019-11-11  Richard Sandiford  

gcc/
* tree-data-ref.c (create_intersect_range_checks_index)
(create_intersect_range_checks): Print dump messages.

gcc/testsuite/
* gcc.dg/vect/vect-alias-check-1.c: Test for the type of alias check.
* gcc.dg/vect/vect-alias-check-8.c: Likewise.
* gcc.dg/vect/vect-alias-check-9.c: Likewise.
* gcc.dg/vect/vect-alias-check-10.c: Likewise.
* gcc.dg/vect/vect-alias-check-11.c: Likewise.
* gcc.dg/vect/vect-alias-check-12.c: Likewise.
* gcc.dg/vect/vect-alias-check-13.c: Likewise.
* gcc.dg/vect/vect-alias-check-14.c: Likewise.
* gcc.dg/vect/vect-alias-check-15.c: Likewise.
* gcc.dg/vect/vect-alias-check-16.c: Likewise.
* gcc.dg/vect/vect-alias-check-17.c: Likewise.

Index: gcc/tree-data-ref.c
===
--- gcc/tree-data-ref.c 2019-11-11 18:30:57.167147102 +
+++ gcc/tree-data-ref.c 2019-11-11 18:31:01.263118514 +
@@ -1890,6 +1890,8 @@ create_intersect_range_checks_index (cla
   else
*cond_expr = part_cond_expr;
 }
+  if (dump_enabled_p ())
+dump_printf (MSG_NOTE, "using an index-based overlap test\n");
   return true;
 }
 
@@ -2037,6 +2039,8 @@ create_intersect_range_checks (class loo
 = fold_build2 (TRUTH_OR_EXPR, boolean_type_node,
fold_build2 (cmp_code, boolean_type_node, seg_a_max, seg_b_min),
fold_build2 (cmp_code, boolean_type_node, seg_b_max, seg_a_min));
+  if (dump_enabled_p ())
+dump_printf (MSG_NOTE, "using an address-based overlap test\n");
 }
 
 /* Create a conditional expression that represents the run-time checks for
Index: gcc/testsuite/gcc.dg/vect/vect-alias-check-1.c
===
--- gcc/testsuite/gcc.dg/vect/vect-alias-check-1.c  2019-03-08 
18:15:02.304871094 +
+++ gcc/testsuite/gcc.dg/vect/vect-alias-check-1.c  2019-11-11 
18:31:01.247118627 +
@@ -15,3 +15,5 @@ fn1 ()
 }
 
 /* { dg-final { scan-tree-dump "improved number of alias checks from \[0-9\]* 
to 1" "vect" } } */
+/* { dg-final { scan-tree-dump "using an address-based overlap test" "vect" } 
} */
+/* { dg-final { scan-tree-dump-not "using an index-based" "vect" } } */
Index: gcc/testsuite/gcc.dg/vect/vect-alias-check-8.c
===
--- gcc/testsuite/gcc.dg/vect/vect-alias-check-8.c  2019-11-11 
18:30:57.167147102 +
+++ gcc/testsuite/gcc.dg/vect/vect-alias-check-8.c  2019-11-11 
18:31:01.251118599 +
@@ -60,3 +60,5 @@ main (void)
 }
 
 /* { dg-final { scan-tree-dump {flags: *WAR\n} "vect" { target vect_int } } } 
*/
+/* { dg-final { scan-tree-dump "using an index-based overlap test" "vect" } } 
*/
+/* { dg-final { scan-tree-dump-not "using an address-based" "vect" } } */
Index: gcc/testsuite/gcc.dg/vect/vect-alias-check-9.c
===
--- gcc/testsuite/gcc.dg/vect/vect-alias-check-9.c  2019-11-11 
18:30:57.167147102 +
+++ gcc/testsuite/gcc.dg/vect/vect-alias-check-9.c  2019-11-11 
18:31:01.251118599 +
@@ -53,3 +53,5 @@ main (void)
 }
 
 /* { dg-final { scan-tree-dump {flags: [^\n]*ARBITRARY\n} "vect" { target 
vect_int } } } */
+/* { dg-final { scan-tree-dump "using an address-based overlap test" "vect" } 
} */
+/* { dg-final { scan-tree-dump-not "using an index-based" "vect" } } */
Index: gcc/testsuite/gcc.dg/vect/vect-alias-check-10.c
===
--- gcc/testsuite/gcc.dg/vect/vect-alias-check-10.c 2019-03-08 
18:15:02.248871307 +
+++ gcc/testsuite/gcc.dg/vect/vect-alias-check-10.c 2019-11-11 
18:31:01.251118599 +
@@ -65,3 +65,6 @@ main (void)
   FOR_EACH_TYPE (DO_TEST)
   return 0;
 }
+
+/* { dg-final { scan-tree-dump-not "using an address-based" "vect" } } */
+/* { dg-final { scan-tree-dump-not "using an index-based" "vect" } } */
Index: gcc/testsuite/gcc.dg/vect/vect-alias-check-11.c
===
--- gcc/testsuite/gcc.dg/vect/vect-alias-check-11.c 2019-03-08 
18:15:02.292871138 +
+++ gcc/testsuite/gcc.dg/vect/vect-alias-check-11.c 2019-11-11 
18:31:01.251118599 +
@@ -95,3 +95,6 @@ main (void)
 /* { dg-final { scan-tree-dump {no alias between [^\n]* when [^\n]* step[^ ]* 
\* 8[)]* is outside \(-24, 24\)} "vect" { target vect_double } } } */
 /* { dg-final { scan-tree-dump {no alias between [^\n]* when [^\n]* step[^ ]* 
\* 8[)]* is outside \(-32, 32\)} "vect" { target vect_double } } } */
 /* { dg-final { scan-tree-dump {run-time check [^\n]* abs \([^*]* \* 8[)]* >= 
32} "vect" { target vect_double } } } */
+
+/* { dg-final { scan-tree-dump-not "using an address-based" "vect" } } */
+/* { dg-final { scan-tree-dump-not "using an index-based" "vect" } } */
Index: 

[5/8] Dump the list of merged alias pairs

[Richard Sandiford]

This patch dumps the final (merged) list of alias pairs.  It also adds:

- WAW and RAW versions of vect-alias-check-8.c
- a "well-ordered" version of vect-alias-check-9.c (i.e. all reads
  before any writes)
- a test with mixed steps in the same alias pair

I also tweaked the test value in vect-alias-check-9.c so that the result
was less likely to be accidentally correct if the alias isn't honoured.


2019-11-11  Richard Sandiford  

gcc/
* tree-data-ref.c (dump_alias_pair): New function.
(prune_runtime_alias_test_list): Use it to dump each merged alias pair.

gcc/testsuite/
* gcc.dg/vect/vect-alias-check-8.c: Test for the RAW flag.
* gcc.dg/vect/vect-alias-check-9.c: Test for the ARBITRARY flag.
(TEST_VALUE): Use a higher value for early iterations.
* gcc.dg/vect/vect-alias-check-14.c: New test.
* gcc.dg/vect/vect-alias-check-15.c: Likewise.
* gcc.dg/vect/vect-alias-check-16.c: Likewise.
* gcc.dg/vect/vect-alias-check-17.c: Likewise.

Index: gcc/tree-data-ref.c
===
--- gcc/tree-data-ref.c 2019-11-11 18:30:53.863170161 +
+++ gcc/tree-data-ref.c 2019-11-11 18:30:57.167147102 +
@@ -1453,6 +1453,54 @@ comp_dr_with_seg_len_pair (const void *p
   return 0;
 }
 
+/* Dump information about ALIAS_PAIR, indenting each line by INDENT.  */
+
+static void
+dump_alias_pair (dr_with_seg_len_pair_t *alias_pair, const char *indent)
+{
+  dump_printf (MSG_NOTE, "%sreference:  %T vs. %T\n", indent,
+  DR_REF (alias_pair->first.dr),
+  DR_REF (alias_pair->second.dr));
+
+  dump_printf (MSG_NOTE, "%ssegment length: %T", indent,
+  alias_pair->first.seg_len);
+  if (!operand_equal_p (alias_pair->first.seg_len,
+   alias_pair->second.seg_len, 0))
+dump_printf (MSG_NOTE, " vs. %T", alias_pair->second.seg_len);
+
+  dump_printf (MSG_NOTE, "\n%saccess size:", indent);
+  dump_dec (MSG_NOTE, alias_pair->first.access_size);
+  if (maybe_ne (alias_pair->first.access_size, alias_pair->second.access_size))
+{
+  dump_printf (MSG_NOTE, " vs. ");
+  dump_dec (MSG_NOTE, alias_pair->second.access_size);
+}
+
+  dump_printf (MSG_NOTE, "\n%salignment:  %d", indent,
+  alias_pair->first.align);
+  if (alias_pair->first.align != alias_pair->second.align)
+dump_printf (MSG_NOTE, " vs. %d", alias_pair->second.align);
+
+  dump_printf (MSG_NOTE, "\n%sflags: ", indent);
+  if (alias_pair->flags & DR_ALIAS_RAW)
+dump_printf (MSG_NOTE, " RAW");
+  if (alias_pair->flags & DR_ALIAS_WAR)
+dump_printf (MSG_NOTE, " WAR");
+  if (alias_pair->flags & DR_ALIAS_WAW)
+dump_printf (MSG_NOTE, " WAW");
+  if (alias_pair->flags & DR_ALIAS_ARBITRARY)
+dump_printf (MSG_NOTE, " ARBITRARY");
+  if (alias_pair->flags & DR_ALIAS_SWAPPED)
+dump_printf (MSG_NOTE, " SWAPPED");
+  if (alias_pair->flags & DR_ALIAS_UNSWAPPED)
+dump_printf (MSG_NOTE, " UNSWAPPED");
+  if (alias_pair->flags & DR_ALIAS_MIXED_STEPS)
+dump_printf (MSG_NOTE, " MIXED_STEPS");
+  if (alias_pair->flags == 0)
+dump_printf (MSG_NOTE, " ");
+  dump_printf (MSG_NOTE, "\n");
+}
+
 /* Merge alias checks recorded in ALIAS_PAIRS and remove redundant ones.
FACTOR is number of iterations that each data reference is accessed.
 
@@ -1656,6 +1704,8 @@ prune_runtime_alias_test_list (vecflags |= DR_ALIAS_ARBITRARY;
   alias_pair->flags &= ~swap_mask;
+  if (dump_enabled_p ())
+   dump_alias_pair (alias_pair, "  ");
 }
 }
 
Index: gcc/testsuite/gcc.dg/vect/vect-alias-check-8.c
===
--- gcc/testsuite/gcc.dg/vect/vect-alias-check-8.c  2019-03-08 
18:15:02.280871184 +
+++ gcc/testsuite/gcc.dg/vect/vect-alias-check-8.c  2019-11-11 
18:30:57.167147102 +
@@ -58,3 +58,5 @@ main (void)
   FOR_EACH_TYPE (DO_TEST)
   return 0;
 }
+
+/* { dg-final { scan-tree-dump {flags: *WAR\n} "vect" { target vect_int } } } 
*/
Index: gcc/testsuite/gcc.dg/vect/vect-alias-check-9.c
===
--- gcc/testsuite/gcc.dg/vect/vect-alias-check-9.c  2019-03-08 
18:15:02.244871320 +
+++ gcc/testsuite/gcc.dg/vect/vect-alias-check-9.c  2019-11-11 
18:30:57.167147102 +
@@ -17,7 +17,7 @@ #define FOR_EACH_TYPE(M) \
   M (sll) M (ull) \
   M (float) M (double)
 
-#define TEST_VALUE(I) ((I) * 5 / 2)
+#define TEST_VALUE(I) ((I) * 17 / 2)
 
 #define ADD_TEST(TYPE) \
   void __attribute__((noinline, noclone))  \
@@ -51,3 +51,5 @@ main (void)
   FOR_EACH_TYPE (DO_TEST)
   return 0;
 }
+
+/* { dg-final { scan-tree-dump {flags: [^\n]*ARBITRARY\n} "vect" { target 
vect_int } } } */
Index: gcc/testsuite/gcc.dg/vect/vect-alias-check-14.c
===
--- /dev/null   2019-09-17 11:41:18.176664108 +0100
+++ 

[4/8] Record whether a dr_with_seg_len contains mixed steps

[Richard Sandiford]

prune_runtime_alias_test_list can merge dr_with_seg_len_pair_ts that
have different steps for the first reference or different steps for the
second reference.  This patch adds a flag to record that.

I don't know whether the change to create_intersect_range_checks_index
fixes anything in practice.  It would have to be a corner case if so,
since at present we only merge two alias pairs if either the first or
the second references are identical and only the other references differ.
And the vectoriser uses VF-based segment lengths only if both references
in a pair have the same step.  Either way, it still seems wrong to use
DR_STEP when it doesn't represent all checks that have been merged into
the pair.


2019-11-11  Richard Sandiford  

gcc/
* tree-data-ref.h (DR_ALIAS_MIXED_STEPS): New flag.
* tree-data-ref.c (prune_runtime_alias_test_list): Set it when
merging data references with different steps.
(create_intersect_range_checks_index): Take a
dr_with_seg_len_pair_t instead of two dr_with_seg_lens.
Bail out if DR_ALIAS_MIXED_STEPS is set.
(create_intersect_range_checks): Take a dr_with_seg_len_pair_t
instead of two dr_with_seg_lens.  Update call to
create_intersect_range_checks_index.
(create_runtime_alias_checks): Update call accordingly.

Index: gcc/tree-data-ref.h
===
--- gcc/tree-data-ref.h 2019-11-11 18:30:50.527193443 +
+++ gcc/tree-data-ref.h 2019-11-11 18:30:53.863170161 +
@@ -250,6 +250,12 @@ typedef struct data_reference *data_refe
Temporary flags that indicate whether there is a pair P whose
DRs have or haven't been swapped around.
 
+   DR_ALIAS_MIXED_STEPS:
+   The DR_STEP for one of the data references in the pair does not
+   accurately describe that reference for all members of P.  (Note
+   that the flag does not say anything about whether the DR_STEPs
+   of the two references in the pair are the same.)
+
The ordering assumption mentioned above is that for every pair
(DR_A, DR_B) in P:
 
@@ -287,6 +293,7 @@ const unsigned int DR_ALIAS_WAW = 1U <<
 const unsigned int DR_ALIAS_ARBITRARY = 1U << 3;
 const unsigned int DR_ALIAS_SWAPPED = 1U << 4;
 const unsigned int DR_ALIAS_UNSWAPPED = 1U << 5;
+const unsigned int DR_ALIAS_MIXED_STEPS = 1U << 6;
 
 /* This struct contains two dr_with_seg_len objects with aliasing data
refs.  Two comparisons are generated from them.  */
Index: gcc/tree-data-ref.c
===
--- gcc/tree-data-ref.c 2019-11-11 18:30:50.527193443 +
+++ gcc/tree-data-ref.c 2019-11-11 18:30:53.863170161 +
@@ -1618,6 +1618,11 @@ prune_runtime_alias_test_list (vecdr), DR_STEP (dr_a2->dr), 0))
+   alias_pair1->flags |= DR_ALIAS_MIXED_STEPS;
+
  if (new_seg_len_p)
{
  dr_a1->seg_len = build_int_cst (TREE_TYPE (dr_a1->seg_len),
@@ -1663,11 +1668,14 @@ prune_runtime_alias_test_list (veclength (); i < s; ++i)
+  dr_with_seg_len_pair_t *alias_pair;
+  unsigned int i;
+  FOR_EACH_VEC_ELT (*alias_pairs, i, alias_pair)
 {
-  const dr_with_seg_len& dr_a = (*alias_pairs)[i].first;
-  const dr_with_seg_len& dr_b = (*alias_pairs)[i].second;
-
+  gcc_assert (alias_pair->flags);
   if (dump_enabled_p ())
dump_printf (MSG_NOTE,
 "create runtime check for data references %T and %T\n",
-DR_REF (dr_a.dr), DR_REF (dr_b.dr));
+DR_REF (alias_pair->first.dr),
+DR_REF (alias_pair->second.dr));
 
   /* Create condition expression for each pair data references.  */
-  create_intersect_range_checks (loop, _cond_expr, dr_a, dr_b);
+  create_intersect_range_checks (loop, _cond_expr, *alias_pair);
   if (*cond_expr)
*cond_expr = fold_build2 (TRUTH_AND_EXPR, boolean_type_node,
  *cond_expr, part_cond_expr);

[3/8] Add flags to dr_with_seg_len_pair_t

[Richard Sandiford]

This patch adds a bunch of flags to dr_with_seg_len_pair_t,
for use by later patches.  The update to tree-loop-distribution.c
is conservatively correct, but might be tweakable later.


2019-11-11  Richard Sandiford  

gcc/
* tree-data-ref.h (DR_ALIAS_RAW, DR_ALIAS_WAR, DR_ALIAS_WAW)
(DR_ALIAS_ARBITRARY, DR_ALIAS_SWAPPED, DR_ALIAS_UNSWAPPED): New flags.
(dr_with_seg_len_pair_t::sequencing): New enum.
(dr_with_seg_len_pair_t::flags): New member variable.
(dr_with_seg_len_pair_t::dr_with_seg_len_pair_t): Take a sequencing
parameter and initialize the flags member variable.
* tree-loop-distribution.c (compute_alias_check_pairs): Update
call accordingly.
* tree-vect-data-refs.c (vect_prune_runtime_alias_test_list): Likewise.
Ensure the two data references in an alias pair are in statement
order, if there is a defined order.
* tree-data-ref.c (prune_runtime_alias_test_list): Use
DR_ALIAS_SWAPPED and DR_ALIAS_UNSWAPPED to record whether we've
swapped the references in a dr_with_seg_len_pair_t.  OR together
the flags when merging two dr_with_seg_len_pair_ts.  After merging,
try to restore the original dr_with_seg_len order, updating the
flags if that fails.

Index: gcc/tree-data-ref.h
===
--- gcc/tree-data-ref.h 2019-07-10 19:41:26.383898124 +0100
+++ gcc/tree-data-ref.h 2019-11-11 18:30:50.527193443 +
@@ -222,20 +222,107 @@ typedef struct data_reference *data_refe
   unsigned int align;
 };
 
+/* Flags that describe a potential alias between two dr_with_seg_lens.
+   In general, each pair of dr_with_seg_lens represents a composite of
+   multiple access pairs P, so testing flags like DR_IS_READ on the DRs
+   does not give meaningful information.
+
+   DR_ALIAS_RAW:
+   There is a pair in P for which the second reference is a read
+   and the first is a write.
+
+   DR_ALIAS_WAR:
+   There is a pair in P for which the second reference is a write
+   and the first is a read.
+
+   DR_ALIAS_WAW:
+   There is a pair in P for which both references are writes.
+
+   DR_ALIAS_ARBITRARY:
+   Either
+   (a) it isn't possible to classify one pair in P as RAW, WAW or WAR; or
+   (b) there is a pair in P that breaks the ordering assumption below.
+
+   This flag overrides the RAW, WAR and WAW flags above.
+
+   DR_ALIAS_UNSWAPPED:
+   DR_ALIAS_SWAPPED:
+   Temporary flags that indicate whether there is a pair P whose
+   DRs have or haven't been swapped around.
+
+   The ordering assumption mentioned above is that for every pair
+   (DR_A, DR_B) in P:
+
+   (1) The original code accesses n elements for DR_A and n elements for DR_B,
+   interleaved as follows:
+
+one access of size DR_A.access_size at DR_A.dr
+one access of size DR_B.access_size at DR_B.dr
+one access of size DR_A.access_size at DR_A.dr + STEP_A
+one access of size DR_B.access_size at DR_B.dr + STEP_B
+one access of size DR_A.access_size at DR_A.dr + STEP_A * 2
+one access of size DR_B.access_size at DR_B.dr + STEP_B * 2
+...
+
+   (2) The new code accesses the same data in exactly two chunks:
+
+one group of accesses spanning |DR_A.seg_len| + DR_A.access_size
+one group of accesses spanning |DR_B.seg_len| + DR_B.access_size
+
+   A pair might break this assumption if the DR_A and DR_B accesses
+   in the original or the new code are mingled in some way.  For example,
+   if DR_A.access_size represents the effect of two individual writes
+   to nearby locations, the pair breaks the assumption if those writes
+   occur either side of the access for DR_B.
+
+   Note that DR_ALIAS_ARBITRARY describes whether the ordering assumption
+   fails to hold for any individual pair in P.  If the assumption *does*
+   hold for every pair in P, it doesn't matter whether it holds for the
+   composite pair or not.  In other words, P should represent the complete
+   set of pairs that the composite pair is testing, so only the ordering
+   of two accesses in the same member of P matters.  */
+const unsigned int DR_ALIAS_RAW = 1U << 0;
+const unsigned int DR_ALIAS_WAR = 1U << 1;
+const unsigned int DR_ALIAS_WAW = 1U << 2;
+const unsigned int DR_ALIAS_ARBITRARY = 1U << 3;
+const unsigned int DR_ALIAS_SWAPPED = 1U << 4;
+const unsigned int DR_ALIAS_UNSWAPPED = 1U << 5;
+
 /* This struct contains two dr_with_seg_len objects with aliasing data
refs.  Two comparisons are generated from them.  */
 
 class dr_with_seg_len_pair_t
 {
 public:
-  dr_with_seg_len_pair_t (const dr_with_seg_len& d1,
-  const dr_with_seg_len& d2)
-: first (d1), second (d2) {}
+  /* WELL_ORDERED indicates that the ordering assumption described above
+ DR_ALIAS_ARBITRARY holds.  REORDERED indicates that it doesn't.  */
+  enum sequencing { 

[2/8] Delay swapping data refs in prune_runtime_alias_test_list

[Richard Sandiford]

prune_runtime_alias_test_list swapped dr_as between two dr_with_seg_len
pairs before finally deciding whether to merge them.  Bailing out later
would therefore leave the pairs in an incorrect state.

IMO a better fix would be to split this out into a subroutine that
produces a temporary dr_with_seg_len on success, rather than changing
an existing one in-place.  It would then be easy to merge both the dr_as
and dr_bs if we wanted to, rather than requiring one of them to be equal.
But here I tried to do something that could be backported if necessary.


2019-11-11  Richard Sandiford  

gcc/
* tree-data-ref.c (prune_runtime_alias_test_list): Delay
swapping the dr_as based on init values until we've decided
whether to merge them.

Index: gcc/tree-data-ref.c
===
--- gcc/tree-data-ref.c 2019-11-11 18:30:43.203244558 +
+++ gcc/tree-data-ref.c 2019-11-11 18:30:47.199216669 +
@@ -1556,13 +1556,6 @@ prune_runtime_alias_test_list (vecseg_len, dr_a2->seg_len, 0))
+ poly_uint64 new_seg_len = 0;
+ bool new_seg_len_p = !operand_equal_p (dr_a1->seg_len,
+dr_a2->seg_len, 0);
+ if (new_seg_len_p)
{
  poly_uint64 seg_len_a1, seg_len_a2;
  if (!poly_int_tree_p (dr_a1->seg_len, _len_a1)
@@ -1597,14 +1593,24 @@ prune_runtime_alias_test_list (vec= 0 && sign_b >= 0)
new_seg_len = upper_bound (seg_len_a1, seg_len_a2);
  else
continue;
+   }
+ /* At this point we're committed to merging the refs.  */
 
+ /* Make sure dr_a1 starts left of dr_a2.  */
+ if (maybe_gt (init_a1, init_a2))
+   {
+ std::swap (*dr_a1, *dr_a2);
+ std::swap (init_a1, init_a2);
+   }
+
+ if (new_seg_len_p)
+   {
  dr_a1->seg_len = build_int_cst (TREE_TYPE (dr_a1->seg_len),
  new_seg_len);
  dr_a1->align = MIN (dr_a1->align, known_alignment (new_seg_len));

[1/8] Move canonicalisation of dr_with_seg_len_pair_ts

[Richard Sandiford]

The two users of tree-data-ref's runtime alias checks both canonicalise
the order of the dr_with_seg_lens in a pair before passing them to
prune_runtime_alias_test_list.  It's more convenient for later patches
if prune_runtime_alias_test_list does that itself.


2019-11-11  Richard Sandiford  

gcc/
* tree-data-ref.c (prune_runtime_alias_test_list): Sort the
two accesses in each dr_with_seg_len_pair_t before trying to
combine separate dr_with_seg_len_pair_ts.
* tree-loop-distribution.c (compute_alias_check_pairs): Don't do
that here.
* tree-vect-data-refs.c (vect_prune_runtime_alias_test_list): Likewise.

Index: gcc/tree-data-ref.c
===
--- gcc/tree-data-ref.c 2019-07-18 09:22:13.893767915 +0100
+++ gcc/tree-data-ref.c 2019-11-11 18:30:43.203244558 +
@@ -1487,13 +1487,32 @@ comp_dr_with_seg_len_pair (const void *p
 prune_runtime_alias_test_list (vec *alias_pairs,
   poly_uint64)
 {
+  /* Canonicalize each pair so that the base components are ordered wrt
+ data_ref_compare_tree.  This allows the loop below to merge more
+ cases.  */
+  unsigned int i;
+  dr_with_seg_len_pair_t *alias_pair;
+  FOR_EACH_VEC_ELT (*alias_pairs, i, alias_pair)
+{
+  data_reference_p dr_a = alias_pair->first.dr;
+  data_reference_p dr_b = alias_pair->second.dr;
+  int comp_res = data_ref_compare_tree (DR_BASE_ADDRESS (dr_a),
+   DR_BASE_ADDRESS (dr_b));
+  if (comp_res == 0)
+   comp_res = data_ref_compare_tree (DR_OFFSET (dr_a), DR_OFFSET (dr_b));
+  if (comp_res == 0)
+   comp_res = data_ref_compare_tree (DR_INIT (dr_a), DR_INIT (dr_b));
+  if (comp_res > 0)
+   std::swap (alias_pair->first, alias_pair->second);
+}
+
   /* Sort the collected data ref pairs so that we can scan them once to
  combine all possible aliasing checks.  */
   alias_pairs->qsort (comp_dr_with_seg_len_pair);
 
   /* Scan the sorted dr pairs and check if we can combine alias checks
  of two neighboring dr pairs.  */
-  for (size_t i = 1; i < alias_pairs->length (); ++i)
+  for (i = 1; i < alias_pairs->length (); ++i)
 {
   /* Deal with two ddrs (dr_a1, dr_b1) and (dr_a2, dr_b2).  */
   dr_with_seg_len *dr_a1 = &(*alias_pairs)[i-1].first,
Index: gcc/tree-loop-distribution.c
===
--- gcc/tree-loop-distribution.c2019-07-10 19:41:20.539944929 +0100
+++ gcc/tree-loop-distribution.c2019-11-11 18:30:43.207244530 +
@@ -2457,12 +2457,6 @@ compute_alias_check_pairs (class loop *l
   struct data_reference *dr_a = DDR_A (ddr);
   struct data_reference *dr_b = DDR_B (ddr);
   tree seg_length_a, seg_length_b;
-  int comp_res = data_ref_compare_tree (DR_BASE_ADDRESS (dr_a),
-   DR_BASE_ADDRESS (dr_b));
-
-  if (comp_res == 0)
-   comp_res = data_ref_compare_tree (DR_OFFSET (dr_a), DR_OFFSET (dr_b));
-  gcc_assert (comp_res != 0);
 
   if (latch_dominated_by_data_ref (loop, dr_a))
seg_length_a = data_ref_segment_size (dr_a, niters_plus_one);
@@ -2485,10 +2479,6 @@ compute_alias_check_pairs (class loop *l
(dr_with_seg_len (dr_a, seg_length_a, access_size_a, align_a),
 dr_with_seg_len (dr_b, seg_length_b, access_size_b, align_b));
 
-  /* Canonicalize pairs by sorting the two DR members.  */
-  if (comp_res > 0)
-   std::swap (dr_with_seg_len_pair.first, dr_with_seg_len_pair.second);
-
   comp_alias_pairs->safe_push (dr_with_seg_len_pair);
 }
 
Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c   2019-11-08 16:06:18.948980179 +
+++ gcc/tree-vect-data-refs.c   2019-11-11 18:30:43.207244530 +
@@ -3478,7 +3478,6 @@ vect_prune_runtime_alias_test_list (loop
   /* First, we collect all data ref pairs for aliasing checks.  */
   FOR_EACH_VEC_ELT (may_alias_ddrs, i, ddr)
 {
-  int comp_res;
   poly_uint64 lower_bound;
   tree segment_length_a, segment_length_b;
   unsigned HOST_WIDE_INT access_size_a, access_size_b;
@@ -3594,14 +3593,11 @@ vect_prune_runtime_alias_test_list (loop
   align_a = vect_vfa_align (dr_info_a);
   align_b = vect_vfa_align (dr_info_b);
 
-  comp_res = data_ref_compare_tree (DR_BASE_ADDRESS (dr_info_a->dr),
-   DR_BASE_ADDRESS (dr_info_b->dr));
-  if (comp_res == 0)
-   comp_res = data_ref_compare_tree (DR_OFFSET (dr_info_a->dr),
- DR_OFFSET (dr_info_b->dr));
-
   /* See whether the alias is known at compilation time.  */
-  if (comp_res == 0
+  if (operand_equal_p (DR_BASE_ADDRESS (dr_info_a->dr),
+  DR_BASE_ADDRESS (dr_info_b->dr), 0)
+ && operand_equal_p (DR_OFFSET 

[0/8] Improve vector alias checks for WAR and WAW dependencies

[Richard Sandiford]

For:

  void
  f1 (int *x, int *y)
  {
for (int i = 0; i < 32; ++i)
  x[i] += y[i];
  }

we check at runtime whether one vector at x would overlap one vector at y.
But in cases like this, the vector code would handle x <= y just fine,
since any write to address A still happens after any read from address A.
The only problem is if x is ahead of y by less than a vector.

The same is true for two writes:

  void
  f2 (int *x, int *y)
  {
for (int i = 0; i < 32; ++i)
  {
x[i] = i;
y[i] = 2;
  }
  }

If y <= x then a vector write at y after a vector write at x would
have the same net effect as the original scalar writes.

Read-after-write cases like:

  int
  f3 (int *x, int *y)
  {
int res = 0;
for (int i = 0; i < 32; ++i)
  {
x[i] = i;
res += y[i];
  }
return res;
  }

can cope with x == y, but otherwise don't allow overlap in either
direction.  Since checking for x == y at runtime would require extra
code, we're probably better off sticking with the current overlap test.

An overlap test is also needed if the scalar or vector accesses covered
by the alias check are mixed together, rather than all statements for
the second access following all statements for the first access.

This patch series tracks whether accesses in an alias check are
well-ordered, and also tracks which combination of RAW, WAR and WAW
dependencies the alias check covers.  It then uses a more relaxed
condition for well-ordered WAR and WAW alias checks.

The most important case this allows is equal addresses/indices for WAR
dependencies.  E.g. more realistic instances of functions like f1 can
support both "constructive" and "destructive" operations, where the
destination pointer is explicitly allowed to be the same as a source
pointer or point to an independent object.

The series probably doesn't help other cases that much in practice.
However, the checks involved are just as simple as (and sometimes
slightly simpler than) the corresponding overlap tests, so there should
be no downside to using the more relaxed tests whenever we can.

The main reason for doing this now is that SVE2 has instructions that
detect RAW and WAR/WAW hazards between two vector pointers.  A follow-on
patch adds support for them.

Each patch tested individually on aarch64-linux-gnu and the series
as a whole on x86_64-linux-gnu.  OK to install?

Richard

Re: [RFC] Only warn for maybe-uninitialized SRAed bits in -Wextra (PR 80635)

[Martin Sebor]

On 11/11/19 10:29 AM, Martin Jambor wrote:

Hi,

On Mon, Nov 11 2019, Martin Sebor wrote:

On 11/8/19 5:41 AM, Martin Jambor wrote:

Hi,

this patch is an attempt to implement my idea from a previous thread
about moving -Wmaybe-uninitialized to -Wextra:

https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00220.html

Specifically, it attempts to split -Wmaybe-uninitialized into those that
are about SRA DECLs and those which are not, and move to -Wextra only
the former ones.  The main idea is that false -Wmaybe-uninitialized
warings about values that are scalar in user's code are easy to silence
by initializing them to zero or something, as opposed to bits of
aggregates such as a value in std::optional which are not.  Therefore,
the warnings about user-scalars can remain in -Wall but warnings about
SRAed pieces should be moved to -Wextra.

The patch is a bit bigger because of documentation (which I'll be happy
to improve based on your suggestions) and testsuite churn, but the main
bit is the following added test in warn_uninit function:

if (wc == OPT_Wmaybe_uninitialized
&& SSA_NAME_VAR (t)
&& DECL_ARTIFICIAL (SSA_NAME_VAR (t))
&& DECL_HAS_DEBUG_EXPR_P (SSA_NAME_VAR (t)))
  {
if (warn_maybe_uninitialized_aggregates)
wc = OPT_Wmaybe_uninitialized_aggregates;
else
return;
  }

The reason why I also test DECL_HAS_DEBUG_EXPR_P is
gfortran.dg/pr39666-2.f90 - without it the test silences a warning about
a decl representing the return value which is an artificial scalar
variable (probably all the way from the front-end).  We can of course
not care about not warning for it but then I don't know how to call and
document the new option :-)  Generally, if someone can think of a better
test to identify SRA DECLs, I'll be happy to change that.  We might put
a bit to identify SRA decls in the decl tree, but I tend to think that
is not a good use of the few remaining bits there.

What do you think, is something along these lines a good idea?

Thanks,

Martin



2019-11-08  Martin Jambor  

* common.opt (Wmaybe-uninitialized-aggregates): New.
* tree-ssa-uninit.c (gate_warn_uninitialized): Also run if
warn_maybe_uninitialized_aggregates is set.
(warn_uninit): Warn for artificial DECLs only if
warn_maybe_uninitialized_aggregates is set.
* doc/invoke.texi (Warning Options): Add
-Wmaybe-uninitialized-aggregates to the list.
(-Wextra): Likewise.
(-Wmaybe-uninitialized): Document that it only works on scalars.
(-Wmaybe-uninitialized-aggregates): Document.

testsuite/
* gcc.dg/pr45083.c: Add Wmaybe-uninitialized-aggregates to options.
* gcc.dg/ubsan/pr81981.c: Likewise.
* gfortran.dg/pr25923.f90: Likewise.
* g++.dg/warn/pr80635.C: New.
---
   gcc/common.opt|  4 +++
   gcc/doc/invoke.texi   | 18 +--
   gcc/testsuite/g++.dg/warn/pr80635.C   | 45 +++
   gcc/testsuite/gcc.dg/pr45083.c|  2 +-
   gcc/testsuite/gcc.dg/ubsan/pr81981.c  |  2 +-
   gcc/testsuite/gfortran.dg/pr25923.f90 |  2 +-
   gcc/tree-ssa-uninit.c | 14 -
   7 files changed, 81 insertions(+), 6 deletions(-)
   create mode 100644 gcc/testsuite/g++.dg/warn/pr80635.C

diff --git a/gcc/common.opt b/gcc/common.opt
index cc279f411d7..03769299df8 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -783,6 +783,10 @@ Wmaybe-uninitialized
   Common Var(warn_maybe_uninitialized) Warning EnabledBy(Wuninitialized)
   Warn about maybe uninitialized automatic variables.
   
+Wmaybe-uninitialized-aggregates

+Common Var(warn_maybe_uninitialized_aggregates) Warning EnabledBy(Wextra)
+Warn about maybe uninitialized automatic parts of aggregates.
+
   Wunreachable-code
   Common Ignore Warning
   Does nothing. Preserved for backward compatibility.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index faa7fa95a0e..dbc3219b770 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -328,7 +328,8 @@ Objective-C and Objective-C++ Dialects}.
   -Wzero-length-bounds @gol
   -Winvalid-pch  -Wlarger-than=@var{byte-size} @gol
   -Wlogical-op  -Wlogical-not-parentheses  -Wlong-long @gol
--Wmain  -Wmaybe-uninitialized  -Wmemset-elt-size  -Wmemset-transposed-args @gol
+-Wmain  -Wmaybe-uninitialized -Wmaybe-uninitialized-aggregates @gol
+-Wmemset-elt-size  -Wmemset-transposed-args @gol
   -Wmisleading-indentation  -Wmissing-attributes  -Wmissing-braces @gol
   -Wmissing-field-initializers  -Wmissing-format-attribute @gol
   -Wmissing-include-dirs  -Wmissing-noreturn  -Wmissing-profile @gol
@@ -4498,6 +4499,7 @@ name is still supported, but the newer name is more 
descriptive.)
   -Wempty-body  @gol
   -Wignored-qualifiers @gol
   -Wimplicit-fallthrough=3 @gol
+-Wmaybe-uninitialized-aggregates @gol
   -Wmissing-field-initializers  @gol
   -Wmissing-parameter-type @r{(C only)}  @gol
   

Re: [golang-dev] [PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Mon, 11 Nov 2019, Ian Lance Taylor wrote:

> > Go's project doesn't take mail patches for changes. Please use gerrit ( 
> > https://go-review.googlesource.com/ ).
> 
> These patches are for gccgo, not the gc toolchain.  They should
> probably have been sent to gofrontend-dev rather than golang-dev.  The
> gccgo repo does take patches via e-mail; I route them through Gerrit
> as needed.

 I may have misinterpreted this paragraph[1]:

"Submitting Changes

   Changes to the Go frontend should follow the same process as for the
   main Go repository, only for the gofrontend project and the
   gofrontend-...@googlegroups.com mailing list rather than the go project
   and the golang-...@googlegroups.com mailing list. Those changes will
   then be merged into the GCC sources."

Sorry about that; I think it might benefit from a rewrite for clarity 
though.

References:

[1] "Contributing to the gccgo frontend - The Go Programming Language", 


  Maciej

Re: [golang-dev] [PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Mon, 11 Nov 2019, Ulderico Cirello wrote:

> Go's project doesn't take mail patches for changes. Please use gerrit (
> https://go-review.googlesource.com/ ).

 Thanks for your reply; this is however too much effort for my limited 
resources and a one-off change.

 The reason is I'm not actively working on Go and I have only enabled Go 
frontend compilation/verification for my RISC-V effort in case there is a 
regression caused by a machine backend change that happens to only trigger 
for the Go frontend so that it does not go unnoticed.

 I have provided this change in a hope it is useful to the community and 
in these circumstances hopefully someone actually interested in Go will 
pick up and merge this change; otherwise I will drop my local change and 
consequently Go verification once GCC 10 has been released.

 Thank you for your understanding.

  Maciej

Re: [golang-dev] [PATCH 0/4] Fix library testsuite compilation for build sysroot

[Ian Lance Taylor]

On Mon, Nov 11, 2019 at 10:31 AM Kaz Kylheku (libffi)
<382-725-6...@kylheku.com> wrote:
>
> On 2019-11-11 10:15, Ulderico Cirello wrote:
> > Hi Maciej,
> >
> > Go's project doesn't take mail patches for changes.
>
> Is it that they'd have to read man pages and learn how to use common
> utilities?
>
> Or that nobody has written a "patch in Go" yet?

Please be polite; thanks.  There are many advantages to using Gerrit
for code review.  It has nothing to do with reading man pages or using
the patch program.

Ian

Re: [golang-dev] [PATCH 0/4] Fix library testsuite compilation for build sysroot

[Ian Lance Taylor]

On Mon, Nov 11, 2019 at 10:15 AM Ulderico Cirello
 wrote:
>
> Go's project doesn't take mail patches for changes. Please use gerrit ( 
> https://go-review.googlesource.com/ ).

These patches are for gccgo, not the gc toolchain.  They should
probably have been sent to gofrontend-dev rather than golang-dev.  The
gccgo repo does take patches via e-mail; I route them through Gerrit
as needed.

Ian

Re: [PATCH] Bump minimum MPFR version to 3.1.0

[Joseph Myers]

On Sat, 9 Nov 2019, Janne Blomqvist wrote:

> Bump the minimum MPFR version to 3.1.0, released 2011-10-03. With this
> requirement one can still build GCC with the operating system provided
> MPFR on old but still supported operating systems like SLES 12 (MPFR
> 3.1.2) or RHEL/CentOS 7.x (MPFR 3.1.1).
> 
> This allows removing some code in the Fortran frontend, as well as
> fixing PR 91828.

As a remark, beyond the cases where this allows conditional code to be 
removed, there are also possible cleanups where GCC is currently using 
MPFR constants / types that are documented as obsolescent 
.

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

Re: [golang-dev] [PATCH 0/4] Fix library testsuite compilation for build sysroot

[Kaz Kylheku (libffi)]

On 2019-11-11 10:15, Ulderico Cirello wrote:

Hi Maciej,

Go's project doesn't take mail patches for changes.


Is it that they'd have to read man pages and learn how to use common 
utilities?


Or that nobody has written a "patch in Go" yet?

[PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

Hi,

 This patch series addresses a problem with the testsuite compiler being 
set up across libatomic, libffi, libgo, libgomp with no correlation 
whatsoever to the target compiler being used in GCC compilation.  
Consequently there in no arrangement made to set up the compilation 
sysroot according to the build sysroot specified for GCC compilation, 
causing a catastrophic failure across the testsuites affected from the 
inability to link executables.

 The fix is based on a similar arrangement already made for passing 
autoconf output variables in libgomp, and uses the GCC_UNDER_TEST (or 
GOC_UNDER_TEST, as applicable) TCL variable already used across several 
GCC library testsuites.

 Verified with a cross-compiler configured for the `riscv-linux-gnu' 
target and the `x86_64-linux-gnu' host and using RISC-V/Linux QEMU in the 
user emulation mode as the target board.  Also no change in results with 
`x86_64-linux-gnu' native regression testing.

 See individual change descriptions for details.

 OK to apply to the GCC repo (for libraries maintained externally I'll be 
happy to assist with any merging required, although given that these 
changes are confined to autoconf/automake scriptery they should be 
straightforward to apply, barring any conflicts in generated files)?

  Maciej

[PATCH 3/4] libgo/test: Fix compilation for build sysroot

[Maciej W. Rozycki]

Fix a problem with the libgo testsuite using a method to determine the 
compiler to use resulting in the tool being different from one the 
library has been built with, and causing a catastrophic failure from the 
lack of a suitable `--sysroot=' option where the `--with-build-sysroot=' 
configuration option has been used to build the compiler resulting in 
the inability to link executables.

Address this problem by providing a DejaGNU configuration file defining 
the compiler to use, via the GOC_UNDER_TEST TCL variable, set from $GOC 
by autoconf, which will have all the required options set for the target 
compiler to build executables in the environment configured, removing 
failures like:

.../bin/riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory
.../bin/riscv64-linux-gnu-ld: cannot find -lm
.../bin/riscv64-linux-gnu-ld: cannot find -lc
collect2: error: ld returned 1 exit status
compiler exited with status 1

No summary comparison, because the libgo testsuite does not provide one 
in this configuration for some reason, however this change improves 
overall test results for the `riscv64-linux-gnu' target (here with the 
`x86_64-linux-gnu' host and RISC-V QEMU in the Linux user emulation mode 
as the target board) from 0 PASSes and 159 FAILs to 133 PASSes and 26 
FAILs.

libgo/
* configure.ac: Add testsuite/libgo-test-support.exp to output 
files.
* configure: Regenerate.
* testsuite/libgo-test-support.exp.in: New file.
* testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New 
variable.
* testsuite/Makefile.in: Regenerate.
* testsuite/lib/libgo.exp: Don't override GOC_UNDER_TEST 
previously set.
---
 libgo/configure   |3 ++-
 libgo/configure.ac|2 +-
 libgo/testsuite/Makefile.am   |2 ++
 libgo/testsuite/Makefile.in   |5 -
 libgo/testsuite/lib/libgo.exp |   13 -
 libgo/testsuite/libgo-test-support.exp.in |1 +
 6 files changed, 18 insertions(+), 8 deletions(-)

gcc-test-libgo-gcc-under-test.diff
Index: gcc/libgo/configure
===
--- gcc.orig/libgo/configure
+++ gcc/libgo/configure
@@ -15850,7 +15850,7 @@ else
   multilib_arg=
 fi
 
-ac_config_files="$ac_config_files Makefile testsuite/Makefile"
+ac_config_files="$ac_config_files Makefile testsuite/Makefile 
testsuite/libgo-test-support.exp"
 
 
 ac_config_commands="$ac_config_commands default"
@@ -17031,6 +17031,7 @@ do
 "libtool") CONFIG_COMMANDS="$CONFIG_COMMANDS libtool" ;;
 "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;;
 "testsuite/Makefile") CONFIG_FILES="$CONFIG_FILES testsuite/Makefile" ;;
+"testsuite/libgo-test-support.exp") CONFIG_FILES="$CONFIG_FILES 
testsuite/libgo-test-support.exp" ;;
 "default") CONFIG_COMMANDS="$CONFIG_COMMANDS default" ;;
 
   *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5;;
Index: gcc/libgo/configure.ac
===
--- gcc.orig/libgo/configure.ac
+++ gcc/libgo/configure.ac
@@ -877,7 +877,7 @@ else
   multilib_arg=
 fi
 
-AC_CONFIG_FILES(Makefile testsuite/Makefile)
+AC_CONFIG_FILES(Makefile testsuite/Makefile testsuite/libgo-test-support.exp)
 
 AC_CONFIG_COMMANDS([default],
 [if test -n "$CONFIG_FILES"; then
Index: gcc/libgo/testsuite/Makefile.am
===
--- gcc.orig/libgo/testsuite/Makefile.am
+++ gcc/libgo/testsuite/Makefile.am
@@ -11,6 +11,8 @@ RUNTEST = `if [ -f $(top_srcdir)/../deja
   echo $(top_srcdir)/../dejagnu/runtest ; \
else echo runtest; fi`
 
+EXTRA_DEJAGNU_SITE_CONFIG = libgo-test-support.exp
+
 # When running the tests we set GCC_EXEC_PREFIX to the install tree so that
 # files that have already been installed there will be found.  The -B option
 # overrides it, so use of GCC_EXEC_PREFIX will not result in using GCC files
Index: gcc/libgo/testsuite/Makefile.in
===
--- gcc.orig/libgo/testsuite/Makefile.in
+++ gcc/libgo/testsuite/Makefile.in
@@ -106,7 +106,7 @@ am__configure_deps = $(am__aclocal_m4_de
 DIST_COMMON = $(srcdir)/Makefile.am
 mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs
 CONFIG_HEADER = $(top_builddir)/config.h
-CONFIG_CLEAN_FILES =
+CONFIG_CLEAN_FILES = libgo-test-support.exp
 CONFIG_CLEAN_VPATH_FILES =
 AM_V_P = $(am__v_P_@AM_V@)
 am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
@@ -299,6 +299,7 @@ RUNTEST = `if [ -f $(top_srcdir)/../deja
   echo $(top_srcdir)/../dejagnu/runtest ; \
else echo runtest; fi`
 
+EXTRA_DEJAGNU_SITE_CONFIG = libgo-test-support.exp
 
 # When running the tests we set GCC_EXEC_PREFIX to the install tree so that
 # files that have already been installed there will be found.  The -B option
@@ -338,6 +339,8 @@ 

[PATCH 1/4] libatomic/test: Fix compilation for build sysroot

[Maciej W. Rozycki]

Fix a problem with the libatomic testsuite using a method to determine 
the compiler to use resulting in the tool being different from one the 
library has been built with, and causing a catastrophic failure from the 
lack of a suitable `--sysroot=' option where the `--with-build-sysroot=' 
configuration option has been used to build the compiler resulting in 
the inability to link executables.

Address this problem by providing a DejaGNU configuration file defining 
the compiler to use, via the GCC_UNDER_TEST TCL variable, set from $CC 
by autoconf, which will have all the required options set for the target 
compiler to build executables in the environment configured, removing 
failures like:

.../bin/riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory
.../bin/riscv64-linux-gnu-ld: cannot find -lm
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: libatomic.c/atomic-compare-exchange-1.c (test for excess errors)
Excess errors:
.../bin/riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory
.../bin/riscv64-linux-gnu-ld: cannot find -lm

UNRESOLVED: libatomic.c/atomic-compare-exchange-1.c compilation failed to 
produce executable

and bringing overall test results for the `riscv64-linux-gnu' target 
(here with the `x86_64-linux-gnu' host and RISC-V QEMU in the Linux user 
emulation mode as the target board) from:

=== libatomic Summary ===

# of unexpected failures27
# of unresolved testcases   27

to:

=== libatomic Summary ===

# of expected passes54

libatomic/
* configure.ac: Add testsuite/libatomic-test-support.exp to 
output files.
* configure: Regenerate.
* testsuite/libatomic-test-support.exp.in: New file.
* testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New 
variable.
* testsuite/Makefile.in: Regenerate.
---
 libatomic/configure   |3 +++
 libatomic/configure.ac|1 +
 libatomic/testsuite/Makefile.am   |2 ++
 libatomic/testsuite/Makefile.in   |5 -
 libatomic/testsuite/libatomic-test-support.exp.in |1 +
 5 files changed, 11 insertions(+), 1 deletion(-)

gcc-test-libatomic-gcc-under-test.diff
Index: gcc/libatomic/configure
===
--- gcc.orig/libatomic/configure
+++ gcc/libatomic/configure
@@ -15701,6 +15701,8 @@ fi
 
 ac_config_files="$ac_config_files Makefile testsuite/Makefile"
 
+ac_config_files="$ac_config_files testsuite/libatomic-test-support.exp"
+
 cat >confcache <<\_ACEOF
 # This file is a shell script that caches the results of configure
 # tests run on this system so they can be shared between configure
@@ -16772,6 +16774,7 @@ do
 "gstdint.h") CONFIG_COMMANDS="$CONFIG_COMMANDS gstdint.h" ;;
 "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;;
 "testsuite/Makefile") CONFIG_FILES="$CONFIG_FILES testsuite/Makefile" ;;
+"testsuite/libatomic-test-support.exp") CONFIG_FILES="$CONFIG_FILES 
testsuite/libatomic-test-support.exp" ;;
 
   *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5;;
   esac
Index: gcc/libatomic/configure.ac
===
--- gcc.orig/libatomic/configure.ac
+++ gcc/libatomic/configure.ac
@@ -279,4 +279,5 @@ else
 fi
 
 AC_CONFIG_FILES(Makefile testsuite/Makefile)
+AC_CONFIG_FILES(testsuite/libatomic-test-support.exp)
 AC_OUTPUT
Index: gcc/libatomic/testsuite/Makefile.am
===
--- gcc.orig/libatomic/testsuite/Makefile.am
+++ gcc/libatomic/testsuite/Makefile.am
@@ -11,3 +11,5 @@ EXPECT = $(shell if test -f $(top_buildd
 _RUNTEST = $(shell if test -f $(top_srcdir)/../dejagnu/runtest; then \
 echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
 RUNTEST = $(_RUNTEST) $(AM_RUNTESTFLAGS)
+
+EXTRA_DEJAGNU_SITE_CONFIG = libatomic-test-support.exp
Index: gcc/libatomic/testsuite/Makefile.in
===
--- gcc.orig/libatomic/testsuite/Makefile.in
+++ gcc/libatomic/testsuite/Makefile.in
@@ -108,7 +108,7 @@ am__configure_deps = $(am__aclocal_m4_de
 DIST_COMMON = $(srcdir)/Makefile.am
 mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs
 CONFIG_HEADER = $(top_builddir)/auto-config.h
-CONFIG_CLEAN_FILES =
+CONFIG_CLEAN_FILES = libatomic-test-support.exp
 CONFIG_CLEAN_VPATH_FILES =
 AM_V_P = $(am__v_P_@AM_V@)
 am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
@@ -277,6 +277,7 @@ _RUNTEST = $(shell if test -f $(top_srcd
 echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
 
 RUNTEST = $(_RUNTEST) $(AM_RUNTESTFLAGS)
+EXTRA_DEJAGNU_SITE_CONFIG = libatomic-test-support.exp
 all: all-am
 
 .SUFFIXES:
@@ -309,6 +310,8 @@ $(top_srcdir)/configure: @MAINTAINER_MOD
 $(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ 

Re: [golang-dev] [PATCH 0/4] Fix library testsuite compilation for build sysroot

[Ulderico Cirello]

Hi Maciej,


Go's project doesn't take mail patches for changes. Please use gerrit (
https://go-review.googlesource.com/ ).


Thanks





- ccf


On Mon, Nov 11, 2019 at 10:12 AM Maciej W. Rozycki  wrote:

> Hi,
>
>  This patch series addresses a problem with the testsuite compiler being
> set up across libatomic, libffi, libgo, libgomp with no correlation
> whatsoever to the target compiler being used in GCC compilation.
> Consequently there in no arrangement made to set up the compilation
> sysroot according to the build sysroot specified for GCC compilation,
> causing a catastrophic failure across the testsuites affected from the
> inability to link executables.
>
>  The fix is based on a similar arrangement already made for passing
> autoconf output variables in libgomp, and uses the GCC_UNDER_TEST (or
> GOC_UNDER_TEST, as applicable) TCL variable already used across several
> GCC library testsuites.
>
>  Verified with a cross-compiler configured for the `riscv-linux-gnu'
> target and the `x86_64-linux-gnu' host and using RISC-V/Linux QEMU in the
> user emulation mode as the target board.  Also no change in results with
> `x86_64-linux-gnu' native regression testing.
>
>  See individual change descriptions for details.
>
>  OK to apply to the GCC repo (for libraries maintained externally I'll be
> happy to assist with any merging required, although given that these
> changes are confined to autoconf/automake scriptery they should be
> straightforward to apply, barring any conflicts in generated files)?
>
>   Maciej
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-dev/alpine.LFD.2.21.1911081714120.13542%40redsun52.ssa.fujisawa.hgst.com
> .
>

[PATCH 4/4] libgomp/test: Fix compilation for build sysroot

[Maciej W. Rozycki]

Fix a problem with the libgomp testsuite using a method to determine 
the compiler to use resulting in the tool being different from one the 
library has been built with, and causing a catastrophic failure from the 
lack of a suitable `--sysroot=' option where the `--with-build-sysroot=' 
configuration option has been used to build the compiler resulting in 
the inability to link executables.

Address this problem by defining the compiler to use, via the 
GCC_UNDER_TEST TCL variable, set in the DejaGNU configuration file from 
$CC by autoconf, which will have all the required options set for the 
target compiler to build executables in the environment configured, 
removing failures like:

.../bin/riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory
.../bin/riscv64-linux-gnu-ld: cannot find -lm
.../bin/riscv64-linux-gnu-ld: cannot find -lpthread
.../bin/riscv64-linux-gnu-ld: cannot find -lc
.../bin/riscv64-linux-gnu-ld: cannot find -latomic
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: libgomp.c/../libgomp.c-c++-common/atomic-18.c (test for excess errors)
Excess errors:
.../bin/riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory
.../bin/riscv64-linux-gnu-ld: cannot find -lm
.../bin/riscv64-linux-gnu-ld: cannot find -lpthread
.../bin/riscv64-linux-gnu-ld: cannot find -lc
.../bin/riscv64-linux-gnu-ld: cannot find -latomic

UNRESOLVED: libgomp.c/../libgomp.c-c++-common/atomic-18.c compilation failed to 
produce executable

and bringing overall test results for the `riscv64-linux-gnu' target 
(here with the `x86_64-linux-gnu' host and RISC-V QEMU in the Linux user 
emulation mode as the target board) from:

=== libgomp Summary ===

# of expected passes44
# of unexpected failures3274
# of unresolved testcases   3241
# of unsupported tests  548

to:

=== libgomp Summary ===

# of expected passes6834
# of unexpected failures4
# of expected failures  4
# of unsupported tests  518

libgomp/
* testsuite/libgomp-test-support.exp.in (GCC_UNDER_TEST): New 
variable.
---
 libgomp/testsuite/libgomp-test-support.exp.in |2 ++
 1 file changed, 2 insertions(+)

gcc-test-libgomp-gcc-under-test.diff
Index: gcc/libgomp/testsuite/libgomp-test-support.exp.in
===
--- gcc.orig/libgomp/testsuite/libgomp-test-support.exp.in
+++ gcc/libgomp/testsuite/libgomp-test-support.exp.in
@@ -1,3 +1,5 @@
+set GCC_UNDER_TEST {@CC@}
+
 set cuda_driver_include "@CUDA_DRIVER_INCLUDE@"
 set cuda_driver_lib "@CUDA_DRIVER_LIB@"
 set hsa_runtime_lib "@HSA_RUNTIME_LIB@"

[PATCH 2/4] libffi/test: Fix compilation for build sysroot

[Maciej W. Rozycki]

Fix a problem with the libffi testsuite using a method to determine the 
compiler to use resulting in the tool being different from one the 
library has been built with, and causing a catastrophic failure from the 
inability to actually choose any compiler at all in a cross-compilation
configuration.

Address this problem by providing a DejaGNU configuration file defining 
the compiler to use, via the GCC_UNDER_TEST TCL variable, set from $CC 
by autoconf, which will have all the required options set for the target 
compiler to build executables in the environment configured, removing 
failures like:

FAIL: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 (test for excess errors)
Excess errors:
default_target_compile: No compiler to compile with
UNRESOLVED: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 compilation 
failed to produce executable

and bringing overall test results for the `riscv64-linux-gnu' target 
(here with the `x86_64-linux-gnu' host and RISC-V QEMU in the Linux user 
emulation mode as the target board) from:

=== libffi Summary ===

# of unexpected failures708
# of unresolved testcases   708
# of unsupported tests  30

to:

=== libffi Summary ===

# of expected passes1934
# of unsupported tests  28

Also respect the TOOL_EXECUTABLE TCL variable for a standalone run via 
`runtest' and remove an unused TOOL_OPTIONS TCL variable instance.

libffi/
* configure.ac: Add testsuite/libffi-test-support.exp to output 
files.
* configure: Regenerate.
* testsuite/libffi-test-support.exp.in: New file.
* testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New 
variable.
* testsuite/Makefile.in: Regenerate.
* testsuite/lib/libffi.exp (libffi-init): Handle GCC_UNDER_TEST.
(libffi_target_compile): Likewise.
---
 libffi/configure|3 ++-
 libffi/configure.ac |2 +-
 libffi/testsuite/Makefile.am|2 ++
 libffi/testsuite/Makefile.in|5 -
 libffi/testsuite/lib/libffi.exp |   16 ++--
 libffi/testsuite/libffi-test-support.exp.in |1 +
 6 files changed, 24 insertions(+), 5 deletions(-)

gcc-test-libffi-gcc-under-test.diff
Index: gcc/libffi/configure
===
--- gcc.orig/libffi/configure
+++ gcc/libffi/configure
@@ -16635,7 +16635,7 @@ ac_config_commands="$ac_config_commands
 ac_config_links="$ac_config_links 
include/ffitarget.h:src/$TARGETDIR/ffitarget.h"
 
 
-ac_config_files="$ac_config_files include/Makefile include/ffi.h Makefile 
testsuite/Makefile man/Makefile libffi.pc"
+ac_config_files="$ac_config_files include/Makefile include/ffi.h Makefile 
testsuite/Makefile testsuite/libffi-test-support.exp man/Makefile libffi.pc"
 
 
 cat >confcache <<\_ACEOF
@@ -17802,6 +17802,7 @@ do
 "include/ffi.h") CONFIG_FILES="$CONFIG_FILES include/ffi.h" ;;
 "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;;
 "testsuite/Makefile") CONFIG_FILES="$CONFIG_FILES testsuite/Makefile" ;;
+"testsuite/libffi-test-support.exp") CONFIG_FILES="$CONFIG_FILES 
testsuite/libffi-test-support.exp" ;;
 "man/Makefile") CONFIG_FILES="$CONFIG_FILES man/Makefile" ;;
 "libffi.pc") CONFIG_FILES="$CONFIG_FILES libffi.pc" ;;
 
Index: gcc/libffi/configure.ac
===
--- gcc.orig/libffi/configure.ac
+++ gcc/libffi/configure.ac
@@ -368,6 +368,6 @@ test -d src/$TARGETDIR || mkdir src/$TAR
 
 AC_CONFIG_LINKS(include/ffitarget.h:src/$TARGETDIR/ffitarget.h)
 
-AC_CONFIG_FILES(include/Makefile include/ffi.h Makefile testsuite/Makefile 
man/Makefile libffi.pc)
+AC_CONFIG_FILES(include/Makefile include/ffi.h Makefile testsuite/Makefile 
testsuite/libffi-test-support.exp man/Makefile libffi.pc)
 
 AC_OUTPUT
Index: gcc/libffi/testsuite/Makefile.am
===
--- gcc.orig/libffi/testsuite/Makefile.am
+++ gcc/libffi/testsuite/Makefile.am
@@ -11,6 +11,8 @@ RUNTEST = `if [ -f $(top_srcdir)/../deja
   echo $(top_srcdir)/../dejagnu/runtest ; \
else echo runtest; fi`
 
+EXTRA_DEJAGNU_SITE_CONFIG = libffi-test-support.exp
+
 AM_RUNTESTFLAGS =
 
 CLEANFILES = *.exe core* *.log *.sum
Index: gcc/libffi/testsuite/Makefile.in
===
--- gcc.orig/libffi/testsuite/Makefile.in
+++ gcc/libffi/testsuite/Makefile.in
@@ -105,7 +105,7 @@ am__configure_deps = $(am__aclocal_m4_de
 DIST_COMMON = $(srcdir)/Makefile.am
 mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs
 CONFIG_HEADER = $(top_builddir)/fficonfig.h
-CONFIG_CLEAN_FILES =
+CONFIG_CLEAN_FILES = libffi-test-support.exp
 CONFIG_CLEAN_VPATH_FILES =
 AM_V_P = $(am__v_P_@AM_V@)
 am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
@@ -278,6 +278,7 @@ RUNTEST = `if [ -f 

[PATCH][vect]PR92347: Don't overwrite safelen for epilogues

[Andre Vieira (lists)]

Hi,

After during my investigation into the first testcase in PR92347 I 
noticed that the ICE was arising because the vectorizer was under the 
assumption it knew how to vectorize the zp call for both the main and 
epilogues.  By the time it got to transform the epilogue 
vectorizable_simd_clone_call would fail, leading to the eventual ICE. 
The reason was because the main loop's safelen was set to MAX_INT at 
time of analysis, but 0 for the epilogue at the time of its 
transformation.  This was because we were copying the loop's safelen to 
the epilogue after vectorizing the main loop and we set safelen to 0 
when we are done vectorizing.  This resulted in the epilogue always 
having safelen set to 0 at transformation time.


I believe its safe to assume that if the main loop can assume that it is 
safe to vectorize between 0 and safelen then so is the epilogue in this 
context.


Bootstrapped x86_64 and aarch64 and ran libgomp.

Is this OK for trunk? (If approved can someone commit on my behalf as 
I'll be away for two weeks?)


Cheers,
Andre

gcc/ChangeLog:
2019-11-11  Andre Vieira  

* tree-vect-loop.c (vect_transform_loop): Don't overwrite epilogues
safelen with 0.

gcc/testsuite/ChangeLog:
2019-11-11  Andre Vieira  

* gcc.dg/vect/pr92347.c: New test.
diff --git a/gcc/testsuite/gcc.dg/vect/pr92347.c b/gcc/testsuite/gcc.dg/vect/pr92347.c
new file mode 100644
index ..f7e6b490c837f209e9a574d6f10e1e2e34e4729e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr92347.c
@@ -0,0 +1,18 @@
+/* Copied from PR 92347.  */
+/* { dg-do compile } */
+/* { dg-options "-O1 -fopenmp" } */
+/* { dg-additional-options "-mavx" { target { i?86-*-* x86_64-*-* } } } */
+
+int by;
+
+#pragma omp declare simd
+int
+zp (int);
+
+void
+qh (int oh)
+{
+#pragma omp simd
+for (by = 0; by < oh; ++by)
+  by = zp (by);
+}
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 78fe6290ee6bf069f7cfaabba466f119e41f39ac..b600d3157457c3180d0456c4f66cbc57012e3c71 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -8587,7 +8587,6 @@ vect_transform_loop (loop_vec_info loop_vinfo)
 
   epilogue->simduid = loop->simduid;
   epilogue->force_vectorize = loop->force_vectorize;
-  epilogue->safelen = loop->safelen;
   epilogue->dont_vectorize = false;
 }
 

Re: [PATCH, GCC] Fix unrolling check.

[Sudakshina Das]

On 11/11/2019 14:50, Eric Botcazou wrote:
>> Thanks for the explanation. However, I do not understand why are we
>> returning with the default value.
> 
> The regression you reported should be clear enough though: if we don't do
> that, we will unroll in cases where we would not have before.  Try with a
> compiler that predates the pragma and compare, there should be no changes.
> 
>> What "do we always do"?
> 
> What we do in the absence of specific unrolling directives for the loop.

Yeah fair enough! Sorry for the trouble.

Sudi
> 

Re: [RFC] Only warn for maybe-uninitialized SRAed bits in -Wextra (PR 80635)

[Martin Jambor]

Hi,

On Mon, Nov 11 2019, Martin Sebor wrote:
> On 11/8/19 5:41 AM, Martin Jambor wrote:
>> Hi,
>> 
>> this patch is an attempt to implement my idea from a previous thread
>> about moving -Wmaybe-uninitialized to -Wextra:
>> 
>> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00220.html
>> 
>> Specifically, it attempts to split -Wmaybe-uninitialized into those that
>> are about SRA DECLs and those which are not, and move to -Wextra only
>> the former ones.  The main idea is that false -Wmaybe-uninitialized
>> warings about values that are scalar in user's code are easy to silence
>> by initializing them to zero or something, as opposed to bits of
>> aggregates such as a value in std::optional which are not.  Therefore,
>> the warnings about user-scalars can remain in -Wall but warnings about
>> SRAed pieces should be moved to -Wextra.
>> 
>> The patch is a bit bigger because of documentation (which I'll be happy
>> to improve based on your suggestions) and testsuite churn, but the main
>> bit is the following added test in warn_uninit function:
>> 
>>if (wc == OPT_Wmaybe_uninitialized
>>&& SSA_NAME_VAR (t)
>>&& DECL_ARTIFICIAL (SSA_NAME_VAR (t))
>>&& DECL_HAS_DEBUG_EXPR_P (SSA_NAME_VAR (t)))
>>  {
>>if (warn_maybe_uninitialized_aggregates)
>>  wc = OPT_Wmaybe_uninitialized_aggregates;
>>else
>>  return;
>>  }
>> 
>> The reason why I also test DECL_HAS_DEBUG_EXPR_P is
>> gfortran.dg/pr39666-2.f90 - without it the test silences a warning about
>> a decl representing the return value which is an artificial scalar
>> variable (probably all the way from the front-end).  We can of course
>> not care about not warning for it but then I don't know how to call and
>> document the new option :-)  Generally, if someone can think of a better
>> test to identify SRA DECLs, I'll be happy to change that.  We might put
>> a bit to identify SRA decls in the decl tree, but I tend to think that
>> is not a good use of the few remaining bits there.
>> 
>> What do you think, is something along these lines a good idea?
>> 
>> Thanks,
>> 
>> Martin
>> 
>> 
>> 
>> 2019-11-08  Martin Jambor  
>> 
>>  * common.opt (Wmaybe-uninitialized-aggregates): New.
>>  * tree-ssa-uninit.c (gate_warn_uninitialized): Also run if
>>  warn_maybe_uninitialized_aggregates is set.
>>  (warn_uninit): Warn for artificial DECLs only if
>>  warn_maybe_uninitialized_aggregates is set.
>>  * doc/invoke.texi (Warning Options): Add
>>  -Wmaybe-uninitialized-aggregates to the list.
>>  (-Wextra): Likewise.
>>  (-Wmaybe-uninitialized): Document that it only works on scalars.
>>  (-Wmaybe-uninitialized-aggregates): Document.
>> 
>>  testsuite/
>>  * gcc.dg/pr45083.c: Add Wmaybe-uninitialized-aggregates to options.
>>  * gcc.dg/ubsan/pr81981.c: Likewise.
>>  * gfortran.dg/pr25923.f90: Likewise.
>>  * g++.dg/warn/pr80635.C: New.
>> ---
>>   gcc/common.opt|  4 +++
>>   gcc/doc/invoke.texi   | 18 +--
>>   gcc/testsuite/g++.dg/warn/pr80635.C   | 45 +++
>>   gcc/testsuite/gcc.dg/pr45083.c|  2 +-
>>   gcc/testsuite/gcc.dg/ubsan/pr81981.c  |  2 +-
>>   gcc/testsuite/gfortran.dg/pr25923.f90 |  2 +-
>>   gcc/tree-ssa-uninit.c | 14 -
>>   7 files changed, 81 insertions(+), 6 deletions(-)
>>   create mode 100644 gcc/testsuite/g++.dg/warn/pr80635.C
>> 
>> diff --git a/gcc/common.opt b/gcc/common.opt
>> index cc279f411d7..03769299df8 100644
>> --- a/gcc/common.opt
>> +++ b/gcc/common.opt
>> @@ -783,6 +783,10 @@ Wmaybe-uninitialized
>>   Common Var(warn_maybe_uninitialized) Warning EnabledBy(Wuninitialized)
>>   Warn about maybe uninitialized automatic variables.
>>   
>> +Wmaybe-uninitialized-aggregates
>> +Common Var(warn_maybe_uninitialized_aggregates) Warning EnabledBy(Wextra)
>> +Warn about maybe uninitialized automatic parts of aggregates.
>> +
>>   Wunreachable-code
>>   Common Ignore Warning
>>   Does nothing. Preserved for backward compatibility.
>> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
>> index faa7fa95a0e..dbc3219b770 100644
>> --- a/gcc/doc/invoke.texi
>> +++ b/gcc/doc/invoke.texi
>> @@ -328,7 +328,8 @@ Objective-C and Objective-C++ Dialects}.
>>   -Wzero-length-bounds @gol
>>   -Winvalid-pch  -Wlarger-than=@var{byte-size} @gol
>>   -Wlogical-op  -Wlogical-not-parentheses  -Wlong-long @gol
>> --Wmain  -Wmaybe-uninitialized  -Wmemset-elt-size  -Wmemset-transposed-args 
>> @gol
>> +-Wmain  -Wmaybe-uninitialized -Wmaybe-uninitialized-aggregates @gol
>> +-Wmemset-elt-size  -Wmemset-transposed-args @gol
>>   -Wmisleading-indentation  -Wmissing-attributes  -Wmissing-braces @gol
>>   -Wmissing-field-initializers  -Wmissing-format-attribute @gol
>>   -Wmissing-include-dirs  -Wmissing-noreturn  -Wmissing-profile @gol
>> @@ -4498,6 +4499,7 @@ name is still supported, but the newer name is more 
>> descriptive.)
>>   -Wempty-body  @gol
>>  

Re: [RFC] Only warn for maybe-uninitialized SRAed bits in -Wextra (PR 80635)

[Martin Sebor]

On 11/8/19 5:41 AM, Martin Jambor wrote:

Hi,

this patch is an attempt to implement my idea from a previous thread
about moving -Wmaybe-uninitialized to -Wextra:

https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00220.html

Specifically, it attempts to split -Wmaybe-uninitialized into those that
are about SRA DECLs and those which are not, and move to -Wextra only
the former ones.  The main idea is that false -Wmaybe-uninitialized
warings about values that are scalar in user's code are easy to silence
by initializing them to zero or something, as opposed to bits of
aggregates such as a value in std::optional which are not.  Therefore,
the warnings about user-scalars can remain in -Wall but warnings about
SRAed pieces should be moved to -Wextra.

The patch is a bit bigger because of documentation (which I'll be happy
to improve based on your suggestions) and testsuite churn, but the main
bit is the following added test in warn_uninit function:

   if (wc == OPT_Wmaybe_uninitialized
   && SSA_NAME_VAR (t)
   && DECL_ARTIFICIAL (SSA_NAME_VAR (t))
   && DECL_HAS_DEBUG_EXPR_P (SSA_NAME_VAR (t)))
 {
   if (warn_maybe_uninitialized_aggregates)
wc = OPT_Wmaybe_uninitialized_aggregates;
   else
return;
 }

The reason why I also test DECL_HAS_DEBUG_EXPR_P is
gfortran.dg/pr39666-2.f90 - without it the test silences a warning about
a decl representing the return value which is an artificial scalar
variable (probably all the way from the front-end).  We can of course
not care about not warning for it but then I don't know how to call and
document the new option :-)  Generally, if someone can think of a better
test to identify SRA DECLs, I'll be happy to change that.  We might put
a bit to identify SRA decls in the decl tree, but I tend to think that
is not a good use of the few remaining bits there.

What do you think, is something along these lines a good idea?

Thanks,

Martin



2019-11-08  Martin Jambor  

* common.opt (Wmaybe-uninitialized-aggregates): New.
* tree-ssa-uninit.c (gate_warn_uninitialized): Also run if
warn_maybe_uninitialized_aggregates is set.
(warn_uninit): Warn for artificial DECLs only if
warn_maybe_uninitialized_aggregates is set.
* doc/invoke.texi (Warning Options): Add
-Wmaybe-uninitialized-aggregates to the list.
(-Wextra): Likewise.
(-Wmaybe-uninitialized): Document that it only works on scalars.
(-Wmaybe-uninitialized-aggregates): Document.

testsuite/
* gcc.dg/pr45083.c: Add Wmaybe-uninitialized-aggregates to options.
* gcc.dg/ubsan/pr81981.c: Likewise.
* gfortran.dg/pr25923.f90: Likewise.
* g++.dg/warn/pr80635.C: New.
---
  gcc/common.opt|  4 +++
  gcc/doc/invoke.texi   | 18 +--
  gcc/testsuite/g++.dg/warn/pr80635.C   | 45 +++
  gcc/testsuite/gcc.dg/pr45083.c|  2 +-
  gcc/testsuite/gcc.dg/ubsan/pr81981.c  |  2 +-
  gcc/testsuite/gfortran.dg/pr25923.f90 |  2 +-
  gcc/tree-ssa-uninit.c | 14 -
  7 files changed, 81 insertions(+), 6 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/warn/pr80635.C

diff --git a/gcc/common.opt b/gcc/common.opt
index cc279f411d7..03769299df8 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -783,6 +783,10 @@ Wmaybe-uninitialized
  Common Var(warn_maybe_uninitialized) Warning EnabledBy(Wuninitialized)
  Warn about maybe uninitialized automatic variables.
  
+Wmaybe-uninitialized-aggregates

+Common Var(warn_maybe_uninitialized_aggregates) Warning EnabledBy(Wextra)
+Warn about maybe uninitialized automatic parts of aggregates.
+
  Wunreachable-code
  Common Ignore Warning
  Does nothing. Preserved for backward compatibility.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index faa7fa95a0e..dbc3219b770 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -328,7 +328,8 @@ Objective-C and Objective-C++ Dialects}.
  -Wzero-length-bounds @gol
  -Winvalid-pch  -Wlarger-than=@var{byte-size} @gol
  -Wlogical-op  -Wlogical-not-parentheses  -Wlong-long @gol
--Wmain  -Wmaybe-uninitialized  -Wmemset-elt-size  -Wmemset-transposed-args @gol
+-Wmain  -Wmaybe-uninitialized -Wmaybe-uninitialized-aggregates @gol
+-Wmemset-elt-size  -Wmemset-transposed-args @gol
  -Wmisleading-indentation  -Wmissing-attributes  -Wmissing-braces @gol
  -Wmissing-field-initializers  -Wmissing-format-attribute @gol
  -Wmissing-include-dirs  -Wmissing-noreturn  -Wmissing-profile @gol
@@ -4498,6 +4499,7 @@ name is still supported, but the newer name is more 
descriptive.)
  -Wempty-body  @gol
  -Wignored-qualifiers @gol
  -Wimplicit-fallthrough=3 @gol
+-Wmaybe-uninitialized-aggregates @gol
  -Wmissing-field-initializers  @gol
  -Wmissing-parameter-type @r{(C only)}  @gol
  -Wold-style-declaration @r{(C only)}  @gol
@@ -5690,10 +5692,22 @@ in fact be called at the place that would cause a 
problem.
  
  Some spurious 

Re: v2 [PATCH 0/X] Introduce HWASAN sanitizer to GCC

[Matthew Malcomson]

On 11/11/2019 16:13, Matthew Malcomson wrote:
> On 07/11/2019 18:37, Matthew Malcomson wrote:
>> I have rebased this series onto Martin Liska's patches that take the most
>> recent libhwasan from upstream LLVM.
>> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html
>>
>> I've also cleared up some nomenclature (I had previously used the word 
>> 'colour'
>> a few times instead of the word 'tag' and that clashes with other 
>> descriptions)
>> and based the patch series off a more recent GCC revision (r277678).
>>
>> There's an ongoing discussion on whether to have __SANITIZER_ADDRESS__, or
>> __SANITIZER_HWADDRESS__, but I'm keeping that discussion to the existing
>> thread.
>>
>> Similarly there's still the question around C++ exceptions that I'm keeping 
>> to
>> the existing thread (on the first patch series).
>>
>>
>> NOTE:
>> Unfortunately, there's a bug in the more recent version of GCC I rebased
>> onto.
>> Hwasan catches this when bootstrapping, which means bootstrapping with 
>> hwasan
>> fails.
>> I'm working on tracking the bug down now, but sending this series 
>> upstream
>> for visibility while that happens.
>>
>> Bugzilla link:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410
>>
>> Entire patch series attached to cover letter.
>>
> 
> It seems that PR 92410 is a little more extensive than it originally
> looked (in fixing it I saw instances of the same basic problem elsewhere
> too).
> 
> Just in case anyone wants to take a look at this HWASAN series in the
> meantime there are two ways:
> 
> 1) Bootstrap with hwasan not crashing on error.
> 
> 2) Apply the last patch I posted on
> http://pdtlreviewboard.cambridge.arm.com/r/12149/

Oops -- clipboard didn't have what I thought it did.
I meant https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410 here.

> 
> 
> Number 1 requires the patch below and to run make with HWASAN_OPTIONS
> set to "halt_on_error=0 exitcode=0".
> 
> diff --git a/config/bootstrap-hwasan.mk b/config/bootstrap-hwasan.mk
> index 91989f4..3672b91 100644
> --- a/config/bootstrap-hwasan.mk
> +++ b/config/bootstrap-hwasan.mk
> @@ -4,8 +4,8 @@
># breaks.  Running with a random frame tag gives approx. 50% chance of
># bootstrap comparison diff in libiberty/alloca.c.
> 
> -STAGE2_CFLAGS += -fsanitize=hwaddress --param hwasan-random-frame-tag=0
> -STAGE3_CFLAGS += -fsanitize=hwaddress --param hwasan-random-frame-tag=0
> +STAGE2_CFLAGS += -fsanitize-recover=hwaddress -fsanitize=hwaddress
> --param hwasan-random-frame-tag=0
> +STAGE3_CFLAGS += -fsanitize-recover=hwaddress -fsanitize=hwaddress
> --param hwasan-random-frame-tag=0
>POSTSTAGE1_LDFLAGS += -fsanitize=hwaddress -static-libhwasan \
> -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/ \
> -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/hwasan/ \
> 
> 
> 
> 
> Number 2 option avoids the current problem, but causes two extra
> testsuite failures (unrelated to hwasan) in gcc.dg/fold-eqandshift-1.c
> and gcc.c-torture/compile/pr32482.c.
> These are existing bugs that a new `assert` catches.
> 

Re: v2 [PATCH 0/X] Introduce HWASAN sanitizer to GCC

[Matthew Malcomson]

On 07/11/2019 18:37, Matthew Malcomson wrote:
> I have rebased this series onto Martin Liska's patches that take the most
> recent libhwasan from upstream LLVM.
> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html
> 
> I've also cleared up some nomenclature (I had previously used the word 
> 'colour'
> a few times instead of the word 'tag' and that clashes with other 
> descriptions)
> and based the patch series off a more recent GCC revision (r277678).
> 
> There's an ongoing discussion on whether to have __SANITIZER_ADDRESS__, or
> __SANITIZER_HWADDRESS__, but I'm keeping that discussion to the existing
> thread.
> 
> Similarly there's still the question around C++ exceptions that I'm keeping to
> the existing thread (on the first patch series).
> 
> 
> NOTE:
>Unfortunately, there's a bug in the more recent version of GCC I rebased
>onto.
>Hwasan catches this when bootstrapping, which means bootstrapping with 
> hwasan
>fails.
>I'm working on tracking the bug down now, but sending this series upstream
>for visibility while that happens.
> 
>Bugzilla link:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410
> 
> Entire patch series attached to cover letter.
> 

It seems that PR 92410 is a little more extensive than it originally 
looked (in fixing it I saw instances of the same basic problem elsewhere 
too).

Just in case anyone wants to take a look at this HWASAN series in the 
meantime there are two ways:

1) Bootstrap with hwasan not crashing on error.

2) Apply the last patch I posted on 
http://pdtlreviewboard.cambridge.arm.com/r/12149/


Number 1 requires the patch below and to run make with HWASAN_OPTIONS 
set to "halt_on_error=0 exitcode=0".

diff --git a/config/bootstrap-hwasan.mk b/config/bootstrap-hwasan.mk
index 91989f4..3672b91 100644
--- a/config/bootstrap-hwasan.mk
+++ b/config/bootstrap-hwasan.mk
@@ -4,8 +4,8 @@
  # breaks.  Running with a random frame tag gives approx. 50% chance of
  # bootstrap comparison diff in libiberty/alloca.c.

-STAGE2_CFLAGS += -fsanitize=hwaddress --param hwasan-random-frame-tag=0
-STAGE3_CFLAGS += -fsanitize=hwaddress --param hwasan-random-frame-tag=0
+STAGE2_CFLAGS += -fsanitize-recover=hwaddress -fsanitize=hwaddress 
--param hwasan-random-frame-tag=0
+STAGE3_CFLAGS += -fsanitize-recover=hwaddress -fsanitize=hwaddress 
--param hwasan-random-frame-tag=0
  POSTSTAGE1_LDFLAGS += -fsanitize=hwaddress -static-libhwasan \
   -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/ \
   -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/hwasan/ \




Number 2 option avoids the current problem, but causes two extra 
testsuite failures (unrelated to hwasan) in gcc.dg/fold-eqandshift-1.c 
and gcc.c-torture/compile/pr32482.c.
These are existing bugs that a new `assert` catches.

Re: [PATCH 3/X] [libsanitizer] Add option to bootstrap using HWASAN

[Matthew Malcomson]

On 11/11/2019 14:30, Martin Liška wrote:
> On 11/7/19 7:37 PM, Matthew Malcomson wrote:
>> +@item @samp{bootstrap-hwasan}
>> +Compiles GCC itself using HWAddress Sanitization in order to catch 
>> invalid
>> +memory accesses within the GCC code.  This option is only available 
>> on AArch64
>> +targets with a very recent linux kernel (5.4 or later).
>> +
> 
> Apparently, I see this hunk being applied:
> 
> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> index 2cb8a342a2c..ed47796e052 100644
> --- a/gcc/doc/install.texi
> +++ b/gcc/doc/install.texi
> @@ -2671,6 +2671,11 @@ the build tree.
> 
>   @end table
> 
> +@item @samp{bootstrap-hwasan}
> +Compiles GCC itself using HWAddress Sanitization in order to catch invalid
> +memory accesses within the GCC code.  This option is only available on 
> AArch64
> +targets with a very recent linux kernel (5.4 or later).
> +
>   @section Building a cross compiler
> 
>   When building a cross compiler, it is not generally possible to do a
> 
> and then I see:
> 
> make[2]: Entering directory '/dev/shm/objdir/gcc'
> if [ xinfo = xinfo ]; then \
>  makeinfo --split-size=500 --split-size=500 --no-split -I 
> /home/marxin/Programming/gcc/gcc/doc \
>      -I /home/marxin/Programming/gcc/gcc/doc/include -o 
> doc/gccinstall.info /home/marxin/Programming/gcc/gcc/doc/install.texi; \
> fi
> /home/marxin/Programming/gcc/gcc/doc/install.texi:2674: @item outside of 
> table or list
> make[2]: *** [Makefile:3279: doc/gccinstall.info] Error 1
> make[2]: Leaving directory '/dev/shm/objdir/gcc'
> 
> Can you please check it?
> Thanks,
> Martin

Ah!
My apologies -- I sent up a series with a few documentation mistakes.
(the others were wording problems so less noticeable)

I'm attaching the entire updated patch series (with the other 
documentation fixes in it too) and the fixed patch for just this part in 
case you just want to compile and test right now.

Regards,
Matthew


all-patches.tar.gz
Description: all-patches.tar.gz
diff --git a/config/bootstrap-hwasan.mk b/config/bootstrap-hwasan.mk
new file mode 100644
index ..4f60bed3fd6e98b47a3a38aea6eba2a7c320da25
--- /dev/null
+++ b/config/bootstrap-hwasan.mk
@@ -0,0 +1,8 @@
+# This option enables -fsanitize=hwaddress for stage2 and stage3.
+
+STAGE2_CFLAGS += -fsanitize=hwaddress
+STAGE3_CFLAGS += -fsanitize=hwaddress
+POSTSTAGE1_LDFLAGS += -fsanitize=hwaddress -static-libhwasan \
+		  -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/ \
+		  -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/hwasan/ \
+		  -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/hwasan/.libs
diff --git a/configure b/configure
index aec9186b2b0123d3088b69eb1ee541567654953e..6f71b111bd18ec053180beecf83dd4549e83c2b9 100755
--- a/configure
+++ b/configure
@@ -7270,7 +7270,7 @@ fi
 # or bootstrap-ubsan, bootstrap it.
 if echo " ${target_configdirs} " | grep " libsanitizer " > /dev/null 2>&1; then
   case "$BUILD_CONFIG" in
-*bootstrap-asan* | *bootstrap-ubsan* )
+*bootstrap-hwasan* | *bootstrap-asan* | *bootstrap-ubsan* )
   bootstrap_target_libs=${bootstrap_target_libs}target-libsanitizer,
   bootstrap_fixincludes=yes
   ;;
diff --git a/configure.ac b/configure.ac
index b8ce2ad20b9d03e42731252a9ec2a8417c13e566..16bfdf164555dad94c789f17b6a63ba1a2e3e9f4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2775,7 +2775,7 @@ fi
 # or bootstrap-ubsan, bootstrap it.
 if echo " ${target_configdirs} " | grep " libsanitizer " > /dev/null 2>&1; then
   case "$BUILD_CONFIG" in
-*bootstrap-asan* | *bootstrap-ubsan* )
+*bootstrap-hwasan* | *bootstrap-asan* | *bootstrap-ubsan* )
   bootstrap_target_libs=${bootstrap_target_libs}target-libsanitizer,
   bootstrap_fixincludes=yes
   ;;
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 6c9579bfaff955eb43875b404fb7db1a667bf522..da9a8809c3440827ac22ef6936e080820197f4e7 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2645,6 +2645,13 @@ Some examples of build configurations designed for developers of GCC are:
 Compiles GCC itself using Address Sanitization in order to catch invalid memory
 accesses within the GCC code.
 
+@item @samp{bootstrap-hwasan}
+Compiles GCC itself using HWAddress Sanitization in order to catch invalid
+memory accesses within the GCC code.  This option is only available on AArch64
+targets with a very recent linux kernel (5.4 or later).
+
+@end table
+
 @section Building a cross compiler
 
 When building a cross compiler, it is not generally possible to do a
diff --git a/libiberty/configure b/libiberty/configure
index 7a34dabec32b0b383bd33f07811757335f4dd39c..cb2dd4ff5295598343cc18b3a79a86a778f2261d 100755
--- a/libiberty/configure
+++ b/libiberty/configure
@@ -5261,6 +5261,7 @@ fi
 NOASANFLAG=
 case " ${CFLAGS} " in
   *\ -fsanitize=address\ *) NOASANFLAG=-fno-sanitize=address ;;
+  *\ -fsanitize=hwaddress\ *) NOASANFLAG=-fno-sanitize=hwaddress ;;
 esac
 
 
diff --git a/libiberty/configure.ac 

Re: [Patch, fortran] PR fortran/92142 - CFI_setpointer corrupts descriptor

[Tobias Burnus]

On 11/11/19 2:58 PM, Mark Eggleston wrote:

Unfortunately ISO_Fortran_binding_16.f90 contains a typo resulting in: 
the cause is that it refers to ISO_Fortran_binding_15.c instead of 
ISO_Fortran_binding_16.c in the dg-additional-sources directive.


I was sure that I tested it and committed the right version after the 
renaming was needed. (Paul's patch used the same file names).


In any case, it is now corrected in Rev. 278055.

Thanks,

Tobias

commit ade0939d853f376a0568d29a94fdde2fd14e08d5
Author: burnus 
Date:   Mon Nov 11 15:35:50 2019 +

Fix commit for PR fortran/92142 - CFI_setpointer corrupts descriptor

2019-11-11  Tobias Burnus  
Mark Eggleston  

PR fortran/92142
* gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.f90:
Correct dg-additional-sources.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@278055 138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 66de94fc582..ebdf61161ee 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,10 @@
+2019-11-11  Tobias Burnus  
+	Mark Eggleston  
+
+	PR fortran/92142
+	* gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.f90:
+	Correct dg-additional-sources.
+
 2019-11-11  Andre Vieira  
 
 	* gcc.dg/vect/vect-reduc-epilogue-gaps.c: New test.
diff --git a/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.f90 b/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.f90
index 799f34b1287..9e5f3b1a9bc 100644
--- a/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.f90
+++ b/gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.f90
@@ -1,6 +1,6 @@
 ! { dg-do run }
 ! { dg-additional-options "-fbounds-check" }
-! { dg-additional-sources ISO_Fortran_binding_15.c }
+! { dg-additional-sources ISO_Fortran_binding_16.c }
 !
 ! Test the fix for PR92142.
 !

Re: [PATCH] include size and offset in -Wstringop-overflow

[Martin Sebor]

On 11/11/19 4:30 AM, Bernhard Reutner-Fischer wrote:

On 8 November 2019 17:57:51 CET, Martin Sebor  wrote:

On 11/6/19 2:06 PM, Martin Sebor wrote:

On 11/6/19 1:39 PM, Jeff Law wrote:

On 11/6/19 1:27 PM, Martin Sebor wrote:

On 11/6/19 11:55 AM, Jeff Law wrote:

On 11/6/19 11:00 AM, Martin Sebor wrote:

The -Wstringop-overflow warnings for single-byte and multi-byte
stores mention the amount of data being stored and the amount of
space remaining in the destination, such as:



warning: writing 4 bytes into a region of size 0 [-Wstringop-overflow=]



 123 |   *p = 0;
 |   ~~~^~~
note: destination object declared here
  45 |   char b[N];
 |^



A warning like this can take some time to analyze.  First, the size



of the destination isn't mentioned and may not be easy to tell from

the sources.  In the note above, when N's value is the result of


some non-trivial computation, chasing it down may be a small project



in and of itself.  Second, it's also not clear why the region size

is zero.  It could be because the offset is exactly N, or because
it's negative, or because it's in some range greater than N.

Mentioning both the size of the destination object and the offset


makes the existing messages clearer, are will become essential when

GCC starts diagnosing overflow into allocated buffers (as my
follow-on patch does).

The attached patch enhances -Wstringop-overflow to do this by
letting compute_objsize return the offset to its caller, doing
something similar in get_stridx, and adding a new function to
the strlen pass to issue this enhanced warning (eventually, I'd
like the function to replace the -Wstringop-overflow handler in


builtins.c).  With the change, the note above might read something

like:

note: at offset 11 to object ‘b’ with size 8 declared here
  45 |   char b[N];
 |^



Is "to object" correct? Into? I somehow fund it hard to read as proposed.


I agree.  Other messages use "offset from" so let me change it to
that.

Thanks for the suggestion!

Martin

[PATCH] libgo/test: Add flags to find libgcc_s in build-tree testing

[Maciej W. Rozycki]

Add a setting for the dynamic loader to find the shared libgcc_s library 
in build-tree testing, fixing a catastrophic libgo testsuite failure in 
cross-compilation where the library cannot be found by the loader at run 
time and consequently no test case executes, producing output (here with 
the `x86_64-linux-gnu' host and the `riscv64-linux-gnu' target, with 
RISC-V QEMU in the Linux user emulation mode as the target board) like:

spawn qemu-riscv64 -E 
LD_LIBRARY_PATH=.:.../riscv64-linux-gnu/lib64/lp64d/libgo/.libs ./a.exe
./a.exe: error while loading shared libraries: libgcc_s.so.1: cannot open 
shared object file: No such file or directory
FAIL: archive/tar

Use the `ld_library_path' TCL variable to propagate the setting obtained 
from where GCC finds the library at link time, making test output look 
like:

spawn qemu-riscv64 -E 
LD_LIBRARY_PATH=.:..././gcc/lib64/lp64d:.../riscv64-linux-gnu/lib64/lp64d/libgo/.libs
 ./a.exe
PASS
PASS: archive/tar

No summary comparison, because the libgo testsuite does not provide one 
in this configuration for some reason, however this change improves 
overall results from 0 PASSes and 159 FAILs to 133 PASSes and 26 FAILs.

gcc/testsuite/
* lib/go.exp (go_link_flags): Add `ld_library_path' setting to 
find shared `libgcc_s' library at run time in build-tree 
testing.
---
Hi,

 Regression-tested with `make check-go' with the `x86_64-linux-gnu' native 
system as well as the `x86_64-linux-gnu' host and the `riscv64-linux-gnu' 
target, with RISC-V QEMU in the Linux user emulation mode as the target 
board.

 NB as a heads-up numerous tests fail quietly (i.e. with no FAIL report 
and no name of the test case given either) to link due to unsatisfied 
symbol references, such as:

.../bin/riscv64-linux-gnu-ld: _gotest_.o: in function 
`cmd..z2fgo..z2finternal..z2fcache.Cache.get':
.../riscv64-linux-gnu/libgo/gotest24771/test/cache.go:182: undefined reference 
to `cmd..z2fgo..z2finternal..z2frenameio.ReadFile'

which I take is due to a reference to `libgotool.a' -- which is where the 
required symbols are defined -- missing from the linker invocation.  I 
don't know what's supposed to supply the library to the linker or whether 
this indeed the actual cause; I find the way libgo tests have been wired 
unusual and consequently hard to follow, so maybe someone more familiar 
with this stuff will be able to tell what is going on here.  I'll be happy 
to push any patches through testing.

 OK to apply to GCC?

  Maciej
---
 gcc/testsuite/lib/go.exp |8 
 1 file changed, 8 insertions(+)

gcc-test-libgo-libgcc-lib-path.diff
Index: gcc/gcc/testsuite/lib/go.exp
===
--- gcc.orig/gcc/testsuite/lib/go.exp
+++ gcc/gcc/testsuite/lib/go.exp
@@ -104,6 +104,14 @@ proc go_link_flags { paths } {
 verbose "shared lib extension: $shlib_ext"
 
 if { $gccpath != "" } {
+  set compiler [lindex $GOC_UNDER_TEST 0]
+  set compiler_opts [join [lrange $GOC_UNDER_TEST 1 end]]
+  set libgccs [remote_exec host "$compiler" \
+  "$compiler_opts -print-file-name=libgcc_s.${shlib_ext}"]
+  if { [lindex $libgccs 0] == 0 \
+  && [set libgccsdir [file dirname [lindex $libgccs 1]]] != "" } {
+  append ld_library_path ":${libgccsdir}"
+  }
   if [file exists "${gccpath}/libgo/libgobegin.a"] {
  append flags "-L${gccpath}/libgo "
   }

Re: [PATCH] Enhance syntax of -fdbg-cnt.

[Martin Liška]

On 11/11/19 3:50 PM, Richard Biener wrote:

On Mon, Nov 11, 2019 at 3:33 PM Martin Liška  wrote:


On 11/11/19 3:19 PM, Richard Biener wrote:

On Mon, Nov 11, 2019 at 9:17 AM Martin Liška  wrote:


Hi.

The patch makes debug counter more usable. In particular, one can now
list multiple closed intervals and -fdbg-cnt-list can reflect that.
Based on the discussion with Richard, I decided to leave semi-closed
intervals and make it closed, it's more intuitive.

Example:
$ g++ -O2 tramp3d-v4.ii 
-fdbg-cnt=match:1-2:6-10:11-20,dce:100:105-200,merged_ipa_icf:300-300 -c 
-fdbg-cnt-list
...
 counter name   closed intervals
-
...
 dce[1, 100], [105, 200]
...
 match  [1, 2], [6, 10], [11, 20]
 merged_ipa_icf [300, 300]

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?


+  /* Reverse intervals exactly once.  */
+  if (v == 1)
+limits[index]->reverse ();

why not do this at option processing time?


Because we don't have there any dbgcnt API. Right now one can use multiple
-fdbg-cnt options on a command line and that's why I'm doing that lazily.


But there's dbg_cnt_process_opt, that one can clearly insert intervals
in appropriately sorted way.


Yes, I'm doing that right now.




I think sorted insertion
is reasonable here (I don't see you sorting them at all?).


I do expect a sorted intervals by user. If it's not provided, an error message
is directly emitted.


I see, I find it overzealous esp. for multiple options like
-fdbg-cnt=foo:5-7 -fdbg-cnt=foo:2-3?
But yeah, it simplifies things.  Still you could insert at the head
and avoid reversal.


I decided to sort the intervals for during each insertion.
It should not affect performance as one does not insert hundreds of intervals.
Doing that I can do following error detection:

$ g++ -O2 tramp3d-v4.ii -fdbg-cnt=match:2-10 -fdbg-cnt=match:200-300 
-fdbg-cnt=match:6-7 -fdbg-cnt-list
cc1plus: error: Interval overlap of ‘-fdbg-cnt=match’: [2, 10] and [6, 7]

I'm going to test the patch.
Martin


Btw, there's vec::bsearch which might be convenient for sorted
insertion (even though
that doesn't return an index but a pointer to the element).


-static unsigned int limit_low[debug_counter_number_of_counters];
+static auto_vec
*limits[debug_counter_number_of_counters] = {NULL};

I think you can avoid one indirection here (vec<> is just one pointer) by doing

static vec limits[debug_counter_number_of_counters] = { vNULL };

?  Verify you get no runtime ctor, not sure if that's correct C++ for
initializing
all elements by vNULL, not just the first...

Alternatively I'd lazily allocate the whole vector rather than each individual
vector (at option processing time again), so

static vec (*limits)[];


I fully agree with that we should reduce one level of indirection.
Lemme take a look..

Thanks,
Martin



Thanks,
Richard.


Thanks,
Martin

gcc/ChangeLog:

2019-11-08  Martin Liska  

  * common.opt: Document change of -fdbg-cnt option.
  * dbgcnt.c (DEBUG_COUNTER): Remove.
  (dbg_cnt_is_enabled): Remove.
  (dbg_cnt): Work with new intervals.
  (dbg_cnt_set_limit_by_index): Set to new
  list of intervals.
  (dbg_cnt_set_limit_by_name): Likewise.
  (dbg_cnt_process_single_pair): Process new format.
  (dbg_cnt_process_opt): Likewise.
  (dbg_cnt_list_all_counters): Likewise.
  * doc/invoke.texi: Document change of -fdbg-cnt option.

gcc/testsuite/ChangeLog:

2019-11-08  Martin Liska  

  * gcc.dg/ipa/ipa-icf-39.c: Update -fdbg-cnt to the new format.
  * gcc.dg/pr68766.c: Likewise.
---
gcc/common.opt|   2 +-
gcc/dbgcnt.c  | 157 +++---
gcc/doc/invoke.texi   |  15 ++-
gcc/testsuite/gcc.dg/ipa/ipa-icf-39.c |   3 +-
gcc/testsuite/gcc.dg/pr68766.c|   1 -
5 files changed, 103 insertions(+), 75 deletions(-)






>From f62eeec40c31c2c5dddc855b1c05cf5c6ee7f66d Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Fri, 8 Nov 2019 16:05:00 +0100
Subject: [PATCH] Enhance syntax of -fdbg-cnt.

gcc/ChangeLog:

2019-11-08  Martin Liska  

	* common.opt: Document change of -fdbg-cnt option.
	* dbgcnt.c (DEBUG_COUNTER): Remove.
	(dbg_cnt_is_enabled): Remove.
	(dbg_cnt): Work with new intervals.
	(dbg_cnt_set_limit_by_index): Set to new
	list of intervals.
	(dbg_cnt_set_limit_by_name): Likewise.
	(dbg_cnt_process_single_pair): Process new format.
	(dbg_cnt_process_opt): Likewise.
	(dbg_cnt_list_all_counters): Likewise.
	* doc/invoke.texi: Document change of -fdbg-cnt option.
	(cmp_tuples): New.

gcc/testsuite/ChangeLog:

2019-11-08  Martin Liska  

	* gcc.dg/ipa/ipa-icf-39.c: Update -fdbg-cnt to the new format.
	* gcc.dg/pr68766.c: Likewise.
---
 gcc/common.opt   

Re: [Committed] IBM Z: Add pattern for load truth value of comparison into reg

[Richard Henderson]

On 11/11/19 4:03 PM, Andreas Krebbel wrote:
> On 11.11.19 15:39, Richard Henderson wrote:
>> On 11/7/19 12:52 PM, Andreas Krebbel wrote:
>>> +; Such patterns get directly emitted by noce_emit_store_flag.
>>> +(define_insn_and_split "*cstorecc_z13"
>>> +  [(set (match_operand:GPR  0 "register_operand""=")
>>> +   (match_operator:GPR 1 "s390_comparison"
>>> +   [(match_operand 2 "cc_reg_operand""c")
>>> +(match_operand 3 "const_int_operand"  "")]))]
>>
>> The clobbered-output seems superfluous, since it can't overlap "c".
> I thought it would be "more" correct this way, but it might lead to an extra 
> reload being emitted - right?

Well, possibly no extra reloads either, since no input will overlap.

>> I believe the only valid const_int is 0, fwiw, so perhaps matching any
>> const_int is overkill.
> We also have CCRAW mode where that value is != 0.

Oh wow.  That's an interesting way to fold those combinations.

>> Does it help Z12 to allow the 3-insn sequence using LOC(G)R?
> Prior to z13 we prefer the variant using a conditional branch.

Ok, just checking.  Thanks,


r~

Re: [Committed] IBM Z: Add pattern for load truth value of comparison into reg

[Andreas Krebbel]

On 11.11.19 15:39, Richard Henderson wrote:
> On 11/7/19 12:52 PM, Andreas Krebbel wrote:
>> +; Such patterns get directly emitted by noce_emit_store_flag.
>> +(define_insn_and_split "*cstorecc_z13"
>> +  [(set (match_operand:GPR  0 "register_operand""=")
>> +(match_operator:GPR 1 "s390_comparison"
>> +[(match_operand 2 "cc_reg_operand""c")
>> + (match_operand 3 "const_int_operand"  "")]))]
> 
> The clobbered-output seems superfluous, since it can't overlap "c".
I thought it would be "more" correct this way, but it might lead to an extra 
reload being emitted -
right?

> I believe the only valid const_int is 0, fwiw, so perhaps matching any
> const_int is overkill.
We also have CCRAW mode where that value is != 0.

> Does it help Z12 to allow the 3-insn sequence using LOC(G)R?
Prior to z13 we prefer the variant using a conditional branch.

Andreas

> 
>> +  "TARGET_Z13"
>> +  "#"
>  > +  "reload_completed"
>> +  [(set (match_dup 0) (const_int 0))
>> +   (set (match_dup 0)
>> +(if_then_else:GPR
>> + (match_op_dup 1 [(match_dup 2) (match_dup 3)])
>> + (const_int 1)
>> + (match_dup 0)))])
> 
> 
> r~
> 

Re: [PATCH] Enhance syntax of -fdbg-cnt.

[Martin Liška]

On 11/11/19 3:19 PM, Richard Biener wrote:

-static unsigned int limit_low[debug_counter_number_of_counters];
+static auto_vec
*limits[debug_counter_number_of_counters] = {NULL};


Hm, apparently it's not working. I see a stack corruption when calling
dbgcnt. I also explicitly called .create (2) for all vectors, but the
ICE still happens.

Anyway, I would probably go with the original patch. It's handy for me
to also have limits[index] == NULL to indicate a counter that is not set.
That's a different state from limits[index].is_empty() which means all
previous intervals were popped and we should return false.

Martin

Re: [RFC] Only warn for maybe-uninitialized SRAed bits in -Wextra (PR 80635)

[Martin Jambor]

Hi,


On Mon, Nov 11 2019, Richard Biener wrote:
> On Fri, Nov 8, 2019 at 1:41 PM Martin Jambor  wrote:
>>
>> Hi,
>>
>> this patch is an attempt to implement my idea from a previous thread
>> about moving -Wmaybe-uninitialized to -Wextra:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00220.html
>>
>> Specifically, it attempts to split -Wmaybe-uninitialized into those that
>> are about SRA DECLs and those which are not, and move to -Wextra only
>> the former ones.  The main idea is that false -Wmaybe-uninitialized
>> warings about values that are scalar in user's code are easy to silence
>> by initializing them to zero or something, as opposed to bits of
>> aggregates such as a value in std::optional which are not.  Therefore,
>> the warnings about user-scalars can remain in -Wall but warnings about
>> SRAed pieces should be moved to -Wextra.
>>
>> The patch is a bit bigger because of documentation (which I'll be happy
>> to improve based on your suggestions) and testsuite churn, but the main
>> bit is the following added test in warn_uninit function:
>>
>>   if (wc == OPT_Wmaybe_uninitialized
>>   && SSA_NAME_VAR (t)
>>   && DECL_ARTIFICIAL (SSA_NAME_VAR (t))
>>   && DECL_HAS_DEBUG_EXPR_P (SSA_NAME_VAR (t)))
>> {
>>   if (warn_maybe_uninitialized_aggregates)
>> wc = OPT_Wmaybe_uninitialized_aggregates;
>>   else
>> return;
>> }
>
> I wonder if this works in practice since the whole point of SRA is to
> have things copy propagated out (so the 't' with the SSA_NAME_VAR
> doesn't prevail or gets commoned with sth else).  Or is this about
> the default defs SRA creates itself to actually emit uninit warnings?

Yes, not warning for those default defs is the idea.  After all, only
when we warn about those DECLs (to which those default defs belong) the
user gets a warning that a bit which they cannot easily initialize on
their own is maybe uninitialized:

pr80635.C:12:13: warning: ‘c1.A::i’ may be used uninitialized in this function 
[-Wmaybe-uninitialized]

Martin

Re: [PATCH] Enhance syntax of -fdbg-cnt.

[Richard Biener]

On Mon, Nov 11, 2019 at 3:33 PM Martin Liška  wrote:
>
> On 11/11/19 3:19 PM, Richard Biener wrote:
> > On Mon, Nov 11, 2019 at 9:17 AM Martin Liška  wrote:
> >>
> >> Hi.
> >>
> >> The patch makes debug counter more usable. In particular, one can now
> >> list multiple closed intervals and -fdbg-cnt-list can reflect that.
> >> Based on the discussion with Richard, I decided to leave semi-closed
> >> intervals and make it closed, it's more intuitive.
> >>
> >> Example:
> >> $ g++ -O2 tramp3d-v4.ii 
> >> -fdbg-cnt=match:1-2:6-10:11-20,dce:100:105-200,merged_ipa_icf:300-300 -c 
> >> -fdbg-cnt-list
> >> ...
> >> counter name   closed intervals
> >> -
> >> ...
> >> dce[1, 100], [105, 200]
> >> ...
> >> match  [1, 2], [6, 10], [11, 20]
> >> merged_ipa_icf [300, 300]
> >>
> >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >>
> >> Ready to be installed?
> >
> > +  /* Reverse intervals exactly once.  */
> > +  if (v == 1)
> > +limits[index]->reverse ();
> >
> > why not do this at option processing time?
>
> Because we don't have there any dbgcnt API. Right now one can use multiple
> -fdbg-cnt options on a command line and that's why I'm doing that lazily.

But there's dbg_cnt_process_opt, that one can clearly insert intervals
in appropriately sorted way.

> > I think sorted insertion
> > is reasonable here (I don't see you sorting them at all?).
>
> I do expect a sorted intervals by user. If it's not provided, an error message
> is directly emitted.

I see, I find it overzealous esp. for multiple options like
-fdbg-cnt=foo:5-7 -fdbg-cnt=foo:2-3?
But yeah, it simplifies things.  Still you could insert at the head
and avoid reversal.
Btw, there's vec::bsearch which might be convenient for sorted
insertion (even though
that doesn't return an index but a pointer to the element).

> > -static unsigned int limit_low[debug_counter_number_of_counters];
> > +static auto_vec
> > *limits[debug_counter_number_of_counters] = {NULL};
> >
> > I think you can avoid one indirection here (vec<> is just one pointer) by 
> > doing
> >
> > static vec limits[debug_counter_number_of_counters] = { vNULL 
> > };
> >
> > ?  Verify you get no runtime ctor, not sure if that's correct C++ for
> > initializing
> > all elements by vNULL, not just the first...
> >
> > Alternatively I'd lazily allocate the whole vector rather than each 
> > individual
> > vector (at option processing time again), so
> >
> > static vec (*limits)[];
>
> I fully agree with that we should reduce one level of indirection.
> Lemme take a look..
>
> Thanks,
> Martin
>
> >
> > Thanks,
> > Richard.
> >
> >> Thanks,
> >> Martin
> >>
> >> gcc/ChangeLog:
> >>
> >> 2019-11-08  Martin Liska  
> >>
> >>  * common.opt: Document change of -fdbg-cnt option.
> >>  * dbgcnt.c (DEBUG_COUNTER): Remove.
> >>  (dbg_cnt_is_enabled): Remove.
> >>  (dbg_cnt): Work with new intervals.
> >>  (dbg_cnt_set_limit_by_index): Set to new
> >>  list of intervals.
> >>  (dbg_cnt_set_limit_by_name): Likewise.
> >>  (dbg_cnt_process_single_pair): Process new format.
> >>  (dbg_cnt_process_opt): Likewise.
> >>  (dbg_cnt_list_all_counters): Likewise.
> >>  * doc/invoke.texi: Document change of -fdbg-cnt option.
> >>
> >> gcc/testsuite/ChangeLog:
> >>
> >> 2019-11-08  Martin Liska  
> >>
> >>  * gcc.dg/ipa/ipa-icf-39.c: Update -fdbg-cnt to the new format.
> >>  * gcc.dg/pr68766.c: Likewise.
> >> ---
> >>gcc/common.opt|   2 +-
> >>gcc/dbgcnt.c  | 157 +++---
> >>gcc/doc/invoke.texi   |  15 ++-
> >>gcc/testsuite/gcc.dg/ipa/ipa-icf-39.c |   3 +-
> >>gcc/testsuite/gcc.dg/pr68766.c|   1 -
> >>5 files changed, 103 insertions(+), 75 deletions(-)
> >>
> >>
>

Re: [PATCH, GCC] Fix unrolling check.

[Eric Botcazou]

> Thanks for the explanation. However, I do not understand why are we 
> returning with the default value.

The regression you reported should be clear enough though: if we don't do 
that, we will unroll in cases where we would not have before.  Try with a 
compiler that predates the pragma and compare, there should be no changes.

> What "do we always do"?

What we do in the absence of specific unrolling directives for the loop.

-- 
Eric Botcazou

Re: [PATCH 0/7] Param conversion to option machinery

[Richard Biener]

On Thu, Nov 7, 2019 at 1:33 PM Martin Liska  wrote:
>
> The email thread is follow up of a demo that I made here:
> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02220.html
>
> The patchset converts current param infrastructure to
> the option machinery. The parts 3 and 4 are quite
> mechanical.
>
> I would appreciate a feedback about what parameters
> should be per function (Optimization keyword) and global.

I didn't go over them but maybe we can postpone this to a followup
and for now make _none_ of them Optimization which preserves
previous behavior (I guess the optimize attribute/pragma doesn't
accept -param either at the moment).

I've commented on part 3/4 spotting a long line and also a
followup / testing opportunity.

> The patch survives bootstrap and regtests on x86_64-linux-gnu
> and ppc64-linux-gnu and I made cross build of all target compilers.

OK if you split the long lines.  The rest can be done as followup.

Thanks for the work,
Richard.

> Thoughts?
> Martin
>
> Martin Liska (7):
>   Param to options conversion.
>   Include new generated gcc/params.opt file.
>   Apply mechanical replacement (generated patch).
>   Remove gcc/params.* files.
>   Remove last leftover usage of params* files.
>   Remove set_default_param_value from documentation.
>   Fix test-suite fallout.
>
>  gcc/Makefile.in   |   20 +-
>  gcc/asan.c|   19 +-
>  gcc/auto-profile.c|3 +-
>  gcc/bb-reorder.c  |5 +-
>  gcc/builtins.c|3 +-
>  gcc/c/gimple-parser.c |3 +-
>  gcc/cfgcleanup.c  |5 +-
>  gcc/cfgexpand.c   |9 +-
>  gcc/cfgloopanal.c |9 +-
>  gcc/cgraph.c  |3 +-
>  gcc/combine.c |5 +-
>  gcc/common.opt|   10 -
>  gcc/common/common-target.def  |6 +-
>  gcc/common/config/aarch64/aarch64-common.c|   16 +-
>  gcc/common/config/gcn/gcn-common.c|1 -
>  gcc/common/config/ia64/ia64-common.c  |9 +-
>  .../config/powerpcspe/powerpcspe-common.c |3 +-
>  gcc/common/config/rs6000/rs6000-common.c  |3 +-
>  gcc/common/config/sh/sh-common.c  |3 +-
>  gcc/config/aarch64/aarch64.c  |   80 +-
>  gcc/config/alpha/alpha.c  |   17 +-
>  gcc/config/arm/arm.c  |   44 +-
>  gcc/config/avr/avr.c  |1 -
>  gcc/config/csky/csky.c|1 -
>  gcc/config/i386/i386-builtins.c   |1 -
>  gcc/config/i386/i386-expand.c |1 -
>  gcc/config/i386/i386-features.c   |1 -
>  gcc/config/i386/i386-options.c|   35 +-
>  gcc/config/i386/i386.c|   27 +-
>  gcc/config/ia64/ia64.c|3 +-
>  gcc/config/rs6000/rs6000-logue.c  |5 +-
>  gcc/config/rs6000/rs6000.c|   56 +-
>  gcc/config/s390/s390.c|   80 +-
>  gcc/config/sparc/sparc.c  |   84 +-
>  gcc/config/visium/visium.c|7 +-
>  gcc/coverage.c|9 +-
>  gcc/cp/name-lookup.c  |3 +-
>  gcc/cp/typeck.c   |5 +-
>  gcc/cprop.c   |1 -
>  gcc/cse.c |7 +-
>  gcc/cselib.c  |3 +-
>  gcc/doc/options.texi  |3 +
>  gcc/doc/tm.texi   |4 +-
>  gcc/dse.c |3 +-
>  gcc/emit-rtl.c|   19 +-
>  gcc/explow.c  |3 +-
>  gcc/final.c   |5 +-
>  gcc/flag-types.h  |   11 +
>  gcc/fold-const.c  |   13 +-
>  gcc/gcc.c |9 -
>  gcc/gcse.c|   17 +-
>  gcc/ggc-common.c  |5 +-
>  gcc/ggc-page.c|5 +-
>  gcc/gimple-loop-interchange.cc|7 +-
>  gcc/gimple-loop-jam.c |9 +-
>  gcc/gimple-loop-versioning.cc |5 +-
>  gcc/gimple-ssa-split-paths.c  |3 +-
>  gcc/gimple-ssa-sprintf.c  |1 -
>  gcc/gimple-ssa-store-merging.c|9 +-
>  gcc/gimple-ssa-strength-reduction.c   |3 +-
>  gcc/gimple-ssa-warn-alloca.c  |1 -
>  gcc/gimple-ssa-warn-restrict.c|1 -
>  gcc/graphite-isl-ast-to-gimple.c 

[PATCH] [PATCH] [ARC] Fix ARC target specific tests.

[Claudiu Zissulescu]

Hi,

Fix ARC specific tests by improving the matching pattern and adding
the missing functionality in arc.exp


OK to appy?
Claudiu


gcc/tests
-xx-xx  Claudiu Zissulescu  

* gcc.target/arc/add_n-combine.c: Match add1/2/3 instruction in
output assembly.
* gcc.target/arc/arc.exp (check_effective_target_codedensity):
Add.
* gcc.target/arc/cmem-7.c: Fix matching patterns.
* gcc.target/arc/cmem-bit-1.c: Likewise.
* gcc.target/arc/cmem-bit-2.c: Likewise.
* gcc.target/arc/cmem-bit-3.c: Likewise.
* gcc.target/arc/cmem-bit-4.c: Likewise.
* gcc.target/arc/interrupt-2.c: Match rtie insn for A7.
* gcc.target/arc/store-merge-1.c: This test is only meaningful for
architectures with double load/store operations.
---
 gcc/testsuite/gcc.target/arc/add_n-combine.c |  6 --
 gcc/testsuite/gcc.target/arc/arc.exp | 10 ++
 gcc/testsuite/gcc.target/arc/cmem-7.c|  8 
 gcc/testsuite/gcc.target/arc/cmem-bit-1.c|  4 ++--
 gcc/testsuite/gcc.target/arc/cmem-bit-2.c|  4 ++--
 gcc/testsuite/gcc.target/arc/cmem-bit-3.c|  4 ++--
 gcc/testsuite/gcc.target/arc/cmem-bit-4.c|  4 ++--
 gcc/testsuite/gcc.target/arc/interrupt-2.c   |  3 ++-
 gcc/testsuite/gcc.target/arc/store-merge-1.c |  3 ++-
 9 files changed, 30 insertions(+), 16 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arc/add_n-combine.c 
b/gcc/testsuite/gcc.target/arc/add_n-combine.c
index cd32ed386f5..bc400df669e 100644
--- a/gcc/testsuite/gcc.target/arc/add_n-combine.c
+++ b/gcc/testsuite/gcc.target/arc/add_n-combine.c
@@ -1,5 +1,5 @@
 /* { dg-do compile }  */
-/* { dg-options "-O2 -fdump-rtl-combine" }  */
+/* { dg-options "-O2" }  */
 
 struct b1 {
   char c;
@@ -45,4 +45,6 @@ void f() {
   a(at3.bn[bu]);
 }
 
-/* { dg-final { scan-rtl-dump-times "\\*add_n" 2 "combine" } } */
+/* { dg-final { scan-assembler "add1" } } */
+/* { dg-final { scan-assembler "add2" } } */
+/* { dg-final { scan-assembler "add3" } } */
diff --git a/gcc/testsuite/gcc.target/arc/arc.exp 
b/gcc/testsuite/gcc.target/arc/arc.exp
index 55e12137a2a..ac1d5b67048 100644
--- a/gcc/testsuite/gcc.target/arc/arc.exp
+++ b/gcc/testsuite/gcc.target/arc/arc.exp
@@ -94,6 +94,16 @@ proc check_effective_target_barrelshifter { } {
 }]
 }
 
+#return 1 if we have code density option on.
+proc check_effective_target_codedensity { } {
+return [check_no_compiler_messages codedensity assembly {
+#if !defined(__ARC_CODE_DENSITY__)
+#error No code density option for this config
+#endif
+}]
+}
+
+
 #return 1 if we use ARCv2 Accumulator registers
 proc check_effective_target_accregs { } {
 return [check_no_compiler_messages accregs assembly {
diff --git a/gcc/testsuite/gcc.target/arc/cmem-7.c 
b/gcc/testsuite/gcc.target/arc/cmem-7.c
index 02673271172..ad7f25d9f8c 100644
--- a/gcc/testsuite/gcc.target/arc/cmem-7.c
+++ b/gcc/testsuite/gcc.target/arc/cmem-7.c
@@ -21,7 +21,7 @@ some_function ()
   return 0;
 }
 
-/* { dg-final { scan-assembler "xldb \[^\n\]*@ss" } } */
-/* { dg-final { scan-assembler "xstb \[^\n\]*@ss" } } */
-/* { dg-final { scan-assembler-not "xldb \[^\n\]*@tt" } } */
-/* { dg-final { scan-assembler-not "xstb \[^\n\]*@tt" } } */
+/* { dg-final { scan-assembler "xldb\\s+\[^\n\]*@ss" } } */
+/* { dg-final { scan-assembler "xstb\\s+\[^\n\]*@ss" } } */
+/* { dg-final { scan-assembler-not "xldb\\s+\[^\n\]*@tt" } } */
+/* { dg-final { scan-assembler-not "xstb\\s+\[^\n\]*@tt" } } */
diff --git a/gcc/testsuite/gcc.target/arc/cmem-bit-1.c 
b/gcc/testsuite/gcc.target/arc/cmem-bit-1.c
index d49ab5cd44f..d3471a2e621 100644
--- a/gcc/testsuite/gcc.target/arc/cmem-bit-1.c
+++ b/gcc/testsuite/gcc.target/arc/cmem-bit-1.c
@@ -16,5 +16,5 @@ void foo() {
 bar();
 }
 
-/* { dg-final { scan-assembler "xldb r\[0-9\]+,\\\[@a_strange_bool\\\]" } } */
-/* { dg-final { scan-assembler "btst_s r\[0-9\]+,7" { target arceb-*-* } } } */
+/* { dg-final { scan-assembler "xldb\\s+r\[0-9\]+,\\\[@a_strange_bool\\\]" } } 
*/
+/* { dg-final { scan-assembler "btst_s\\s+r\[0-9\]+,7" { target arceb-*-* } } 
} */
diff --git a/gcc/testsuite/gcc.target/arc/cmem-bit-2.c 
b/gcc/testsuite/gcc.target/arc/cmem-bit-2.c
index 45b49c6dfc3..4b022944f60 100644
--- a/gcc/testsuite/gcc.target/arc/cmem-bit-2.c
+++ b/gcc/testsuite/gcc.target/arc/cmem-bit-2.c
@@ -16,5 +16,5 @@ void foo() {
 bar();
 }
 
-/* { dg-final { scan-assembler "xldb r\[0-9\]+,\\\[@a_strange_bool\\\]" } } */
-/* { dg-final { scan-assembler "btst_s r\[0-9\]+,7" { target arceb-*-* } } } */
+/* { dg-final { scan-assembler "xldb\\s+r\[0-9\]+,\\\[@a_strange_bool\\\]" } } 
*/
+/* { dg-final { scan-assembler "btst_s\\s+r\[0-9\]+,7" { target arceb-*-* } } 
} */
diff --git a/gcc/testsuite/gcc.target/arc/cmem-bit-3.c 
b/gcc/testsuite/gcc.target/arc/cmem-bit-3.c
index 371ff2bca8b..40fbb934bf9 100644
--- a/gcc/testsuite/gcc.target/arc/cmem-bit-3.c
+++ b/gcc/testsuite/gcc.target/arc/cmem-bit-3.c
@@ -16,5 +16,5 

Re: [Committed] IBM Z: Add pattern for load truth value of comparison into reg

[Richard Henderson]

On 11/7/19 12:52 PM, Andreas Krebbel wrote:
> +; Such patterns get directly emitted by noce_emit_store_flag.
> +(define_insn_and_split "*cstorecc_z13"
> +  [(set (match_operand:GPR  0 "register_operand""=")
> + (match_operator:GPR 1 "s390_comparison"
> + [(match_operand 2 "cc_reg_operand""c")
> +  (match_operand 3 "const_int_operand"  "")]))]

The clobbered-output seems superfluous, since it can't overlap "c".
I believe the only valid const_int is 0, fwiw, so perhaps matching any
const_int is overkill.

Does it help Z12 to allow the 3-insn sequence using LOC(G)R?

> +  "TARGET_Z13"
> +  "#"
 > +  "reload_completed"
> +  [(set (match_dup 0) (const_int 0))
> +   (set (match_dup 0)
> + (if_then_else:GPR
> +  (match_op_dup 1 [(match_dup 2) (match_dup 3)])
> +  (const_int 1)
> +  (match_dup 0)))])


r~

Re: [PATCH 3/7] Apply mechanical replacement (generated patch).

[Richard Biener]

On Thu, Nov 7, 2019 at 1:35 PM Martin Liska  wrote:
>
>
> gcc/ChangeLog:

I think I've noticed at least one long line (please double-check):

- if (tree_to_uhwi (t) < (unsigned HOST_WIDE_INT)
INTEGER_SHARE_LIMIT)
+ if (tree_to_uhwi (t) < (unsigned HOST_WIDE_INT)
param_integer_share_limit)

as a followup I notice that the targets *_default_params () functions should
be merged into the default-options structs they have (did you check the
defaults are still applied and user-overridable?)

> 2019-11-07  Martin Liska  
>
> * asan.c (asan_sanitize_stack_p): Replace old parameter syntax
> with the new one, include opts.h if needed.  Use SET_OPTION_IF_UNSET
> macro.
> (asan_sanitize_allocas_p): Likewise.
> (asan_emit_stack_protection): Likewise.
> (asan_protect_global): Likewise.
> (instrument_derefs): Likewise.
> (instrument_builtin_call): Likewise.
> (asan_expand_mark_ifn): Likewise.
> * auto-profile.c (auto_profile): Likewise.
> * bb-reorder.c (copy_bb_p): Likewise.
> (duplicate_computed_gotos): Likewise.
> * builtins.c (inline_expand_builtin_string_cmp): Likewise.
> * cfgcleanup.c (try_crossjump_to_edge): Likewise.
> (try_crossjump_bb): Likewise.
> * cfgexpand.c (defer_stack_allocation): Likewise.
> (stack_protect_classify_type): Likewise.
> (pass_expand::execute): Likewise.
> * cfgloopanal.c (expected_loop_iterations_unbounded): Likewise.
> (estimate_reg_pressure_cost): Likewise.
> * cgraph.c (cgraph_edge::maybe_hot_p): Likewise.
> * combine.c (combine_instructions): Likewise.
> (record_value_for_reg): Likewise.
> * common/config/aarch64/aarch64-common.c 
> (aarch64_option_validate_param): Likewise.
> (aarch64_option_default_params): Likewise.
> * common/config/ia64/ia64-common.c (ia64_option_default_params): 
> Likewise.
> * common/config/powerpcspe/powerpcspe-common.c 
> (rs6000_option_default_params): Likewise.
> * common/config/rs6000/rs6000-common.c 
> (rs6000_option_default_params): Likewise.
> * common/config/sh/sh-common.c (sh_option_default_params): Likewise.
> * config/aarch64/aarch64.c (aarch64_output_probe_stack_range): 
> Likewise.
> (aarch64_allocate_and_probe_stack_space): Likewise.
> (aarch64_expand_epilogue): Likewise.
> (aarch64_override_options_internal): Likewise.
> * config/alpha/alpha.c (alpha_option_override): Likewise.
> * config/arm/arm.c (arm_option_override): Likewise.
> (arm_valid_target_attribute_p): Likewise.
> * config/i386/i386-options.c (ix86_option_override_internal): 
> Likewise.
> * config/i386/i386.c (get_probe_interval): Likewise.
> (ix86_adjust_stack_and_probe_stack_clash): Likewise.
> (ix86_max_noce_ifcvt_seq_cost): Likewise.
> * config/ia64/ia64.c (ia64_adjust_cost): Likewise.
> * config/rs6000/rs6000-logue.c 
> (get_stack_clash_protection_probe_interval): Likewise.
> (get_stack_clash_protection_guard_size): Likewise.
> * config/rs6000/rs6000.c (rs6000_option_override_internal): Likewise.
> * config/s390/s390.c (allocate_stack_space): Likewise.
> (s390_emit_prologue): Likewise.
> (s390_option_override_internal): Likewise.
> * config/sparc/sparc.c (sparc_option_override): Likewise.
> * config/visium/visium.c (visium_option_override): Likewise.
> * coverage.c (get_coverage_counts): Likewise.
> (coverage_compute_profile_id): Likewise.
> (coverage_begin_function): Likewise.
> (coverage_end_function): Likewise.
> * cse.c (cse_find_path): Likewise.
> (cse_extended_basic_block): Likewise.
> (cse_main): Likewise.
> * cselib.c (cselib_invalidate_mem): Likewise.
> * dse.c (dse_step1): Likewise.
> * emit-rtl.c (set_new_first_and_last_insn): Likewise.
> (get_max_insn_count): Likewise.
> (make_debug_insn_raw): Likewise.
> (init_emit): Likewise.
> * explow.c (compute_stack_clash_protection_loop_data): Likewise.
> * final.c (compute_alignments): Likewise.
> * fold-const.c (fold_range_test): Likewise.
> (fold_truth_andor): Likewise.
> (tree_single_nonnegative_warnv_p): Likewise.
> (integer_valued_real_single_p): Likewise.
> * gcse.c (want_to_gcse_p): Likewise.
> (prune_insertions_deletions): Likewise.
> (hoist_code): Likewise.
> (gcse_or_cprop_is_too_expensive): Likewise.
> * ggc-common.c: Likewise.
> * ggc-page.c (ggc_collect): Likewise.
> * gimple-loop-interchange.cc (MAX_NUM_STMT): Likewise.
> (MAX_DATAREFS): Likewise.
> (OUTER_STRIDE_RATIO): Likewise.
> * gimple-loop-jam.c (tree_loop_unroll_and_jam): Likewise.
> * 

Re: [PATCH] Enhance syntax of -fdbg-cnt.

[Martin Liška]

On 11/11/19 3:19 PM, Richard Biener wrote:

On Mon, Nov 11, 2019 at 9:17 AM Martin Liška  wrote:


Hi.

The patch makes debug counter more usable. In particular, one can now
list multiple closed intervals and -fdbg-cnt-list can reflect that.
Based on the discussion with Richard, I decided to leave semi-closed
intervals and make it closed, it's more intuitive.

Example:
$ g++ -O2 tramp3d-v4.ii 
-fdbg-cnt=match:1-2:6-10:11-20,dce:100:105-200,merged_ipa_icf:300-300 -c 
-fdbg-cnt-list
...
counter name   closed intervals
-
...
dce[1, 100], [105, 200]
...
match  [1, 2], [6, 10], [11, 20]
merged_ipa_icf [300, 300]

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?


+  /* Reverse intervals exactly once.  */
+  if (v == 1)
+limits[index]->reverse ();

why not do this at option processing time?


Because we don't have there any dbgcnt API. Right now one can use multiple
-fdbg-cnt options on a command line and that's why I'm doing that lazily.


I think sorted insertion
is reasonable here (I don't see you sorting them at all?).


I do expect a sorted intervals by user. If it's not provided, an error message
is directly emitted.



-static unsigned int limit_low[debug_counter_number_of_counters];
+static auto_vec
*limits[debug_counter_number_of_counters] = {NULL};

I think you can avoid one indirection here (vec<> is just one pointer) by doing

static vec limits[debug_counter_number_of_counters] = { vNULL };

?  Verify you get no runtime ctor, not sure if that's correct C++ for
initializing
all elements by vNULL, not just the first...

Alternatively I'd lazily allocate the whole vector rather than each individual
vector (at option processing time again), so

static vec (*limits)[];


I fully agree with that we should reduce one level of indirection.
Lemme take a look..

Thanks,
Martin



Thanks,
Richard.


Thanks,
Martin

gcc/ChangeLog:

2019-11-08  Martin Liska  

 * common.opt: Document change of -fdbg-cnt option.
 * dbgcnt.c (DEBUG_COUNTER): Remove.
 (dbg_cnt_is_enabled): Remove.
 (dbg_cnt): Work with new intervals.
 (dbg_cnt_set_limit_by_index): Set to new
 list of intervals.
 (dbg_cnt_set_limit_by_name): Likewise.
 (dbg_cnt_process_single_pair): Process new format.
 (dbg_cnt_process_opt): Likewise.
 (dbg_cnt_list_all_counters): Likewise.
 * doc/invoke.texi: Document change of -fdbg-cnt option.

gcc/testsuite/ChangeLog:

2019-11-08  Martin Liska  

 * gcc.dg/ipa/ipa-icf-39.c: Update -fdbg-cnt to the new format.
 * gcc.dg/pr68766.c: Likewise.
---
   gcc/common.opt|   2 +-
   gcc/dbgcnt.c  | 157 +++---
   gcc/doc/invoke.texi   |  15 ++-
   gcc/testsuite/gcc.dg/ipa/ipa-icf-39.c |   3 +-
   gcc/testsuite/gcc.dg/pr68766.c|   1 -
   5 files changed, 103 insertions(+), 75 deletions(-)

Re: [8/n] Replace autovectorize_vector_sizes with autovectorize_vector_modes

[Richard Biener]

On Wed, Oct 30, 2019 at 4:58 PM Richard Sandiford
 wrote:
>
> Richard Biener  writes:
> > On Fri, Oct 25, 2019 at 2:37 PM Richard Sandiford
> >  wrote:
> >>
> >> This is another patch in the series to remove the assumption that
> >> all modes involved in vectorisation have to be the same size.
> >> Rather than have the target provide a list of vector sizes,
> >> it makes the target provide a list of vector "approaches",
> >> with each approach represented by a mode.
> >>
> >> A later patch will pass this mode to targetm.vectorize.related_mode
> >> to get the vector mode for a given element mode.  Until then, the modes
> >> simply act as an alternative way of specifying the vector size.
> >
> > Is there a restriction to use integer vector modes for the hook
> > or would FP vector modes be OK as well?
>
> Conceptually, each mode returned by the hook represents a set of vector
> modes, with the set containing one member for each supported element
> type.  The idea is to represent the set using the member with the
> smallest element type, preferring integer modes over floating-point
> modes in the event of a tie.  So using a floating-point mode as the
> representative mode is fine if floating-point elements are the smallest
> (or only) supported element type.
>
> > Note that your x86 change likely disables word_mode vectorization with
> > -mno-sse?
>
> No, that still works, because...
>
> > That is, how do we represent GPR vectorization "size" here?
> > The preferred SIMD mode hook may return an integer mode,
> > are non-vector modes OK for autovectorize_vector_modes?
>
> ...at least with all current targets, preferred_simd_mode is only
> an integer mode if the target has no "real" vectorisation support
> for that element type.  There's no need to handle that case in
> autovectorize_vector_sizes/modes, and e.g. the x86 hook does nothing
> when SSE is disabled.
>
> So while preferred_simd_mode can continue to return integer modes,
> autovectorize_vector_modes always returns vector modes.

Hmm, I see.  IIRC I was playing with a patch for x86 that
enabled word-mode vectorization (64bits) for SSE before (I see
we don't do that at the moment).  The MMX-with-SSE has made
that somewhat moot but with iterating over modes we could
even make MMX-with-SSE (MMX modes) and word-mode vectors
coexist by allowing the hook to return V4SI, V2SI, DImode?
Because MMX-with-SSE might be more costly than word-mode
but can of course handle more cases.

So you say the above isn't supported and cannot be made supported?

Thanks,
Richard.

> This patch just treats the mode as an alternative way of specifying
> the vector size.  11/n then tries to use related_vector_mode to choose
> the vector mode for each element type instead.  But 11/n only uses
> related_vector_mode if vec_info::vector_mode is a vector mode.  If it's
> an integer mode (as for -mno-sse), or if related_vector_mode fails to
> find a vector mode, then we still fall back to mode_for_vector and so
> pick an integer mode in the same cases as before.
>
> Thanks,
> Richard

Re: [PATCH 3/X] [libsanitizer] Add option to bootstrap using HWASAN

[Martin Liška]

On 11/7/19 7:37 PM, Matthew Malcomson wrote:

+@item @samp{bootstrap-hwasan}
+Compiles GCC itself using HWAddress Sanitization in order to catch invalid
+memory accesses within the GCC code.  This option is only available on AArch64
+targets with a very recent linux kernel (5.4 or later).
+


Apparently, I see this hunk being applied:

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 2cb8a342a2c..ed47796e052 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2671,6 +2671,11 @@ the build tree.
 
 @end table
 
+@item @samp{bootstrap-hwasan}

+Compiles GCC itself using HWAddress Sanitization in order to catch invalid
+memory accesses within the GCC code.  This option is only available on AArch64
+targets with a very recent linux kernel (5.4 or later).
+
 @section Building a cross compiler
 
 When building a cross compiler, it is not generally possible to do a


and then I see:

make[2]: Entering directory '/dev/shm/objdir/gcc'
if [ xinfo = xinfo ]; then \
makeinfo --split-size=500 --split-size=500 --no-split -I 
/home/marxin/Programming/gcc/gcc/doc \
-I /home/marxin/Programming/gcc/gcc/doc/include -o 
doc/gccinstall.info /home/marxin/Programming/gcc/gcc/doc/install.texi; \
fi
/home/marxin/Programming/gcc/gcc/doc/install.texi:2674: @item outside of table 
or list
make[2]: *** [Makefile:3279: doc/gccinstall.info] Error 1
make[2]: Leaving directory '/dev/shm/objdir/gcc'

Can you please check it?
Thanks,
Martin

Re: [PATCH] Relax lto-dump.o dependency.

[Richard Biener]

On Mon, Nov 11, 2019 at 3:06 PM Martin Liška  wrote:
>
> Hi.
>
> Current lto-dump.o relies on some FE generated files as
> pre-requirement. That hover delays LTO linking of the lto-dump
> and so that I adjusted the dependency to LTO_OBJS which will
> work as well.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?

OK.

> Thanks,
> Martin
>
> gcc/lto/ChangeLog:
>
> 2019-11-11  Martin Liska  
>
> * Make-lang.in: Relax dependency of lto-dump.o to
> LTO_OBJS which will allow faster linking (mainly with LTO).
> ---
>   gcc/lto/Make-lang.in | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
>

Re: [PATCH] Sort debug counter names.

[Richard Biener]

On Mon, Nov 11, 2019 at 9:23 AM Martin Liška  wrote:
>
> Hi.
>
> The small patch is about sorting of debug counter
> values.
>
> Ready to be installed?

OK

> Thanks,
> Martin

Re: [PATCH] Enhance syntax of -fdbg-cnt.

[Richard Biener]

On Mon, Nov 11, 2019 at 9:17 AM Martin Liška  wrote:
>
> Hi.
>
> The patch makes debug counter more usable. In particular, one can now
> list multiple closed intervals and -fdbg-cnt-list can reflect that.
> Based on the discussion with Richard, I decided to leave semi-closed
> intervals and make it closed, it's more intuitive.
>
> Example:
> $ g++ -O2 tramp3d-v4.ii 
> -fdbg-cnt=match:1-2:6-10:11-20,dce:100:105-200,merged_ipa_icf:300-300 -c 
> -fdbg-cnt-list
> ...
>counter name   closed intervals
> -
> ...
>dce[1, 100], [105, 200]
> ...
>match  [1, 2], [6, 10], [11, 20]
>merged_ipa_icf [300, 300]
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?

+  /* Reverse intervals exactly once.  */
+  if (v == 1)
+limits[index]->reverse ();

why not do this at option processing time?  I think sorted insertion
is reasonable here (I don't see you sorting them at all?).

-static unsigned int limit_low[debug_counter_number_of_counters];
+static auto_vec
*limits[debug_counter_number_of_counters] = {NULL};

I think you can avoid one indirection here (vec<> is just one pointer) by doing

static vec limits[debug_counter_number_of_counters] = { vNULL };

?  Verify you get no runtime ctor, not sure if that's correct C++ for
initializing
all elements by vNULL, not just the first...

Alternatively I'd lazily allocate the whole vector rather than each individual
vector (at option processing time again), so

static vec (*limits)[];

Thanks,
Richard.

> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2019-11-08  Martin Liska  
>
> * common.opt: Document change of -fdbg-cnt option.
> * dbgcnt.c (DEBUG_COUNTER): Remove.
> (dbg_cnt_is_enabled): Remove.
> (dbg_cnt): Work with new intervals.
> (dbg_cnt_set_limit_by_index): Set to new
> list of intervals.
> (dbg_cnt_set_limit_by_name): Likewise.
> (dbg_cnt_process_single_pair): Process new format.
> (dbg_cnt_process_opt): Likewise.
> (dbg_cnt_list_all_counters): Likewise.
> * doc/invoke.texi: Document change of -fdbg-cnt option.
>
> gcc/testsuite/ChangeLog:
>
> 2019-11-08  Martin Liska  
>
> * gcc.dg/ipa/ipa-icf-39.c: Update -fdbg-cnt to the new format.
> * gcc.dg/pr68766.c: Likewise.
> ---
>   gcc/common.opt|   2 +-
>   gcc/dbgcnt.c  | 157 +++---
>   gcc/doc/invoke.texi   |  15 ++-
>   gcc/testsuite/gcc.dg/ipa/ipa-icf-39.c |   3 +-
>   gcc/testsuite/gcc.dg/pr68766.c|   1 -
>   5 files changed, 103 insertions(+), 75 deletions(-)
>
>

Re: [RFC] Only warn for maybe-uninitialized SRAed bits in -Wextra (PR 80635)

[Richard Biener]

On Fri, Nov 8, 2019 at 1:41 PM Martin Jambor  wrote:
>
> Hi,
>
> this patch is an attempt to implement my idea from a previous thread
> about moving -Wmaybe-uninitialized to -Wextra:
>
> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00220.html
>
> Specifically, it attempts to split -Wmaybe-uninitialized into those that
> are about SRA DECLs and those which are not, and move to -Wextra only
> the former ones.  The main idea is that false -Wmaybe-uninitialized
> warings about values that are scalar in user's code are easy to silence
> by initializing them to zero or something, as opposed to bits of
> aggregates such as a value in std::optional which are not.  Therefore,
> the warnings about user-scalars can remain in -Wall but warnings about
> SRAed pieces should be moved to -Wextra.
>
> The patch is a bit bigger because of documentation (which I'll be happy
> to improve based on your suggestions) and testsuite churn, but the main
> bit is the following added test in warn_uninit function:
>
>   if (wc == OPT_Wmaybe_uninitialized
>   && SSA_NAME_VAR (t)
>   && DECL_ARTIFICIAL (SSA_NAME_VAR (t))
>   && DECL_HAS_DEBUG_EXPR_P (SSA_NAME_VAR (t)))
> {
>   if (warn_maybe_uninitialized_aggregates)
> wc = OPT_Wmaybe_uninitialized_aggregates;
>   else
> return;
> }

I wonder if this works in practice since the whole point of SRA is to
have things copy propagated out (so the 't' with the SSA_NAME_VAR
doesn't prevail or gets commoned with sth else).  Or is this about
the default defs SRA creates itself to actually emit uninit warnings?

> The reason why I also test DECL_HAS_DEBUG_EXPR_P is
> gfortran.dg/pr39666-2.f90 - without it the test silences a warning about
> a decl representing the return value which is an artificial scalar
> variable (probably all the way from the front-end).  We can of course
> not care about not warning for it but then I don't know how to call and
> document the new option :-)  Generally, if someone can think of a better
> test to identify SRA DECLs, I'll be happy to change that.  We might put
> a bit to identify SRA decls in the decl tree, but I tend to think that
> is not a good use of the few remaining bits there.
>
> What do you think, is something along these lines a good idea?
>
> Thanks,
>
> Martin
>
>
>
> 2019-11-08  Martin Jambor  
>
> * common.opt (Wmaybe-uninitialized-aggregates): New.
> * tree-ssa-uninit.c (gate_warn_uninitialized): Also run if
> warn_maybe_uninitialized_aggregates is set.
> (warn_uninit): Warn for artificial DECLs only if
> warn_maybe_uninitialized_aggregates is set.
> * doc/invoke.texi (Warning Options): Add
> -Wmaybe-uninitialized-aggregates to the list.
> (-Wextra): Likewise.
> (-Wmaybe-uninitialized): Document that it only works on scalars.
> (-Wmaybe-uninitialized-aggregates): Document.
>
> testsuite/
> * gcc.dg/pr45083.c: Add Wmaybe-uninitialized-aggregates to options.
> * gcc.dg/ubsan/pr81981.c: Likewise.
> * gfortran.dg/pr25923.f90: Likewise.
> * g++.dg/warn/pr80635.C: New.
> ---
>  gcc/common.opt|  4 +++
>  gcc/doc/invoke.texi   | 18 +--
>  gcc/testsuite/g++.dg/warn/pr80635.C   | 45 +++
>  gcc/testsuite/gcc.dg/pr45083.c|  2 +-
>  gcc/testsuite/gcc.dg/ubsan/pr81981.c  |  2 +-
>  gcc/testsuite/gfortran.dg/pr25923.f90 |  2 +-
>  gcc/tree-ssa-uninit.c | 14 -
>  7 files changed, 81 insertions(+), 6 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/warn/pr80635.C
>
> diff --git a/gcc/common.opt b/gcc/common.opt
> index cc279f411d7..03769299df8 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -783,6 +783,10 @@ Wmaybe-uninitialized
>  Common Var(warn_maybe_uninitialized) Warning EnabledBy(Wuninitialized)
>  Warn about maybe uninitialized automatic variables.
>
> +Wmaybe-uninitialized-aggregates
> +Common Var(warn_maybe_uninitialized_aggregates) Warning EnabledBy(Wextra)
> +Warn about maybe uninitialized automatic parts of aggregates.
> +
>  Wunreachable-code
>  Common Ignore Warning
>  Does nothing. Preserved for backward compatibility.
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index faa7fa95a0e..dbc3219b770 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -328,7 +328,8 @@ Objective-C and Objective-C++ Dialects}.
>  -Wzero-length-bounds @gol
>  -Winvalid-pch  -Wlarger-than=@var{byte-size} @gol
>  -Wlogical-op  -Wlogical-not-parentheses  -Wlong-long @gol
> --Wmain  -Wmaybe-uninitialized  -Wmemset-elt-size  -Wmemset-transposed-args 
> @gol
> +-Wmain  -Wmaybe-uninitialized -Wmaybe-uninitialized-aggregates @gol
> +-Wmemset-elt-size  -Wmemset-transposed-args @gol
>  -Wmisleading-indentation  -Wmissing-attributes  -Wmissing-braces @gol
>  -Wmissing-field-initializers  -Wmissing-format-attribute @gol
>  -Wmissing-include-dirs  -Wmissing-noreturn  

[PATCH] Relax lto-dump.o dependency.

[Martin Liška]

Hi.

Current lto-dump.o relies on some FE generated files as
pre-requirement. That hover delays LTO linking of the lto-dump
and so that I adjusted the dependency to LTO_OBJS which will
work as well.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

gcc/lto/ChangeLog:

2019-11-11  Martin Liska  

* Make-lang.in: Relax dependency of lto-dump.o to
LTO_OBJS which will allow faster linking (mainly with LTO).
---
 gcc/lto/Make-lang.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/gcc/lto/Make-lang.in b/gcc/lto/Make-lang.in
index 00701aec800..faee8899502 100644
--- a/gcc/lto/Make-lang.in
+++ b/gcc/lto/Make-lang.in
@@ -92,7 +92,7 @@ $(LTO_DUMP_EXE): $(LTO_EXE) $(LTO_DUMP_OBJS) $(BACKEND) $(LIBDEPS)
 	+$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
 		$(LTO_DUMP_OBJS) $(BACKEND) $(BACKENDLIBS) $(LIBS)
 
-lto/lto-dump.o: $(LTO_EXE)
+lto/lto-dump.o: $(LTO_OBJS)
 
 lto1.fda: ../prev-gcc/lto1$(exeext) ../prev-gcc/$(PERF_DATA)
 	$(CREATE_GCOV) -binary ../prev-gcc/lto1$(exeext) -gcov lto1.fda -profile ../prev-gcc/$(PERF_DATA) -gcov_version 1

[PATCH] Use more SET_OPTION_IF_UNSET.

[Martin Liška]

There's one more refactoring patch that is about more
usage of SET_OPTION_IF_UNSET for parameters.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin
>From 638a27f03c7ce06bcc02d7c5d27ba6eb794abede Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 11 Nov 2019 13:35:55 +0100
Subject: [PATCH] Use more SET_OPTION_IF_UNSET.

gcc/ChangeLog:

2019-11-11  Martin Liska  

	* config/i386/i386-options.c (ix86_recompute_optlev_based_flags):
	Use SET_OPTION_IF_UNSET.
	(ix86_option_override_internal): Likewise.
	* opts.c (default_options_optimization): Likewise.
	(finish_options): Likewise.
	(enable_fdo_optimizations): Likewise.
	(common_handle_option): Likewise.

gcc/c-family/ChangeLog:

2019-11-11  Martin Liska  

	* c-opts.c (c_common_post_options):
	Use SET_OPTION_IF_UNSET.

gcc/fortran/ChangeLog:

2019-11-11  Martin Liska  

	* options.c (gfc_init_options):
	Use SET_OPTION_IF_UNSET.

gcc/go/ChangeLog:

2019-11-11  Martin Liska  

	* go-lang.c (go_langhook_post_options):
	Use SET_OPTION_IF_UNSET.
---
 gcc/c-family/c-opts.c  |  34 -
 gcc/config/i386/i386-options.c |  34 +
 gcc/fortran/options.c  |   4 +-
 gcc/go/go-lang.c   |  20 +++---
 gcc/opts.c | 123 +
 5 files changed, 94 insertions(+), 121 deletions(-)

diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 75b69597be2..c913291c07c 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -828,9 +828,9 @@ c_common_post_options (const char **pfilename)
 
   /* C2X Annex F does not permit certain built-in functions to raise
  "inexact".  */
-  if (flag_isoc2x
-  && !global_options_set.x_flag_fp_int_builtin_inexact)
-flag_fp_int_builtin_inexact = 0;
+  if (flag_isoc2x)
+SET_OPTION_IF_UNSET (_options, _options_set,
+			 flag_fp_int_builtin_inexact, 0);
 
   /* By default we use C99 inline semantics in GNU99 or C99 mode.  C99
  inline semantics are not supported in GNU89 or C89 mode.  */
@@ -847,9 +847,9 @@ c_common_post_options (const char **pfilename)
 
   /* If -ffreestanding, -fno-hosted or -fno-builtin then disable
  pattern recognition.  */
-  if (!global_options_set.x_flag_tree_loop_distribute_patterns
-  && flag_no_builtin)
-flag_tree_loop_distribute_patterns = 0;
+  if (flag_no_builtin)
+SET_OPTION_IF_UNSET (_options, _options_set,
+			 flag_tree_loop_distribute_patterns, 0);
 
   /* -Woverlength-strings is off by default, but is enabled by -Wpedantic.
  It is never enabled in C++, as the minimum limit is not normative
@@ -918,16 +918,17 @@ c_common_post_options (const char **pfilename)
  && (cxx_dialect >= cxx11 || flag_isoc99));
 
   /* -Wregister is enabled by default in C++17.  */
-  if (!global_options_set.x_warn_register)
-warn_register = cxx_dialect >= cxx17;
+  SET_OPTION_IF_UNSET (_options, _options_set, warn_register,
+		   cxx_dialect >= cxx17);
 
   /* -Wcomma-subscript is enabled by default in C++20.  */
-  if (!global_options_set.x_warn_comma_subscript)
-warn_comma_subscript = (cxx_dialect >= cxx2a && warn_deprecated);
+  SET_OPTION_IF_UNSET (_options, _options_set,
+		   warn_comma_subscript,
+		   cxx_dialect >= cxx2a && warn_deprecated);
 
   /* -Wvolatile is enabled by default in C++20.  */
-  if (!global_options_set.x_warn_volatile)
-warn_volatile = (cxx_dialect >= cxx2a && warn_deprecated);
+  SET_OPTION_IF_UNSET (_options, _options_set, warn_volatile,
+		   cxx_dialect >= cxx2a && warn_deprecated);
 
   /* Declone C++ 'structors if -Os.  */
   if (flag_declone_ctor_dtor == -1)
@@ -979,12 +980,13 @@ c_common_post_options (const char **pfilename)
   /* By default, enable the new inheriting constructor semantics along with ABI
  11.  New and old should coexist fine, but it is a change in what
  artificial symbols are generated.  */
-  if (!global_options_set.x_flag_new_inheriting_ctors)
-flag_new_inheriting_ctors = abi_version_at_least (11);
+  SET_OPTION_IF_UNSET (_options, _options_set,
+		   flag_new_inheriting_ctors,
+		   abi_version_at_least (11));
 
   /* For GCC 7, only enable DR150 resolution by default if -std=c++17.  */
-  if (!global_options_set.x_flag_new_ttp)
-flag_new_ttp = (cxx_dialect >= cxx17);
+  SET_OPTION_IF_UNSET (_options, _options_set, flag_new_ttp,
+		   cxx_dialect >= cxx17);
 
   if (cxx_dialect >= cxx11)
 {
diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
index c909f8ea1ed..b082228ebf2 100644
--- a/gcc/config/i386/i386-options.c
+++ b/gcc/config/i386/i386-options.c
@@ -1605,12 +1605,12 @@ ix86_recompute_optlev_based_flags (struct gcc_options *opts,
  in case they weren't overwritten by command line options.  */
   if (TARGET_64BIT_P (opts->x_ix86_isa_flags))
 {
-  if (opts->x_optimize >= 1 && !opts_set->x_flag_omit_frame_pointer)
-	opts->x_flag_omit_frame_pointer = !USE_IX86_FRAME_POINTER;
+  

Re: [Patch, fortran] PR fortran/92142 - CFI_setpointer corrupts descriptor

[Mark Eggleston]

Unfortunately ISO_Fortran_binding_16.f90 contains a typo resulting in:

FAIL: gfortran.dg/ISO_Fortran_binding_16.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_16.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_16.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_16.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for 
excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_16.f90   -O3 -g (test for excess 
errors)

FAIL: gfortran.dg/ISO_Fortran_binding_16.f90   -Os  (test for excess errors)

the cause is that it refers to ISO_Fortran_binding_15.c instead of 
ISO_Fortran_binding_16.c in the dg-additional-sources directive.


regards,

Mark

On 11/11/2019 10:29, Tobias Burnus wrote:

Hi José,

On 10/29/19 11:35 AM, José Rui Faustino de Sousa wrote:
Added the suggested check and a few touches to comments and the error 
message.

Thanks.

that might be a bug in the C code of the test itself
I took a look and although there are problems with the code of the 
test I do not think they are relevant.


Index: gcc/testsuite/gfortran.dg/ISO_Fortran_binding_10.c


I have included that patch.

Other remark: ChangeLog missing in the updated version of the patch. 
(I just saw that you did include it when posting initially.)


I have now committed the patch as Rev. 278048 to the trunk.
Thanks for the patch!

Cheers,

Tobias


--
https://www.codethink.co.uk/privacy.html

Re: Fix SLP downward group access classification (PR92420)

[Richard Biener]

On Fri, Nov 8, 2019 at 5:21 PM Richard Sandiford
 wrote:
>
> This PR was caused by the SLP handling in get_group_load_store_type
> returning VMAT_CONTIGUOUS rather than VMAT_CONTIGUOUS_REVERSE for
> downward groups.
>
> A more elaborate fix would be to try to combine the reverse permutation
> into SLP_TREE_LOAD_PERMUTATION for loads, but that's really a follow-on
> optimisation and not backport material.  It might also not necessarily
> be a win, if the target supports (say) reversing and odd/even swaps
> as independent permutes but doesn't recognise the combined form.
>
> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK for trunk?

OK.

> OK for branches without the assert, after a grace period?

OK as well.

Thanks,
Richard.

> Thanks,
> Richard
>
>
> 2019-11-08  Richard Sandiford  
>
> gcc/
> PR tree-optimization/92420
> * tree-vect-stmts.c (get_negative_load_store_type): Move further
> up file.
> (get_group_load_store_type): Use it for reversed SLP accesses.
>
> gcc/testsuite/
> * gcc.dg/vect/pr92420.c: New test.
>
> Index: gcc/tree-vect-stmts.c
> ===
> --- gcc/tree-vect-stmts.c   2019-11-08 09:06:29.482897293 +
> +++ gcc/tree-vect-stmts.c   2019-11-08 16:18:10.864080575 +
> @@ -2147,6 +2147,56 @@ perm_mask_for_reverse (tree vectype)
>return vect_gen_perm_mask_checked (vectype, indices);
>  }
>
> +/* A subroutine of get_load_store_type, with a subset of the same
> +   arguments.  Handle the case where STMT_INFO is a load or store that
> +   accesses consecutive elements with a negative step.  */
> +
> +static vect_memory_access_type
> +get_negative_load_store_type (stmt_vec_info stmt_info, tree vectype,
> + vec_load_store_type vls_type,
> + unsigned int ncopies)
> +{
> +  dr_vec_info *dr_info = STMT_VINFO_DR_INFO (stmt_info);
> +  dr_alignment_support alignment_support_scheme;
> +
> +  if (ncopies > 1)
> +{
> +  if (dump_enabled_p ())
> +   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
> +"multiple types with negative step.\n");
> +  return VMAT_ELEMENTWISE;
> +}
> +
> +  alignment_support_scheme = vect_supportable_dr_alignment (dr_info, false);
> +  if (alignment_support_scheme != dr_aligned
> +  && alignment_support_scheme != dr_unaligned_supported)
> +{
> +  if (dump_enabled_p ())
> +   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
> +"negative step but alignment required.\n");
> +  return VMAT_ELEMENTWISE;
> +}
> +
> +  if (vls_type == VLS_STORE_INVARIANT)
> +{
> +  if (dump_enabled_p ())
> +   dump_printf_loc (MSG_NOTE, vect_location,
> +"negative step with invariant source;"
> +" no permute needed.\n");
> +  return VMAT_CONTIGUOUS_DOWN;
> +}
> +
> +  if (!perm_mask_for_reverse (vectype))
> +{
> +  if (dump_enabled_p ())
> +   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
> +"negative step and reversing not supported.\n");
> +  return VMAT_ELEMENTWISE;
> +}
> +
> +  return VMAT_CONTIGUOUS_REVERSE;
> +}
> +
>  /* STMT_INFO is either a masked or unconditional store.  Return the value
> being stored.  */
>
> @@ -2273,7 +2323,15 @@ get_group_load_store_type (stmt_vec_info
>  "Peeling for outer loop is not supported\n");
>   return false;
> }
> - *memory_access_type = VMAT_CONTIGUOUS;
> + int cmp = compare_step_with_zero (stmt_info);
> + if (cmp < 0)
> +   *memory_access_type = get_negative_load_store_type
> + (stmt_info, vectype, vls_type, 1);
> + else
> +   {
> + gcc_assert (!loop_vinfo || cmp > 0);
> + *memory_access_type = VMAT_CONTIGUOUS;
> +   }
> }
>  }
>else
> @@ -2375,56 +2433,6 @@ get_group_load_store_type (stmt_vec_info
>return true;
>  }
>
> -/* A subroutine of get_load_store_type, with a subset of the same
> -   arguments.  Handle the case where STMT_INFO is a load or store that
> -   accesses consecutive elements with a negative step.  */
> -
> -static vect_memory_access_type
> -get_negative_load_store_type (stmt_vec_info stmt_info, tree vectype,
> - vec_load_store_type vls_type,
> - unsigned int ncopies)
> -{
> -  dr_vec_info *dr_info = STMT_VINFO_DR_INFO (stmt_info);
> -  dr_alignment_support alignment_support_scheme;
> -
> -  if (ncopies > 1)
> -{
> -  if (dump_enabled_p ())
> -   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
> -"multiple types with negative step.\n");
> -  return VMAT_ELEMENTWISE;
> -}
> -
> -  alignment_support_scheme = vect_supportable_dr_alignment (dr_info, false);
> -  if 

Re: [PATCH] Fix PR92324

[Richard Biener]

On Mon, 11 Nov 2019, Christophe Lyon wrote:

> On Fri, 8 Nov 2019 at 09:57, Richard Biener  wrote:
> >
> >
> > I've been sitting on this for a few days since I'm not 100% happy
> > with how the code looks like.  There's possibly still holes in it
> > (chains with mixed signed/unsigned adds for example might pick
> > up signed adds in the epilogue), but the wrong-code cases should
> > work fine now.  I'm probably going to followup with some
> > mass renaming of variable/parameter names to make it more clear
> > which stmt / type we are actually looking at ...
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
> >
> > Richard.
> >
> > 2019-11-08  Richard Biener  
> >
> > PR tree-optimization/
> > * tree-vect-loop.c (vect_create_epilog_for_reduction): Use
> > STMT_VINFO_REDUC_VECTYPE for all computations, inserting
> > sign-conversions as necessary.
> > (vectorizable_reduction): Reject conversions in the chain
> > that are not sign-conversions, base analysis on a non-converting
> > stmt and its operation sign.  Set STMT_VINFO_REDUC_VECTYPE.
> > * tree-vect-stmts.c (vect_stmt_relevant_p): Don't dump anything
> > for debug stmts.
> > * tree-vectorizer.h (_stmt_vec_info::reduc_vectype): New.
> > (STMT_VINFO_REDUC_VECTYPE): Likewise.
> >
> > * gcc.dg/vect/pr92205.c: XFAIL.
> > * gcc.dg/vect/pr92324-1.c: New testcase.
> > * gcc.dg/vect/pr92324-2.c: Likewise.
> >
> 
> Hi Richard,
> 
> This new testcase (pr92324-2.c) fails on arm/aarch64:
> FAIL: gcc.dg/vect/pr92324-2.c -flto -ffat-lto-objects execution test
> FAIL: gcc.dg/vect/pr92324-2.c execution test

Can you open a bugreport?  I suspect the arm/aarch64 vector
min/max patterns are bogus or we go a different code-path
in the vectorizer here (IIRC x86 has reduc_[us]max_* patterns
while aarch64 has none of that).

Thanks,
Richard.

> Christophe
> 
> 
> > Index: gcc/tree-vect-loop.c
> > ===
> > --- gcc/tree-vect-loop.c(revision 277922)
> > +++ gcc/tree-vect-loop.c(working copy)
> > @@ -4231,7 +4231,6 @@ vect_create_epilog_for_reduction (stmt_v
> >gimple *new_phi = NULL, *phi;
> >stmt_vec_info phi_info;
> >gimple_stmt_iterator exit_gsi;
> > -  tree vec_dest;
> >tree new_temp = NULL_TREE, new_name, new_scalar_dest;
> >gimple *epilog_stmt = NULL;
> >gimple *exit_phi;
> > @@ -4264,7 +4263,7 @@ vect_create_epilog_for_reduction (stmt_v
> >  }
> >gcc_assert (!nested_in_vect_loop || double_reduc);
> >
> > -  vectype = STMT_VINFO_VECTYPE (stmt_info);
> > +  vectype = STMT_VINFO_REDUC_VECTYPE (reduc_info);
> >gcc_assert (vectype);
> >mode = TYPE_MODE (vectype);
> >
> > @@ -4505,48 +4504,43 @@ vect_create_epilog_for_reduction (stmt_v
> >   one vector.  */
> >if (REDUC_GROUP_FIRST_ELEMENT (stmt_info) || direct_slp_reduc)
> >  {
> > +  gimple_seq stmts = NULL;
> >tree first_vect = PHI_RESULT (new_phis[0]);
> > -  gassign *new_vec_stmt = NULL;
> > -  vec_dest = vect_create_destination_var (scalar_dest, vectype);
> > +  first_vect = gimple_convert (, vectype, first_vect);
> >for (k = 1; k < new_phis.length (); k++)
> >  {
> >   gimple *next_phi = new_phis[k];
> >tree second_vect = PHI_RESULT (next_phi);
> > -  tree tem = make_ssa_name (vec_dest, new_vec_stmt);
> > -  new_vec_stmt = gimple_build_assign (tem, code,
> > - first_vect, second_vect);
> > -  gsi_insert_before (_gsi, new_vec_stmt, GSI_SAME_STMT);
> > - first_vect = tem;
> > + second_vect = gimple_convert (, vectype, second_vect);
> > +  first_vect = gimple_build (, code, vectype,
> > +first_vect, second_vect);
> >  }
> > +  gsi_insert_seq_before (_gsi, stmts, GSI_SAME_STMT);
> >
> >new_phi_result = first_vect;
> > -  if (new_vec_stmt)
> > -{
> > -  new_phis.truncate (0);
> > -  new_phis.safe_push (new_vec_stmt);
> > -}
> > +  new_phis.truncate (0);
> > +  new_phis.safe_push (SSA_NAME_DEF_STMT (first_vect));
> >  }
> >/* Likewise if we couldn't use a single defuse cycle.  */
> >else if (ncopies > 1)
> >  {
> >gcc_assert (new_phis.length () == 1);
> > +  gimple_seq stmts = NULL;
> >tree first_vect = PHI_RESULT (new_phis[0]);
> > -  gassign *new_vec_stmt = NULL;
> > -  vec_dest = vect_create_destination_var (scalar_dest, vectype);
> > +  first_vect = gimple_convert (, vectype, first_vect);
> >stmt_vec_info next_phi_info = loop_vinfo->lookup_stmt (new_phis[0]);
> >for (int k = 1; k < ncopies; ++k)
> > {
> >   next_phi_info = STMT_VINFO_RELATED_STMT (next_phi_info);
> >   tree second_vect = PHI_RESULT (next_phi_info->stmt);
> 

[PATCH,libstdc++] Update link to "Why not LGPL".

[Gerald Pfeifer]

Committed.  With a one line GIT log at the top. ;-)

Gerald


2019-11-11  Gerald Pfeifer  

* doc/xml/gnu/gpl-3.0.xml: Adjust link to "Why not LGPL".

Index: doc/xml/gnu/gpl-3.0.xml
===
--- doc/xml/gnu/gpl-3.0.xml (revision 278050)
+++ doc/xml/gnu/gpl-3.0.xml (working copy)
@@ -829,6 +829,6 @@ under certain conditions; type ‘show c<
 subroutine library, you may consider it more useful to permit linking
 proprietary applications with the library.  If this is what you want to do,
 use the GNU Lesser General Public License instead of 
this
-License.  But first, please read http://www.w3.org/1999/xlink; 
xlink:href="https://www.gnu.org/philosophy/why-not-lgpl.html;>https://www.gnu.org/philosophy/why-not-lgpl.html.
+License.  But first, please read http://www.w3.org/1999/xlink; 
xlink:href="https://www.gnu.org/licenses/why-not-lgpl.html;>https://www.gnu.org/licenses/why-not-lgpl.html.
   
 

Re: PC-relative TLS support

[Alan Modra]

On Mon, Nov 11, 2019 at 05:56:47AM -0600, Segher Boessenkool wrote:
> On Wed, Aug 21, 2019 at 09:55:28PM +0930, Alan Modra wrote:
> > This patch removes !TARGET_TLS_MARKERS support.  -mtls-markers (and
> > -mno-tls-markers) disappear as valid options too, because I figure
> > they haven't been used too much except by people testing the
> > compiler.
> 
> Okay.
> 
> > (rs6000_call_template_1): Delete TARGET_TLS_MARKERS test and
> > allow other UNSPECs besides UNSPEC_TLSGD and UNSPEC_TLSLD.
> 
> Why is that?  Should we allow the other code that can happen and keep
> the gcc_unreachable?  Or do we know that no other code can happen here
> ever, and the extra documentation isn't useful?

The code in question is just printing the @tlsgd or @tlsld arg.  I
don't see any point in asserting that no other UNSPEC could ever be
used in a call operand.  Other places dealing with UNSPEC_TLSGD
and UNSPEC_TLSLD don't check, and if another UNSPEC is invented for
some fancy future call insn it's quite unlikely to want to output
anything here.

(I don't think I found such an UNSPEC already extant..)

> > --- a/gcc/config/rs6000/rs6000.md
> > +++ b/gcc/config/rs6000/rs6000.md
> > @@ -9413,7 +9413,7 @@ (define_insn_and_split "*tls_gd"
> > (unspec:P [(match_operand:P 1 "rs6000_tls_symbol_ref" "")
> >(match_operand:P 2 "gpc_reg_operand" "b")]
> >   UNSPEC_TLSGD))]
> > -  "HAVE_AS_TLS && TARGET_TLS_MARKERS"
> > +  "HAVE_AS_TLS && !TARGET_XCOFF"
> 
> Should that be TARGET_ELF instead?

Either should work.  So, yes, probably better with TARGET_ELF.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH, rs6000] Refactor FP vector comparison operators

[Segher Boessenkool]

Hi!

On Mon, Nov 11, 2019 at 03:40:51PM +0800, Kewen.Lin wrote:
> This is a subsequent patch to refactor the existing float point
> vector comparison operator supports.  The patch to fix PR92132
> supplemented vector float point comparison by exposing the names
> for unordered/ordered/uneq/ltgt and adding ungt/unge/unlt/unle/
> ne.  As Segher pointed out, some patterns can be refactored
> together.  The main link on this is: 
> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00452.html
> 
> 
> The refactoring mainly follows the below patterns:
> 
> pattern 1:
>   lt(a,b) = gt(b,a)
>   le(a,b) = ge(b,a)

This is done by swap_condition normally.

> pattern 2:
>   unge(a,b) = ~gt(b,a)
>   unle(a,b) = ~gt(a,b)
>   ne(a,b)   = ~eq(a,b)
>   ungt(a,b) = ~ge(b,a)
>   unlt(a,b) = ~ge(a,b)

This is reverse_condition_maybe_unordered (and a swap, in two cases).

> pattern 3:
>   ltgt: gt(a,b) | gt(b,a)
>   ordered: ge(a,b) | ge(b,a)

That's the only interesting one :-)

> pattern 4:
>   uneq: ~gt(a,b) & ~gt(b,a)
>   unordered: ~ge(a,b) & ~ge(b,a)

That is 3, reversed.

> Naming the code iterators and attributes are really knotty for me :(.

Maybe the above helps :-)

>   (vector_ for VEC_F and vec_fp_cmp1): New
>   define_and_split.

> +;; code iterators and attributes for vector FP comparison operators:
> +
> +;; 1. lt and le.
> +(define_code_iterator vec_fp_cmp1 [lt le])
> +(define_code_attr vec_fp_cmp1_attr [(lt "gt")
> + (le "ge")])

So this is just (a subset of) swap_condition.

(I'm reordering stuff)

> +; 1. For lt and le:
> +; lt(a,b) = gt(b,a)
> +; le(a,b) = ge(b,a)
> +(define_insn_and_split "vector_"
>[(set (match_operand:VEC_F 0 "vfloat_operand")
> + (vec_fp_cmp1:VEC_F (match_operand:VEC_F 1 "vfloat_operand")
> +(match_operand:VEC_F 2 "vfloat_operand")))]
>"VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)"
>"#"
>""
> +  [(set (match_dup 0)
> + (:VEC_F (match_dup 2)
> +   (match_dup 1)))]
>  {
>  })

Empty preparation statements (the {}) can just be left out completely.

The split condition "" is incorrect, it should be "&& 1": if it starts
with "&&", the insn condition is included.

> +; 2. unge, unle, ne, ungt and unlt.
> +(define_code_iterator vec_fp_cmp2 [unge unle ne ungt unlt])
> +(define_code_attr vec_fp_cmp2_attr [(unge "gt")
> + (unle "gt")
> + (ne   "eq")
> + (ungt "ge")
> + (unlt "ge")])

> +; 2. For unge, unle, ne, ungt and unlt:
> +; unge(a,b) = ~gt(b,a)
> +; unle(a,b) = ~gt(a,b)
> +; ne(a,b)   = ~eq(a,b)
> +; ungt(a,b) = ~ge(b,a)
> +; unlt(a,b) = ~ge(a,b)
> +(define_insn_and_split "vector_"
>[(set (match_operand:VEC_F 0 "vfloat_operand")
> + (vec_fp_cmp2:VEC_F (match_operand:VEC_F 1 "vfloat_operand")
> +(match_operand:VEC_F 2 "vfloat_operand")))]
>"VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)"
>"#"
>""
>[(set (match_dup 3)
> + (:VEC_F (match_dup 1)
> +   (match_dup 2)))
> (set (match_dup 0)
> + (not:VEC_F (match_dup 3)))]
>  {
>operands[3] = gen_reg_rtx (mode);
> +
> +  if ( == UNGE ||  == UNGT)
> +std::swap (operands[1], operands[2]);
>  })

So maybe it is simplest to *do* use match_operator here, handle all of
lt gt le ge eq unge unle ungt unlt ne  in one define_expand, which then
swaps the condition and the args, and expand the extra not for the five
where that is needed?


> +;; 3. ltgt and ordered.
> +(define_code_iterator vec_fp_cmp3 [ltgt ordered])
> +(define_code_attr vec_fp_cmp3_attr [(ltgt "gt")
> + (ordered "ge")])
> +
> +;; 4. uneq and unordered.
> +(define_code_iterator vec_fp_cmp4 [uneq unordered])
> +(define_code_attr vec_fp_cmp4_attr [(uneq "gt")
> + (unordered "ge")])

And then another one for  ltgt uneq ordered unordered  perhaps?

So you'll need to define two new predicates then.  Something like
vector_fp_comparison_operator and, erm, vector_fp_extra_comparison_operator,
which kind of sucks as a name, but there is only one ;-)

Sorry for sending you first one way, and then back the other.


Segher

Re: [Patch][OpenMP][Fortran] Support absent optional args with use_device_{ptr,addr} (+ OpenACC's use_device clause)

[Thomas Schwinge]

Hi Tobias!

Thanks for looking into this mess ;-) of Fortran optional arguments
support for OMP, based on what Kwok has already developed.


On 2019-11-08T16:41:23+0100, Tobias Burnus  wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/use_device_ptr-optional-2.f90

When adding '{ dg-do run }' for torture testing (please remember to), I
see the '-O0' and '-O1' execution testing FAIL, complaining that
"libgomp: use_device_ptr pointer wasn't mapped".


Grüße
 Thomas


> @@ -0,0 +1,33 @@
> +! Check whether absent optional arguments are properly
> +! handled with use_device_{addr,ptr}.
> +program main
> + implicit none (type, external)
> + call foo()
> +contains
> +  subroutine foo(v, w, x, y, z)
> +integer, target, optional, value :: v
> +integer, target, optional :: w
> +integer, target, optional :: x(:)
> +integer, target, optional, allocatable :: y
> +integer, target, optional, allocatable :: z(:)
> +integer :: d
> +
> +!$omp target data map(d) use_device_addr(v, w, x, y, z)
> +  if(present(v)) stop 1
> +  if(present(w)) stop 2
> +  if(present(x)) stop 3
> +  if(present(y)) stop 4
> +  if(present(z)) stop 5
> +!$omp end target data
> +
> +! Using 'v' in use_device_ptr gives an ICE
> +! TODO: Find out what the OpenMP spec permits for use_device_ptr
> +
> +!$omp target data map(d) use_device_ptr(w, x, y, z)
> +  if(present(w)) stop 6
> +  if(present(x)) stop 7
> +  if(present(y)) stop 8
> +  if(present(z)) stop 9
> +!$omp end target data
> +  end subroutine foo
> +end program main


signature.asc
Description: PGP signature

Re: [wwwdocs] readings.html - "Porting GCC for Dunces" is gone

[Hans-Peter Nilsson]

> From: Gerald Pfeifer 
> Date: Sun, 10 Nov 2019 14:53:23 +0100

> Hi H-P,
> 
> it appears this download is gone. Do you have an alternate location?

Wha...?  No, not at the moment.

>http://ftp.axis.se/pub/users/hp/pgccfd/;>

While I could certainly enter a ticket and hope to get it
reinstated that way, I guess it's time to just take the hint.

Can it be hosted on gcc.gnu.org?  From my point of view, that
seems appropriate.

brgds, H-P

Re: PC-relative TLS support

[Segher Boessenkool]

On Wed, Aug 21, 2019 at 09:55:28PM +0930, Alan Modra wrote:
> This patch removes !TARGET_TLS_MARKERS support.  -mtls-markers (and
> -mno-tls-markers) disappear as valid options too, because I figure
> they haven't been used too much except by people testing the
> compiler.

Okay.

>   (rs6000_call_template_1): Delete TARGET_TLS_MARKERS test and
>   allow other UNSPECs besides UNSPEC_TLSGD and UNSPEC_TLSLD.

Why is that?  Should we allow the other code that can happen and keep
the gcc_unreachable?  Or do we know that no other code can happen here
ever, and the extra documentation isn't useful?

> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -9413,7 +9413,7 @@ (define_insn_and_split "*tls_gd"
>   (unspec:P [(match_operand:P 1 "rs6000_tls_symbol_ref" "")
>  (match_operand:P 2 "gpc_reg_operand" "b")]
> UNSPEC_TLSGD))]
> -  "HAVE_AS_TLS && TARGET_TLS_MARKERS"
> +  "HAVE_AS_TLS && !TARGET_XCOFF"

Should that be TARGET_ELF instead?

Okay for trunk with those two things looked at.  Thanks!


Segher