Re: [PR100843] store by mult pieces: punt on max_len < min_len

[Alexandre Oliva via Gcc-patches]

On Dec 10, 2021, Jeff Law  wrote:

> The patch is clearly safe.  My question is should we have caught this
> earlier in the call chain?

Callers will call try_store_by_multiple_pieces if set_storage_via_setmem
fails.  setmem doesn't necessarily need min and max len to do its job,
so if we were to modify callers, it would be just guarding the calls of
try_store_by_multiple_pieces with max_len >= min_len: 3 callers in 2
files, which didn't seem appealing to me.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] configure: Account CXXFLAGS in gcc-plugin.m4.

[Iain Sandoe via Gcc-patches]

While doing tests of the PCH changes, I noticed that all the
plugin tests were being omitted from m32 Darwin under some
permutations of flags.  It turned out to be a broken config
test - it was not removing -mdynamic-no-pic properly.

We now use a C++ compiler so that we need to process CXXFLAGS
as well as CFLAGS in the gcc-plugin config fragment.

Tested on i686, x86_64-darwin, x86_64, powerpc64le-linux
OK for master?
backports?

Signed-off-by: Iain Sandoe 

config/ChangeLog:

* gcc-plugin.m4: Save and process CXXFLAGS.

gcc/ChangeLog:

* configure: Regenerate.

libcc1/ChangeLog:

* configure: Regenerate.
---
 config/gcc-plugin.m4 | 5 +
 gcc/configure| 5 +
 libcc1/configure | 5 +
 3 files changed, 15 insertions(+)

diff --git a/config/gcc-plugin.m4 b/config/gcc-plugin.m4
index 8f278719118..7ee342fe5fe 100644
--- a/config/gcc-plugin.m4
+++ b/config/gcc-plugin.m4
@@ -91,14 +91,18 @@ AC_DEFUN([GCC_ENABLE_PLUGINS],
  # Check that we can build shared objects with -fPIC -shared
  saved_LDFLAGS="$LDFLAGS"
  saved_CFLAGS="$CFLAGS"
+ saved_CXXFLAGS="$CXXFLAGS"
  case "${host}" in
*-*-darwin*)
 CFLAGS=`echo $CFLAGS | sed s/-mdynamic-no-pic//g`
 CFLAGS="$CFLAGS -fPIC"
+CXXFLAGS=`echo $CXXFLAGS | sed s/-mdynamic-no-pic//g`
+CXXFLAGS="$CXXFLAGS -fPIC"
 LDFLAGS="$LDFLAGS -shared -undefined dynamic_lookup"
;;
*)
 CFLAGS="$CFLAGS -fPIC"
+CXXFLAGS="$CXXFLAGS -fPIC"
 LDFLAGS="$LDFLAGS -fPIC -shared"
;;
  esac
@@ -113,6 +117,7 @@ AC_DEFUN([GCC_ENABLE_PLUGINS],
  fi
  LDFLAGS="$saved_LDFLAGS"
  CFLAGS="$saved_CFLAGS"
+ CXXFLAGS="$saved_CXXFLAGS"
 
  # If plugin support had been requested but not available, fail.
  if test x"$enable_plugin" = x"no" ; then
diff --git a/gcc/configure b/gcc/configure
index de20e5d2629..5470987b62f 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -32038,14 +32038,18 @@ fi
  # Check that we can build shared objects with -fPIC -shared
  saved_LDFLAGS="$LDFLAGS"
  saved_CFLAGS="$CFLAGS"
+ saved_CXXFLAGS="$CXXFLAGS"
  case "${host}" in
*-*-darwin*)
 CFLAGS=`echo $CFLAGS | sed s/-mdynamic-no-pic//g`
 CFLAGS="$CFLAGS -fPIC"
+CXXFLAGS=`echo $CXXFLAGS | sed s/-mdynamic-no-pic//g`
+CXXFLAGS="$CXXFLAGS -fPIC"
 LDFLAGS="$LDFLAGS -shared -undefined dynamic_lookup"
;;
*)
 CFLAGS="$CFLAGS -fPIC"
+CXXFLAGS="$CXXFLAGS -fPIC"
 LDFLAGS="$LDFLAGS -fPIC -shared"
;;
  esac
@@ -32077,6 +32081,7 @@ rm -f core conftest.err conftest.$ac_objext \
  fi
  LDFLAGS="$saved_LDFLAGS"
  CFLAGS="$saved_CFLAGS"
+ CXXFLAGS="$saved_CXXFLAGS"
 
  # If plugin support had been requested but not available, fail.
  if test x"$enable_plugin" = x"no" ; then
diff --git a/libcc1/configure b/libcc1/configure
index b198b0b9074..01cfb2806da 100755
--- a/libcc1/configure
+++ b/libcc1/configure
@@ -15141,14 +15141,18 @@ fi
  # Check that we can build shared objects with -fPIC -shared
  saved_LDFLAGS="$LDFLAGS"
  saved_CFLAGS="$CFLAGS"
+ saved_CXXFLAGS="$CXXFLAGS"
  case "${host}" in
*-*-darwin*)
 CFLAGS=`echo $CFLAGS | sed s/-mdynamic-no-pic//g`
 CFLAGS="$CFLAGS -fPIC"
+CXXFLAGS=`echo $CXXFLAGS | sed s/-mdynamic-no-pic//g`
+CXXFLAGS="$CXXFLAGS -fPIC"
 LDFLAGS="$LDFLAGS -shared -undefined dynamic_lookup"
;;
*)
 CFLAGS="$CFLAGS -fPIC"
+CXXFLAGS="$CXXFLAGS -fPIC"
 LDFLAGS="$LDFLAGS -fPIC -shared"
;;
  esac
@@ -15180,6 +15184,7 @@ rm -f core conftest.err conftest.$ac_objext \
  fi
  LDFLAGS="$saved_LDFLAGS"
  CFLAGS="$saved_CFLAGS"
+ CXXFLAGS="$saved_CXXFLAGS"
 
  # If plugin support had been requested but not available, fail.
  if test x"$enable_plugin" = x"no" ; then
-- 
2.24.3 (Apple Git-128)

[pushed] libgcc, Darwin: Update darwin10 unwinder shim dependencies.

[Iain Sandoe via Gcc-patches]

We include libgcc_tm.h to provide a prototype for this shim
so add that to the make dependencies.

tested on x86_64-darwin, pushed to master, thanks
Iain

Signed-off-by: Iain Sandoe 

libgcc/ChangeLog:

* config/t-darwin: Add libgcc_tm.h to the dependencies
for darwin10-unwind-find-enc-func.
---
 libgcc/config/t-darwin | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcc/config/t-darwin b/libgcc/config/t-darwin
index a855ecfd526..299d26c2c96 100644
--- a/libgcc/config/t-darwin
+++ b/libgcc/config/t-darwin
@@ -25,7 +25,7 @@ libemutls_w.a: emutls_s.o
$(RANLIB_FOR_TARGET) $@
 
 # Patch to __Unwind_Find_Enclosing_Function for Darwin10.
-d10-uwfef.o: $(srcdir)/config/darwin10-unwind-find-enc-func.c
+d10-uwfef.o: $(srcdir)/config/darwin10-unwind-find-enc-func.c libgcc_tm.h
$(crt_compile) -mmacosx-version-min=10.6 -c $<
 
 # Using this crt as a library means that it will not be added to an exe
-- 
2.24.3 (Apple Git-128)

[committed] jit: set DECL_CONTEXT of RESULT_DECL [PR103562]

[David Malcolm via Gcc-patches]

libgccjit was failing to set the DECL_CONTEXT of function RESULT_DECLs,
leading to them failing to be properly handled by the inlining machinery.
Fixed thusly.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-5903-ga2f4b4b76cdd0a4150e82e69fae4a70c54b523d2.

gcc/jit/ChangeLog:
PR jit/103562
* jit-playback.c (gcc::jit::playback::context::new_function): Set
DECL_CONTEXT of the result_decl.

gcc/testsuite/ChangeLog:
PR jit/103562
* jit.dg/all-non-failing-tests.h: Add comment about...
* jit.dg/test-pr103562.c: New test.

Signed-off-by: David Malcolm 
---
 gcc/jit/jit-playback.c   |  1 +
 gcc/testsuite/jit.dg/all-non-failing-tests.h |  3 +
 gcc/testsuite/jit.dg/test-pr103562.c | 62 
 3 files changed, 66 insertions(+)
 create mode 100644 gcc/testsuite/jit.dg/test-pr103562.c

diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
index b9c05864900..a9f52cbd0ef 100644
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -473,6 +473,7 @@ new_function (location *loc,
   DECL_ARTIFICIAL (resdecl) = 1;
   DECL_IGNORED_P (resdecl) = 1;
   DECL_RESULT (fndecl) = resdecl;
+  DECL_CONTEXT (resdecl) = fndecl;
 
   if (builtin_id)
 {
diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h 
b/gcc/testsuite/jit.dg/all-non-failing-tests.h
index a7fddf96db8..3663f726a99 100644
--- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
+++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
@@ -230,6 +230,9 @@
 #undef create_code
 #undef verify_code
 
+/* test-pr103562.c: We don't add this one, since it touches
+   the optimization level of the context as a whole.  */
+
 /* test-pr66700-observing-write-through-ptr.c */
 #define create_code create_code_pr66700_observing_write_through_ptr
 #define verify_code verify_code_pr66700_observing_write_through_ptr
diff --git a/gcc/testsuite/jit.dg/test-pr103562.c 
b/gcc/testsuite/jit.dg/test-pr103562.c
new file mode 100644
index 000..de361b96bd1
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-pr103562.c
@@ -0,0 +1,62 @@
+#include 
+#include "harness.h"
+
+struct my_struct { long a; long b; long c; };
+
+void create_code (gcc_jit_context *ctxt, void *user_data)
+{
+   /* Create the equivalent of:
+   struct my_struct { long a; long b; long c; };
+   static struct my_struct deref(struct my_struct *ptr) { return 
*ptr; } 
+   long get_a(struct my_struct *s) { return deref(s).a; }
+  and compile it at -O1.  */
+   gcc_jit_context_set_int_option(ctxt, 
GCC_JIT_INT_OPTION_OPTIMIZATION_LEVEL, 1);
+
+   gcc_jit_type *long_type = gcc_jit_context_get_type(ctxt, 
GCC_JIT_TYPE_LONG);
+   gcc_jit_field* fields[3] = {
+   gcc_jit_context_new_field(ctxt, NULL, long_type, "a"),
+   gcc_jit_context_new_field(ctxt, NULL, long_type, "b"),
+   gcc_jit_context_new_field(ctxt, NULL, long_type, "c"),
+   };
+   gcc_jit_struct *my_struct =
+   gcc_jit_context_new_struct_type(ctxt, NULL, "my_struct", 3, 
fields);
+   gcc_jit_type *my_struct_type = gcc_jit_struct_as_type(my_struct);
+   gcc_jit_type *my_struct_ptr_type = 
gcc_jit_type_get_pointer(my_struct_type);
+
+   /* struct my_struct deref(struct my_struct *ptr) { return *ptr; } */
+   gcc_jit_param *param_deref =
+   gcc_jit_context_new_param(ctxt, NULL, my_struct_ptr_type, 
"ptr");
+   gcc_jit_function *func_deref = gcc_jit_context_new_function(
+   ctxt, NULL, GCC_JIT_FUNCTION_INTERNAL,
+   my_struct_type, "deref",
+   1, ¶m_deref,
+   0);
+   gcc_jit_block *blockDeref = gcc_jit_function_new_block(func_deref, 
NULL);
+   gcc_jit_block_end_with_return(
+   blockDeref, NULL,
+   
gcc_jit_lvalue_as_rvalue(gcc_jit_rvalue_dereference(gcc_jit_param_as_rvalue(param_deref),
 NULL)));
+
+   /* long get_a(struct my_struct *s) { return deref(s).a; } */
+   gcc_jit_param *param_get_a = gcc_jit_context_new_param(ctxt, NULL, 
my_struct_ptr_type, "s");
+   gcc_jit_function *func_get_a = gcc_jit_context_new_function(
+   ctxt, NULL, GCC_JIT_FUNCTION_EXPORTED,
+   long_type, "get_a",
+   1, ¶m_get_a,
+   0);
+   gcc_jit_block *block_get_a = gcc_jit_function_new_block(func_get_a, 
NULL);
+   gcc_jit_rvalue *argsForDeref[1] = 
{gcc_jit_param_as_rvalue(param_get_a)};
+   gcc_jit_rvalue *callDeref = gcc_jit_context_new_call(ctxt, NULL, 
func_deref, 1, argsForDeref);
+   gcc_jit_block_end_with_return(
+   block_get_a, NULL,
+   gcc_jit_rvalue_access_field(callDeref, NULL, fields[0]));
+}
+
+void
+verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
+{
+  typedef long(*fn_type) (struct my_struct*);
+  fn_type get_a = (fn_type) gcc_jit_result_get_code(result, "get_a");
+
+  struct my_struct s = {1, 2, 3};
+ 

testsuite: Be more informative for ICEs

[Thomas Schwinge]

Hi!

OK to push the attached "testsuite: Be more informative for ICEs"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 5ffc2cfc9c6ec6ed0937311377118efd648f0297 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 10 Dec 2021 19:08:26 +0100
Subject: [PATCH] testsuite: Be more informative for ICEs

For example, for the two (FAIL, XFAIL)
'gcc/testsuite/lib/gcc-dg.exp:gcc-dg-test-1' cases:

-FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (internal compiler error)
+FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (internal compiler error: tree check: expected var_decl or function_decl or field_decl or type_decl or concept_decl or template_decl, have namespace_decl in get_merge_kind, at cp/module.cc:10072)

-FAIL: gfortran.dg/gomp/clauses-1.f90   -O  (internal compiler error)
+FAIL: gfortran.dg/gomp/clauses-1.f90   -O  (internal compiler error: Segmentation fault)

-XFAIL: c-c++-common/goacc/kernels-decompose-ice-1.c (internal compiler error)
+XFAIL: c-c++-common/goacc/kernels-decompose-ice-1.c (internal compiler error: in lower_omp_target, at omp-low.c:13147)

-XFAIL: g++.dg/cpp1z/constexpr-lambda26.C  -std=c++17 (internal compiler error)
+XFAIL: g++.dg/cpp1z/constexpr-lambda26.C  -std=c++17 (internal compiler error: in cxx_eval_constant_expression, at cp/constexpr.c:6954)

That allows for more easily spotting when during development you're trading one
ICE for another.

	gcc/testsuite/
	* lib/fortran-torture.exp (fortran-torture-compile)
	(fortran-torture-execute): Be more informative for ICEs.
	* lib/gcc-defs.exp (${tool}_check_compile): Likewise.
	* lib/gcc-dg.exp (gcc-dg-test-1): Likewise.
	* lib/go-torture.exp (go-torture-compile, go-torture-execute):
	Likewise.
---
 gcc/testsuite/lib/fortran-torture.exp | 8 
 gcc/testsuite/lib/gcc-defs.exp| 4 ++--
 gcc/testsuite/lib/gcc-dg.exp  | 6 +++---
 gcc/testsuite/lib/go-torture.exp  | 8 
 4 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/gcc/testsuite/lib/fortran-torture.exp b/gcc/testsuite/lib/fortran-torture.exp
index d6759aa0b4b..11d73d9f1f7 100644
--- a/gcc/testsuite/lib/fortran-torture.exp
+++ b/gcc/testsuite/lib/fortran-torture.exp
@@ -138,8 +138,8 @@ proc fortran-torture-compile { src option } {
 	return
 }
 
-if [string match "*internal compiler error*" $comp_output] then {
-	gfortran_fail $testcase "$option (internal compiler error)"
+if [regexp -line -- "internal compiler error.*" $comp_output ice] then {
+	gfortran_fail $testcase "$option ($ice)"
 	catch { remote_file build delete $output }
 	return
 }
@@ -263,8 +263,8 @@ proc fortran-torture-execute { src } {
 	continue
 	}
 
-	if [string match "*internal compiler error*" $comp_output] then {
-	gfortran_fail $testcase "$option (internal compiler error)"
+	if [regexp -line -- "internal compiler error.*" $comp_output ice] then {
+	gfortran_fail $testcase "$option ($ice)"
 	catch { remote_file build delete $executable }
 	continue
 	}
diff --git a/gcc/testsuite/lib/gcc-defs.exp b/gcc/testsuite/lib/gcc-defs.exp
index d17308d0f86..66df4e1c6aa 100644
--- a/gcc/testsuite/lib/gcc-defs.exp
+++ b/gcc/testsuite/lib/gcc-defs.exp
@@ -38,8 +38,8 @@ proc ${tool}_check_compile {testcase option objname gcc_output} {
 	return 0
 }
 
-if [string match "*internal compiler error*" $gcc_output] then {
-	${tool}_fail $testcase "$option (internal compiler error)"
+if [regexp -line -- "internal compiler error.*" $gcc_output ice] then {
+	${tool}_fail $testcase "$option ($ice)"
 	return 0
 }
 
diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index 78a6c3651ef..464059608b8 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -315,13 +315,13 @@ proc gcc-dg-test-1 { target_compile prog do_what extra_tool_flags } {
 # to avoid a second failure for excess errors.
 # "Error reporting routines re-entered" ICE says "Internal" rather than
 # "internal", so match that too.
-if [string match {*[Ii]nternal compiler error*} $comp_output] {
+if [regexp -line -- {[Ii]nternal compiler error.*} $comp_output ice] {
 	upvar 2 name name
 	if { $expect_ice == 0 } {
-	  fail "$name (internal compiler error)"
+	  fail "$name ($ice)"
 	} else {
 	  # We expected an ICE and we got it.
-	  xfail "$name (internal compiler error)"
+	  xfail "$name ($ice)"
 	  # Prune the ICE from the output.
 	  set comp_output [prune_ices $comp_output]
 	}
diff --git a/gcc/testsuite/lib/go-torture.exp b/gcc/testsuite/lib/go-torture.exp
index 28247a1902d..adeae36f916 100644
--- a/gcc/testsuite/lib/go-torture.exp
+++ b/gcc/testsuite/lib/go-torture.exp
@@ -88,8 +88,8 @@ proc go-torture-compile { src option } {
 	return
 

Re: [PR100518] store by mult pieces: keep addr in Pmode

[Jeff Law via Gcc-patches]

On 12/9/2021 3:18 PM, Alexandre Oliva via Gcc-patches wrote:

The conversion of a MEM address to ptr_mode in
try_store_by_multiple_pieces was misguided: copy_addr_to_reg expects
Pmode for addresses.

Regstrapped on x86_64-linux-gnu, testcase verified with a cross to
aarch64.  Ok to install?


for  gcc/ChangeLog

PR target/100518
* builtins.c (try_store_by_multiple_pieces): Drop address
conversion to ptr_mode.

for  gcc/testsuite/ChangeLog

PR target/100518
* gcc.target/aarch64/pr100518.c: New.

OK
jeff

Re: [PR100843] store by mult pieces: punt on max_len < min_len

[Jeff Law via Gcc-patches]

On 12/9/2021 3:16 PM, Alexandre Oliva via Gcc-patches wrote:

The testcase confuses the code that detects min and max len for the
memset, so max_len ends up less than min_len.  That shouldn't be
possible, but the testcase requires us to handle this case.

The store-by-mult-pieces algorithm actually relies on min and max
lengths, so if we find them to be inconsistent, the best we can do is
punting.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/ChangeLog

PR middle-end/100843
* builtins.c (try_store_by_multiple_pieces): Fail if min_len
is greater than max_len.

for  gcc/testsuite/ChangeLog

PR middle-end/100843
* gcc.dg/pr100843.c: New.
The patch is clearly safe.  My question is should we have caught this 
earlier in the call chain?  If so, I'd prefer to fix it there and leave 
the gcc_unreachable in place to catch other bogus cases that may get 
into try_store_by_multiple_pieces.



Jeff

[PATCH] c++: Allow constexpr decltype(auto) [PR102229]

[Marek Polacek via Gcc-patches]

My r11-2202 was trying to enforce [dcl.type.auto.deduct]/4, which says
"If the placeholder-type-specifier is of the form type-constraint[opt]
decltype(auto), T shall be the placeholder alone."  But this made us
reject 'constexpr decltype(auto)', which, after clarification from CWG,
should be valid.  [dcl.type.auto.deduct]/4 is supposed to be a syntactic
constraint, not semantic, so it's OK that the constexpr marks the object
as const.

As a consequence, checking TYPE_QUALS in do_auto_deduction is too late,
and we have a FIXME there anyway.  So in this patch I'm attempting to
detect 'const decltype(auto)' earlier.  If I'm going to use TYPE_QUALS,
it needs to happen before we mark the object as const due to constexpr,
that is, before grokdeclarator's

  /* A `constexpr' specifier used in an object declaration declares
 the object as `const'.  */
  if (constexpr_p && innermost_code != cdk_function)
...

Constrained decltype(auto) was a little problem, hence the TYPENAME
check.  But in a typename context you can't use decltype(auto) anyway,
I think.

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

PR c++/102229

gcc/cp/ChangeLog:

* decl.c (check_decltype_auto): New.
(grokdeclarator): Call it.
* pt.c (do_auto_deduction): Don't check decltype(auto) here.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/decltype-auto5.C: New test.
---
 gcc/cp/decl.c   | 58 ++---
 gcc/cp/pt.c | 13 -
 gcc/testsuite/g++.dg/cpp1y/decltype-auto5.C | 35 +
 3 files changed, 74 insertions(+), 32 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/decltype-auto5.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 56f80775ca0..196eac287eb 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -11354,6 +11354,33 @@ name_unnamed_type (tree type, tree decl)
   gcc_assert (!TYPE_UNNAMED_P (type));
 }
 
+/* Check that decltype(auto) was well-formed: only plain decltype(auto)
+   is allowed.  TYPE might contain a decltype(auto).  Returns true if
+   there was a problem, false otherwise.  */
+
+static bool
+check_decltype_auto (location_t loc, tree type)
+{
+  if (tree a = type_uses_auto (type))
+{
+  if (AUTO_IS_DECLTYPE (a))
+   {
+ if (a != type)
+   {
+ error_at (loc, "%qT as type rather than plain "
+   "%", type);
+ return true;
+   }
+ else if (TYPE_QUALS (type) != TYPE_UNQUALIFIED)
+   {
+ error_at (loc, "% cannot be cv-qualified");
+ return true;
+   }
+   }
+}
+  return false;
+}
+
 /* Given declspecs and a declarator (abstract or otherwise), determine
the name and type of the object declared and construct a DECL node
for it.
@@ -12702,25 +12729,9 @@ grokdeclarator (const cp_declarator *declarator,
  "allowed");
return error_mark_node;
  }
-   /* Only plain decltype(auto) is allowed.  */
-   if (tree a = type_uses_auto (type))
- {
-   if (AUTO_IS_DECLTYPE (a))
- {
-   if (a != type)
- {
-   error_at (typespec_loc, "%qT as type rather than "
- "plain %", type);
-   return error_mark_node;
- }
-   else if (TYPE_QUALS (type) != TYPE_UNQUALIFIED)
- {
-   error_at (typespec_loc, "% cannot be "
- "cv-qualified");
-   return error_mark_node;
- }
- }
- }
+
+   if (check_decltype_auto (typespec_loc, type))
+ return error_mark_node;
 
if (ctype == NULL_TREE
&& decl_context == FIELD
@@ -13080,6 +13091,15 @@ grokdeclarator (const cp_declarator *declarator,
 
   id_loc = declarator ? declarator->id_loc : input_location;
 
+  if (innermost_code != cdk_function
+/* Don't check this if it can be the artifical decltype(auto)
+   we created when building a constraint in a compound-requirement:
+   that the type-constraint is plain is going to be checked in
+   cp_parser_compound_requirement.  */
+  && decl_context != TYPENAME
+  && check_decltype_auto (id_loc, type))
+return error_mark_node;
+
   /* A `constexpr' specifier used in an object declaration declares
  the object as `const'.  */
   if (constexpr_p && innermost_code != cdk_function)
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 9834baf34db..6d5da17b9d0 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -29912,19 +29912,6 @@ do_auto_deduction (tree type, tree init, tree 
auto_node,
return error_mark_node;
   targs = make_tree_vec (1);
   TREE_VEC_ELT (targs, 0) = deduced;
-  /* FIXME: These errors ought to be diagnosed at pars

[PATCH] PR fortran/103606 - [9/10/11/12 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13297

[Harald Anlauf via Gcc-patches]

Dear all,

when accessing CLASS components we need to ensure that the
corresponding class container has already been built.
Invalid code, e.g. the testcase in PR103606, may otherwise
generate segfaults due to invalid reads.

Regtested on x86_64-pc-linux-gnu.  OK for mainline / branches?

Thanks,
Harald

From 6e41e4391a54337bd32560be2b72e11ceba37b3a Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Fri, 10 Dec 2021 22:41:24 +0100
Subject: [PATCH] Fortran: fix checking of elemental functions of type CLASS

gcc/fortran/ChangeLog:

	PR fortran/103606
	* resolve.c (resolve_fl_procedure): Do not access CLASS components
	before class container has been built.

gcc/testsuite/ChangeLog:

	PR fortran/103606
	* gfortran.dg/pr103606.f90: New test.
---
 gcc/fortran/resolve.c  |  3 ++-
 gcc/testsuite/gfortran.dg/pr103606.f90 | 12 
 2 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr103606.f90

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 0ed31970f8b..bff1b35446f 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -13294,7 +13294,8 @@ resolve_fl_procedure (gfc_symbol *sym, int mp_flag)

   /* An elemental function is required to return a scalar 12.7.1  */
   if (sym->attr.elemental && sym->attr.function
-  && (sym->as || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->as)))
+  && (sym->as || (sym->ts.type == BT_CLASS && sym->attr.class_ok
+		  && CLASS_DATA (sym)->as)))
 {
   gfc_error ("ELEMENTAL function %qs at %L must have a scalar "
 		 "result", sym->name, &sym->declared_at);
diff --git a/gcc/testsuite/gfortran.dg/pr103606.f90 b/gcc/testsuite/gfortran.dg/pr103606.f90
new file mode 100644
index 000..43283184e89
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103606.f90
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! PR fortran/103606 -  ICE in resolve_fl_procedure
+! Contributed by G.Steinmetz
+
+program p
+  type t
+  end type
+contains
+  elemental function f() result(z) ! { dg-error "CLASS variable" }
+class(t) :: z
+  end
+end
--
2.26.2

Re: [PATCH] Replace gnu::unique_ptr with std::unique_ptr

[Jonathan Wakely via Gcc-patches]

On 10/12/21 21:20 +, Jonathan Wakely wrote:

Ping


Oh sorry, Jakub already replied to this (after I mentioned it on IRC)
and approved it. 


Un-ping!



On 09/11/21 17:51 +, Jonathan Wakely wrote:

Now that GCC is compiled as C++11 there is no need to keep the C++03
implementation of gnu::unique_ptr.

This removes the unique-ptr.h header and replaces it with  in
system.h, and changes the INCLUDE_UNIQUE_PTR macro to INCLUDE_MEMORY.
Uses of gnu::unique_ptr and gnu::move can be replaced with
std::unique_ptr and std::move. There are no uses of unique_xmalloc_ptr
or xmalloc_deleter in GCC.


Bootstrapped and tested on powerpc64le-linux. OK for trunk?



gcc/analyzer/ChangeLog:

* engine.cc: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.

gcc/c-family/ChangeLog:

* known-headers.cc: Define INCLUDE_MEMORY instead of
INCLUDE_UNIQUE_PTR.
* name-hint.h: Likewise.
(class name_hint): Use std::unique_ptr instead of gnu::unique_ptr.

gcc/c/ChangeLog:

* c-decl.c: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.
* c-parser.c: Likewise.

gcc/cp/ChangeLog:

* error.c: Define INCLUDE_MEMORY instead of
INCLUDE_UNIQUE_PTR.
* lex.c: Likewise.
* name-lookup.c: Likewise.
(class namespace_limit_reached): Use std::unique_ptr instead of
gnu::unique_ptr.
(suggest_alternatives_for): Use std::move instead of gnu::move.
(suggest_alternatives_in_other_namespaces): Likewise.
* parser.c: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.

gcc/ChangeLog:

* Makefile.in: Remove unique-ptr-tests.o.
* selftest-run-tests.c (selftest::run_tests): Remove
unique_ptr_tests_cc_tests.
* selftest.h (unique_ptr_tests_cc_tests): Remove.
* system.h: Check INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR
and include  instead of "unique-ptr.h".
* unique-ptr-tests.cc: Removed.

include/ChangeLog:

* unique-ptr.h: Removed.
---
gcc/Makefile.in   |   1 -
gcc/analyzer/engine.cc|   2 +-
gcc/c-family/known-headers.cc |   2 +-
gcc/c-family/name-hint.h  |  12 +-
gcc/c/c-decl.c|   2 +-
gcc/c/c-parser.c  |   2 +-
gcc/cp/error.c|   2 +-
gcc/cp/lex.c  |   2 +-
gcc/cp/name-lookup.c  |  10 +-
gcc/cp/parser.c   |   2 +-
gcc/selftest-run-tests.c  |   1 -
gcc/selftest.h|   1 -
gcc/system.h  |   8 +-
gcc/unique-ptr-tests.cc   | 236 
include/unique-ptr.h  | 405 --
15 files changed, 21 insertions(+), 667 deletions(-)
delete mode 100644 gcc/unique-ptr-tests.cc
delete mode 100644 include/unique-ptr.h

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 571e9c28e29..1e8e4449ffb 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1693,7 +1693,6 @@ OBJS = \
tree.o \
tristate.o \
typed-splay-tree.o \
-   unique-ptr-tests.o \
valtrack.o \
value-pointer-equiv.o \
value-query.o \
diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index f21f8e5b78a..1312741bb47 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -19,7 +19,7 @@ along with GCC; see the file COPYING3.  If not see
.  */

#include "config.h"
-#define INCLUDE_UNIQUE_PTR
+#define INCLUDE_MEMORY
#include "system.h"
#include "coretypes.h"
#include "tree.h"
diff --git a/gcc/c-family/known-headers.cc b/gcc/c-family/known-headers.cc
index a3912468a8d..572cca177fa 100644
--- a/gcc/c-family/known-headers.cc
+++ b/gcc/c-family/known-headers.cc
@@ -18,7 +18,7 @@ along with GCC; see the file COPYING3.  If not see
.  */

#include "config.h"
-#define INCLUDE_UNIQUE_PTR
+#define INCLUDE_MEMORY
#include "system.h"
#include "coretypes.h"
#include "c-family/c-common.h"
diff --git a/gcc/c-family/name-hint.h b/gcc/c-family/name-hint.h
index ea433243ba4..3141552ea59 100644
--- a/gcc/c-family/name-hint.h
+++ b/gcc/c-family/name-hint.h
@@ -20,12 +20,12 @@ along with GCC; see the file COPYING3.  If not see
#ifndef GCC_NAME_HINT_H
#define GCC_NAME_HINT_H

-/* This header uses gnu::unique_ptr, but unique-ptr.h can't be directly
+/* This header uses std::unique_ptr, but  can't be directly
  included due to issues with macros.  Hence it must be included from
-   system.h by defining INCLUDE_UNIQUE_PTR in any source file using it.  */
+   system.h by defining INCLUDE_MEMORY in any source file using it.  */

-#ifndef GNU_UNIQUE_PTR_H
-# error "You must define INCLUDE_UNIQUE_PTR before including system.h to use 
name-hint.h"
+#ifndef INCLUDE_MEMORY
+# error "You must define INCLUDE_MEMORY before including system.h to use 
name-hint.h"
#endif

enum lookup_name_fuzzy_kind {
@@ -106,7 +106,7 @@ public:

 /* Take ownership of this name_hint's deferred_diagnostic, for use
in chaining up deferred diagnostics.  

Re: [PATCH] pch: Small cleanup

[Jeff Law via Gcc-patches]

On 12/10/2021 5:56 AM, Jakub Jelinek wrote:

On Thu, Dec 09, 2021 at 05:59:54PM +0100, Jakub Jelinek via Gcc-patches wrote:

/tmp/6140018_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/aarch64/aarch64-sve-builtins.cc:3920:0:
./gt-aarch64-sve-builtins.h: In function 'void
gt_pch_p_19registered_function(void*, void*, gt_pointer_operator, void*)':
./gt-aarch64-sve-builtins.h:86:44: error: no matching function for call to
'gt_pch_nx(aarch64_sve::function_instance*, void (*&)(void*, void*, void*),
void*&)'
  gt_pch_nx (&((*x).instance), op, cookie);

Fixed thusly, compile tested on x86_64-linux, committed to trunk.

Here is a small cleanup.  IMHO we should use gt_pointer_operator instead of
specifying manually void (*) (void *, void *) or
void (*) (void *, void *, void *) so that next time we want to change it,
we don't have to trace all the spots.  I was afraid it wouldn't work due to
header dependencies, but it works well.  gengtype generated files also
use gt_pointer_operator.

Ok for trunk (tested on x86_64-linux and cross to aarch64-linux)?

2021-12-10  Jakub Jelinek  

* machmode.h (gt_pch_nx): Use gt_pointer_operator as type of second
argument instead of equivalent void (*) (void *, void *, void *).
* poly-int.h (gt_pch_nx): Likewise.
* wide-int.h (gt_pch_nx): Likewise.
* config/aarch64/aarch64-sve-builtins.cc (gt_pch_nx): Likewise.

OK
jeff

Re: [PATCH] Replace gnu::unique_ptr with std::unique_ptr

[Jonathan Wakely via Gcc-patches]

Ping

On 09/11/21 17:51 +, Jonathan Wakely wrote:

Now that GCC is compiled as C++11 there is no need to keep the C++03
implementation of gnu::unique_ptr.

This removes the unique-ptr.h header and replaces it with  in
system.h, and changes the INCLUDE_UNIQUE_PTR macro to INCLUDE_MEMORY.
Uses of gnu::unique_ptr and gnu::move can be replaced with
std::unique_ptr and std::move. There are no uses of unique_xmalloc_ptr
or xmalloc_deleter in GCC.


Bootstrapped and tested on powerpc64le-linux. OK for trunk?



gcc/analyzer/ChangeLog:

* engine.cc: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.

gcc/c-family/ChangeLog:

* known-headers.cc: Define INCLUDE_MEMORY instead of
INCLUDE_UNIQUE_PTR.
* name-hint.h: Likewise.
(class name_hint): Use std::unique_ptr instead of gnu::unique_ptr.

gcc/c/ChangeLog:

* c-decl.c: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.
* c-parser.c: Likewise.

gcc/cp/ChangeLog:

* error.c: Define INCLUDE_MEMORY instead of
INCLUDE_UNIQUE_PTR.
* lex.c: Likewise.
* name-lookup.c: Likewise.
(class namespace_limit_reached): Use std::unique_ptr instead of
gnu::unique_ptr.
(suggest_alternatives_for): Use std::move instead of gnu::move.
(suggest_alternatives_in_other_namespaces): Likewise.
* parser.c: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.

gcc/ChangeLog:

* Makefile.in: Remove unique-ptr-tests.o.
* selftest-run-tests.c (selftest::run_tests): Remove
unique_ptr_tests_cc_tests.
* selftest.h (unique_ptr_tests_cc_tests): Remove.
* system.h: Check INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR
and include  instead of "unique-ptr.h".
* unique-ptr-tests.cc: Removed.

include/ChangeLog:

* unique-ptr.h: Removed.
---
gcc/Makefile.in   |   1 -
gcc/analyzer/engine.cc|   2 +-
gcc/c-family/known-headers.cc |   2 +-
gcc/c-family/name-hint.h  |  12 +-
gcc/c/c-decl.c|   2 +-
gcc/c/c-parser.c  |   2 +-
gcc/cp/error.c|   2 +-
gcc/cp/lex.c  |   2 +-
gcc/cp/name-lookup.c  |  10 +-
gcc/cp/parser.c   |   2 +-
gcc/selftest-run-tests.c  |   1 -
gcc/selftest.h|   1 -
gcc/system.h  |   8 +-
gcc/unique-ptr-tests.cc   | 236 
include/unique-ptr.h  | 405 --
15 files changed, 21 insertions(+), 667 deletions(-)
delete mode 100644 gcc/unique-ptr-tests.cc
delete mode 100644 include/unique-ptr.h

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 571e9c28e29..1e8e4449ffb 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1693,7 +1693,6 @@ OBJS = \
tree.o \
tristate.o \
typed-splay-tree.o \
-   unique-ptr-tests.o \
valtrack.o \
value-pointer-equiv.o \
value-query.o \
diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index f21f8e5b78a..1312741bb47 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -19,7 +19,7 @@ along with GCC; see the file COPYING3.  If not see
.  */

#include "config.h"
-#define INCLUDE_UNIQUE_PTR
+#define INCLUDE_MEMORY
#include "system.h"
#include "coretypes.h"
#include "tree.h"
diff --git a/gcc/c-family/known-headers.cc b/gcc/c-family/known-headers.cc
index a3912468a8d..572cca177fa 100644
--- a/gcc/c-family/known-headers.cc
+++ b/gcc/c-family/known-headers.cc
@@ -18,7 +18,7 @@ along with GCC; see the file COPYING3.  If not see
.  */

#include "config.h"
-#define INCLUDE_UNIQUE_PTR
+#define INCLUDE_MEMORY
#include "system.h"
#include "coretypes.h"
#include "c-family/c-common.h"
diff --git a/gcc/c-family/name-hint.h b/gcc/c-family/name-hint.h
index ea433243ba4..3141552ea59 100644
--- a/gcc/c-family/name-hint.h
+++ b/gcc/c-family/name-hint.h
@@ -20,12 +20,12 @@ along with GCC; see the file COPYING3.  If not see
#ifndef GCC_NAME_HINT_H
#define GCC_NAME_HINT_H

-/* This header uses gnu::unique_ptr, but unique-ptr.h can't be directly
+/* This header uses std::unique_ptr, but  can't be directly
   included due to issues with macros.  Hence it must be included from
-   system.h by defining INCLUDE_UNIQUE_PTR in any source file using it.  */
+   system.h by defining INCLUDE_MEMORY in any source file using it.  */

-#ifndef GNU_UNIQUE_PTR_H
-# error "You must define INCLUDE_UNIQUE_PTR before including system.h to use 
name-hint.h"
+#ifndef INCLUDE_MEMORY
+# error "You must define INCLUDE_MEMORY before including system.h to use 
name-hint.h"
#endif

enum lookup_name_fuzzy_kind {
@@ -106,7 +106,7 @@ public:

  /* Take ownership of this name_hint's deferred_diagnostic, for use
 in chaining up deferred diagnostics.  */
-  gnu::unique_ptr take_deferred () { return move 
(m_deferred); }
+  std::unique_ptr take_deferred () { return move 
(m_deferred); }

  /* Call t

Re: [PATCH] Remove an invalid assert. [PR103619]

[Jeff Law via Gcc-patches]

On 12/9/2021 10:32 AM, Hafiz Abid Qadeer wrote:

Commit 13b6c7639cf assumed that registers in a span will be in a certain
order. But that assumption is not true at least for the big endian targets.
Currently amdgcn is probably only target where CFA is split into multiple
registers so build_span_loc is only gets called for it. However, the
dwf_cfa_reg function where this ICE was seen can be called for any
architecture from the comparison dwf_cfa_reg (src) == cur_cfa->reg in
dwarf2out_frame_debug_expr. So dwf_cfa_reg should not assume certain
order of registers.

I was tempted to modify the assert to handle big-endian cases but that will
still be error prone and may fail on some other targets.

gcc/ChangeLog:

PR debug/103619
* dwarf2cfi.c (dwf_cfa_reg): Remove gcc_assert.
FWIW, the bogus assert can be triggered on other platforms too. c6x-elf 
for example with -mbig-endian.


I don't know enough about this code to review.

jeff

Re: [PATCH] gengtype: remove "tree_exp" special attribute

[Jeff Law via Gcc-patches]

On 12/10/2021 8:41 AM, Patrick Palka via Gcc-patches wrote:

The function comment for adjust_field_tree_exp says this special case
is for handling trees whose operands may contain pointers to RTL instead
of to trees.  But ever since r0-59671, which fixed/removed the last two
tree codes for which this was possible (GOTO_SUBROUTINE_EXPR and
WITH_CLEANUP_EXPR), this special attribute is largely a no-op.

This patch removes it and instead just annotates struct tree_exp
with the "length" attribute directly.  Not sure it makes a difference,
but I use %h instead of %0 in the "length" attribute to be consistent
with other structures' "length" attributes within tree-core.h.

This changes the code generated for TS_EXP handling in gt-cp-tree.h from:

   case TS_EXP:
 gt_ggc_m_9tree_node ((*x).generic.exp.typed.type);
 switch ((int) (TREE_CODE ((tree) &(*x
   {
   default:
{
  size_t i3;
  size_t l3 = (size_t)(TREE_OPERAND_LENGTH ((tree) &(*x)));
  for (i3 = 0; i3 != l3; i3++) {
gt_ggc_m_9tree_node ((*x).generic.exp.operands[i3]);
  }
}
break;
   }
 break;

to:

   case TS_EXP:
 {
   size_t l3 = (size_t)(TREE_OPERAND_LENGTH ((tree)&((*x).generic.exp)));
   gt_ggc_m_9tree_node ((*x).generic.exp.typed.type);
   {
size_t i3;
for (i3 = 0; i3 != l3; i3++) {
  gt_ggc_m_9tree_node ((*x).generic.exp.operands[i3]);
}
   }
 }

which seems equivalent and simpler.

Boostrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk?

gcc/ChangeLog:

* gengtype.c (adjust_field_tree_exp): Remove.
(adjust_field_type): Don't handle the "tree_exp" special attribute.
* tree-core.h (struct tree_exp): Replace special and desc
attributes with length.

Should this wait until stage1 reopens?  It doesn't seem like a bugfix.

jeff

Re: [PATCH] vect: Add bias parameter for partial vectorization

[Richard Sandiford via Gcc-patches]

Robin Dapp  writes:
> Hi Kewen, Richard,
>
> thanks for the comments, I addressed them in the attached v4.

Sorry again for the slow review.  I only have some very minor
comments left:

> Bootstrap and regtest are good as before.
>
> Regards
>  Robin
>
> diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
> index bf033e31c1c..dc2756f83e9 100644
> --- a/gcc/config/rs6000/vsx.md
> +++ b/gcc/config/rs6000/vsx.md
> @@ -5637,7 +5637,8 @@
>  (define_expand "len_load_v16qi"
>[(match_operand:V16QI 0 "vlogical_operand")
> (match_operand:V16QI 1 "memory_operand")
> -   (match_operand:QI 2 "gpc_reg_operand")]
> +   (match_operand:QI 2 "gpc_reg_operand")
> +   (match_operand:QI 3 "zero_constant")]
>"TARGET_P9_VECTOR && TARGET_64BIT"
>  {
>rtx mem = XEXP (operands[1], 0);
> @@ -5651,6 +5652,7 @@
>[(match_operand:V16QI 0 "memory_operand")
> (match_operand:V16QI 1 "vlogical_operand")
> (match_operand:QI 2 "gpc_reg_operand")
> +   (match_operand:QI 3 "zero_constant")
>]
>"TARGET_P9_VECTOR && TARGET_64BIT"
>  {
> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
> index 2b41cb7fb7b..8df61f578bd 100644
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -5213,7 +5213,10 @@ which must be a vector mode.  Operand 2 has whichever 
> integer mode the
>  target prefers.  If operand 2 exceeds the number of elements in mode
>  @var{m}, the behavior is undefined.  If the target prefers the length
>  to be measured in bytes rather than elements, it should only implement
> -this pattern for vectors of @code{QI} elements.
> +this pattern for vectors of @code{QI} elements.  Operand 3 specifies
> +a bias predicate that determines whether a length of zero is permitted
> +or not.  If permitted, the predicate should only allow a zero immediate,
> +otherwise it should only allow an immediate value of -1.

I think it would be better to fold this into the existing documentation
a bit more:

--
Load (operand 2 - operand 3) elements from vector memory operand 1 into
vector register operand 0, setting the other elements of operand 0 to
undefined values.  Operands 0 and 1 have mode @var{m}, which must be a
vector mode.  Operand 2 has whichever integer mode the target prefers.
Operand 3 conceptually has mode @code{QI}.

Operand 2 can be a variable or a constant amount.  Operand 3 specifies
a constant bias: it is either a constant 0 or a constant -1.  The predicate
on operand 3 must only accept the bias values that the target actually
supports.  GCC handles a bias of 0 more efficiently than a bias of -1.

If (operand 2 - operand 3) exceeds the number of elements in mode @var{m},
the behavior is undefined.

If the target prefers the length to be measured in bytes rather than
elements, it should only implement this pattern for vectors of @code{QI}
elements.
--

> @@ -5226,7 +5229,10 @@ a vector mode.  Operand 2 has whichever integer mode 
> the target prefers.
>  If operand 2 exceeds the number of elements in mode @var{m}, the behavior
>  is undefined.  If the target prefers the length to be measured in bytes
>  rather than elements, it should only implement this pattern for vectors
> -of @code{QI} elements.
> +of @code{QI} elements.  Operand 3 specifies a bias predicate that
> +determines whether a length of zero is permitted or not.  If permitted,
> +the predicate should only allow a zero constant, otherwise it should
> +only allow an immediate value of -1.
>  
>  This pattern is not allowed to @code{FAIL}.

Similarly here I think we should say:

--
Store (operand 2 - operand 3) vector elements from vector register
operand 1 into memory operand 0, leaving the other elements of operand 0
unchanged.  Operands 0 and 1 have mode @var{m}, which must be a vector mode.
Operand 2 has whichever integer mode the target prefers.  Operand 3
conceptually has mode @code{QI}.

Operand 2 can be a variable or a constant amount.  Operand 3 specifies
a constant bias: it is either a constant 0 or a constant -1.  The predicate
on operand 3 must only accept the bias values that the target actually
supports.  GCC handles a bias of 0 more efficiently than a bias of -1.

If (operand 2 - operand 3) exceeds the number of elements in mode @var{m},
the behavior is undefined.

If the target prefers the length to be measured in bytes rather than
elements, it should only implement this pattern for vectors of @code{QI}
elements.
--

> diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
> index 8312d08aab2..d45f080c06f 100644
> --- a/gcc/internal-fn.c
> +++ b/gcc/internal-fn.c
> @@ -2696,9 +2696,9 @@ expand_call_mem_ref (tree type, gcall *stmt, int index)
>  static void
>  expand_partial_load_optab_fn (internal_fn, gcall *stmt, convert_optab optab)
>  {
>

[PATCH] c++: processing_template_decl vs template depth [PR103408]

[Patrick Palka via Gcc-patches]

We use processing_template_decl in two slightly different ways: as
a flag to signal that we're dealing with templated trees, and its
magnitude is also used as a proxy for the current syntactic template
depth.  This overloaded meaning of p_t_d is conceptually confusing and
leads to bugs that we end up working around in an ad-hoc fashion.

This patch replaces all uses of processing_template_decl that care about
its magnitude to instead look at the depth of current_template_parms
via a new current_template_depth macro.  This allows us to eliminate 3
workarounds in the concepts code: two about non-templated
requires-expressions (in constraint.cc) and one about lambdas inside
constraints (in cp_parser_requires_clause_expression etc).

The replacement was mostly mechanical.  There were two gotchas:

  * In synthesize_implicit_template_parm, when introducing a new template
parameter list for an abbreviated function template, we need to add a
new level of current_template_parms before calling
process_template_parm since this function now looks at
current_template_depth to determine the level of the new parameter.

  * In instantiate_class_template_1 when instantiating a template
friend, we need to set current_template_parms instead of
processing_template_decl so that the friend_depth computation in
make_friend_class remains correct.

Bootstrpped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?  Also tested on cmcstl2 and rangev3.

PR c++/103408

gcc/cp/ChangeLog:

* constraint.cc (type_deducible_p): Remove workaround for
non-templated requires-expressions.
(normalize_placeholder_type_constraints): Likewise.
* cp-tree.h (current_template_depth): Define.
* decl.c (start_decl): Inspect current_template_depth instead of
the magnitude of processing_template_decl.
(grokfndecl): Likewise.
(grokvardecl): Likewise.
(grokdeclarator): Likewise.
* friend.c (make_friend_class): Likewise.
(do_friend): Likewise.
* parser.c (cp_parser_requires_clause_expression): Remove
workaround for lambdas inside constraints.
(cp_parser_constraint_expression): Likewise.
(cp_parser_requires_expression): Likewise.
(synthesize_implicit_template_parm): Add to current_template_parms
before calling process_template_parm.
* pt.c (inline_needs_template_parms): Inspect
current_template_depth instead of the magnitude of
processing_template_decl.
(push_inline_template_parms_recursive): Likewise.
(maybe_begin_member_template_processing): Likewise.
(begin_template_parm_list): Likewise.
(process_template_parm): Likewise.
(end_template_parm_list): Likewise.
(add_inherited_template_parms): Likewise.
(instantiate_class_template_1): Rename
adjust_processing_template_decl to adjust_template_depth.  Set
current_template_parms instead of processing_template_decl when
adjust_template_depth.
(make_auto_1): Inspect current_template_depth instead of the
magnitude of processing_template_decl.
(splice_late_return_type): Likewise.
* semantics.c (fixup_template_type): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/concepts/diagnostic18.C: Expect a "constraints on a
non-templated function" error.
* g++.dg/cpp23/auto-fncast10.C: New test.
---
 gcc/cp/constraint.cc | 16 --
 gcc/cp/cp-tree.h |  2 +
 gcc/cp/decl.c| 10 ++--
 gcc/cp/friend.c  |  4 +-
 gcc/cp/parser.c  | 28 --
 gcc/cp/pt.c  | 54 +++-
 gcc/cp/semantics.c   |  2 +-
 gcc/testsuite/g++.dg/concepts/diagnostic18.C |  2 +-
 gcc/testsuite/g++.dg/cpp23/auto-fncast10.C   | 19 +++
 9 files changed, 70 insertions(+), 67 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp23/auto-fncast10.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 2896efdd7f2..566f4e38fac 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -2016,14 +2016,6 @@ type_deducible_p (tree expr, tree type, tree 
placeholder, tree args,
  references are preserved in the result.  */
   expr = force_paren_expr_uneval (expr);
 
-  /* When args is NULL, we're evaluating a non-templated requires expression,
- but even those are parsed under processing_template_decl == 1, and so the
- placeholder 'auto' inside this return-type-requirement has level 2.  In
- order to have all parms and arguments match up for satisfaction, we need
- to pass an empty level of OUTER_TARGS in this case.  */
-  if (!args)
-args = make_tree_vec (0);
-
   tree deduced_type = do_auto_deduction (type, expr, placeholder,
 info.compla

Re: [PATCH] jit: Add support for global rvalue initialization and ctors

[Marc Nieper-Wißkirchen via Gcc-patches]

 Hi,

I would favor adding support for this kind of initialization to libgccjit.

Does it also support the libgccjit equivalent of the following C module,
which contains forward references in the struct initializers?

struct bar bar;
struct foo foo;

struct foo
{
  struct bar *b;
};

struct bar
{
  struct foo *f;
};

struct bar bar = {.f = &foo};
struct foo foo = {.b = &bar};

Thanks,

Marc

Am Mo., 29. Nov. 2021 um 21:04 Uhr schrieb Petter Tomner via Jit <
j...@gcc.gnu.org>:

> Hi!
>
> I have wrapped up the patch than adds support for initialization of global
> variables
> with rvalues aswell as rvalue constructors for structs, arrays and unions.
>
> New entrypoints are:
>
> gcc_jit_global_set_initializer_rvalue
>
> Which sets the initial value of a global to a rvalue.
>
> And:
>
> gcc_jit_context_new_array_constructor
> gcc_jit_context_new_struct_constructor
> gcc_jit_context_new_union_constructor
>
> Those three makes a constructor with a rvalue that e.g. can be assigned to
> a local or returned
> from a function, or most importantly used to set the initial value of
> global variables
> with gcc_jit_global_set_initializer_rvalue.
>
> If no fields are specified for a struct or union to the constructors,
> definition order is assumed.
>
> There can be gaps in the fields specified to the struct constructor, but
> they need to be in order.
>
> For pointer arithmetic to work with setting DECL_INITIAL, alot of folding
> is added.
>
> make check-jit runs fine on gnu-linux-x64 Debian.
>
> Regards,

Re: [PATCH] Replace gnu::unique_ptr with std::unique_ptr

[Jakub Jelinek via Gcc-patches]

On Tue, Nov 09, 2021 at 05:51:27PM +, Jonathan Wakely via Gcc-patches wrote:
> Now that GCC is compiled as C++11 there is no need to keep the C++03
> implementation of gnu::unique_ptr.
> 
> This removes the unique-ptr.h header and replaces it with  in
> system.h, and changes the INCLUDE_UNIQUE_PTR macro to INCLUDE_MEMORY.
> Uses of gnu::unique_ptr and gnu::move can be replaced with
> std::unique_ptr and std::move. There are no uses of unique_xmalloc_ptr
> or xmalloc_deleter in GCC.
> 
> 
> Bootstrapped and tested on powerpc64le-linux. OK for trunk?
> 
> 
> 
> gcc/analyzer/ChangeLog:
> 
>   * engine.cc: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.
> 
> gcc/c-family/ChangeLog:
> 
>   * known-headers.cc: Define INCLUDE_MEMORY instead of
>   INCLUDE_UNIQUE_PTR.
>   * name-hint.h: Likewise.
>   (class name_hint): Use std::unique_ptr instead of gnu::unique_ptr.
> 
> gcc/c/ChangeLog:
> 
>   * c-decl.c: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.
>   * c-parser.c: Likewise.
> 
> gcc/cp/ChangeLog:
> 
>   * error.c: Define INCLUDE_MEMORY instead of
>   INCLUDE_UNIQUE_PTR.
>   * lex.c: Likewise.
>   * name-lookup.c: Likewise.
>   (class namespace_limit_reached): Use std::unique_ptr instead of
>   gnu::unique_ptr.
>   (suggest_alternatives_for): Use std::move instead of gnu::move.
>   (suggest_alternatives_in_other_namespaces): Likewise.
>   * parser.c: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.
> 
> gcc/ChangeLog:
> 
>   * Makefile.in: Remove unique-ptr-tests.o.
>   * selftest-run-tests.c (selftest::run_tests): Remove
>   unique_ptr_tests_cc_tests.
>   * selftest.h (unique_ptr_tests_cc_tests): Remove.
>   * system.h: Check INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR
>   and include  instead of "unique-ptr.h".
>   * unique-ptr-tests.cc: Removed.
> 
> include/ChangeLog:
> 
>   * unique-ptr.h: Removed.

LGTM.

Jakub

Re: pr103523: Check for PLUS/MINUS support

[Richard Sandiford via Gcc-patches]

Joel Hutton  writes:
> ok for backport to 11?

Yes, thanks.

Richard

[PATCH] Leverage sysroot for VxWorks

[Olivier Hainque via Gcc-patches]

Hello,

The build of a VxWorks toolchain relies a lot on system headers
and VxWorks has a few very specific features that require special
processing. For example, different sets of headers for the kernel
vs the rtp modes, which the compiler knows about by way of -mrtp
on the command line.

If we manage to avoid the need for fixincludes on recent versions
of VxWorks (>= 7), we still need to handle at least VxWorks 6.9 at
this stage.

We sort of get away with locating the correct headers at
run-time thanks to environment variables and various tests for
-mrtp in cpp specs, but getting fixincludes to work for old
configurations has always been tricky and getting a toolchain
to build with c++/libstdc++ support gets trickier with every
move to a more recent release.

sysroot_headers_suffix_spec is a pretty powerful device to help
address such issues, and this patch introduces changes that let
us get advantage of it.

The general idea is to leverage the assumption that compilations
occur with --sysroot=$VSB_DIR on vx7 or --sysroot=$WIND_BASE/target
prior to that.

For the toolchains we build, this is achieved with a few
configure options like:

  --with-sysroot
  --with-build-sysroot=${WIND_BASE}/target
  --with-specs=%{!sysroot=*:--sysroot=%:getenv(WIND_BASE /target)}

This allows simplifying the libgcc compilation flags control
and we take the opportunity to merge t-vxworks7 into t-vxworks as
the two files were differing only on the libgcc2 flags part.

This also makes sure that we don't set inhibit_libc true
during the build, which is sane since the build really relies a
lot on system headers.

Preliminary tests showed that a build from mainline sources
now actually fail if the build configuration somehow gets to
inhibit_libc=true.

I have had very good results with this for several ports on a
gcc-11 branch, for both VxWorks 6.9 and two variants of 7.2,
for both kernel and rtp modes, including with shared libs on
two targets for 7.2 (powerpc64 and x86_64).

I was also able to get a successful build of c, c++
and libstdc++ on mainline for VxWorks 6.9, with a few fixincludes
adjustments as expected.

This touches only VxWorks related items and, all in all, I
believe this robustifies the family of ports and helps avoid
build failure with mainline sources so remains applicable
to the current stage. 

Olivier

---

2021-12-09  Olivier Hainque  

gcc/
* config/t-vxworks: Clear NATIVE_SYSTEM_HEADER_DIR.
* config/vxworks.h (SYSROOT_HEADERS_SUFFIX_SPEC): Define, for
VxWorks 7 and earlier.
(VXWORKS_ADDITIONAL_CPP_SPEC): Simplify accordingly.
(STARTFILE_PREFIX_SPEC): Adjust accordingly.
* config/rs6000/vxworks.h (STARTFILE_PREFIX_SPEC): Adjust.

libgcc/
* config/t-vxworks (LIBGCC2_INCLUDES): Simplify and handle
both VxWorks7 and earlier.
* config/t-vxworks7: Remove.
* config.host: Remove special case for vxworks7.



0001-Leverage-sysroot-for-VxWorks.patch
Description: Binary data

Re: [PATCH] #undef isblank before def or decl in libstdc++ headers

[Jonathan Wakely via Gcc-patches]

On Fri, 10 Dec 2021 at 17:07, Olivier Hainque via Libstdc++
 wrote:
>
> Hello,
>
> The attached patch helps fix a build failure of libstdc++
> on some variants of VxWorks where the system headers expose
> an "isblank" macro.
>
> I understand this kind of thing normally is handled through
> fixincludes, however fixincludes on VxWorks is very tricky and
> we already have
>
>   libstdc++-v3/include/c_global/cctype:#undef isblank
>   libstdc++-v3/include/tr1/cctype:#undef isblank
>
> so the suggestion here is to simply do the same in a couple
> more places.

Both of those places already include  so I think we should just do this:

--- a/libstdc++-v3/include/c_global/cctype
+++ b/libstdc++-v3/include/c_global/cctype
@@ -78,10 +78,10 @@ namespace std

#if __cplusplus >= 201103L

-#ifdef _GLIBCXX_USE_C99_CTYPE_TR1
-
#undef isblank

+#ifdef _GLIBCXX_USE_C99_CTYPE_TR1
+
namespace std
{
  using ::isblank;

I'm curious why _GLIBCXX_USE_C99_CTYPE_TR1 is not defined if VxWorks
has isblank, the configure check is:

  # Check for the existence of  functions.
  AC_CACHE_CHECK([for ISO C99 support to TR1 in ],
  glibcxx_cv_c99_ctype_tr1, [
  AC_TRY_COMPILE([#include ],
 [int ch;
  int ret;
  ret = isblank(ch);
 ],[glibcxx_cv_c99_ctype_tr1=yes],
   [glibcxx_cv_c99_ctype_tr1=no])
  ])
  if test x"$glibcxx_cv_c99_ctype_tr1" = x"yes"; then
AC_DEFINE(_GLIBCXX_USE_C99_CTYPE_TR1, 1,
  [Define if C99 functions in  should be imported in
   in namespace std::tr1.])
  fi

In any case, undef'ing it unconditionally in  should work, and
avoids having to do it in multiple places (we still need it in
 because that is used in C++98 code, whereas the other
definitions of functions called "isblank" were added for C++11).

Re: [committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

[Jonathan Wakely via Gcc-patches]

On Fri, 10 Dec 2021 at 17:17, Jakub Jelinek wrote:
>
> On Fri, Dec 10, 2021 at 10:11:04AM -0700, Martin Sebor via Gcc-patches wrote:
> > On 12/10/21 9:41 AM, Jakub Jelinek wrote:
> > > On Fri, Dec 10, 2021 at 09:35:50AM -0700, Martin Sebor via Gcc-patches 
> > > wrote:
> > > > The above was just a quick proof of concept experiment.  You're
> > > > of course right that the final solution can't be so crude(*).
> > > > But if the required functions are always_inline (I think member
> > > > functions defined in the body of the class implicitly are
> > >
> > > They are not, and can't be, nothing says that such member functions
> > > can't use constructs that make it uninlinable (with always_inline
> > > that would be an error), or are way too large that inlining is not
> > > desirable, etc.  They are just implicitly inline.
> >
> > The functions we're talking about are the trivial max_size()
> > members of std::string and allocator traits.  They just return
> > a constant.
> >
> > But I see I was wrong, even member functions have to be explicitly
> > declared always_inline to be guaranteed to be inlined even at -O0.
> > I don't think that should be an issue for the trivial max_size()
> > (at least not for the std::string specialization).
>
> Note, if those functions are declared constexpr, without -fno-inline
> (default at -O0), then cp_fold will try to evaluate such calls to constant
> expressions already, effectively "inlining" them.

Every member function of std::string is constexpr in C++20, but not
before. But we could add constexpr to internal _M_xxx functions if
that benefits optimization.

For std::basic_string::max_size() it has to call another function
provided by the allocator, but for the std::string (i.e.
std::basic_string, allocator>)
specialization we know what the allocator is going to tell us.

--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -1071,7 +1071,12 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
  _GLIBCXX20_CONSTEXPR
  size_type
  max_size() const _GLIBCXX_NOEXCEPT
-  { return (_Alloc_traits::max_size(_M_get_allocator()) - 1) / 2; }
+  {
+   if _GLIBCXX17_CONSTEXPR (__are_same>)
+ return size_t(-1) / 2;
+   else
+ return (_Alloc_traits::max_size(_M_get_allocator()) - 1) / 2;
+  }

  /**
   *  @brief  Resizes the %string to the specified number of characters.

Re: [committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

[Jonathan Wakely via Gcc-patches]

On Fri, 10 Dec 2021 at 16:35, Martin Sebor  wrote:
>
> On 12/10/21 3:12 AM, Jonathan Wakely wrote:
> > On Fri, 10 Dec 2021 at 01:50, Martin Sebor via Libstdc++
> >  wrote:
> >>
> >> On 12/9/21 5:38 PM, Martin Sebor wrote:
> >>> On 12/9/21 4:24 PM, Jonathan Wakely via Gcc-patches wrote:
>  These warnings are triggered by perfectly valid code using std::string.
>  They're particularly bad when --enable-fully-dynamic-string is used,
>  because even std::string().begin() will give a warning.
> 
>  Use pragmas to stop the troublesome warnings for copies done by
>  std::char_traits.
> >>>
> >>> I'm still experimenting with some of the approaches we discussed
> >>> last week, but based on my findings so far this was going to be
> >>> my suggestion at lest for now, until or unless the problem turns
> >>> out to affect more code than just std::string.
> >>
> >> Just minutes after I wrote this I tried following the clue
> >> in the note printed for the test case from PR 103534 with
> >> an enhancement I'm experimenting with:
> >>
> >> /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:426:56:
> >> warning: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’
> >> specified size between 18446744073709551600 and 18446744073709551615
> >> exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
> >> 426 | return static_cast(__builtin_memcpy(__s1,
> >> __s2, __n));
> >> |
> >> ^
> >> /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:426:56:
> >> note: when
> >> ‘(.std::__cxx11::basic_string::_M_string_length >
> >> 18446744073709551599)’
> >>
> >> and adding an assert to string::size():
> >>
> >> constexpr
> >> size_type
> >> size() const noexcept
> >> {
> >>   if (_M_string_length >= -1LU >> 1)
> >
> > I think that will be wrong for 64-bit Windows, where long is 32-bit,
> > but the string's max size is closer to -1LLU >> 2, and we don't want
> > to just use -1LLU because that's wrong for 32-bit targets.
> >
> > Technically the max size is (N - 1)/2 where N is the allocator's max
> > size, which is PTRDIFF_MAX for std::allocator, SIZE_MAX for allocators
> > that use the default value from std::allocator_traits, or some other
> > value that the allocator defines. And the value is reduced
> > appropriately if sizeof(char_type) > 1.
> >
> > But if we call this->max_size() which calls _Alloc_traits::max_size()
> > which potentially calls allocator_type::max_size(), will the compiler
> > actually make those calls to mark the path unreachable, or will it
> > just ignore the unreachable if it can't fold all those calls at
> > compile time?
>
> The above was just a quick proof of concept experiment.  You're
> of course right that the final solution can't be so crude(*).
> But if the required functions are always_inline (I think member
> functions defined in the body of the class implicitly are) then

They're implicitly inline, but not implicitly always_inline.

> I'd expect them to be folded at compile time at all optimization
> levels.  That's what makes -Winvalid-memory-order work in C++
> even at -O0 in the patch I posted earlier this week.
>
> If I still remember my C++-library-fu, even though the standard
> requires containers to call max_size() etc., since std::string
> is (or can be) an explicit specialization, there shouldn't be
> a way for a conforming program to find out if it does, so it
> could take shortcuts.  That makes me wonder if it could even
> call malloc instead of operator new to get around the problem
> with the operator's replaceability.

std::string is required to use std::allocator and users can't
specialize that to observe its allocations, but it does require:

The storage for the array is obtained by calling ::operator new
(17.6.3), but it is unspecified when or how often this function is
called.

Users can certainly observe whether std::string *never* calls their
replaced operator new (and if they've replaced it specifically to
ensure allocations use their own source, and not malloc, they wouldn't
be happy).

[pushed] c++: Add test for C++23 auto(x)

[Marek Polacek via Gcc-patches]

I was curious if our auto(x) works in contexts like bit-field width
and similar.  It appears that it does.  Might be worth adding a test
for it.

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

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/auto-fncast10.C: New test.
---
 gcc/testsuite/g++.dg/cpp23/auto-fncast10.C | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp23/auto-fncast10.C

diff --git a/gcc/testsuite/g++.dg/cpp23/auto-fncast10.C 
b/gcc/testsuite/g++.dg/cpp23/auto-fncast10.C
new file mode 100644
index 000..29c779b2cb4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp23/auto-fncast10.C
@@ -0,0 +1,18 @@
+// { dg-do compile { target c++23 } }
+
+struct S {
+  int i1 : auto(12);
+  int i2 : auto{12};
+  static constexpr auto x = auto(12);
+  static constexpr auto y = auto{12};
+};
+
+struct R {
+  int i;
+};
+
+static constexpr R r1 = { auto(23) };
+static constexpr R r2 = { auto{23} };
+enum E { X = auto(12), Y = auto{1u} };
+static_assert (auto(true));
+static_assert (auto{true});

base-commit: 982a2c9b7866558039df61b0596caad57c94c8c4
-- 
2.33.1

[PATCH] PR target/32803: Add -Oz option for improved clang compatibility.

[Roger Sayle]

This patch adds support for an -Oz command line option, aggressively
optimizing for size at the expense of performance.  GCC's current -Os
provides a reasonable balance of size and performance, whereas -Oz is
probably only useful for code size benchmarks such as CSiBE.  Or so I
thought until I read in https://news.ycombinator.com/item?id=25408853
that clang's -Oz sometimes outperforms -O[23s]; I suspect modern instruction
decode stages can treat "pushq $1; popq %rax" as a short uop encoding.

Instead of introducing a new global variable, this patch simply abuses
the existing optimize_size by setting its value to 2.  The only change
in behaviour is the tweak to the i386 backend implementing the suggestion
in PR target/32803 to use a short push/pop sequence for loading small
immediate values (-128..127) on x86, matching the behaviour of LLVM.

On x86_64, the simple function:
int foo() { return 25; }

currently generates with -Os:
foo:movl$25, %eax   // 5 bytes
ret

With the proposed -Oz, it generates:
foo:pushq   $25 // 2 bytes
popq%rax// 1 byte
ret

On CSiBE, this results in a 0.94% improvement (3703513 bytes total
down to 3668516 bytes).

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check with no new failures.  Ok for mainline?


2021-12-10  Roger Sayle  

gcc/ChangeLog
PR target/32803
* common.opt (Oz): New command line option.
* lto-wrapper.c (merge_and_complain, append_compiler_options):
Treat OPT_Oz as synonymous with OPT_Os.
* optc-save-gen.awk: Increase maximum value of optimize_size to 2.
* opts.c (default_options_optimization) [OPT_Oz]: Handle OPT_Oz
just like OPT_Os, except set opt->x_optimize_size to 2.
(common_handle_option): Skip OPT_Oz just like OPT_Os.

* config/i386/i386.md (*movdi_internal): Use a push/pop sequence
for suitable SImode TYPE_IMOV moves when optimize_size > 1.
(*movsi_internal): Likewise.

gcc/testsuite/ChangeLog
PR target/32803
* gcc.target/i386/pr32803.c: New test case.


Thanks in advance,
Roger
--

diff --git a/gcc/common.opt b/gcc/common.opt
index fa0a44f..bf6aed2 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -483,6 +483,10 @@ Og
 Common Optimization
 Optimize for debugging experience rather than speed or size.
 
+Oz
+Common Optimization
+Optimize for space aggressively rather than speed.
+
 Q
 Driver
 
diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
index 54f642d..7d2b7e5 100644
--- a/gcc/lto-wrapper.c
+++ b/gcc/lto-wrapper.c
@@ -370,12 +370,14 @@ merge_and_complain (vec 
&decoded_options,
case OPT_Ofast:
case OPT_Og:
case OPT_Os:
+   case OPT_Oz:
  existing_opt = -1;
  for (j = 0; j < decoded_options.length (); ++j)
if (decoded_options[j].opt_index == OPT_O
|| decoded_options[j].opt_index == OPT_Ofast
|| decoded_options[j].opt_index == OPT_Og
-   || decoded_options[j].opt_index == OPT_Os)
+   || decoded_options[j].opt_index == OPT_Os
+   || decoded_options[j].opt_index == OPT_Oz)
  {
existing_opt = j;
break;
@@ -407,6 +409,7 @@ merge_and_complain (vec &decoded_options,
  level = MAX (level, 1);
  break;
case OPT_Os:
+   case OPT_Oz:
  level = MAX (level, 2);
  break;
default:
@@ -428,6 +431,7 @@ merge_and_complain (vec &decoded_options,
  level = MAX (level, 1);
  break;
case OPT_Os:
+   case OPT_Oz:
  level = MAX (level, 2);
  break;
default:
@@ -725,6 +729,7 @@ append_compiler_options (obstack *argv_obstack, 
vec opts)
case OPT_Ofast:
case OPT_Og:
case OPT_Os:
+   case OPT_Oz:
  break;
 
case OPT_Xassembler:
diff --git a/gcc/optc-save-gen.awk b/gcc/optc-save-gen.awk
index e363ac7..81c2db0 100644
--- a/gcc/optc-save-gen.awk
+++ b/gcc/optc-save-gen.awk
@@ -93,7 +93,7 @@ var_opt_char[1] = "optimize_size";
 var_opt_char[2] = "optimize_debug";
 var_opt_char[3] = "optimize_fast";
 var_opt_range["optimize"] = "0, 255";
-var_opt_range["optimize_size"] = "0, 1";
+var_opt_range["optimize_size"] = "0, 2";
 var_opt_range["optimize_debug"] = "0, 1";
 var_opt_range["optimize_fast"] = "0, 1";
 
diff --git a/gcc/opts.c b/gcc/opts.c
index b16497e..7fba3d7a 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -745,6 +745,15 @@ default_options_optimization (struct gcc_options *opts,
  opts->x_optimize_debug = 0;
  break;
 
+   case OPT_Oz:
+ opts->x_optimize_size = 2;
+
+ /* Optimizing for size forces optimize to be 2.  */
+ opts->x_optimize = 2;
+ opts->x_optimize_fast = 0;
+ opts->x_optimize_debug = 

[PATCH 7/7] openmp: Add testcases for metadirectives

[Kwok Cheung Yeung]

This adds testcases for metadirectives.

KwokFrom d3f80b603298fb2f3501a28b888acfdbc02a64e7 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung 
Date: Tue, 7 Dec 2021 11:25:33 +
Subject: [PATCH 7/7] openmp: Add testcases for metadirectives

2021-12-10  Kwok Cheung Yeung  

gcc/testsuite/
* c-c++-common/gomp/metadirective-1.c: New.
* c-c++-common/gomp/metadirective-2.c: New.
* c-c++-common/gomp/metadirective-3.c: New.
* c-c++-common/gomp/metadirective-4.c: New.
* c-c++-common/gomp/metadirective-5.c: New.
* c-c++-common/gomp/metadirective-6.c: New.
* gcc.dg/gomp/metadirective-1.c: New.
* gfortran.dg/gomp/metadirective-1.f90: New.
* gfortran.dg/gomp/metadirective-2.f90: New.
* gfortran.dg/gomp/metadirective-3.f90: New.
* gfortran.dg/gomp/metadirective-4.f90: New.
* gfortran.dg/gomp/metadirective-5.f90: New.
* gfortran.dg/gomp/metadirective-6.f90: New.

libgomp/
* testsuite/libgomp.c-c++-common/metadirective-1.c: New.
* testsuite/libgomp.c-c++-common/metadirective-2.c: New.
* testsuite/libgomp.c-c++-common/metadirective-3.c: New.
* testsuite/libgomp.c-c++-common/metadirective-4.c: New.
* testsuite/libgomp.fortran/metadirective-1.f90: New.
* testsuite/libgomp.fortran/metadirective-2.f90: New.
* testsuite/libgomp.fortran/metadirective-3.f90: New.
* testsuite/libgomp.fortran/metadirective-4.f90: New.
---
 .../c-c++-common/gomp/metadirective-1.c   | 29 
 .../c-c++-common/gomp/metadirective-2.c   | 74 +++
 .../c-c++-common/gomp/metadirective-3.c   | 31 
 .../c-c++-common/gomp/metadirective-4.c   | 40 ++
 .../c-c++-common/gomp/metadirective-5.c   | 24 ++
 .../c-c++-common/gomp/metadirective-6.c   | 31 
 gcc/testsuite/gcc.dg/gomp/metadirective-1.c   | 15 
 .../gfortran.dg/gomp/metadirective-1.f90  | 41 ++
 .../gfortran.dg/gomp/metadirective-2.f90  | 59 +++
 .../gfortran.dg/gomp/metadirective-3.f90  | 34 +
 .../gfortran.dg/gomp/metadirective-4.f90  | 39 ++
 .../gfortran.dg/gomp/metadirective-5.f90  | 30 
 .../gfortran.dg/gomp/metadirective-6.f90  | 31 
 .../libgomp.c-c++-common/metadirective-1.c| 35 +
 .../libgomp.c-c++-common/metadirective-2.c| 41 ++
 .../libgomp.c-c++-common/metadirective-3.c| 34 +
 .../libgomp.c-c++-common/metadirective-4.c| 52 +
 .../libgomp.fortran/metadirective-1.f90   | 33 +
 .../libgomp.fortran/metadirective-2.f90   | 40 ++
 .../libgomp.fortran/metadirective-3.f90   | 29 
 .../libgomp.fortran/metadirective-4.f90   | 46 
 21 files changed, 788 insertions(+)
 create mode 100644 gcc/testsuite/c-c++-common/gomp/metadirective-1.c
 create mode 100644 gcc/testsuite/c-c++-common/gomp/metadirective-2.c
 create mode 100644 gcc/testsuite/c-c++-common/gomp/metadirective-3.c
 create mode 100644 gcc/testsuite/c-c++-common/gomp/metadirective-4.c
 create mode 100644 gcc/testsuite/c-c++-common/gomp/metadirective-5.c
 create mode 100644 gcc/testsuite/c-c++-common/gomp/metadirective-6.c
 create mode 100644 gcc/testsuite/gcc.dg/gomp/metadirective-1.c
 create mode 100644 gcc/testsuite/gfortran.dg/gomp/metadirective-1.f90
 create mode 100644 gcc/testsuite/gfortran.dg/gomp/metadirective-2.f90
 create mode 100644 gcc/testsuite/gfortran.dg/gomp/metadirective-3.f90
 create mode 100644 gcc/testsuite/gfortran.dg/gomp/metadirective-4.f90
 create mode 100644 gcc/testsuite/gfortran.dg/gomp/metadirective-5.f90
 create mode 100644 gcc/testsuite/gfortran.dg/gomp/metadirective-6.f90
 create mode 100644 libgomp/testsuite/libgomp.c-c++-common/metadirective-1.c
 create mode 100644 libgomp/testsuite/libgomp.c-c++-common/metadirective-2.c
 create mode 100644 libgomp/testsuite/libgomp.c-c++-common/metadirective-3.c
 create mode 100644 libgomp/testsuite/libgomp.c-c++-common/metadirective-4.c
 create mode 100644 libgomp/testsuite/libgomp.fortran/metadirective-1.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/metadirective-2.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/metadirective-3.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/metadirective-4.f90

diff --git a/gcc/testsuite/c-c++-common/gomp/metadirective-1.c 
b/gcc/testsuite/c-c++-common/gomp/metadirective-1.c
new file mode 100644
index 000..72cf0abbbd7
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/gomp/metadirective-1.c
@@ -0,0 +1,29 @@
+/* { dg-do compile } */
+
+#define N 100
+
+void f (int a[], int b[], int c[])
+{
+  #pragma omp metadirective \
+  default (teams loop) \
+  default (parallel loop) /* { dg-error "there can only be one default 
clause in a metadirective before '\\(' token" } */
+for (i = 0; i < N; i++) c[i] = a[i] * b[i];
+
+  #pragma omp metadirective \
+  default (ba

[PATCH 6/7] openmp, fortran: Add Fortran support for parsing metadirectives

[Kwok Cheung Yeung]

This patch implements metadirective parsing in the Fortran frontend.

The code previously used to process context selectors in 'declare 
variant' is refactored so that it can be reused in metadirectives. The 
big case lists in parse_executable are moved into macros, since 
parse_omp_metadirective_body needs to know how to act depending on the 
type of directive variant. The selection of end statements in 
parse_omp_do and parse_omp_structured_block are also delegated to 
gfc_omp_end_stmt.


Labels in directive variant bodies are handled by assigning a unique 
number to each statement body parsed in a metadirective, and adding this 
number as a field to gfc_st_label, such that labels with identical 
numbers but different region ids are considered different.


I have also reverted my previous changes to the TREE_STRING_LENGTH check 
in omp_check_context_selector and omp_context_name_list_prop. This is 
because in the accel compiler, lang_GNU_Fortran returns 0 even when the 
code is in Fortran, resulting in the selector failing to match. Instead, 
I opted to increment the TREE_STRING_LENGTH when it is created in 
gfc_trans_omp_set_selector - this should be safe as it is an internal 
implementation detail not visible to end users.


KwokFrom eed8a06fca397edd5fb451f08c8b1a6f7d67951a Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung 
Date: Mon, 6 Dec 2021 22:59:36 +
Subject: [PATCH 6/7] openmp, fortran: Add Fortran support for parsing
 metadirectives

This adds support for parsing OpenMP metadirectives in the Fortran front end.

2021-12-10  Kwok Cheung Yeung  

gcc/
* omp-general.c (omp_check_context_selector): Revert string length
check.
(omp_context_name_list_prop): Likewise.

gcc/fortran/
* decl.c (gfc_match_end): Handle COMP_OMP_METADIRECTIVE and
COMP_OMP_BEGIN_METADIRECTIVE.
* dump-parse-tree.c (show_omp_node): Handle EXEC_OMP_METADIRECTIVE.
(show_code_node): Handle EXEC_OMP_METADIRECTIVE.
* gfortran.h (enum gfc_statement): Add ST_OMP_METADIRECTIVE,
ST_OMP_BEGIN_METADIRECTIVE and ST_OMP_END_METADIRECTIVE.
(struct gfc_omp_metadirective_clause): New structure.
(gfc_get_omp_metadirective_clause): New macro.
(struct gfc_st_label): Add omp_region field.
(enum gfc_exec_op): Add EXEC_OMP_METADIRECTIVE.
(struct gfc_code): Add omp_metadirective_clauses field.
(gfc_free_omp_metadirective_clauses): New prototype.
(match_omp_directive): New prototype.
* io.c (format_asterisk): Initialize omp_region field.
* match.h (gfc_match_omp_begin_metadirective): New prototype.
(gfc_match_omp_metadirective): New prototype.
* openmp.c (gfc_match_omp_eos): Match ')' in context selectors.
(gfc_free_omp_metadirective_clauses): New.
(gfc_match_omp_clauses): Remove context_selector argument.  Rely on
gfc_match_omp_eos to match end of clauses.
(match_omp): Remove extra argument to gfc_match_omp_clauses.
(gfc_match_omp_context_selector): Remove extra argument to
gfc_match_omp_clauses.  Set gfc_matching_omp_context_selector
before call to gfc_match_omp_clauses and reset after.
(gfc_match_omp_context_selector_specification): Modify to take a
gfc_omp_set_selector** argument.
(gfc_match_omp_declare_variant): Pass set_selectors to
gfc_match_omp_context_selector_specification.
(match_omp_metadirective): New.
(gfc_match_omp_begin_metadirective): New.
(gfc_match_omp_metadirective): New.
(resolve_omp_metadirective): New.
(gfc_resolve_omp_directive): Handle EXEC_OMP_METADIRECTIVE.
* parse.c (gfc_matching_omp_context_selector): New variable.
(gfc_in_metadirective_body): New variable.
(gfc_omp_region_count): New variable.
(decode_omp_directive): Match 'begin metadirective',
'end metadirective' and 'metadirective'.
(match_omp_directive): New.
(case_omp_structured_block): New.
(case_omp_do): New.
(gfc_ascii_statement): Handle metadirective statements.
(gfc_omp_end_stmt): New.
(parse_omp_do): Delegate to gfc_omp_end_stmt.
(parse_omp_structured_block): Delegate to gfc_omp_end_stmt. Handle
ST_OMP_END_METADIRECTIVE.
(parse_omp_metadirective_body): New.
(parse_executable): Delegate to case_omp_structured_block and
case_omp_do.  Return after one statement if compiling regular
metadirective.  Handle metadirective statements.
(gfc_parse_file): Reset gfc_omp_region_count,
gfc_in_metadirective_body and gfc_matching_omp_context_selector.
* parse.h (enum gfc_compile_state): Add COMP_OMP_METADIRECTIVE and
COMP_OMP_BEGIN_METADIRECTIVE.
(gfc_omp_end_stmt): New prototype.
(gfc_matching_omp_context_selector): New declaration.
(gfc_in_metadirective_body): New declaration.
   

[PATCH 5/7] openmp: Add C++ support for parsing metadirectives

[Kwok Cheung Yeung]

This patch adds metadirective parsing support to the C++ parser. This is 
basically just a straight port of the C code to the C++ front end.


KwokFrom e9bb138d4c3f560e48e408facce2361533685a98 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung 
Date: Mon, 6 Dec 2021 22:58:01 +
Subject: [PATCH 5/7] openmp: Add C++ support for parsing metadirectives

This adds support for parsing OpenMP metadirectives in the C++ front end.

2021-12-10  Kwok Cheung Yeung  

gcc/cp/
* parser.c (cp_parser_skip_to_end_of_statement): Handle parentheses.
(cp_parser_skip_to_end_of_block_or_statement): Likewise.
(cp_parser_omp_context_selector): Add extra argument.  Allow
non-constant expressions.
(cp_parser_omp_context_selector_specification): Add extra argument and
propagate to cp_parser_omp_context_selector.
(analyze_metadirective_body): New.
(cp_parser_omp_metadirective): New.
(cp_parser_omp_construct): Handle PRAGMA_OMP_METADIRECTIVE.
(cp_parser_pragma): Handle PRAGMA_OMP_METADIRECTIVE.
---
 gcc/cp/parser.c | 425 +++-
 1 file changed, 417 insertions(+), 8 deletions(-)

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 6f273bfe21f..afbfe148949 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -3907,6 +3907,17 @@ cp_parser_skip_to_end_of_statement (cp_parser* parser)
  ++nesting_depth;
  break;
 
+   case CPP_OPEN_PAREN:
+ /* Track parentheses in case the statement is a standalone 'for'
+statement - we want to skip over the semicolons separating the
+operands.  */
+ ++nesting_depth;
+ break;
+
+   case CPP_CLOSE_PAREN:
+ --nesting_depth;
+ break;
+
case CPP_KEYWORD:
  if (token->keyword != RID__EXPORT
  && token->keyword != RID__MODULE
@@ -3996,6 +4007,17 @@ cp_parser_skip_to_end_of_block_or_statement (cp_parser* 
parser)
  nesting_depth++;
  break;
 
+   case CPP_OPEN_PAREN:
+ /* Track parentheses in case the statement is a standalone 'for'
+statement - we want to skip over the semicolons separating the
+operands.  */
+ nesting_depth++;
+ break;
+
+   case CPP_CLOSE_PAREN:
+ nesting_depth--;
+ break;
+
case CPP_KEYWORD:
  if (token->keyword != RID__EXPORT
  && token->keyword != RID__MODULE
@@ -44972,7 +44994,8 @@ static const char *const omp_user_selectors[] = {
  score(score-expression)  */
 
 static tree
-cp_parser_omp_context_selector (cp_parser *parser, tree set, bool has_parms_p)
+cp_parser_omp_context_selector (cp_parser *parser, tree set, bool has_parms_p,
+   bool metadirective_p)
 {
   tree ret = NULL_TREE;
   do
@@ -45188,15 +45211,21 @@ cp_parser_omp_context_selector (cp_parser *parser, 
tree set, bool has_parms_p)
  while (1);
  break;
case CTX_PROPERTY_EXPR:
- t = cp_parser_constant_expression (parser);
+ /* Allow non-constant expressions in metadirectives.  */
+ t = metadirective_p
+ ? cp_parser_expression (parser)
+ : cp_parser_constant_expression (parser);
  if (t != error_mark_node)
{
  t = fold_non_dependent_expr (t);
- if (!value_dependent_expression_p (t)
- && (!INTEGRAL_TYPE_P (TREE_TYPE (t))
- || !tree_fits_shwi_p (t)))
+ if (metadirective_p && !INTEGRAL_TYPE_P (TREE_TYPE (t)))
error_at (token->location, "property must be "
- "constant integer expression");
+  "integer expression");
+ else if (!metadirective_p && !value_dependent_expression_p (t)
+   && (!INTEGRAL_TYPE_P (TREE_TYPE (t))
+   || !tree_fits_shwi_p (t)))
+   error_at (token->location, "property must be constant "
+  "integer expression");
  else
properties = tree_cons (NULL_TREE, t, properties);
}
@@ -45260,7 +45289,8 @@ cp_parser_omp_context_selector (cp_parser *parser, tree 
set, bool has_parms_p)
 
 static tree
 cp_parser_omp_context_selector_specification (cp_parser *parser,
- bool has_parms_p)
+ bool has_parms_p,
+ bool metadirective_p = false)
 {
   tree ret = NULL_TREE;
   do
@@ -45308,7 +45338,8 @@ cp_parser_omp_context_selector_specification (cp_parser 
*parser,
return error_mark_node;
 
   tree selectors
-   = cp_parser_omp_context_selector (parser, set, has_parms_p);
+   = cp_parser_omp_context_select

[PATCH 4/7] openmp: Add support for streaming metadirectives and resolving them after LTO

[Kwok Cheung Yeung]

This patch adds support for streaming the Gimple metadirective 
representation during LTO. An extra pass (also using 
omp_get_dynamic_candidates) is also added to resolve metadirectives 
after LTO, which is required for selectors that need to be resolved on 
the accel compiler.


KwokFrom 85826d05e029571fd003dd629aa04ce3e17d9c71 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung 
Date: Mon, 6 Dec 2021 22:56:07 +
Subject: [PATCH 4/7] openmp: Add support for streaming metadirectives and
 resolving them after LTO

This patch adds support for streaming metadirective Gimple statements during
LTO, and adds a metadirective expansion pass that runs after LTO.  This is
required for metadirectives with selectors that can only be resolved from
within the accel compiler.

2021-12-10  Kwok Cheung Yeung  

gcc/
* Makefile.in (OBJS): Add omp-expand-metadirective.o.
* gimple-streamer-in.c (input_gimple_stmt): Add case for
GIMPLE_OMP_METADIRECTIVE.  Handle metadirective labels.
* gimple-streamer-out.c (output_gimple_stmt): Likewise.
* omp-expand-metadirective.cc: New.
* passes.def: Add pass_omp_expand_metadirective.
* tree-pass.h (make_pass_omp_expand_metadirective): New prototype.
---
 gcc/Makefile.in |   1 +
 gcc/gimple-streamer-in.c|  10 ++
 gcc/gimple-streamer-out.c   |   6 +
 gcc/omp-expand-metadirective.cc | 191 
 gcc/passes.def  |   1 +
 gcc/tree-pass.h |   1 +
 6 files changed, 210 insertions(+)
 create mode 100644 gcc/omp-expand-metadirective.cc

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 2a0be9e66a6..34a17f36922 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1519,6 +1519,7 @@ OBJS = \
omp-oacc-kernels-decompose.o \
omp-oacc-neuter-broadcast.o \
omp-simd-clone.o \
+   omp-expand-metadirective.o \
opt-problem.o \
optabs.o \
optabs-libfuncs.o \
diff --git a/gcc/gimple-streamer-in.c b/gcc/gimple-streamer-in.c
index 1c979f438a5..b821aa3ca30 100644
--- a/gcc/gimple-streamer-in.c
+++ b/gcc/gimple-streamer-in.c
@@ -151,6 +151,7 @@ input_gimple_stmt (class lto_input_block *ib, class data_in 
*data_in,
 case GIMPLE_COND:
 case GIMPLE_GOTO:
 case GIMPLE_DEBUG:
+case GIMPLE_OMP_METADIRECTIVE:
   for (i = 0; i < num_ops; i++)
{
  tree *opp, op = stream_read_tree (ib, data_in);
@@ -188,6 +189,15 @@ input_gimple_stmt (class lto_input_block *ib, class 
data_in *data_in,
  else
gimple_call_set_fntype (call_stmt, stream_read_tree (ib, data_in));
}
+  if (gomp_metadirective *metadirective_stmt
+   = dyn_cast  (stmt))
+   {
+ gimple_alloc_omp_metadirective (metadirective_stmt);
+ for (i = 0; i < num_ops; i++)
+   gimple_omp_metadirective_set_label (metadirective_stmt, i,
+   stream_read_tree (ib,
+ data_in));
+   }
   break;
 
 case GIMPLE_NOP:
diff --git a/gcc/gimple-streamer-out.c b/gcc/gimple-streamer-out.c
index fcbf92300d4..c19dff74261 100644
--- a/gcc/gimple-streamer-out.c
+++ b/gcc/gimple-streamer-out.c
@@ -127,6 +127,7 @@ output_gimple_stmt (struct output_block *ob, struct 
function *fn, gimple *stmt)
 case GIMPLE_COND:
 case GIMPLE_GOTO:
 case GIMPLE_DEBUG:
+case GIMPLE_OMP_METADIRECTIVE:
   for (i = 0; i < gimple_num_ops (stmt); i++)
{
  tree op = gimple_op (stmt, i);
@@ -169,6 +170,11 @@ output_gimple_stmt (struct output_block *ob, struct 
function *fn, gimple *stmt)
  else
stream_write_tree (ob, gimple_call_fntype (stmt), true);
}
+  if (gimple_code (stmt) == GIMPLE_OMP_METADIRECTIVE)
+   for (i = 0; i < gimple_num_ops (stmt); i++)
+ stream_write_tree (ob, gimple_omp_metadirective_label (stmt, i),
+true);
+
   break;
 
 case GIMPLE_NOP:
diff --git a/gcc/omp-expand-metadirective.cc b/gcc/omp-expand-metadirective.cc
new file mode 100644
index 000..aaf048a699a
--- /dev/null
+++ b/gcc/omp-expand-metadirective.cc
@@ -0,0 +1,191 @@
+/* Expand an OpenMP metadirective.
+
+   Copyright (C) 2021 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#include 

[PATCH 3/7] openmp: Add support for resolving metadirectives during parsing and Gimplification

[Kwok Cheung Yeung]

This patch contains code to resolve metadirectives, either during 
parsing or Gimplification.


The dynamic candidate selection algorithm from the OpenMP 5.1 spec is 
implemented in omp_get_dynamic_candidates in omp-general.c, which 
returns a vector containing information on the top-scoring candidate 
variants. The vector always consists of entries with dynamic selectors 
first, followed by a single entry with an all-static selector (which can 
be the default clause if all the other clauses are dynamic). If all 
selectors are static (i.e. OpenMP 5.0), then omp_get_dynamic_candidates 
will return a vector of at most length 1.


If any part of the selectors in the candidate list cannot be resolved at 
the current stage of compilation, an empty list is returned. Note that 
it is possible to resolve metadirectives even with some selectors 
unresolvable as long as those selectors are not part of the candidate list.


omp_context_selector_matches should always return 1 for dynamic 
selectors (since we can generate code to evaluate the condition at any 
time). omp_dynamic_cond, when given a selector, should return just the 
part of it that must be evaluated at run-time.


Metadirectives are resolved in both tree and Gimple form by generating a 
sequence of if..then..else statements that evaluate the dynamic selector 
of each candidate returned from omp_get_dynamic_candidates in order, 
jumping to the directive body if true, to the next evaluation if not.


KwokFrom 65ee7342256db3c81cc6741ce2c96e36dd4a9ca6 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung 
Date: Mon, 6 Dec 2021 22:49:23 +
Subject: [PATCH 3/7] openmp: Add support for resolving metadirectives during
 parsing and Gimplification

This adds support for resolving metadirectives according to the OpenMP 5.1
specification.  The variants are sorted by score, then gathered into a list
of dynamic replacement candidates.  The metadirective is then expanded into
a sequence of 'if..else' statements to test the dynamic selector and execute
the variant if the selector is satisfied.

If any of the selectors in the list are unresolvable, GCC will give up on
resolving the metadirective and try again later.

2021-12-10  Kwok Cheung Yeung  

gcc/
* gimplify.c (expand_omp_metadirective): New.
* omp-general.c: Include tree-pretty-print.h.
(DELAY_METADIRECTIVES_AFTER_LTO): New macro.
(omp_context_selector_matches): Delay resolution of selectors.  Allow
non-constant expressions.
(omp_dynamic_cond): New.
(omp_dynamic_selector_p): New.
(sort_variant): New.
(omp_get_dynamic_candidates): New.
(omp_resolve_metadirective): New.
(omp_resolve_metadirective): New.
* omp-general.h (struct omp_metadirective_variant): New.
(omp_resolve_metadirective): New prototype.

gcc/c-family/
* c-omp.c (c_omp_expand_metadirective_r): New.
(c_omp_expand_metadirective): New.
---
 gcc/c-family/c-omp.c |  45 -
 gcc/gimplify.c   |  72 +-
 gcc/omp-general.c| 232 ++-
 gcc/omp-general.h|   7 ++
 4 files changed, 346 insertions(+), 10 deletions(-)

diff --git a/gcc/c-family/c-omp.c b/gcc/c-family/c-omp.c
index 9a7a6834f1b..fedaec566ee 100644
--- a/gcc/c-family/c-omp.c
+++ b/gcc/c-family/c-omp.c
@@ -3264,8 +3264,49 @@ c_omp_categorize_directive (const char *first, const 
char *second,
   return NULL;
 }
 
+static tree
+c_omp_expand_metadirective_r (vec 
&candidates,
+ hash_map &body_labels,
+ unsigned index)
+{
+  struct omp_metadirective_variant &candidate = candidates[index];
+  tree if_block = push_stmt_list ();
+  if (candidate.directive != NULL_TREE)
+add_stmt (candidate.directive);
+  if (candidate.body != NULL_TREE)
+{
+  tree *label = body_labels.get (candidate.body);
+  if (label != NULL)
+   add_stmt (build1 (GOTO_EXPR, void_type_node, *label));
+  else
+   {
+ tree body_label = create_artificial_label (UNKNOWN_LOCATION);
+ add_stmt (build1 (LABEL_EXPR, void_type_node, body_label));
+ add_stmt (candidate.body);
+ body_labels.put (candidate.body, body_label);
+   }
+}
+  if_block = pop_stmt_list (if_block);
+
+  if (index == candidates.length () - 1)
+return if_block;
+
+  tree cond = candidate.selector;
+  gcc_assert (cond != NULL_TREE);
+
+  tree else_block = c_omp_expand_metadirective_r (candidates, body_labels,
+ index + 1);
+  tree ret = push_stmt_list ();
+  tree stmt = build3 (COND_EXPR, void_type_node, cond, if_block, else_block);
+  add_stmt (stmt);
+  ret = pop_stmt_list (ret);
+
+  return ret;
+}
+
 tree
-c_omp_expand_metadirective (vec &)
+c_omp_expand_metadirective (vec &candidates)
 {
-  return NULL_TREE;
+  hash_map body_labels;
+  return c_omp_expand_metadirective_r (candidates, body_labels, 0);
 }
di

[PATCH 2/7] openmp: Add middle-end support for metadirectives

[Kwok Cheung Yeung]

This patch contains the required support for metadirectives in the 
middle-end.


The tree metadirective representation is gimplified into the high Gimple 
representation, which is structured like this:


#pragma omp metadirective
  when ():

goto body_label|end_label
  when (>:

goto body_label|end_label
  default:

goto body_label|end_label
body_label:
  
end_label:

Each variant ends with an explicit goto to either the shared standalone 
body (if the variant uses it) or to the point after the body (if it does 
not).


When lowered to low Gimple, the directive bodies move outside of the 
metadirective statement, retaining only the labels to the bodies, so it 
looks like this instead:


#pragma omp metadirective
  when (): goto body1_label
  when (>: goto body2_label
  default: goto default_label
body1_label:
  
  goto body_label|end_label
body2_label:
  
  goto body_label|end_label
default_label:
  
  goto body_label|end_label
body_label:
  
end_label:

When scanning the OpenMP regions in the ompexp pass, we create a 'clone' 
of the surrounding context when recursively scanning the directive 
variants. If the same outer context was used for all variants, then it 
would appear as if all the variants were inside the region at the same 
time (only one variant of the metadirective is ever active at a time), 
which can lead to spurious errors.


The rest of the code is the plumbing required to allow the Gimple 
metadirective statement to pass through the middle-end. GCC will emit an 
ICE if it makes it through to the back-end though, as the metadirective 
is supposed to be eliminated before it gets that far.


KwokFrom 1a2fcbb2191fd1dd694ea5730e54fab19d6465b4 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung 
Date: Mon, 6 Dec 2021 22:29:34 +
Subject: [PATCH 2/7] openmp: Add middle-end support for metadirectives

This adds a new Gimple statement type GIMPLE_OMP_METADIRECTIVE, which
represents the metadirective in Gimple. In high Gimple, the statement
contains the body of the directive variants, whereas in low Gimple, it
only contains labels to the bodies.

This patch adds support for converting metadirectives from tree to Gimple
form, and handling of the Gimple form (Gimple lowering, OpenMP lowering
and expansion, inlining, SSA handling etc).

Metadirectives should be resolved before they reach the back-end, otherwise
the compiler will crash as GCC does not know how to convert metadirective
Gimple statements to RTX.

2021-12-10  Kwok Cheung Yeung  

gcc/
* gimple-low.c (lower_omp_metadirective): New.
(lower_stmt): Handle GIMPLE_OMP_METADIRECTIVE.
* gimple-pretty-print.c (dump_gimple_omp_metadirective): New.
(pp_gimple_stmt_1): Handle GIMPLE_OMP_METADIRECTIVE.
* gimple-walk.c (walk_gimple_op): Handle GIMPLE_OMP_METADIRECTIVE.
(walk_gimple_stmt): Likewise.
* gimple.c (gimple_alloc_omp_metadirective): New.
(gimple_build_omp_metadirective): New.
(gimple_build_omp_metadirective_variant): New.
* gimple.def (GIMPLE_OMP_METADIRECTIVE): New.
(GIMPLE_OMP_METADIRECTIVE_VARIANT): New.
* gimple.h (gomp_metadirective_variant): New.
(gomp_metadirective): New.
(is_a_helper ::test): New.
(is_a_helper ::test): New.
(is_a_helper ::test): New.
(is_a_helper ::test): New.
(gimple_alloc_omp_metadirective): New prototype.
(gimple_build_omp_metadirective): New prototype.
(gimple_build_omp_metadirective_variant): New prototype.
(gimple_has_substatements): Add GIMPLE_OMP_METADIRECTIVE case.
(gimple_has_ops): Add GIMPLE_OMP_METADIRECTIVE.
(gimple_omp_metadirective_label): New.
(gimple_omp_metadirective_set_label): New.
(gimple_omp_metadirective_variants): New.
(gimple_omp_metadirective_set_variants): New.
(CASE_GIMPLE_OMP): Add GIMPLE_OMP_METADIRECTIVE.
* gimplify.c (is_gimple_stmt): Add OMP_METADIRECTIVE.
(expand_omp_metadirective): New.
(gimplify_omp_metadirective): New.
(gimplify_expr): Add case for OMP_METADIRECTIVE.
* gsstruct.def (GSS_OMP_METADIRECTIVE): New.
(GSS_OMP_METADIRECTIVE_VARIANT): New.
* omp-expand.c (build_omp_regions_1): Handle GIMPLE_OMP_METADIRECTIVE.
(omp_make_gimple_edges): Likewise.
* omp-low.c (struct omp_context): Add next_clone field.
(new_omp_context): Initialize next_clone field.
(clone_omp_context): New.
(delete_omp_context): Delete clone contexts.
(scan_omp_metadirective): New.
(scan_omp_1_stmt): Handle GIMPLE_OMP_METADIRECTIVE.
(lower_omp_metadirective): New.
(lower_omp_1): Handle GIMPLE_OMP_METADIRECTIVE.
* tree-cfg.c (cleanup_dead_labels): Handle GIMPLE_OMP_METADIRECTIVE.
(gimple_redirect_edge_and_branch): Likewise.
* tree-inline.c (remap_gimple_stmt): Handle GIMPLE_OMP_METADIRECTIVE.
(estimate_num_in

[PATCH 1/7] openmp: Add C support for parsing metadirectives

[Kwok Cheung Yeung]

This patch adds support for parsing metadirectives in the C parser.

Metadirectives are represented by a OMP_METADIRECTIVE tree node. It has 
a single operand (accessed by OMP_METADIRECTIVE_CLAUSES) which contains 
a chain of TREE_LIST nodes, each one representing a clause from the 
metadirective. TREE_PURPOSE(clause) contains the selector of the clause, 
while TREE_VALUE(clause) contains another TREE_LIST - the TREE_PURPOSE 
contains the tree for the directive, while the TREE_VALUE contains the 
standalone body (if any).


If an OMP directive has an associated body, it will be part of the tree 
at TREE_PURPOSE(TREE_VALUE(clause)) - the standalone body at 
TREE_VALUE(TREE_VALUE(clause) is only used for standalone directives 
that do not have an associated body (strictly speaking, it isn't a part 
of the directive variant at all). At present, all standalone bodies in a 
metadirective are shared, and will point to the same tree node.


Labels in the statement body are handled by first scanning the body for 
labels, then enclosing the statements in a lexical block with the found 
labels declared as local using __label__. This prevents labels in the 
body interfering with each other when the body is re-parsed.


I have removed support for the 'omp begin metadirective'..'omp end 
metadirective' form of the directive that was originally in the WIP 
patch. According to the spec, the only variant directives that can be 
used in this form must have an 'end ' form (apart from the 
'nothing' directive), and in C/C++, the only directive that we support 
with an end form is 'declare target', which we currently forbid since it 
is declarative.


KwokFrom dc88559b0295104472a0cbf79de03b0549bd35f5 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung 
Date: Mon, 6 Dec 2021 19:15:23 +
Subject: [PATCH 1/7] openmp: Add C support for parsing metadirectives

This patch implements parsing for the OpenMP metadirective introduced in
OpenMP 5.0.  Metadirectives are parsed into an OMP_METADIRECTIVE node,
with the variant clauses forming a chain accessible via
OMP_METADIRECTIVE_CLAUSES.  Each clause contains the context selector
and tree for the variant.

User conditions in the selector are now permitted to be non-constant when
used in metadirectives as specified in OpenMP 5.1.

2021-12-10  Kwok Cheung Yeung  

gcc/
* omp-general.c (omp_context_selector_matches): Add extra argument.
(omp_resolve_metadirective): New stub function.
* omp-general.h (struct omp_metadirective_variant): New.
(omp_context_selector_matches): Add extra argument.
(omp_resolve_metadirective): New prototype.
* tree.def (OMP_METADIRECTIVE): New.
* tree.h (OMP_METADIRECTIVE_CLAUSES): New macro.

gcc/c/
* c-parser.c (c_parser_skip_to_end_of_block_or_statement): Handle
parentheses in statement.
(c_parser_omp_metadirective): New prototype.
(c_parser_omp_context_selector): Add extra argument.  Allow
non-constant expressions.
(c_parser_omp_context_selector_specification): Add extra argument and
propagate it to c_parser_omp_context_selector.
(analyze_metadirective_body): New.
(c_parser_omp_metadirective): New.
(c_parser_omp_construct): Handle PRAGMA_OMP_METADIRECTIVE.

gcc/c-family
* c-common.h (enum c_omp_directive_kind): Add C_OMP_DIR_META.
(c_omp_expand_metadirective): New prototype.
* c-gimplify.c (genericize_omp_metadirective_stmt): New.
(c_genericize_control_stmt): Handle OMP_METADIRECTIVE tree nodes.
* c-omp.c (omp_directives): Classify metadirectives as C_OMP_DIR_META.
(c_omp_expand_metadirective): New stub function.
* c-pragma.c (omp_pragmas): Add entry for metadirective.
* c-pragma.h (enum pragma_kind): Add PRAGMA_OMP_METADIRECTIVE.
---
 gcc/c-family/c-common.h   |   4 +-
 gcc/c-family/c-gimplify.c |  25 +++
 gcc/c-family/c-omp.c  |  14 +-
 gcc/c-family/c-pragma.c   |   1 +
 gcc/c-family/c-pragma.h   |   1 +
 gcc/c/c-parser.c  | 403 +-
 gcc/omp-general.c |  14 +-
 gcc/omp-general.h |   9 +-
 gcc/tree.def  |   5 +
 gcc/tree.h|   3 +
 10 files changed, 465 insertions(+), 14 deletions(-)

diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index c089fda12e4..ef37051791f 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -1257,7 +1257,8 @@ enum c_omp_directive_kind {
   C_OMP_DIR_CONSTRUCT,
   C_OMP_DIR_DECLARATIVE,
   C_OMP_DIR_UTILITY,
-  C_OMP_DIR_INFORMATIONAL
+  C_OMP_DIR_INFORMATIONAL,
+  C_OMP_DIR_META
 };
 
 struct c_omp_directive {
@@ -1270,6 +1271,7 @@ struct c_omp_directive {
 extern const struct c_omp_directive *c_omp_categorize_directive (const char *,
 const char *,
 const char *);
+ex

[PATCH 0/7] openmp: OpenMP metadirectives support

[Kwok Cheung Yeung]

Hello

This is my current patchset for OpenMP metadirectives support. It aims 
to implement the specification from OpenMP 5.1, with dynamic selector 
support (though currently only the dynamic user selector set is 
supported), and supports the C, C++ and Fortran front ends.


The patch has been bootstrapped on a x86_64 Linux machine, and the 
testsuite run with no regressions (libgomp tested with both no 
offloading and with offloading to nvptx). Okay for inclusion in trunk?


Kwok

Re: [WIP, OpenMP] OpenMP metadirectives support

[Kwok Cheung Yeung]

Hello

It has been several months since I posted my WIP patch, and my current 
patch set (which I will post separately) has evolved considerably since 
then. I have added C++ and Fortran support, as well as dynamic selectors 
from the OpenMP 5.1 spec (currently only the 'user={condition()}' 
selector is implemented, target_device is TBD).


On 26/07/2021 3:29 pm, Jakub Jelinek wrote:

Note, there is a partial overlap with the attribute syntax changes, see below.
c-family/c-omp.c now has omp_directives table that should be updated for
changes like this and then c_omp_categorize_directive that returns some
information about the directives given a directive name (though, that name
can be one, two or three tokens long, consider e.g. target enter data
or cancellation point directives).


I have modified the C/C++ parser code to lookup the type of the 
directive using c_omp_categorize_directive.



For metadirective, I think very special case are declarative directives in
them, I'd tend to sorry for them at least for now, I'm pretty sure many
cases with them are just unimplementable and will need to be restricted in
the standard, others can be implemented with lots of effort.
Whether it is e.g. metadirective guarding declare target ... end declare
target pair that would only conditionally set declare target and instead of
a single bit to find out if something is declare target or not we'd until
resolved need to compute it for all possibilities, or e.g. conditional
declare reduction/declare mapper where the name lookup for reduction or map
directives would be dependent on metadirective resolution later on, etc.
I'm afraid a total nightmare nobody has really thought about details for it.


The parsers currently emit a sorry if a C_OMP_DIR_DECLARATIVE directive 
is encountered in a metadirective, though I am sure there are many 
remaining ways that one could break it!



As an optimisation, identical body trees could be merged together, but that
can come later.


I'm afraid it isn't just an optimization and we need to be as smart as
possible.  I'm not sure it is possible to parse everything many times,
consider e.g. labels in the blocks, nested function definitions, variable
definitions, etc.
While OpenMP requires that essentially the code must be valid if the
metadirective is replaced by any of those mentioned directives which rules
quite some weirdo corner cases, nothing prevents e.g. two or more
when directives to be standalone directives (which don't have any body and
so whatever comes after them should be left parsed for later as normal
statement sequence), one or more to be normal constructs that accept a
structured block and one or more to be e.g. looping constructs (simd, for,
distribute, taskloop or combined versions of those).
Even when issues with labels etc. are somehow solved (e.g. for structured
blocks we have the restriction that goto, break, continue, or switch into
a case/default label, etc. can't be used to enter or exit the structured
block which could mean some cases can be handled through renaming seen
labels in all but one bodies), most important is to sync on where parsing
should continue after the metadirective.
I think it would be nice if the metadirective parsing at least made quick
analysis on what kind of bodies the directives will want and can use the new
c-omp.c infrastructure or if needed extend it (e.g. separate the 
C_OMP_DIR_CONSTRUCT
category into C_OMP_DIR_CONSTRUCT and C_OMP_DIR_LOOPING_CONSTRUCT where
the latter would be used for those that expect some omp loop after it).
One option would be then to parse the body as the most restricted construct
(looping (and determine highest needed collapse and ordered), then construct,
then standalone) and be able to adjust what we parsed into what the
different constructs need, but another option is the separate parsing of
the code after the directive multiple times, but at least in the order of
most restricted to least restricted, remember where to stop and don't parse
it multiple times at least for directives that need the same thing.



After some experimentation, I'm not sure if it is possible in the 
general case to share bodies between variants. For one thing, it 
complicates the OMP region outlining and lowering, and becomes rather 
invasive to implement in the parser. Another is the possibility of 
having metadirectives nested within metadirective bodies. e.g. Something 
of the form:


#pragma omp metadirective \
when (cond1: dir1) \
when (cond2: dir2)
  {
#pragma omp metadirective \
  when (construct dir1: dirA)
  when (construct dir2: dirB)
(body)
  }

in which case the way the inner metadirective is resolved depends on the 
outer metadirective, leading to different bodies.


In my current patch set, I have implemented a limited form of statement 
body sharing when the body is not part of an OMP directive (e.g. an 'omp 
flush' followed by the body). Variables declarations and local functions 
in the b

Re: [committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

[Jakub Jelinek via Gcc-patches]

On Fri, Dec 10, 2021 at 10:11:04AM -0700, Martin Sebor via Gcc-patches wrote:
> On 12/10/21 9:41 AM, Jakub Jelinek wrote:
> > On Fri, Dec 10, 2021 at 09:35:50AM -0700, Martin Sebor via Gcc-patches 
> > wrote:
> > > The above was just a quick proof of concept experiment.  You're
> > > of course right that the final solution can't be so crude(*).
> > > But if the required functions are always_inline (I think member
> > > functions defined in the body of the class implicitly are
> > 
> > They are not, and can't be, nothing says that such member functions
> > can't use constructs that make it uninlinable (with always_inline
> > that would be an error), or are way too large that inlining is not
> > desirable, etc.  They are just implicitly inline.
> 
> The functions we're talking about are the trivial max_size()
> members of std::string and allocator traits.  They just return
> a constant.
> 
> But I see I was wrong, even member functions have to be explicitly
> declared always_inline to be guaranteed to be inlined even at -O0.
> I don't think that should be an issue for the trivial max_size()
> (at least not for the std::string specialization).

Note, if those functions are declared constexpr, without -fno-inline
(default at -O0), then cp_fold will try to evaluate such calls to constant
expressions already, effectively "inlining" them.

Jakub

Re: [committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

[Martin Sebor via Gcc-patches]

On 12/10/21 9:41 AM, Jakub Jelinek wrote:

On Fri, Dec 10, 2021 at 09:35:50AM -0700, Martin Sebor via Gcc-patches wrote:

The above was just a quick proof of concept experiment.  You're
of course right that the final solution can't be so crude(*).
But if the required functions are always_inline (I think member
functions defined in the body of the class implicitly are


They are not, and can't be, nothing says that such member functions
can't use constructs that make it uninlinable (with always_inline
that would be an error), or are way too large that inlining is not
desirable, etc.  They are just implicitly inline.


The functions we're talking about are the trivial max_size()
members of std::string and allocator traits.  They just return
a constant.

But I see I was wrong, even member functions have to be explicitly
declared always_inline to be guaranteed to be inlined even at -O0.
I don't think that should be an issue for the trivial max_size()
(at least not for the std::string specialization).

Martin

[PATCH] #undef isblank before def or decl in libstdc++ headers

[Olivier Hainque via Gcc-patches]

Hello,

The attached patch helps fix a build failure of libstdc++
on some variants of VxWorks where the system headers expose
an "isblank" macro.

I understand this kind of thing normally is handled through
fixincludes, however fixincludes on VxWorks is very tricky and
we already have

  libstdc++-v3/include/c_global/cctype:#undef isblank
  libstdc++-v3/include/tr1/cctype:#undef isblank

so the suggestion here is to simply do the same in a couple
more places.

I checked that it gets us through the observed build failure
for VxWorks, then bootstrapped and regtested on native 64bit
linux.

Ok to commit?

Thanks in advance,

With Kind Regards,

Olivier

2021-12-07  Olivier Hainque  

libstdc++-v3/

* include/bits/locale_facets.h: #undef isblank before
providing a definition.
* libstdc++-v3/include/bits/localefwd.h: Likewise.



0001-Add-undef-isblank-before-definition-or-decl-in-bits-.patch
Description: Binary data

Re: [Patch 7/8 V2] Arm: Emit build attributes for PACBTI target feature.

[Richard Earnshaw via Gcc-patches]

On 10/12/2021 16:36, Andrea Corallo via Gcc-patches wrote:

Richard Earnshaw via Gcc-patches  writes:


On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote:



-Original Message-
From: Gcc-patches  On Behalf Of Tejas Belagod via
Gcc-patches
Sent: Friday, October 8, 2021 1:19 PM
To: gcc-patches@gcc.gnu.org
Subject: [Patch 6/7, Arm, GCC] Emit build attributes for PACBTI target
feature.

Hi,

This patch emits assembler directives for PACBTI build attributes as defined
by the ABI. (https://github.com/ARM-software/abi-
aa/releases/download/2021Q1/addenda32.pdf)

Tested on arm-none-eabi.

2021-10-04  Tejas Belagod  

gcc/ChangeLog:

* config/arm/arm.c (arm_file_start): Emit EABI attributes for
Tag_PAC_extension, Tag_BTI_extension, TAG_BTI_use,
TAG_PACRET_use.

gcc/testsuite/ChangeLog:

* gcc.target/arm/acle/pacbti-m-predef-1.c: New test.
* gcc.target/arm/acle/pacbti-m-predef-3: New test.
* gcc.target/arm/acle/pacbti-m-predef-6.c: New test.

This patch emits assembler directives for PACBTI build attributes
as defined by the ABI.
https://github.com/ARM-software/abi-aa/releases/download/2021Q1/addenda32.pdf
2021-10-25  Tejas Belagod  
gcc/ChangeLog:
* config/arm/arm.c (arm_file_start): Emit EABI attributes for
Tag_PAC_extension, Tag_BTI_extension, TAG_BTI_use, TAG_PACRET_use.
gcc/testsuite/ChangeLog:
* gcc.target/arm/acle/pacbti-m-predef-1.c: New test.
* gcc.target/arm/acle/pacbti-m-predef-3: New test.
* gcc.target/arm/acle/pacbti-m-predef-6.c: New test.


I'm not sure what the value of making these executable tests is.  It
means that they can only be used when the test model has PAC/BTI
available.  But they don't really test the PAC/BTI generation, so that
seems rather pointless.

Better, IMO to make them simple compile/scan-assembler tests that
check the build attributes are correct.

R.


Hi Richard,

agreed.  Please find attached the updated version of the patch.

Thanks for reviewing

   Andrea



Oh, another one:

diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c 
b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c

new file mode 100644
index 000..bdf9131c142
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c
@@ -0,0 +1,16 @@
+#if defined (__ARM_FEATURE_BTI_DEFAULT)
+#error "Feature test macro __ARM_FEATURE_BTI_DEFAULT should be defined."
+#endif
+
+#if defined (__ARM_FEATURE_PAC_DEFAULT)
+#error "Feature test macro __ARM_FEATURE_PAC_DEFAULT should be undefined."
+#endif

Shouldn't the first error message be 'undefined'?

Re: [Patch 7/8 V2] Arm: Emit build attributes for PACBTI target feature.

[Richard Earnshaw via Gcc-patches]

On 10/12/2021 16:36, Andrea Corallo via Gcc-patches wrote:

Richard Earnshaw via Gcc-patches  writes:


On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote:



-Original Message-
From: Gcc-patches  On Behalf Of Tejas Belagod via
Gcc-patches
Sent: Friday, October 8, 2021 1:19 PM
To: gcc-patches@gcc.gnu.org
Subject: [Patch 6/7, Arm, GCC] Emit build attributes for PACBTI target
feature.

Hi,

This patch emits assembler directives for PACBTI build attributes as defined
by the ABI. (https://github.com/ARM-software/abi-
aa/releases/download/2021Q1/addenda32.pdf)

Tested on arm-none-eabi.

2021-10-04  Tejas Belagod  

gcc/ChangeLog:

* config/arm/arm.c (arm_file_start): Emit EABI attributes for
Tag_PAC_extension, Tag_BTI_extension, TAG_BTI_use,
TAG_PACRET_use.

gcc/testsuite/ChangeLog:

* gcc.target/arm/acle/pacbti-m-predef-1.c: New test.
* gcc.target/arm/acle/pacbti-m-predef-3: New test.
* gcc.target/arm/acle/pacbti-m-predef-6.c: New test.

This patch emits assembler directives for PACBTI build attributes
as defined by the ABI.
https://github.com/ARM-software/abi-aa/releases/download/2021Q1/addenda32.pdf
2021-10-25  Tejas Belagod  
gcc/ChangeLog:
* config/arm/arm.c (arm_file_start): Emit EABI attributes for
Tag_PAC_extension, Tag_BTI_extension, TAG_BTI_use, TAG_PACRET_use.
gcc/testsuite/ChangeLog:
* gcc.target/arm/acle/pacbti-m-predef-1.c: New test.
* gcc.target/arm/acle/pacbti-m-predef-3: New test.
* gcc.target/arm/acle/pacbti-m-predef-6.c: New test.


I'm not sure what the value of making these executable tests is.  It
means that they can only be used when the test model has PAC/BTI
available.  But they don't really test the PAC/BTI generation, so that
seems rather pointless.

Better, IMO to make them simple compile/scan-assembler tests that
check the build attributes are correct.

R.


Hi Richard,

agreed.  Please find attached the updated version of the patch.

Thanks for reviewing

   Andrea



Sorry, I've just been looking at this again and noted the following:

+  if (TARGET_HAVE_PACBTI)
+   {
+ arm_emit_eabi_attribute ("Tag_PAC_extension", 50, 2);
+ arm_emit_eabi_attribute ("Tag_BTI_extension", 52, 2);
+ arm_emit_eabi_attribute ("TAG_BTI_use", 74, bti);
+ arm_emit_eabi_attribute ("TAG_PACRET_use", 76, pac);
+   }
+  else
+   {
+ if (pac || bti)
+   {
+ arm_emit_eabi_attribute ("Tag_PAC_extension", 50, 1);
+ arm_emit_eabi_attribute ("Tag_BTI_extension", 52, 1);
+ arm_emit_eabi_attribute ("TAG_BTI_use", 74, bti);
+ arm_emit_eabi_attribute ("TAG_PACRET_use", 76, pac);
+   }
+   }
+

Firstly, the if subclause inside the else can be lifted out to an 'else 
if'; secondly, we don't want to emit TAG_BTI_use or TAG_PACRET_use if 
the value is zero (since the default in the absence of the tag is zero). 
 So better to have this as:


  if (TARGET_HAVE_PACBTI)
{
  arm_emit_eabi_attribute ("Tag_PAC_extension", 50, 2);
  arm_emit_eabi_attribute ("Tag_BTI_extension", 52, 2);
}
  else if (pac || bti)
{
  arm_emit_eabi_attribute ("Tag_PAC_extension", 50, 1);
  arm_emit_eabi_attribute ("Tag_BTI_extension", 52, 1);
}

  if (bti)
arm_emit_eabi_attribute ("TAG_BTI_use", 74, 1);
  if (pac)
arm_emit_eabi_attribute ("TAG_PACRET_use", 76, 1);

And then adjust the tests for the zero case to use scan-assembler-not.

R.

Re: [committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

[Jakub Jelinek via Gcc-patches]

On Fri, Dec 10, 2021 at 09:35:50AM -0700, Martin Sebor via Gcc-patches wrote:
> The above was just a quick proof of concept experiment.  You're
> of course right that the final solution can't be so crude(*).
> But if the required functions are always_inline (I think member
> functions defined in the body of the class implicitly are

They are not, and can't be, nothing says that such member functions
can't use constructs that make it uninlinable (with always_inline
that would be an error), or are way too large that inlining is not
desirable, etc.  They are just implicitly inline.

Jakub

Re: [Patch 7/8 V2] Arm: Emit build attributes for PACBTI target feature.

[Andrea Corallo via Gcc-patches]

Richard Earnshaw via Gcc-patches  writes:

> On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote:
>> 
>>> -Original Message-
>>> From: Gcc-patches >> bounces+belagod=gcc.gnu@gcc.gnu.org> On Behalf Of Tejas Belagod via
>>> Gcc-patches
>>> Sent: Friday, October 8, 2021 1:19 PM
>>> To: gcc-patches@gcc.gnu.org
>>> Subject: [Patch 6/7, Arm, GCC] Emit build attributes for PACBTI target
>>> feature.
>>>
>>> Hi,
>>>
>>> This patch emits assembler directives for PACBTI build attributes as defined
>>> by the ABI. (https://github.com/ARM-software/abi-
>>> aa/releases/download/2021Q1/addenda32.pdf)
>>>
>>> Tested on arm-none-eabi.
>>>
>>> 2021-10-04  Tejas Belagod  
>>>
>>> gcc/ChangeLog:
>>>
>>> * config/arm/arm.c (arm_file_start): Emit EABI attributes for
>>> Tag_PAC_extension, Tag_BTI_extension, TAG_BTI_use,
>>> TAG_PACRET_use.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> * gcc.target/arm/acle/pacbti-m-predef-1.c: New test.
>>> * gcc.target/arm/acle/pacbti-m-predef-3: New test.
>>> * gcc.target/arm/acle/pacbti-m-predef-6.c: New test.
>> This patch emits assembler directives for PACBTI build attributes
>> as defined by the ABI.
>> https://github.com/ARM-software/abi-aa/releases/download/2021Q1/addenda32.pdf
>> 2021-10-25  Tejas Belagod  
>> gcc/ChangeLog:
>>  * config/arm/arm.c (arm_file_start): Emit EABI attributes for
>>  Tag_PAC_extension, Tag_BTI_extension, TAG_BTI_use, TAG_PACRET_use.
>> gcc/testsuite/ChangeLog:
>>  * gcc.target/arm/acle/pacbti-m-predef-1.c: New test.
>>  * gcc.target/arm/acle/pacbti-m-predef-3: New test.
>>  * gcc.target/arm/acle/pacbti-m-predef-6.c: New test.
>
> I'm not sure what the value of making these executable tests is.  It
> means that they can only be used when the test model has PAC/BTI
> available.  But they don't really test the PAC/BTI generation, so that
> seems rather pointless.
>
> Better, IMO to make them simple compile/scan-assembler tests that
> check the build attributes are correct.
>
> R.

Hi Richard,

agreed.  Please find attached the updated version of the patch.

Thanks for reviewing

  Andrea

>From 6e54ecc3e20a3af8f72a38e55f086a33490353a0 Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Mon, 6 Dec 2021 11:42:24 +0100
Subject: [PATCH] Emit build attributes for PACBTI target feature.

gcc/ChangeLog:

* config/arm/arm.c (arm_file_start): Emit EABI attributes for
Tag_PAC_extension, Tag_BTI_extension, TAG_BTI_use, TAG_PACRET_use.

gcc/testsuite/ChangeLog:

* gcc.target/arm/acle/pacbti-m-predef-1.c: New test.
* gcc.target/arm/acle/pacbti-m-predef-3: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-6.c: Likewise.
* gcc.target/arm/acle/pacbti-m-predef-7.c: Likewise.

Co-Authored-By: Tejas Belagod  
---
 gcc/config/arm/arm.c  | 20 +++
 .../gcc.target/arm/acle/pacbti-m-predef-1.c   | 16 +++
 .../gcc.target/arm/acle/pacbti-m-predef-3.c   | 16 +++
 .../gcc.target/arm/acle/pacbti-m-predef-6.c   | 15 ++
 .../gcc.target/arm/acle/pacbti-m-predef-7.c   | 16 +++
 5 files changed, 83 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-1.c
 create mode 100644 gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-3.c
 create mode 100644 gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-6.c
 create mode 100644 gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-7.c

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index ee22acddee5..a493523fe30 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -28221,6 +28221,8 @@ static void
 arm_file_start (void)
 {
   int val;
+  bool pac = (aarch_ra_sign_scope != AARCH_FUNCTION_NONE);
+  bool bti = (aarch_enable_bti == 1);
 
   arm_print_asm_arch_directives
 (asm_out_file, TREE_TARGET_OPTION (target_option_default_node));
@@ -28291,6 +28293,24 @@ arm_file_start (void)
arm_emit_eabi_attribute ("Tag_ABI_FP_16bit_format", 38,
 (int) arm_fp16_format);
 
+  if (TARGET_HAVE_PACBTI)
+   {
+ arm_emit_eabi_attribute ("Tag_PAC_extension", 50, 2);
+ arm_emit_eabi_attribute ("Tag_BTI_extension", 52, 2);
+ arm_emit_eabi_attribute ("TAG_BTI_use", 74, bti);
+ arm_emit_eabi_attribute ("TAG_PACRET_use", 76, pac);
+   }
+  else
+   {
+ if (pac || bti)
+   {
+ arm_emit_eabi_attribute ("Tag_PAC_extension", 50, 1);
+ arm_emit_eabi_attribute ("Tag_BTI_extension", 52, 1);
+ arm_emit_eabi_attribute ("TAG_BTI_use", 74, bti);
+ arm_emit_eabi_attribute ("TAG_PACRET_use", 76, pac);
+   }
+   }
+
   if (arm_lang_output_object_attributes_hook)
arm_lang_output_object_attributes_hook();
 }
diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-1.c 
b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-1.c
new file mode 100644
index 000..75d3e00ef64
---

Re: [committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

[Martin Sebor via Gcc-patches]

On 12/10/21 3:12 AM, Jonathan Wakely wrote:

On Fri, 10 Dec 2021 at 01:50, Martin Sebor via Libstdc++
 wrote:


On 12/9/21 5:38 PM, Martin Sebor wrote:

On 12/9/21 4:24 PM, Jonathan Wakely via Gcc-patches wrote:

These warnings are triggered by perfectly valid code using std::string.
They're particularly bad when --enable-fully-dynamic-string is used,
because even std::string().begin() will give a warning.

Use pragmas to stop the troublesome warnings for copies done by
std::char_traits.


I'm still experimenting with some of the approaches we discussed
last week, but based on my findings so far this was going to be
my suggestion at lest for now, until or unless the problem turns
out to affect more code than just std::string.


Just minutes after I wrote this I tried following the clue
in the note printed for the test case from PR 103534 with
an enhancement I'm experimenting with:

/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:426:56:
warning: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’
specified size between 18446744073709551600 and 18446744073709551615
exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
426 | return static_cast(__builtin_memcpy(__s1,
__s2, __n));
|
^
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:426:56:
note: when
‘(.std::__cxx11::basic_string::_M_string_length >
18446744073709551599)’

and adding an assert to string::size():

constexpr
size_type
size() const noexcept
{
  if (_M_string_length >= -1LU >> 1)


I think that will be wrong for 64-bit Windows, where long is 32-bit,
but the string's max size is closer to -1LLU >> 2, and we don't want
to just use -1LLU because that's wrong for 32-bit targets.

Technically the max size is (N - 1)/2 where N is the allocator's max
size, which is PTRDIFF_MAX for std::allocator, SIZE_MAX for allocators
that use the default value from std::allocator_traits, or some other
value that the allocator defines. And the value is reduced
appropriately if sizeof(char_type) > 1.

But if we call this->max_size() which calls _Alloc_traits::max_size()
which potentially calls allocator_type::max_size(), will the compiler
actually make those calls to mark the path unreachable, or will it
just ignore the unreachable if it can't fold all those calls at
compile time?


The above was just a quick proof of concept experiment.  You're
of course right that the final solution can't be so crude(*).
But if the required functions are always_inline (I think member
functions defined in the body of the class implicitly are) then
I'd expect them to be folded at compile time at all optimization
levels.  That's what makes -Winvalid-memory-order work in C++
even at -O0 in the patch I posted earlier this week.

If I still remember my C++-library-fu, even though the standard
requires containers to call max_size() etc., since std::string
is (or can be) an explicit specialization, there shouldn't be
a way for a conforming program to find out if it does, so it
could take shortcuts.  That makes me wonder if it could even
call malloc instead of operator new to get around the problem
with the operator's replaceability.



We could just use __SIZE_MAX__/2 which might be larger than the real
maximum, but will never be smaller.

Jason made a suggestion last week which was that if the warning code
has a range like [2,INT_MAX] or [2UL,ULONG_MAX] that it should assume
that is really [2,infinity] and so not warn. If the upper bound is the
maximum possible value for the type, that's effectively unbounded, and
the warning could assume it's simply not got enough information to
give a useful warning. If it has a range like [2,300] for a buffer of
length 100, that should warn. But [2,infinity] is effectively ranger
saying "I have no idea what this value is" and the warning machinery
should not be issuing warnings on the basis of "I have no idea what
this value is".


The warnings use the lower bound of the access size and ignore
the upper bound.  They use the upper bound of the space remaining
in the destination(s) and ignore the lower bound.

In a call to memcpy (P + I, s, N) the access size is N, and
the space remaining in A is the upper bound of the size of
the largest array A that P points to (it might point to any
number of them, and some might be dynamically allocated with
a size in some range) minus the lower bound of I or zero,
whichever is greater.

This is the most conservative strategy.  There are other
strategies where we could get more true positives but also
more false positives.  Those might be appropriate for
the "maybe" kind of warnings.

Martin


__builtin_unreachable ();
  return _M_string_length;
}

That gets rid of the false positive in this PR.  I realize
the others happen for other reasons but this approach at least
suggests that there might be other ways to sup

[PATCH] c++: don't leak 'arglist' in build_new_op

[Patrick Palka via Gcc-patches]

'arglist' can be captured by a conversion within 'candidates', but if we
use a releasing_vec then we'll be sure to free it only after
'candidates' is freed by obstack_free.

Bootstrapped and regtested in x86_64-pc-linux-gnu, does this look OK for
trunk?

gcc/cp/ChangeLog:

* call.c (build_new_op): Use releasing_vec for arglist.  Declare
conv in the scope it's used.
---
 gcc/cp/call.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 28bd8e0c260..347df5da35d 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -6461,13 +6461,12 @@ build_new_op (const op_location_t &loc, enum tree_code 
code, int flags,
  tsubst_flags_t complain)
 {
   struct z_candidate *candidates = 0, *cand;
-  vec *arglist;
+  releasing_vec arglist;
   tree result = NULL_TREE;
   bool result_valid_p = false;
   enum tree_code code2 = ERROR_MARK;
   enum tree_code code_orig_arg1 = ERROR_MARK;
   enum tree_code code_orig_arg2 = ERROR_MARK;
-  conversion *conv;
   void *p;
   bool strict_p;
   bool any_viable_p;
@@ -6543,7 +6542,6 @@ build_new_op (const op_location_t &loc, enum tree_code 
code, int flags,
   arg2_type = integer_type_node;
 }
 
-  vec_alloc (arglist, 3);
   arglist->quick_push (arg1);
   if (arg2 != NULL_TREE)
 arglist->quick_push (arg2);
@@ -6814,7 +6812,7 @@ build_new_op (const op_location_t &loc, enum tree_code 
code, int flags,
 corresponding parameters of the selected operation function,
 except that the second standard conversion sequence of a
 user-defined conversion sequence (12.3.3.1.2) is not applied."  */
- conv = cand->convs[0];
+ conversion *conv = cand->convs[0];
  if (conv->user_conv_p)
{
  conv = strip_standard_conversion (conv);
-- 
2.34.1.75.gabe6bb3905

Re: [PATCH] Define _C99 in libstdc++ vxworks/os_defines.h

[Olivier Hainque via Gcc-patches]

> On 10 Dec 2021, at 16:42, Jonathan Wakely  wrote:
> 
> 
> OK to commit then, thanks.
> 
> The comment is a bit misleading though:
> 
> +// libstdc++ relies on C99 features for virtually all versions of C++,
> +// up to at least C++98.
> +#undef _C99
> +#define _C99 1
> 
> The "up to" seems backwards, I'd expect it to say "down to" or "as far
> back as at least C++98".
> 
> But there's nothing older than C++98 anyway, so this just means "all
> versions", there's no "virtually" about it.
> 
> Please just say "libstdc++ relies on C99 features for all versions of C++".

Sure, thanks Jonathan. Yes, I agree the comment is confused.
I hesitated between a couple of perspectives and just mixed
things up.

Thanks for your prompt review!

Olivier

Re: [PATCH] c++: remove COMPOUND_EXPR_OVERLOADED flag

[Marek Polacek via Gcc-patches]

On Fri, Dec 10, 2021 at 10:48:00AM -0500, Patrick Palka via Gcc-patches wrote:
> This flag is never set because non-dependent COMPOUND_EXPRs are fully
> resolved into a CALL_EXPR at template definition time (in
> build_x_compound_expr) ever since r6-5772.
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?

LGTM.
 
> gcc/cp/ChangeLog:
> 
>   * cp-tree.h (COMPOUND_EXPR_OVERLOADED): Remove.
>   * pt.c (build_non_dependent_expr): Don't inspect this flag.
>   * tree.c (build_min_non_dep): Don't set this flag.
> ---
>  gcc/cp/cp-tree.h | 6 --
>  gcc/cp/pt.c  | 3 +--
>  gcc/cp/tree.c| 5 -
>  3 files changed, 1 insertion(+), 13 deletions(-)
> 
> diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> index b1c3bc5ed1f..e4330fb1f8b 100644
> --- a/gcc/cp/cp-tree.h
> +++ b/gcc/cp/cp-tree.h
> @@ -404,7 +404,6 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX];
>NEW_EXPR_USE_GLOBAL (in NEW_EXPR).
>COND_EXPR_IS_VEC_DELETE (in COND_EXPR).
>DELETE_EXPR_USE_GLOBAL (in DELETE_EXPR).
> -  COMPOUND_EXPR_OVERLOADED (in COMPOUND_EXPR).
>CLEANUP_P (in TRY_BLOCK)
>AGGR_INIT_VIA_CTOR_P (in AGGR_INIT_EXPR)
>PTRMEM_OK_P (in ADDR_EXPR, OFFSET_REF, SCOPE_REF)
> @@ -4015,11 +4014,6 @@ struct GTY(()) lang_decl {
>  #define CALL_OR_AGGR_INIT_CHECK(NODE) \
>TREE_CHECK2 ((NODE), CALL_EXPR, AGGR_INIT_EXPR)
>  
> -/* Indicates that this is a non-dependent COMPOUND_EXPR which will
> -   resolve to a function call.  */
> -#define COMPOUND_EXPR_OVERLOADED(NODE) \
> -  TREE_LANG_FLAG_0 (COMPOUND_EXPR_CHECK (NODE))
> -
>  /* In a CALL_EXPR appearing in a template, true if Koenig lookup
> should be performed at instantiation time.  */
>  #define KOENIG_LOOKUP_P(NODE) TREE_LANG_FLAG_0 (CALL_EXPR_CHECK (NODE))
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index 9834baf34db..cbdb4b566aa 100644
> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -28373,8 +28373,7 @@ build_non_dependent_expr (tree expr)
>   ? build_non_dependent_expr (TREE_OPERAND (expr, 1))
>   : build_non_dependent_expr (TREE_OPERAND (expr, 0))),
>  build_non_dependent_expr (TREE_OPERAND (expr, 2)));
> -  if (TREE_CODE (expr) == COMPOUND_EXPR
> -  && !COMPOUND_EXPR_OVERLOADED (expr))
> +  if (TREE_CODE (expr) == COMPOUND_EXPR)
>  return build2 (COMPOUND_EXPR,
>  TREE_TYPE (expr),
>  TREE_OPERAND (expr, 0),
> diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
> index 52c56831f98..f6f7927f293 100644
> --- a/gcc/cp/tree.c
> +++ b/gcc/cp/tree.c
> @@ -3577,11 +3577,6 @@ build_min_non_dep (enum tree_code code, tree non_dep, 
> ...)
>for (i = 0; i < length; i++)
>  TREE_OPERAND (t, i) = va_arg (p, tree);
>  
> -  if (code == COMPOUND_EXPR && TREE_CODE (non_dep) != COMPOUND_EXPR)
> -/* This should not be considered a COMPOUND_EXPR, because it
> -   resolves to an overload.  */
> -COMPOUND_EXPR_OVERLOADED (t) = 1;
> -
>va_end (p);
>return convert_from_reference (t);
>  }
> -- 
> 2.34.1.75.gabe6bb3905
> 

Marek

Re: [PATCH] c++: remove COMPOUND_EXPR_OVERLOADED flag

[Patrick Palka via Gcc-patches]

On Fri, Dec 10, 2021 at 10:48 AM Patrick Palka  wrote:
>
> This flag is never set because non-dependent COMPOUND_EXPRs are fully

Whoops, this should say, ... non-dependent COMPOUND_EXPRs that resolve
to an overload are expressed as a CALL_EXPR at template definition
time ...

> resolved into a CALL_EXPR at template definition time (in
> build_x_compound_expr) ever since r6-5772.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?
>
> gcc/cp/ChangeLog:
>
> * cp-tree.h (COMPOUND_EXPR_OVERLOADED): Remove.
> * pt.c (build_non_dependent_expr): Don't inspect this flag.
> * tree.c (build_min_non_dep): Don't set this flag.
> ---
>  gcc/cp/cp-tree.h | 6 --
>  gcc/cp/pt.c  | 3 +--
>  gcc/cp/tree.c| 5 -
>  3 files changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> index b1c3bc5ed1f..e4330fb1f8b 100644
> --- a/gcc/cp/cp-tree.h
> +++ b/gcc/cp/cp-tree.h
> @@ -404,7 +404,6 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX];
>NEW_EXPR_USE_GLOBAL (in NEW_EXPR).
>COND_EXPR_IS_VEC_DELETE (in COND_EXPR).
>DELETE_EXPR_USE_GLOBAL (in DELETE_EXPR).
> -  COMPOUND_EXPR_OVERLOADED (in COMPOUND_EXPR).
>CLEANUP_P (in TRY_BLOCK)
>AGGR_INIT_VIA_CTOR_P (in AGGR_INIT_EXPR)
>PTRMEM_OK_P (in ADDR_EXPR, OFFSET_REF, SCOPE_REF)
> @@ -4015,11 +4014,6 @@ struct GTY(()) lang_decl {
>  #define CALL_OR_AGGR_INIT_CHECK(NODE) \
>TREE_CHECK2 ((NODE), CALL_EXPR, AGGR_INIT_EXPR)
>
> -/* Indicates that this is a non-dependent COMPOUND_EXPR which will
> -   resolve to a function call.  */
> -#define COMPOUND_EXPR_OVERLOADED(NODE) \
> -  TREE_LANG_FLAG_0 (COMPOUND_EXPR_CHECK (NODE))
> -
>  /* In a CALL_EXPR appearing in a template, true if Koenig lookup
> should be performed at instantiation time.  */
>  #define KOENIG_LOOKUP_P(NODE) TREE_LANG_FLAG_0 (CALL_EXPR_CHECK (NODE))
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index 9834baf34db..cbdb4b566aa 100644
> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -28373,8 +28373,7 @@ build_non_dependent_expr (tree expr)
> ? build_non_dependent_expr (TREE_OPERAND (expr, 1))
> : build_non_dependent_expr (TREE_OPERAND (expr, 0))),
>build_non_dependent_expr (TREE_OPERAND (expr, 2)));
> -  if (TREE_CODE (expr) == COMPOUND_EXPR
> -  && !COMPOUND_EXPR_OVERLOADED (expr))
> +  if (TREE_CODE (expr) == COMPOUND_EXPR)
>  return build2 (COMPOUND_EXPR,
>TREE_TYPE (expr),
>TREE_OPERAND (expr, 0),
> diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
> index 52c56831f98..f6f7927f293 100644
> --- a/gcc/cp/tree.c
> +++ b/gcc/cp/tree.c
> @@ -3577,11 +3577,6 @@ build_min_non_dep (enum tree_code code, tree non_dep, 
> ...)
>for (i = 0; i < length; i++)
>  TREE_OPERAND (t, i) = va_arg (p, tree);
>
> -  if (code == COMPOUND_EXPR && TREE_CODE (non_dep) != COMPOUND_EXPR)
> -/* This should not be considered a COMPOUND_EXPR, because it
> -   resolves to an overload.  */
> -COMPOUND_EXPR_OVERLOADED (t) = 1;
> -
>va_end (p);
>return convert_from_reference (t);
>  }
> --
> 2.34.1.75.gabe6bb3905
>

Re: [PATCH] libstdc++: Add std::time_get %r support [PR71367]

[Jonathan Wakely via Gcc-patches]

On Fri, 10 Dec 2021 at 12:49, Jakub Jelinek via Libstdc++
 wrote:
>
> Hi!
>
> This incremental patch adds std::time_get %r support (%p was added already
> in the previous patch).  The _M_am_fm_format method previously in the header
> unfortunately had wrong arguments and so was useless, so the largest
> complication in this patch is exporting a new symbol in the right symbol
> version.
>
> Tested on x86_64-linux, ok for trunk?

Yes, this one is OK too, thanks!


>
> 2021-12-10  Jakub Jelinek  
>
> PR libstdc++/71367
> * config/locale/dragonfly/time_members.cc (_M_initialize_timepunct):
> Initialize "C" _M_am_pm_format to %I:%M:%S %p rather than empty
> string.
> * config/locale/gnu/time_members.cc (_M_initialize_timepunct):
> Likewise.
> * config/locale/generic/time_members.cc (_M_initialize_timepunct):
> Likewise.
> * include/bits/locale_facets_nonio.h (_M_am_pm_format): New method.
> * include/bits/locale_facets_nonio.tcc (_M_extract_via_format): Handle
> %r.
> * config/abi/pre/gnu.ver (GLIBCXX_3.4.30): Export _M_am_pm_format
> with const _CharT** argument, ensure it isn't exported in GLIBCXX_3.4.
> * testsuite/22_locale/time_get/get/char/71367.cc: New test.
> * testsuite/22_locale/time_get/get/wchar_t/71367.cc: New test.
>
> --- libstdc++-v3/config/locale/dragonfly/time_members.cc.jj 2021-01-05 
> 00:13:58.281297350 +0100
> +++ libstdc++-v3/config/locale/dragonfly/time_members.cc2021-12-10 
> 12:27:18.350425776 +0100
> @@ -74,7 +74,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   _M_data->_M_date_time_era_format = "";
>   _M_data->_M_am = "AM";
>   _M_data->_M_pm = "PM";
> - _M_data->_M_am_pm_format = "";
> + _M_data->_M_am_pm_format = "%I:%M:%S %p";
>
>   // Day names, starting with "C"'s Sunday.
>   _M_data->_M_day1 = "Sunday";
> @@ -231,7 +231,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   _M_data->_M_date_time_era_format = L"";
>   _M_data->_M_am = L"AM";
>   _M_data->_M_pm = L"PM";
> - _M_data->_M_am_pm_format = L"";
> + _M_data->_M_am_pm_format = L"%I:%M:%S %p";
>
>   // Day names, starting with "C"'s Sunday.
>   _M_data->_M_day1 = L"Sunday";
> --- libstdc++-v3/config/locale/gnu/time_members.cc.jj   2021-01-05 
> 00:13:58.282297338 +0100
> +++ libstdc++-v3/config/locale/gnu/time_members.cc  2021-12-10 
> 12:26:52.979787605 +0100
> @@ -80,7 +80,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   _M_data->_M_date_time_era_format = "";
>   _M_data->_M_am = "AM";
>   _M_data->_M_pm = "PM";
> - _M_data->_M_am_pm_format = "";
> + _M_data->_M_am_pm_format = "%I:%M:%S %p";
>
>   // Day names, starting with "C"'s Sunday.
>   _M_data->_M_day1 = "Sunday";
> @@ -236,7 +236,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   _M_data->_M_date_time_era_format = L"";
>   _M_data->_M_am = L"AM";
>   _M_data->_M_pm = L"PM";
> - _M_data->_M_am_pm_format = L"";
> + _M_data->_M_am_pm_format = L"%I:%M:%S %p";
>
>   // Day names, starting with "C"'s Sunday.
>   _M_data->_M_day1 = L"Sunday";
> --- libstdc++-v3/config/locale/generic/time_members.cc.jj   2021-01-05 
> 00:13:58.282297338 +0100
> +++ libstdc++-v3/config/locale/generic/time_members.cc  2021-12-10 
> 12:27:55.433896906 +0100
> @@ -72,7 +72,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>_M_data->_M_date_time_era_format = "";
>_M_data->_M_am = "AM";
>_M_data->_M_pm = "PM";
> -  _M_data->_M_am_pm_format = "";
> +  _M_data->_M_am_pm_format = "%I:%M:%S %p";
>
>// Day names, starting with "C"'s Sunday.
>_M_data->_M_day1 = "Sunday";
> @@ -157,7 +157,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>_M_data->_M_date_time_era_format = L"";
>_M_data->_M_am = L"AM";
>_M_data->_M_pm = L"PM";
> -  _M_data->_M_am_pm_format = L"";
> +  _M_data->_M_am_pm_format = L"%I:%M:%S %p";
>
>// Day names, starting with "C"'s Sunday.
>_M_data->_M_day1 = L"Sunday";
> --- libstdc++-v3/include/bits/locale_facets_nonio.h.jj  2021-04-06 
> 23:49:08.318882385 +0200
> +++ libstdc++-v3/include/bits/locale_facets_nonio.h 2021-12-10 
> 12:55:26.240337962 +0100
> @@ -243,6 +243,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  #endif
>
>void
> +  _M_am_pm_format(const _CharT** __ampm_format) const
> +  {
> +   __ampm_format[0] = _M_data->_M_am_pm_format;
> +  }
> +
> +  void
>_M_am_pm(const _CharT** __ampm) const
>{
> __ampm[0] = _M_data->_M_am;
> --- libstdc++-v3/include/bits/locale_facets_nonio.tcc.jj2021-12-09 
> 22:52:34.892266539 +0100
> +++ libstdc++-v3/include/bits/locale_facets_nonio.tcc   2021-12-10 
> 12:56:02.721816838 +0100
> @@ -806,6 +806,13 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11
>   if (!__tmperr && __mem)
>  

Re: [PATCH] libstdc++: Some time_get fixes [PR78714]

[Jonathan Wakely via Gcc-patches]

On Thu, 9 Dec 2021 at 14:20, Jakub Jelinek wrote:
>
> Hi!
>
> The following patch is an attempt to fix various time_get related issues.
> Sorry, it is long...
>
> One of them is PR78714.  It seems _M_extract_via_format has been written
> with how strftime behaves in mind rather than how strptime behaves.
> There is a significant difference between the two, for strftime %a and %A
> behave differently etc., one emits an abbreviated name, the other full name.
> For strptime both should behave the same and accept both the full or
> abbreviated names.  This needed large changes in _M_extract_name, which
> was assuming the names are unique and names aren't prefixes of other names.
> The _M_extract_name changes allow to deal with those cases.  As can be
> seen in the new testcase, e.g. for %b and english locales we need to
> accept both Apr and April.  If we see Apr in the input, the code looks
> at whether there is end right after those 3 chars or if the next
> character doesn't match characters in the longer names; in that case
> it accepts the abbreviated name.  Otherwise, if the input has Apri, it
> commits to a longer name and fails if it isn't April.  This behavior is
> different from strptime, which for %bix and Aprix accepts it, but for
> an input iterator I'm afraid we can't do better, we can't go back (peek
> more than the current character).

Yes, I think that's the best we can do.

> Another case is that %d and %e in strptime should work the same, while
> previously the code was hardcoding that %d would be 01 to 31 and %e
>  1 to 31 (with leading 0 replaced by space).
> strptime POSIX 2009 documentation seems to suggest for numbers it should
> accept up to the specified number of digits rather than exactly that number
> of digits:
> The pattern "[x,y]" indicates that the value shall fall within the range
> given (both bounds being inclusive), and the maximum number of characters 
> scanned
> shall be the maximum required to represent any value in the range without 
> leading
> zeros.
> so by my reading "1:" is valid for "%H:".

I agree.

> The glibc strptime implementation actually skips any amount of whitespace
> in all the cases where a number is read, my current patch skips a single
> space at the start of %d/%e but not the others, but doesn't subtract the
> space length from the len characters.
> One option would be to do the leading whitespace skipping in _M_extract_num
> but take it into account how many digits can be read.
> This matters for " 12:" and "%H:", but not for " 12:" and " %H:"
> as in the latter case the space in the format string results in all the
> whitespace at the start to be consumed.
> Note, the allowing of a single digit rather than 2 changes a behavior in
> other ways, e.g. when seeing 40 in a number for range [1, 31] we reject
> it as before, but previously we'd keep *ret == '4' because it was assuming
> it has to be 2 digits and 40 isn't valid, so we know error already on the
> 4, but now we accept the 4 as value and fail iff the next format string
> doesn't match the 0.

Again, I think that's the best we can do. And I think that's fine. The
primary purpose of these interfaces is to read valid dates, not check
whether input forms a valid date or not.

If you want to be able to tentatively parse a date (or number, or
monetary quantity etc) and then try recovering and parsing it
differently (e.g. "if it doesn't parse as a date in format X, try
format Y") then you can copy the input to a new buffer and re-parse
it. We don't need to make that work by rewinding the input iterator or
trying to peek ahead until we know if the parse will succeed.

> Also, previously it wasn't really checking the number was in the right
> range, it would accept 00 for [1, 31] numbers, or would accept 39.

Doh.

>
> Another thing is that %I was parsing 12 as tm_hour 12 rather than as tm_hour 0
> like e.g. glibc does.
>
> Another thing is that %t was matching a single tab and %n a single newline,
> while strptime docs say it skips over whitespace (again, zero or more).
>
> Another thing is that %p wasn't handled at all, I think this was the main
> cause of

Yes, and that's PR 71367

> FAIL: 22_locale/time_get/get_time/char/2.cc execution test
> FAIL: 22_locale/time_get/get_time/char/wrapped_env.cc execution test
> FAIL: 22_locale/time_get/get_time/char/wrapped_locale.cc execution test
> FAIL: 22_locale/time_get/get_time/wchar_t/2.cc execution test
> FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_env.cc execution test
> FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_locale.cc execution test
> before this patch, because en_HK* locales do use %I and %p in it.
> The patch handles %p only if it follows %I (i.e. when the hour is parsed
> first), which is the more usual case (in glibc):
> grep '%I' localedata/locales/* | grep '%I.*%p' | wc -l
> 282
> grep '%I' localedata/locales/* | grep -v '%I.*%p' | wc -l
> 44
> grep '%I' localedata/locales/* | grep -v '%p' | wc -l
> 17
> The last case use %P inste

[PATCH] c++: remove COMPOUND_EXPR_OVERLOADED flag

[Patrick Palka via Gcc-patches]

This flag is never set because non-dependent COMPOUND_EXPRs are fully
resolved into a CALL_EXPR at template definition time (in
build_x_compound_expr) ever since r6-5772.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?

gcc/cp/ChangeLog:

* cp-tree.h (COMPOUND_EXPR_OVERLOADED): Remove.
* pt.c (build_non_dependent_expr): Don't inspect this flag.
* tree.c (build_min_non_dep): Don't set this flag.
---
 gcc/cp/cp-tree.h | 6 --
 gcc/cp/pt.c  | 3 +--
 gcc/cp/tree.c| 5 -
 3 files changed, 1 insertion(+), 13 deletions(-)

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index b1c3bc5ed1f..e4330fb1f8b 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -404,7 +404,6 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX];
   NEW_EXPR_USE_GLOBAL (in NEW_EXPR).
   COND_EXPR_IS_VEC_DELETE (in COND_EXPR).
   DELETE_EXPR_USE_GLOBAL (in DELETE_EXPR).
-  COMPOUND_EXPR_OVERLOADED (in COMPOUND_EXPR).
   CLEANUP_P (in TRY_BLOCK)
   AGGR_INIT_VIA_CTOR_P (in AGGR_INIT_EXPR)
   PTRMEM_OK_P (in ADDR_EXPR, OFFSET_REF, SCOPE_REF)
@@ -4015,11 +4014,6 @@ struct GTY(()) lang_decl {
 #define CALL_OR_AGGR_INIT_CHECK(NODE) \
   TREE_CHECK2 ((NODE), CALL_EXPR, AGGR_INIT_EXPR)
 
-/* Indicates that this is a non-dependent COMPOUND_EXPR which will
-   resolve to a function call.  */
-#define COMPOUND_EXPR_OVERLOADED(NODE) \
-  TREE_LANG_FLAG_0 (COMPOUND_EXPR_CHECK (NODE))
-
 /* In a CALL_EXPR appearing in a template, true if Koenig lookup
should be performed at instantiation time.  */
 #define KOENIG_LOOKUP_P(NODE) TREE_LANG_FLAG_0 (CALL_EXPR_CHECK (NODE))
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 9834baf34db..cbdb4b566aa 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -28373,8 +28373,7 @@ build_non_dependent_expr (tree expr)
? build_non_dependent_expr (TREE_OPERAND (expr, 1))
: build_non_dependent_expr (TREE_OPERAND (expr, 0))),
   build_non_dependent_expr (TREE_OPERAND (expr, 2)));
-  if (TREE_CODE (expr) == COMPOUND_EXPR
-  && !COMPOUND_EXPR_OVERLOADED (expr))
+  if (TREE_CODE (expr) == COMPOUND_EXPR)
 return build2 (COMPOUND_EXPR,
   TREE_TYPE (expr),
   TREE_OPERAND (expr, 0),
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 52c56831f98..f6f7927f293 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -3577,11 +3577,6 @@ build_min_non_dep (enum tree_code code, tree non_dep, 
...)
   for (i = 0; i < length; i++)
 TREE_OPERAND (t, i) = va_arg (p, tree);
 
-  if (code == COMPOUND_EXPR && TREE_CODE (non_dep) != COMPOUND_EXPR)
-/* This should not be considered a COMPOUND_EXPR, because it
-   resolves to an overload.  */
-COMPOUND_EXPR_OVERLOADED (t) = 1;
-
   va_end (p);
   return convert_from_reference (t);
 }
-- 
2.34.1.75.gabe6bb3905

Re: [PATCH] Define _C99 in libstdc++ vxworks/os_defines.h

[Jonathan Wakely via Gcc-patches]

On Fri, 10 Dec 2021 at 15:16, Rasmus Villemoes via Libstdc++
 wrote:
>
> On 10/12/2021 16.06, Olivier Hainque wrote:
> > Hello,
> >
> > The attached patch for libstdc++ / VxWorks helps building
> > the library for old versions of the OS, as witnessed with
> > VxWorks 6.9 in particular.
> >
> > It explicitly requests C99 features from old system headers,
> > on which libstc++ relies since at least c++98. The specific
> > issue that exposed this was a failure to compile
> >
> >   libstdc++-v3/src/c++17/floating_to_chars.cc
> >
> > for VxWorks 6.9 with a batch of errors such as:
> >
> >   error: 'FP_NAN' was not declared in this scope
> >
> > The missing definitions are provided by the
> > system headers with guards on _HAS_C9X, which gets
> > internally defined when _C99 is.
> >
> > Ok to commit?
>
> Yes, we've observed that error as well. We have just patched our vxworks
> 5.5 headers to provide FP_NAN et al. There's no test of definedness or
> other uses of a _C99 macro anywhere, so ok by me, as it shouldn't change
> anything on our end.
>
> Rasmus

OK to commit then, thanks.

The comment is a bit misleading though:

+// libstdc++ relies on C99 features for virtually all versions of C++,
+// up to at least C++98.
+#undef _C99
+#define _C99 1

The "up to" seems backwards, I'd expect it to say "down to" or "as far
back as at least C++98".

But there's nothing older than C++98 anyway, so this just means "all
versions", there's no "virtually" about it.

Please just say "libstdc++ relies on C99 features for all versions of C++".

[PATCH] gengtype: remove "tree_exp" special attribute

[Patrick Palka via Gcc-patches]

The function comment for adjust_field_tree_exp says this special case
is for handling trees whose operands may contain pointers to RTL instead
of to trees.  But ever since r0-59671, which fixed/removed the last two
tree codes for which this was possible (GOTO_SUBROUTINE_EXPR and
WITH_CLEANUP_EXPR), this special attribute is largely a no-op.

This patch removes it and instead just annotates struct tree_exp
with the "length" attribute directly.  Not sure it makes a difference,
but I use %h instead of %0 in the "length" attribute to be consistent
with other structures' "length" attributes within tree-core.h.

This changes the code generated for TS_EXP handling in gt-cp-tree.h from:

  case TS_EXP:
gt_ggc_m_9tree_node ((*x).generic.exp.typed.type);
switch ((int) (TREE_CODE ((tree) &(*x
  {
  default:
{
  size_t i3;
  size_t l3 = (size_t)(TREE_OPERAND_LENGTH ((tree) &(*x)));
  for (i3 = 0; i3 != l3; i3++) {
gt_ggc_m_9tree_node ((*x).generic.exp.operands[i3]);
  }
}
break;
  }
break;

to:

  case TS_EXP:
{
  size_t l3 = (size_t)(TREE_OPERAND_LENGTH ((tree)&((*x).generic.exp)));
  gt_ggc_m_9tree_node ((*x).generic.exp.typed.type);
  {
size_t i3;
for (i3 = 0; i3 != l3; i3++) {
  gt_ggc_m_9tree_node ((*x).generic.exp.operands[i3]);
}
  }
}

which seems equivalent and simpler.

Boostrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk?

gcc/ChangeLog:

* gengtype.c (adjust_field_tree_exp): Remove.
(adjust_field_type): Don't handle the "tree_exp" special attribute.
* tree-core.h (struct tree_exp): Replace special and desc
attributes with length.
---
 gcc/gengtype.c  | 35 +--
 gcc/tree-core.h |  4 +---
 2 files changed, 2 insertions(+), 37 deletions(-)

diff --git a/gcc/gengtype.c b/gcc/gengtype.c
index db218a7bce7..2dc443175fa 100644
--- a/gcc/gengtype.c
+++ b/gcc/gengtype.c
@@ -511,7 +511,6 @@ pair_p typedefs = NULL;
 type_p structures = NULL;
 pair_p variables = NULL;
 
-static type_p adjust_field_tree_exp (type_p t, options_p opt);
 static type_p adjust_field_rtx_def (type_p t, options_p opt);
 
 /* Define S as a typedef to T at POS.  */
@@ -1384,36 +1383,6 @@ adjust_field_rtx_def (type_p t, options_p ARG_UNUSED 
(opt))
nodot, NULL);
 }
 
-/* Handle `special("tree_exp")'.  This is a special case for
-   field `operands' of struct tree_exp, which although it claims to contain
-   pointers to trees, actually sometimes contains pointers to RTL too.
-   Passed T, the old type of the field, and OPT its options.  Returns
-   a new type for the field.  */
-
-static type_p
-adjust_field_tree_exp (type_p t, options_p opt ATTRIBUTE_UNUSED)
-{
-  pair_p flds;
-  options_p nodot;
-
-  if (t->kind != TYPE_ARRAY)
-{
-  error_at_line (&lexer_line,
-"special `tree_exp' must be applied to an array");
-  return &string_type;
-}
-
-  nodot = create_string_option (NULL, "dot", "");
-
-  flds = create_field (NULL, t, "");
-  flds->opt = create_string_option (nodot, "length",
-   "TREE_OPERAND_LENGTH ((tree) &%0)");
-  flds->opt = create_string_option (flds->opt, "default", "");
-
-  return new_structure ("tree_exp_subunion", TYPE_UNION, &lexer_line, flds,
-   nodot, NULL);
-}
-
 /* Perform any special processing on a type T, about to become the type
of a field.  Return the appropriate type for the field.
At present:
@@ -1447,9 +1416,7 @@ adjust_field_type (type_p t, options_p opt)
 && opt->kind == OPTION_STRING)
   {
const char *special_name = opt->info.string;
-   if (strcmp (special_name, "tree_exp") == 0)
- t = adjust_field_tree_exp (t, opt);
-   else if (strcmp (special_name, "rtx_def") == 0)
+   if (strcmp (special_name, "rtx_def") == 0)
  t = adjust_field_rtx_def (t, opt);
else
  error_at_line (&lexer_line, "unknown special `%s'", special_name);
diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index 91ae5237d7e..c48018999ce 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -1547,9 +1547,7 @@ enum omp_clause_linear_kind
 struct GTY(()) tree_exp {
   struct tree_typed typed;
   location_t locus;
-  tree GTY ((special ("tree_exp"),
-desc ("TREE_CODE ((tree) &%0)")))
-operands[1];
+  tree GTY ((length ("TREE_OPERAND_LENGTH ((tree)&%h)"))) operands[1];
 };
 
 /* Immediate use linking structure.  This structure is used for maintaining
-- 
2.34.1.75.gabe6bb3905

Re: [PATCH] Define _C99 in libstdc++ vxworks/os_defines.h

[Rasmus Villemoes via Gcc-patches]

On 10/12/2021 16.06, Olivier Hainque wrote:
> Hello,
> 
> The attached patch for libstdc++ / VxWorks helps building
> the library for old versions of the OS, as witnessed with
> VxWorks 6.9 in particular.
> 
> It explicitly requests C99 features from old system headers,
> on which libstc++ relies since at least c++98. The specific
> issue that exposed this was a failure to compile
> 
>   libstdc++-v3/src/c++17/floating_to_chars.cc
> 
> for VxWorks 6.9 with a batch of errors such as:
> 
>   error: 'FP_NAN' was not declared in this scope
> 
> The missing definitions are provided by the
> system headers with guards on _HAS_C9X, which gets
> internally defined when _C99 is.
> 
> Ok to commit?

Yes, we've observed that error as well. We have just patched our vxworks
5.5 headers to provide FP_NAN et al. There's no test of definedness or
other uses of a _C99 macro anywhere, so ok by me, as it shouldn't change
anything on our end.

Rasmus

Re: [PATCH 2/4] libgcc: vxcrtstuff.c: remove ctor/dtor declarations

[Olivier Hainque via Gcc-patches]

> On 1 Nov 2021, at 10:34, Rasmus Villemoes  wrote:
> 
> These declarations prevent the priority given in the
> constructor/destructor attributes from taking effect, thus emitting
> the function pointers in the ordinary (lowest-priority)
> .init_array/.fini_array sections.
> 
> libgcc/
>   * config/vxcrtstuff.c: Remove constructor/destructor
>   declarations.

Ok, thanks.

Olivier

Re: [PATCH 3/4] libgcc: vxcrtstuff.c: make ctor/dtor functions static

[Olivier Hainque via Gcc-patches]

> On 10 Dec 2021, at 16:07, Rasmus Villemoes  wrote:
> 
>> 
>> This is OK, can you please commit?
> 
> Well, yes, but it depends contextually (but not functionally) on patch
> 2/4. Should I redo this one, or can I get you to take a look at 2/4 first?
> 
> You've already ok'ed 1/4 and 4/4 (which were anyway independent of each
> other and 2,3) and I've committed those


Ah, sure. Yes, 2/4 is ok as well. I have been testing with
a combined version of the two, actually.

I'll send a separate approval for 2/4 momentarily. Thanks.

Olivier

[PATCH] mips: Improved RTL representation of wsbh/dsbh/dshd

[Roger Sayle]

This patch to the mips backend updates the representations used
internally for MIPS' wsbh, dsbh and dshd instructions.  These were
previously described using an UNSPEC rtx, which prevents simplification
at the RTL level.  In addition to now being able to eliminate rotate
instructions before/after wsbh, allowing a wsbh to be emitted without
a backend builtin, these new representations also allow dsbh and dshd
to be synthesized from standard C/C++ vector idioms.

This patch has been tested by a make bootstrap and make -k check
on mips-unknown-linux-gnu, with --enable-multiarch --enable-multilib
--enable-targets=all --with-arch-32=mips32r2 --with-arch-64=mips64r2
(thanks to the compile farm's gcc230.fsffrance.org) and a cross-compiler
to mips64-linux-gnu hosted on x86_64-pc-linux-gnu.

Ok for mainline?


2021-12-10  Roger Sayle  

gcc/ChangeLog
* config/mips/mips.c (mips_vector_mode_supported_p): Allow
V4HI and V8QI modes on TARGET_64BIT with ISA_HAS_WSBH.
(mips_expand_vec_perm_const_1): With one_vector_p, try
expanding a vselect directly before an interleaved variant.
* mips.md (UNSPEC_WSBH, UNSPEC_DSBH, UNSPEC_DSHD): Delete.
(bswapsi2): Change from define_insn_and_split to an expander.
(bswapdi2): Change from define_insn_and_split to an expander.
(wsbh): Represent as SI rotate by 16 of a bswap32.
(wsbh_2): Also recognize as a bswap32 of a rotatert:SI ... 16.
(wsbh_v4qi): Recognize wsbh from a vec_select:V4QI.
(wsbh_v2hi): Recognize wsbh from a vec_select:V2HI.
(dsbh): Represent as a DImode cast of a vec_select:V8QI.
(dsbh_v8qi): Recognize dsbh from a vec_select:V8QI.
(dshd): Represent as a DImode cast of a vec_select:V8QI.
(dshd_v8qi): Recognize dshd from a vec_select:V8QI.
(dshd_v4hi): Recognize dshd from a vec_select:V4HI.

gcc/testsuite/ChangeLog
* gcc.target/mips/dsbh-v8qi.c: New test case.
* gcc.target/mips/dshd-v4hi.c: New test case.
* gcc.target/mips/dshd-v8qi.c: New test case.
* gcc.target/mips/wsbh.c: New test case.


Thanks in advance,
Roger
--

diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 807bf1a..c5699d6 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -13407,9 +13407,12 @@ mips_vector_mode_supported_p (machine_mode mode)
   return TARGET_DSP;
 
 case E_V2SImode:
+  return TARGET_LOONGSON_MMI;
+
 case E_V4HImode:
 case E_V8QImode:
-  return TARGET_LOONGSON_MMI;
+  return TARGET_LOONGSON_MMI
+|| (TARGET_64BIT && ISA_HAS_WSBH);
 
 default:
   return MSA_SUPPORTED_MODE_P (mode);
@@ -21608,6 +21611,9 @@ mips_expand_vec_perm_const_1 (struct expand_vec_perm_d 
*d)
 
   if (d->one_vector_p)
 {
+  if (mips_expand_vselect (d->target, d->op0, d->perm, nelt))
+   return true;
+
   /* Try interleave with alternating operands.  */
   memcpy (perm2, d->perm, sizeof(perm2));
   for (i = 1; i < nelt; i += 2)
diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
index 455b9b8..21364d6 100644
--- a/gcc/config/mips/mips.md
+++ b/gcc/config/mips/mips.md
@@ -81,11 +81,6 @@
   UNSPEC_STORE_LEFT
   UNSPEC_STORE_RIGHT
 
-  ;; Integer operations that are too cumbersome to describe directly.
-  UNSPEC_WSBH
-  UNSPEC_DSBH
-  UNSPEC_DSHD
-
   ;; Floating-point moves.
   UNSPEC_LOAD_LOW
   UNSPEC_LOAD_HIGH
@@ -5866,45 +5861,139 @@
   "wsbh\t%0,%1"
   [(set_attr "type" "shift")])
 
-(define_insn_and_split "bswapsi2"
+(define_expand "bswapsi2"
   [(set (match_operand:SI 0 "register_operand" "=d")
(bswap:SI (match_operand:SI 1 "register_operand" "d")))]
   "ISA_HAS_WSBH && ISA_HAS_ROR"
-  "#"
-  "&& 1"
-  [(set (match_dup 0) (unspec:SI [(match_dup 1)] UNSPEC_WSBH))
-   (set (match_dup 0) (rotatert:SI (match_dup 0) (const_int 16)))]
-  ""
-  [(set_attr "insn_count" "2")])
+{
+  rtx tmp = gen_reg_rtx (SImode);
+  emit_insn (gen_wsbh (tmp, operands[1]));
+  emit_insn (gen_rotrsi3 (operands[0], tmp, GEN_INT (16)));
+  DONE;
+})
 
-(define_insn_and_split "bswapdi2"
+(define_expand "bswapdi2"
   [(set (match_operand:DI 0 "register_operand" "=d")
(bswap:DI (match_operand:DI 1 "register_operand" "d")))]
   "TARGET_64BIT && ISA_HAS_WSBH"
-  "#"
-  "&& 1"
-  [(set (match_dup 0) (unspec:DI [(match_dup 1)] UNSPEC_DSBH))
-   (set (match_dup 0) (unspec:DI [(match_dup 0)] UNSPEC_DSHD))]
-  ""
-  [(set_attr "insn_count" "2")])
+{
+  rtx tmp = gen_reg_rtx (DImode);
+  emit_insn (gen_dsbh (tmp, operands[1]));
+  emit_insn (gen_dshd (operands[0], tmp));
+  DONE;
+})
 
 (define_insn "wsbh"
   [(set (match_operand:SI 0 "register_operand" "=d")
-   (unspec:SI [(match_operand:SI 1 "register_operand" "d")] UNSPEC_WSBH))]
+(rotatert:SI (bswap:SI (match_operand:SI 1 "register_operand" "d"))
+(const_int 16)))]
+  "ISA_HAS_WSBH"
+  "wsbh\t%0,%1"
+  [(set_attr "type" "shift")])
+
+;; Non-canonical variant of wsbh
+(define_insn "ws

Re: [PATCH 3/4] libgcc: vxcrtstuff.c: make ctor/dtor functions static

[Rasmus Villemoes via Gcc-patches]

On 10/12/2021 15.20, Olivier Hainque wrote:
> Hi again Rasmus,
> 
>> On 1 Nov 2021, at 10:34, Rasmus Villemoes  wrote:
>>
>> When the translation unit itself creates pointers to the ctors/dtors
>> in a specific section handled by the linker (whether .init_array or
>> .ctors.*), there's no reason for the functions to have external
>> linkage. That ends up polluting the symbol table in the running
>> kernel.
>>
>> This makes vxcrtstuff.c on par with the generic crtstuff.c which also
>> defines e.g. frame_dummy and __do_global_dtors_aux static.
>>
>> libgcc/
>>  * config/vxcrtstuff.c: Make constructor and destructor
>>  functions static when possible.
> 
> 
> This is OK, can you please commit?

Well, yes, but it depends contextually (but not functionally) on patch
2/4. Should I redo this one, or can I get you to take a look at 2/4 first?

You've already ok'ed 1/4 and 4/4 (which were anyway independent of each
other and 2,3) and I've committed those

Rasmus

Re: [PATCH v3 7/7] ifcvt: Run second pass if it is possible to omit a temporary.

[Robin Dapp via Gcc-patches]

Hi Jeff,

> I'd generally prefer to refactor the bits between the restart label and 
> the goto restart into a function and call it twice, passing in the 
> additional bits to allow for better costing.  Can you look into that?  
> If it's going to be major surgery, then the goto approach will be OK.

I transplanted the loop into a separate function
"noce_convert_multiple_sets_1" (for the lack of a better name right
now).  I guess an argument could be made about also moving

+  rtx cc_cmp = cond_exec_get_condition (jump);
+  rtx rev_cc_cmp = cond_exec_get_condition (jump, /* get_reversed */ true);

into the function and not care about traversing all instructions
twice/four times (will not be more than a few anyway) but I did not do
that for now.

Does this look better? Not fully tested yet everywhere but a test suite
run on s390 looked good.

Regards
 Robincommit 63926561fcdeace9e07b0240fc929b47b7b99404
Author: Robin Dapp 
Date:   Fri Sep 17 20:22:10 2021 +0200

ifcvt: Run second pass if it is possible to omit a temporary.

If one of the to-be-converted SETs requires the original comparison
(i.e. in order to generate a min/max insn) but no other insn after it
does, we can omit creating temporaries, thus facilitating costing.

diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index a13b28c9ee0..301181b2d1a 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -3250,9 +3250,6 @@ noce_convert_multiple_sets (struct noce_if_info *if_info)
   rtx x = XEXP (cond, 0);
   rtx y = XEXP (cond, 1);
 
-  rtx cc_cmp = cond_exec_get_condition (jump);
-  rtx rev_cc_cmp = cond_exec_get_condition (jump, /* get_reversed */ true);
-
   /* The true targets for a conditional move.  */
   auto_vec targets;
   /* The temporaries introduced to allow us to not consider register
@@ -3260,13 +3257,139 @@ noce_convert_multiple_sets (struct noce_if_info *if_info)
   auto_vec temporaries;
   /* The insns we've emitted.  */
   auto_vec unmodified_insns;
-  int count = 0;
 
   hash_set need_no_cmov;
   hash_map rewired_src;
 
   need_cmov_or_rewire (then_bb, &need_no_cmov, &rewired_src);
 
+  int last_needs_comparison = -1;
+
+  bool ok = noce_convert_multiple_sets_1
+(if_info, &need_no_cmov, &rewired_src, &targets, &temporaries,
+ &unmodified_insns, &last_needs_comparison);
+  if (!ok)
+  return false;
+
+  /* If there are insns that overwrite part of the initial
+ comparison, we can still omit creating temporaries for
+ the last of them.
+ As the second try will always create a less expensive,
+ valid sequence, we do not need to compare and can discard
+ the first one.  */
+  if (last_needs_comparison != -1)
+{
+  end_sequence ();
+  start_sequence ();
+  ok = noce_convert_multiple_sets_1
+	(if_info, &need_no_cmov, &rewired_src, &targets, &temporaries,
+	 &unmodified_insns, &last_needs_comparison);
+  /* Actually we should not fail anymore if we reached here,
+	 but better still check.  */
+  if (!ok)
+	  return false;
+}
+
+  /* We must have seen some sort of insn to insert, otherwise we were
+ given an empty BB to convert, and we can't handle that.  */
+  gcc_assert (!unmodified_insns.is_empty ());
+
+  /* Now fixup the assignments.  */
+  for (unsigned i = 0; i < targets.length (); i++)
+if (targets[i] != temporaries[i])
+  noce_emit_move_insn (targets[i], temporaries[i]);
+
+  /* Actually emit the sequence if it isn't too expensive.  */
+  rtx_insn *seq = get_insns ();
+
+  if (!targetm.noce_conversion_profitable_p (seq, if_info))
+{
+  end_sequence ();
+  return FALSE;
+}
+
+  for (insn = seq; insn; insn = NEXT_INSN (insn))
+set_used_flags (insn);
+
+  /* Mark all our temporaries and targets as used.  */
+  for (unsigned i = 0; i < targets.length (); i++)
+{
+  set_used_flags (temporaries[i]);
+  set_used_flags (targets[i]);
+}
+
+  set_used_flags (cond);
+  set_used_flags (x);
+  set_used_flags (y);
+
+  unshare_all_rtl_in_chain (seq);
+  end_sequence ();
+
+  if (!seq)
+return FALSE;
+
+  for (insn = seq; insn; insn = NEXT_INSN (insn))
+if (JUMP_P (insn)
+	|| recog_memoized (insn) == -1)
+  return FALSE;
+
+  emit_insn_before_setloc (seq, if_info->jump,
+			   INSN_LOCATION (unmodified_insns.last ()));
+
+  /* Clean up THEN_BB and the edges in and out of it.  */
+  remove_edge (find_edge (test_bb, join_bb));
+  remove_edge (find_edge (then_bb, join_bb));
+  redirect_edge_and_branch_force (single_succ_edge (test_bb), join_bb);
+  delete_basic_block (then_bb);
+  num_true_changes++;
+
+  /* Maybe merge blocks now the jump is simple enough.  */
+  if (can_merge_blocks_p (test_bb, join_bb))
+{
+  merge_blocks (test_bb, join_bb);
+  num_true_changes++;
+}
+
+  num_updated_if_blocks++;
+  if_info->transform_name = "noce_convert_multiple_sets";
+  return TRUE;
+}
+
+/* This goes through all relevant insns of IF_INFO->then_bb and tries to
+   create conditional moves.  In case a simple move sufficis the 

[PATCH] Define _C99 in libstdc++ vxworks/os_defines.h

[Olivier Hainque via Gcc-patches]

Hello,

The attached patch for libstdc++ / VxWorks helps building
the library for old versions of the OS, as witnessed with
VxWorks 6.9 in particular.

It explicitly requests C99 features from old system headers,
on which libstc++ relies since at least c++98. The specific
issue that exposed this was a failure to compile

  libstdc++-v3/src/c++17/floating_to_chars.cc

for VxWorks 6.9 with a batch of errors such as:

  error: 'FP_NAN' was not declared in this scope

The missing definitions are provided by the
system headers with guards on _HAS_C9X, which gets
internally defined when _C99 is.

Ok to commit?

Thanks in advance!

2021-12-07  Olivier Hainque  

libstdc++-v3/

* config/os/vxworks/os_defines.h: #define _C99.

Olivier



0001-Define-_C99-in-libstdc-vxworks-os_defines.h.patch
Description: Binary data

[PATCH] c++: two-stage name lookup for overloaded operators [PR51577]

[Patrick Palka via Gcc-patches]

In order to properly implement two-stage name lookup for dependent
operator expressions, we need to remember the result of unqualified
lookup of the operator at template definition time, and reuse that
result rather than performing another unqualified lookup at
instantiation time.

Ideally we could just store the lookup result in the expression directly,
but as pointed out in r9-6405 this isn't really possible since we use
the standard tree codes to represent most dependent operator expressions.

We could perhaps create a new tree code to represent dependent operator
expressions, say a DEPENDENT_OPERATOR_EXPR with enough operands to store
the lookup results along and everything else, but that'd require a lot
of careful work to make sure we handle this new tree code properly
across the frontend.

However, currently type-dependent operator (and call) expressions are
given an empty TREE_TYPE, so this space is effectively unused except to
signal that the expression is type-dependent.  It'd be convenient if we
could use this space to store the lookup results while preserving the
dependent-ness of the expression.

To that end, this patch creates a new kind of type, called
DEPENDENT_OPERATOR_TYPE, which we give to dependent operator expressions
and into which we can store the result of operator lookup at template
definition time (DEPENDENT_OPERATOR_TYPE_SAVED_LOOKUPS).  Since this
type is always dependent, and since the frontend doesn't seem to care
much about the particular type of a type-dependent expression, using
this type in place of a NULL_TREE type seems to just work; only
dependent_type_p and WILDCARD_TYPE_P need to be adjusted to return true
for this new type.

The rest of the patch mostly consists of adding the necessary plumbing
to pass DEPENDENT_OPERATOR_TYPE_SAVED_LOOKUPS to add_operator_candidates,
adjusting all callers of build_x_binary_op & friends appropriately, and
removing the now unnecessary push_operator_bindings mechanism.

In passing, this patch simplifies finish_constraint_binary_op to avoid
using build_x_binary_op for building a binary constraint-expr; we don't
need to consider operator||/&& overloads here.  This patch also makes
FOLD_EXPR_OP yield a tree_code instead of a raw INTEGER_CST.

Finally, this patch adds the XFAILed test operator-8.C which is about
broken two-stage name lookup for rewritten non-dependent operator
expressions, an existing bug that's otherwise only documented in
build_new_op.

Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK for
trunk?

PR c++/51577
PR c++/83035
PR c++/100465

gcc/cp/ChangeLog:

* call.c (add_operator_candidates): Add lookups parameter.
Use it to avoid performing a second unqualified lookup when
instantiating a dependent operator expression.
(build_new_op): Add lookups parameter and pass it appropriately.
* constraint.cc (finish_constraint_binary_op): Use
build_min_nt_loc instead of build_x_binary_op.
* coroutines.cc (build_co_await): Adjust call to build_new_op.
* cp-objcp-common.c (cp_common_init_ts): Mark
DEPENDENT_OPERATOR_TYPE appropriately.
* cp-tree.def (DEPENDENT_OPERATOR_TYPE): Define.
* cp-tree.h (WILDCARD_TYPE_P): Accept DEPENDENT_OPERATOR_TYPE.
(FOLD_EXPR_OP_RAW): New, renamed from ...
(FOLD_EXPR_OP): ... this.  Change this to return the tree_code directly.
(DEPENDENT_OPERATOR_TYPE_SAVED_LOOKUPS): Define.
(DEPENDENT_OPERATOR_SAVED_LOOKUPS): Define.
(build_new_op): Add lookups parameter.
(build_dependent_operator_type): Declare.
(build_x_indirect_ref): Add lookups parameter.
(build_x_binary_op): Likewise.
(build_x_unary_op): Likewise.
(build_x_compound_expr): Likewise.
(build_x_modify_expr): Likewise.
* cxx-pretty-print.c (get_fold_operator): Adjust after
FOLD_EXPR_OP change.
* decl.c (start_preparsed_function): Don't call
push_operator_bindings.
* decl2.c (grok_array_decl): Adjust calls to build_new_op.
* method.c (do_one_comp): Likewise.
(build_comparison_op): Likewise.
* module.cc (trees_out::type_node): Handle DEPENDENT_OPERATOR_TYPE.
(trees_in::tree_node): Likewise.
* name-lookup.c (lookup_name): Revert r11-2876 change.
(op_unqualified_lookup): Remove.
(maybe_save_operator_binding): Remove.
(discard_operator_bindings): Remove.
(push_operator_bindings): Remove.
* name-lookup.h (maybe_save_operator_binding): Remove.
(push_operator_bindings): Remove.
(discard_operator_bindings): Remove.
* parser.c (cp_parser_unary_expression): Adjust calls to build_x_*.
(cp_parser_binary_expression): Likewise.
(cp_parser_assignment_expression): Likewise.
(cp_parser_expression): Likewise.
(do_range_for_auto_deduction): Likewise.
(cp_convert_range_for): Li

Re: [Patch 6/8 V2] Arm: Add pointer authentication for stack-unwinding runtime.

[Andrea Corallo via Gcc-patches]

Richard Earnshaw  writes:

> On 09/12/2021 17:36, Andrea Corallo via Gcc-patches wrote:
>> Richard Earnshaw via Gcc-patches  writes:
>> 
>>> On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote:

> -Original Message-
> From: Gcc-patches  bounces+belagod=gcc.gnu@gcc.gnu.org> On Behalf Of Tejas Belagod via
> Gcc-patches
> Sent: Friday, October 8, 2021 1:18 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [Patch 5/7, Arm. GCC] Add pointer authentication for stack-
> unwinding runtime.
>
> Hi,
>
> This patch adds authentication for when the stack is unwound when an
> exception is taken.  All the changes here are done to the runtime code in
> libgcc's unwinder code for Arm target. All the changes are guarded under
> defined (__ARM_FEATURE_PAC_DEFAULT) and activates only if the +pacbti
> feature is switched on for the architecture. This means that switching on 
> the
> target feature via -march or -mcpu is sufficient and -mbranch-protection
> need not be enabled. This ensures that the unwinder is authenticated only 
> if
> the PACBTI instructions are available in the non-NOP space as it uses 
> AUTG.
> Just generating PAC/AUT instructions using -mbranch-protection will not
> enable authentication on the unwinder.
>
> Tested on arm-none-eabi. OK for trunk?
>
> 2021-10-04  Tejas Belagod  
>
> gcc/ChangeLog:
>
>   * ginclude/unwind-arm-common.h (_Unwind_VRS_RegClass):
> Introduce
>   new pseudo register class _UVRSC_PAC.
>   * libgcc/config/arm/pr-support.c (__gnu_unwind_execute): Decode
>   exception opcode (0xb4) for saving RA_AUTH_CODE and
> authenticate
>   with AUTG if found.
>   * libgcc/config/arm/unwind-arm.c (struct pseudo_regs): New.
>   (phase1_vrs): Introduce new field to store pseudo-reg state.
>   (phase2_vrs): Likewise.
>   (_Unwind_VRS_Get): Load pseudo register state from virtual reg set.
>   (_Unwind_VRS_Set): Store pseudo register state to virtual reg set.
>   (_Unwind_VRS_Pop): Load pseudo register value from stack into
> VRS.
 Rebased and respin based on reviews for previous patches.
 This patch adds authentication for when the stack is unwound when
 an exception is taken.  All the changes here are done to the runtime
 code in libgcc's unwinder code for Arm target. All the changes are
 guarded under defined (__ARM_FEATURE_PAUTH) and activates only
 if the +pacbti feature is switched on for the architecture. This means
 that switching on the target feature via -march or -mcpu is sufficient
 and -mbranch-protection need not be enabled. This ensures that the
 unwinder is authenticated only if the PACBTI instructions are available
 in the non-NOP space as it uses AUTG. Just generating PAC/AUT instructions
 using -mbranch-protection will not enable authentication on the unwinder.
 2021-10-25  Tejas Belagod  
 gcc/ChangeLog:
* ginclude/unwind-arm-common.h (_Unwind_VRS_RegClass):
 Introduce
new pseudo register class _UVRSC_PAC.
* libgcc/config/arm/pr-support.c (__gnu_unwind_execute): Decode
exception opcode (0xb4) for saving RA_AUTH_CODE and authenticate
with AUTG if found.
* libgcc/config/arm/unwind-arm.c (struct pseudo_regs): New.
(phase1_vrs): Introduce new field to store pseudo-reg state.
(phase2_vrs): Likewise.
(_Unwind_VRS_Get): Load pseudo register state from virtual reg set.
(_Unwind_VRS_Set): Store pseudo register state to virtual reg set.
(_Unwind_VRS_Pop): Load pseudo register value from stack into VRS.
 Tested the following configurations, OK for trunk?
 -mthumb/-march=armv8.1-m.main+pacbti/-mfloat-abi=soft
 -marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp
 mcmodel=small and tiny
 aarch64-none-linux-gnu native test and bootstrap
 Thanks,
 Tejas.

>> 
>>> I'd like to try to get rid of most of the ifdefs from this patch; at
>>> least, it shouldn't be using the ACLE PAUTH feature.  The unwinder
>>> should be able to cope with any unwind sequence thrown at it.
>>>
>>> Things are a little more complicated for pointer authentication,
>>> though, because some operations in the main code constructing the
>>> frame may be using architectural NOP instructions, while the unwinder
>>> cannot do the validation using only the architectural NOPs.
>>>
>>> So we need a fall-back: if the unwinder is built without the PAUTH
>>> feature it needs to unwind the pauth frames without the additional
>>> validation (but it still needs to be able to handle them).
>>>
>>> So the only remaining question is whether the additional support
>>> should only be enabled for M-profile targets, or whether we should
>>> just put this code into all builds of the unwinder.  I'm not sure I
>>> have a complete answer to that.  My inclination is to put it in
>>>

[PATCH] Improved handling of REG_UNUSED notes on PARALLEL in try_combine.

[Roger Sayle]

This patch is the middle-end piece of a set of patches for PR target/43892,
that improves combine's ability to optimize instructions with multiple
side-effects, such as updating explicit carry (flag) registers.

In RTL, an instruction that updates multiple registers is represented
as a PARALLEL of several SETs, such as PowerPC's subfc instruction:

(insn 80 79 81 4 (parallel [
(set (reg:SI 143)
(minus:SI (reg/v:SI 142 [  ])
(reg:SI 141 [ _16 ])))
(set (reg:SI 98 ca)
(leu:SI (reg:SI 141 [ _16 ])
(reg/v:SI 142 [  ])))
]) "../pr43892.c":8:6 104 {subfsi3_carry}
 (expr_list:REG_DEAD (reg:SI 141 [ _16 ])
(expr_list:REG_UNUSED (reg:SI 143)
(nil

As shown above, it's relatively common for only one of the results
of these instructions to be used, and the other destination register(s)
ignored, annotated with a REG_UNUSED note (as above).

This patch teaches combine to take advantage of these REG_UNUSED
annotations when trying to simplify instruction sequences.
Currently, these annotations are ignored and the useless SETs
preserved in try_combine's combination attempts:

Trying 79 -> 80:
   79: r142:SI=r139:SI+r141:SI
  REG_DEAD r139:SI
   80: {r143:SI=r142:SI-r141:SI;ca:SI=leu(r141:SI,r142:SI);}
  REG_DEAD r141:SI
  REG_UNUSED r143:SI
Failed to match this instruction:
(parallel [
(set (reg:SI 143)
(reg/v:SI 139 [  ]))
(set (reg:SI 98 ca)
(geu:SI (plus:SI (reg/v:SI 139 [  ])
(reg:SI 141 [ _16 ]))
(reg/v:SI 139 [  ])))
(set (reg/v:SI 142 [  ])
(plus:SI (reg/v:SI 139 [  ])
(reg:SI 141 [ _16 ])))
])

Notice that the combined/fused instruction passed to recog contains
a (set (reg:SI 143) (reg:139)), even though r143 was marked as unused
in the input sequence.  Fortunately, it's trivial to prune these
vestigial SETs, using the logic in single_set to determine that
only one of the SETs in a PARALLEL is useful, or expressed another
way, that the parallel can be simplified to the single_set.

This patch has been tested on x86_64-pc-linux-gnu with a make
bootstrap and make -k check with no new failures, and in
combination with other patches on powerpc64-unknown-linux-gnu
(c.f. https://gcc.gnu.org/pipermail/gcc-patches/2021-December/585977.html)
I'll include a testcase for this functionality with the final
rs6000 backend patch in the series.

Ok for mainline?


2021-12-10  Roger Sayle  

gcc/ChangeLog
* combine.c (try_combine): When I2 or I3 is PARALLEL without
clobbers that is effectively just a single_set, just use that
SET during the recombination/fusion attempt.


Thanks in advance,
Roger
--

diff --git a/gcc/combine.c b/gcc/combine.c
index 03e9a78..07f70b3 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -2901,6 +2901,17 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1, 
rtx_insn *i0,
  alloc_insn_link (i1, regno, LOG_LINKS (i2)));
 }
 
+  /* If I2 is a PARALLEL with only one useful SET and without clobbers,
+ transform I2 into that SET.  */
+  if (GET_CODE (PATTERN (i2)) == PARALLEL
+  && GET_CODE (XVECEXP (PATTERN (i2), 0, XVECLEN (PATTERN (i2), 0) - 1))
+!= CLOBBER)
+{
+  rtx tmp = single_set (i2);
+  if (tmp)
+SUBST (PATTERN (i2), tmp);
+}
+
   /* If I2 is a PARALLEL of two SETs of REGs (and perhaps some CLOBBERs),
  make those two SETs separate I1 and I2 insns, and make an I0 that is
  the original I1.  */
@@ -3389,6 +3400,18 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1, 
rtx_insn *i0,
   int extra_sets = added_sets_0 + added_sets_1 + added_sets_2;
   combine_extras++;
 
+  /* If I3 was a PARALLEL with only one useful SET, we can discard
+the other SETs now before constructing the new PARALLEL.  */
+  if (GET_CODE (newpat) == PARALLEL
+ && newpat == PATTERN (i3)
+  && GET_CODE (XVECEXP (newpat, 0, XVECLEN (newpat, 0) - 1))
+!= CLOBBER)
+   {
+ rtx tmp = single_set (i3);
+ if (tmp)
+   newpat = tmp;
+   }
+
   if (GET_CODE (newpat) == PARALLEL)
{
  rtvec old = XVEC (newpat, 0);

Re: [PATCH 3/4] libgcc: vxcrtstuff.c: make ctor/dtor functions static

[Olivier Hainque via Gcc-patches]

Hi again Rasmus,

> On 1 Nov 2021, at 10:34, Rasmus Villemoes  wrote:
> 
> When the translation unit itself creates pointers to the ctors/dtors
> in a specific section handled by the linker (whether .init_array or
> .ctors.*), there's no reason for the functions to have external
> linkage. That ends up polluting the symbol table in the running
> kernel.
> 
> This makes vxcrtstuff.c on par with the generic crtstuff.c which also
> defines e.g. frame_dummy and __do_global_dtors_aux static.
> 
> libgcc/
>   * config/vxcrtstuff.c: Make constructor and destructor
>   functions static when possible.


This is OK, can you please commit?

Thanks!

Cheers,

Olivier

[committed] libstdc++: Guard mutex and condvar with gthreads macro [PR103638]

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux --enable-threads={posix,single}, pushed to
trunk.  The testsuite is now clean for --enable-threads=single (apart
from the expected abi-check failures, because the baselines are for the
posix thread model).



A mutex and condition variable is used for timed waits on atomics if
there is no "platform wait" (e.g. futex) supported. But the use of those
types wasn't guarded by the _GLIBCXX_HAS_GTHREADS macro, causing errors
for --disable-threads builds. This fix allows  to work on
targets with futexes but no gthreads.

libstdc++-v3/ChangeLog:

PR libstdc++/103638
* include/bits/atomic_timed_wait.h: Check _GLIBCXX_HAS_GTHREADS
before using std::mutex and std::__condvar.
---
 libstdc++-v3/include/bits/atomic_timed_wait.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/libstdc++-v3/include/bits/atomic_timed_wait.h 
b/libstdc++-v3/include/bits/atomic_timed_wait.h
index efbe3da8b6c..ba83398285c 100644
--- a/libstdc++-v3/include/bits/atomic_timed_wait.h
+++ b/libstdc++-v3/include/bits/atomic_timed_wait.h
@@ -137,6 +137,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 // (e.g. __ulock_wait())which is better than pthread_cond_clockwait
 #endif // ! PLATFORM_TIMED_WAIT
 
+#ifdef _GLIBCXX_HAS_GTHREADS
 // Returns true if wait ended before timeout.
 // _Clock must be either steady_clock or system_clock.
 template
@@ -192,6 +193,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return false;
  }
   }
+#endif // _GLIBCXX_HAS_GTHREADS
 
 struct __timed_waiter_pool : __waiter_pool_base
 {
@@ -239,6 +241,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
if (_M_deadline <= __now)
  return false;
 
+   // FIXME: this_thread::sleep_for not available #ifdef _GLIBCXX_NO_SLEEP
+
auto __elapsed = __now - _M_t0;
if (__elapsed > 128ms)
  {
-- 
2.31.1

[committed] libstdc++: Fix definition of _GLIBCXX_NO_SLEEP config macro

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux --enable-threads={posix,single}, pushed to trunk.


If no OS function to sleep (e.g. nanosleep, usleep, Win32 Sleep etc.) is
available then configure defines the macro NO_SLEEP. But this will not
get prefixed with "_GLIBCXX_" because include/Makefile.am only does that
for macros beginning with "HAVE_". The configure script should define
_GLIBCXX_NO_SLEEP instead (which is what the code actually checks for).

libstdc++-v3/ChangeLog:

* acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Add _GLIBCXX_
prefix to NO_SLEEP macro.
* config.h.in: Regenerate.
* configure: Regenerate.
---
 libstdc++-v3/acinclude.m4 | 2 +-
 libstdc++-v3/config.h.in  | 6 +++---
 libstdc++-v3/configure| 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 6d9a8875e31..635168d7e25 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -1562,7 +1562,7 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME], [
   fi
 
   if test x"$ac_no_sleep" = x"yes"; then
-AC_DEFINE(NO_SLEEP,1, [Defined if no way to sleep is available.])
+AC_DEFINE(_GLIBCXX_NO_SLEEP,1, [Defined if no way to sleep is available.])
   fi
 
   AC_SUBST(GLIBCXX_LIBS)
diff --git a/libstdc++-v3/config.h.in b/libstdc++-v3/config.h.in
index 420021fcb1a..10675fe2530 100644
--- a/libstdc++-v3/config.h.in
+++ b/libstdc++-v3/config.h.in
@@ -714,9 +714,6 @@
*/
 #undef LT_OBJDIR
 
-/* Defined if no way to sleep is available. */
-#undef NO_SLEEP
-
 /* Name of package */
 #undef PACKAGE
 
@@ -838,6 +835,9 @@
 /* Define if C99 llrint and llround functions are missing from . */
 #undef _GLIBCXX_NO_C99_ROUNDING_FUNCS
 
+/* Defined if no way to sleep is available. */
+#undef _GLIBCXX_NO_SLEEP
+
 /* Define if ptrdiff_t is int. */
 #undef _GLIBCXX_PTRDIFF_T_IS_INT
 
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 61a14a2cb3b..b1a0157d0b9 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -21006,7 +21006,7 @@ $as_echo "$ac_has_win32_sleep" >&6; }
 
   if test x"$ac_no_sleep" = x"yes"; then
 
-$as_echo "#define NO_SLEEP 1" >>confdefs.h
+$as_echo "#define _GLIBCXX_NO_SLEEP 1" >>confdefs.h
 
   fi
 
-- 
2.31.1

[PATCH] Fix inaccuracies in VxWorks LINK_SPEC

[Olivier Hainque via Gcc-patches]

Hello,

The attached patch fixes a couple of incorrect things in
the VxWorks default LINK_SPEC, exposed during our work on
the support for building shared libraries.

-v needs to generate a -V not -v, as most/all other ports do,
to output the available emulations.

The latter causes collect2 to output exec'd collect-ld with same
switches, which in turn causes a configure test which accumulates
linker switches to contain duplicates, leading to a libstdc++ configure
failure in some configurations.

The change also removes reference to %(link_target), long obsolete.

Tested with builds and test runs on VxWorks 6.9 and 7.2.

Olivier


2021-12-07  Doug Rupp  

* config/vxworks.h (LINK_SPEC): Remove %(link_target).
Change %{v:-v} to %{v:-V}.



0001-Fix-inaccuracies-in-VxWorks-LINK_SPEC.patch
Description: Binary data

Re: [committed 4/4] d: Merge upstream phobos 574bf883b

[Iain Buclaw via Gcc-patches]

Excerpts from Iain Buclaw's message of December 9, 2021 11:11 pm:
> Excerpts from Andreas Schwab's message of December 9, 2021 11:09 am:
>> Breaks aarch64:
>> 
>> ../../../../libphobos/libdruntime/core/sys/linux/unistd.d:10:15: error: 
>> module 'core.sys.linux.syscalls' import 'SystemCall' not found
>>10 | public import core.sys.linux.syscalls : SystemCall;
>>   |   ^
>> 
> 
> Hi Andreas,
> 
> Thanks!  I've raised a revert for the change in upstream that broke
> this.  Unfortunately they only considered X86 and X86_64 in the change.
> 

Patch was included as part of r12-5887.

Iain.

[PATCH] Remove assignment to STMP_FIXINC from t-vxworks

[Olivier Hainque via Gcc-patches]

Hello,

The attached patch just removes the assignment to STMP_FIXINC
from t-vxworks.

This aligns VxWorks with what the vast majority of targets do
and the value set was redundant with the default Makefile setting
anyway, possibly confusing on a target when the management
of fixincludes is pretty sensitive (more patches coming for that).

Tested with build + tests on both Vxworks 6.9 and 7.2.

Olivier

2021-12-07  Olivier Hainque  

* config/t-vxworks: Remove assignment to STMP_FIXINC.



0001-Remove-assignment-to-STMP_FIXINC-from-t-vxworks.patch
Description: Binary data

Re: [PATCH] replace t-ppccomm for libgcc powerpc*-vxworks*

[Olivier Hainque via Gcc-patches]

> On 10 Dec 2021, at 14:29, Rasmus Villemoes  wrote:
> 
> On 10/12/2021 14.08, Olivier Hainque wrote:
>> Hello,
>> 
>> The attached patch is the one originally sent by Rasmus at
>> 
>>  https://gcc.gnu.org/pipermail/gcc-patches/2018-October/508026.html. (*)
>> 
>> and which escaped the radar at the time.
>> 
>> The change looked good and turned out helpful in the context of
>> work on the support of shared library for VxWorks.
>> 
>> Tested on VxWorks 7.2 and sanity checked with a build for VxWorks 6.9,
>> I'll commit shortly.
> 
> Thanks, I've actually been carrying that locally ever since (because I
> have other changes on top that rely on it), so I'm quite confident
> including that upstream won't break anything on my end :)

Great, thanks for confirming.

I still have a few minor cleanups to post, then
a few more involved, starting with one regarding the use
of sysroot prior to the bits more geared towards shared
libraries.

Cheers,

Olivier

Re: [PATCH] replace t-ppccomm for libgcc powerpc*-vxworks*

[Rasmus Villemoes]

On 10/12/2021 14.08, Olivier Hainque wrote:
> Hello,
> 
> The attached patch is the one originally sent by Rasmus at
> 
>   https://gcc.gnu.org/pipermail/gcc-patches/2018-October/508026.html. (*)
> 
> and which escaped the radar at the time.
> 
> The change looked good and turned out helpful in the context of
> work on the support of shared library for VxWorks.
> 
> Tested on VxWorks 7.2 and sanity checked with a build for VxWorks 6.9,
> I'll commit shortly.

Thanks, I've actually been carrying that locally ever since (because I
have other changes on top that rely on it), so I'm quite confident
including that upstream won't break anything on my end :)

Rasmus

Re: pr103523: Check for PLUS/MINUS support

[Joel Hutton via Gcc-patches]

ok for backport to 11?

From: Richard Sandiford 
Sent: 10 December 2021 10:22
To: Joel Hutton 
Cc: GCC Patches ; Richard Biener 
Subject: Re: pr103523: Check for PLUS/MINUS support

Joel Hutton  writes:
> Hi all,
>
> This is to address pr103523.
>
> bootstrapped and regression tested on aarch64.
>
> Check for PLUS_EXPR/MINUS_EXPR support in vectorizable_induction.
> PR103523 is an ICE on valid code:
>
> void d(float *a, float b, int c) {
> float e;
> for (; c; c--, e += b)
>   a[c] = e;
> }
>
> This is due to not checking for PLUS_EXPR support, which is missing in
> VNx2sf mode. This causes an ICE at expand time. This patch adds a check
> for support in vectorizable_induction.
>
> gcc/ChangeLog:
>
> PR tree-optimization/PR103523

The bugzilla hook expects: PR tree-optimization/103523

> * tree-vect-loop.c (vectorizable_induction): Check for
> PLUS_EXPR/MINUS_EXPR support.

OK, thanks.

Richard

[PATCH] replace t-ppccomm for libgcc powerpc*-vxworks*

[Olivier Hainque via Gcc-patches]

Hello,

The attached patch is the one originally sent by Rasmus at

  https://gcc.gnu.org/pipermail/gcc-patches/2018-October/508026.html. (*)

and which escaped the radar at the time.

The change looked good and turned out helpful in the context of
work on the support of shared library for VxWorks.

Tested on VxWorks 7.2 and sanity checked with a build for VxWorks 6.9,
I'll commit shortly.

Thanks for proposing it in the first place Rasmus :)

2021-12-07  Rasmus Villemoes  

libgcc/
* config/rs6000/t-vxworks: New file.
* config.host (powerpc*-*-vxworks*): Use it instead of
t-ppccomm.

---

(*)

VxWorks doesn't use the __eabi function (in fact, the ecrti.o and
ecrtn.o files are not added to extra_parts). This means that the
__SBSS_END__ etc. symbols in eabi.S are always undefined. This is mostly
harmless, but it is inconvenient when one wants to create a libgcc
runtime module by doing a --whole-archive link of libgcc.a.

Moreover, it turns out that ibm-ldouble.o ends up being empty for
powerpc-wrs-vxworks, since only __ppc__ and __PPC__ are
TARGET_OS_CPP_BUILTINS, while the entire ibm-ldouble.c is protected by

#if (defined (__MACH__) || defined (__powerpc__) || defined (_AIX)) \
&& !defined (__rtems__)

To avoid the above inconvenience, and make it a little more clear what
actually gets built and used for powerpc-wrs-vxworks, create a new
t-vxworks which adds tramp.S to LIB2ADD, and use that instead of
t-ppccomm.

---



0001-Replace-t-ppccomm-by-t-vxworks-in-libgcc-config-rs60.patch
Description: Binary data

Re: [PATCH] inline: fix ICE with -fprofile-generate

[Jan Hubicka via Gcc-patches]

> Fixes ICE spotted by Honza where we have a better place where
> to check for no_profile_instrument_function attribute.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
>   PR ipa/103636
> 
> gcc/ChangeLog:
> 
>   * ipa-inline.c (can_inline_edge_p): Move logic checking
>   no_profile_instrument_function logic to ...
>   (can_early_inline_edge_p): ... here.
OK, thanks!
Honza

[PATCH] pch: Small cleanup

[Jakub Jelinek via Gcc-patches]

On Thu, Dec 09, 2021 at 05:59:54PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > /tmp/6140018_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/aarch64/aarch64-sve-builtins.cc:3920:0:
> > ./gt-aarch64-sve-builtins.h: In function 'void
> > gt_pch_p_19registered_function(void*, void*, gt_pointer_operator, void*)':
> > ./gt-aarch64-sve-builtins.h:86:44: error: no matching function for call to
> > 'gt_pch_nx(aarch64_sve::function_instance*, void (*&)(void*, void*, void*),
> > void*&)'
> >  gt_pch_nx (&((*x).instance), op, cookie);
> 
> Fixed thusly, compile tested on x86_64-linux, committed to trunk.

Here is a small cleanup.  IMHO we should use gt_pointer_operator instead of
specifying manually void (*) (void *, void *) or
void (*) (void *, void *, void *) so that next time we want to change it,
we don't have to trace all the spots.  I was afraid it wouldn't work due to
header dependencies, but it works well.  gengtype generated files also
use gt_pointer_operator.

Ok for trunk (tested on x86_64-linux and cross to aarch64-linux)?

2021-12-10  Jakub Jelinek  

* machmode.h (gt_pch_nx): Use gt_pointer_operator as type of second
argument instead of equivalent void (*) (void *, void *, void *).
* poly-int.h (gt_pch_nx): Likewise.
* wide-int.h (gt_pch_nx): Likewise.
* config/aarch64/aarch64-sve-builtins.cc (gt_pch_nx): Likewise.

--- gcc/machmode.h.jj   2021-12-09 15:40:06.145023853 +0100
+++ gcc/machmode.h  2021-12-10 13:40:47.858430024 +0100
@@ -1199,7 +1199,7 @@ gt_pch_nx (pod_mode *)
 
 template
 void
-gt_pch_nx (pod_mode *, void (*) (void *, void *, void *), void *)
+gt_pch_nx (pod_mode *, gt_pointer_operator, void *)
 {
 }
 
--- gcc/poly-int.h.jj   2021-12-09 15:40:06.159023652 +0100
+++ gcc/poly-int.h  2021-12-10 13:41:05.476178926 +0100
@@ -2717,7 +2717,7 @@ gt_pch_nx (poly_int_pod *)
 
 template
 void
-gt_pch_nx (poly_int_pod *, void (*) (void *, void *, void *), void *)
+gt_pch_nx (poly_int_pod *, gt_pointer_operator, void *)
 {
 }
 
--- gcc/wide-int.h.jj   2021-12-09 15:40:06.218022803 +0100
+++ gcc/wide-int.h  2021-12-10 13:41:35.405752355 +0100
@@ -3338,7 +3338,7 @@ gt_pch_nx (generic_wide_int  *)
 
 template
 void
-gt_pch_nx (generic_wide_int  *, void (*) (void *, void *, void *), void *)
+gt_pch_nx (generic_wide_int  *, gt_pointer_operator, void *)
 {
 }
 
@@ -3356,7 +3356,7 @@ gt_pch_nx (trailing_wide_ints  *)
 
 template
 void
-gt_pch_nx (trailing_wide_ints  *, void (*) (void *, void *, void *), void *)
+gt_pch_nx (trailing_wide_ints  *, gt_pointer_operator, void *)
 {
 }
 
--- gcc/config/aarch64/aarch64-sve-builtins.cc.jj   2021-12-09 
17:56:53.445371821 +0100
+++ gcc/config/aarch64/aarch64-sve-builtins.cc  2021-12-10 13:42:03.112357466 
+0100
@@ -3913,7 +3913,7 @@ gt_pch_nx (function_instance *)
 }
 
 inline void
-gt_pch_nx (function_instance *, void (*) (void *, void *, void *), void *)
+gt_pch_nx (function_instance *, gt_pointer_operator, void *)
 {
 }
 


Jakub

[PATCH] inline: fix ICE with -fprofile-generate

[Martin Liška]

Fixes ICE spotted by Honza where we have a better place where
to check for no_profile_instrument_function attribute.

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

Ready to be installed?
Thanks,
Martin

PR ipa/103636

gcc/ChangeLog:

* ipa-inline.c (can_inline_edge_p): Move logic checking
no_profile_instrument_function logic to ...
(can_early_inline_edge_p): ... here.
---
 gcc/ipa-inline.c | 25 +
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index 54cd085a84d..a1c312f1774 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -396,22 +396,6 @@ can_inline_edge_p (struct cgraph_edge *e, bool report,
   e->inline_failed = CIF_SANITIZE_ATTRIBUTE_MISMATCH;
   inlinable = false;
 }
-  else if (profile_arc_flag
-  && (lookup_attribute ("no_profile_instrument_function",
-DECL_ATTRIBUTES (caller->decl)) == NULL_TREE)
-  != (lookup_attribute ("no_profile_instrument_function",
-DECL_ATTRIBUTES (callee->decl)) == NULL_TREE))
-{
-  cgraph_node *origin = caller;
-  while (origin->clone_of)
-   origin = origin->clone_of;
-
-  if (!DECL_STRUCT_FUNCTION 
(origin->decl)->always_inline_functions_inlined)
-   {
- e->inline_failed = CIF_UNSPECIFIED;
- inlinable = false;
-   }
-}
 
   if (!inlinable && report)

 report_inline_failed_reason (e);
@@ -637,6 +621,8 @@ can_inline_edge_by_limits_p (struct cgraph_edge *e, bool 
report,
 static bool
 can_early_inline_edge_p (struct cgraph_edge *e)
 {
+  cgraph_node *caller = (e->caller->inlined_to
+? e->caller->inlined_to : e->caller);
   struct cgraph_node *callee = e->callee->ultimate_alias_target ();
   /* Early inliner might get called at WPA stage when IPA pass adds new
  function.  In this case we cannot really do any of early inlining
@@ -660,6 +646,13 @@ can_early_inline_edge_p (struct cgraph_edge *e)
 "  edge not inlinable: not in SSA form\n");
   return false;
 }
+  else if (profile_arc_flag
+  && ((lookup_attribute ("no_profile_instrument_function",
+DECL_ATTRIBUTES (caller->decl)) == NULL_TREE)
+  != (lookup_attribute ("no_profile_instrument_function",
+DECL_ATTRIBUTES (callee->decl)) == 
NULL_TREE)))
+return false;
+
   if (!can_inline_edge_p (e, true, true)
   || !can_inline_edge_by_limits_p (e, true, false, true))
 return false;
--
2.34.1

[PATCH] libstdc++: Add std::time_get %r support [PR71367]

[Jakub Jelinek via Gcc-patches]

Hi!

This incremental patch adds std::time_get %r support (%p was added already
in the previous patch).  The _M_am_fm_format method previously in the header
unfortunately had wrong arguments and so was useless, so the largest
complication in this patch is exporting a new symbol in the right symbol
version.

Tested on x86_64-linux, ok for trunk?

2021-12-10  Jakub Jelinek  

PR libstdc++/71367
* config/locale/dragonfly/time_members.cc (_M_initialize_timepunct):
Initialize "C" _M_am_pm_format to %I:%M:%S %p rather than empty
string.
* config/locale/gnu/time_members.cc (_M_initialize_timepunct):
Likewise.
* config/locale/generic/time_members.cc (_M_initialize_timepunct):
Likewise.
* include/bits/locale_facets_nonio.h (_M_am_pm_format): New method.
* include/bits/locale_facets_nonio.tcc (_M_extract_via_format): Handle
%r.
* config/abi/pre/gnu.ver (GLIBCXX_3.4.30): Export _M_am_pm_format
with const _CharT** argument, ensure it isn't exported in GLIBCXX_3.4.
* testsuite/22_locale/time_get/get/char/71367.cc: New test.
* testsuite/22_locale/time_get/get/wchar_t/71367.cc: New test.

--- libstdc++-v3/config/locale/dragonfly/time_members.cc.jj 2021-01-05 
00:13:58.281297350 +0100
+++ libstdc++-v3/config/locale/dragonfly/time_members.cc2021-12-10 
12:27:18.350425776 +0100
@@ -74,7 +74,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  _M_data->_M_date_time_era_format = "";
  _M_data->_M_am = "AM";
  _M_data->_M_pm = "PM";
- _M_data->_M_am_pm_format = "";
+ _M_data->_M_am_pm_format = "%I:%M:%S %p";
 
  // Day names, starting with "C"'s Sunday.
  _M_data->_M_day1 = "Sunday";
@@ -231,7 +231,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  _M_data->_M_date_time_era_format = L"";
  _M_data->_M_am = L"AM";
  _M_data->_M_pm = L"PM";
- _M_data->_M_am_pm_format = L"";
+ _M_data->_M_am_pm_format = L"%I:%M:%S %p";
 
  // Day names, starting with "C"'s Sunday.
  _M_data->_M_day1 = L"Sunday";
--- libstdc++-v3/config/locale/gnu/time_members.cc.jj   2021-01-05 
00:13:58.282297338 +0100
+++ libstdc++-v3/config/locale/gnu/time_members.cc  2021-12-10 
12:26:52.979787605 +0100
@@ -80,7 +80,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  _M_data->_M_date_time_era_format = "";
  _M_data->_M_am = "AM";
  _M_data->_M_pm = "PM";
- _M_data->_M_am_pm_format = "";
+ _M_data->_M_am_pm_format = "%I:%M:%S %p";
 
  // Day names, starting with "C"'s Sunday.
  _M_data->_M_day1 = "Sunday";
@@ -236,7 +236,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  _M_data->_M_date_time_era_format = L"";
  _M_data->_M_am = L"AM";
  _M_data->_M_pm = L"PM";
- _M_data->_M_am_pm_format = L"";
+ _M_data->_M_am_pm_format = L"%I:%M:%S %p";
 
  // Day names, starting with "C"'s Sunday.
  _M_data->_M_day1 = L"Sunday";
--- libstdc++-v3/config/locale/generic/time_members.cc.jj   2021-01-05 
00:13:58.282297338 +0100
+++ libstdc++-v3/config/locale/generic/time_members.cc  2021-12-10 
12:27:55.433896906 +0100
@@ -72,7 +72,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _M_data->_M_date_time_era_format = "";
   _M_data->_M_am = "AM";
   _M_data->_M_pm = "PM";
-  _M_data->_M_am_pm_format = "";
+  _M_data->_M_am_pm_format = "%I:%M:%S %p";
 
   // Day names, starting with "C"'s Sunday.
   _M_data->_M_day1 = "Sunday";
@@ -157,7 +157,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _M_data->_M_date_time_era_format = L"";
   _M_data->_M_am = L"AM";
   _M_data->_M_pm = L"PM";
-  _M_data->_M_am_pm_format = L"";
+  _M_data->_M_am_pm_format = L"%I:%M:%S %p";
 
   // Day names, starting with "C"'s Sunday.
   _M_data->_M_day1 = L"Sunday";
--- libstdc++-v3/include/bits/locale_facets_nonio.h.jj  2021-04-06 
23:49:08.318882385 +0200
+++ libstdc++-v3/include/bits/locale_facets_nonio.h 2021-12-10 
12:55:26.240337962 +0100
@@ -243,6 +243,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif
 
   void
+  _M_am_pm_format(const _CharT** __ampm_format) const
+  {
+   __ampm_format[0] = _M_data->_M_am_pm_format;
+  }
+
+  void
   _M_am_pm(const _CharT** __ampm) const
   {
__ampm[0] = _M_data->_M_am;
--- libstdc++-v3/include/bits/locale_facets_nonio.tcc.jj2021-12-09 
22:52:34.892266539 +0100
+++ libstdc++-v3/include/bits/locale_facets_nonio.tcc   2021-12-10 
12:56:02.721816838 +0100
@@ -806,6 +806,13 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11
  if (!__tmperr && __mem)
__tm->tm_hour += 12;
  break;
+   case 'r':
+ // Locale's 12-hour clock time format (in C %I:%M:%S %p).
+ const char_type*  __ampm_format;
+ __tp._M_am_pm_format(&__ampm_format);
+ __beg = _M_extract_via_format

[PATCH][pushed] param: Add missing . in description.

[Martin Liška]

Fixes:
FAIL: compiler driver --help=param option(s): "^ +-.*[^:.]$" absent from output: 
"
--param=max-inline-functions-called-once-loop-depth= Maximum loop depth of a call 
which is considered for inlining functions called once"
FAIL: compiler driver --help=params option(s): "[^.]$" absent from output: "e"

gcc/ChangeLog:

* params.opt: Add missing dot.
---
 gcc/params.opt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/params.opt b/gcc/params.opt
index f1b5757461c..80ec6546bcd 100644
--- a/gcc/params.opt
+++ b/gcc/params.opt
@@ -547,7 +547,7 @@ Maximum depth of search in the dominator tree for 
expressions to hoist.
 
 -param=max-inline-functions-called-once-loop-depth=

 Common Joined UInteger Var(param_inline_functions_called_once_loop_depth) 
Init(6) Optimization Param
-Maximum loop depth of a call which is considered for inlining functions called 
once
+Maximum loop depth of a call which is considered for inlining functions called 
once.
 
 -param=max-inline-functions-called-once-insns=

 Common Joined UInteger Var(param_inline_functions_called_once_insns) 
Init(4000) Optimization Param
--
2.34.1

Re: [PATCH, v2] PR fortran/103418 - random_number() does not accept pointer, intent(in) array argument

[Mikael Morin]

On 09/12/2021 23:05, Harald Anlauf wrote:

Hi Mikael,

Am 08.12.21 um 10:32 schrieb Mikael Morin:

On 07/12/2021 21:46, Harald Anlauf wrote:

Hi Mikael,

Am 07.12.21 um 21:17 schrieb Mikael Morin:

The existing code looks dubious to me (or at least difficult to
understand), and your patch doesn’t make that any better.
I would rather try to remove the whole block, and fix the fallout on
move_alloc by adding calls to gfc_check_vardef_context in
gfc_check_move_alloc.
Can you try that instead?


I hadn't thought that far but will think about a possibly better
solution.


Hello,

I thought about it some more over night, and it is probably a poor
suggestion to restrict the check to move_alloc only.  The existing code
was added for move_alloc, but it has a broader scope.  Still,
gfc_check_vardef_context has the correct checks and is the one to be 
used.


I have played a little, and it took some time to understand the fallout.
Your suggestion to rely on gfc_check_vardef_context actually helped to
uncover another bug: a bad check for CLASS pointer.

Reading gfc_check_vardef_context, I have undersood what the existing 
code was doing, and why.  It was not that dubious after all.  Still, I 
prefer the v2 much.



See attached for an updated patch and the extended testcase.

Regtested again.  OK now?


Yes, thanks.

Re: [Patch 6/8 V2] Arm: Add pointer authentication for stack-unwinding runtime.

[Richard Earnshaw via Gcc-patches]

On 09/12/2021 17:36, Andrea Corallo via Gcc-patches wrote:

Richard Earnshaw via Gcc-patches  writes:


On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote:



-Original Message-
From: Gcc-patches  On Behalf Of Tejas Belagod via
Gcc-patches
Sent: Friday, October 8, 2021 1:18 PM
To: gcc-patches@gcc.gnu.org
Subject: [Patch 5/7, Arm. GCC] Add pointer authentication for stack-
unwinding runtime.

Hi,

This patch adds authentication for when the stack is unwound when an
exception is taken.  All the changes here are done to the runtime code in
libgcc's unwinder code for Arm target. All the changes are guarded under
defined (__ARM_FEATURE_PAC_DEFAULT) and activates only if the +pacbti
feature is switched on for the architecture. This means that switching on the
target feature via -march or -mcpu is sufficient and -mbranch-protection
need not be enabled. This ensures that the unwinder is authenticated only if
the PACBTI instructions are available in the non-NOP space as it uses AUTG.
Just generating PAC/AUT instructions using -mbranch-protection will not
enable authentication on the unwinder.

Tested on arm-none-eabi. OK for trunk?

2021-10-04  Tejas Belagod  

gcc/ChangeLog:

* ginclude/unwind-arm-common.h (_Unwind_VRS_RegClass):
Introduce
new pseudo register class _UVRSC_PAC.
* libgcc/config/arm/pr-support.c (__gnu_unwind_execute): Decode
exception opcode (0xb4) for saving RA_AUTH_CODE and
authenticate
with AUTG if found.
* libgcc/config/arm/unwind-arm.c (struct pseudo_regs): New.
(phase1_vrs): Introduce new field to store pseudo-reg state.
(phase2_vrs): Likewise.
(_Unwind_VRS_Get): Load pseudo register state from virtual reg set.
(_Unwind_VRS_Set): Store pseudo register state to virtual reg set.
(_Unwind_VRS_Pop): Load pseudo register value from stack into
VRS.

Rebased and respin based on reviews for previous patches.
This patch adds authentication for when the stack is unwound when
an exception is taken.  All the changes here are done to the runtime
code in libgcc's unwinder code for Arm target. All the changes are
guarded under defined (__ARM_FEATURE_PAUTH) and activates only
if the +pacbti feature is switched on for the architecture. This means
that switching on the target feature via -march or -mcpu is sufficient
and -mbranch-protection need not be enabled. This ensures that the
unwinder is authenticated only if the PACBTI instructions are available
in the non-NOP space as it uses AUTG. Just generating PAC/AUT instructions
using -mbranch-protection will not enable authentication on the unwinder.
2021-10-25  Tejas Belagod  
gcc/ChangeLog:
* ginclude/unwind-arm-common.h (_Unwind_VRS_RegClass):
Introduce
new pseudo register class _UVRSC_PAC.
* libgcc/config/arm/pr-support.c (__gnu_unwind_execute): Decode
exception opcode (0xb4) for saving RA_AUTH_CODE and authenticate
with AUTG if found.
* libgcc/config/arm/unwind-arm.c (struct pseudo_regs): New.
(phase1_vrs): Introduce new field to store pseudo-reg state.
(phase2_vrs): Likewise.
(_Unwind_VRS_Get): Load pseudo register state from virtual reg set.
(_Unwind_VRS_Set): Store pseudo register state to virtual reg set.
(_Unwind_VRS_Pop): Load pseudo register value from stack into VRS.
Tested the following configurations, OK for trunk?
-mthumb/-march=armv8.1-m.main+pacbti/-mfloat-abi=soft
-marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp
mcmodel=small and tiny
aarch64-none-linux-gnu native test and bootstrap
Thanks,
Tejas.




I'd like to try to get rid of most of the ifdefs from this patch; at
least, it shouldn't be using the ACLE PAUTH feature.  The unwinder
should be able to cope with any unwind sequence thrown at it.

Things are a little more complicated for pointer authentication,
though, because some operations in the main code constructing the
frame may be using architectural NOP instructions, while the unwinder
cannot do the validation using only the architectural NOPs.

So we need a fall-back: if the unwinder is built without the PAUTH
feature it needs to unwind the pauth frames without the additional
validation (but it still needs to be able to handle them).

So the only remaining question is whether the additional support
should only be enabled for M-profile targets, or whether we should
just put this code into all builds of the unwinder.  I'm not sure I
have a complete answer to that.  My inclination is to put it in
unconditionally - we haven't had conditionals for any other optional
architecture feature before.  If something similar is added for
A/R-profiles, then either we will share the code exactly, or we'll end
up with a different unwind code to use as a suitable discriminator.

R.


Hi Richard,

thanks for reviewing.

The attached patch implements what I think we want.  That unwinders is
always able to unwind the stack but will perform authentication onl

[PATCH] x86_64: Improve code expanded for highpart multiplications.

[Roger Sayle]

While working on a middle-end patch to more aggressively use highpart
multiplications on targets that support them, I noticed that the RTL
expanded by the x86 backend interacts poorly with register allocation
leading to suboptimal code.

For the testcase,
typedef int __attribute ((mode(TI))) ti_t;
long foo(long x)
{
  return ((ti_t)x * 19065) >> 64;
}

we'd like to avoid:
foo:movq%rdi, %rax
movl$19065, %edx
imulq   %rdx
movq%rdx, %rax
ret

and would prefer:
foo:movl$19065, %eax
imulq   %rdi
movq%rdx, %rax
ret

This patch provides a pair of peephole2 transformations to tweak the
spills generated by reload, and at the same time replaces the current
define_expand with define_insn patterns using the new [su]mul_highpart
RTX codes.  I've left the old-style patterns in the machine description
for the time being, but plan to remove these once my planned middle-end
improvements make them obsolete.

This patch has been tested on x86_64-pc-linux-gnu (both with and without
the middle-end changes) by make bootstrap and make -k check with no new
failures.  The new test case, which currently passes, ensures that the
code we generate isn't adversely affected by changes outside the backend.
Ok for mainline?


2021-12-10  Roger Sayle  

gcc/ChangeLog
* config/i386/i386.md (any_mul_highpart): New code iterator.
(sgnprefix, s): Add attribute support for [su]mul_highpart.
(mul3_highpart): Delete expander.
(muldi3_highpart, mulsi3_highpart, mulsi32_highpart_zext):
New define_insn patterns.
(define_peephole2): Tweak the register allocation for the above
instructions after reload.

gcc/testsuite/ChangeLog
* gcc.target/i386/smuldi3_highpart.c: New test case.


Thanks in advance,
Roger
--

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 4e9fae8..fc79146 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -992,11 +992,16 @@
 ;; Mapping of extend operators
 (define_code_iterator any_extend [sign_extend zero_extend])
 
+;; Mapping of highpart multiply operators
+(define_code_iterator any_mul_highpart [smul_highpart umul_highpart])
+
 ;; Prefix for insn menmonic.
 (define_code_attr sgnprefix [(sign_extend "i") (zero_extend "")
+(smul_highpart "i") (umul_highpart "")
 (div "i") (udiv "")])
 ;; Prefix for define_insn
-(define_code_attr s [(sign_extend "s") (zero_extend "u")])
+(define_code_attr s [(sign_extend "s") (zero_extend "u")
+(smul_highpart "s") (umul_highpart "u")])
 (define_code_attr u [(sign_extend "") (zero_extend "u")
 (div "") (udiv "u")])
 (define_code_attr u_bool [(sign_extend "false") (zero_extend "true")
@@ -8426,20 +8431,64 @@
(set_attr "bdver1_decode" "direct")
(set_attr "mode" "QI")])
 
-(define_expand "mul3_highpart"
-  [(parallel [(set (match_operand:DWIH 0 "register_operand")
-  (truncate:DWIH
-(lshiftrt:
-  (mult:
-(any_extend:
-  (match_operand:DWIH 1 "nonimmediate_operand"))
-(any_extend:
-  (match_operand:DWIH 2 "register_operand")))
-  (match_dup 3
- (clobber (scratch:DWIH))
- (clobber (reg:CC FLAGS_REG))])]
+;; Highpart multiplication patterns
+(define_insn "muldi3_highpart"
+  [(set (match_operand:DI 0 "register_operand" "=d")
+   (any_mul_highpart:DI
+ (match_operand:DI 1 "register_operand" "%a")
+ (match_operand:DI 2 "nonimmediate_operand" "rm")))
+   (clobber (match_scratch:DI 3 "=1"))
+   (clobber (reg:CC FLAGS_REG))]
+  "TARGET_64BIT"
+  "mul{q}\t%2"
+  [(set_attr "type" "imul")
+   (set_attr "length_immediate" "0")
+   (set (attr "athlon_decode")
+ (if_then_else (eq_attr "cpu" "athlon")
+   (const_string "vector")
+   (const_string "double")))
+   (set_attr "amdfam10_decode" "double")
+   (set_attr "bdver1_decode" "direct")
+   (set_attr "mode" "DI")])
+
+(define_insn "*mulsi3_highpart_zext"
+  [(set (match_operand:DI 0 "register_operand" "=d")
+   (zero_extend:DI 
+ (any_mul_highpart:SI
+   (match_operand:SI 1 "register_operand" "%a")
+   (match_operand:SI 2 "nonimmediate_operand" "rm"
+   (clobber (match_scratch:SI 3 "=1"))
+   (clobber (reg:CC FLAGS_REG))]
+  "TARGET_64BIT"
+  "mul{l}\t%2"
+  [(set_attr "type" "imul")
+   (set_attr "length_immediate" "0")
+   (set (attr "athlon_decode")
+ (if_then_else (eq_attr "cpu" "athlon")
+   (const_string "vector")
+   (const_string "double")))
+   (set_attr "amdfam10_decode" "double")
+   (set_attr "bdver1_decode" "direct")
+   (set_attr "mode" "SI")])
+
+(define_insn "*mulsi3_highpart"
+  [(set (match_operand:SI 0 "register_operand" "=d")
+   (any_mul_highpart:SI
+ (match_operand:SI 1 "r

[PATCH] symtab: Fold &a == &b to 0 if folding_initializer [PR94716]

[Jakub Jelinek via Gcc-patches]

Hi!

On Thu, Dec 09, 2021 at 06:09:12PM -0500, Jason Merrill wrote:
> For the more general comparison of decls like your a != b example above I
> think clang is in the right; in manifestly constant-evaluated context
> (folding_initializer) we should return that they are unequal and prevent a
> later alias declaration, like we do for comparison to 0 in
> maybe_nonzero_address.  It's possible that this gives a wrong answer based
> on something in another translation unit, but that's unlikely, and taking
> that chance seems better than rejecting code that needs a constant answer.

I agree.  This is an incremental patch to do that (so far untested),
Honza, what do you think about it?

2021-12-10  Jakub Jelinek  

PR c++/94716
gcc/
* symtab.c: Include fold-const.h.
(symtab_node::equal_address_to): If folding_initializer is true,
handle it like memory_accessed.  Simplify.
gcc/testsuite/
* gcc.dg/init-compare-1.c: New test.
* g++.dg/cpp0x/constexpr-compare1.C: New test.
* g++.dg/cpp1y/constexpr-94716.C: New test.
* g++.dg/cpp1z/constexpr-compare1.C: New test.

--- gcc/symtab.c.jj 2021-12-09 20:41:30.085566768 +0100
+++ gcc/symtab.c2021-12-10 11:14:56.072577457 +0100
@@ -38,6 +38,7 @@ along with GCC; see the file COPYING3.
 #include "stringpool.h"
 #include "attribs.h"
 #include "builtins.h"
+#include "fold-const.h"
 
 static const char *ipa_ref_use_name[] = {"read","write","addr","alias"};
 
@@ -2276,10 +2277,12 @@ symtab_node::equal_address_to (symtab_no
   return 0;
 }
 
+  if (rs1 == rs2)
+return -1;
+
   /* If the FE tells us at least one of the decls will never be aliased nor
  overlapping with other vars in some other way, return 0.  */
   if (VAR_P (decl)
-  && rs1 != rs2
   && (lookup_attribute ("non overlapping", DECL_ATTRIBUTES (decl))
  || lookup_attribute ("non overlapping", DECL_ATTRIBUTES (s2->decl
 return 0;
@@ -2288,9 +2291,14 @@ symtab_node::equal_address_to (symtab_no
  are different unless they are declared as alias of one to another while
  the code folding comparisons doesn't.
  We probably should be consistent and use this fact here, too, but for
- the moment return false only when we are called from the alias oracle.  */
+ the moment return false only when we are called from the alias oracle.
+ Return 0 in C constant initializers and C++ manifestly constant
+ expressions, the likelyhood that different vars will be aliases is
+ small and returning -1 lets us reject too many initializers.  */
+  if (memory_accessed || folding_initializer)
+return 0;
 
-  return memory_accessed && rs1 != rs2 ? 0 : -1;
+  return -1;
 }
 
 /* Worker for call_for_symbol_and_aliases.  */
--- gcc/testsuite/gcc.dg/init-compare-1.c.jj2021-12-10 11:31:45.839084036 
+0100
+++ gcc/testsuite/gcc.dg/init-compare-1.c   2021-12-10 11:32:08.551757661 
+0100
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+
+extern int a, b;
+int c = &a == &a;
+int d = &a != &b;
--- gcc/testsuite/g++.dg/cpp0x/constexpr-compare1.C.jj  2021-12-10 
11:25:58.579074051 +0100
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-compare1.C 2021-12-10 
11:31:38.100195242 +0100
@@ -0,0 +1,7 @@
+// { dg-do compile { target c++11 } }
+
+extern int a, b;
+static_assert (&a == &a, "");
+static_assert (&a != &b, "");
+constexpr bool c = &a == &a;
+constexpr bool d = &a != &b;
--- gcc/testsuite/g++.dg/cpp1y/constexpr-94716.C.jj 2021-12-10 
11:24:20.028490189 +0100
+++ gcc/testsuite/g++.dg/cpp1y/constexpr-94716.C2021-12-10 
11:35:52.782538861 +0100
@@ -0,0 +1,8 @@
+// PR c++/94716
+// { dg-do compile { target c++14 } }
+
+template  char v = 0;
+static_assert (&v<2> == &v<2>, "");
+static_assert (&v<0> != &v<1>, "");
+constexpr bool a = &v<2> == &v<2>;
+constexpr bool b = &v<0> != &v<1>;
--- gcc/testsuite/g++.dg/cpp1z/constexpr-compare1.C.jj  2021-12-10 
11:28:31.642874577 +0100
+++ gcc/testsuite/g++.dg/cpp1z/constexpr-compare1.C 2021-12-10 
11:30:59.114755454 +0100
@@ -0,0 +1,8 @@
+// { dg-do compile { target c++17 } }
+
+inline int a = 0;
+inline int b = 0;
+static_assert (&a == &a);
+static_assert (&a != &b);
+constexpr bool c = &a == &a;
+constexpr bool d = &a != &b;


Jakub

Re: [PATCH] PR ipa/103601: ICE compiling CSiBE in ipa-modref's insert_kill

[Jan Hubicka via Gcc-patches]

> On Fri, Dec 10, 2021 at 2:30 AM Roger Sayle  
> wrote:
> >
> >
> > This patch fixes PR ipa/103061 which is P1 regression that shows up as
> > an ICE in ipa-modref-tree.c's insert_kill when compiling the CSiBE
> > benchmark.  I believe the underlying cause is that the new kill tracking
> > functionality wasn't anticipating memory accesses that are zero bits
> > wide!?.  The failing source code (test case) contains the unusual lines:
> > typedef struct { } spinlock_t;
> > and
> > q->lock = (spinlock_t) { };
> > Making spinlock_t larger, or removing the assignment work around the issue.
> 
> zero sized accesses (load and stores) should have been removed during
> gimplification. Why was it not?

Sadly this does not happen systematically... I already had to fix
similar issue with load/store analysis in modref :(

> >
> > 2021-12-10  Roger Sayle  
> >
> > gcc/ChangeLog
> > PR ipa/103601
> > * ipa-modref-tree.h (useful_for_kill_p): Zero width accesses aren't
> > useful for kill tracking.

The patch is OK.  Even if we make gimplifier smarter about zero width
accesses I guess we want to be safe that they are not synthetized from
i.e. variable sized arrays.

Thanks for fixing this!
Honza
> >
> > gcc/testsuite/ChangeLog
> > PR ipa/103601
> > * gcc.dg/ipa/pr103601.c: New test case.
> >
> > Thanks in advance,
> > Roger
> > --
> >

Re: [PATCH] PR ipa/103601: ICE compiling CSiBE in ipa-modref's insert_kill

[Andrew Pinski via Gcc-patches]

On Fri, Dec 10, 2021 at 2:30 AM Roger Sayle  wrote:
>
>
> This patch fixes PR ipa/103061 which is P1 regression that shows up as
> an ICE in ipa-modref-tree.c's insert_kill when compiling the CSiBE
> benchmark.  I believe the underlying cause is that the new kill tracking
> functionality wasn't anticipating memory accesses that are zero bits
> wide!?.  The failing source code (test case) contains the unusual lines:
> typedef struct { } spinlock_t;
> and
> q->lock = (spinlock_t) { };
> Making spinlock_t larger, or removing the assignment work around the issue.

zero sized accesses (load and stores) should have been removed during
gimplification. Why was it not?

Thanks,
Andrew

>
> The one line patch below to useful_for_kill_p teaches IPA that a memory
> write is only useful as a "kill" if it is more than zero bits wide.
> In theory, the existing known_size_p (size) test is now redundant, as
> poly_int64 currently uses the value -1 for unknown size values,
> but the proposed change makes the semantics clear, and defends against
> possible future changes in representation [but I'm happy to change this].
>
> This patch has been tested on x86_64-pc-linux-gnu with a make bootstrap
> and make -k check with no new failures.  Ok for mainline?
>
>
> 2021-12-10  Roger Sayle  
>
> gcc/ChangeLog
> PR ipa/103601
> * ipa-modref-tree.h (useful_for_kill_p): Zero width accesses aren't
> useful for kill tracking.
>
> gcc/testsuite/ChangeLog
> PR ipa/103601
> * gcc.dg/ipa/pr103601.c: New test case.
>
> Thanks in advance,
> Roger
> --
>

[PATCH] PR ipa/103601: ICE compiling CSiBE in ipa-modref's insert_kill

[Roger Sayle]

This patch fixes PR ipa/103061 which is P1 regression that shows up as
an ICE in ipa-modref-tree.c's insert_kill when compiling the CSiBE
benchmark.  I believe the underlying cause is that the new kill tracking
functionality wasn't anticipating memory accesses that are zero bits
wide!?.  The failing source code (test case) contains the unusual lines:
typedef struct { } spinlock_t;
and
q->lock = (spinlock_t) { };
Making spinlock_t larger, or removing the assignment work around the issue.

The one line patch below to useful_for_kill_p teaches IPA that a memory
write is only useful as a "kill" if it is more than zero bits wide.
In theory, the existing known_size_p (size) test is now redundant, as
poly_int64 currently uses the value -1 for unknown size values,
but the proposed change makes the semantics clear, and defends against
possible future changes in representation [but I'm happy to change this].

This patch has been tested on x86_64-pc-linux-gnu with a make bootstrap
and make -k check with no new failures.  Ok for mainline?


2021-12-10  Roger Sayle  

gcc/ChangeLog
PR ipa/103601
* ipa-modref-tree.h (useful_for_kill_p): Zero width accesses aren't
useful for kill tracking.

gcc/testsuite/ChangeLog
PR ipa/103601
* gcc.dg/ipa/pr103601.c: New test case.

Thanks in advance,
Roger
--

diff --git a/gcc/ipa-modref-tree.h b/gcc/ipa-modref-tree.h
index 35190c2..4ad556f 100644
--- a/gcc/ipa-modref-tree.h
+++ b/gcc/ipa-modref-tree.h
@@ -87,7 +87,8 @@ struct GTY(()) modref_access_node
 {
   return parm_offset_known && parm_index != MODREF_UNKNOWN_PARM
 && parm_index != MODREF_RETSLOT_PARM && known_size_p (size)
-&& known_eq (max_size, size);
+&& known_eq (max_size, size)
+&& known_gt (size, 0);
 }
   /* Dump range to debug OUT.  */
   void dump (FILE *out);
diff --git a/gcc/testsuite/gcc.dg/ipa/pr103601.c 
b/gcc/testsuite/gcc.dg/ipa/pr103601.c
new file mode 100644
index 000..7bdb5e5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr103601.c
@@ -0,0 +1,35 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fgnu89-inline" } */
+
+typedef struct { } spinlock_t;
+struct list_head {
+ struct list_head *next, *prev;
+};
+struct __wait_queue_head {
+ spinlock_t lock;
+ struct list_head task_list;
+};
+typedef struct __wait_queue_head wait_queue_head_t;
+static inline void init_waitqueue_head(wait_queue_head_t *q)
+{
+ q->lock = (spinlock_t) { };
+ do { (&q->task_list)->next = (&q->task_list); (&q->task_list)->prev = 
(&q->task_list); } while (0);
+}
+struct timer_list {
+ void (*function)(unsigned long);
+};
+struct rpc_task {
+ struct timer_list tk_timer;
+ wait_queue_head_t tk_wait;
+};
+static void
+rpc_run_timer(struct rpc_task *task)
+{
+}
+inline void
+rpc_init_task(struct rpc_task *task)
+{
+ task->tk_timer.function = (void (*)(unsigned long)) rpc_run_timer;
+ init_waitqueue_head(&task->tk_wait);
+}
+

Re: pr103523: Check for PLUS/MINUS support

[Richard Sandiford via Gcc-patches]

Joel Hutton  writes:
> Hi all,
>
> This is to address pr103523.
>
> bootstrapped and regression tested on aarch64.
>
> Check for PLUS_EXPR/MINUS_EXPR support in vectorizable_induction.
> PR103523 is an ICE on valid code:
>
> void d(float *a, float b, int c) {
> float e;
> for (; c; c--, e += b)
>   a[c] = e;
> }
>
> This is due to not checking for PLUS_EXPR support, which is missing in
> VNx2sf mode. This causes an ICE at expand time. This patch adds a check
> for support in vectorizable_induction.
>
> gcc/ChangeLog:
>
> PR tree-optimization/PR103523

The bugzilla hook expects: PR tree-optimization/103523

> * tree-vect-loop.c (vectorizable_induction): Check for
> PLUS_EXPR/MINUS_EXPR support.

OK, thanks.

Richard

Re: [committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

[Jonathan Wakely via Gcc-patches]

On Fri, 10 Dec 2021 at 01:50, Martin Sebor via Libstdc++
 wrote:
>
> On 12/9/21 5:38 PM, Martin Sebor wrote:
> > On 12/9/21 4:24 PM, Jonathan Wakely via Gcc-patches wrote:
> >> These warnings are triggered by perfectly valid code using std::string.
> >> They're particularly bad when --enable-fully-dynamic-string is used,
> >> because even std::string().begin() will give a warning.
> >>
> >> Use pragmas to stop the troublesome warnings for copies done by
> >> std::char_traits.
> >
> > I'm still experimenting with some of the approaches we discussed
> > last week, but based on my findings so far this was going to be
> > my suggestion at lest for now, until or unless the problem turns
> > out to affect more code than just std::string.
>
> Just minutes after I wrote this I tried following the clue
> in the note printed for the test case from PR 103534 with
> an enhancement I'm experimenting with:
>
> /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:426:56:
> warning: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’
> specified size between 18446744073709551600 and 18446744073709551615
> exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
>426 | return static_cast(__builtin_memcpy(__s1,
> __s2, __n));
>|
> ^
> /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:426:56:
> note: when
> ‘(.std::__cxx11::basic_string::_M_string_length >
> 18446744073709551599)’
>
> and adding an assert to string::size():
>
>constexpr
>size_type
>size() const noexcept
>{
>  if (_M_string_length >= -1LU >> 1)

I think that will be wrong for 64-bit Windows, where long is 32-bit,
but the string's max size is closer to -1LLU >> 2, and we don't want
to just use -1LLU because that's wrong for 32-bit targets.

Technically the max size is (N - 1)/2 where N is the allocator's max
size, which is PTRDIFF_MAX for std::allocator, SIZE_MAX for allocators
that use the default value from std::allocator_traits, or some other
value that the allocator defines. And the value is reduced
appropriately if sizeof(char_type) > 1.

But if we call this->max_size() which calls _Alloc_traits::max_size()
which potentially calls allocator_type::max_size(), will the compiler
actually make those calls to mark the path unreachable, or will it
just ignore the unreachable if it can't fold all those calls at
compile time?

We could just use __SIZE_MAX__/2 which might be larger than the real
maximum, but will never be smaller.

Jason made a suggestion last week which was that if the warning code
has a range like [2,INT_MAX] or [2UL,ULONG_MAX] that it should assume
that is really [2,infinity] and so not warn. If the upper bound is the
maximum possible value for the type, that's effectively unbounded, and
the warning could assume it's simply not got enough information to
give a useful warning. If it has a range like [2,300] for a buffer of
length 100, that should warn. But [2,infinity] is effectively ranger
saying "I have no idea what this value is" and the warning machinery
should not be issuing warnings on the basis of "I have no idea what
this value is".


>__builtin_unreachable ();
>  return _M_string_length;
>}
>
> That gets rid of the false positive in this PR.  I realize
> the others happen for other reasons but this approach at least
> suggests that there might be other ways to suppress them than
> the #pragma.  Unlike it, the alternative approaches should also
> improve codegen.

[PATCH] driver: Improve option diagnostics [PR103465]

[Martin Liška]

It happens that options are parsed and various diagnostics happen
in finish_options. That's a proper place as the function is also called
for optimize/target attributes (pragmas). However, it is possible that
target overwrites an option from command line and so the diagnostics
does not happen. That's fixed in the patch.

- options are parsed and finish_options is called:

  if (opts->x_flag_unwind_tables
  && !targetm_common.unwind_tables_default
  && opts->x_flag_reorder_blocks_and_partition
  && (ui_except == UI_SJLJ || ui_except >= UI_TARGET))
{
  if (opts_set->x_flag_reorder_blocks_and_partition)
inform (loc,
"%<-freorder-blocks-and-partition%> does not support "
"unwind info on this architecture");
  opts->x_flag_reorder_blocks_and_partition = 0;
  opts->x_flag_reorder_blocks = 1;
}

It's not triggered because of opts->x_flag_unwind_tables is false by default, 
but
the option is overwritten in target:

...
  if (TARGET_64BIT_P (opts->x_ix86_isa_flags))
{
  if (opts->x_optimize >= 1)
SET_OPTION_IF_UNSET (opts, opts_set, flag_omit_frame_pointer,
 !USE_IX86_FRAME_POINTER);
  if (opts->x_flag_asynchronous_unwind_tables
  && TARGET_64BIT_MS_ABI)
SET_OPTION_IF_UNSET (opts, opts_set, flag_unwind_tables, 1);
...

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

Ready to be installed?
Thanks,
Martin

PR driver/103465

gcc/ChangeLog:

* opts.c (finish_options): More part of diagnostics to ...
(diagnose_options): ... here. Call the function from both
finish_options and process_options.
* opts.h (diagnose_options): Declare.
* toplev.c (process_options): Call diagnose_options.
---
 gcc/opts.c   | 125 ---
 gcc/opts.h   |   2 +
 gcc/toplev.c |   2 +
 3 files changed, 72 insertions(+), 57 deletions(-)

diff --git a/gcc/opts.c b/gcc/opts.c
index 870cceca85a..525640b2968 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -1005,8 +1005,6 @@ void
 finish_options (struct gcc_options *opts, struct gcc_options *opts_set,
location_t loc)
 {
-  enum unwind_info_type ui_except;
-
   if (opts->x_dump_base_name
   && ! opts->x_dump_base_name_prefixed)
 {
@@ -1107,61 +1105,6 @@ finish_options (struct gcc_options *opts, struct 
gcc_options *opts_set,
   opts->x_flag_no_inline = 1;
 }
 
-  /* The optimization to partition hot and cold basic blocks into separate

- sections of the .o and executable files does not work (currently)
- with exception handling.  This is because there is no support for
- generating unwind info.  If opts->x_flag_exceptions is turned on
- we need to turn off the partitioning optimization.  */
-
-  ui_except = targetm_common.except_unwind_info (opts);
-
-  if (opts->x_flag_exceptions
-  && opts->x_flag_reorder_blocks_and_partition
-  && (ui_except == UI_SJLJ || ui_except >= UI_TARGET))
-{
-  if (opts_set->x_flag_reorder_blocks_and_partition)
-inform (loc,
-   "%<-freorder-blocks-and-partition%> does not work "
-   "with exceptions on this architecture");
-  opts->x_flag_reorder_blocks_and_partition = 0;
-  opts->x_flag_reorder_blocks = 1;
-}
-
-  /* If user requested unwind info, then turn off the partitioning
- optimization.  */
-
-  if (opts->x_flag_unwind_tables
-  && !targetm_common.unwind_tables_default
-  && opts->x_flag_reorder_blocks_and_partition
-  && (ui_except == UI_SJLJ || ui_except >= UI_TARGET))
-{
-  if (opts_set->x_flag_reorder_blocks_and_partition)
-inform (loc,
-   "%<-freorder-blocks-and-partition%> does not support "
-   "unwind info on this architecture");
-  opts->x_flag_reorder_blocks_and_partition = 0;
-  opts->x_flag_reorder_blocks = 1;
-}
-
-  /* If the target requested unwind info, then turn off the partitioning
- optimization with a different message.  Likewise, if the target does not
- support named sections.  */
-
-  if (opts->x_flag_reorder_blocks_and_partition
-  && (!targetm_common.have_named_sections
- || (opts->x_flag_unwind_tables
- && targetm_common.unwind_tables_default
- && (ui_except == UI_SJLJ || ui_except >= UI_TARGET
-{
-  if (opts_set->x_flag_reorder_blocks_and_partition)
-inform (loc,
-   "%<-freorder-blocks-and-partition%> does not work "
-   "on this architecture");
-  opts->x_flag_reorder_blocks_and_partition = 0;
-  opts->x_flag_reorder_blocks = 1;
-}
-
-
   /* Pipelining of outer loops is only possible when general pipelining
  capabilities are requested.  */
   if (!opts->x_flag_sel_sched_pipelining)
@@ -1397,6 +1340,74 @@ finish_options (struct gcc_options *opts, struct 
gcc_options *opts_set,
 && debug_info_level >= DINFO_LEVEL_

pr103523: Check for PLUS/MINUS support

[Joel Hutton via Gcc-patches]

Hi all,

This is to address pr103523.

bootstrapped and regression tested on aarch64.

Check for PLUS_EXPR/MINUS_EXPR support in vectorizable_induction.
PR103523 is an ICE on valid code:

void d(float *a, float b, int c) {
    float e;
    for (; c; c--, e += b)
      a[c] = e;
}

This is due to not checking for PLUS_EXPR support, which is missing in
VNx2sf mode. This causes an ICE at expand time. This patch adds a check
for support in vectorizable_induction.

gcc/ChangeLog:
        
PR tree-optimization/PR103523
* tree-vect-loop.c (vectorizable_induction): Check for
    PLUS_EXPR/MINUS_EXPR support.
diff --git a/gcc/testsuite/gcc.target/aarch64/pr103523.c b/gcc/testsuite/gcc.target/aarch64/pr103523.c
new file mode 100644
index ..736e8936c5f6768bdf098ddc37b2c21ab74ee0df
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr103523.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-march=armv8-a+sve -mtune=neoverse-v1 -Ofast" } */
+
+void d(float *a, float b, int c) {
+float e;
+for (; c; c--, e += b)
+  a[c] = e;
+}
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 7f544ba1fd5198dd32cda05e62382ab2e1e9bb50..f700d5e7ac2c05402407a46113320f79359906fa 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -8065,6 +8065,15 @@ vectorizable_induction (loop_vec_info loop_vinfo,
   return false;
 }
 
+  step_expr = STMT_VINFO_LOOP_PHI_EVOLUTION_PART (stmt_info);
+  gcc_assert (step_expr != NULL_TREE);
+  tree step_vectype = get_same_sized_vectype (TREE_TYPE (step_expr), vectype);
+
+  /* Check for backend support of PLUS/MINUS_EXPR. */
+  if (!directly_supported_p (PLUS_EXPR, step_vectype)
+  || !directly_supported_p (MINUS_EXPR, step_vectype))
+return false;
+
   if (!vec_stmt) /* transformation not required.  */
 {
   unsigned inside_cost = 0, prologue_cost = 0;
@@ -8124,10 +8133,6 @@ vectorizable_induction (loop_vec_info loop_vinfo,
   if (dump_enabled_p ())
 dump_printf_loc (MSG_NOTE, vect_location, "transform induction phi.\n");
 
-  step_expr = STMT_VINFO_LOOP_PHI_EVOLUTION_PART (stmt_info);
-  gcc_assert (step_expr != NULL_TREE);
-  tree step_vectype = get_same_sized_vectype (TREE_TYPE (step_expr), vectype);
-
   pe = loop_preheader_edge (iv_loop);
   /* Find the first insertion point in the BB.  */
   basic_block bb = gimple_bb (phi);

Re: [committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

[Jonathan Wakely via Gcc-patches]

On Fri, 10 Dec 2021 at 00:39, Martin Sebor via Libstdc++
 wrote:
>
> On 12/9/21 4:24 PM, Jonathan Wakely via Gcc-patches wrote:
> > These warnings are triggered by perfectly valid code using std::string.
> > They're particularly bad when --enable-fully-dynamic-string is used,
> > because even std::string().begin() will give a warning.
> >
> > Use pragmas to stop the troublesome warnings for copies done by
> > std::char_traits.
>
> I'm still experimenting with some of the approaches we discussed
> last week, but based on my findings so far this was going to be
> my suggestion at lest for now, until or unless the problem turns
> out to affect more code than just std::string.
>
> That said, I noticed a typo in the patch:
>
> >
> > libstdc++-v3/ChangeLog:
> >
> >   PR libstdc++/103332
> >   PR libstdc++/102958
> >   PR libstdc++/103483
> >   * include/bits/char_traits.h: Suppress stringop and array-bounds
> >   warnings.
> > ---
> >   libstdc++-v3/include/bits/char_traits.h | 7 +++
> >   1 file changed, 7 insertions(+)
> >
> > diff --git a/libstdc++-v3/include/bits/char_traits.h 
> > b/libstdc++-v3/include/bits/char_traits.h
> > index da3e0aa..3f7befcf8b2 100644
> > --- a/libstdc++-v3/include/bits/char_traits.h
> > +++ b/libstdc++-v3/include/bits/char_traits.h
> > @@ -54,6 +54,11 @@ namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
> >   {
> >   _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >
> > +#pragma GCC diagnostic push
> > +#pragma GCC diagnostic ignored "-Wstringop-overflow"
> > +#pragma GCC diagnostic ignored "-Wstringop-overread"
> > +#pragma GCC diagnostic ignored "-Warray-bounds"
>
> (Just for reference, as I mentioned in my private mail, at -O1
> the same code also triggers -Wfree-nonheap-object.)
>
> > +
> > /**
> >  *  @brief  Mapping from character type to associated types.
> >  *
> > @@ -990,6 +995,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > } // namespace __detail
> >   #endif // C++20
> >
> > +#pragma GCC diagnostic push
>
> This should be pop.

Oops! thanks, fixed at r12-5888 by the attached patch. Tested
x86_64-linux, pushed to trunk.
commit db184a3453b6fe810e2d9765ef8ed9028f96e968
Author: Jonathan Wakely 
Date:   Fri Dec 10 09:06:37 2021

libstdc++: Fix diagnostic pragma push that should be pop

libstdc++-v3/ChangeLog:

* include/bits/char_traits.h: Change pragma push to pop.

diff --git a/libstdc++-v3/include/bits/char_traits.h 
b/libstdc++-v3/include/bits/char_traits.h
index 3f7befcf8b2..13239580622 100644
--- a/libstdc++-v3/include/bits/char_traits.h
+++ b/libstdc++-v3/include/bits/char_traits.h
@@ -995,7 +995,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   } // namespace __detail
 #endif // C++20
 
-#pragma GCC diagnostic push
+#pragma GCC diagnostic pop
 
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace

Re: [Patch 8/8, Arm, GCC] Introduce multilibs for PACBTI target feature. [Was RE: [Patch 7/7, Arm, GCC] Introduce multilibs for PACBTI target feature.]

[Andrea Corallo via Gcc-patches]

Richard Earnshaw via Gcc-patches  writes:

> On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote:
>> 
>>> -Original Message-
>>> From: Gcc-patches >> bounces+belagod=gcc.gnu@gcc.gnu.org> On Behalf Of Tejas Belagod via
>>> Gcc-patches
>>> Sent: Friday, October 8, 2021 1:19 PM
>>> To: gcc-patches@gcc.gnu.org
>>> Subject: [Patch 7/7, Arm, GCC] Introduce multilibs for PACBTI target 
>>> feature.
>>>
>>> Hi,
>>>
>>> This patch adds a multilib for pacbti target feature.
>>>
>>> Tested on arm-none-eabi. OK for trunk?
>>>
>>> 2021-10-04  Tejas Belagod  
>>>
>>> gcc/ChangeLog:
>>>
>>> * config/arm/t-rmprofile: Add multilib rules for +pacbti.
>> This patch adds a multilib for pacbti target feature.
>> 2021-10-04  Tejas Belagod  
>> gcc/ChangeLog:
>>  * config/arm/t-rmprofile: Add multilib rules for +pacbti.
>> Tested the following configurations, OK for trunk?
>> -mthumb/-march=armv8.1-m.main+pacbti/-mfloat-abi=soft
>> -marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp
>> mcmodel=small and tiny
>> aarch64-none-linux-gnu native test and bootstrap
>> Thanks,
>> Tejas.
>> 

Hi Richard,

> I can't decide whether this is too much, or too little.  But it
> doesn't feel right as it is.
>
> Ideally we don't want yet another multilib.  It would be better to
> have one of the existing multilib variants made pac/bti safe.
>
> And secondly, what about the hand-written assembler files in libgcc?
> Don't they need updating to be PAC/BTI safe?

I agree with you, this patch is missing at least bti landing pads in the
hand-written assembler files in libgcc.

> Also, does this even do what you intend it to do?  It adds the PAC/BTI
> architectural feature, but it doesn't actually enable PAC/BTI in the
> generated code.

Good point, I'll fix this too in the upcoming respin.

Thanks for reviewing.

BR

  Andrea