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

[Jakub Jelinek]

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.

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?

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.

--- gcc/cp/method.c.jj  2019-11-07 21:21:27.097760879 +0100
+++ gcc/cp/method.c 2019-11-11 08:28:22.633822845 +0100
@@ -1098,34 +1098,39 @@ early_check_defaulted_comparison (tree f
   ok = false;
 }
 
-  int i = DECL_NONSTATIC_MEMBER_FUNCTION_P (fn);
-  if (i && type_memfn_quals (TREE_TYPE (fn)) != TYPE_QUAL_CONST)
+  if (DECL_NONSTATIC_MEMBER_FUNCTION_P (fn)
+  && 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);
-  for (; parmnode != void_list_node; parmnode = TREE_CHAIN (parmnode))
+  tree firstparmnode = FUNCTION_FIRST_USER_PARMTYPE (fn);
+  for (tree parmnode = firstparmnode; 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;
-  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;
+  /* a non-static const member of C having one parameter of type const C&,
+or a friend of C having either two parameters of type const C& or two
+parameters of type C.  */
+  if ((!DECL_NONSTATIC_MEMBER_FUNCTION_P (fn)
+  && !same_type_p (TREE_VALUE (firstparmnode), parmtype))
+ || ((DECL_NONSTATIC_MEMBER_FUNCTION_P (fn)
+  || !same_type_p (parmtype, ctx))
+ && (TREE_CODE (parmtype) != REFERENCE_TYPE
+ || TYPE_QUALS (TREE_TYPE (parmtype)) != TYPE_QUAL_CONST
+ || !(same_type_ignoring_top_level_qualifiers_p
+   (TREE_TYPE (parmtype), ctx)
+   {
+ if (DECL_NONSTATIC_MEMBER_FUNCTION_P (fn))
+   error_at (loc, "defaulted %qD must have parameter type "
+  "%", fn, ctx);
+ else
+   error_at (loc, "defaulted %qD must have parameter types "
+  "%, % or "
+  "%qT, %qT", fn, ctx, ctx, ctx, ctx);
+ ok = false;
+ break;
+   }
 }
 
   /* We still need to deduce deleted/constexpr/noexcept and maybe return. */
--- gcc/testsuite/g++.dg/cpp2a/spaceship-synth1-neg.C.jj2019-11-11 
08:23:34.040215264 +0100
+++ gcc/testsuite/g++.dg/cpp2a/spaceship-synth1-neg.C   2019-11-11 
08:32:56.206659041 +0100
@@ -0,0 +1,15 @@
+// Test with all operators explicitly defaulted.
+// { dg-do compile { target c++2a } }
+
+#include 
+
+struct D
+{
+  int i;
+  auto operator<=>(D& x) const = default;   // { dg-error 
"defaulted \[^\n\r]* must have parameter type 'const D&'" }
+  bool operator==(int x) const = default;   // { dg-error 
"defaulted \[^\n\r]* must have parameter type 'const D&'" }
+  bool operator!=(const int& x) const = default;// { dg-error 
"defaulted \[^\n\r]* must have parameter type 'const D&'" }
+  friend bool operator<(int& x, D& y) = default;// { dg-error 
"defaulted \[^\n\r]* must have parameter types 'const D&', 'const D&' or 'D', 
'D'" }
+  friend bool operator<=(const D& x, D y) = default;// { dg-error 
"defaulted \[^\n\r]* must have parameter types 'const D&', 'const D&' or 'D', 
'D'" }
+  friend bool operator>(D x, con

[PATCH] Enhance syntax of -fdbg-cnt.

[Martin Liška]

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?
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(-)


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..2a024b1b88d 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,74 @@ print_limit_reach (const char *counter, int limit, bool upper_p)
 bool
 dbg_cnt (enum debug_counter index)
 {
-  count[index]++;
+  unsigned v = ++count[index];
 
-  /* 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);
+  if (limits[index] == NULL)
+return true;
+  else if (limits[index]->is_empty ())
+return false;
 
-  return dbg_cnt_is_enabled (index);
-}
+  /* Reverse intervals exactly once.  */
+  if (v == 1)
+limits[index]->reverse ();
 
-static void
-dbg_cnt_set_limit_by_index (enum debug_counter index, int low, int high)
-{
-  limit_low[index] = low;
-  limit_high[index] = high;
+  unsigned last = limits[index]->length () - 1;
+  unsigned int min = (*limits[index])[last].first;
+  unsigned int max = (*limits[index])[last].second;
 
-  fprintf (stderr, "dbg_cnt '%s' set to %d-%d\n", map[index].name, low, high);
+  if (v < min)
+return false;
+  else if (v == min)
+{
+  print_limit_reach (map[index].name, v, false);
+  if (min == max)
+	limits[index]->pop ();
+  return true;
+}
+  else if (v < max)
+return true;
+  else if (v == max)
+{
+  print_limit_reach (map[index].name, v, true);
+  limits[index]->pop ();
+  return true;
+}
+  else
+return false;
 }
 
 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 lowe

[PATCH] Sort debug counter names.

[Martin Liška]

Hi.

The small patch is about sorting of debug counter
values.

Ready to be installed?
Thanks,
Martin
>From f9e1387c8e03d73d00d701fa9754af850424215f Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 11 Nov 2019 09:03:24 +0100
Subject: [PATCH] Sort debug counter names.

gcc/ChangeLog:

2019-11-11  Martin Liska  

	* dbgcnt.def (DEBUG_COUNTER): Sort counters
	alphabetically.
---
 gcc/dbgcnt.def | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/gcc/dbgcnt.def b/gcc/dbgcnt.def
index cbd437ea594..5b96a7eaf9d 100644
--- a/gcc/dbgcnt.def
+++ b/gcc/dbgcnt.def
@@ -140,7 +140,8 @@ echo ubound: $ub
 
 */
 
-/* Debug counter definitions.  */
+/* Debug counter definitions.
+   Please keep the list sorted in alphabetic order.  */
 DEBUG_COUNTER (asan_use_after_scope)
 DEBUG_COUNTER (auto_inc_dec)
 DEBUG_COUNTER (ccp)
@@ -153,10 +154,12 @@ DEBUG_COUNTER (dce_ud)
 DEBUG_COUNTER (delete_trivial_dead)
 DEBUG_COUNTER (devirt)
 DEBUG_COUNTER (df_byte_scan)
+DEBUG_COUNTER (dom_unreachable_edges)
 DEBUG_COUNTER (dse)
 DEBUG_COUNTER (dse1)
 DEBUG_COUNTER (dse2)
 DEBUG_COUNTER (gcse2_delete)
+DEBUG_COUNTER (gimple_unroll)
 DEBUG_COUNTER (global_alloc_at_func)
 DEBUG_COUNTER (global_alloc_at_reg)
 DEBUG_COUNTER (graphite_scop)
@@ -170,7 +173,9 @@ DEBUG_COUNTER (if_conversion_tree)
 DEBUG_COUNTER (ipa_sra_params)
 DEBUG_COUNTER (ipa_sra_retvalues)
 DEBUG_COUNTER (ira_move)
+DEBUG_COUNTER (ivopts_loop)
 DEBUG_COUNTER (local_alloc_for_sched)
+DEBUG_COUNTER (match)
 DEBUG_COUNTER (merged_ipa_icf)
 DEBUG_COUNTER (postreload_cse)
 DEBUG_COUNTER (pre)
@@ -188,15 +193,11 @@ DEBUG_COUNTER (sel_sched_insn_cnt)
 DEBUG_COUNTER (sel_sched_region_cnt)
 DEBUG_COUNTER (sms_sched_loop)
 DEBUG_COUNTER (split_for_sched2)
+DEBUG_COUNTER (store_merging)
 DEBUG_COUNTER (store_motion)
 DEBUG_COUNTER (stv_conversion)
 DEBUG_COUNTER (tail_call)
-DEBUG_COUNTER (treepre_insert)
 DEBUG_COUNTER (tree_sra)
+DEBUG_COUNTER (treepre_insert)
 DEBUG_COUNTER (vect_loop)
 DEBUG_COUNTER (vect_slp)
-DEBUG_COUNTER (dom_unreachable_edges)
-DEBUG_COUNTER (match)
-DEBUG_COUNTER (store_merging)
-DEBUG_COUNTER (gimple_unroll)
-DEBUG_COUNTER (ivopts_loop)
-- 
2.24.0

Re: [PATCH] Bump minimum MPFR version to 3.1.0

[Richard Biener]

On November 9, 2019 8:47:52 PM GMT+01:00, 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.

OK. 

Thanks, 
Richard. 

>ChangeLog:
>
>2019-11-09  Janne Blomqvist  
>
>   PR fortran/91828
>   * configure.ac: Bump minimum MPFR to 3.1.0, recommended to 3.1.6+.
>   * configure: Regenerated.
>
>gcc/ChangeLog:
>
>2019-11-09  Janne Blomqvist  
>
>   PR fortran/91828
>   * doc/install.texi: Document that the minimum MPFR version is
>   3.1.0.
>
>gcc/fortran/ChangeLog:
>
>2019-11-09  Janne Blomqvist  
>
>   PR fortran/91828
>   * simplify.c (gfc_simplify_fraction): Remove fallback path for
>   MPFR < 3.1.0.
>---
> configure.ac   |  6 +++---
> gcc/doc/install.texi   |  2 +-
> gcc/fortran/simplify.c | 37 -
> 3 files changed, 4 insertions(+), 41 deletions(-)
>
>diff --git a/configure.ac b/configure.ac
>index b8ce2ad20b9..d63a8bae940 100644
>--- a/configure.ac
>+++ b/configure.ac
>@@ -1601,12 +1601,12 @@ if test -d ${srcdir}/gcc && test "x$have_gmp" =
>xno; then
> AC_MSG_CHECKING([for the correct version of mpfr.h])
> AC_TRY_COMPILE([#include 
> #include ],[
>-#if MPFR_VERSION < MPFR_VERSION_NUM(2,4,0)
>+#if MPFR_VERSION < MPFR_VERSION_NUM(3,1,0)
> choke me
> #endif
> ], [AC_TRY_COMPILE([#include 
> #include ],[
>-#if MPFR_VERSION < MPFR_VERSION_NUM(2,4,2)
>+#if MPFR_VERSION < MPFR_VERSION_NUM(3,1,6)
> choke me
> #endif
>  ], [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([buggy but acceptable])])],
>@@ -1661,7 +1661,7 @@ if test -d ${srcdir}/gcc && test "x$have_gmp" =
>xno; then
> # The library versions listed in the error message below should match
> # the HARD-minimums enforced above.
>   if test x$have_gmp != xyes; then
>-AC_MSG_ERROR([Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC
>0.8.0+.
>+AC_MSG_ERROR([Building GCC requires GMP 4.2+, MPFR 3.1.0+ and MPC
>0.8.0+.
> Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify
> their locations.  Source code for these libraries can be found at
> their respective hosting sites as well as at
>diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
>index 2cb8a342a2c..93b01ff7971 100644
>--- a/gcc/doc/install.texi
>+++ b/gcc/doc/install.texi
>@@ -384,7 +384,7 @@ and @option{--with-gmp-include}.
> The in-tree build is only supported with the GMP version that
> download_prerequisites installs.
> 
>-@item MPFR Library version 2.4.2 (or later)
>+@item MPFR Library version 3.1.0 (or later)
> 
> Necessary to build GCC@.  It can be downloaded from
> @uref{https://www.mpfr.org}.  If an MPFR source distribution is found
>diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
>index 2eb1943c3ee..0461d31cd88 100644
>--- a/gcc/fortran/simplify.c
>+++ b/gcc/fortran/simplify.c
>@@ -3076,12 +3076,7 @@ gfc_expr *
> gfc_simplify_fraction (gfc_expr *x)
> {
>   gfc_expr *result;
>-
>-#if MPFR_VERSION < MPFR_VERSION_NUM(3,1,0)
>-  mpfr_t absv, exp, pow2;
>-#else
>   mpfr_exp_t e;
>-#endif
> 
>   if (x->expr_type != EXPR_CONSTANT)
> return NULL;
>@@ -3095,41 +3090,9 @@ gfc_simplify_fraction (gfc_expr *x)
>   return result;
> }
> 
>-#if MPFR_VERSION < MPFR_VERSION_NUM(3,1,0)
>-
>-  /* MPFR versions before 3.1.0 do not include mpfr_frexp.
>- TODO: remove the kludge when MPFR 3.1.0 or newer will be required
>*/
>-
>-  if (mpfr_sgn (x->value.real) == 0)
>-{
>-  mpfr_set (result->value.real, x->value.real, GFC_RND_MODE);
>-  return result;
>-}
>-
>-  gfc_set_model_kind (x->ts.kind);
>-  mpfr_init (exp);
>-  mpfr_init (absv);
>-  mpfr_init (pow2);
>-
>-  mpfr_abs (absv, x->value.real, GFC_RND_MODE);
>-  mpfr_log2 (exp, absv, GFC_RND_MODE);
>-
>-  mpfr_trunc (exp, exp);
>-  mpfr_add_ui (exp, exp, 1, GFC_RND_MODE);
>-
>-  mpfr_ui_pow (pow2, 2, exp, GFC_RND_MODE);
>-
>-  mpfr_div (result->value.real, x->value.real, pow2, GFC_RND_MODE);
>-
>-  mpfr_clears (exp, absv, pow2, NULL);
>-
>-#else
>-
>   /* mpfr_frexp() correctly handles zeros and NaNs.  */
>   mpfr_frexp (&e, result->value.real, x->value.real, GFC_RND_MODE);
> 
>-#endif
>-
>   return range_check (result, "FRACTION");
> }
> 

Re: [build] Properly track GCC language configure fragments

[Thomas Schwinge]

Hi!

On 2019-10-25T20:48:58+, Joseph Myers  wrote:
> This patch is OK.

Thanks.  See attached; as posted, committed to trunk in r278035,
gcc-9-branch in r278036, gcc-8-branch in r278037, gcc-7-branch omitted as
that one's frozen for the final release, and this fix isn't important
enough.


Grüße
 Thomas


From 5ba7804033a285907cfda88c9de5acc103c9881a Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Mon, 11 Nov 2019 08:05:27 +
Subject: [PATCH] [build] Properly track GCC language configure fragments

The 'gcc/configure' script sources all 'gcc/*/config-lang.in' files, but fails
to emit such dependency information into the build machinery.  That means,
currently, when something gets changed in a 'gcc/*/config-lang.in' file, this
is not noticed, and doesn't propagate through the build machinery.

Handling of configure fragments is modelled in the same way as it already
exists for Makefile fragments.

	gcc/
	* Makefile.in (LANG_CONFIGUREFRAGS): Define.
	(config.status): Use/depend on it.
	* configure.ac (all_lang_configurefrags): Track, 'AC_SUBST'.
	* configure: Regenerate.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@278035 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog|  7 +++
 gcc/Makefile.in  |  3 ++-
 gcc/configure| 10 +++---
 gcc/configure.ac |  5 -
 4 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 96efa4224bd7..a1e928bf804d 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2019-11-11  Thomas Schwinge  
+
+	* Makefile.in (LANG_CONFIGUREFRAGS): Define.
+	(config.status): Use/depend on it.
+	* configure.ac (all_lang_configurefrags): Track, 'AC_SUBST'.
+	* configure: Regenerate.
+
 2019-11-11  Jiufu Guo  
 
 	PR tree-optimization/88760
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 95f054c4d4f3..ac21401af391 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1122,6 +1122,7 @@ endif
 # Support for additional languages (other than C).
 # C can be supported this way too (leave for later).
 
+LANG_CONFIGUREFRAGS  = @all_lang_configurefrags@
 LANG_MAKEFRAGS = @all_lang_makefrags@
 
 # Used by gcc/jit/Make-lang.in
@@ -1910,7 +1911,7 @@ cstamp-h: config.in config.status
 # Really, really stupid make features, such as SUN's KEEP_STATE, may force
 # a target to build even if it is up-to-date.  So we must verify that
 # config.status does not exist before failing.
-config.status: $(srcdir)/configure $(srcdir)/config.gcc
+config.status: $(srcdir)/configure $(srcdir)/config.gcc $(LANG_CONFIGUREFRAGS)
 	@if [ ! -f config.status ] ; then \
 	  echo You must configure gcc.  Look at http://gcc.gnu.org/install/ for details.; \
 	  false; \
diff --git a/gcc/configure b/gcc/configure
index a2df82e021f5..be58e1a4d5f5 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -701,6 +701,7 @@ build_exeext
 all_selected_languages
 all_languages
 all_lang_makefrags
+all_lang_configurefrags
 all_gtfiles
 all_compilers
 srcdir
@@ -18937,7 +18938,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 18940 "configure"
+#line 18941 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -19043,7 +19044,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19046 "configure"
+#line 19047 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -29928,7 +29929,8 @@ lang_tree_files=
 all_languages=
 all_compilers=
 all_outputs='Makefile'
-# List of language makefile fragments.
+# List of language configure and makefile fragments.
+all_lang_configurefrags=
 all_lang_makefrags=
 # Additional files for gengtype
 all_gtfiles="$target_gtfiles"
@@ -30014,6 +30016,7 @@ do
 	esac
 	$ok || continue
 
+	all_lang_configurefrags="$all_lang_configurefrags \$(srcdir)/$gcc_subdir/config-lang.in"
 	all_lang_makefrags="$all_lang_makefrags \$(srcdir)/$gcc_subdir/Make-lang.in"
 	if test -f $srcdir/$gcc_subdir/lang.opt; then
 	lang_opt_files="$lang_opt_files $srcdir/$gcc_subdir/lang.opt"
@@ -30165,6 +30168,7 @@ fi
 
 
 
+
 
 
 
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 5f32fd4d5e4d..6bce1e3b6d9f 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -6333,7 +6333,8 @@ lang_tree_files=
 all_languages=
 all_compilers=
 all_outputs='Makefile'
-# List of language makefile fragments.
+# List of language configure and makefile fragments.
+all_lang_configurefrags=
 all_lang_makefrags=
 # Additional files for gengtype
 all_gtfiles="$target_gtfiles"
@@ -6421,6 +6422,7 @@ changequote([,])dnl
 	esac
 	$ok || continue
 
+	all_lang_configurefrags="$all_lang_configurefrags \$(srcdir)/$gcc_subdir/config-lang.in"
 	all_lang_makefrags="$all_lang_makefrags \$(srcdir)/$gcc_subdir/Make-lang.in"
 	if test -f $srcdir/$gcc_subdir/lang.opt; then
 	lang_opt_files="$lang_opt_files $srcdir/$gcc_subdir/lang.opt"
@@ -6528,6 +6530,7 @@ AC_SUBST(subdirs)
 AC_SUBST(srcdir)
 AC_SUBST(all_compilers)
 A

Re: [gomp4.1] Start of structure element mapping support

[Thomas Schwinge]

Hi!

On 2019-10-16T18:52:55+0200, Jakub Jelinek  wrote:
> On Wed, Oct 16, 2019 at 03:22:52PM +0200, Thomas Schwinge wrote:
>> Stumbled over this while reviewing Julian's "Factor out duplicate code in
>> gimplify_scan_omp_clauses":
>
>> ..., which here gets writte to...
>> 
>> > +  if (base != decl)
>> > +break;
>> > +  gcc_assert (offset == NULL_TREE
>> > +  || TREE_CODE (offset) == INTEGER_CST);
>> 
>> ..., but here we again check 'offset', not 'offset2'...
>
> Yes, it indeed [...]

Thanks.  See attached; committed "Assert 'offset2' instead of 'offset' in
'gcc/gimplify.c:gimplify_scan_omp_clauses'" to trunk in r278038,
gcc-9-branch in r278039, gcc-8-branch in r278040, gcc-7-branch (slightly
different patch) omitted as that one's frozen for the final release, and
this fix isn't important enough.


Grüße
 Thomas


From c88bb56e02340083d10a728c2ca05748df5c6218 Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Mon, 11 Nov 2019 08:18:46 +
Subject: [PATCH] Assert 'offset2' instead of 'offset' in
 'gcc/gimplify.c:gimplify_scan_omp_clauses'

... to fix a long-time typo/copy'n'past-o.

	gcc/
	* gimplify.c (gimplify_scan_omp_clauses): Assert 'offset2' instead
	of 'offset'.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@278038 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog  | 3 +++
 gcc/gimplify.c | 4 ++--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index a1e928bf804d..ca0cebc20180 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,8 @@
 2019-11-11  Thomas Schwinge  
 
+	* gimplify.c (gimplify_scan_omp_clauses): Assert 'offset2' instead
+	of 'offset'.
+
 	* Makefile.in (LANG_CONFIGUREFRAGS): Define.
 	(config.status): Use/depend on it.
 	* configure.ac (all_lang_configurefrags): Track, 'AC_SUBST'.
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 5fa0ba6dda60..2bc41cf98ae9 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -8890,8 +8890,8 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq *pre_p,
 			  break;
 			if (scp)
 			  continue;
-			gcc_assert (offset == NULL_TREE
-	|| poly_int_tree_p (offset));
+			gcc_assert (offset2 == NULL_TREE
+	|| poly_int_tree_p (offset2));
 			tree d1 = OMP_CLAUSE_DECL (*sc);
 			tree d2 = OMP_CLAUSE_DECL (c);
 			while (TREE_CODE (d1) == ARRAY_REF)
-- 
2.17.1

From a3174355911ea11b2e1f2786a7bffe2c5489e128 Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Mon, 11 Nov 2019 08:19:23 +
Subject: [PATCH] Assert 'offset2' instead of 'offset' in
 'gcc/gimplify.c:gimplify_scan_omp_clauses'

... to fix a long-time typo/copy'n'past-o.

	gcc/
	* gimplify.c (gimplify_scan_omp_clauses): Assert 'offset2' instead
	of 'offset'.

Backport from trunk r278038.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-9-branch@278039 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog  | 4 
 gcc/gimplify.c | 4 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 52d867db50a1..fc19dae278d4 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,9 @@
 2019-11-11  Thomas Schwinge  
 
+	Backport from trunk:
+	* gimplify.c (gimplify_scan_omp_clauses): Assert 'offset2' instead
+	of 'offset'.
+
 	Backport from trunk:
 	* Makefile.in (LANG_CONFIGUREFRAGS): Define.
 	(config.status): Use/depend on it.
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 28e13a710215..a0cb6c402bcf 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -8718,8 +8718,8 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq *pre_p,
 			  break;
 			if (scp)
 			  continue;
-			gcc_assert (offset == NULL_TREE
-	|| poly_int_tree_p (offset));
+			gcc_assert (offset2 == NULL_TREE
+	|| poly_int_tree_p (offset2));
 			tree d1 = OMP_CLAUSE_DECL (*sc);
 			tree d2 = OMP_CLAUSE_DECL (c);
 			while (TREE_CODE (d1) == ARRAY_REF)
-- 
2.17.1

From 2c1fdb6ef7fc5fbde790143c9c58b0f10241f9d8 Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Mon, 11 Nov 2019 08:19:41 +
Subject: [PATCH] Assert 'offset2' instead of 'offset' in
 'gcc/gimplify.c:gimplify_scan_omp_clauses'

... to fix a long-time typo/copy'n'past-o.

	gcc/
	* gimplify.c (gimplify_scan_omp_clauses): Assert 'offset2' instead
	of 'offset'.

Backport from trunk r278038.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-8-branch@278040 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog  | 4 
 gcc/gimplify.c | 4 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 80bf2e121c63..29441ada5dd3 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,9 @@
 2019-11-11  Thomas Schwinge  
 
+	Backport from trunk:
+	* gimplify.c (gimplify_scan_omp_clauses): Assert 'offset2' instead
+	of 'offset'.
+
 	Backport from trunk:
 	* Makefile.in (LANG_CONFIGUREFRAGS): Define.
 	(config.status): Use/depend on it.
diff --git a/gcc/gimplify.

[8/9/10 Regression] [PR87833] Intel MIC (emulated) offloading still broken

[Thomas Schwinge]

Hi!

On 2019-05-29T09:50:42-0600, Jeff Law  wrote:
> On 5/29/19 8:32 AM, Thomas Schwinge wrote:
>> On Thu, 9 May 2019 15:46:06 +0300, Ilya Verbin  wrote:
>>> I have left Intel 3 years ago. If you have any questions regarding MIC
>>> offloading, you can reach me by iver...@gmail.com
>> 
>> We're (a) looking for somebody to step up as a maintainer for that, and

That's still unresolved.

At the 2019 GNU Tools Cauldron, we discussed this topic in the OMP BoF,
and decided that despite its unmaintained status, we shall try to keep
GCC's Intel MIC (emulated) offloading support functional (at least until
any more complicated problems arise), because it might be useful for
Jakub once a year or so, for testing OMP changes.


>> (b) that person to get active, and take ownership of
>> , and review the proposed patch,
>> .
> My question would be where in the world is the -fno-pie stuff coming
> from.  It's also not clear where mkoffload is being called within c#5
> (presumably via the linker plugin) AFAICT we don't get the command line
> for that.  -v  or -Wl,-v probably would have helped.  It's difficult to
> know if HJ's patch is correct or not given the missing bits of information.
>
> But I'm willing to trust HJ here.  I'll ack the patch for the trunk.
> You or HJ can go ahead and install it.

I too have not made an attempt to really understand this problem and
solution.  See attached; as posted by H.J.,
,
I have now committed "[PR87833] x86: Put -fPIC and -shared the last to
create offload image" to trunk in r278041, gcc-9-branch in r278042,
gcc-8-branch in r278043.


> THe bigger question about the viability/usability of MIC is punted ;-)


Grüße
 Thomas


From 73e2538765507c373e1d7c14363094a2f6cf645a Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Mon, 11 Nov 2019 08:38:28 +
Subject: [PATCH] [PR87833] x86: Put -fPIC and -shared the last to create
 offload image

On x86, since -fPIC and -shared should be used to create offload image,
we put them the last to properly create offload image.

2019-11-11  H.J. Lu  

	PR target/87833
	* config/i386/intelmic-mkoffload.c (prepare_target_image): Put
	-fPIC and -shared the last to create offload image.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@278041 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog| 6 ++
 gcc/config/i386/intelmic-mkoffload.c | 5 +++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index ca0cebc20180..1b0145fbc787 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2019-11-11  H.J. Lu  
+
+	PR target/87833
+	* config/i386/intelmic-mkoffload.c (prepare_target_image): Put
+	-fPIC and -shared the last to create offload image.
+
 2019-11-11  Thomas Schwinge  
 
 	* gimplify.c (gimplify_scan_omp_clauses): Assert 'offset2' instead
diff --git a/gcc/config/i386/intelmic-mkoffload.c b/gcc/config/i386/intelmic-mkoffload.c
index 2a3e912ee74f..0b12edc72c14 100644
--- a/gcc/config/i386/intelmic-mkoffload.c
+++ b/gcc/config/i386/intelmic-mkoffload.c
@@ -453,8 +453,6 @@ prepare_target_image (const char *target_compiler, int argc, char **argv)
   if (verbose)
 obstack_ptr_grow (&argv_obstack, "-v");
   obstack_ptr_grow (&argv_obstack, "-xlto");
-  obstack_ptr_grow (&argv_obstack, "-shared");
-  obstack_ptr_grow (&argv_obstack, "-fPIC");
   obstack_ptr_grow (&argv_obstack, opt1);
   for (int i = 1; i < argc; i++)
 {
@@ -466,6 +464,9 @@ prepare_target_image (const char *target_compiler, int argc, char **argv)
   if (!out_obj_filename)
 fatal_error (input_location, "output file not specified");
   obstack_ptr_grow (&argv_obstack, opt2);
+  /* NB: Put -fPIC and -shared the last to create shared library.  */
+  obstack_ptr_grow (&argv_obstack, "-fPIC");
+  obstack_ptr_grow (&argv_obstack, "-shared");
   obstack_ptr_grow (&argv_obstack, "-o");
   obstack_ptr_grow (&argv_obstack, target_so_filename);
   compile_for_target (&argv_obstack);
-- 
2.17.1

From 22bf0cb640189880b683180d50b1e5b4b93e1fd9 Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Mon, 11 Nov 2019 08:39:10 +
Subject: [PATCH] [PR87833] x86: Put -fPIC and -shared the last to create
 offload image

On x86, since -fPIC and -shared should be used to create offload image,
we put them the last to properly create offload image.

2019-11-11  H.J. Lu  

	PR target/87833
	* config/i386/intelmic-mkoffload.c (prepare_target_image): Put
	-fPIC and -shared the last to create offload image.

Backport from trunk r278041.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-9-branch@278042 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog| 7 +++
 gcc/config/i386/intelmic-mkoffload.c | 5 +++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index fc19dae278d4..8552

Re: [Patch][OpenMP] use_device_addr/use_device_ptr with Fortran allocatable/pointer arrays (= array descriptor)

[Thomas Schwinge]

Hi!

On 2019-10-31T18:09:28+0100, Tobias Burnus  wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/use_device_addr-3.f90

> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/use_device_addr-4.f90

> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/use_device_ptr-1.f90

As obvious; see attached, committed "Torture testing:
'libgomp.fortran/use_device_addr-3.f90',
'libgomp.fortran/use_device_addr-4.f90',
'libgomp.fortran/use_device_ptr-1.f90'" to trunk in r278044.


Grüße
 Thomas


From d7a5b0d74344a5012fb46a1ccb5b1b94b8110c50 Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Mon, 11 Nov 2019 08:50:29 +
Subject: [PATCH] Torture testing: 'libgomp.fortran/use_device_addr-3.f90',
 'libgomp.fortran/use_device_addr-4.f90',
 'libgomp.fortran/use_device_ptr-1.f90'

	libgomp/
	* testsuite/libgomp.fortran/use_device_addr-3.f90: Specify 'dg-do
	run'.
	* testsuite/libgomp.fortran/use_device_addr-4.f90: Likewise.
	* testsuite/libgomp.fortran/use_device_ptr-1.f90: Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@278044 138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgomp/ChangeLog   | 7 +++
 libgomp/testsuite/libgomp.fortran/use_device_addr-3.f90 | 2 ++
 libgomp/testsuite/libgomp.fortran/use_device_addr-4.f90 | 2 ++
 libgomp/testsuite/libgomp.fortran/use_device_ptr-1.f90  | 2 ++
 4 files changed, 13 insertions(+)

diff --git a/libgomp/ChangeLog b/libgomp/ChangeLog
index 067d247da9ac..0e73cadb6cd0 100644
--- a/libgomp/ChangeLog
+++ b/libgomp/ChangeLog
@@ -1,3 +1,10 @@
+2019-11-11  Thomas Schwinge  
+
+	* testsuite/libgomp.fortran/use_device_addr-3.f90: Specify 'dg-do
+	run'.
+	* testsuite/libgomp.fortran/use_device_addr-4.f90: Likewise.
+	* testsuite/libgomp.fortran/use_device_ptr-1.f90: Likewise.
+
 2019-11-06  Thomas Schwinge  
 
 	* testsuite/libgomp.oacc-c-c++-common/par-loop-comb-reduction-1.c:
diff --git a/libgomp/testsuite/libgomp.fortran/use_device_addr-3.f90 b/libgomp/testsuite/libgomp.fortran/use_device_addr-3.f90
index 6d794d74cb3e..5c42bee718ce 100644
--- a/libgomp/testsuite/libgomp.fortran/use_device_addr-3.f90
+++ b/libgomp/testsuite/libgomp.fortran/use_device_addr-3.f90
@@ -1,3 +1,5 @@
+! { dg-do run }
+
 ! Comprehensive run-time test for use_device_addr
 !
 ! Tests array with array descriptor
diff --git a/libgomp/testsuite/libgomp.fortran/use_device_addr-4.f90 b/libgomp/testsuite/libgomp.fortran/use_device_addr-4.f90
index 32dc92c2ff4b..5e66a79da90b 100644
--- a/libgomp/testsuite/libgomp.fortran/use_device_addr-4.f90
+++ b/libgomp/testsuite/libgomp.fortran/use_device_addr-4.f90
@@ -1,3 +1,5 @@
+! { dg-do run }
+
 ! Comprehensive run-time test for use_device_addr
 !
 ! Tests array with array descriptor
diff --git a/libgomp/testsuite/libgomp.fortran/use_device_ptr-1.f90 b/libgomp/testsuite/libgomp.fortran/use_device_ptr-1.f90
index 6428beb357c8..e5390e27a512 100644
--- a/libgomp/testsuite/libgomp.fortran/use_device_ptr-1.f90
+++ b/libgomp/testsuite/libgomp.fortran/use_device_ptr-1.f90
@@ -1,3 +1,5 @@
+! { dg-do run }
+
 module target_procs
   use iso_c_binding
   implicit none (type, external)
-- 
2.17.1



signature.asc
Description: PGP signature

Re: [Patch][Fortran/OpenMP] Don't create "alloc:" for 'target exit data'

[Thomas Schwinge]

Hi!

On 2019-10-30T16:48:43+0100, Tobias Burnus  wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/target9.f90

As obvious; see attached, committed "Torture testing:
'libgomp.fortran/target9.f90'" to trunk in r278045.


Grüße
 Thomas


From d462cbc6c489949752b4d652abec30dbb95c2855 Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Mon, 11 Nov 2019 08:50:40 +
Subject: [PATCH] Torture testing: 'libgomp.fortran/target9.f90'

	libgomp/
	* testsuite/libgomp.fortran/target9.f90: Specify 'dg-do run'.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@278045 138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgomp/ChangeLog | 2 ++
 libgomp/testsuite/libgomp.fortran/target9.f90 | 1 +
 2 files changed, 3 insertions(+)

diff --git a/libgomp/ChangeLog b/libgomp/ChangeLog
index 0e73cadb6cd0..1fc8c471b6f8 100644
--- a/libgomp/ChangeLog
+++ b/libgomp/ChangeLog
@@ -1,5 +1,7 @@
 2019-11-11  Thomas Schwinge  
 
+	* testsuite/libgomp.fortran/target9.f90: Specify 'dg-do run'.
+
 	* testsuite/libgomp.fortran/use_device_addr-3.f90: Specify 'dg-do
 	run'.
 	* testsuite/libgomp.fortran/use_device_addr-4.f90: Likewise.
diff --git a/libgomp/testsuite/libgomp.fortran/target9.f90 b/libgomp/testsuite/libgomp.fortran/target9.f90
index 91d60a33307e..30adc1bd70af 100644
--- a/libgomp/testsuite/libgomp.fortran/target9.f90
+++ b/libgomp/testsuite/libgomp.fortran/target9.f90
@@ -1,3 +1,4 @@
+! { dg-do run }
 ! { dg-require-effective-target offload_device_nonshared_as } */
 
 module target_test
-- 
2.17.1



signature.asc
Description: PGP signature

Re: [PATCH][arm][1/X] Add initial support for saturation intrinsics

[Kyrill Tkachov]

Hi Richard,

On 11/9/19 12:44 PM, Richard Henderson wrote:

On 11/7/19 11:26 AM, Kyrill Tkachov wrote:

-;; The code sequence emitted by this insn pattern uses the Q flag, which GCC
-;; doesn't generally know about, so we don't bother expanding to individual
-;; instructions.  It may be better to just use an out-of-line asm libcall for
-;; this.
+;; The code sequence emitted by this insn pattern uses the Q flag, so we need
+;; to bail out when ARM_Q_BIT_READ and resort to a library sequence instead.
+
+(define_expand "ssmulsa3"
+  [(parallel [(set (match_operand:SA 0 "s_register_operand")
+   (ss_mult:SA (match_operand:SA 1 "s_register_operand")
+   (match_operand:SA 2 "s_register_operand")))
+   (clobber (match_scratch:DI 3))
+   (clobber (match_scratch:SI 4))
+   (clobber (reg:CC CC_REGNUM))])]
+  "TARGET_32BIT && arm_arch6"
+  {
+if (ARM_Q_BIT_READ)
+  FAIL;
+  }
+)

Coming back to this, why would you not just represent the update of the Q bit?
  This is not generated by generic pattern matching, but by the __ssmulsa3
builtin function.  It seems easy to me to simply describe how this older
builtin operates in conjunction with the new acle builtins.

I recognize that ssadd3 etc are more difficult, because they can be
generated by arithmetic operations on TYPE_SATURATING.  Although again it seems
weird to generate expensive out-of-line code for TYPE_SATURATING when used in
conjunction with acle builtins.

I think it would be better to merely expand the documentation.  Even if only so
far as to say "unsupported to mix these".


I'm tempted to agree, as this part of the patch is quite ugly.

Thank you for the comments on these patches, I wasn't aware of some of 
the mechanisms.


I guess I should have posted the series as an RFC first...

I'll send patches to fix up the issues.

Thanks,

Kyrill


+(define_expand "maddhisi4"
+  [(set (match_operand:SI 0 "s_register_operand")
+   (plus:SI (mult:SI (sign_extend:SI
+  (match_operand:HI 1 "s_register_operand"))
+ (sign_extend:SI
+  (match_operand:HI 2 "s_register_operand")))
+(match_operand:SI 3 "s_register_operand")))]
+  "TARGET_DSP_MULTIPLY"
+  {
+/* If this function reads the Q bit from ACLE intrinsics break up the
+   multiplication and accumulation as an overflow during accumulation will
+   clobber the Q flag.  */
+if (ARM_Q_BIT_READ)
+  {
+   rtx tmp = gen_reg_rtx (SImode);
+   emit_insn (gen_mulhisi3 (tmp, operands[1], operands[2]));
+   emit_insn (gen_addsi3 (operands[0], tmp, operands[3]));
+   DONE;
+  }
+  }
+)
+
+(define_insn "*arm_maddhisi4"
[(set (match_operand:SI 0 "s_register_operand" "=r")
(plus:SI (mult:SI (sign_extend:SI
   (match_operand:HI 1 "s_register_operand" "r"))
  (sign_extend:SI
   (match_operand:HI 2 "s_register_operand" "r")))
 (match_operand:SI 3 "s_register_operand" "r")))]
-  "TARGET_DSP_MULTIPLY"
+  "TARGET_DSP_MULTIPLY && !ARM_Q_BIT_READ"
"smlabb%?\\t%0, %1, %2, %3"
[(set_attr "type" "smlaxy")
 (set_attr "predicable" "yes")]

I think this case would be better represented with a single
define_insn_and_split and a peephole2.  It is easy to notice during peep2
whether or not the Q bit is actually live at the exact place we want to expand
this operation.  If it is live, then use two insns; if it isn't, use one.


r~

Re: [Patch][Fortran] OpenACC – permit common blocks in some clauses

[Thomas Schwinge]

Hi Tobias!

By the way, do you know what's the status is for Fortran common blocks in
OpenMP: supported vs. expected per the specification?


On 2019-10-25T16:36:10+0200, Tobias Burnus  wrote:
> On 10/25/19 10:43 AM, Thomas Schwinge wrote:
>> Or, would it be easy to add an OpenACC 'kernels' test case that otherwise
>> faild (at run time, say, with aforementioned duplicate mapping errors, or
>> would contain "strange"/duplicate/conflicting mapping items in the
>> '-fdump-tree-gimple' dump)?

> * I have now a new test case 
> libgomp/testsuite/libgomp.oacc-fortran/common-block-3.f90 which looks at 
> omplower.

Thanks.

Curious: why 'omplower' instead of 'gimple' dump?


> Regarding the new test case: Without the gcc/gimplify.c changes, one has 
> (see last item before child fn):
>
>      #pragma omp target oacc_parallel map(tofrom:a [len: 400]) 
> map(tofrom:b [len: 400]) map(tofrom:c [len: 4]) map(tofrom:block [len: 
> 812]) [child fn …
>      #pragma omp target oacc_kernels map(force_tofrom:i [len: 4]) 
> map(tofrom:y [len: 400]) map(tofrom:x [len: 400]) 
> map(tofrom:kernel_block [len: 804]) map(force_tofrom:c [len: 4]) 
> map(tofrom:block [len: 812])  [child fn …
>
> With the changes of gcc/gimplify.c, one has:
>
>      #pragma omp target oacc_parallel map(tofrom:a [len: 400]) 
> map(tofrom:b [len: 400]) map(tofrom:c [len: 4]) [child fn …
>      #pragma omp target oacc_kernels map(force_tofrom:i [len: 4]) 
> map(tofrom:y [len: 400]) map(tofrom:x [len: 400]) map(force_tofrom:c 
> [len: 4])  [child fn …
>
>
> And without gimplify.c, the added run-tests indeed fail with:
> libgomp: Trying to map into device [0x407100..0x407294) object when 
> [0x407100..0x407290) is already mapped

OK, good, my suspicion was thus right that there's something "strange"
there.  ;-)

> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/goacc/common-block-3.f90
> @@ -0,0 +1,39 @@
> +! { dg-options "-fopenacc -fdump-tree-omplower" }

(For later: we usually just use 'dg-additional-options
"-fdump-tree-omplower"'; '-fopenacc' is implied inside '*/goacc/'.)

> +
> +module consts
> +  integer, parameter :: n = 100
> +end module consts
> +
> +program main
> +  use consts
> +  implicit none
> +
> +  integer :: i, j
> +  real ::  a(n) = 0, b(n) = 0, c, d
> +  real ::  x(n) = 0, y(n), z
> +  common /BLOCK/ a, b, c, j, d
> +  common /KERNELS_BLOCK/ x, y, z
> +
> +  c = 1.0
> +  !$acc parallel loop copy(/BLOCK/)
> +  do i = 1, n
> + a(i) = b(i) + c
> +  end do
> +  !$acc kernels
> +  do i = 1, n
> + x(i) = y(i) + c
> +  end do
> +  !$acc end kernels
> +end program main
> +
> +! { dg-final { scan-tree-dump-times "omp target oacc_parallel 
> .*map\\(tofrom:a \\\[len: 400\\\]\\)" 1 "omplower" } }
> +! { dg-final { scan-tree-dump-times "omp target oacc_parallel 
> .*map\\(tofrom:b \\\[len: 400\\\]\\\)" 1 "omplower" } }
> +! { dg-final { scan-tree-dump-times "omp target oacc_parallel 
> .*map\\(tofrom:c \\\[len: 4\\\]\\)" 1 "omplower" } }
> +
> +! { dg-final { scan-tree-dump-times "omp target oacc_kernels 
> .*map\\(force_tofrom:i \\\[len: 4\\\]\\)" 1 "omplower" } }
> +! { dg-final { scan-tree-dump-times "omp target oacc_kernels 
> .*map\\(tofrom:x \\\[len: 400\\\]\\)" 1 "omplower" } }
> +! { dg-final { scan-tree-dump-times "omp target oacc_kernels 
> .*map\\(tofrom:y \\\[len: 400\\\]\\\)" 1 "omplower" } }
> +! { dg-final { scan-tree-dump-times "omp target oacc_kernels 
> .*map\\(force_tofrom:c \\\[len: 4\\\]\\)" 1 "omplower" } }
> +
> +! { dg-final { scan-tree-dump-not "map\\(.*:block\\)" "omplower" } }
> +! { dg-final { scan-tree-dump-not "map\\(.*:kernels_block\\)" "omplower" } }

For my understanding: the several unused variables in the common blocks
are to make sure that they don't cause any issues, don't get mapped at
all?

I we were to add to 'gfortran.dg/goacc/common-block-3.f90' a test case
for the upcoming OpenACC 'serial' construct (which basically equals the
OpenACC 'parallel' construct), would we copy/adapt the 'parallel' 'BLOCK'
test case, or add a new, separate common block?

Or, asking the other way round: why aren't in the current test case,
'parallel' and 'kernels' using the same common block, and both explicitly
'copy' the common block vs. not do that?


> * In the compile-time *{2,3} test case, there is now also a 'enter data' 
> and 'update host/self/device' test.

;-) Heh, 'update' got inside the 'parallel' region:

> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/goacc/common-block-1.f90
> @@ -0,0 +1,74 @@
> +[...]
> +  !$acc parallel firstprivate(/blockA/, /blockB/, e, v)
> +  !$acc update device(/blockA/)
> +  !$acc update self(/blockB/, v)
> +  !$acc update host(/blockA/, e, /blockB/)
> +  !$acc end parallel
> +[...]

> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/goacc/common-block-2.f90

Likewise.

As obvoius; see attached, committed "Fix OpenACC directives nesting in
'gfortran.dg/goacc/common-block-1.f90',
'gfortran.dg/goacc/common-block-2.f90'" to trunk in r278047.


Grüße
 Thomas


From 068b41bc6db50d6f

Re: [8/n] Replace autovectorize_vector_sizes with autovectorize_vector_modes

[Richard Sandiford]

Ping

Richard Sandiford  writes:
> 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.
>
> 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

2019-10-24  Richard Sandiford  

gcc/
* target.h (vector_sizes, auto_vector_sizes): Delete.
(vector_modes, auto_vector_modes): New typedefs.
* target.def (autovectorize_vector_sizes): Replace with...
(autovectorize_vector_modes): ...this new hook.
* doc/tm.texi.in (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES):
Replace with...
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): ...this new hook.
* doc/tm.texi: Regenerate.
* targhooks.h (default_autovectorize_vector_sizes): Delete.
(default_autovectorize_vector_modes): New function.
* targhooks.c (default_autovectorize_vector_sizes): Delete.
(default_autovectorize_vector_modes): New function.
* omp-general.c (omp_max_vf): Use autovectorize_vector_modes instead
of autovectorize_vector_sizes.  Use the number of units in the mode
to calculate the maximum VF.
* omp-low.c (omp_clause_aligned_alignment): Use
autovectorize_vector_modes instead of autovectorize_vector_sizes.
Use a loop based on related_mode to iterate through all supported
vector modes for a given scalar mode.
* optabs-query.c (can_vec_mask_load_store_p): Use
autovectorize_vector_modes instead of autovectorize_vector_sizes.
* tree-vect-loop.c (vect_analyze_loop, vect_transform_loop): Likewise.
* tree-vect-slp.c (vect_slp_bb_region): Likewise.
* config/aarch64/aarch64.c (aarch64_autovectorize_vector_sizes):
Replace with...
(aarch64_autovectorize_vector_modes): ...this new function.
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Delete.
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): Define.
* config/arc/arc.c (arc_autovectorize_vector_sizes): Replace with...
(arc_autovectorize_vector_modes): ...this new function.
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Delete.
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): Define.
* config/arm/arm.c (arm_autovectorize_vector_sizes): Replace with...
(arm_autovectorize_vector_modes): ...this new function.
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Delete.
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES): Define.
* config/i386/i386.c (ix86_autovectorize_vector_sizes): Replace with...
(ix86_autovectorize_vector_modes): ...this new function.
(TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Delete.
(TARGET_VECTORIZE_AUTOVECTORIZE

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

[Tobias Burnus]

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

 gcc/testsuite/ChangeLog  |8 +++
 gcc/testsuite/gfortran.dg/ISO_Fortran_binding_10.c   |4 -
 gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.c   |   40 +++
 gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.f90 |   25 +++
 libgfortran/ChangeLog|7 +++
 libgfortran/runtime/ISO_Fortran_binding.c|   22 +++---
 6 files changed, 97 insertions(+), 9 deletions(-)
Index: gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.c
===
--- gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.c	(nonexistent)
+++ gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.c	(revision 278048)
@@ -0,0 +1,40 @@
+/* Test the fix for PR92142. */
+
+#include "../../../libgfortran/ISO_Fortran_binding.h"
+
+#include 
+
+int c_setpointer(CFI_cdesc_t *);
+
+int c_setpointer(CFI_cdesc_t *ip)
+{
+  CFI_cdesc_t *yp = NULL;
+  void *auxp = ip->base_addr;
+  int ierr;
+  int status;
+
+  /* Setting up the pointer */
+  ierr = 1;
+  yp = malloc(sizeof(*ip));
+  if (yp == NULL) return ierr;
+  status = CFI_establish(yp, NULL, CFI_attribute_pointer, ip->type, ip->elem_len, ip->rank, NULL);
+  if (status != CFI_SUCCESS) return ierr;
+  if (yp->attribute != CFI_attribute_pointer) return ierr;
+  /* Set the pointer to ip */
+  ierr = 2;
+  status = CFI_setpointer(yp, ip, NULL);
+  if (status != CFI_SUCCESS) return ierr;
+  if (yp->attribute != CFI_attribute_pointer) return ierr;
+  /* Set the pointer to NULL */
+  ierr = 3;
+  status = CFI_setpointer(yp, NULL, NULL);
+  if (status != CFI_SUCCESS) return ierr;
+  if (yp->attribute != CFI_attribute_pointer) return ierr;
+  /* "Set" the ip variable to yp (should not be possible) */
+  ierr = 4;
+  status = CFI_setpointer(ip, yp, NULL);
+  if (status != CFI_INVALID_ATTRIBUTE) return ierr;
+  if (ip->attribute != CFI_attribute_other) return ierr;
+  if (ip->base_addr != auxp) return ierr;
+  return 0;
+}
Index: gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.f90
===
--- gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.f90	(revision 278048)
@@ -0,0 +1,25 @@
+! { dg-do run }
+! { dg-additional-options "-fbounds-check" }
+! { dg-additional-sources ISO_Fortran_binding_15.c }
+!
+! Test the fix for PR92142.
+!
+  use, intrinsic :: iso_c_binding, only: c_int
+
+  implicit none
+  
+  interface
+function c_setpointer(ip) result(ierr) bind(c)
+  use, intrinsic :: iso_c_binding, only: c_int
+  type(*), dimension(..), target :: ip
+  integer(c_int) :: ierr
+end function c_setpointer
+  end interface
+  
+  integer(c_int) :: it = 1
+  
+  if (c_setpointer(it) /= 0) stop 1
+  
+end
+
+! { dg-output "CFI_setpointer: Result shall be the address of a C descriptor for a Fortran pointer." }
Index: gcc/testsuite/gfortran.dg/ISO_Fortran_binding_10.c
===
--- gcc/testsuite/gfortran.dg/ISO_Fortran_binding_10.c	(revision 278047)
+++ gcc/testsuite/gfortran.dg/ISO_Fortran_binding_10.c	(revision 278048)
@@ -15,7 +15,7 @@
   bool err;
   CFI_CDESC_T(1) that;
   CFI_index_t lb[] = { 0, 0 };
-  CFI_index_t ub[] = { 4, 1 };
+  CFI_index_t ub[] = { 4, 0 };
   CFI_index_t st[] = { 2, 0 };
   int chksum[] = { 9, 36, 38 };
 
@@ -50,7 +50,7 @@
 
   if (err)
 {
-  printf("FAIL C: contiguity for flag value %i - is %i\n",flag, value);
+  printf("FAIL C: contiguity for flag value %i - is %i\n", flag, value);
   *status = 10;
   return;
 }
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(revision 278047)
+++ gcc/testsuite/ChangeLog	(revision 278048)
@@ -1,3 +1,11 @@
+2019-11-11  José Rui Faustino de Sousa  
+
+	PR fortran/92142
+	* gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.c: New.
+	* gcc/testsuite/gfortran.dg/ISO_Fortran_binding_16.f90: New.
+	* gcc/testsuite/gfortran.dg/ISO_Fortran_binding_10.c: Correct
+	upper bounds for case 0.
+
 2019-11-11  Thomas Schwinge  
 
 	* gfortran.dg/goacc/common-block-1.f90: Fix OpenACC directives
Index: libgfortran/runtime/ISO_Fortran_binding.c
===

Re: [PATCH] Fix PR92324

[Christophe Lyon]

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

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 (&stmts, 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 (&exit_gsi, new_vec_stmt, GSI_SAME_STMT);
> - first_vect = tem;
> + second_vect = gimple_convert (&stmts, vectype, second_vect);
> +  first_vect = gimple_build (&stmts, code, vectype,
> +first_vect, second_vect);
>  }
> +  gsi_insert_seq_before (&exit_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 (&stmts, 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);
> -  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 (&exit_gsi, new_vec_stmt, GSI_SAME_STMT);
> - first_vect = tem;
> + second_vect = gimple_convert (&stmts, vectype, second_vect);
> + first_vect = gimple_build (&stmts, code, vectype,
> +  

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

[Bernhard Reutner-Fischer]

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.

thanks,

Re: [PATCH, GCC] Fix unrolling check.

[Sudakshina Das]

Hi Eric

On 08/11/2019 19:16, Eric Botcazou wrote:
>> I was fiddling around with the loop unrolling pass and noticed a check
>> in decide_unroll_* functions (in the patch). The comment on top of this
>> check says
>> "/* If we were not asked to unroll this loop, just return back silently.
>>*/"
>> However the check returns when loop->unroll == 0 rather than 1.
>>
>> The check was added in r255106 where the ChangeLog suggests that the
>> actual intention was probably to check the value 1 and not 0.
> 
> No, this is intended, 0 is the default value of the field, not 1.  And note
> that decide_unroll_constant_iterations, decide_unroll_runtime_iterations and
> decide_unroll_stupid *cannot* be called with loop->unroll == 1 because of this
> check in decide_unrolling:

Thanks for the explanation. However, I do not understand why are we 
returning with the default value. The comment for "unroll" is a bit 
ambiguous for value 0.

   /* The number of times to unroll the loop.  0 means no information given,
  just do what we always do.  A value of 1 means do not unroll the loop.
  A value of USHRT_MAX means unroll with no specific unrolling factor.
  Other values means unroll with the given unrolling factor.  */
   unsigned short unroll;

What "do we always do"?

Thanks
Sudi

> 
>if (loop->unroll == 1)
>   {
> if (dump_file)
>   fprintf (dump_file,
>";; Not unrolling loop, user didn't want it unrolled\n");
> continue;
>   }
> 
>> Tested on aarch64-none-elf with one new regression:
>> FAIL: gcc.dg/pr40209.c (test for excess errors)
>> This fails because the changes cause the loop to unroll 3 times using
>> unroll_stupid and that shows up as excess error due -fopt-info. This
>> option was added in r202077 but I am not sure why this particular test
>> was chosen for it.
> 
> That's a regression, there should be no unrolling.
> 

Re: PC-relative TLS support

[Segher Boessenkool]

Hi Alan,

On Mon, Nov 11, 2019 at 05:46:01PM +1030, Alan Modra wrote:
> On Wed, Aug 21, 2019 at 09:55:28PM +0930, Alan Modra wrote:
> > On Mon, Aug 19, 2019 at 07:45:19AM -0500, Segher Boessenkool wrote:
> > > But if you think we can remove the !TARGET_TLS_MARKERS everywhere it
> > > is relevant at all, now is the time, patches very welcome, it would be
> > > a nice cleanup :-)  Needs testing everywhere of course, but now is
> > > stage 1 :-)
> > 
> > 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.  Bootstrapped and regression tested powerpc64le-linux and
> > powerpc-ibm-aix7.1.3.0 (on gcc111).  I believe powerpc*-darwin doesn't
> > support TLS.

Excellent :-)

> > Requiring an 8 year old binutils-2.20 shouldn't be that onerous.

Right.  Your binutils should be about the same vintage as your GCC, or
various things will not work anyway.  And building binutils is easy and
cheap anyway, compared to building GCC.

> I should have pinged this before now,

And I shouldn't have dropped it :-)

> and really I think the following
> additional patch makes more sense than any sort of sorry message.
> Mostly people will be running the assembler anyway so will discover
> quickly that their assembler is too old.

Yeah, that's fine.  Almost no one would ever hit that anwyay.

I'll reply to the rest as reply to the original mail.


Segher

[PATCH] Enable libsanitizer build on riscv64

[Andreas Schwab]

Only ubsan is supported so far.  This has been tested on openSUSE
Tumbleweed, there are no testsuite failures.

* configure.tgt (riscv64-*-linux*): Enable build.
---
 libsanitizer/configure.tgt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index 714f2923605..f7f3a6bd3ff 100644
--- a/libsanitizer/configure.tgt
+++ b/libsanitizer/configure.tgt
@@ -65,6 +65,8 @@ case "${target}" in
;;
   x86_64-*-solaris2.11* | i?86-*-solaris2.11*)
;;
+  riscv64-*-linux*)
+   ;;
   *)
UNSUPPORTED=1
;;
-- 
2.24.0


-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH] Add OpenACC 2.6 `serial' construct support

[Thomas Schwinge]

Hi Frederik!

On 2019-11-07T10:52:13+0100, Frederik Harwath  wrote:
> this patch implements the OpenACC 2.6 "serial" construct.

Thanks for taking on that one.

> It has been tested by running the testsuite with nvptx-none
> offloading on x86_64-pc-linux-gnu.

This is OK for trunk with the attached "incremental, into Add OpenACC 2.6
`serial' construct support" merged in.  (No need to re-test; I've just
done that.)  In the incremental patch, I'm streamlining some code,
format/handle 'serial' the same as existing 'parallel', etc., plus a few
more things, see my comments in the patch review below.

To record the review effort, please include "Reviewed-by: Thomas Schwinge
" in the commit log, see
.


I'm working on an additional patch to handle 'serial' in more cases where
it's wrong to diverge from 'parallel' (this tells us: a lot of testsuite
coverage is missing...), etc.

Thus I'm adding a lot of testsuite coverage.  I'm not asking you to work
on that, as that's not a feasible task for someone who's still new to all
this, to figure out the appropriate tests that should be
augmented/duplicated for 'serial'.  And, coming up with a list for you to
work though, I suppose would be more time consuming for me instead of
just doing it myself.  ;-)

However, you're of course always encouraged to learn from reading such
patches, and ask questions for any things unclear, of course.


> The `serial' construct (cf. section 2.5.3 of the OpenACC 2.6 standard)
> is equivalent to a `parallel' construct with clauses `num_gangs(1)
>  num_workers(1) vector_length(1)' implied.

..., and that's how it -- basically -- is implemented, and thus every
usage of 'serial' gets an annoying 'warning: using vector_length (32),
ignoring 1' for nvptx offloading compilation.  I wonder if we should
sinply disable that nvptx back end warning when an 'oacc serial'
attribute is present?  Or, if we should not, to highlight the issue that
I recently filed 
"OpenACC 'serial' construct might not actually be serial", discovered
during this review process?  (Summary: by GCC have a default of
'vector_length (32)', we do get vector parallelism with 'loop vector', or
'routine vector' inside 'serial' regions -- not clear if that's
intentional, and/or correct.)

> These clauses are therefore not supported with the `serial'
> construct. All the remaining clauses accepted with `parallel' are also
> accepted with `serial'.
>
> The `serial' construct is implemented like `parallel', except for
> hardcoding dimensions rather than taking them from the relevant
> clauses, in `expand_omp_target'.

> Separate codes are used to denote the `serial' construct throughout the
> middle end, even though the mapping of `serial' to an equivalent
> `parallel' construct could have been done in the individual language
> frontends.

Yeah, I'd pointed this out early on, and I still wonder if early
translating 'serial' into 'parallel num_gangs (1) num_workers (1)
vector_length (1)' (if that's really just what it is) would be better?
Would save quite some effort (duplicate all 'parallel' handling for
'serial').  On the other hand, we'd then need a different mechanism for:

> In particular, this allows to distinguish between `parallel'
> and `serial' in warnings, error messages, dumps etc.

... that (or just say "compute construct" instead of 'parallel',
'kernels', 'serial').  But we'll eventually want such a more general
mechnisma anyway;  "Adapt OpenMP diagnostic
messages for OpenACC".

So -- we've now got that implementation, and we can still clean it up
later on.


>   * omp-builtins.def (BUILT_IN_GOACC_PARALLEL): Add parameter.

Not anymore.


>  create mode 100644 gcc/testsuite/gfortran.dg/goacc/serial-dims.f90

>  create mode 100644 libgomp/testsuite/libgomp.oacc-fortran/serial-dims-aux.c
>  create mode 100644 libgomp/testsuite/libgomp.oacc-fortran/serial-dims.f90

Thanks to you (and/or Tobias, I suppose) for adding some Fortran
testsuite coversage, because:

> --- a/gcc/fortran/parse.c
> +++ b/gcc/fortran/parse.c
> @@ -683,6 +683,9 @@ decode_oacc_directive (void)
>matcha ("end parallel loop", gfc_match_omp_eos_error,
> ST_OACC_END_PARALLEL_LOOP);
>matcha ("end parallel", gfc_match_omp_eos_error, ST_OACC_END_PARALLEL);
> +  matcha ("end serial loop", gfc_match_omp_eos_error,
> +   ST_OACC_END_SERIAL_LOOP);
> +  matcha ("end serial", gfc_match_omp_eos_error, ST_OACC_END_SERIAL);
>matcha ("enter data", gfc_match_oacc_enter_data, ST_OACC_ENTER_DATA);
>matcha ("exit data", gfc_match_oacc_exit_data, ST_OACC_EXIT_DATA);
>break;

Wow, wow.  I see this has not been present in the og8 and og9 commits of
the OpenACC 'serial' changes.  This tells us: the OpenACC 'serial'
construct has *not at all* been tested with Fortran; any compilation
a

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

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: [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: [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: 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

[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: [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 (&stmts, 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 (&exit_gsi, new_vec_stmt, GSI_SAME_STMT);
> > - first_vect = tem;
> > + second_vect = gimple_convert (&stmts, vectype, second_vect);
> > +  first_vect = gimple_build (&stmts, code, vectype,
> > +first_vect, second_vect);
> >  }
> > +  gsi_insert_seq_before (&exit_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 (&stmts, 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 = PH

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, 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

[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 (&global_options, &global_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 (&global_options, &global_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 (&global_options, &global_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 (&global_options, &global_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 (&global_options, &global_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 (&global_options, &global_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 (&global_options, &global_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 && !opt

[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

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  -Wmissing-

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: [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] 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 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: [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] 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: [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.
> * gimple-loop-versioning.

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""=&d")
> + (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~

[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: [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 

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] 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: [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.

[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: [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""=&d")
>> +(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: [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""=&d")
>>> +   (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: [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   

[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] 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

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 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 b/lib

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: 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: [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 wa

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: [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
> 

[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;
 }
 

[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 $(top_srcdi

[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@"

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 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@ $(am__aclocal_

[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 @@ $(top_srcdir)/conf

[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

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?

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

[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: [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

[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

[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: [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
   -Wold-style-declaratio

[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

[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 

[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, &seg_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));

[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 { WELL_ORDER

[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, &part_cond_expr, dr_a, dr_b);
+  create_intersect_range_checks (loop, &part_cond_expr, *alias_pair);
   if (*cond_expr)
*cond_expr = fold_build2 (TRUTH_AND_EXPR, boolean_type_node,
  *cond_expr, part_cond_expr);

[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
+++ gcc/testsuite/gcc.dg/vect/

[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: 

[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 ADD_TEST(TYPE

[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, &niter_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;
+
+  poly

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

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

[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

[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

[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 &operator=(S &&x) = 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

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 &operator=(S &&x) = default; const T s{}; };
> +}
> +
> +void bar ()
> +{
> +  foo();
> +}
>
> Jakub
>
>

[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);
}

[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 (&ns->code, simplify_io_impl_do, dummy_expr_callback, NULL);
   gfc_code_walker (&ns->code, convert_do_while, dummy_expr_callback, NULL);
   gfc_code_walker (&ns->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, &symtree, 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;
+

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.

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 = &MEM  [(void *)p_5 + 5B];
>_2 = &MEM  [(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 (limit

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

[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, 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

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] 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 "=&r") (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 "=&r") (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 "pre

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: [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] 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

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