[PATCH] RISC-V: Elimilate warning

2023-09-11 Thread Li Xu
From: xuli 

   ./riscv-gcc/gcc/config/riscv/riscv-vector-builtins-bases.cc:1719:34:
  warning: unused parameter 'e' [-Wunused-parameter]
   rtx expand (function_expander ) const override

  ^

gcc/ChangeLog:

* config/riscv/riscv-vector-builtins-bases.cc: remove unused parameter.
---
 gcc/config/riscv/riscv-vector-builtins-bases.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc 
b/gcc/config/riscv/riscv-vector-builtins-bases.cc
index be3df2c1ea2..e2de95db88a 100644
--- a/gcc/config/riscv/riscv-vector-builtins-bases.cc
+++ b/gcc/config/riscv/riscv-vector-builtins-bases.cc
@@ -1856,7 +1856,7 @@ public:
 return clobber;
   }
 
-  rtx expand (function_expander ) const override
+  rtx expand (function_expander &) const override
   {
 return NULL_RTX;
   }
-- 
2.17.1



[PATCH 2/2] libstdc++: Optimize is_member_pointer trait performance

2023-09-11 Thread Ken Matsui via Gcc-patches
This patch optimizes the performance of the is_member_pointer trait
by dispatching to the new __is_member_pointer built-in trait.

libstdc++-v3/ChangeLog:

* include/std/type_traits (is_member_pointer): Use __is_member_pointer
built-in trait.
(is_member_pointer_v): Likewise.

Signed-off-by: Ken Matsui 
---
 libstdc++-v3/include/std/type_traits | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index 677cd934b94..69dccfa035d 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -709,6 +709,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 struct is_compound
 : public __not_>::type { };
 
+  /// is_member_pointer
+#if _GLIBCXX_USE_BUILTIN_TRAIT(__is_member_pointer)
+  template
+struct is_member_pointer
+: public __bool_constant<__is_member_pointer(_Tp)>
+{ };
+#else
   /// @cond undocumented
   template
 struct __is_member_pointer_helper
@@ -719,11 +726,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 : public true_type { };
   /// @endcond
 
-  /// is_member_pointer
   template
 struct is_member_pointer
 : public __is_member_pointer_helper<__remove_cv_t<_Tp>>::type
 { };
+#endif
 
   template
 struct is_same;
@@ -3216,8 +3223,15 @@ template 
   inline constexpr bool is_scalar_v = is_scalar<_Tp>::value;
 template 
   inline constexpr bool is_compound_v = is_compound<_Tp>::value;
+
+#if _GLIBCXX_USE_BUILTIN_TRAIT(__is_member_pointer)
+template 
+  inline constexpr bool is_member_pointer_v = __is_member_pointer(_Tp);
+#else
 template 
   inline constexpr bool is_member_pointer_v = is_member_pointer<_Tp>::value;
+#endif
+
 template 
   inline constexpr bool is_const_v = false;
 template 
-- 
2.42.0



[PATCH 1/2] c++: Implement __is_member_pointer built-in trait

2023-09-11 Thread Ken Matsui via Gcc-patches
This patch implements built-in trait for std::is_member_pointer.

gcc/cp/ChangeLog:

* cp-trait.def (IS_MEMBER_POINTER): Define __is_member_pointer.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_MEMBER_POINTER.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/ext/has-builtin-1.C: Test existence of __is_member_pointer.
* g++.dg/ext/is_member_pointer.C: New test.

Signed-off-by: Ken Matsui 
---
 gcc/cp/constraint.cc |  3 ++
 gcc/cp/cp-trait.def  |  1 +
 gcc/cp/semantics.cc  |  4 +++
 gcc/testsuite/g++.dg/ext/has-builtin-1.C |  3 ++
 gcc/testsuite/g++.dg/ext/is_member_pointer.C | 30 
 5 files changed, 41 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/ext/is_member_pointer.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index c9e4e7043cd..a3e90281d29 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -3757,6 +3757,9 @@ diagnose_trait_expr (tree expr, tree args)
 case CPTK_IS_TRIVIALLY_COPYABLE:
   inform (loc, "  %qT is not trivially copyable", t1);
   break;
+case CPTK_IS_MEMBER_POINTER:
+  inform (loc, "  %qT is not a member pointer", t1);
+  break;
 case CPTK_IS_ASSIGNABLE:
   inform (loc, "  %qT is not assignable from %qT", t1, t2);
   break;
diff --git a/gcc/cp/cp-trait.def b/gcc/cp/cp-trait.def
index 8b7fece0cc8..9aa11eb4280 100644
--- a/gcc/cp/cp-trait.def
+++ b/gcc/cp/cp-trait.def
@@ -69,6 +69,7 @@ DEFTRAIT_EXPR (IS_ENUM, "__is_enum", 1)
 DEFTRAIT_EXPR (IS_FINAL, "__is_final", 1)
 DEFTRAIT_EXPR (IS_LAYOUT_COMPATIBLE, "__is_layout_compatible", 2)
 DEFTRAIT_EXPR (IS_LITERAL_TYPE, "__is_literal_type", 1)
+DEFTRAIT_EXPR (IS_MEMBER_POINTER, "__is_member_pointer", 1)
 DEFTRAIT_EXPR (IS_NOTHROW_ASSIGNABLE, "__is_nothrow_assignable", 2)
 DEFTRAIT_EXPR (IS_NOTHROW_CONSTRUCTIBLE, "__is_nothrow_constructible", -1)
 DEFTRAIT_EXPR (IS_NOTHROW_CONVERTIBLE, "__is_nothrow_convertible", 2)
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 0f7f4e87ae4..7b4ffb283f1 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -12169,6 +12169,9 @@ trait_expr_value (cp_trait_kind kind, tree type1, tree 
type2)
 case CPTK_IS_TRIVIAL:
   return trivial_type_p (type1);
 
+case CPTK_IS_MEMBER_POINTER:
+  return TYPE_PTRMEM_P (type1);
+
 case CPTK_IS_TRIVIALLY_ASSIGNABLE:
   return is_trivially_xible (MODIFY_EXPR, type1, type2);
 
@@ -12359,6 +12362,7 @@ finish_trait_expr (location_t loc, cp_trait_kind kind, 
tree type1, tree type2)
 case CPTK_IS_ENUM:
 case CPTK_IS_UNION:
 case CPTK_IS_SAME:
+case CPTK_IS_MEMBER_POINTER:
   break;
 
 case CPTK_IS_LAYOUT_COMPATIBLE:
diff --git a/gcc/testsuite/g++.dg/ext/has-builtin-1.C 
b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
index f343e153e56..31cbc43a26f 100644
--- a/gcc/testsuite/g++.dg/ext/has-builtin-1.C
+++ b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
@@ -146,3 +146,6 @@
 #if !__has_builtin (__remove_cvref)
 # error "__has_builtin (__remove_cvref) failed"
 #endif
+#if !__has_builtin (__is_member_pointer)
+# error "__has_builtin (__is_member_pointer) failed"
+#endif
diff --git a/gcc/testsuite/g++.dg/ext/is_member_pointer.C 
b/gcc/testsuite/g++.dg/ext/is_member_pointer.C
new file mode 100644
index 000..7ee2e3ab90c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/is_member_pointer.C
@@ -0,0 +1,30 @@
+// { dg-do compile { target c++11 } }
+
+#include 
+
+using namespace __gnu_test;
+
+#define SA(X) static_assert((X),#X)
+
+#define SA_TEST_NON_VOLATILE(TRAIT, TYPE, EXPECT)  \
+  SA(TRAIT(TYPE) == EXPECT);   \
+  SA(TRAIT(const TYPE) == EXPECT)
+
+#define SA_TEST_CATEGORY(TRAIT, TYPE, EXPECT)  \
+  SA(TRAIT(TYPE) == EXPECT);   \
+  SA(TRAIT(const TYPE) == EXPECT); \
+  SA(TRAIT(volatile TYPE) == EXPECT);  \
+  SA(TRAIT(const volatile TYPE) == EXPECT)
+
+SA_TEST_CATEGORY(__is_member_pointer, int (ClassType::*), true);
+SA_TEST_CATEGORY(__is_member_pointer, ClassType (ClassType::*), true);
+
+SA_TEST_NON_VOLATILE(__is_member_pointer, int (ClassType::*)(int), true);
+SA_TEST_NON_VOLATILE(__is_member_pointer, int (ClassType::*)(int) const, true);
+SA_TEST_NON_VOLATILE(__is_member_pointer, int (ClassType::*)(float, ...), 
true);
+SA_TEST_NON_VOLATILE(__is_member_pointer, ClassType (ClassType::*)(ClassType), 
true);
+SA_TEST_NON_VOLATILE(__is_member_pointer,
+float (ClassType::*)(int, float, int[], int&), true);
+
+// Sanity check.
+SA_TEST_CATEGORY(__is_member_pointer, ClassType, false);
-- 
2.42.0



[PATCH 0/2] Optimize is_member_pointer trait performance

2023-09-11 Thread Ken Matsui via Gcc-patches
This patch series optimizes is_member_pointer trait
performance. The first patch implements __is_member_pointer
built-in trait. The second patch optimizes is_member_pointer
trait performance by using __is_member_pointer built-in trait
if available.

The performance improvement is shown in the following benchmark:

https://github.com/ken-matsui/gsoc23/blob/main/is_member_pointer_v.md#mon-sep-11-092927-pm-pdt-2023

Time: -47.2037% +/- 2.12936%
Peak Memory Usage: -39.4183% +/- 0.00217276%
Total Memory Usage: -41.9905% +/- 0%

Ken Matsui (2):
  c++: Implement __is_member_pointer built-in trait
  libstdc++: Optimize is_member_pointer trait performance

 gcc/cp/constraint.cc |  3 ++
 gcc/cp/cp-trait.def  |  1 +
 gcc/cp/semantics.cc  |  4 +++
 gcc/testsuite/g++.dg/ext/has-builtin-1.C |  3 ++
 gcc/testsuite/g++.dg/ext/is_member_pointer.C | 30 
 libstdc++-v3/include/std/type_traits | 16 ++-
 6 files changed, 56 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/ext/is_member_pointer.C

-- 
2.42.0



[PATCH] MATCH: Simplify (a CMP1 b) ^ (a CMP2 b)

2023-09-11 Thread Andrew Pinski via Gcc-patches
This adds the missing optimizations here.
Note we don't need to match where CMP1 and CMP2 are complements of each
other as that is already handled elsewhere.

I added a new executable testcase to make sure we optimize it correctly
as I had originally messed up one of the entries for the resulting
comparison to make sure they were 100% correct.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

PR tree-optimization/107881

gcc/ChangeLog:

* match.pd (`(a CMP1 b) ^ (a CMP2 b)`): New pattern.
(`(a CMP1 b) == (a CMP2 b)`): New pattern.

gcc/testsuite/ChangeLog:

* gcc.c-torture/execute/pr107881-1.c: New test.
* gcc.dg/tree-ssa/cmpeq-4.c: New test.
* gcc.dg/tree-ssa/cmpxor-1.c: New test.
---
 gcc/match.pd  |  20 +++
 .../gcc.c-torture/execute/pr107881-1.c| 115 ++
 gcc/testsuite/gcc.dg/tree-ssa/cmpeq-4.c   |  51 
 gcc/testsuite/gcc.dg/tree-ssa/cmpxor-1.c  |  51 
 4 files changed, 237 insertions(+)
 create mode 100644 gcc/testsuite/gcc.c-torture/execute/pr107881-1.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/cmpeq-4.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/cmpxor-1.c

diff --git a/gcc/match.pd b/gcc/match.pd
index e96e385c6fa..39c7ea1088f 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -3154,6 +3154,26 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   { constant_boolean_node (true, type); })
  ))
 
+/* Optimize (a CMP b) ^ (a CMP b)  */
+/* Optimize (a CMP b) != (a CMP b)  */
+(for op (bit_xor ne)
+ (for cmp1 (lt lt lt le le le)
+  cmp2 (gt eq ne ge eq ne)
+  rcmp (ne le gt ne lt ge)
+  (simplify
+   (op:c (cmp1:c @0 @1) (cmp2:c @0 @1))
+   (if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE (@0)))
+(rcmp @0 @1)
+
+/* Optimize (a CMP b) == (a CMP b)  */
+(for cmp1 (lt lt lt le le le)
+ cmp2 (gt eq ne ge eq ne)
+ rcmp (eq gt le eq ge lt)
+ (simplify
+  (eq:c (cmp1:c @0 @1) (cmp2:c @0 @1))
+  (if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE (@0)))
+(rcmp @0 @1
+
 /* We can't reassociate at all for saturating types.  */
 (if (!TYPE_SATURATING (type))
 
diff --git a/gcc/testsuite/gcc.c-torture/execute/pr107881-1.c 
b/gcc/testsuite/gcc.c-torture/execute/pr107881-1.c
new file mode 100644
index 000..063ec4c2797
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr107881-1.c
@@ -0,0 +1,115 @@
+#define func(vol, op1, op2, op3)   \
+_Bool op1##_##op2##_##op3##_##vol (int a, int b)   \
+{  \
+ vol _Bool x = op_##op1(a, b); \
+ vol _Bool y = op_##op2(a, b); \
+ return op_##op3(x, y);\
+}
+
+#define op_lt(a, b) ((a) < (b))
+#define op_le(a, b) ((a) <= (b))
+#define op_eq(a, b) ((a) == (b))
+#define op_ne(a, b) ((a) != (b))
+#define op_gt(a, b) ((a) > (b))
+#define op_ge(a, b) ((a) >= (b))
+#define op_xor(a, b) ((a) ^ (b))
+
+
+#define funcs(a) \
+ a(lt,lt,ne) \
+ a(lt,lt,eq) \
+ a(lt,lt,xor) \
+ a(lt,le,ne) \
+ a(lt,le,eq) \
+ a(lt,le,xor) \
+ a(lt,gt,ne) \
+ a(lt,gt,eq) \
+ a(lt,gt,xor) \
+ a(lt,ge,ne) \
+ a(lt,ge,eq) \
+ a(lt,ge,xor) \
+ a(lt,eq,ne) \
+ a(lt,eq,eq) \
+ a(lt,eq,xor) \
+ a(lt,ne,ne) \
+ a(lt,ne,eq) \
+ a(lt,ne,xor) \
+  \
+ a(le,lt,ne) \
+ a(le,lt,eq) \
+ a(le,lt,xor) \
+ a(le,le,ne) \
+ a(le,le,eq) \
+ a(le,le,xor) \
+ a(le,gt,ne) \
+ a(le,gt,eq) \
+ a(le,gt,xor) \
+ a(le,ge,ne) \
+ a(le,ge,eq) \
+ a(le,ge,xor) \
+ a(le,eq,ne) \
+ a(le,eq,eq) \
+ a(le,eq,xor) \
+ a(le,ne,ne) \
+ a(le,ne,eq) \
+ a(le,ne,xor)  \
+ \
+ a(gt,lt,ne) \
+ a(gt,lt,eq) \
+ a(gt,lt,xor) \
+ a(gt,le,ne) \
+ a(gt,le,eq) \
+ a(gt,le,xor) \
+ a(gt,gt,ne) \
+ a(gt,gt,eq) \
+ a(gt,gt,xor) \
+ a(gt,ge,ne) \
+ a(gt,ge,eq) \
+ a(gt,ge,xor) \
+ a(gt,eq,ne) \
+ a(gt,eq,eq) \
+ a(gt,eq,xor) \
+ a(gt,ne,ne) \
+ a(gt,ne,eq) \
+ a(gt,ne,xor) \
+  \
+ a(ge,lt,ne) \
+ a(ge,lt,eq) \
+ a(ge,lt,xor) \
+ a(ge,le,ne) \
+ a(ge,le,eq) \
+ a(ge,le,xor) \
+ a(ge,gt,ne) \
+ a(ge,gt,eq) \
+ a(ge,gt,xor) \
+ a(ge,ge,ne) \
+ a(ge,ge,eq) \
+ a(ge,ge,xor) \
+ a(ge,eq,ne) \
+ a(ge,eq,eq) \
+ a(ge,eq,xor) \
+ a(ge,ne,ne) \
+ a(ge,ne,eq) \
+ a(ge,ne,xor)
+
+#define funcs1(a,b,c) \
+func(,a,b,c) \
+func(volatile,a,b,c)
+
+funcs(funcs1)
+
+#define test(op1,op2,op3)  \
+do {   \
+  if (op1##_##op2##_##op3##_(x,y)  \
+  != op1##_##op2##_##op3##_volatile(x,y))  \
+__builtin_abort(); \
+} while(0);
+
+int main()
+{
+  for(int x = -10; x < 10; x++)
+for(int y = -10; y < 10; y++)
+{
+funcs(test)
+}
+}
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/cmpeq-4.c 
b/gcc/testsuite/gcc.dg/tree-ssa/cmpeq-4.c
new file mode 100644
index 000..868d80fdcca
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/cmpeq-4.c
@@ -0,0 +1,51 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized -fdump-tree-original" } */
+/* PR 

Re: [PATCH] RISC-V: Finish Typing Un-Typed Instructions and Turn on Assert

2023-09-11 Thread Jeff Law via Gcc-patches




On 9/11/23 21:17, Lehua Ding wrote:

Hi Jeff,

On 2023/9/12 11:00, Jeff Law wrote:

I'd rather be consistent and make it policy that every insn has a type.


Since the type set here will not be used by sched pass (these insn 
pattern will not exit at shced pass since use define_insn_and_split with 
condition `TARGET_VECTOR && can_create_pseudo_p ()`), I think it is easy 
to cause misunderstanding and some problems are not easy to find (e.g. 
accidentally went through the sched pass should be assert error).
But that condition is _not_ generally sufficient to prevent these insns 
from existing during sched1.  ie, a pass between split1 and sched1 could 
create these patterns and successfully match them.  That in turn would 
trigger the assertion.


can_create_pseudo_p is true up through the register allocator.  As a 
result a condition like TARGET_VECTOR && can_create_pseudo_p() is _not_ 
sufficient to ensure the pattern does not exist during sched1.  While no 
pass likely creates these kinds of insns right now in that window 
between split1 and sched1, there's no guarantee that will always be true.


The simple rule is easy to follow.  Every insn should have a type.  That 
also gives us a degree of future-proof, even if someone adds additional 
passes/capabilities between split1 and sched1.



jeff


Re: [PATCH v2 2/2] riscv: Add support for str(n)cmp inline expansion

2023-09-11 Thread Jeff Law via Gcc-patches




On 9/6/23 10:07, Christoph Muellner wrote:

From: Christoph Müllner 

This patch implements expansions for the cmpstrsi and cmpstrnsi
builtins for RV32/RV64 for xlen-aligned strings if Zbb or XTheadBb
instructions are available.  The expansion basically emits a comparison
sequence which compares XLEN bits per step if possible.

This allows to inline calls to strcmp() and strncmp() if both strings
are xlen-aligned.  For strncmp() the length parameter needs to be known.
The benefits over calls to libc are:
* no call/ret instructions
* no stack frame allocation
* no register saving/restoring
* no alignment tests

The inlining mechanism is gated by a new switches ('-minline-strcmp' and
'-minline-strncmp') and by the variable 'optimize_size'.
The amount of emitted unrolled loop iterations can be controlled by the
parameter '--param=riscv-strcmp-inline-limit=N', which defaults to 64.

The comparision sequence is inspired by the strcmp example
in the appendix of the Bitmanip specification (incl. the fast
result calculation in case the first word does not contain
a NULL byte).  Additional inspiration comes from rs6000-string.c.

The emitted sequence is not triggering any readahead pagefault issues,
because only aligned strings are accessed by aligned xlen-loads.

This patch has been tested using the glibc string tests on QEMU:
* rv64gc_zbb/rv64gc_xtheadbb with riscv-strcmp-inline-limit=64
* rv64gc_zbb/rv64gc_xtheadbb with riscv-strcmp-inline-limit=8
* rv32gc_zbb/rv32gc_xtheadbb with riscv-strcmp-inline-limit=64

Signed-off-by: Christoph Müllner 

gcc/ChangeLog:

* config/riscv/bitmanip.md (*_not): Export INSN name.
(_not3): Likewise.
* config/riscv/riscv-protos.h (riscv_expand_strcmp): New
prototype.
* config/riscv/riscv-string.cc (GEN_EMIT_HELPER3): New helper
macros.
(GEN_EMIT_HELPER2): Likewise.
(emit_strcmp_scalar_compare_byte): New function.
(emit_strcmp_scalar_compare_subword): Likewise.
(emit_strcmp_scalar_compare_word): Likewise.
(emit_strcmp_scalar_load_and_compare): Likewise.
(emit_strcmp_scalar_call_to_libc): Likewise.
(emit_strcmp_scalar_result_calculation_nonul): Likewise.
(emit_strcmp_scalar_result_calculation): Likewise.
(riscv_expand_strcmp_scalar): Likewise.
(riscv_expand_strcmp): Likewise.
* config/riscv/riscv.md (*slt_): Export
INSN name.
(@slt_3): Likewise.
(cmpstrnsi): Invoke expansion function for str(n)cmp.
(cmpstrsi): Likewise.
* config/riscv/riscv.opt: Add new parameter
'-mstring-compare-inline-limit'.
* doc/invoke.texi: Document new parameter
'-mstring-compare-inline-limit'.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xtheadbb-strcmp-unaligned.c: New test.
* gcc.target/riscv/xtheadbb-strcmp.c: New test.
* gcc.target/riscv/zbb-strcmp-disabled-2.c: New test.
* gcc.target/riscv/zbb-strcmp-disabled.c: New test.
* gcc.target/riscv/zbb-strcmp-unaligned.c: New test.
* gcc.target/riscv/zbb-strcmp.c: New test.

OK for the trunk.  THanks for pushing this along.

jeff


Re: [PATCH v2 1/2] riscv: Add support for strlen inline expansion

2023-09-11 Thread Jeff Law via Gcc-patches




On 9/6/23 10:07, Christoph Muellner wrote:

From: Christoph Müllner 

This patch implements the expansion of the strlen builtin for RV32/RV64
for xlen-aligned aligned strings if Zbb or XTheadBb instructions are available.
The inserted sequences are:

rv32gc_zbb (RV64 is similar):
   add a3,a0,4
   li  a4,-1
.L1:  lw  a5,0(a0)
   add a0,a0,4
   orc.b   a5,a5
   beq a5,a4,.L1
   not a5,a5
   ctz a5,a5
   srl a5,a5,0x3
   add a0,a0,a5
   sub a0,a0,a3

rv64gc_xtheadbb (RV32 is similar):
   add   a4,a0,8
.L2:  lda5,0(a0)
   add   a0,a0,8
   th.tstnbz a5,a5
   beqz  a5,.L2
   th.reva5,a5
   th.ff1a5,a5
   srl   a5,a5,0x3
   add   a0,a0,a5
   sub   a0,a0,a4

This allows to inline calls to strlen(), with optimized code for
xlen-aligned strings, resulting in the following benefits over
a call to libc:
* no call/ret instructions
* no stack frame allocation
* no register saving/restoring
* no alignment test

The inlining mechanism is gated by a new switch ('-minline-strlen')
and by the variable 'optimize_size'.

Tested using the glibc string tests.

Signed-off-by: Christoph Müllner 

gcc/ChangeLog:

* config.gcc: Add new object riscv-string.o.
riscv-string.cc.
* config/riscv/riscv-protos.h (riscv_expand_strlen):
New function.
* config/riscv/riscv.md (strlen): New expand INSN.
* config/riscv/riscv.opt: New flag 'minline-strlen'.
* config/riscv/t-riscv: Add new object riscv-string.o.
* config/riscv/thead.md (th_rev2): Export INSN name.
(th_rev2): Likewise.
(th_tstnbz2): New INSN.
* doc/invoke.texi: Document '-minline-strlen'.
* emit-rtl.cc (emit_likely_jump_insn): New helper function.
(emit_unlikely_jump_insn): Likewise.
* rtl.h (emit_likely_jump_insn): New prototype.
(emit_unlikely_jump_insn): Likewise.
* config/riscv/riscv-string.cc: New file.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xtheadbb-strlen-unaligned.c: New test.
* gcc.target/riscv/xtheadbb-strlen.c: New test.
* gcc.target/riscv/zbb-strlen-disabled-2.c: New test.
* gcc.target/riscv/zbb-strlen-disabled.c: New test.
* gcc.target/riscv/zbb-strlen-unaligned.c: New test.
* gcc.target/riscv/zbb-strlen.c: New test.
Note that I don't think we need the new UNSPEC_STRLEN since its only 
used in the expander and doesn't survive into RTL.  Your call on whether 
or not to remove it now or as a separate patch (or keep it if I'm wrong 
about it not being needed.


OK for the trunk.  Sorry this got lost in the shuffle last year.

jeff
.


Re: Re: [PATCH] RISC-V: Add vcreate intrinsics for RVV tuple types

2023-09-11 Thread Li Xu
Committed, thanks juzhe and kito.
--
Li Xu
>LGTM, thanks for implement this :)
>
>On Tue, Sep 12, 2023 at 10:16 AM juzhe.zh...@rivai.ai
> wrote:
>>
>> Thanks for support it.
>> LGTM from my side.
>> Wait for kito's more comments.
>>
>>
>>
>> juzhe.zh...@rivai.ai
>>
>> From: Li Xu
>> Date: 2023-09-12 10:08
>> To: gcc-patches
>> CC: kito.cheng; palmer; juzhe.zhong; pan2.li; gaofei; wangfeng; xuli
>> Subject: [PATCH] RISC-V: Add vcreate intrinsics for RVV tuple types
>> From: xuli 
>>
>> gcc/ChangeLog:
>>
>> * config/riscv/riscv-vector-builtins-bases.cc (class vcreate):
>> (BASE): New class.
>> * config/riscv/riscv-vector-builtins-bases.h: Ditto.
>> * config/riscv/riscv-vector-builtins-functions.def (vcreate): Add 
>>vcreate support.
>> * config/riscv/riscv-vector-builtins-shapes.cc (struct vcreate_def): 
>>Ditto.
>> (SHAPE): Ditto.
>> * config/riscv/riscv-vector-builtins-shapes.h: Ditto.
>> * config/riscv/riscv-vector-builtins.cc: Add args type.
>>
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.target/riscv/rvv/base/tuple_create.c: New test.
>> ---
>> .../riscv/riscv-vector-builtins-bases.cc  |  40 ++
>> .../riscv/riscv-vector-builtins-bases.h   |   1 +
>> .../riscv/riscv-vector-builtins-functions.def |   1 +
>> .../riscv/riscv-vector-builtins-shapes.cc |  50 +++
>> .../riscv/riscv-vector-builtins-shapes.h  |   1 +
>> gcc/config/riscv/riscv-vector-builtins.cc |  12 ++
>> .../gcc.target/riscv/rvv/base/tuple_create.c  | 123 ++
>> 7 files changed, 228 insertions(+)
>> create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/tuple_create.c
>>
>> diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc 
>> b/gcc/config/riscv/riscv-vector-builtins-bases.cc
>> index 8e679f72392..be3df2c1ea2 100644
>> --- a/gcc/config/riscv/riscv-vector-builtins-bases.cc
>> +++ b/gcc/config/riscv/riscv-vector-builtins-bases.cc
>> @@ -1824,6 +1824,44 @@ public:
>>    }
>> };
>> +class vcreate : public function_base
>> +{
>> +public:
>> +  gimple *fold (gimple_folder ) const override
>> +  {
>> +    unsigned int nargs = gimple_call_num_args (f.call);
>> +    tree lhs_type = TREE_TYPE (f.lhs);
>> +
>> +    /* Replace the call with a clobber of the result (to prevent it from
>> +   becoming upwards exposed) followed by stores into each individual
>> +   vector of tuple.
>> +
>> +   The fold routines expect the replacement statement to have the
>> +   same lhs as the original call, so return the clobber statement
>> +   rather than the final vector store.  */
>> +    gassign *clobber = gimple_build_assign (f.lhs, build_clobber 
>> (lhs_type));
>> +
>> +    for (unsigned int i = nargs; i-- > 0; )
>> +  {
>> + tree rhs_vector = gimple_call_arg (f.call, i);
>> + tree field = tuple_type_field (TREE_TYPE (f.lhs));
>> + tree lhs_array = build3 (COMPONENT_REF, TREE_TYPE (field),
>> + unshare_expr (f.lhs), field, NULL_TREE);
>> + tree lhs_vector = build4 (ARRAY_REF, TREE_TYPE (rhs_vector),
>> +   lhs_array, size_int (i),
>> +   NULL_TREE, NULL_TREE);
>> + gassign *assign = gimple_build_assign (lhs_vector, rhs_vector);
>> + gsi_insert_after (f.gsi, assign, GSI_SAME_STMT);
>> +  }
>> +    return clobber;
>> +  }
>> +
>> +  rtx expand (function_expander ) const override
>> +  {
>> +    return NULL_RTX;
>> +  }
>> +};
>> +
>> class read_vl : public function_base
>> {
>> public:
>> @@ -2285,6 +2323,7 @@ static CONSTEXPR const vlmul_ext vlmul_ext_obj;
>> static CONSTEXPR const vlmul_trunc vlmul_trunc_obj;
>> static CONSTEXPR const vset vset_obj;
>> static CONSTEXPR const vget vget_obj;
>> +static CONSTEXPR const vcreate vcreate_obj;
>> static CONSTEXPR const read_vl read_vl_obj;
>> static CONSTEXPR const vleff vleff_obj;
>> static CONSTEXPR const vlenb vlenb_obj;
>> @@ -2546,6 +2585,7 @@ BASE (vlmul_ext)
>> BASE (vlmul_trunc)
>> BASE (vset)
>> BASE (vget)
>> +BASE (vcreate)
>> BASE (read_vl)
>> BASE (vleff)
>> BASE (vlenb)
>> diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.h 
>> b/gcc/config/riscv/riscv-vector-builtins-bases.h
>> index 69d4562091f..131041ea66f 100644
>> --- a/gcc/config/riscv/riscv-vector-builtins-bases.h
>> +++ b/gcc/config/riscv/riscv-vector-builtins-bases.h
>> @@ -267,6 +267,7 @@ extern const function_base *const vlmul_ext;
>> extern const function_base *const vlmul_trunc;
>> extern const function_base *const vset;
>> extern const function_base *const vget;
>> +extern const function_base *const vcreate;
>> extern const function_base *const read_vl;
>> extern const function_base *const vleff;
>> extern const function_base *const vlenb;
>> diff --git a/gcc/config/riscv/riscv-vector-builtins-functions.def 
>> b/gcc/config/riscv/riscv-vector-builtins-functions.def
>> index 3ce06dc60b7..18ed2c2b8f6 100644
>> --- a/gcc/config/riscv/riscv-vector-builtins-functions.def
>> +++ b/gcc/config/riscv/riscv-vector-builtins-functions.def
>> @@ -621,6 +621,7 @@ DEF_RVV_FUNCTION (vget, 

Re: [PATCH 2/2] RISC-V: Make SHA-256, SM3 and SM4 builtins operate on uint32_t

2023-09-11 Thread Tsukasa OI via Gcc-patches
On 2023/09/12 11:44, Kito Cheng wrote:
> LGTM, I think llvm and GCC are inconsistent for those intrinsics API
> is really unfortunate...so really appreciate making those API align :)

I guess that you mean LGTM to this patch set (given the context).
If so, I will commit this patch set later.

> And did you have plan to add riscv_crypto.h after updating/fixing all builtin?

Like riscv_vector.h?  I don't and I think we need to discuss what to
include in... like Toolchain SIG first.

Additionally, we need to discuss what to do with these XLEN-specific
builtins specific to LLVM (my idea is, add XLEN-specific builtins like
LLVM but not to remove XLEN independent ones).

Thanks,
Tsukasa

> Excerpt from the latest clang/include/clang/Basic/BuiltinsRISCV.def:
> 
> // Zbb extension
> TARGET_BUILTIN(__builtin_riscv_orc_b_32, "UiUi", "nc", "zbb")
> TARGET_BUILTIN(__builtin_riscv_orc_b_64, "UWiUWi", "nc", "zbb,64bit")
> TARGET_BUILTIN(__builtin_riscv_clz_32, "UiUi", "nc", "zbb|xtheadbb")
> TARGET_BUILTIN(__builtin_riscv_clz_64, "UiUWi", "nc", "zbb|xtheadbb,64bit")
> TARGET_BUILTIN(__builtin_riscv_ctz_32, "UiUi", "nc", "zbb")
> TARGET_BUILTIN(__builtin_riscv_ctz_64, "UiUWi", "nc", "zbb,64bit")
> 
> // Zbc or Zbkc extension
> TARGET_BUILTIN(__builtin_riscv_clmul_32, "UiUiUi", "nc", "zbc|zbkc")
> TARGET_BUILTIN(__builtin_riscv_clmul_64, "UWiUWiUWi", "nc", "zbc|zbkc,64bit")
> TARGET_BUILTIN(__builtin_riscv_clmulh_32, "UiUiUi", "nc", "zbc|zbkc,32bit")
> TARGET_BUILTIN(__builtin_riscv_clmulh_64, "UWiUWiUWi", "nc", "zbc|zbkc,64bit")
> TARGET_BUILTIN(__builtin_riscv_clmulr_32, "UiUiUi", "nc", "zbc,32bit")
> TARGET_BUILTIN(__builtin_riscv_clmulr_64, "UWiUWiUWi", "nc", "zbc,64bit")
> 
> // Zbkx
> TARGET_BUILTIN(__builtin_riscv_xperm4_32, "UiUiUi", "nc", "zbkx,32bit")
> TARGET_BUILTIN(__builtin_riscv_xperm4_64, "UWiUWiUWi", "nc", "zbkx,64bit")
> TARGET_BUILTIN(__builtin_riscv_xperm8_32, "UiUiUi", "nc", "zbkx,32bit")
> TARGET_BUILTIN(__builtin_riscv_xperm8_64, "UWiUWiUWi", "nc", "zbkx,64bit")
> 
> // Zbkb extension
> TARGET_BUILTIN(__builtin_riscv_brev8_32, "UiUi", "nc", "zbkb")
> TARGET_BUILTIN(__builtin_riscv_brev8_64, "UWiUWi", "nc", "zbkb,64bit")
> TARGET_BUILTIN(__builtin_riscv_zip_32, "UiUi", "nc", "zbkb,32bit")
> TARGET_BUILTIN(__builtin_riscv_unzip_32, "UiUi", "nc", "zbkb,32bit")


Re: [PATCH] RISC-V: Finish Typing Un-Typed Instructions and Turn on Assert

2023-09-11 Thread Lehua Ding

Hi Jeff,

On 2023/9/12 11:00, Jeff Law wrote:

I'd rather be consistent and make it policy that every insn has a type.


Since the type set here will not be used by sched pass (these insn 
pattern will not exit at shced pass since use define_insn_and_split with 
condition `TARGET_VECTOR && can_create_pseudo_p ()`), I think it is easy 
to cause misunderstanding and some problems are not easy to find (e.g. 
accidentally went through the sched pass should be assert error). In my 
opinion, assert in sched function can ensure that all insn pattern that 
reach sched pass have a type attribute. If not, it is a problem and 
needs to be located and checked. All insn patterns add type to allow 
assert to pass, but at the same time hide or ignore some problems. I 
don't know if there is a problem with my understanding, thank you.


--
Best,
Lehua



Re: [PATCH 3/3] [V2] [RISC-V] support cm.mva01s cm.mvsa01 in zcmp

2023-09-11 Thread Jeff Law via Gcc-patches




On 9/7/23 14:33, Palmer Dabbelt wrote:

On Thu, 07 Sep 2023 13:16:36 PDT (-0700), dimi...@dinux.eu wrote:

Hi,

This patch appears to have caused PR 111259.


Thanks.  Looks like wer'e not running our tests with RTL checking, 
Patrick is going to try and see if we've got compute time left for some 
builds -- even just having builds with checking would be a good one, we 
get bit by these bugs from time to time.


I'm spinning up a --enable-checking=yes build.  Maybe we just need 
something like


    diff --git a/gcc/config/riscv/predicates.md 
b/gcc/config/riscv/predicates.md

    index 53e7c1d03aa..aa4f02c67d5 100644
    --- a/gcc/config/riscv/predicates.md
    +++ b/gcc/config/riscv/predicates.md
    @@ -172,11 +172,11 @@ (define_predicate "stack_pop_up_to_s11_operand"
     ;; ZCMP predicates
     (define_predicate "a0a1_reg_operand"
    -  (and (match_operand 0 "register_operand")
    +  (and (match_code "reg")
    (match_test "IN_RANGE (REGNO (op), A0_REGNUM, A1_REGNUM)")))
     (define_predicate "zcmp_mv_sreg_operand"
    -  (and (match_operand 0 "register_operand")
    +  (and (match_code "reg")
    (match_test "TARGET_RVE ? IN_RANGE (REGNO (op), S0_REGNUM, 
S1_REGNUM)

     : IN_RANGE (REGNO (op), S0_REGNUM, S1_REGNUM)
     || IN_RANGE (REGNO (op), S2_REGNUM, S7_REGNUM)")))

Presumably you got a SUBREG if that patch solves the problem.

Note that due to RTL checking's compile-time cost, I think it's a 
separate option to enable-checking.  It's probably not feasible to turn 
it on for anything but cross testing right now.


IIRC Jakub does RTL checking builds & regression testing just once a 
year in the spring due to its cost.  And I think on just one target 
(x86).  We could probably do something similar to weed out these kinds 
of problems.  Spin it in November and wait however long it takes :-)


jeff



Re: [PATCH v5] RISC-V:Optimize the MASK opt generation

2023-09-11 Thread Jeff Law via Gcc-patches




On 9/7/23 19:26, Feng Wang wrote:


  Supported ISA specs (for use with the -misa-spec= option):
diff --git a/gcc/opt-functions.awk b/gcc/opt-functions.awk
index 36de4639318..cbfcf7dabcf 100644
--- a/gcc/opt-functions.awk
+++ b/gcc/opt-functions.awk
@@ -387,3 +387,14 @@ function integer_range_info(range_option, init, option, 
uinteger_used)
  else
  return "-1, -1"
  }
+
+# Find the index of target variable from extra_target_vars
+function find_index(var, var_arry, n_var_arry)
+{
+for (var_index = 0; var_index < n_var_arry; var_index++)
+{
+if (var_arry[var_index] == var)
+break
+}
+return var_index
+}
So if the mapping isn't found, it looks like this will return 
n_var_arry.  It looks like the caller expects that and adds a new entry 
to var_arry.  I would suggest a better comment.  Perhaps something like


# Find the index of VAR in VAR_ARRY which as length N_VAR_ARRY.  If
# VAR is not found, return N_VAR_ARRY.

I believe there is extensive documentation of the options handling in 
doc/options.texi.  The new functionality in this patch should be 
documented there.  Give it your best shot and I can help polish up the 
language.


Thanks,
Jeff


Re: [PATCH] RISC-V: Finish Typing Un-Typed Instructions and Turn on Assert

2023-09-11 Thread Jeff Law via Gcc-patches




On 9/11/23 20:33, Lehua Ding wrote:

Hi Edwin,

Sorry to bother you. I have a small question for you.

On 2023/9/12 6:52, Edwin Lu wrote:
--- a/gcc/config/riscv/autovec-opt.md +++ 
b/gcc/config/riscv/autovec-opt.md @@ -649,7 +649,8 @@ 
(define_insn_and_split "*cond_" gen_int_mode 
(GET_MODE_NUNITS (mode), Pmode)}; 
riscv_vector::expand_cond_len_unop (icode, ops); DONE; -}) +} 
+[(set_attr "type" "vector")])


Is it necessary to add type attribute to these INSNs that exist only 
before split1 pass? These instructions are expanded into the pattern in 
vector.md after split1 pass and do not reach the sched1 pass at all. If 
so, I feel that these patterns cannot be added, and it is reasonable to 
report an error if these INSNs reach sched1 pass. Thanks.

I'd rather be consistent and make it policy that every insn has a type.

The next thing I'd like to do (and it's probably much more work) is to 
validate that every insn type maps to a functional unit for the sched2 
pass.  The scheduler will do some horrible things to the generated code 
when lots of insns either don't have types or the types aren't matched 
to a functional unit.


Jeff


[PATCH 1/2] c++: Implement __is_bounded_array built-in trait

2023-09-11 Thread Ken Matsui via Gcc-patches
This patch implements built-in trait for std::is_bounded_array.

gcc/cp/ChangeLog:

* cp-trait.def (IS_BOUNDED_ARRAY): Define __is_bounded_array.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_BOUNDED_ARRAY.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/ext/has-builtin-1.C: Test existence of __is_bounded_array.
* g++.dg/ext/is_bounded_array.C: New test.

Signed-off-by: Ken Matsui 
---
 gcc/cp/constraint.cc|  3 ++
 gcc/cp/cp-trait.def |  1 +
 gcc/cp/semantics.cc |  4 +++
 gcc/testsuite/g++.dg/ext/has-builtin-1.C|  3 ++
 gcc/testsuite/g++.dg/ext/is_bounded_array.C | 38 +
 5 files changed, 49 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/ext/is_bounded_array.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index c9e4e7043cd..4db9acade65 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -3760,6 +3760,9 @@ diagnose_trait_expr (tree expr, tree args)
 case CPTK_IS_ASSIGNABLE:
   inform (loc, "  %qT is not assignable from %qT", t1, t2);
   break;
+case CPTK_IS_BOUNDED_ARRAY:
+  inform (loc, "  %qT is not a bounded array", t1);
+  break;
 case CPTK_IS_TRIVIALLY_ASSIGNABLE:
   inform (loc, "  %qT is not trivially assignable from %qT", t1, t2);
   break;
diff --git a/gcc/cp/cp-trait.def b/gcc/cp/cp-trait.def
index 8b7fece0cc8..d50ca8a7781 100644
--- a/gcc/cp/cp-trait.def
+++ b/gcc/cp/cp-trait.def
@@ -61,6 +61,7 @@ DEFTRAIT_EXPR (IS_ABSTRACT, "__is_abstract", 1)
 DEFTRAIT_EXPR (IS_AGGREGATE, "__is_aggregate", 1)
 DEFTRAIT_EXPR (IS_ASSIGNABLE, "__is_assignable", 2)
 DEFTRAIT_EXPR (IS_BASE_OF, "__is_base_of", 2)
+DEFTRAIT_EXPR (IS_BOUNDED_ARRAY, "__is_bounded_array", 1)
 DEFTRAIT_EXPR (IS_CLASS, "__is_class", 1)
 DEFTRAIT_EXPR (IS_CONSTRUCTIBLE, "__is_constructible", -1)
 DEFTRAIT_EXPR (IS_CONVERTIBLE, "__is_convertible", 2)
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 0f7f4e87ae4..87eeed34068 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -12142,6 +12142,9 @@ trait_expr_value (cp_trait_kind kind, tree type1, tree 
type2)
 case CPTK_IS_ENUM:
   return type_code1 == ENUMERAL_TYPE;
 
+case CPTK_IS_BOUNDED_ARRAY:
+  return type_code1 == ARRAY_TYPE && TYPE_DOMAIN (type1);
+
 case CPTK_IS_FINAL:
   return CLASS_TYPE_P (type1) && CLASSTYPE_FINAL (type1);
 
@@ -12359,6 +12362,7 @@ finish_trait_expr (location_t loc, cp_trait_kind kind, 
tree type1, tree type2)
 case CPTK_IS_ENUM:
 case CPTK_IS_UNION:
 case CPTK_IS_SAME:
+case CPTK_IS_BOUNDED_ARRAY:
   break;
 
 case CPTK_IS_LAYOUT_COMPATIBLE:
diff --git a/gcc/testsuite/g++.dg/ext/has-builtin-1.C 
b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
index f343e153e56..04db7756a26 100644
--- a/gcc/testsuite/g++.dg/ext/has-builtin-1.C
+++ b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
@@ -146,3 +146,6 @@
 #if !__has_builtin (__remove_cvref)
 # error "__has_builtin (__remove_cvref) failed"
 #endif
+#if !__has_builtin (__is_bounded_array)
+# error "__has_builtin (__is_bounded_array) failed"
+#endif
diff --git a/gcc/testsuite/g++.dg/ext/is_bounded_array.C 
b/gcc/testsuite/g++.dg/ext/is_bounded_array.C
new file mode 100644
index 000..346790eba12
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/is_bounded_array.C
@@ -0,0 +1,38 @@
+// { dg-do compile { target c++11 } }
+
+#include 
+
+using namespace __gnu_test;
+
+#define SA(X) static_assert((X),#X)
+
+#define SA_TEST_CONST(TRAIT, TYPE, EXPECT) \
+  SA(TRAIT(TYPE) == EXPECT);   \
+  SA(TRAIT(const TYPE) == EXPECT)
+
+#define SA_TEST_CATEGORY(TRAIT, TYPE, EXPECT)  \
+  SA(TRAIT(TYPE) == EXPECT);   \
+  SA(TRAIT(const TYPE) == EXPECT); \
+  SA(TRAIT(volatile TYPE) == EXPECT);  \
+  SA(TRAIT(const volatile TYPE) == EXPECT)
+
+SA_TEST_CATEGORY(__is_bounded_array, int[2], true);
+SA_TEST_CATEGORY(__is_bounded_array, int[], false);
+SA_TEST_CATEGORY(__is_bounded_array, int[2][3], true);
+SA_TEST_CATEGORY(__is_bounded_array, int[][3], false);
+SA_TEST_CATEGORY(__is_bounded_array, float*[2], true);
+SA_TEST_CATEGORY(__is_bounded_array, float*[], false);
+SA_TEST_CATEGORY(__is_bounded_array, float*[2][3], true);
+SA_TEST_CATEGORY(__is_bounded_array, float*[][3], false);
+SA_TEST_CATEGORY(__is_bounded_array, ClassType[2], true);
+SA_TEST_CATEGORY(__is_bounded_array, ClassType[], false);
+SA_TEST_CATEGORY(__is_bounded_array, ClassType[2][3], true);
+SA_TEST_CATEGORY(__is_bounded_array, ClassType[][3], false);
+SA_TEST_CATEGORY(__is_bounded_array, int(*)[2], false);
+SA_TEST_CATEGORY(__is_bounded_array, int(*)[], false);
+SA_TEST_CATEGORY(__is_bounded_array, int(&)[2], false);
+SA_TEST_CONST(__is_bounded_array, int(&)[], false);
+
+// Sanity check.
+SA_TEST_CATEGORY(__is_bounded_array, ClassType, 

[PATCH 2/2] libstdc++: Optimize is_bounded_array trait performance

2023-09-11 Thread Ken Matsui via Gcc-patches
This patch optimizes the performance of the is_bounded_array trait
by dispatching to the new __is_bounded_array built-in trait.

libstdc++-v3/ChangeLog:

* include/std/type_traits (is_bounded_array_v): Use __is_bounded_array
built-in trait.

Signed-off-by: Ken Matsui 
---
 libstdc++-v3/include/std/type_traits | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index 677cd934b94..766f9a69445 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -3494,11 +3494,16 @@ template
   /// True for a type that is an array of known bound.
   /// @ingroup variable_templates
   /// @since C++20
+# if _GLIBCXX_USE_BUILTIN_TRAIT(__is_bounded_array)
+  template
+inline constexpr bool is_bounded_array_v = __is_bounded_array(_Tp);
+# else
   template
 inline constexpr bool is_bounded_array_v = false;
 
   template
 inline constexpr bool is_bounded_array_v<_Tp[_Size]> = true;
+# endif
 
   /// True for a type that is an array of unknown bound.
   /// @ingroup variable_templates
-- 
2.42.0



[PATCH 0/2] Optimize is_bounded_array trait performance

2023-09-11 Thread Ken Matsui via Gcc-patches
This patch series optimizes is_bounded_array trait
performance. The first patch implements __is_bounded_array
built-in trait. The second patch optimizes is_bounded_array
trait performance by using __is_bounded_array built-in trait
if available.

The performance improvement is shown in the following benchmark:

https://github.com/ken-matsui/gsoc23/blob/main/is_bounded_array_v.md#mon-sep-11-072608-pm-pdt-2023

Time:
Peak Memory Usage:
Total Memory Usage:

Ken Matsui (2):
  c++: Implement __is_bounded_array built-in trait
  libstdc++: Optimize is_bounded_array trait performance

 gcc/cp/constraint.cc|  3 ++
 gcc/cp/cp-trait.def |  1 +
 gcc/cp/semantics.cc |  4 +++
 gcc/testsuite/g++.dg/ext/has-builtin-1.C|  3 ++
 gcc/testsuite/g++.dg/ext/is_bounded_array.C | 38 +
 libstdc++-v3/include/std/type_traits|  5 +++
 6 files changed, 54 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/ext/is_bounded_array.C

-- 
2.42.0



Re: [PATCH] RISC-V: Add vcreate intrinsics for RVV tuple types

2023-09-11 Thread Kito Cheng via Gcc-patches
LGTM, thanks for implement this :)

On Tue, Sep 12, 2023 at 10:16 AM juzhe.zh...@rivai.ai
 wrote:
>
> Thanks for support it.
> LGTM from my side.
> Wait for kito's more comments.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: Li Xu
> Date: 2023-09-12 10:08
> To: gcc-patches
> CC: kito.cheng; palmer; juzhe.zhong; pan2.li; gaofei; wangfeng; xuli
> Subject: [PATCH] RISC-V: Add vcreate intrinsics for RVV tuple types
> From: xuli 
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vector-builtins-bases.cc (class vcreate):
> (BASE): New class.
> * config/riscv/riscv-vector-builtins-bases.h: Ditto.
> * config/riscv/riscv-vector-builtins-functions.def (vcreate): Add 
> vcreate support.
> * config/riscv/riscv-vector-builtins-shapes.cc (struct vcreate_def): 
> Ditto.
> (SHAPE): Ditto.
> * config/riscv/riscv-vector-builtins-shapes.h: Ditto.
> * config/riscv/riscv-vector-builtins.cc: Add args type.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/base/tuple_create.c: New test.
> ---
> .../riscv/riscv-vector-builtins-bases.cc  |  40 ++
> .../riscv/riscv-vector-builtins-bases.h   |   1 +
> .../riscv/riscv-vector-builtins-functions.def |   1 +
> .../riscv/riscv-vector-builtins-shapes.cc |  50 +++
> .../riscv/riscv-vector-builtins-shapes.h  |   1 +
> gcc/config/riscv/riscv-vector-builtins.cc |  12 ++
> .../gcc.target/riscv/rvv/base/tuple_create.c  | 123 ++
> 7 files changed, 228 insertions(+)
> create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/tuple_create.c
>
> diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc 
> b/gcc/config/riscv/riscv-vector-builtins-bases.cc
> index 8e679f72392..be3df2c1ea2 100644
> --- a/gcc/config/riscv/riscv-vector-builtins-bases.cc
> +++ b/gcc/config/riscv/riscv-vector-builtins-bases.cc
> @@ -1824,6 +1824,44 @@ public:
>}
> };
> +class vcreate : public function_base
> +{
> +public:
> +  gimple *fold (gimple_folder ) const override
> +  {
> +unsigned int nargs = gimple_call_num_args (f.call);
> +tree lhs_type = TREE_TYPE (f.lhs);
> +
> +/* Replace the call with a clobber of the result (to prevent it from
> +   becoming upwards exposed) followed by stores into each individual
> +   vector of tuple.
> +
> +   The fold routines expect the replacement statement to have the
> +   same lhs as the original call, so return the clobber statement
> +   rather than the final vector store.  */
> +gassign *clobber = gimple_build_assign (f.lhs, build_clobber (lhs_type));
> +
> +for (unsigned int i = nargs; i-- > 0; )
> +  {
> + tree rhs_vector = gimple_call_arg (f.call, i);
> + tree field = tuple_type_field (TREE_TYPE (f.lhs));
> + tree lhs_array = build3 (COMPONENT_REF, TREE_TYPE (field),
> + unshare_expr (f.lhs), field, NULL_TREE);
> + tree lhs_vector = build4 (ARRAY_REF, TREE_TYPE (rhs_vector),
> +   lhs_array, size_int (i),
> +   NULL_TREE, NULL_TREE);
> + gassign *assign = gimple_build_assign (lhs_vector, rhs_vector);
> + gsi_insert_after (f.gsi, assign, GSI_SAME_STMT);
> +  }
> +return clobber;
> +  }
> +
> +  rtx expand (function_expander ) const override
> +  {
> +return NULL_RTX;
> +  }
> +};
> +
> class read_vl : public function_base
> {
> public:
> @@ -2285,6 +2323,7 @@ static CONSTEXPR const vlmul_ext vlmul_ext_obj;
> static CONSTEXPR const vlmul_trunc vlmul_trunc_obj;
> static CONSTEXPR const vset vset_obj;
> static CONSTEXPR const vget vget_obj;
> +static CONSTEXPR const vcreate vcreate_obj;
> static CONSTEXPR const read_vl read_vl_obj;
> static CONSTEXPR const vleff vleff_obj;
> static CONSTEXPR const vlenb vlenb_obj;
> @@ -2546,6 +2585,7 @@ BASE (vlmul_ext)
> BASE (vlmul_trunc)
> BASE (vset)
> BASE (vget)
> +BASE (vcreate)
> BASE (read_vl)
> BASE (vleff)
> BASE (vlenb)
> diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.h 
> b/gcc/config/riscv/riscv-vector-builtins-bases.h
> index 69d4562091f..131041ea66f 100644
> --- a/gcc/config/riscv/riscv-vector-builtins-bases.h
> +++ b/gcc/config/riscv/riscv-vector-builtins-bases.h
> @@ -267,6 +267,7 @@ extern const function_base *const vlmul_ext;
> extern const function_base *const vlmul_trunc;
> extern const function_base *const vset;
> extern const function_base *const vget;
> +extern const function_base *const vcreate;
> extern const function_base *const read_vl;
> extern const function_base *const vleff;
> extern const function_base *const vlenb;
> diff --git a/gcc/config/riscv/riscv-vector-builtins-functions.def 
> b/gcc/config/riscv/riscv-vector-builtins-functions.def
> index 3ce06dc60b7..18ed2c2b8f6 100644
> --- a/gcc/config/riscv/riscv-vector-builtins-functions.def
> +++ b/gcc/config/riscv/riscv-vector-builtins-functions.def
> @@ -621,6 +621,7 @@ DEF_RVV_FUNCTION (vget, vget, none_preds, 
> all_v_vget_lmul4_x2_ops)
> // Tuple types
> DEF_RVV_FUNCTION (vset, vset, none_preds, all_v_vset_tuple_ops)
> DEF_RVV_FUNCTION (vget, vget, none_preds, 

Re: [PATCH 2/2] RISC-V: Make SHA-256, SM3 and SM4 builtins operate on uint32_t

2023-09-11 Thread Kito Cheng via Gcc-patches
LGTM, I think llvm and GCC are inconsistent for those intrinsics API
is really unfortunate...so really appreciate making those API align :)
And did you have plan to add riscv_crypto.h after updating/fixing all builtin?

On Tue, Sep 12, 2023 at 9:29 AM Tsukasa OI via Gcc-patches
 wrote:
>
> From: Tsukasa OI 
>
> This is in parity with the LLVM commit a64b3e92c7cb ("[RISCV] Re-define
> sha256, Zksed, and Zksh intrinsics to use i32 types.").
>
> SHA-256, SM3 and SM4 instructions operate on 32-bit integers and upper
> 32-bits have no effects on RV64 (the output is sign-extended from the
> original 32-bit value).  In that sense, making those intrinsics only
> operate on uint32_t is much more natural than XLEN-bits wide integers.
>
> This commit reforms instructions and expansions based on 32-bit
> instruction handling on RV64 (such as ADDW).
>
> Before:
>riscv__si: For RV32, fully operate on uint32_t
>riscv__di: For RV64, fully operate on uint64_t
> After:
>   *riscv__si: For RV32, fully operate on uint32_t
>riscv__di_extended:
>   For RV64.  Input is uint32_t and output is int64_t,
>   sign-extended from the int32_t result
>   (represents a part of  behavior).
>riscv__si: Common (fully operate on uint32_t).
>   On RV32, "expands" to *riscv__si.
>   On RV64, initially expands to riscv__di_extended *and*
>   extracts lower 32-bits from the int64_t result.
>
> It also refines definitions of SHA-256, SM3 and SM4 intrinsics.
>
> gcc/ChangeLog:
>
> * config/riscv/crypto.md (riscv_sha256sig0_,
> riscv_sha256sig1_, riscv_sha256sum0_,
> riscv_sha256sum1_, riscv_sm3p0_, riscv_sm3p1_,
> riscv_sm4ed_, riscv_sm4ks_): Remove and replace with
> new insn/expansions.
> (SHA256_OP, SM3_OP, SM4_OP): New iterators.
> (sha256_op, sm3_op, sm4_op): New attributes for iteration.
> (*riscv__si): New raw instruction for RV32.
> (*riscv__si): Ditto.
> (*riscv__si): Ditto.
> (riscv__di_extended): New base instruction for RV64.
> (riscv__di_extended): Ditto.
> (riscv__di_extended): Ditto.
> (riscv__si): New common instruction expansion.
> (riscv__si): Ditto.
> (riscv__si): Ditto.
> * config/riscv/riscv-builtins.cc: Add availability "crypto_zknh",
> "crypto_zksh" and "crypto_zksed".  Remove availability
> "crypto_zksh{32,64}" and "crypto_zksed{32,64}".
> * config/riscv/riscv-ftypes.def: Remove unused function type.
> * config/riscv/riscv-scalar-crypto.def: Make SHA-256, SM3 and SM4
> intrinsics to operate on uint32_t.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/zknh-sha256.c: Moved to...
> * gcc.target/riscv/zknh-sha256-64.c: ...here.  Test RV64.
> * gcc.target/riscv/zknh-sha256-32.c: New test for RV32.
> * gcc.target/riscv/zksh64.c: Change the type.
> * gcc.target/riscv/zksed64.c: Ditto.
> ---
>  gcc/config/riscv/crypto.md| 161 --
>  gcc/config/riscv/riscv-builtins.cc|   7 +-
>  gcc/config/riscv/riscv-ftypes.def |   1 -
>  gcc/config/riscv/riscv-scalar-crypto.def  |  24 +--
>  .../gcc.target/riscv/zknh-sha256-32.c |  10 ++
>  .../riscv/{zknh-sha256.c => zknh-sha256-64.c} |   8 +-
>  gcc/testsuite/gcc.target/riscv/zksed64.c  |   4 +-
>  gcc/testsuite/gcc.target/riscv/zksh64.c   |   4 +-
>  8 files changed, 139 insertions(+), 80 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/riscv/zknh-sha256-32.c
>  rename gcc/testsuite/gcc.target/riscv/{zknh-sha256.c => zknh-sha256-64.c} 
> (78%)
>
> diff --git a/gcc/config/riscv/crypto.md b/gcc/config/riscv/crypto.md
> index e4b7f0190dfe..03a1d03397d9 100644
> --- a/gcc/config/riscv/crypto.md
> +++ b/gcc/config/riscv/crypto.md
> @@ -250,36 +250,47 @@
>
>  ;; ZKNH - SHA256
>
> -(define_insn "riscv_sha256sig0_"
> -  [(set (match_operand:X 0 "register_operand" "=r")
> -(unspec:X [(match_operand:X 1 "register_operand" "r")]
> -  UNSPEC_SHA_256_SIG0))]
> -  "TARGET_ZKNH"
> -  "sha256sig0\t%0,%1"
> -  [(set_attr "type" "crypto")])
> -
> -(define_insn "riscv_sha256sig1_"
> -  [(set (match_operand:X 0 "register_operand" "=r")
> -(unspec:X [(match_operand:X 1 "register_operand" "r")]
> -  UNSPEC_SHA_256_SIG1))]
> -  "TARGET_ZKNH"
> -  "sha256sig1\t%0,%1"
> +(define_int_iterator SHA256_OP [
> +  UNSPEC_SHA_256_SIG0 UNSPEC_SHA_256_SIG1
> +  UNSPEC_SHA_256_SUM0 UNSPEC_SHA_256_SUM1])
> +(define_int_attr sha256_op [
> +  (UNSPEC_SHA_256_SIG0 "sha256sig0") (UNSPEC_SHA_256_SIG1 "sha256sig1")
> +  (UNSPEC_SHA_256_SUM0 "sha256sum0") (UNSPEC_SHA_256_SUM1 "sha256sum1")])
> +
> +(define_insn "*riscv__si"
> +  [(set (match_operand:SI 0 "register_operand" "=r")
> +(unspec:SI [(match_operand:SI 1 "register_operand" "r")]
> +   

Re: [PATCH] RISC-V: Finish Typing Un-Typed Instructions and Turn on Assert

2023-09-11 Thread Lehua Ding

Hi Edwin,

Sorry to bother you. I have a small question for you.

On 2023/9/12 6:52, Edwin Lu wrote:
--- a/gcc/config/riscv/autovec-opt.md +++ 
b/gcc/config/riscv/autovec-opt.md @@ -649,7 +649,8 @@ 
(define_insn_and_split "*cond_" gen_int_mode 
(GET_MODE_NUNITS (mode), Pmode)}; 
riscv_vector::expand_cond_len_unop (icode, ops); DONE; -}) +} 
+[(set_attr "type" "vector")])


Is it necessary to add type attribute to these INSNs that exist only 
before split1 pass? These instructions are expanded into the pattern in 
vector.md after split1 pass and do not reach the sched1 pass at all. If 
so, I feel that these patterns cannot be added, and it is reasonable to 
report an error if these INSNs reach sched1 pass. Thanks.


--
Best,
Lehua



Re: [PATCH] RISC-V: Add vcreate intrinsics for RVV tuple types

2023-09-11 Thread juzhe.zh...@rivai.ai
Thanks for support it.
LGTM from my side.
Wait for kito's more comments.



juzhe.zh...@rivai.ai
 
From: Li Xu
Date: 2023-09-12 10:08
To: gcc-patches
CC: kito.cheng; palmer; juzhe.zhong; pan2.li; gaofei; wangfeng; xuli
Subject: [PATCH] RISC-V: Add vcreate intrinsics for RVV tuple types
From: xuli 
 
gcc/ChangeLog:
 
* config/riscv/riscv-vector-builtins-bases.cc (class vcreate):
(BASE): New class.
* config/riscv/riscv-vector-builtins-bases.h: Ditto.
* config/riscv/riscv-vector-builtins-functions.def (vcreate): Add 
vcreate support.
* config/riscv/riscv-vector-builtins-shapes.cc (struct vcreate_def): 
Ditto.
(SHAPE): Ditto.
* config/riscv/riscv-vector-builtins-shapes.h: Ditto.
* config/riscv/riscv-vector-builtins.cc: Add args type.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/base/tuple_create.c: New test.
---
.../riscv/riscv-vector-builtins-bases.cc  |  40 ++
.../riscv/riscv-vector-builtins-bases.h   |   1 +
.../riscv/riscv-vector-builtins-functions.def |   1 +
.../riscv/riscv-vector-builtins-shapes.cc |  50 +++
.../riscv/riscv-vector-builtins-shapes.h  |   1 +
gcc/config/riscv/riscv-vector-builtins.cc |  12 ++
.../gcc.target/riscv/rvv/base/tuple_create.c  | 123 ++
7 files changed, 228 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/tuple_create.c
 
diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc 
b/gcc/config/riscv/riscv-vector-builtins-bases.cc
index 8e679f72392..be3df2c1ea2 100644
--- a/gcc/config/riscv/riscv-vector-builtins-bases.cc
+++ b/gcc/config/riscv/riscv-vector-builtins-bases.cc
@@ -1824,6 +1824,44 @@ public:
   }
};
+class vcreate : public function_base
+{
+public:
+  gimple *fold (gimple_folder ) const override
+  {
+unsigned int nargs = gimple_call_num_args (f.call);
+tree lhs_type = TREE_TYPE (f.lhs);
+
+/* Replace the call with a clobber of the result (to prevent it from
+   becoming upwards exposed) followed by stores into each individual
+   vector of tuple.
+
+   The fold routines expect the replacement statement to have the
+   same lhs as the original call, so return the clobber statement
+   rather than the final vector store.  */
+gassign *clobber = gimple_build_assign (f.lhs, build_clobber (lhs_type));
+
+for (unsigned int i = nargs; i-- > 0; )
+  {
+ tree rhs_vector = gimple_call_arg (f.call, i);
+ tree field = tuple_type_field (TREE_TYPE (f.lhs));
+ tree lhs_array = build3 (COMPONENT_REF, TREE_TYPE (field),
+ unshare_expr (f.lhs), field, NULL_TREE);
+ tree lhs_vector = build4 (ARRAY_REF, TREE_TYPE (rhs_vector),
+   lhs_array, size_int (i),
+   NULL_TREE, NULL_TREE);
+ gassign *assign = gimple_build_assign (lhs_vector, rhs_vector);
+ gsi_insert_after (f.gsi, assign, GSI_SAME_STMT);
+  }
+return clobber;
+  }
+
+  rtx expand (function_expander ) const override
+  {
+return NULL_RTX;
+  }
+};
+
class read_vl : public function_base
{
public:
@@ -2285,6 +2323,7 @@ static CONSTEXPR const vlmul_ext vlmul_ext_obj;
static CONSTEXPR const vlmul_trunc vlmul_trunc_obj;
static CONSTEXPR const vset vset_obj;
static CONSTEXPR const vget vget_obj;
+static CONSTEXPR const vcreate vcreate_obj;
static CONSTEXPR const read_vl read_vl_obj;
static CONSTEXPR const vleff vleff_obj;
static CONSTEXPR const vlenb vlenb_obj;
@@ -2546,6 +2585,7 @@ BASE (vlmul_ext)
BASE (vlmul_trunc)
BASE (vset)
BASE (vget)
+BASE (vcreate)
BASE (read_vl)
BASE (vleff)
BASE (vlenb)
diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.h 
b/gcc/config/riscv/riscv-vector-builtins-bases.h
index 69d4562091f..131041ea66f 100644
--- a/gcc/config/riscv/riscv-vector-builtins-bases.h
+++ b/gcc/config/riscv/riscv-vector-builtins-bases.h
@@ -267,6 +267,7 @@ extern const function_base *const vlmul_ext;
extern const function_base *const vlmul_trunc;
extern const function_base *const vset;
extern const function_base *const vget;
+extern const function_base *const vcreate;
extern const function_base *const read_vl;
extern const function_base *const vleff;
extern const function_base *const vlenb;
diff --git a/gcc/config/riscv/riscv-vector-builtins-functions.def 
b/gcc/config/riscv/riscv-vector-builtins-functions.def
index 3ce06dc60b7..18ed2c2b8f6 100644
--- a/gcc/config/riscv/riscv-vector-builtins-functions.def
+++ b/gcc/config/riscv/riscv-vector-builtins-functions.def
@@ -621,6 +621,7 @@ DEF_RVV_FUNCTION (vget, vget, none_preds, 
all_v_vget_lmul4_x2_ops)
// Tuple types
DEF_RVV_FUNCTION (vset, vset, none_preds, all_v_vset_tuple_ops)
DEF_RVV_FUNCTION (vget, vget, none_preds, all_v_vget_tuple_ops)
+DEF_RVV_FUNCTION (vcreate, vcreate, none_preds, all_v_vcreate_tuple_ops)
DEF_RVV_FUNCTION (vlseg, seg_loadstore, full_preds, 
tuple_v_scalar_const_ptr_ops)
DEF_RVV_FUNCTION (vsseg, seg_loadstore, none_m_preds, tuple_v_scalar_ptr_ops)
DEF_RVV_FUNCTION (vlsseg, seg_loadstore, full_preds, 
tuple_v_scalar_const_ptr_ptrdiff_ops)
diff --git 

[PATCH] RISC-V: Add vcreate intrinsics for RVV tuple types

2023-09-11 Thread Li Xu
From: xuli 

gcc/ChangeLog:

* config/riscv/riscv-vector-builtins-bases.cc (class vcreate):
(BASE): New class.
* config/riscv/riscv-vector-builtins-bases.h: Ditto.
* config/riscv/riscv-vector-builtins-functions.def (vcreate): Add 
vcreate support.
* config/riscv/riscv-vector-builtins-shapes.cc (struct vcreate_def): 
Ditto.
(SHAPE): Ditto.
* config/riscv/riscv-vector-builtins-shapes.h: Ditto.
* config/riscv/riscv-vector-builtins.cc: Add args type.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/tuple_create.c: New test.
---
 .../riscv/riscv-vector-builtins-bases.cc  |  40 ++
 .../riscv/riscv-vector-builtins-bases.h   |   1 +
 .../riscv/riscv-vector-builtins-functions.def |   1 +
 .../riscv/riscv-vector-builtins-shapes.cc |  50 +++
 .../riscv/riscv-vector-builtins-shapes.h  |   1 +
 gcc/config/riscv/riscv-vector-builtins.cc |  12 ++
 .../gcc.target/riscv/rvv/base/tuple_create.c  | 123 ++
 7 files changed, 228 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/tuple_create.c

diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc 
b/gcc/config/riscv/riscv-vector-builtins-bases.cc
index 8e679f72392..be3df2c1ea2 100644
--- a/gcc/config/riscv/riscv-vector-builtins-bases.cc
+++ b/gcc/config/riscv/riscv-vector-builtins-bases.cc
@@ -1824,6 +1824,44 @@ public:
   }
 };
 
+class vcreate : public function_base
+{
+public:
+  gimple *fold (gimple_folder ) const override
+  {
+unsigned int nargs = gimple_call_num_args (f.call);
+tree lhs_type = TREE_TYPE (f.lhs);
+
+/* Replace the call with a clobber of the result (to prevent it from
+   becoming upwards exposed) followed by stores into each individual
+   vector of tuple.
+
+   The fold routines expect the replacement statement to have the
+   same lhs as the original call, so return the clobber statement
+   rather than the final vector store.  */
+gassign *clobber = gimple_build_assign (f.lhs, build_clobber (lhs_type));
+
+for (unsigned int i = nargs; i-- > 0; )
+  {
+   tree rhs_vector = gimple_call_arg (f.call, i);
+   tree field = tuple_type_field (TREE_TYPE (f.lhs));
+   tree lhs_array = build3 (COMPONENT_REF, TREE_TYPE (field),
+unshare_expr (f.lhs), field, NULL_TREE);
+   tree lhs_vector = build4 (ARRAY_REF, TREE_TYPE (rhs_vector),
+ lhs_array, size_int (i),
+ NULL_TREE, NULL_TREE);
+   gassign *assign = gimple_build_assign (lhs_vector, rhs_vector);
+   gsi_insert_after (f.gsi, assign, GSI_SAME_STMT);
+  }
+return clobber;
+  }
+
+  rtx expand (function_expander ) const override
+  {
+return NULL_RTX;
+  }
+};
+
 class read_vl : public function_base
 {
 public:
@@ -2285,6 +2323,7 @@ static CONSTEXPR const vlmul_ext vlmul_ext_obj;
 static CONSTEXPR const vlmul_trunc vlmul_trunc_obj;
 static CONSTEXPR const vset vset_obj;
 static CONSTEXPR const vget vget_obj;
+static CONSTEXPR const vcreate vcreate_obj;
 static CONSTEXPR const read_vl read_vl_obj;
 static CONSTEXPR const vleff vleff_obj;
 static CONSTEXPR const vlenb vlenb_obj;
@@ -2546,6 +2585,7 @@ BASE (vlmul_ext)
 BASE (vlmul_trunc)
 BASE (vset)
 BASE (vget)
+BASE (vcreate)
 BASE (read_vl)
 BASE (vleff)
 BASE (vlenb)
diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.h 
b/gcc/config/riscv/riscv-vector-builtins-bases.h
index 69d4562091f..131041ea66f 100644
--- a/gcc/config/riscv/riscv-vector-builtins-bases.h
+++ b/gcc/config/riscv/riscv-vector-builtins-bases.h
@@ -267,6 +267,7 @@ extern const function_base *const vlmul_ext;
 extern const function_base *const vlmul_trunc;
 extern const function_base *const vset;
 extern const function_base *const vget;
+extern const function_base *const vcreate;
 extern const function_base *const read_vl;
 extern const function_base *const vleff;
 extern const function_base *const vlenb;
diff --git a/gcc/config/riscv/riscv-vector-builtins-functions.def 
b/gcc/config/riscv/riscv-vector-builtins-functions.def
index 3ce06dc60b7..18ed2c2b8f6 100644
--- a/gcc/config/riscv/riscv-vector-builtins-functions.def
+++ b/gcc/config/riscv/riscv-vector-builtins-functions.def
@@ -621,6 +621,7 @@ DEF_RVV_FUNCTION (vget, vget, none_preds, 
all_v_vget_lmul4_x2_ops)
 // Tuple types
 DEF_RVV_FUNCTION (vset, vset, none_preds, all_v_vset_tuple_ops)
 DEF_RVV_FUNCTION (vget, vget, none_preds, all_v_vget_tuple_ops)
+DEF_RVV_FUNCTION (vcreate, vcreate, none_preds, all_v_vcreate_tuple_ops)
 DEF_RVV_FUNCTION (vlseg, seg_loadstore, full_preds, 
tuple_v_scalar_const_ptr_ops)
 DEF_RVV_FUNCTION (vsseg, seg_loadstore, none_m_preds, tuple_v_scalar_ptr_ops)
 DEF_RVV_FUNCTION (vlsseg, seg_loadstore, full_preds, 
tuple_v_scalar_const_ptr_ptrdiff_ops)
diff --git a/gcc/config/riscv/riscv-vector-builtins-shapes.cc 
b/gcc/config/riscv/riscv-vector-builtins-shapes.cc
index 

Re: [PATCH v5] RISC-V:Optimize the MASK opt generation

2023-09-11 Thread Kito Cheng via Gcc-patches
Hi Feng:

This version is LGTM, but I guess I would like to ask Jeff or another
global maintainer to approve that, anyway I'll follow up this in the
next gcc sync up meeting :)

On Fri, Sep 8, 2023 at 9:28 AM Feng Wang  wrote:
>
> Accoring to Kito's advice, using "MASK(name) Var(other_flag_name)"
> to generate MASK and TARGET MACRO automatically.
> This patch improve the MACRO generation of MASK_* and TARGET_*.
> Due to the more and more riscv extensions are added, the default target_flag
> is full.
> Before this patch,if you want to add new MACRO,you should define the
> MACRO in the riscv-opts.h manually.
> After this patch, you just need two steps:
> 1.Define the new TargetVariable.
> 2.Define "MASK(name) Var(new_target_flag).
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-opts.h (MASK_ZICSR):
> (MASK_ZIFENCEI): Delete;
> (MASK_ZIHINTNTL):Ditto;
> (MASK_ZIHINTPAUSE):  Ditto;
> (TARGET_ZICSR):  Ditto;
> (TARGET_ZIFENCEI):   Ditto;
> (TARGET_ZIHINTNTL):  Ditto;
> (TARGET_ZIHINTPAUSE):Ditto;
> (MASK_ZAWRS):Ditto;
> (TARGET_ZAWRS):  Ditto;
> (MASK_ZBA):  Ditto;
> (MASK_ZBB):  Ditto;
> (MASK_ZBC):  Ditto;
> (MASK_ZBS):  Ditto;
> (TARGET_ZBA):Ditto;
> (TARGET_ZBB):Ditto;
> (TARGET_ZBC):Ditto;
> (TARGET_ZBS):Ditto;
> (MASK_ZFINX):Ditto;
> (MASK_ZDINX):Ditto;
> (MASK_ZHINX):Ditto;
> (MASK_ZHINXMIN): Ditto;
> (TARGET_ZFINX):  Ditto;
> (TARGET_ZDINX):  Ditto;
> (TARGET_ZHINX):  Ditto;
> (TARGET_ZHINXMIN):   Ditto;
> (MASK_ZBKB): Ditto;
> (MASK_ZBKC): Ditto;
> (MASK_ZBKX): Ditto;
> (MASK_ZKNE): Ditto;
> (MASK_ZKND): Ditto;
> (MASK_ZKNH): Ditto;
> (MASK_ZKR):  Ditto;
> (MASK_ZKSED):Ditto;
> (MASK_ZKSH): Ditto;
> (MASK_ZKT):  Ditto;
> (TARGET_ZBKB):   Ditto;
> (TARGET_ZBKC):   Ditto;
> (TARGET_ZBKX):   Ditto;
> (TARGET_ZKNE):   Ditto;
> (TARGET_ZKND):   Ditto;
> (TARGET_ZKNH):   Ditto;
> (TARGET_ZKR):Ditto;
> (TARGET_ZKSED):  Ditto;
> (TARGET_ZKSH):   Ditto;
> (TARGET_ZKT):Ditto;
> (MASK_ZTSO): Ditto;
> (TARGET_ZTSO):   Ditto;
> (MASK_VECTOR_ELEN_32):   Ditto;
> (MASK_VECTOR_ELEN_64):   Ditto;
> (MASK_VECTOR_ELEN_FP_32):Ditto;
> (MASK_VECTOR_ELEN_FP_64):Ditto;
> (MASK_VECTOR_ELEN_FP_16):Ditto;
> (TARGET_VECTOR_ELEN_32): Ditto;
> (TARGET_VECTOR_ELEN_64): Ditto;
> (TARGET_VECTOR_ELEN_FP_32):Ditto;
> (TARGET_VECTOR_ELEN_FP_64):Ditto;
> (TARGET_VECTOR_ELEN_FP_16):Ditto;
>  (MASK_ZVBB):   Ditto;
> (MASK_ZVBC):   Ditto;
> (TARGET_ZVBB): Ditto;
> (TARGET_ZVBC): Ditto;
> (MASK_ZVKG):   Ditto;
> (MASK_ZVKNED): Ditto;
> (MASK_ZVKNHA): Ditto;
> (MASK_ZVKNHB): Ditto;
> (MASK_ZVKSED): Ditto;
> (MASK_ZVKSH):  Ditto;
> (MASK_ZVKN):   Ditto;
> (MASK_ZVKNC):  Ditto;
> (MASK_ZVKNG):  Ditto;
> (MASK_ZVKS):   Ditto;
> (MASK_ZVKSC):  Ditto;
> (MASK_ZVKSG):  Ditto;
> (MASK_ZVKT):   Ditto;
> (TARGET_ZVKG): Ditto;
> (TARGET_ZVKNED):   Ditto;
> (TARGET_ZVKNHA):   Ditto;
> (TARGET_ZVKNHB):   Ditto;
> (TARGET_ZVKSED):   Ditto;
> (TARGET_ZVKSH):Ditto;
> (TARGET_ZVKN): Ditto;
> (TARGET_ZVKNC):Ditto;
> (TARGET_ZVKNG):Ditto;
> (TARGET_ZVKS): Ditto;
> (TARGET_ZVKSC):Ditto;
> (TARGET_ZVKSG):Ditto;
> (TARGET_ZVKT): Ditto;
> (MASK_ZVL32B): Ditto;
> (MASK_ZVL64B): Ditto;
> (MASK_ZVL128B):Ditto;
> (MASK_ZVL256B):Ditto;
> (MASK_ZVL512B):Ditto;
> (MASK_ZVL1024B):   Ditto;
> (MASK_ZVL2048B):   Ditto;
> (MASK_ZVL4096B):   Ditto;
> (MASK_ZVL8192B):   Ditto;
> (MASK_ZVL16384B):  Ditto;
> (MASK_ZVL32768B):  Ditto;
> (MASK_ZVL65536B):  Ditto;
> (TARGET_ZVL32B):   Ditto;
> (TARGET_ZVL64B):   Ditto;
> (TARGET_ZVL128B):  Ditto;
> (TARGET_ZVL256B):  Ditto;
> (TARGET_ZVL512B):  Ditto;
> (TARGET_ZVL1024B): Ditto;
> (TARGET_ZVL2048B): Ditto;
> 

Re: [PATCH 0/2] resolve confilct between zcmp multi push/pop and shrink-wrap-separate

2023-09-11 Thread Kito Cheng via Gcc-patches
Pushed to trunk, thanks :)

On Wed, Sep 6, 2023 at 5:41 PM Fei Gao  wrote:
>
> Enable muti push and pop for Zcmp when shrink-wrap-separate is ineffective.
>
> Fei Gao (2):
>   allow targets to check shrink-wrap-separate enabled or not
>   [V2][RISC-V] enable muti push and pop for Zcmp when shrink-wrap-separate is 
> ineffective
>
>  gcc/config/riscv/riscv.cc | 21 -
>  gcc/shrink-wrap.cc| 22 +++--
>  gcc/shrink-wrap.h |  1 +
>  gcc/testsuite/gcc.target/riscv/rv32e_zcmp.c   |  2 +-
>  gcc/testsuite/gcc.target/riscv/rv32i_zcmp.c   |  2 +-
>  .../gcc.target/riscv/zcmp_push_fpr.c  |  2 +-
>  .../riscv/zcmp_shrink_wrap_separate.c | 93 +++
>  .../riscv/zcmp_shrink_wrap_separate2.c| 93 +++
>  .../gcc.target/riscv/zcmp_stack_alignment.c   |  2 +-
>  9 files changed, 223 insertions(+), 15 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/riscv/zcmp_shrink_wrap_separate.c
>  create mode 100644 
> gcc/testsuite/gcc.target/riscv/zcmp_shrink_wrap_separate2.c
>
> --
> 2.17.1
>


RE: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV intrinsic

2023-09-11 Thread Li, Pan2 via Gcc-patches
Got it, will have a try.

Pan

From: juzhe.zh...@rivai.ai 
Sent: Tuesday, September 12, 2023 9:30 AM
To: Li, Pan2 
Cc: kito.cheng ; gcc-patches ; 
Wang, Yanzhang 
Subject: Re: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for 
RVV intrinsic

Add a function call get_non_overloaded_instance into instance.
The instance already know it is void vmv (void).
In this function search the arglist. and return the real non-overloaded decl.


juzhe.zh...@rivai.ai

From: Li, Pan2
Date: 2023-09-12 09:20
To: 钟居哲
CC: kito.cheng; 
gcc-patches; Wang, 
Yanzhang
Subject: RE: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for 
RVV intrinsic
We cannot leverage this instance for correctness.
The rfun of below code is the overloaded builtin is for the overloaded 
function, which is registered as void xxx(void) as aarch64 did to avoid the 
conflict.

Let’s take vmv_v_i32m1 as example in rfun table.

Index 0: void vmv_v(void) overloaded
Index 1: i32m1 vmv_v_v_i32m1_i32m1 (i32m1, size_t) non-overloaded
Index 2: placeholder.

When we enter the hook(aka the code list below), the rfun we have is the index 
0 rfun instead of index 1.
Then we need the arglist to lookup the rfun of index 1 for the underlying call, 
as well as build the instance for the index 1 rfun.

Aarch64 has the same rfun table as above, they leverage a loop to parse the 
arglist with machine mode matching in a predefined type suffix(which is not 
available in RISC-V).

I think they almost try to resolve the same problem but different implement 
details.

Pan

From: 钟居哲 mailto:juzhe.zh...@rivai.ai>>
Sent: Tuesday, September 12, 2023 7:20 AM
To: Li, Pan2 mailto:pan2...@intel.com>>
Cc: kito.cheng mailto:kito.ch...@gmail.com>>; gcc-patches 
mailto:gcc-patches@gcc.gnu.org>>; Wang, Yanzhang 
mailto:yanzhang.w...@intel.com>>
Subject: Re: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for 
RVV intrinsic

I don't understand.


+tree

+resolve_overloaded_builtin (location_t loc, unsigned int code,

+ vec *arglist)

+{

+  if (code >= vec_safe_length (registered_functions))

+return NULL_TREE;

+

+  const registered_function *rfun = (*registered_functions)[code];

+

+  if (!rfun || !rfun->overloaded_p)

+return NULL_TREE;

+

+  return function_resolver (loc, rfun->instance, rfun->decl, *arglist)

+.resolve ();

+}
You already have rfun->instance. Just use this instance should be good enough.

juzhe.zh...@rivai.ai

From: Li, Pan2
Date: 2023-09-11 23:24
To: 钟居哲
CC: kito.cheng; 
gcc-patches; Wang, 
Yanzhang
Subject: RE: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for 
RVV intrinsic
For function instance with void or void arguments, it is easy as you mentioned 
as below.

For generate API (to get the right hash), you need to build the rvv_type_info, 
predications_type_index and rvv_op_info
from the arglist (aka vec) from hook.

Then we need to construct above parameters from one tree argument. Sorry I not 
sure if I understand correctly but I failed
to locate somewhere has similar usage.

Could you please help to insight me some best practice about the transformation 
from tree to above types?

Pan

From: 钟居哲 mailto:juzhe.zh...@rivai.ai>>
Sent: Monday, September 11, 2023 9:07 PM
To: Li, Pan2 mailto:pan2...@intel.com>>
Cc: kito.cheng mailto:kito.ch...@gmail.com>>; gcc-patches 
mailto:gcc-patches@gcc.gnu.org>>; Wang, Yanzhang 
mailto:yanzhang.w...@intel.com>>
Subject: Re: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for 
RVV intrinsic

function_instance
get_read_vl_instance (void)
{
  return function_instance ("read_vl", bases::read_vl, shapes::read_vl,
  none_ops[0], PRED_TYPE_none, _none_void_ops);
}

tree
get_read_vl_decl (void)
{
  function_instance instance = get_read_vl_instance ();
  hashval_t hash = instance.hash ();
  registered_function *rfn = function_table->find_with_hash (instance, hash);
  gcc_assert (rfn);
  return rfn->decl;
}

You should reference it. I don't see why it's hard for use to construct 
instance first, then use that instance hash to get the decl.

juzhe.zh...@rivai.ai

From: Li, Pan2
Date: 2023-09-11 20:26
To: juzhe.zhong
CC: kito.cheng; 
gcc-patches; Wang, 
Yanzhang
Subject: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV 
intrinsic
> No. You must construct instance. 'strcmp' is very ugly.

Strcmp here 

Re: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV intrinsic

2023-09-11 Thread juzhe.zh...@rivai.ai
Add a function call get_non_overloaded_instance into instance.
The instance already know it is void vmv (void).
In this function search the arglist. and return the real non-overloaded decl.



juzhe.zh...@rivai.ai
 
From: Li, Pan2
Date: 2023-09-12 09:20
To: 钟居哲
CC: kito.cheng; gcc-patches; Wang, Yanzhang
Subject: RE: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for 
RVV intrinsic
We cannot leverage this instance for correctness.
The rfun of below code is the overloaded builtin is for the overloaded 
function, which is registered as void xxx(void) as aarch64 did to avoid the 
conflict.
 
Let’s take vmv_v_i32m1 as example in rfun table.
 
Index 0: void vmv_v(void) overloaded
Index 1: i32m1 vmv_v_v_i32m1_i32m1 (i32m1, size_t) non-overloaded
Index 2: placeholder.
 
When we enter the hook(aka the code list below), the rfun we have is the index 
0 rfun instead of index 1.
Then we need the arglist to lookup the rfun of index 1 for the underlying call, 
as well as build the instance for the index 1 rfun.
 
Aarch64 has the same rfun table as above, they leverage a loop to parse the 
arglist with machine mode matching in a predefined type suffix(which is not 
available in RISC-V).
 
I think they almost try to resolve the same problem but different implement 
details.
 
Pan
 
From: 钟居哲  
Sent: Tuesday, September 12, 2023 7:20 AM
To: Li, Pan2 
Cc: kito.cheng ; gcc-patches ; 
Wang, Yanzhang 
Subject: Re: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for 
RVV intrinsic
 
I don't understand.
 
+tree+resolve_overloaded_builtin (location_t loc, unsigned int code,+   
   vec *arglist)+{+  if (code >= vec_safe_length 
(registered_functions))+return NULL_TREE;++  const registered_function 
*rfun = (*registered_functions)[code];++  if (!rfun || !rfun->overloaded_p)+
return NULL_TREE;++  return function_resolver (loc, rfun->instance, rfun->decl, 
*arglist)+.resolve ();+}
You already have rfun->instance. Just use this instance should be good enough.


juzhe.zh...@rivai.ai
 
From: Li, Pan2
Date: 2023-09-11 23:24
To: 钟居哲
CC: kito.cheng; gcc-patches; Wang, Yanzhang
Subject: RE: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for 
RVV intrinsic
For function instance with void or void arguments, it is easy as you mentioned 
as below.
 
For generate API (to get the right hash), you need to build the rvv_type_info, 
predications_type_index and rvv_op_info
from the arglist (aka vec) from hook.
 
Then we need to construct above parameters from one tree argument. Sorry I not 
sure if I understand correctly but I failed
to locate somewhere has similar usage.
 
Could you please help to insight me some best practice about the transformation 
from tree to above types?
 
Pan
 
From: 钟居哲  
Sent: Monday, September 11, 2023 9:07 PM
To: Li, Pan2 
Cc: kito.cheng ; gcc-patches ; 
Wang, Yanzhang 
Subject: Re: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for 
RVV intrinsic
 
function_instance
get_read_vl_instance (void)
{
  return function_instance ("read_vl", bases::read_vl, shapes::read_vl,
  none_ops[0], PRED_TYPE_none, _none_void_ops);
}
 
tree
get_read_vl_decl (void)
{
  function_instance instance = get_read_vl_instance ();
  hashval_t hash = instance.hash ();
  registered_function *rfn = function_table->find_with_hash (instance, hash);
  gcc_assert (rfn);
  return rfn->decl;
}
 
You should reference it. I don't see why it's hard for use to construct 
instance first, then use that instance hash to get the decl.


juzhe.zh...@rivai.ai
 
From: Li, Pan2
Date: 2023-09-11 20:26
To: juzhe.zhong
CC: kito.cheng; gcc-patches; Wang, Yanzhang
Subject: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV 
intrinsic
> No. You must construct instance. 'strcmp' is very ugly.
 
Strcmp here is defensive code here for early exit if not found (can be removed 
for correctness), which is not required to find the right declaration.
 
Pan
 
From: juzhe.zhong  
Sent: Monday, September 11, 2023 8:20 PM
To: Li, Pan2 
Cc: kito.cheng ; gcc-patches ; 
Wang, Yanzhang 
Subject: Re: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV 
intrinsic
 
No. You must construct instance. 'strcmp' is very ugly.
 Replied Message 
From
Li, Pan2
Date
09/11/2023 20:09
To
juzhe.zh...@rivai.ai,
kito.cheng
Cc
gcc-patches,
Wang, Yanzhang
Subject
RE: Re: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV 
intrinsic
> -if (overloaded_p && instance.pred == PRED_TYPE_m)
> +if (overloaded_p)
 
Thanks for pointing this out, my misunderstanding for policy function result in 
this change as mistake, will send V2 for this.
 
> Plz change it into : Actually, it is not easy to convert to this approach as 
> aarch64 has different implementation of types information.Like 
> type_suffix_info (aarch64 loop type suffix to get the arglist type in 
> infer_vector_or_tuple_type) etc.Thus, it is not easy to construct 
> rvv_type_info, predication_type_index and 

[PATCH 1/2] RISC-V: Make bit manipulation value / round number and shift amount types for builtins unsigned

2023-09-11 Thread Tsukasa OI via Gcc-patches
From: Tsukasa OI 

For bit manipulation operations, input(s) and the manipulated output are
better to be unsigned like other target-independent builtins like
__builtin_bswap32 and __builtin_popcount.

Although this is not completely compatible as before (as the type changes),
most code will run normally, even without warnings (with -Wall -Wextra).

To make consistent to the LLVM commit 599421ae36c3 ("[RISCV] Use unsigned
instead of signed types for Zk* and Zb* builtins."), round numbers and
shift amount on the scalar crypto instructions are also changed
to unsigned.

gcc/ChangeLog:

* config/riscv/riscv-builtins.cc (RISCV_ATYPE_UQI): New for
uint8_t.  (RISCV_ATYPE_UHI): New for uint16_t.
(RISCV_ATYPE_QI, RISCV_ATYPE_HI, RISCV_ATYPE_SI, RISCV_ATYPE_DI):
Removed as no longer used.
(RISCV_ATYPE_UDI): New for uint64_t.
* config/riscv/riscv-cmo.def: Make types unsigned for not working
"zicbop_cbo_prefetchi" and working bit manipulation clmul builtin
argument/return types.
* config/riscv/riscv-ftypes.def: Make bit manipulation, round
number and shift amount types unsigned.
* config/riscv/riscv-scalar-crypto.def: Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/zbc32.c: Make signed type to unsigned.
* gcc.target/riscv/zbc64.c: Ditto.
* gcc.target/riscv/zbkb32.c: Ditto.
* gcc.target/riscv/zbkb64.c: Ditto.
* gcc.target/riscv/zbkc32.c: Ditto.
* gcc.target/riscv/zbkc64.c: Ditto.
* gcc.target/riscv/zbkx32.c: Ditto.
* gcc.target/riscv/zbkx64.c: Ditto.
* gcc.target/riscv/zknd32.c: Ditto.
* gcc.target/riscv/zknd64.c: Ditto.
* gcc.target/riscv/zkne32.c: Ditto.
* gcc.target/riscv/zkne64.c: Ditto.
* gcc.target/riscv/zknh-sha256.c: Ditto.
* gcc.target/riscv/zknh-sha512-32.c: Ditto.
* gcc.target/riscv/zknh-sha512-64.c: Ditto.
* gcc.target/riscv/zksed32.c: Ditto.
* gcc.target/riscv/zksed64.c: Ditto.
* gcc.target/riscv/zksh32.c: Ditto.
* gcc.target/riscv/zksh64.c: Ditto.
---
 gcc/config/riscv/riscv-builtins.cc|   7 +-
 gcc/config/riscv/riscv-cmo.def|  16 +--
 gcc/config/riscv/riscv-ftypes.def |  24 ++--
 gcc/config/riscv/riscv-scalar-crypto.def  | 104 +-
 gcc/testsuite/gcc.target/riscv/zbc32.c|   6 +-
 gcc/testsuite/gcc.target/riscv/zbc64.c|   6 +-
 gcc/testsuite/gcc.target/riscv/zbkb32.c   |  10 +-
 gcc/testsuite/gcc.target/riscv/zbkb64.c   |   8 +-
 gcc/testsuite/gcc.target/riscv/zbkc32.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zbkc64.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zbkx32.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zbkx64.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zknd32.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zknd64.c   |  10 +-
 gcc/testsuite/gcc.target/riscv/zkne32.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zkne64.c   |   8 +-
 gcc/testsuite/gcc.target/riscv/zknh-sha256.c  |   8 +-
 .../gcc.target/riscv/zknh-sha512-32.c |  12 +-
 .../gcc.target/riscv/zknh-sha512-64.c |   8 +-
 gcc/testsuite/gcc.target/riscv/zksed32.c  |   4 +-
 gcc/testsuite/gcc.target/riscv/zksed64.c  |   4 +-
 gcc/testsuite/gcc.target/riscv/zksh32.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zksh64.c   |   4 +-
 23 files changed, 133 insertions(+), 134 deletions(-)

diff --git a/gcc/config/riscv/riscv-builtins.cc 
b/gcc/config/riscv/riscv-builtins.cc
index 8afe7b7e97d3..f6b06b3c16ac 100644
--- a/gcc/config/riscv/riscv-builtins.cc
+++ b/gcc/config/riscv/riscv-builtins.cc
@@ -155,11 +155,10 @@ AVAIL (hint_pause, (!0))
 
 /* Argument types.  */
 #define RISCV_ATYPE_VOID void_type_node
+#define RISCV_ATYPE_UQI unsigned_intQI_type_node
+#define RISCV_ATYPE_UHI unsigned_intHI_type_node
 #define RISCV_ATYPE_USI unsigned_intSI_type_node
-#define RISCV_ATYPE_QI intQI_type_node
-#define RISCV_ATYPE_HI intHI_type_node
-#define RISCV_ATYPE_SI intSI_type_node
-#define RISCV_ATYPE_DI intDI_type_node
+#define RISCV_ATYPE_UDI unsigned_intDI_type_node
 #define RISCV_ATYPE_VOID_PTR ptr_type_node
 
 /* RISCV_FTYPE_ATYPESN takes N RISCV_FTYPES-like type codes and lists
diff --git a/gcc/config/riscv/riscv-cmo.def b/gcc/config/riscv/riscv-cmo.def
index b92044dc6ff9..ff713b78e19e 100644
--- a/gcc/config/riscv/riscv-cmo.def
+++ b/gcc/config/riscv/riscv-cmo.def
@@ -13,15 +13,15 @@ RISCV_BUILTIN (zero_si, "zicboz_cbo_zero", 
RISCV_BUILTIN_DIRECT_NO_TARGET, RISCV
 RISCV_BUILTIN (zero_di, "zicboz_cbo_zero", RISCV_BUILTIN_DIRECT_NO_TARGET, 
RISCV_VOID_FTYPE_VOID_PTR, zero64),
 
 // zicbop
-RISCV_BUILTIN (prefetchi_si, "zicbop_cbo_prefetchi", RISCV_BUILTIN_DIRECT, 
RISCV_SI_FTYPE_SI, prefetchi32),
-RISCV_BUILTIN (prefetchi_di, "zicbop_cbo_prefetchi", RISCV_BUILTIN_DIRECT, 
RISCV_DI_FTYPE_DI, prefetchi64),
+RISCV_BUILTIN (prefetchi_si, "zicbop_cbo_prefetchi", 

[PATCH 2/2] RISC-V: Make SHA-256, SM3 and SM4 builtins operate on uint32_t

2023-09-11 Thread Tsukasa OI via Gcc-patches
From: Tsukasa OI 

This is in parity with the LLVM commit a64b3e92c7cb ("[RISCV] Re-define
sha256, Zksed, and Zksh intrinsics to use i32 types.").

SHA-256, SM3 and SM4 instructions operate on 32-bit integers and upper
32-bits have no effects on RV64 (the output is sign-extended from the
original 32-bit value).  In that sense, making those intrinsics only
operate on uint32_t is much more natural than XLEN-bits wide integers.

This commit reforms instructions and expansions based on 32-bit
instruction handling on RV64 (such as ADDW).

Before:
   riscv__si: For RV32, fully operate on uint32_t
   riscv__di: For RV64, fully operate on uint64_t
After:
  *riscv__si: For RV32, fully operate on uint32_t
   riscv__di_extended:
  For RV64.  Input is uint32_t and output is int64_t,
  sign-extended from the int32_t result
  (represents a part of  behavior).
   riscv__si: Common (fully operate on uint32_t).
  On RV32, "expands" to *riscv__si.
  On RV64, initially expands to riscv__di_extended *and*
  extracts lower 32-bits from the int64_t result.

It also refines definitions of SHA-256, SM3 and SM4 intrinsics.

gcc/ChangeLog:

* config/riscv/crypto.md (riscv_sha256sig0_,
riscv_sha256sig1_, riscv_sha256sum0_,
riscv_sha256sum1_, riscv_sm3p0_, riscv_sm3p1_,
riscv_sm4ed_, riscv_sm4ks_): Remove and replace with
new insn/expansions.
(SHA256_OP, SM3_OP, SM4_OP): New iterators.
(sha256_op, sm3_op, sm4_op): New attributes for iteration.
(*riscv__si): New raw instruction for RV32.
(*riscv__si): Ditto.
(*riscv__si): Ditto.
(riscv__di_extended): New base instruction for RV64.
(riscv__di_extended): Ditto.
(riscv__di_extended): Ditto.
(riscv__si): New common instruction expansion.
(riscv__si): Ditto.
(riscv__si): Ditto.
* config/riscv/riscv-builtins.cc: Add availability "crypto_zknh",
"crypto_zksh" and "crypto_zksed".  Remove availability
"crypto_zksh{32,64}" and "crypto_zksed{32,64}".
* config/riscv/riscv-ftypes.def: Remove unused function type.
* config/riscv/riscv-scalar-crypto.def: Make SHA-256, SM3 and SM4
intrinsics to operate on uint32_t.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/zknh-sha256.c: Moved to...
* gcc.target/riscv/zknh-sha256-64.c: ...here.  Test RV64.
* gcc.target/riscv/zknh-sha256-32.c: New test for RV32.
* gcc.target/riscv/zksh64.c: Change the type.
* gcc.target/riscv/zksed64.c: Ditto.
---
 gcc/config/riscv/crypto.md| 161 --
 gcc/config/riscv/riscv-builtins.cc|   7 +-
 gcc/config/riscv/riscv-ftypes.def |   1 -
 gcc/config/riscv/riscv-scalar-crypto.def  |  24 +--
 .../gcc.target/riscv/zknh-sha256-32.c |  10 ++
 .../riscv/{zknh-sha256.c => zknh-sha256-64.c} |   8 +-
 gcc/testsuite/gcc.target/riscv/zksed64.c  |   4 +-
 gcc/testsuite/gcc.target/riscv/zksh64.c   |   4 +-
 8 files changed, 139 insertions(+), 80 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/zknh-sha256-32.c
 rename gcc/testsuite/gcc.target/riscv/{zknh-sha256.c => zknh-sha256-64.c} (78%)

diff --git a/gcc/config/riscv/crypto.md b/gcc/config/riscv/crypto.md
index e4b7f0190dfe..03a1d03397d9 100644
--- a/gcc/config/riscv/crypto.md
+++ b/gcc/config/riscv/crypto.md
@@ -250,36 +250,47 @@
 
 ;; ZKNH - SHA256
 
-(define_insn "riscv_sha256sig0_"
-  [(set (match_operand:X 0 "register_operand" "=r")
-(unspec:X [(match_operand:X 1 "register_operand" "r")]
-  UNSPEC_SHA_256_SIG0))]
-  "TARGET_ZKNH"
-  "sha256sig0\t%0,%1"
-  [(set_attr "type" "crypto")])
-
-(define_insn "riscv_sha256sig1_"
-  [(set (match_operand:X 0 "register_operand" "=r")
-(unspec:X [(match_operand:X 1 "register_operand" "r")]
-  UNSPEC_SHA_256_SIG1))]
-  "TARGET_ZKNH"
-  "sha256sig1\t%0,%1"
+(define_int_iterator SHA256_OP [
+  UNSPEC_SHA_256_SIG0 UNSPEC_SHA_256_SIG1
+  UNSPEC_SHA_256_SUM0 UNSPEC_SHA_256_SUM1])
+(define_int_attr sha256_op [
+  (UNSPEC_SHA_256_SIG0 "sha256sig0") (UNSPEC_SHA_256_SIG1 "sha256sig1")
+  (UNSPEC_SHA_256_SUM0 "sha256sum0") (UNSPEC_SHA_256_SUM1 "sha256sum1")])
+
+(define_insn "*riscv__si"
+  [(set (match_operand:SI 0 "register_operand" "=r")
+(unspec:SI [(match_operand:SI 1 "register_operand" "r")]
+   SHA256_OP))]
+  "TARGET_ZKNH && !TARGET_64BIT"
+  "\t%0,%1"
   [(set_attr "type" "crypto")])
 
-(define_insn "riscv_sha256sum0_"
-  [(set (match_operand:X 0 "register_operand" "=r")
-(unspec:X [(match_operand:X 1 "register_operand" "r")]
-  UNSPEC_SHA_256_SUM0))]
-  "TARGET_ZKNH"
-  "sha256sum0\t%0,%1"
+(define_insn "riscv__di_extended"
+  [(set (match_operand:DI 0 "register_operand" "=r")
+(sign_extend:DI
+ (unspec:SI [(match_operand:SI 1 

[PATCH 0/2] RISC-V: Change RISC-V bit manipulation / scalar crypto builtin types

2023-09-11 Thread Tsukasa OI via Gcc-patches
Hello,

My research suggests my previous RFC patchs will not break any real-world
programs (as far as I could find) and I will submit this patch set
(previously, two RFC patch sets) for upstream contribution.

RFC PATCH 1 (combined to this):

RFC PATCH 2 (combined to this):


This patch set consists of two commits:

1.  Changing signed types to unsigned types on bit manipulation and scalar
crypto intrinsics.
2.  Changing from uint64_t (changed from int64_t on the PATCH 1/2) to
uint32_t on SHA-256, SM3 and SM4 intrinsics (all operate on 32-bit
integers and upper 32-bits are not affected).

This is in sync with following commits in LLVM (will be a part of 17):

1. 599421ae36c3
  ("[RISCV] Use unsigned instead of signed types for Zk* and Zb* builtins.")
2. a64b3e92c7cb
  ("[RISCV] Re-define sha256, Zksed, and Zksh intrinsics to use i32 types.")

Many RISC-V builtins operate in signed integer types but in many cases,
they are better to be unsigned.

It follows with a bit fixed cover letter from the previous RFC PATCH sets.

Sincerely,
Tsukasa



Many RISC-V builtins operate in signed integer types but in many cases,
they are better to be unsigned.

There are a few reasons to do that in PATCH 1/2:

1.  Being more natural
For bit manipulation operations, the direct input and the manipulated
result should have an unsigned type.
e.g. __builtin_bswap16
Both input and output should be (and are) unsigned.
e.g. __builtin_popcount
The input should be (and is) unsigned.
The output is a bit count and is in int (signed integer).
2.  In parity with LLVM (likely in version 17)
LLVM made similar changes to this patch set in the commit 599421ae36c3
("[RISCV] Use unsigned instead of signed types for Zk* and Zb*
builtins.") by Craig Topper.
Note that shift amount / round number argument types are changed to
unsigned in this LLVM commit, I did the same.
3.  Minimum compatibility breakage
This change rarely causes warnings even if both -Wall and -Wextra are
specified.

This is not completely compatible.  For instance, we will notice when
operating with for instance C++'s "auto" / "decltype" or overload
resolution.  But I consider this change in PATCH 1/2 is acceptable.



There are also operations that only operate in 32-bit integers but require
XLEN-bit wide integers.  Intrinsics for SHA-256, SM3 and SM4 applies.

PATCH 2/2 changes this in parity with the LLVM commit a64b3e92c7cb ("[RISCV]
Re-define sha256, Zksed, and Zksh intrinsics to use i32 types.") by Craig
Topper and makes those intrinsics accept/return uint32_t even on RV64.

This instruction/expansion changes are based on the handling of 32-bit
instructions on RV64 (such as ADDW).

Before:
   riscv__si: For RV32, fully operate on uint32_t
   riscv__di: For RV64, fully operate on uint64_t
After:
  *riscv__si: For RV32, fully operate on uint32_t
   riscv__di_extended:
  For RV64. Input is uint32_t and output is int64_t,
  sign-extended from the int32_t result
  (represents a part of  behavior).
   riscv__si: Common (fully operate on uint32_t).
  On RV32, "expands" to *riscv__si.
  On RV64, initially expands to riscv__di_extended and
  extracts lower 32-bits from the int64_t result.

I think this (not completely compatible) change is still acceptable.




Tsukasa OI (2):
  RISC-V: Make bit manipulation value / round number and shift amount
types for builtins unsigned
  RISC-V: Make SHA-256, SM3 and SM4 builtins operate on uint32_t

 gcc/config/riscv/crypto.md| 161 --
 gcc/config/riscv/riscv-builtins.cc|  14 +-
 gcc/config/riscv/riscv-cmo.def|  16 +-
 gcc/config/riscv/riscv-ftypes.def |  23 ++-
 gcc/config/riscv/riscv-scalar-crypto.def  |  96 +--
 gcc/testsuite/gcc.target/riscv/zbc32.c|   6 +-
 gcc/testsuite/gcc.target/riscv/zbc64.c|   6 +-
 gcc/testsuite/gcc.target/riscv/zbkb32.c   |  10 +-
 gcc/testsuite/gcc.target/riscv/zbkb64.c   |   8 +-
 gcc/testsuite/gcc.target/riscv/zbkc32.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zbkc64.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zbkx32.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zbkx64.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zknd32.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zknd64.c   |  10 +-
 gcc/testsuite/gcc.target/riscv/zkne32.c   |   4 +-
 gcc/testsuite/gcc.target/riscv/zkne64.c   |   8 +-
 .../gcc.target/riscv/zknh-sha256-32.c |  10 ++
 .../riscv/{zknh-sha256.c => zknh-sha256-64.c} |   8 +-
 .../gcc.target/riscv/zknh-sha512-32.c |  12 +-
 .../gcc.target/riscv/zknh-sha512-64.c |   8 +-
 gcc/testsuite/gcc.target/riscv/zksed32.c  |  

RE: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV intrinsic

2023-09-11 Thread Li, Pan2 via Gcc-patches
We cannot leverage this instance for correctness.
The rfun of below code is the overloaded builtin is for the overloaded 
function, which is registered as void xxx(void) as aarch64 did to avoid the 
conflict.

Let’s take vmv_v_i32m1 as example in rfun table.

Index 0: void vmv_v(void) overloaded
Index 1: i32m1 vmv_v_v_i32m1_i32m1 (i32m1, size_t) non-overloaded
Index 2: placeholder.

When we enter the hook(aka the code list below), the rfun we have is the index 
0 rfun instead of index 1.
Then we need the arglist to lookup the rfun of index 1 for the underlying call, 
as well as build the instance for the index 1 rfun.

Aarch64 has the same rfun table as above, they leverage a loop to parse the 
arglist with machine mode matching in a predefined type suffix(which is not 
available in RISC-V).

I think they almost try to resolve the same problem but different implement 
details.

Pan

From: 钟居哲 
Sent: Tuesday, September 12, 2023 7:20 AM
To: Li, Pan2 
Cc: kito.cheng ; gcc-patches ; 
Wang, Yanzhang 
Subject: Re: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for 
RVV intrinsic

I don't understand.


+tree

+resolve_overloaded_builtin (location_t loc, unsigned int code,

+  vec *arglist)

+{

+  if (code >= vec_safe_length (registered_functions))

+return NULL_TREE;

+

+  const registered_function *rfun = (*registered_functions)[code];

+

+  if (!rfun || !rfun->overloaded_p)

+return NULL_TREE;

+

+  return function_resolver (loc, rfun->instance, rfun->decl, *arglist)

+.resolve ();

+}
You already have rfun->instance. Just use this instance should be good enough.

juzhe.zh...@rivai.ai

From: Li, Pan2
Date: 2023-09-11 23:24
To: 钟居哲
CC: kito.cheng; 
gcc-patches; Wang, 
Yanzhang
Subject: RE: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for 
RVV intrinsic
For function instance with void or void arguments, it is easy as you mentioned 
as below.

For generate API (to get the right hash), you need to build the rvv_type_info, 
predications_type_index and rvv_op_info
from the arglist (aka vec) from hook.

Then we need to construct above parameters from one tree argument. Sorry I not 
sure if I understand correctly but I failed
to locate somewhere has similar usage.

Could you please help to insight me some best practice about the transformation 
from tree to above types?

Pan

From: 钟居哲 mailto:juzhe.zh...@rivai.ai>>
Sent: Monday, September 11, 2023 9:07 PM
To: Li, Pan2 mailto:pan2...@intel.com>>
Cc: kito.cheng mailto:kito.ch...@gmail.com>>; gcc-patches 
mailto:gcc-patches@gcc.gnu.org>>; Wang, Yanzhang 
mailto:yanzhang.w...@intel.com>>
Subject: Re: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for 
RVV intrinsic

function_instance
get_read_vl_instance (void)
{
  return function_instance ("read_vl", bases::read_vl, shapes::read_vl,
  none_ops[0], PRED_TYPE_none, _none_void_ops);
}

tree
get_read_vl_decl (void)
{
  function_instance instance = get_read_vl_instance ();
  hashval_t hash = instance.hash ();
  registered_function *rfn = function_table->find_with_hash (instance, hash);
  gcc_assert (rfn);
  return rfn->decl;
}

You should reference it. I don't see why it's hard for use to construct 
instance first, then use that instance hash to get the decl.

juzhe.zh...@rivai.ai

From: Li, Pan2
Date: 2023-09-11 20:26
To: juzhe.zhong
CC: kito.cheng; 
gcc-patches; Wang, 
Yanzhang
Subject: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV 
intrinsic
> No. You must construct instance. 'strcmp' is very ugly.

Strcmp here is defensive code here for early exit if not found (can be removed 
for correctness), which is not required to find the right declaration.

Pan

From: juzhe.zhong mailto:juzhe.zh...@rivai.ai>>
Sent: Monday, September 11, 2023 8:20 PM
To: Li, Pan2 mailto:pan2...@intel.com>>
Cc: kito.cheng mailto:kito.ch...@gmail.com>>; gcc-patches 
mailto:gcc-patches@gcc.gnu.org>>; Wang, Yanzhang 
mailto:yanzhang.w...@intel.com>>
Subject: Re: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV 
intrinsic

No. You must construct instance. 'strcmp' is very ugly.
 Replied Message 
From
Li, Pan2
Date
09/11/2023 20:09
To
juzhe.zh...@rivai.ai,
kito.cheng
Cc
gcc-patches,
Wang, Yanzhang
Subject
RE: Re: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV 
intrinsic
> -if (overloaded_p && instance.pred == PRED_TYPE_m)
> +if (overloaded_p)


[PATCH 3/3] libstdc++: Fix std::not_fn perfect forwarding [PR111327]

2023-09-11 Thread Patrick Palka via Gcc-patches
The previous patch fixed perfect forwarding for std::bind_front.
This patch fixes the same issue for std::not_fn.

Tested on x86_64-pc-linux-gnu, does this look OK for trunk and
perhaps 13?

PR libstdc++/111327

libstdc++-v3/ChangeLog:

* include/std/functional (_GLIBCXX_NOT_FN_CALL_OP): Also define
a deleted fallback operator() overload.  Constrain both the
main and deleted overloads accordingly.
* testsuite/20_util/function_objects/not_fn/111327.cc: New test.
---
 libstdc++-v3/include/std/functional   | 10 +--
 .../20_util/function_objects/not_fn/111327.cc | 29 +++
 2 files changed, 37 insertions(+), 2 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/20_util/function_objects/not_fn/111327.cc

diff --git a/libstdc++-v3/include/std/functional 
b/libstdc++-v3/include/std/functional
index c50b9e4d365..9551e38dfdb 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -1061,7 +1061,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // forwarding _M_fn and the function arguments with the same qualifiers,
   // and deducing the return type and exception-specification.
 #define _GLIBCXX_NOT_FN_CALL_OP( _QUALS )  \
-  template  \
+  template::value>> \
_GLIBCXX20_CONSTEXPR\
decltype(_S_not<__inv_res_t<_Fn _QUALS, _Args...>>())   \
operator()(_Args&&... __args) _QUALS\
@@ -1070,7 +1071,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{   \
  return !std::__invoke(std::forward< _Fn _QUALS >(_M_fn),  \
std::forward<_Args>(__args)...);\
-   }
+   }   \
+   \
+  template::value>> \
+   void operator()(_Args&&... __args) _QUALS = delete;
+
   _GLIBCXX_NOT_FN_CALL_OP( & )
   _GLIBCXX_NOT_FN_CALL_OP( const & )
   _GLIBCXX_NOT_FN_CALL_OP( && )
diff --git a/libstdc++-v3/testsuite/20_util/function_objects/not_fn/111327.cc 
b/libstdc++-v3/testsuite/20_util/function_objects/not_fn/111327.cc
new file mode 100644
index 000..93e00ee8057
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/function_objects/not_fn/111327.cc
@@ -0,0 +1,29 @@
+// PR libstdc++/111327 - std::bind_front (and std::not_fn) doesn't perfectly
+// forward according to value category of the call wrapper object
+// { dg-do compile { target c++17 } }
+
+#include 
+#include 
+
+struct F {
+  void operator()(...) & = delete;
+  bool operator()(...) const &;
+};
+
+struct G {
+  void operator()(...) && = delete;
+  bool operator()(...) const &&;
+};
+
+int main() {
+  auto f = std::not_fn(F{});
+  f(); // { dg-error "deleted" }
+  std::move(f)();
+  std::as_const(f)();
+  std::move(std::as_const(f))();
+
+  auto g = std::not_fn(G{});
+  g(); // { dg-error "deleted" }
+  std::move(g)(); // { dg-error "deleted" }
+  std::move(std::as_const(g))();
+}
-- 
2.42.0.158.g94e83dcf5b



[PATCH 2/3] libstdc++: Fix std::bind_front perfect forwarding [PR111327]

2023-09-11 Thread Patrick Palka via Gcc-patches
In order to properly implement a perfect forwarding call wrapper
(before 'deducing this' at least) we need a total of 8 operator()
overloads, 4 main ones and 4 deleted ones for each const/ref qual pair,
as described in section 5.5 of P0847R6.  Otherwise the wrapper may
not perfectly forward according to the value category and constness
of the wrapped object.  This patch fixes this bug in std::bind_front.

PR libstdc++/111327

libstdc++-v3/ChangeLog:

* include/std/functional (_Bind_front::operator()): Add deleted
fallback overloads for each const/ref qualifier pair.  Give the
main overloads dummy constraints to make them more specialized
than the deleted overloads.
* testsuite/20_util/function_objects/bind_front/111327.cc: New test.
---
 libstdc++-v3/include/std/functional   | 16 
 .../function_objects/bind_front/111327.cc | 41 +++
 2 files changed, 57 insertions(+)
 create mode 100644 
libstdc++-v3/testsuite/20_util/function_objects/bind_front/111327.cc

diff --git a/libstdc++-v3/include/std/functional 
b/libstdc++-v3/include/std/functional
index 7d1b890bb4e..c50b9e4d365 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -938,6 +938,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   ~_Bind_front() = default;
 
   template
+   requires true
constexpr
invoke_result_t<_Fd&, _BoundArgs&..., _CallArgs...>
operator()(_CallArgs&&... __call_args) &
@@ -948,6 +949,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
 
   template
+   requires true
constexpr
invoke_result_t
operator()(_CallArgs&&... __call_args) const &
@@ -959,6 +961,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
 
   template
+   requires true
constexpr
invoke_result_t<_Fd, _BoundArgs..., _CallArgs...>
operator()(_CallArgs&&... __call_args) &&
@@ -969,6 +972,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
 
   template
+   requires true
constexpr
invoke_result_t
operator()(_CallArgs&&... __call_args) const &&
@@ -979,6 +983,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  std::forward<_CallArgs>(__call_args)...);
}
 
+  template
+   void operator()(_CallArgs&&...) & = delete;
+
+  template
+   void operator()(_CallArgs&&...) const & = delete;
+
+  template
+   void operator()(_CallArgs&&...) && = delete;
+
+  template
+   void operator()(_CallArgs&&...) const && = delete;
+
 private:
   using _BoundIndices = index_sequence_for<_BoundArgs...>;
 
diff --git 
a/libstdc++-v3/testsuite/20_util/function_objects/bind_front/111327.cc 
b/libstdc++-v3/testsuite/20_util/function_objects/bind_front/111327.cc
new file mode 100644
index 000..6eb51994476
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/function_objects/bind_front/111327.cc
@@ -0,0 +1,41 @@
+// PR libstdc++/111327 - std::bind_front doesn't perfectly forward according
+// to value category of the call wrapper object
+// { dg-options "-std=gnu++20" }
+// { dg-do compile { target c++20 } }
+
+#include 
+#include 
+
+struct F {
+  void operator()(...) & = delete;
+  void operator()(...) const &;
+};
+
+struct G {
+  void operator()(...) && = delete;
+  void operator()(...) const &&;
+};
+
+int main() {
+  auto f0 = std::bind_front(F{});
+  f0(); // { dg-error "deleted" }
+  std::move(f0)();
+  std::as_const(f0)();
+  std::move(std::as_const(f0))();
+
+  auto g0 = std::bind_front(G{});
+  g0(); // { dg-error "deleted" }
+  std::move(g0)(); // { dg-error "deleted" }
+  std::move(std::as_const(g0))();
+
+  auto f1 = std::bind_front(F{}, 42);
+  f1(); // { dg-error "deleted" }
+  std::move(f1)();
+  std::as_const(f1)();
+  std::move(std::as_const(f1))();
+
+  auto g1 = std::bind_front(G{}, 42);
+  g1(); // { dg-error "deleted" }
+  std::move(g1)(); // { dg-error "deleted" }
+  std::move(std::as_const(g1))();
+}
-- 
2.42.0.158.g94e83dcf5b



[PATCH 1/3] libstdc++: Remove std::bind_front specialization for no bound args

2023-09-11 Thread Patrick Palka via Gcc-patches
This specialization for the case of no bound args, added by
r13-4214-gcbd05ca5ab1231, seems to be mostly obsoleted by
r13-5033-ge2eab3c4edb6aa which added [[no_unique_address]] to the
main template's data members.  And the compile time advantage of
avoiding an empty tuple and index_sequence seems minimal.  Removing this
specialization also means we don't have to fix the PR111327 bug in
another place.

PR libstdc++/111327

libstdc++-v3/ChangeLog:

* include/std/functional (_Bind_front0): Remove.
(_Bind_front_t): Adjust.
---
 libstdc++-v3/include/std/functional | 63 +
 1 file changed, 1 insertion(+), 62 deletions(-)

diff --git a/libstdc++-v3/include/std/functional 
b/libstdc++-v3/include/std/functional
index 60d4d1f3dd2..7d1b890bb4e 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -996,69 +996,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   [[no_unique_address]] std::tuple<_BoundArgs...> _M_bound_args;
 };
 
-  // Avoid the overhead of an empty tuple<> if there are no bound args.
-  template
-struct _Bind_front0
-{
-  static_assert(is_move_constructible_v<_Fd>);
-
-  // First parameter is to ensure this constructor is never used
-  // instead of the copy/move constructor.
-  template
-   explicit constexpr
-   _Bind_front0(int, _Fn&& __fn)
-   noexcept(is_nothrow_constructible_v<_Fd, _Fn>)
-   : _M_fd(std::forward<_Fn>(__fn))
-   { }
-
-  _Bind_front0(const _Bind_front0&) = default;
-  _Bind_front0(_Bind_front0&&) = default;
-  _Bind_front0& operator=(const _Bind_front0&) = default;
-  _Bind_front0& operator=(_Bind_front0&&) = default;
-  ~_Bind_front0() = default;
-
-  template
-   constexpr
-   invoke_result_t<_Fd&, _CallArgs...>
-   operator()(_CallArgs&&... __call_args) &
-   noexcept(is_nothrow_invocable_v<_Fd&, _CallArgs...>)
-   { return std::invoke(_M_fd, std::forward<_CallArgs>(__call_args)...); }
-
-  template
-   constexpr
-   invoke_result_t
-   operator()(_CallArgs&&... __call_args) const &
-   noexcept(is_nothrow_invocable_v)
-   { return std::invoke(_M_fd, std::forward<_CallArgs>(__call_args)...); }
-
-  template
-   constexpr
-   invoke_result_t<_Fd, _CallArgs...>
-   operator()(_CallArgs&&... __call_args) &&
-   noexcept(is_nothrow_invocable_v<_Fd, _CallArgs...>)
-   {
- return std::invoke(std::move(_M_fd),
-std::forward<_CallArgs>(__call_args)...);
-   }
-
-  template
-   constexpr
-   invoke_result_t
-   operator()(_CallArgs&&... __call_args) const &&
-   noexcept(is_nothrow_invocable_v)
-   {
- return std::invoke(std::move(_M_fd),
-std::forward<_CallArgs>(__call_args)...);
-   }
-
-private:
-  [[no_unique_address]] _Fd _M_fd;
-};
-
   template
-using _Bind_front_t
-  = __conditional_t>,
-   _Bind_front, decay_t<_Args>...>>;
+using _Bind_front_t = _Bind_front, decay_t<_Args>...>;
 
   /** Create call wrapper by partial application of arguments to function.
*
-- 
2.42.0.158.g94e83dcf5b



Re: Re: [PATCH 2/2] [RISC-V] Enalble zcmp for -Os

2023-09-11 Thread Fei Gao
On 2023-09-06 16:06  Kito Cheng  wrote:
>
>On Wed, Sep 6, 2023 at 9:47 AM Fei Gao  wrote:
>>
>> On 2023-09-05 20:02  Kito Cheng  wrote:
>> >
>> >> @@ -5569,7 +5571,9 @@ riscv_avoid_multi_push (const struct 
>> >> riscv_frame_info *frame)
>> >>  {
>> >>    if (!TARGET_ZCMP || crtl->calls_eh_return || frame_pointer_needed
>> >>    || cfun->machine->interrupt_handler_p || 
>> >>cfun->machine->varargs_size != 0
>> >> -  || crtl->args.pretend_args_size != 0 || flag_shrink_wrap_separate
>> >> +  || crtl->args.pretend_args_size != 0
>> >> +  || (use_shrink_wrapping_separate ()
>> >> + && !riscv_avoid_shrink_wrapping_separate ())
>> >
>> >I think we should also check "!optimize_function_for_size_p (cfun)"
>> >here, otherwise that does not really match what we claim in the commit
>> >message.
>> >
>> A similar check optimize_function_for_speed_p is included in
>> use_shrink_wrapping_separate of [1/2] allow targets to check
>> shrink-wrap-separate enabled or not.
>>
>> >e.g. it still will enable with -O2 -fno-shrink-wrap-separate
>> It's intentional to enable zcmp with -O2 -fno-shrink-wrap-separate.
>> Maybe I should have given a better commit message saying
>> "enable muti push and pop for Zcmp extension when
>> shrink-wrap-separate is inactive".
>>
>> Would you like a new patch from me or agree with my
>> explanation and modify commit message in your side?
>
>Could you send a new patch with updated commit message. 
hi Kito

New patch with updated commit message:
https://patchwork.sourceware.org/project/gcc/list/?series=24300

BR, 
Fei
>
>
>>
>> BR
>> Fei
>> >
>> >>    || (frame->mask & ~MULTI_PUSH_GPR_MASK))
>> >>  return true;
>> >>
>>

[Linaro-TCWG-CI] gcc patch #75674: FAIL: 88 regressions

2023-09-11 Thread ci_notify--- via Gcc-patches
Dear contributor, our automatic CI has detected problems related to your 
patch(es).  Please find some details below.  If you have any questions, please 
follow up on linaro-toolch...@lists.linaro.org mailing list, Libera's 
#linaro-tcwg channel, or ping your favourite Linaro toolchain developer on the 
usual project channel.

In CI config tcwg_gcc_check/master-arm after:

  | gcc patch https://patchwork.sourceware.org/patch/75674
  | Author: benjamin priour 
  | Date:   Mon Sep 11 19:44:34 2023 +0200
  | 
  | analyzer: Move gcc.dg/analyzer tests to c-c++-common (3) [PR96395]
  | 
  | Hi,
  | 
  | Patch below is mostly done, just have to check the formatting.
  | Althought, I'd like your feedback on how to manage named_constants
  | from enum in C++.
  | ... 21 lines of the commit log omitted.
  | ... applied on top of baseline commit:
  | 8fdf712a384 MATCH: [PR111348] add missing :c to cmp in the `(a CMP b) ? 
minmax : minmax` pattern

FAIL: 88 regressions

regressions.sum:
=== g++ tests ===

Running g++:g++.dg/analyzer/analyzer.exp ...
FAIL: c-c++-common/analyzer/call-summaries-2.c -std=c++14 (test for excess 
errors)
FAIL: c-c++-common/analyzer/call-summaries-2.c -std=c++17 (test for excess 
errors)
FAIL: c-c++-common/analyzer/call-summaries-2.c -std=c++20 (test for excess 
errors)
FAIL: c-c++-common/analyzer/call-summaries-2.c -std=c++98 (test for excess 
errors)
FAIL: c-c++-common/analyzer/memcpy-1.c -std=c++14  (test for warnings, line 25)
FAIL: c-c++-common/analyzer/memcpy-1.c -std=c++14  (test for warnings, line 48)
FAIL: c-c++-common/analyzer/memcpy-1.c -std=c++14 (test for excess errors)
... and 83 more entries

You can find the failure logs in *.log.1.xz files in
 - 
https://ci.linaro.org/job/tcwg_gcc_check--master-arm-precommit/3475/artifact/artifacts/artifacts.precommit/00-sumfiles/
 .
The full lists of regressions and progressions are in
 - 
https://ci.linaro.org/job/tcwg_gcc_check--master-arm-precommit/3475/artifact/artifacts/artifacts.precommit/notify/
 .
The list of [ignored] baseline and flaky failures are in
 - 
https://ci.linaro.org/job/tcwg_gcc_check--master-arm-precommit/3475/artifact/artifacts/artifacts.precommit/sumfiles/xfails.xfail
 .



-8<--8<--8<--
The information below can be used to reproduce a debug environment:

Current build   : 
https://ci.linaro.org/job/tcwg_gcc_check--master-arm-precommit/3475/artifact/artifacts
Reference build : 
https://ci.linaro.org/job/tcwg_gcc_check--master-arm-build/998/artifact/artifacts


Re: RISC-V: Replace not + bitwise_imm with li + bitwise_not

2023-09-11 Thread Jeff Law via Gcc-patches




On 9/11/23 13:16, Andrew Waterman via Gcc-patches wrote:

Note this is a size-speed tradeoff, as the Zcb extension has a
16-bit-wide C.NOT instruction.  Might want to suppress this
optimization when Zcb is present and the function is being optimize > for size.

Yea, let's gate this on !optimize_function_for_size_p (cfun).

While we don't have Zcb support yet, hopefully we will soon.

jeff


Re: Re: [PATCH V3] RISC-V: Support Dynamic LMUL Cost model

2023-09-11 Thread juzhe.zh...@rivai.ai
>> What about one test with global live ranges?  Not a necessity IMHO we can 
>> still
>> add it later.
We already have.


juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2023-09-12 04:31
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; jeffreyalaw
Subject: Re: [PATCH V3] RISC-V: Support Dynamic LMUL Cost model
Hi Juzhe,
 
glad that we can use the dominator info directly.  Could we move the
calculation of the info to the beginning (if it's not available)?  That
makes it clearer that it's a prerequisite.  Function comments look
good now.
 
Some general remarks kind of similar to v1:
 
- I would prefer a hash_map or similar to hold the end point for a range
   instead of looking through potentially all ranges in contrived cases.
 
- As long as we're just looking for the maximum number of live registers,
   we can use a sliding-window approach:  create a structure with all
   start and end points, sort it, and increase the current pressure
   if we start a new range or decrease.  That's O(n log n).
 
> +  const ssa_use_operand_t *const head = &(SSA_NAME_IMM_USE_NODE (t));
> +  const ssa_use_operand_t *ptr;
> +
> +  for (ptr = head->next; ptr != head; ptr = ptr->next)
> + {
 
Why does FOR_EACH_IMM_USE not work here?
 
> +   unsigned int max_point
> + = (*program_points_per_bb.get (e->src)).length () - 1;
> +   for (k = 0; k < (*live_ranges).length (); k++)
> + {
> +   if ((*live_ranges)[i].var == def)
 
Would also be nice not having to search through all ranges but just index/hash
it via var (or similar).
 
What about one test with global live ranges?  Not a necessity IMHO we can still
add it later.
 
Regards
Robin
 
 


Re: [PATCH] RISC-V: Finish Typing Un-Typed Instructions and Turn on Assert

2023-09-11 Thread Jeff Law via Gcc-patches




On 9/11/23 16:52, Edwin Lu wrote:

Updates autovec instruction that was added after last patch and turns on the
assert statement to ensure all new instructions have a type.

* config/riscv/autovec-opt.md: Update type
* config/riscv/riscv.cc (riscv_sched_variable_issue): Remove assert
"Remove assert" -> "Enable assert."  We're removing the #if 0 guard, not 
the assert itself :-)


OK with the ChangeLog fixed.
jeff


Re: [PATCH v5] Implement new RTL optimizations pass: fold-mem-offsets.

2023-09-11 Thread Jeff Law via Gcc-patches




On 9/9/23 02:46, Manolis Tsamis wrote:

This is a new RTL pass that tries to optimize memory offset calculations
by moving them from add immediate instructions to the memory loads/stores.
For example it can transform this:

   addi t4,sp,16
   add  t2,a6,t4
   shl  t3,t2,1
   ld   a2,0(t3)
   addi a2,1
   sd   a2,8(t2)

into the following (one instruction less):

   add  t2,a6,sp
   shl  t3,t2,1
   ld   a2,32(t3)
   addi a2,1
   sd   a2,24(t2)

Although there are places where this is done already, this pass is more
powerful and can handle the more difficult cases that are currently not
optimized. Also, it runs late enough and can optimize away unnecessary
stack pointer calculations.

gcc/ChangeLog:

* Makefile.in: Add fold-mem-offsets.o.
* passes.def: Schedule a new pass.
* tree-pass.h (make_pass_fold_mem_offsets): Declare.
* common.opt: New options.
* doc/invoke.texi: Document new option.
* fold-mem-offsets.cc: New file.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/fold-mem-offsets-1.c: New test.
* gcc.target/riscv/fold-mem-offsets-2.c: New test.
* gcc.target/riscv/fold-mem-offsets-3.c: New test.

Signed-off-by: Manolis Tsamis 
---

Changes in v5:
 - Introduce new helper function fold_offsets_1.
 - Fix bug because constants could be partially propagated
   through instructions that weren't understood.
 - Introduce helper class fold_mem_info that stores f-m-o
   info for an instruction.
 - Calculate fold_offsets only once with do_fold_info_calculation.
 - Fix correctness issue by introducing compute_validity_closure.
 - Propagate in more cases for PLUS/MINUS with constant.

Changes in v4:
 - Add DF_EQ_NOTES flag to avoid incorrect state in notes.
 - Remove fold_mem_offsets_driver and enum fold_mem_phase.
 - Call recog when patching offsets in do_commit_offset.
 - Restore INSN_CODE after modifying insn in do_check_validity.

Changes in v3:
 - Added propagation for more codes:
   sub, neg, mul.
 - Added folding / elimination for sub and
   const int moves.
 - For the validity check of the generated addresses
   also test memory_address_addr_space_p.
 - Replaced GEN_INT with gen_int_mode.
 - Replaced some bitmap_head with auto_bitmap.
 - Refactor each phase into own function for readability.
 - Add dump details.
 - Replace rtx iteration with reg_mentioned_p.
 - Return early for codes that we can't propagate through.

Changes in v2:
 - Made the pass target-independant instead of RISCV specific.
 - Fixed a number of bugs.
 - Add code to handle more ADD patterns as found
   in other targets (x86, aarch64).
 - Improved naming and comments.
 - Fixed bitmap memory leak.





+
+/* Get the single reaching definition of an instruction inside a BB.
+   The definition is desired for REG used in INSN.
+   Return the definition insn or NULL if there's no definition with
+   the desired criteria.  */
+static rtx_insn*
+get_single_def_in_bb (rtx_insn *insn, rtx reg)
+{
+  df_ref use;
+  struct df_link *ref_chain, *ref_link;
+
+  FOR_EACH_INSN_USE (use, insn)
+{
+  if (GET_CODE (DF_REF_REG (use)) == SUBREG)
+   return NULL;
+  if (REGNO (DF_REF_REG (use)) == REGNO (reg))
+   break;
+}
+
+  if (!use)
+return NULL;
+
+  ref_chain = DF_REF_CHAIN (use);
So what if there's two uses of REG in INSN?  I don't think it's be 
common at all, but probably better safe and reject than sorry, right? Or 
is that case filtered out earlier?






+
+  rtx_insn* def = DF_REF_INSN (ref_chain->ref);

Formatting nit.  The '*' should be next to the variable, not the type.


+



+
+static HOST_WIDE_INT
+fold_offsets (rtx_insn* insn, rtx reg, bool analyze, bitmap foldable_insns);
+
+/*  Helper function for fold_offsets.
+
+If DO_RECURSION is false and ANALYZE is true this function returns true iff
+it understands the structure of INSN and knows how to propagate constants
+through it.  In this case OFFSET_OUT and FOLDABLE_INSNS are unused.
+
+If DO_RECURSION is true then it also calls fold_offsets for each recognised
+part of INSN with the appropriate arguments.
+
+If DO_RECURSION is true and ANALYZE is false then offset that would result
+from folding is computed and is returned through the pointer OFFSET_OUT.
+The instructions that can be folded are recorded in FOLDABLE_INSNS.
+*/
+static bool fold_offsets_1 (rtx_insn* insn, bool analyze, bool do_recursion,
+   HOST_WIDE_INT *offset_out, bitmap foldable_insns)
Nit.  Linkage and return type on separate line.  That makes the function 
name start at the beginning of a line.





+
+/* Test if INSN is a memory load / store that can have an offset folded to it.
+   Return true iff INSN is such an 

[PATCH 2/2] libstdc++: Optimize is_scoped_enum trait performance

2023-09-11 Thread Ken Matsui via Gcc-patches
This patch optimizes the performance of the is_scoped_enum trait
by dispatching to the new __is_scoped_enum built-in trait.

libstdc++-v3/ChangeLog:

* include/std/type_traits (is_scoped_enum): Use
__is_scoped_enum built-in trait.
(is_scoped_enum_v): Likewise.

Signed-off-by: Ken Matsui 
---
 libstdc++-v3/include/std/type_traits | 12 
 1 file changed, 12 insertions(+)

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index 677cd934b94..26ae491fa69 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -3585,6 +3585,12 @@ template
   /// True if the type is a scoped enumeration type.
   /// @since C++23
 
+# if _GLIBCXX_USE_BUILTIN_TRAIT(__is_scoped_enum)
+  template
+struct is_scoped_enum
+: bool_constant<__is_scoped_enum(_Tp)>
+{ };
+# else
   template
 struct is_scoped_enum
 : false_type
@@ -3596,11 +3602,17 @@ template
 struct is_scoped_enum<_Tp>
 : bool_constant
 { };
+# endif
 
   /// @ingroup variable_templates
   /// @since C++23
+# if _GLIBCXX_USE_BUILTIN_TRAIT(__is_scoped_enum)
+  template
+inline constexpr bool is_scoped_enum_v = __is_scoped_enum(_Tp);
+# else
   template
 inline constexpr bool is_scoped_enum_v = is_scoped_enum<_Tp>::value;
+# endif
 #endif
 
 #ifdef __cpp_lib_reference_from_temporary // C++ >= 23 && 
ref_{converts,constructs}_from_temp
-- 
2.42.0



[PATCH 1/2] c++: Implement __is_scoped_enum built-in trait

2023-09-11 Thread Ken Matsui via Gcc-patches
This patch implements built-in trait for
std::is_scoped_enum.

gcc/cp/ChangeLog:

* cp-trait.def (IS_SCOPED_ENUM): Define
__is_scoped_enum.
* constraint.cc (diagnose_trait_expr): Handle
CPTK_IS_SCOPED_ENUM.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/ext/has-builtin-1.C: Test existence of
is_scoped_enum.
* g++.dg/ext/is_scoped_enum.C: New test.

Signed-off-by: Ken Matsui 
---
 gcc/cp/constraint.cc  |  3 +
 gcc/cp/cp-trait.def   |  1 +
 gcc/cp/semantics.cc   |  4 ++
 gcc/testsuite/g++.dg/ext/has-builtin-1.C  |  3 +
 gcc/testsuite/g++.dg/ext/is_scoped_enum.C | 67 +++
 5 files changed, 78 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/ext/is_scoped_enum.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index c9e4e7043cd..ba387cb5eb5 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -3760,6 +3760,9 @@ diagnose_trait_expr (tree expr, tree args)
 case CPTK_IS_ASSIGNABLE:
   inform (loc, "  %qT is not assignable from %qT", t1, t2);
   break;
+case CPTK_IS_SCOPED_ENUM:
+  inform (loc, "  %qT is not a scoped enum", t1);
+  break;
 case CPTK_IS_TRIVIALLY_ASSIGNABLE:
   inform (loc, "  %qT is not trivially assignable from %qT", t1, t2);
   break;
diff --git a/gcc/cp/cp-trait.def b/gcc/cp/cp-trait.def
index 8b7fece0cc8..8caabe4c289 100644
--- a/gcc/cp/cp-trait.def
+++ b/gcc/cp/cp-trait.def
@@ -76,6 +76,7 @@ DEFTRAIT_EXPR (IS_POINTER_INTERCONVERTIBLE_BASE_OF, 
"__is_pointer_interconvertib
 DEFTRAIT_EXPR (IS_POD, "__is_pod", 1)
 DEFTRAIT_EXPR (IS_POLYMORPHIC, "__is_polymorphic", 1)
 DEFTRAIT_EXPR (IS_SAME, "__is_same", 2)
+DEFTRAIT_EXPR (IS_SCOPED_ENUM, "__is_scoped_enum", 1)
 DEFTRAIT_EXPR (IS_STD_LAYOUT, "__is_standard_layout", 1)
 DEFTRAIT_EXPR (IS_TRIVIAL, "__is_trivial", 1)
 DEFTRAIT_EXPR (IS_TRIVIALLY_ASSIGNABLE, "__is_trivially_assignable", 2)
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 0f7f4e87ae4..7e10d81fa34 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -12163,6 +12163,9 @@ trait_expr_value (cp_trait_kind kind, tree type1, tree 
type2)
 case CPTK_IS_SAME:
   return same_type_p (type1, type2);
 
+case CPTK_IS_SCOPED_ENUM:
+  return SCOPED_ENUM_P (type1);
+
 case CPTK_IS_STD_LAYOUT:
   return std_layout_type_p (type1);
 
@@ -12359,6 +12362,7 @@ finish_trait_expr (location_t loc, cp_trait_kind kind, 
tree type1, tree type2)
 case CPTK_IS_ENUM:
 case CPTK_IS_UNION:
 case CPTK_IS_SAME:
+case CPTK_IS_SCOPED_ENUM:
   break;
 
 case CPTK_IS_LAYOUT_COMPATIBLE:
diff --git a/gcc/testsuite/g++.dg/ext/has-builtin-1.C 
b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
index f343e153e56..bc79e50054a 100644
--- a/gcc/testsuite/g++.dg/ext/has-builtin-1.C
+++ b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
@@ -146,3 +146,6 @@
 #if !__has_builtin (__remove_cvref)
 # error "__has_builtin (__remove_cvref) failed"
 #endif
+#if !__has_builtin (__is_scoped_enum)
+# error "__has_builtin (__is_scoped_enum) failed"
+#endif
diff --git a/gcc/testsuite/g++.dg/ext/is_scoped_enum.C 
b/gcc/testsuite/g++.dg/ext/is_scoped_enum.C
new file mode 100644
index 000..a563b6ee67d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/is_scoped_enum.C
@@ -0,0 +1,67 @@
+// { dg-do compile { target c++11 } }
+
+#include 
+
+using namespace __gnu_test;
+
+#define SA(X) static_assert((X),#X)
+
+#define SA_TEST_FN(TRAIT, TYPE, EXPECT)\
+  SA(TRAIT(TYPE) == EXPECT);   \
+  SA(TRAIT(const TYPE) == EXPECT);
+
+#define SA_TEST_CATEGORY(TRAIT, TYPE, EXPECT)  \
+  SA(TRAIT(TYPE) == EXPECT);   \
+  SA(TRAIT(const TYPE) == EXPECT); \
+  SA(TRAIT(volatile TYPE) == EXPECT);  \
+  SA(TRAIT(const volatile TYPE) == EXPECT)
+
+enum class E { e1, e2 };
+SA_TEST_CATEGORY(__is_scoped_enum, E, true);
+enum class Ec : char { e1, e2 };
+SA_TEST_CATEGORY(__is_scoped_enum, Ec, true);
+
+// negative tests
+enum U { u1, u2 };
+SA_TEST_CATEGORY(__is_scoped_enum, U, false);
+enum F : int { f1, f2 };
+SA_TEST_CATEGORY(__is_scoped_enum, F, false);
+struct S;
+SA_TEST_CATEGORY(__is_scoped_enum, S, false);
+struct S { };
+SA_TEST_CATEGORY(__is_scoped_enum, S, false);
+
+SA_TEST_CATEGORY(__is_scoped_enum, int, false);
+SA_TEST_CATEGORY(__is_scoped_enum, int[], false);
+SA_TEST_CATEGORY(__is_scoped_enum, int[2], false);
+SA_TEST_CATEGORY(__is_scoped_enum, int[][2], false);
+SA_TEST_CATEGORY(__is_scoped_enum, int[2][3], false);
+SA_TEST_CATEGORY(__is_scoped_enum, int*, false);
+SA_TEST_CATEGORY(__is_scoped_enum, int&, false);
+SA_TEST_CATEGORY(__is_scoped_enum, int*&, false);
+SA_TEST_FN(__is_scoped_enum, int(), false);
+SA_TEST_FN(__is_scoped_enum, int(*)(), false);
+SA_TEST_FN(__is_scoped_enum, int(&)(), false);
+
+enum opaque_unscoped : 

[PATCH 0/2] Optimize is_scoped_enum trait performance

2023-09-11 Thread Ken Matsui via Gcc-patches
This patch series optimizes is_scoped_enum trait
performance. The first patch implements __is_scoped_enum
built-in trait. The second patch optimizes is_scoped_enum
trait performance by using __is_scoped_enum built-in trait
if available.

The performance improvement is shown in the following benchmark:

https://github.com/ken-matsui/gsoc23/blob/main/is_scoped_enum_v.md#mon-sep-11-050411-pm-pdt-2023

Time: -32.717% +/- 1.67315%
Peak Memory Usage: -17.3805% +/- 0.00931763%
Total Memory Usage: -19.0881% +/- 0%

Ken Matsui (2):
  c++: Implement __is_scoped_enum built-in trait
  libstdc++: Optimize is_scoped_enum trait performance

 gcc/cp/constraint.cc  |  3 +
 gcc/cp/cp-trait.def   |  1 +
 gcc/cp/semantics.cc   |  4 ++
 gcc/testsuite/g++.dg/ext/has-builtin-1.C  |  3 +
 gcc/testsuite/g++.dg/ext/is_scoped_enum.C | 67 +++
 libstdc++-v3/include/std/type_traits  | 12 
 6 files changed, 90 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/ext/is_scoped_enum.C

-- 
2.42.0



Re: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV intrinsic

2023-09-11 Thread 钟居哲
I don't understand.

+tree
+resolve_overloaded_builtin (location_t loc, unsigned int code,
+   vec *arglist)
+{
+  if (code >= vec_safe_length (registered_functions))
+return NULL_TREE;
+
+  const registered_function *rfun = (*registered_functions)[code];
+
+  if (!rfun || !rfun->overloaded_p)
+return NULL_TREE;
+
+  return function_resolver (loc, rfun->instance, rfun->decl, *arglist)
+.resolve ();
+}
You already have rfun->instance. Just use this instance should be good enough.


juzhe.zh...@rivai.ai
 
From: Li, Pan2
Date: 2023-09-11 23:24
To: 钟居哲
CC: kito.cheng; gcc-patches; Wang, Yanzhang
Subject: RE: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for 
RVV intrinsic
For function instance with void or void arguments, it is easy as you mentioned 
as below.
 
For generate API (to get the right hash), you need to build the rvv_type_info, 
predications_type_index and rvv_op_info
from the arglist (aka vec) from hook.
 
Then we need to construct above parameters from one tree argument. Sorry I not 
sure if I understand correctly but I failed
to locate somewhere has similar usage.
 
Could you please help to insight me some best practice about the transformation 
from tree to above types?
 
Pan
 
From: 钟居哲  
Sent: Monday, September 11, 2023 9:07 PM
To: Li, Pan2 
Cc: kito.cheng ; gcc-patches ; 
Wang, Yanzhang 
Subject: Re: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for 
RVV intrinsic
 
function_instance
get_read_vl_instance (void)
{
  return function_instance ("read_vl", bases::read_vl, shapes::read_vl,
  none_ops[0], PRED_TYPE_none, _none_void_ops);
}
 
tree
get_read_vl_decl (void)
{
  function_instance instance = get_read_vl_instance ();
  hashval_t hash = instance.hash ();
  registered_function *rfn = function_table->find_with_hash (instance, hash);
  gcc_assert (rfn);
  return rfn->decl;
}
 
You should reference it. I don't see why it's hard for use to construct 
instance first, then use that instance hash to get the decl.


juzhe.zh...@rivai.ai
 
From: Li, Pan2
Date: 2023-09-11 20:26
To: juzhe.zhong
CC: kito.cheng; gcc-patches; Wang, Yanzhang
Subject: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV 
intrinsic
> No. You must construct instance. 'strcmp' is very ugly.
 
Strcmp here is defensive code here for early exit if not found (can be removed 
for correctness), which is not required to find the right declaration.
 
Pan
 
From: juzhe.zhong  
Sent: Monday, September 11, 2023 8:20 PM
To: Li, Pan2 
Cc: kito.cheng ; gcc-patches ; 
Wang, Yanzhang 
Subject: Re: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV 
intrinsic
 
No. You must construct instance. 'strcmp' is very ugly.
 Replied Message 
From
Li, Pan2
Date
09/11/2023 20:09
To
juzhe.zh...@rivai.ai,
kito.cheng
Cc
gcc-patches,
Wang, Yanzhang
Subject
RE: Re: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV 
intrinsic
> -if (overloaded_p && instance.pred == PRED_TYPE_m)
> +if (overloaded_p)
 
Thanks for pointing this out, my misunderstanding for policy function result in 
this change as mistake, will send V2 for this.
 
> Plz change it into : Actually, it is not easy to convert to this approach as 
> aarch64 has different implementation of types information.Like 
> type_suffix_info (aarch64 loop type suffix to get the arglist type in 
> infer_vector_or_tuple_type) etc.Thus, it is not easy to construct 
> rvv_type_info, predication_type_index and rvv_op_info from arglist, these are 
> requiredby function_instance when constructing. Pan
 
From: juzhe.zh...@rivai.ai  
Sent: Monday, September 11, 2023 5:13 PM
To: kito.cheng 
Cc: Li, Pan2 ; gcc-patches ; Wang, 
Yanzhang 
Subject: Re: Re: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for 
RVV intrinsic
 
>> Just make sure it's the right change?
It seem incorrect to me.
 
More comments (I just reviewed again):
 
+tree+function_resolver::lookup ()+{+  unsigned int code_limit = 
vec_safe_length (registered_functions);++  for (unsigned code = get_sub_code () 
+ 1; code < code_limit; code++)+{+  registered_function *rfun = 
(*registered_functions)[code];+  function_instance instance = 
rfun->instance;++  if (strcmp (base_name, instance.base_name) != 0)+  
break;++  if (rfun->overloaded_p)+  continue;++  unsigned k;+  
const rvv_arg_type_info *args = instance.op_info->args;++  for (k = 0; 
args[k].base_type != NUM_BASE_TYPES; k++)+  {+if (k >= 
m_arglist.length ())+  break;++if (TYPE_MODE 
(instance.get_arg_type (k))+  != TYPE_MODE (TREE_TYPE (m_arglist[k])))+ 
 break;+  }++  if (args[k].base_type == NUM_BASE_TYPES)+
return rfun->decl;+}++  return NULL_TREE;+} Plz change it into : 
/* Silently check whether there is an instance of the function with the
   mode suffix given by MODE and the type suffixes given by TYPE0 and TYPE1.
   Return its function decl if so, otherwise 

[Linaro-TCWG-CI] gcc patch #75674: FAIL: 68 regressions

2023-09-11 Thread ci_notify--- via Gcc-patches
Dear contributor, our automatic CI has detected problems related to your 
patch(es).  Please find some details below.  If you have any questions, please 
follow up on linaro-toolch...@lists.linaro.org mailing list, Libera's 
#linaro-tcwg channel, or ping your favourite Linaro toolchain developer on the 
usual project channel.

In CI config tcwg_gcc_check/master-aarch64 after:

  | gcc patch https://patchwork.sourceware.org/patch/75674
  | Author: benjamin priour 
  | Date:   Mon Sep 11 19:44:34 2023 +0200
  | 
  | analyzer: Move gcc.dg/analyzer tests to c-c++-common (3) [PR96395]
  | 
  | Hi,
  | 
  | Patch below is mostly done, just have to check the formatting.
  | Althought, I'd like your feedback on how to manage named_constants
  | from enum in C++.
  | ... 21 lines of the commit log omitted.
  | ... applied on top of baseline commit:
  | 048927ed856 i386: Handle CONST_WIDE_INT in output_pic_addr_const [PR111340]

FAIL: 68 regressions

regressions.sum:
=== g++ tests ===

Running g++:g++.dg/analyzer/analyzer.exp ...
FAIL: c-c++-common/analyzer/call-summaries-2.c -std=c++14 (test for excess 
errors)
FAIL: c-c++-common/analyzer/call-summaries-2.c -std=c++17 (test for excess 
errors)
FAIL: c-c++-common/analyzer/call-summaries-2.c -std=c++20 (test for excess 
errors)
FAIL: c-c++-common/analyzer/call-summaries-2.c -std=c++98 (test for excess 
errors)
FAIL: c-c++-common/analyzer/memcpy-1.c -std=c++14  (test for warnings, line 25)
FAIL: c-c++-common/analyzer/memcpy-1.c -std=c++14  (test for warnings, line 48)
FAIL: c-c++-common/analyzer/memcpy-1.c -std=c++14 (test for excess errors)
... and 63 more entries

You can find the failure logs in *.log.1.xz files in
 - 
https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-precommit/2244/artifact/artifacts/artifacts.precommit/00-sumfiles/
 .
The full lists of regressions and progressions are in
 - 
https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-precommit/2244/artifact/artifacts/artifacts.precommit/notify/
 .
The list of [ignored] baseline and flaky failures are in
 - 
https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-precommit/2244/artifact/artifacts/artifacts.precommit/sumfiles/xfails.xfail
 .



-8<--8<--8<--
The information below can be used to reproduce a debug environment:

Current build   : 
https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-precommit/2244/artifact/artifacts
Reference build : 
https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/927/artifact/artifacts


[PATCH] RISC-V: Finish Typing Un-Typed Instructions and Turn on Assert

2023-09-11 Thread Edwin Lu
Updates autovec instruction that was added after last patch and turns on the
assert statement to ensure all new instructions have a type.

* config/riscv/autovec-opt.md: Update type
* config/riscv/riscv.cc (riscv_sched_variable_issue): Remove assert

Signed-off-by: Edwin Lu 
---
 gcc/config/riscv/autovec-opt.md | 3 ++-
 gcc/config/riscv/riscv.cc   | 2 --
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/gcc/config/riscv/autovec-opt.md b/gcc/config/riscv/autovec-opt.md
index 58e80044f1e..f1d058ce911 100644
--- a/gcc/config/riscv/autovec-opt.md
+++ b/gcc/config/riscv/autovec-opt.md
@@ -649,7 +649,8 @@ (define_insn_and_split "*cond_"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine vlmax neg and UNSPEC_VCOPYSIGN
 (define_insn_and_split "*copysign_neg"
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 12926b206ac..d3b09543ba0 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -7708,11 +7708,9 @@ riscv_sched_variable_issue (FILE *, int, rtx_insn *insn, 
int more)
   if (get_attr_type (insn) == TYPE_GHOST)
 return 0;
 
-#if 0
   /* If we ever encounter an insn with an unknown type, trip
  an assert so we can find and fix this problem.  */
   gcc_assert (get_attr_type (insn) != TYPE_UNKNOWN);
-#endif
 
   return more - 1;
 }
-- 
2.34.1



[PATCH 2/2] libstdc++: Optimize is_unbounded_array trait performance

2023-09-11 Thread Ken Matsui via Gcc-patches
This patch optimizes the performance of the is_unbounded_array trait
by dispatching to the new __is_unbounded_array built-in trait.

libstdc++-v3/ChangeLog:

* include/std/type_traits (is_unbounded_array_v): Use
__is_unbounded_array built-in trait.

Signed-off-by: Ken Matsui 
---
 libstdc++-v3/include/std/type_traits | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index 677cd934b94..a82987b4a6f 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -3503,11 +3503,16 @@ template
   /// True for a type that is an array of unknown bound.
   /// @ingroup variable_templates
   /// @since C++20
+# if _GLIBCXX_USE_BUILTIN_TRAIT(__is_unbounded_array)
+  template
+inline constexpr bool is_unbounded_array_v = __is_unbounded_array(_Tp);
+# else
   template
 inline constexpr bool is_unbounded_array_v = false;
 
   template
 inline constexpr bool is_unbounded_array_v<_Tp[]> = true;
+# endif
 
   /// True for a type that is an array of known bound.
   /// @since C++20
-- 
2.42.0



[PATCH 1/2] c++: Implement __is_unbounded_array built-in trait

2023-09-11 Thread Ken Matsui via Gcc-patches
This patch implements built-in trait for
std::is_unbounded_array.

gcc/cp/ChangeLog:

* cp-trait.def (IS_UNBOUNDED_ARRAY): Define
__is_unbounded_array.
* constraint.cc (diagnose_trait_expr): Handle
CPTK_IS_UNBOUNDED_ARRAY.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/ext/has-builtin-1.C: Test existence of
is_unbounded_array.
* g++.dg/ext/is_unbounded_array.C: New test.

Signed-off-by: Ken Matsui 
---
 gcc/cp/constraint.cc  |  3 ++
 gcc/cp/cp-trait.def   |  1 +
 gcc/cp/semantics.cc   |  4 ++
 gcc/testsuite/g++.dg/ext/has-builtin-1.C  |  3 ++
 gcc/testsuite/g++.dg/ext/is_unbounded_array.C | 37 +++
 5 files changed, 48 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/ext/is_unbounded_array.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index c9e4e7043cd..0250e4aba83 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -3760,6 +3760,9 @@ diagnose_trait_expr (tree expr, tree args)
 case CPTK_IS_ASSIGNABLE:
   inform (loc, "  %qT is not assignable from %qT", t1, t2);
   break;
+case CPTK_IS_UNBOUNDED_ARRAY:
+  inform (loc, "  %qT is not an unbounded array", t1);
+  break;
 case CPTK_IS_TRIVIALLY_ASSIGNABLE:
   inform (loc, "  %qT is not trivially assignable from %qT", t1, t2);
   break;
diff --git a/gcc/cp/cp-trait.def b/gcc/cp/cp-trait.def
index 8b7fece0cc8..d7d09165d3b 100644
--- a/gcc/cp/cp-trait.def
+++ b/gcc/cp/cp-trait.def
@@ -81,6 +81,7 @@ DEFTRAIT_EXPR (IS_TRIVIAL, "__is_trivial", 1)
 DEFTRAIT_EXPR (IS_TRIVIALLY_ASSIGNABLE, "__is_trivially_assignable", 2)
 DEFTRAIT_EXPR (IS_TRIVIALLY_CONSTRUCTIBLE, "__is_trivially_constructible", -1)
 DEFTRAIT_EXPR (IS_TRIVIALLY_COPYABLE, "__is_trivially_copyable", 1)
+DEFTRAIT_EXPR (IS_UNBOUNDED_ARRAY, "__is_unbounded_array", 1)
 DEFTRAIT_EXPR (IS_UNION, "__is_union", 1)
 DEFTRAIT_EXPR (REF_CONSTRUCTS_FROM_TEMPORARY, 
"__reference_constructs_from_temporary", 2)
 DEFTRAIT_EXPR (REF_CONVERTS_FROM_TEMPORARY, 
"__reference_converts_from_temporary", 2)
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 0f7f4e87ae4..6ea5281cf59 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -12178,6 +12178,9 @@ trait_expr_value (cp_trait_kind kind, tree type1, tree 
type2)
 case CPTK_IS_TRIVIALLY_COPYABLE:
   return trivially_copyable_p (type1);
 
+case CPTK_IS_UNBOUNDED_ARRAY:
+  return array_of_unknown_bound_p (type1);
+
 case CPTK_IS_UNION:
   return type_code1 == UNION_TYPE;
 
@@ -12359,6 +12362,7 @@ finish_trait_expr (location_t loc, cp_trait_kind kind, 
tree type1, tree type2)
 case CPTK_IS_ENUM:
 case CPTK_IS_UNION:
 case CPTK_IS_SAME:
+case CPTK_IS_UNBOUNDED_ARRAY:
   break;
 
 case CPTK_IS_LAYOUT_COMPATIBLE:
diff --git a/gcc/testsuite/g++.dg/ext/has-builtin-1.C 
b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
index f343e153e56..91f44804763 100644
--- a/gcc/testsuite/g++.dg/ext/has-builtin-1.C
+++ b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
@@ -146,3 +146,6 @@
 #if !__has_builtin (__remove_cvref)
 # error "__has_builtin (__remove_cvref) failed"
 #endif
+#if !__has_builtin (__is_unbounded_array)
+# error "__has_builtin (__is_unbounded_array) failed"
+#endif
diff --git a/gcc/testsuite/g++.dg/ext/is_unbounded_array.C 
b/gcc/testsuite/g++.dg/ext/is_unbounded_array.C
new file mode 100644
index 000..1307d24f5a5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/is_unbounded_array.C
@@ -0,0 +1,37 @@
+// { dg-do compile { target c++11 } }
+
+#include 
+
+using namespace __gnu_test;
+
+#define SA(X) static_assert((X),#X)
+
+#define SA_TEST_CATEGORY(TRAIT, TYPE, EXPECT)  \
+  SA(TRAIT(TYPE) == EXPECT);   \
+  SA(TRAIT(const TYPE) == EXPECT); \
+  SA(TRAIT(volatile TYPE) == EXPECT);  \
+  SA(TRAIT(const volatile TYPE) == EXPECT)
+
+SA_TEST_CATEGORY(__is_unbounded_array, int[2], false);
+SA_TEST_CATEGORY(__is_unbounded_array, int[], true);
+SA_TEST_CATEGORY(__is_unbounded_array, int[2][3], false);
+SA_TEST_CATEGORY(__is_unbounded_array, int[][3], true);
+SA_TEST_CATEGORY(__is_unbounded_array, float*[2], false);
+SA_TEST_CATEGORY(__is_unbounded_array, float*[], true);
+SA_TEST_CATEGORY(__is_unbounded_array, float*[2][3], false);
+SA_TEST_CATEGORY(__is_unbounded_array, float*[][3], true);
+SA_TEST_CATEGORY(__is_unbounded_array, ClassType[2], false);
+SA_TEST_CATEGORY(__is_unbounded_array, ClassType[], true);
+SA_TEST_CATEGORY(__is_unbounded_array, ClassType[2][3], false);
+SA_TEST_CATEGORY(__is_unbounded_array, ClassType[][3], true);
+SA_TEST_CATEGORY(__is_unbounded_array, IncompleteClass[2][3], false);
+SA_TEST_CATEGORY(__is_unbounded_array, IncompleteClass[][3], true);
+SA_TEST_CATEGORY(__is_unbounded_array, int(*)[2], false);

[PATCH 0/2] Optimize is_unbounded_array trait performance

2023-09-11 Thread Ken Matsui via Gcc-patches
This patch series optimizes is_unbounded_array trait
performance. The first patch implements __is_unbounded_array
built-in trait. The second patch optimizes is_unbounded_array
trait performance by using __is_unbounded_array built-in trait
if available.

The performance improvement is shown in the following benchmark:

https://github.com/ken-matsui/gsoc23/blob/main/is_unbounded_array_v.md#mon-sep-11-030125-pm-pdt-2023

Time: -2.79908%
Peak Memory Usage: -1.11666%
Total Memory Usage: -2.48356%

Ken Matsui (2):
  c++: Implement __is_unbounded_array built-in trait
  libstdc++: Optimize is_unbounded_array trait performance

 gcc/cp/constraint.cc  |  3 ++
 gcc/cp/cp-trait.def   |  1 +
 gcc/cp/semantics.cc   |  4 ++
 gcc/testsuite/g++.dg/ext/has-builtin-1.C  |  3 ++
 gcc/testsuite/g++.dg/ext/is_unbounded_array.C | 37 +++
 libstdc++-v3/include/std/type_traits  |  5 +++
 6 files changed, 53 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/ext/is_unbounded_array.C

-- 
2.42.0



[PING][PATCH 0/9] Add btf_decl_tag C attribute

2023-09-11 Thread David Faust via Gcc-patches
Ping.

This series adds a new C language attribute for recording additional
information in DWARF and BTF, similar to an existing attribute in clang.

https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624156.html

There are components in c-family, dwarf, ctf and btf.
Thanks.

On 7/11/23 14:57, David Faust via Gcc-patches wrote:
> Hello,
> 
> This series adds support for a new attribute, "btf_decl_tag" in GCC.
> The same attribute is already supported in clang, and is used by various
> components of the BPF ecosystem.
> 
> The purpose of the attribute is to allow to associate (to "tag")
> declarations with arbitrary string annotations, which are emitted into
> debugging information (DWARF and/or BTF) to facilitate post-compilation
> analysis (the motivating use case being the Linux kernel BPF verifier).
> Multiple tags are allowed on the same declaration.
> 
> These strings are not interpreted by the compiler, and the attribute
> itself has no effect on generated code, other than to produce additional
> DWARF DIEs and/or BTF records conveying the annotations.
> 
> This entails:
> 
> - A new C-language-level attribute which allows to associate (to "tag")
>   particular declarations with arbitrary strings.
> 
> - The conveyance of that information in DWARF in the form of a new DIE,
>   DW_TAG_GNU_annotation, with tag number (0x6000) and format matching
>   that of the DW_TAG_LLVM_annotation extension supported in LLVM for
>   the same purpose. These DIEs are already supported by BPF tooling,
>   such as pahole.
> 
> - The conveyance of that information in BTF debug info in the form of
>   BTF_KIND_DECL_TAG records. These records are already supported by
>   LLVM and other tools in the eBPF ecosystem, such as the Linux kernel
>   eBPF verifier.
> 
> 
> Background
> ==
> 
> The purpose of these tags is to convey additional semantic information
> to post-compilation consumers, in particular the Linux kernel eBPF
> verifier. The verifier can make use of that information while analyzing
> a BPF program to aid in determining whether to allow or reject the
> program to be run. More background on these tags can be found in the
> early support for them in the kernel here [1] and [2].
> 
> The "btf_decl_tag" attribute is half the story; the other half is a
> sibling attribute "btf_type_tag" which serves the same purpose but
> applies to types. Support for btf_type_tag will come in a separate
> patch series, since it is impaced by GCC bug 110439 which needs to be
> addressed first.
> 
> I submitted an initial version of this work (including btf_type_tag)
> last spring [3], however at the time there were some open questions
> about the behavior of the btf_type_tag attribute and issues with its
> implementation. Since then we have clarified these details and agreed
> to solutions with the BPF community and LLVM BPF folks.
> 
> The main motivation for emitting the tags in DWARF is that the Linux
> kernel generates its BTF information via pahole, using DWARF as a source:
> 
> ++  BTF  BTF   +--+
> | pahole |---> vmlinux.btf --->| verifier |
> ++ +--+
> ^^
> ||
>   DWARF |BTF |
> ||
>   vmlinux  +-+
>   module1.ko   | BPF program |
>   module2.ko   +-+
> ...
> 
> This is because:
> 
> a)  pahole adds additional kernel-specific information into the
> produced BTF based on additional analysis of kernel objects.
> 
> b)  Unlike GCC, LLVM will only generate BTF for BPF programs.
> 
> b)  GCC can generate BTF for whatever target with -gbtf, but there is no
> support for linking/deduplicating BTF in the linker.
> 
> In the scenario above, the verifier needs access to the pointer tags of
> both the kernel types/declarations (conveyed in the DWARF and translated
> to BTF by pahole) and those of the BPF program (available directly in BTF).
> 
> 
> DWARF Representation
> 
> 
> As noted above, btf_decl_tag is represented in DWARF via a new DIE
> DW_TAG_GNU_annotation, with identical format to the LLVM DWARF
> extension DW_TAG_LLVM_annotation serving the same purpose. The DIE has
> the following format:
> 
>   DW_TAG_GNU_annotation (0x6000)
> DW_AT_name: "btf_decl_tag"
> DW_AT_const_value: 
> 
> These DIEs are placed in the DWARF tree as children of the DIE for the
> appropriate declaration, and one such DIE is created for each occurrence
> of the btf_decl_tag attribute on a declaration.
> 
> For example:
> 
>   const int * c __attribute__((btf_decl_tag ("__c"), btf_decl_tag 
> ("devicemem")));
> 
> This declaration produces the following DWARF:
> 
>  <1><1e>: Abbrev Number: 2 (DW_TAG_variable)
> 

Re: [r14-3823 Regression] FAIL: c-c++-common/analyzer/compound-assignment-1.c -std=c++98 (test for warnings, line 72) on Linux/x86_64

2023-09-11 Thread Jakub Jelinek via Gcc-patches
On Mon, Sep 11, 2023 at 07:27:57PM +0200, Benjamin Priour via Gcc-patches wrote:
> Thanks for the report,
> 
> After investigation it seems the location of the new dejagnu directive for
> C++ differs depending on the configuration.
> The expected warning is still emitted, but its location differ slightly.
> I expect it to be not an issue per se of the analyzer, but a divergence in
> the FE between the two configurations.

I think the divergence is whether called_by_test_5b returns the struct
in registers or in memory.  If in memory (like in the x86_64 -m32 case), we have
  [compound-assignment-1.c:71:21] D.3191 = called_by_test_5b (); [return slot 
optimization]
  [compound-assignment-1.c:71:21 discrim 1] D.3191 ={v} {CLOBBER(eol)};
  [compound-assignment-1.c:72:1] return;
in the IL, while if in registers (like x86_64 -m64 case), just
  [compound-assignment-1.c:71:21] D.3591 = called_by_test_5b ();
  [compound-assignment-1.c:72:1] return;

If you just want to avoid the differences, putting } on the same line as the
call might be a usable workaround for that.

Jakub



[PATCH] MATCH: [PR111348] add missing :c to cmp in the `(a CMP b) ? minmax : minmax` pattern

2023-09-11 Thread Andrew Pinski via Gcc-patches
When I added this pattern in r14-337-gc43819a9b4cd, I had missed the :c on the 
cmp
part of the pattern meaning there might be some missing optimizations happening.
The testcase shows an example of the missed optmization.

Committed as obvious after a bootstrap/test on x86_64-linux-gnu.

PR tree-optimization/111348

gcc/ChangeLog:

* match.pd (`(a CMP b) ? minmax : minmax`): Add :c on
the cmp part of the pattern.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/minmax-26.c: New test.
---
 gcc/match.pd  |  2 +-
 gcc/testsuite/gcc.dg/tree-ssa/minmax-26.c | 22 ++
 2 files changed, 23 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/minmax-26.c

diff --git a/gcc/match.pd b/gcc/match.pd
index 209b0599382..e96e385c6fa 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -5417,7 +5417,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (for minmax (min max)
  (for cmp (lt le gt ge ne)
   (simplify
-   (cond (cmp @1 @3) (minmax:c @1 @4) (minmax:c @2 @4))
+   (cond (cmp:c @1 @3) (minmax:c @1 @4) (minmax:c @2 @4))
(with
 {
   tree_code code = minmax_from_comparison (cmp, @1, @2, @1, @3);
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/minmax-26.c 
b/gcc/testsuite/gcc.dg/tree-ssa/minmax-26.c
new file mode 100644
index 000..e4b7412e766
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/minmax-26.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized -fdump-tree-original" } */
+/* PR tree-optimization/111348 */
+
+int test1(int a, int b, int c)
+{
+return (a > b) ? ((a > c) ? a : c) : ((b > c) ? b : c);
+}
+
+
+int test1_(int a, int b, int c)
+{
+return (b < a) ? ((a > c) ? a : c) : ((b > c) ? b : c);
+}
+
+/* test1 and test1_ should be able to optimize to `MAX_EXPR , 
c>;` during fold.  */
+/* { dg-final { scan-tree-dump-times "MAX_EXPR , c>" 2 
"original" } } */
+/* { dg-final { scan-tree-dump-not "b > a" "original" } } */
+/* { dg-final { scan-tree-dump-not "a > b" "original" } } */
+/* { dg-final { scan-tree-dump-times "MAX_EXPR " 4 "optimized" } } */
+/* { dg-final { scan-tree-dump-not "if " "optimized" } } */
+
-- 
2.31.1



Re: [PATCH] gimple-match: Do not try UNCOND optimization with COND_LEN.

2023-09-11 Thread Robin Dapp via Gcc-patches
Hi,

as Juzhe noticed in gcc.dg/pr92301.c there was still something missing in
the last patch.  The attached v2 makes sure we always have a COND_LEN operation
before returning true and initializes len and bias even if they are unused.

Bootstrapped and regtested on aarch64 and x86.

Regards
 Robin

Subject: [PATCH v2] gimple-match: Do not try UNCOND optimization with
 COND_LEN.

On riscv we mis-optimize conditional (length) operations into
unconditional operations e.g. in slp-reduc-7.c and
gcc.dg/pr92301.c.

This patch prevents optimizing e.g.
 COND_LEN_ADD ({-1, ... }, a, 0, c, len, bias)
unconditionally into just "a".

Currently, we assume that COND_LEN operations can be optimized similarly
to COND operations.  As the length is part of the mask (and usually not
compile-time constant), we must not perform any optimization that relies
on just the mask being "true".  This patch ensures that we still have a
COND_LEN pattern after optimization.

gcc/ChangeLog:

PR target/111311
* gimple-match-exports.cc (maybe_resimplify_conditional_op):
Check for length masking.
(try_conditional_simplification): Check that the result is still
length masked.
---
 gcc/gimple-match-exports.cc | 38 ++---
 gcc/gimple-match.h  |  3 ++-
 2 files changed, 33 insertions(+), 8 deletions(-)

diff --git a/gcc/gimple-match-exports.cc b/gcc/gimple-match-exports.cc
index b36027b0bad..d41de98a3d3 100644
--- a/gcc/gimple-match-exports.cc
+++ b/gcc/gimple-match-exports.cc
@@ -262,7 +262,8 @@ maybe_resimplify_conditional_op (gimple_seq *seq, 
gimple_match_op *res_op,
   if (!res_op->cond.cond)
 return false;
 
-  if (!res_op->cond.else_value
+  if (!res_op->cond.len
+  && !res_op->cond.else_value
   && res_op->code.is_tree_code ())
 {
   /* The "else" value doesn't matter.  If the "then" value is a
@@ -301,9 +302,12 @@ maybe_resimplify_conditional_op (gimple_seq *seq, 
gimple_match_op *res_op,
 
   /* If the "then" value is a gimple value and the "else" value matters,
  create a VEC_COND_EXPR between them, then see if it can be further
- simplified.  */
+ simplified.
+ Don't do this if we have a COND_LEN_ as that would make us lose the
+ length masking.  */
   gimple_match_op new_op;
-  if (res_op->cond.else_value
+  if (!res_op->cond.len
+  && res_op->cond.else_value
   && VECTOR_TYPE_P (res_op->type)
   && gimple_simplified_result_is_gimple_val (res_op))
 {
@@ -314,7 +318,7 @@ maybe_resimplify_conditional_op (gimple_seq *seq, 
gimple_match_op *res_op,
   return gimple_resimplify3 (seq, res_op, valueize);
 }
 
-  /* Otherwise try rewriting the operation as an IFN_COND_* call.
+  /* Otherwise try rewriting the operation as an IFN_COND_(LEN_)* call.
  Again, this isn't a simplification in itself, since it's what
  RES_OP already described.  */
   if (convert_conditional_op (res_op, _op))
@@ -386,9 +390,29 @@ try_conditional_simplification (internal_fn ifn, 
gimple_match_op *res_op,
 default:
   gcc_unreachable ();
 }
-  *res_op = cond_op;
-  maybe_resimplify_conditional_op (seq, res_op, valueize);
-  return true;
+
+  if (len)
+{
+  /* If we had a COND_LEN before we need to ensure that it stays that
+way.  */
+  gimple_match_op old_op = *res_op;
+  *res_op = cond_op;
+  maybe_resimplify_conditional_op (seq, res_op, valueize);
+
+  auto cfn = combined_fn (res_op->code);
+  if (internal_fn_p (cfn)
+ && internal_fn_len_index (as_internal_fn (cfn)) != -1)
+   return true;
+
+  *res_op = old_op;
+  return false;
+}
+  else
+{
+  *res_op = cond_op;
+  maybe_resimplify_conditional_op (seq, res_op, valueize);
+  return true;
+}
 }
 
 /* Helper for the autogenerated code, valueize OP.  */
diff --git a/gcc/gimple-match.h b/gcc/gimple-match.h
index bec3ff42e3e..d192b7dae3e 100644
--- a/gcc/gimple-match.h
+++ b/gcc/gimple-match.h
@@ -56,7 +56,8 @@ public:
 
 inline
 gimple_match_cond::gimple_match_cond (tree cond_in, tree else_value_in)
-  : cond (cond_in), else_value (else_value_in)
+  : cond (cond_in), else_value (else_value_in), len (NULL_TREE),
+bias (NULL_TREE)
 {
 }
 
-- 
2.41.0




Re: [PATCH V3] RISC-V: Support Dynamic LMUL Cost model

2023-09-11 Thread Robin Dapp via Gcc-patches
Hi Juzhe,

glad that we can use the dominator info directly.  Could we move the
calculation of the info to the beginning (if it's not available)?  That
makes it clearer that it's a prerequisite.  Function comments look
good now.

Some general remarks kind of similar to v1:

 - I would prefer a hash_map or similar to hold the end point for a range
   instead of looking through potentially all ranges in contrived cases.

 - As long as we're just looking for the maximum number of live registers,
   we can use a sliding-window approach:  create a structure with all
   start and end points, sort it, and increase the current pressure
   if we start a new range or decrease.  That's O(n log n).

> +  const ssa_use_operand_t *const head = &(SSA_NAME_IMM_USE_NODE (t));
> +  const ssa_use_operand_t *ptr;
> +
> +  for (ptr = head->next; ptr != head; ptr = ptr->next)
> + {

Why does FOR_EACH_IMM_USE not work here?

> +   unsigned int max_point
> + = (*program_points_per_bb.get (e->src)).length () - 1;
> +   for (k = 0; k < (*live_ranges).length (); k++)
> + {
> +   if ((*live_ranges)[i].var == def)

Would also be nice not having to search through all ranges but just index/hash
it via var (or similar).

What about one test with global live ranges?  Not a necessity IMHO we can still
add it later.

Regards
 Robin



Re: [C PATCH 1/6 v2] c: reorganize recursive type checking

2023-09-11 Thread Joseph Myers
On Sun, 10 Sep 2023, Martin Uecker via Gcc-patches wrote:

> Thanks Joseph, below is a a revised version of this patch
> with slight additional changes to the comment of
> tagged_types_tu_compatible_p.
> 
> ok for trunk? 

The revised version of this patch is OK.

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


Re: RISC-V: Replace not + bitwise_imm with li + bitwise_not

2023-09-11 Thread Andrew Waterman via Gcc-patches
Note this is a size-speed tradeoff, as the Zcb extension has a
16-bit-wide C.NOT instruction.  Might want to suppress this
optimization when Zcb is present and the function is being optimized
for size.


On Mon, Sep 11, 2023 at 9:52 AM Jivan Hakobyan via Gcc-patches
 wrote:
>
> In the case when we have C code like this
>
> int foo (int a) {
>return 100 & ~a;
> }
>
> GCC generates the following instruction sequence
>
> foo:
>  not a0,a0
>  andia0,a0,100
>  ret
>
> This patch replaces that with this sequence
> foo:
>  li a5,100
>  andn a0,a5,a0
>  ret
>
> The profitability comes from an out-of-order processor being able to
> issue the "li a5, 100" at any time after it's fetched while "not a0, a0" has
> to wait until any prior setter of a0 has reached completion.
>
>
> gcc/ChangeLog:
> * config/riscv/bitmanip.md (*_not_const): New split
> pattern.
>
> gcc/testsuite/ChangeLog:
> * gcc.target/riscv/zbb-andn-orn-01.c: New test.
> * gcc.target/riscv/zbb-andn-orn-02.c: Likewise.
>
>
> --
> With the best regards
> Jivan Hakobyan


Re: [PATCH] analyzer: implement symbolic value support for CPython plugin's refcnt checker [PR107646]

2023-09-11 Thread David Malcolm via Gcc-patches
On Sun, 2023-09-10 at 22:12 -0400, Eric Feng wrote:
> On Thu, Sep 7, 2023 at 1:28 PM David Malcolm 
> wrote:
> 
> > On Mon, 2023-09-04 at 22:13 -0400, Eric Feng wrote:
> > 

[...snip...]

> > 
> > 
> > I know you're emulating the old behavior I implemented way back in
> > cpychecker, but I don't like that behavior :(
> > 
> > Specifically, although the patch improves the behavior for symbolic
> > values, it regresses the precision of wording for the concrete
> > values
> > case.  If we have e.g. a concrete ob_refcnt of 2, whereas we only
> > have
> > 1 pointer, then it's more readable to say:
> > 
> >   warning: expected ‘obj’ to have reference count: ‘1’ but
> > ob_refcnt
> > field is ‘2’
> > 
> > than:
> > 
> >   warning: expected ‘obj’ to have reference count: N + ‘1’ but
> > ob_refcnt
> > field is N + ‘2’
> > 
> > ...and we shouldn't quote concrete numbers, the message should be:
> > 
> >   warning: expected ‘obj’ to have reference count of 1 but
> > ob_refcnt field
> > is 2
> 
> 
> > or better:
> > 
> >   warning: ‘*obj’ is pointed to by 1 pointer but 'ob_refcnt' field
> > is 2
> > 
> > 
> > Can you move the unwrapping of the svalue from the tests below into
> > the
> > emit vfunc?  That way the m_actual_refcnt doesn't have to be a
> > constant_svalue; you could have logic in the emit vfunc to print
> > readable messages based on what kind of svalue it is.
> > 
> > Rather than 'N', it might be better to say 'initial'; how about:
> > 
> >   warning: ‘*obj’ is pointed to by 0 additional pointers but
> > 'ob_refcnt'
> > field has increased by 1
> >   warning: ‘*obj’ is pointed to by 1 additional pointer but
> > 'ob_refcnt'
> > field has increased by 2
> >   warning: ‘*obj’ is pointed to by 1 additional pointer but
> > 'ob_refcnt'
> > field is unchanged
> >   warning: ‘*obj’ is pointed to by 2 additional pointers but
> > 'ob_refcnt'
> > field has decreased by 1
> >   warning: ‘*obj’ is pointed to by 1 fewer pointers but 'ob_refcnt'
> > field
> > is unchanged
> > 
> > and similar?
> > 
> 
> That makes sense to me as well (indeed I was just emulating the old
> behavior)! Will experiment and keep you posted on a revised patch
> with this
> in mind.  This is somewhat of a minor detail but can we emit ‘*obj’
> as
> bolded text in the diagnostic message? Currently, I can emit this
> (including the asterisk) like so: '*%E'. But unlike using %qE, it
> doesn't
> bold the body of the single quotations. Is this possible?

Yes.

You could use %< and %> to get the colorized (and localized) quotes
(see pretty-print.cc), but better would probably be to pass a tree for
the *obj, rather than obj.  You can make this by building a MEM_REF
tree node wrapping the pointer (you can see an example of this in the
RK_SYMBOLIC case of region_model::get_representative_path_var_1).

Dave



[committed] i386: Handle CONST_WIDE_INT in output_pic_addr_const [PR111340]

2023-09-11 Thread Uros Bizjak via Gcc-patches
PR target/111340

gcc/ChangeLog:

* config/i386/i386.cc (output_pic_addr_const): Handle CONST_WIDE_INT.
Call output_addr_const for CASE_CONST_SCALAR_INT.

gcc/testsuite/ChangeLog:

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

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}, will
be backported to release branches.

Uros.
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 1cef7ee8f1a..477e6cecc38 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -12344,8 +12344,8 @@ output_pic_addr_const (FILE *file, rtx x, int code)
   assemble_name (asm_out_file, buf);
   break;
 
-case CONST_INT:
-  fprintf (file, HOST_WIDE_INT_PRINT_DEC, INTVAL (x));
+CASE_CONST_SCALAR_INT:
+  output_addr_const (file, x);
   break;
 
 case CONST:
diff --git a/gcc/testsuite/gcc.target/i386/pr111340.c 
b/gcc/testsuite/gcc.target/i386/pr111340.c
new file mode 100644
index 000..6539ae566c0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr111340.c
@@ -0,0 +1,9 @@
+/* PR target/111340 */
+/* { dg-do compile { target { fpic && int128 } } } */
+/* { dg-options "-O2 -fpic" } */
+
+void
+bar (void)
+{
+  __asm ("# %0" : : "g" unsigned __int128) 0x123456789abcdef0ULL) << 64) | 
0x0fedcba987654321ULL));
+}


Re: [PATCH] fortran: Undo new symbols in all namespaces [PR110996]

2023-09-11 Thread Harald Anlauf via Gcc-patches

Hi Mikael,

On 9/11/23 14:38, Mikael Morin via Gcc-patches wrote:

Hello,

this fixes a memory management issue in the fortran frontend.
I have included the (reduced) testcase from the PR, even if it wasn't failing
here on x86_64 with the test harness.
Tested on x86_64-pc-linux-gnu and manually checked the testcase with
valgrind.
OK for master?


nice fix!  This is OK for mainline.

Thanks for the patch!

Harald


-- >8 --

Remove new symbols from all namespaces they may have been added to in case a
statement mismatches in the end and all the symbols referenced in it have to
be reverted.

This fixes memory errors and random internal compiler errors caused by
a new symbol left with dangling pointers but not properly removed from the
namespace at statement rejection.

Before this change, new symbols were removed from their own namespace
(their ns field) only.  This change additionally removes them from the
namespaces pointed to by respectively the gfc_current_ns global variable,
and the symbols' formal_ns field.

PR fortran/110996

gcc/fortran/ChangeLog:

* gfortran.h (gfc_release_symbol): Set return type to bool.
* symbol.cc (gfc_release_symbol): Ditto.  Return whether symbol was
freed.
(delete_symbol_from_ns): New, outline code from...
(gfc_restore_last_undo_checkpoint): ... here.  Delete new symbols
from two more namespaces.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr110996.f90: New test.
---
  gcc/fortran/gfortran.h |  2 +-
  gcc/fortran/symbol.cc  | 57 --
  gcc/testsuite/gfortran.dg/pr110996.f90 | 16 
  3 files changed, 62 insertions(+), 13 deletions(-)
  create mode 100644 gcc/testsuite/gfortran.dg/pr110996.f90

diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 371f8743312..f4a1c106cea 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3514,7 +3514,7 @@ gfc_symtree *gfc_get_unique_symtree (gfc_namespace *);
  gfc_user_op *gfc_get_uop (const char *);
  gfc_user_op *gfc_find_uop (const char *, gfc_namespace *);
  void gfc_free_symbol (gfc_symbol *&);
-void gfc_release_symbol (gfc_symbol *&);
+bool gfc_release_symbol (gfc_symbol *&);
  gfc_symbol *gfc_new_symbol (const char *, gfc_namespace *);
  gfc_symtree* gfc_find_symtree_in_proc (const char *, gfc_namespace *);
  int gfc_find_symbol (const char *, gfc_namespace *, int, gfc_symbol **);
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index 2cba2ea0bed..a6078bc608a 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -3105,13 +3105,14 @@ gfc_free_symbol (gfc_symbol *)
  }


-/* Decrease the reference counter and free memory when we reach zero.  */
+/* Decrease the reference counter and free memory when we reach zero.
+   Returns true if the symbol has been freed, false otherwise.  */

-void
+bool
  gfc_release_symbol (gfc_symbol *)
  {
if (sym == NULL)
-return;
+return false;

if (sym->formal_ns != NULL && sym->refs == 2 && sym->formal_ns != sym->ns
&& (!sym->attr.entry || !sym->module))
@@ -3125,10 +3126,11 @@ gfc_release_symbol (gfc_symbol *)

sym->refs--;
if (sym->refs > 0)
-return;
+return false;

gcc_assert (sym->refs == 0);
gfc_free_symbol (sym);
+  return true;
  }


@@ -3649,6 +3651,29 @@ gfc_drop_last_undo_checkpoint (void)
  }


+/* Remove the reference to the symbol SYM in the symbol tree held by NS
+   and free SYM if the last reference to it has been removed.
+   Returns whether the symbol has been freed.  */
+
+static bool
+delete_symbol_from_ns (gfc_symbol *sym, gfc_namespace *ns)
+{
+  if (ns == nullptr)
+return false;
+
+  /* The derived type is saved in the symtree with the first
+ letter capitalized; the all lower-case version to the
+ derived type contains its associated generic function.  */
+  const char *sym_name = gfc_fl_struct (sym->attr.flavor)
+? gfc_dt_upper_string (sym->name)
+: sym->name;
+
+  gfc_delete_symtree (>sym_root, sym_name);
+
+  return gfc_release_symbol (sym);
+}
+
+
  /* Undoes all the changes made to symbols since the previous checkpoint.
 This subroutine is made simpler due to the fact that attributes are
 never removed once added.  */
@@ -3703,15 +3728,23 @@ gfc_restore_last_undo_checkpoint (void)
}
if (p->gfc_new)
{
- /* The derived type is saved in the symtree with the first
-letter capitalized; the all lower-case version to the
-derived type contains its associated generic function.  */
- if (gfc_fl_struct (p->attr.flavor))
-   gfc_delete_symtree (>ns->sym_root,gfc_dt_upper_string (p->name));
-  else
-   gfc_delete_symtree (>ns->sym_root, p->name);
+ bool freed = delete_symbol_from_ns (p, p->ns);

- gfc_release_symbol (p);
+ /* If the symbol is a procedure (function or subroutine), remove
+   

Re: [PATCH 4/5][Committed] RISC-V: Update Types for RISC-V Instructions

2023-09-11 Thread Edwin Lu

On 9/6/2023 4:23 PM, Kito Cheng via Gcc-patches wrote:

LGTM

Edwin Lu  於 2023年9月7日 週四 01:52 寫道:


This patch adds types to riscv instructions that were added or were
missed by the original patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628996.html

gcc/ChangeLog:

 * config/riscv/riscv.md: Update types

Signed-off-by: Edwin Lu 
---
  gcc/config/riscv/riscv.md | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index c329f55db43..c1cecd27815 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -2223,6 +2223,7 @@ (define_insn "movsidf2_low_rv32"
"TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA"
"fmv.x.w\t%0,%1"
[(set_attr "move_type" "fmove")
+   (set_attr "type" "fmove")
 (set_attr "mode" "DF")])


@@ -2235,6 +2236,7 @@ (define_insn "movsidf2_high_rv32"
"TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA"
"fmvh.x.d\t%0,%1"
[(set_attr "move_type" "fmove")
+   (set_attr "type" "fmove")
 (set_attr "mode" "DF")])

  (define_insn "movdfsisi3_rv32"
@@ -2247,6 +2249,7 @@ (define_insn "movdfsisi3_rv32"
"TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA"
"fmvp.d.x\t%0,%2,%1"
[(set_attr "move_type" "fmove")
+   (set_attr "type" "fmove")
 (set_attr "mode" "DF")])

  (define_split
--
2.34.1





Committed!

Edwin


Re: [PATCH 3/5][Committed] RISC-V: Add Types to Un-Typed Zicond Instructions

2023-09-11 Thread Edwin Lu

On 9/7/2023 6:17 AM, Jeff Law via Gcc-patches wrote:



On 9/6/23 18:42, Tsukasa OI via Gcc-patches wrote:



Looks okay to me but will need to resolve merge conflicts after commit
af88776caa20 ("RISC-V: Add support for 'XVentanaCondOps' reusing
'Zicond' support").
Sure.  We allow trival updates to resolve merge conflicts without 
needing another round of review.


Jeff


Committed!

Edwin


[PATCH] small _BitInt tweaks

2023-09-11 Thread Jakub Jelinek via Gcc-patches
Hi!

When discussing PR111369 with Andrew Pinski, I've realized that
I haven't added BITINT_TYPE handling to range_check_type.  Right now
(unsigned) max + 1 == (unsigned) min for signed _BitInt,l so I think we
don't need to do the extra hops for BITINT_TYPE (though possibly we don't
need them for INTEGER_TYPE either in the two's complement word and we don't
support anything else, though I really don't know if Ada or some other
FEs don't create weird INTEGER_TYPEs).
And, also I think it is undesirable when being asked for signed_type_for
of unsigned _BitInt(1) (which is valid) to get signed _BitInt(1) (which is
invalid, the standard only allows signed _BitInt(2) and larger), so the
patch returns 1-bit signed INTEGER_TYPE for those cases.

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

2023-09-11  Jakub Jelinek  

gcc/
* tree.cc (signed_or_unsigned_type_for): Return INTEGER_TYPE for
signed variant of unsigned _BitInt(1).
* fold-const.cc (range_check_type): Handle BITINT_TYPE like
OFFSET_TYPE.
gcc/c-family/
* c-common.cc (c_common_signed_or_unsigned_type): Return INTEGER_TYPE
for signed variant of unsigned _BitInt(1).

--- gcc/tree.cc.jj  2023-09-06 17:50:30.707589026 +0200
+++ gcc/tree.cc 2023-09-11 16:24:58.749625569 +0200
@@ -11096,7 +11096,7 @@ signed_or_unsigned_type_for (int unsigne
   else
 return NULL_TREE;
 
-  if (TREE_CODE (type) == BITINT_TYPE)
+  if (TREE_CODE (type) == BITINT_TYPE && (unsignedp || bits > 1))
 return build_bitint_type (bits, unsignedp);
   return build_nonstandard_integer_type (bits, unsignedp);
 }
--- gcc/c-family/c-common.cc.jj 2023-09-06 17:34:24.467254960 +0200
+++ gcc/c-family/c-common.cc2023-09-11 16:24:07.873300311 +0200
@@ -2739,7 +2739,9 @@ c_common_signed_or_unsigned_type (int un
   || TYPE_UNSIGNED (type) == unsignedp)
 return type;
 
-  if (TREE_CODE (type) == BITINT_TYPE)
+  if (TREE_CODE (type) == BITINT_TYPE
+  /* signed _BitInt(1) is invalid, avoid creating that.  */
+  && (unsignedp || TYPE_PRECISION (type) > 1))
 return build_bitint_type (TYPE_PRECISION (type), unsignedp);
 
 #define TYPE_OK(node)  \
--- gcc/fold-const.cc.jj2023-09-11 11:05:47.473728473 +0200
+++ gcc/fold-const.cc   2023-09-11 16:28:06.052141516 +0200
@@ -5565,7 +5565,12 @@ range_check_type (tree etype)
   else
return NULL_TREE;
 }
-  else if (POINTER_TYPE_P (etype) || TREE_CODE (etype) == OFFSET_TYPE)
+  else if (POINTER_TYPE_P (etype)
+  || TREE_CODE (etype) == OFFSET_TYPE
+  /* Right now all BITINT_TYPEs satisfy
+ (unsigned) max + 1 == (unsigned) min, so no need to verify
+ that like for INTEGER_TYPEs.  */
+  || TREE_CODE (etype) == BITINT_TYPE)
 etype = unsigned_type_for (etype);
   return etype;
 }

Jakub



Re: [PATCH v2 1/5][Committed] RISC-V: Update Types for Vector Instructions

2023-09-11 Thread Edwin Lu

On 9/8/2023 4:56 PM, Jeff Law via Gcc-patches wrote:



On 9/8/23 12:16, Edwin Lu wrote:
This patch adds types to vector instructions that were added after or 
were

missed by the original patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628594.html

gcc/ChangeLog:

* config/riscv/autovec-opt.md: Update types
* config/riscv/autovec.md: likewise
I think these were all define_insn_and_splits, so just about anything 
will do.  OK.


jeff


Committed!

Edwin


[PATCH] sccvn: Avoid ICEs on _BitInt load BIT_AND_EXPR mask [PR111338]

2023-09-11 Thread Jakub Jelinek via Gcc-patches
Hi!

The following testcase ICEs, because vn_walk_cb_data::push_partial_def
uses a fixed size buffer (64 target bytes) for its
construction/deconstruction of partial stores and fails if larger precision
than that is needed, and the PR93582 changes assert push_partial_def
succeeds (and check the various other conditions much earlier when seeing
the BIT_AND_EXPR statement, like CHAR_BIT == 8, BITS_PER_UNIT == 8,
BYTES_BIG_ENDIAN == WORDS_BIG_ENDIAN, etc.).  So, just removing the assert
and allowing it fail there doesn't really work and ICEs later on.

The following patch moves the bufsize out of the method and tests it
together with the other checks.

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

BTW, perhaps we could increase the bufsize as well or in addition to
increasing it make the buffer allocated using XALLOCAVEC, but still I think
it is useful to have some upper bound and so I think this patch is useful
even in that case.

2023-09-11  Jakub Jelinek  

PR middle-end/111338
* tree-ssa-sccvn.cc (struct vn_walk_cb_data): Add bufsize non-static
data member.
(vn_walk_cb_data::push_partial_def): Remove bufsize variable.
(visit_nary_op): Avoid the BIT_AND_EXPR with constant rhs2
optimization if type's precision is too large for
vn_walk_cb_data::bufsize.

* gcc.dg/bitint-37.c: New test.

--- gcc/tree-ssa-sccvn.cc.jj2023-09-06 17:28:24.232977433 +0200
+++ gcc/tree-ssa-sccvn.cc   2023-09-08 13:22:27.928158846 +0200
@@ -1903,6 +1903,7 @@ struct vn_walk_cb_data
   alias_set_type first_base_set;
   splay_tree known_ranges;
   obstack ranges_obstack;
+  static constexpr HOST_WIDE_INT bufsize = 64;
 };
 
 vn_walk_cb_data::~vn_walk_cb_data ()
@@ -1973,7 +1974,6 @@ vn_walk_cb_data::push_partial_def (pd_da
   HOST_WIDE_INT offseti,
   HOST_WIDE_INT maxsizei)
 {
-  const HOST_WIDE_INT bufsize = 64;
   /* We're using a fixed buffer for encoding so fail early if the object
  we want to interpret is bigger.  */
   if (maxsizei > bufsize * BITS_PER_UNIT
@@ -5414,6 +5414,7 @@ visit_nary_op (tree lhs, gassign *stmt)
  && CHAR_BIT == 8
  && BITS_PER_UNIT == 8
  && BYTES_BIG_ENDIAN == WORDS_BIG_ENDIAN
+ && TYPE_PRECISION (type) <= vn_walk_cb_data::bufsize * BITS_PER_UNIT
  && !integer_all_onesp (gimple_assign_rhs2 (stmt))
  && !integer_zerop (gimple_assign_rhs2 (stmt)))
{
--- gcc/testsuite/gcc.dg/bitint-37.c.jj 2023-09-08 13:27:51.676882523 +0200
+++ gcc/testsuite/gcc.dg/bitint-37.c2023-09-08 13:27:22.460268614 +0200
@@ -0,0 +1,11 @@
+/* PR middle-end/111338 */
+/* { dg-do compile { target bitint575 } } */
+/* { dg-options "-O1" } */
+
+_BitInt(575) e;
+
+_BitInt(575)
+foo (void)
+{
+  return e & 1;
+}

Jakub



Re: [r14-3823 Regression] FAIL: c-c++-common/analyzer/compound-assignment-1.c -std=c++98 (test for warnings, line 72) on Linux/x86_64

2023-09-11 Thread Benjamin Priour via Gcc-patches
Hi,
Thanks for the report,

After investigation it seems the location of the new dejagnu directive for
C++ differs depending on the configuration.
The expected warning is still emitted, but its location differ slightly.
I expect it to be not an issue per se of the analyzer, but a divergence in
the FE between the two configurations.

Need further investigation.

Best,
Benjamin.

On Mon, Sep 11, 2023 at 10:03 AM Jiang, Haochen 
wrote:

> On Linux/x86_64,
>
> 50b5199cff690891726877e1c00ac53dfb7cc1c8 is the first bad commit
> commit 50b5199cff690891726877e1c00ac53dfb7cc1c8
> Author: benjamin priour 
> Date:   Sat Sep 9 18:03:56 2023 +0200
>
> analyzer: Move gcc.dg/analyzer tests to c-c++-common (2) [PR96395]
>
> caused
>
> FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++14 (test for
> excess errors)
> FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++14  (test for
> warnings, line 72)
> FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++17 (test for
> excess errors)
> FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++17  (test for
> warnings, line 72)
> FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++20 (test for
> excess errors)
> FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++20  (test for
> warnings, line 72)
> FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++98 (test for
> excess errors)
> FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++98  (test for
> warnings, line 72)
>
> with GCC configured with
>
> ../../gcc/configure
> --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-3823/usr
> --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
> --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet
> --without-isl --enable-libmpx x86_64-linux --disable-bootstrap
>
> To reproduce:
>
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="analyzer.exp=c-c++-common/analyzer/compound-assignment-1.c
> --target_board='unix{-m32}'"
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="analyzer.exp=c-c++-common/analyzer/compound-assignment-1.c
> --target_board='unix{-m32\ -march=cascadelake}'"
>
> (If you met problems with cascadelake related, disabling AVX512F in
> command line might save that.)
> (However, please make sure that there is no potential problems with
> AVX512.)
>


Re: [PATCH] RISC-V Add Types to Un-Typed Thead Instructions:

2023-09-11 Thread Edwin Lu

On 9/10/2023 8:37 AM, Jeff Law via Gcc-patches wrote:



On 8/31/23 11:36, Edwin Lu wrote:

Related Discussion:
https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/

This patch updates the THEAD instructions to ensure that no insn is left
without a type attribute.

Tested for regressions using rv32/64 multilib for linux/newlib.

gcc/Changelog:

* config/riscv/thead.md: Update types
OK.  THe first could arguably be "multi", but both instructions it 
generates appear to be move/conversions, so "fmove" is reasonable as well.


Ok for the trunk.  And I think that's should allow us to turn on the 
assertion, right?


jeff

I just did one final check, there's one insn in autovec-opt.md that was 
added (line 635) but otherwise I think that should be it. I've typed it 
"vector" for now and am currently running a test to make sure nothing 
breaks. Would you like me to send another patch for it?


Edwin


Re: [PATCH] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11 [PR 111050]

2023-09-11 Thread François Dumont via Gcc-patches



On 11/09/2023 13:51, Jonathan Wakely wrote:

On Sun, 10 Sept 2023 at 14:57, François Dumont via Libstdc++
 wrote:

Following confirmation of the fix by TC here is the patch where I'm
simply adding a 'constexpr' on _M_next().

Please let me know this ChangeLog entry is correct. I would prefer this
patch to be assigned to 'TC' with me as co-author but I don't know how
to do such a thing. Unless I need to change my user git identity to do so ?

Sam already explained that, but please check with Tim how he wants to
be credited, if at all. He doesn't have a copyright assignment, and
hasn't added a DCO sign-off to the patch, but it's small enough to not
need it as this is the first contribution credited to him.



  libstdc++: Add constexpr qualification to _Hash_node::_M_next()

What has this constexpr addition got to do with the ABI change and the
always_inline attributes?

It certainly doesn't seem like it should be the summary line of the
git commit message.


Oops, sorry, that's what I had started to do before Tim submitted anything.

Here is latest version:

Author: TC 
Date:   Wed Sep 6 19:31:55 2023 +0200

    libstdc++: Force inline on _Hash_node_value_base methods to fix abi 
(PR111050)


https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1b6f0476837205932613ddb2b3429a55c26c409d
    changed _Hash_node_value_base to no longer derive from 
_Hash_node_base, which means
    that its member functions expect _M_storage to be at a different 
offset. So explosions
    result if an out-of-line definition is emitted for any of the 
member functions (say,
    in a non-optimized build) and the resulting object file is then 
linked with code built

    using older version of GCC/libstdc++.

    libstdc++-v3/ChangeLog:

    PR libstdc++/111050
    * include/bits/hashtable_policy.h
    (_Hash_node_value_base<>::_M_valptr(), 
_Hash_node_value_base<>::_M_v())

    Add [[__gnu__::__always_inline__]].
    (_Hash_node<>::_M_next()): Add constexpr.

    Co-authored-by: François Dumont 

Ok for you TC (Tim ?) ?




[PATCH 1/2] c++: Implement __is_member_function_pointer built-in trait

2023-09-11 Thread Ken Matsui via Gcc-patches
This patch implements built-in trait for
std::is_member_function_pointer.

gcc/cp/ChangeLog:

* cp-trait.def (IS_MEMBER_FUNCTION_POINTER): Define
__is_member_function_pointer.
* constraint.cc (diagnose_trait_expr): Handle
CPTK_IS_MEMBER_FUNCTION_POINTER.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/ext/has-builtin-1.C: Test existence of
is_member_function_pointer.
* g++.dg/ext/is_member_function_pointer.C: New test.

Signed-off-by: Ken Matsui 
---
 gcc/cp/constraint.cc  |  3 ++
 gcc/cp/cp-trait.def   |  1 +
 gcc/cp/semantics.cc   |  4 +++
 gcc/testsuite/g++.dg/ext/has-builtin-1.C  |  3 ++
 .../g++.dg/ext/is_member_function_pointer.C   | 31 +++
 5 files changed, 42 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/ext/is_member_function_pointer.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index c9e4e7043cd..e366095c47e 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -3757,6 +3757,9 @@ diagnose_trait_expr (tree expr, tree args)
 case CPTK_IS_TRIVIALLY_COPYABLE:
   inform (loc, "  %qT is not trivially copyable", t1);
   break;
+case CPTK_IS_MEMBER_FUNCTION_POINTER:
+  inform (loc, "  %qT is not a member function pointer", t1);
+  break;
 case CPTK_IS_ASSIGNABLE:
   inform (loc, "  %qT is not assignable from %qT", t1, t2);
   break;
diff --git a/gcc/cp/cp-trait.def b/gcc/cp/cp-trait.def
index 8b7fece0cc8..47e6f3d5541 100644
--- a/gcc/cp/cp-trait.def
+++ b/gcc/cp/cp-trait.def
@@ -72,6 +72,7 @@ DEFTRAIT_EXPR (IS_LITERAL_TYPE, "__is_literal_type", 1)
 DEFTRAIT_EXPR (IS_NOTHROW_ASSIGNABLE, "__is_nothrow_assignable", 2)
 DEFTRAIT_EXPR (IS_NOTHROW_CONSTRUCTIBLE, "__is_nothrow_constructible", -1)
 DEFTRAIT_EXPR (IS_NOTHROW_CONVERTIBLE, "__is_nothrow_convertible", 2)
+DEFTRAIT_EXPR (IS_MEMBER_FUNCTION_POINTER, "__is_member_function_pointer", 1)
 DEFTRAIT_EXPR (IS_POINTER_INTERCONVERTIBLE_BASE_OF, 
"__is_pointer_interconvertible_base_of", 2)
 DEFTRAIT_EXPR (IS_POD, "__is_pod", 1)
 DEFTRAIT_EXPR (IS_POLYMORPHIC, "__is_polymorphic", 1)
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 0f7f4e87ae4..d47db9a70aa 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -12193,6 +12193,9 @@ trait_expr_value (cp_trait_kind kind, tree type1, tree 
type2)
 case CPTK_IS_NOTHROW_CONSTRUCTIBLE:
   return is_nothrow_xible (INIT_EXPR, type1, type2);
 
+case CPTK_IS_MEMBER_FUNCTION_POINTER:
+  return TYPE_PTRMEMFUNC_P (type1);
+
 case CPTK_IS_CONVERTIBLE:
   return is_convertible (type1, type2);
 
@@ -12359,6 +12362,7 @@ finish_trait_expr (location_t loc, cp_trait_kind kind, 
tree type1, tree type2)
 case CPTK_IS_ENUM:
 case CPTK_IS_UNION:
 case CPTK_IS_SAME:
+case CPTK_IS_MEMBER_FUNCTION_POINTER:
   break;
 
 case CPTK_IS_LAYOUT_COMPATIBLE:
diff --git a/gcc/testsuite/g++.dg/ext/has-builtin-1.C 
b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
index f343e153e56..2385a475344 100644
--- a/gcc/testsuite/g++.dg/ext/has-builtin-1.C
+++ b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
@@ -146,3 +146,6 @@
 #if !__has_builtin (__remove_cvref)
 # error "__has_builtin (__remove_cvref) failed"
 #endif
+#if !__has_builtin (__is_member_function_pointer)
+# error "__has_builtin (__is_member_function_pointer) failed"
+#endif
diff --git a/gcc/testsuite/g++.dg/ext/is_member_function_pointer.C 
b/gcc/testsuite/g++.dg/ext/is_member_function_pointer.C
new file mode 100644
index 000..555123e8f07
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/is_member_function_pointer.C
@@ -0,0 +1,31 @@
+// { dg-do compile { target c++11 } }
+
+#include 
+
+using namespace __gnu_test;
+
+#define SA(X) static_assert((X),#X)
+
+#define SA_TEST_FN(TRAIT, TYPE, EXPECT)\
+  SA(TRAIT(TYPE) == EXPECT);   \
+  SA(TRAIT(const TYPE) == EXPECT);
+
+#define SA_TEST_CATEGORY(TRAIT, TYPE, EXPECT)  \
+  SA(TRAIT(TYPE) == EXPECT);   \
+  SA(TRAIT(const TYPE) == EXPECT); \
+  SA(TRAIT(volatile TYPE) == EXPECT);  \
+  SA(TRAIT(const volatile TYPE) == EXPECT)
+
+// Positive tests.
+SA_TEST_FN(__is_member_function_pointer, int (ClassType::*) (int), true);
+SA_TEST_FN(__is_member_function_pointer, int (ClassType::*) (int) const, true);
+SA_TEST_FN(__is_member_function_pointer, int (ClassType::*) (float, ...), 
true);
+SA_TEST_FN(__is_member_function_pointer, ClassType (ClassType::*) (ClassType), 
true);
+SA_TEST_FN(__is_member_function_pointer, float (ClassType::*) (int, float, 
int[], int&), true);
+
+// Negative tests.
+SA_TEST_CATEGORY(__is_member_function_pointer, int (ClassType::*), false);
+SA_TEST_CATEGORY(__is_member_function_pointer, ClassType (ClassType::*), 
false);
+
+// Sanity check.

[PATCH 2/2] libstdc++: Optimize is_member_function_pointer trait performance

2023-09-11 Thread Ken Matsui via Gcc-patches
This patch optimizes the performance of the is_member_function_pointer trait
by dispatching to the new __is_member_function_pointer built-in trait.

libstdc++-v3/ChangeLog:

* include/std/type_traits (is_member_function_pointer): Use
__is_member_function_pointer built-in trait.
(is_member_function_pointer_v): Likewise.

Signed-off-by: Ken Matsui 
---
 libstdc++-v3/include/std/type_traits | 16 
 1 file changed, 16 insertions(+)

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index 677cd934b94..98aeb104653 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -581,6 +581,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 : public __is_member_object_pointer_helper<__remove_cv_t<_Tp>>::type
 { };
 
+#if _GLIBCXX_USE_BUILTIN_TRAIT(__is_member_function_pointer)
+  /// is_member_function_pointer
+  template
+struct is_member_function_pointer
+: public __bool_constant<__is_member_function_pointer(_Tp)>
+{ };
+#else
   template
 struct __is_member_function_pointer_helper
 : public false_type { };
@@ -594,6 +601,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 struct is_member_function_pointer
 : public __is_member_function_pointer_helper<__remove_cv_t<_Tp>>::type
 { };
+#endif
 
   /// is_enum
   template
@@ -3189,9 +3197,17 @@ template 
 template 
   inline constexpr bool is_member_object_pointer_v =
 is_member_object_pointer<_Tp>::value;
+
+#if _GLIBCXX_USE_BUILTIN_TRAIT(__is_member_function_pointer)
+template 
+  inline constexpr bool is_member_function_pointer_v =
+__is_member_function_pointer(_Tp);
+#else
 template 
   inline constexpr bool is_member_function_pointer_v =
 is_member_function_pointer<_Tp>::value;
+#endif
+
 template 
   inline constexpr bool is_enum_v = __is_enum(_Tp);
 template 
-- 
2.42.0



[PATCH 0/2] Optimize is_member_function_pointer trait performance

2023-09-11 Thread Ken Matsui via Gcc-patches
This patch series optimizes is_member_function_pointer trait
performance. The first patch implements __is_member_function_pointer
built-in trait. The second patch optimizes is_member_function_pointer
trait performance by using __is_member_function_pointer built-in trait
if available.

The performance improvement is shown in the following benchmark:

https://github.com/ken-matsui/gsoc23/blob/main/is_member_function_pointer_v.md#mon-sep-11-095601-am-pdt-2023

Time: -35.1125%
Peak Memory Usage: -25.783%
Total Memory Usage: -27.9437%

Sincerely,
Ken Matsui

Ken Matsui (2):
  c++: Implement __is_member_function_pointer built-in trait
  libstdc++: Optimize is_member_function_pointer trait performance

 gcc/cp/constraint.cc  |  3 ++
 gcc/cp/cp-trait.def   |  1 +
 gcc/cp/semantics.cc   |  4 +++
 gcc/testsuite/g++.dg/ext/has-builtin-1.C  |  3 ++
 .../g++.dg/ext/is_member_function_pointer.C   | 31 +++
 libstdc++-v3/include/std/type_traits  | 16 ++
 6 files changed, 58 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/ext/is_member_function_pointer.C

-- 
2.42.0



Re: [PATCH] analyzer: Move gcc.dg/analyzer tests to c-c++-common (2) [PR96395]

2023-09-11 Thread Benjamin Priour via Gcc-patches
Hi Christophe,

On Mon, Sep 11, 2023 at 4:23 PM Christophe Lyon 
wrote:

> Hi!
>
>
> On Wed, 6 Sept 2023 at 22:22, David Malcolm via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
>> On Wed, 2023-09-06 at 15:50 +0200, Benjamin Priour wrote:
>> > Hi David,
>> > Thanks for the review.
>> >
>> >
>> >
>> > On Tue, Sep 5, 2023 at 1:53 PM David Malcolm 
>> > wrote:
>> >
>> > > On Mon, 2023-09-04 at 20:00 +0200, priour...@gmail.com wrote:
>> > >
>> > >
>> > [...snip...]
>> >
>> >
>> > > All of these "new" tests (apart from the "-noexcept" ones) look
>> > > like
>> > > they're meant to be existing tests that were moved, but where the
>> > > copy
>> > > of the test in gcc.dg/analyzer didn't get deleted, so they show up
>> > > as a
>> > > duplicate.  See the details below.
>> > >
>> >
>> > > >   * c-c++-common/analyzer/file-pr58237-noexcept.c: New test.
>> > >
>> > > When duplicating a test like this, the test isn't entirely "new",
>> > > so
>> > > please say something like this in the ChangeLog entry, to make it
>> > > clear
>> > > where it came from:
>> > >
>> > >
>> > I actually wasn't sure about these -noexcept tests. They were part
>> > of gcc.dg/analyzer, thus only gcc was running them. Exceptions
>> > were not disabled *explicitly*, but since it was C, they weren't
>> > enabled
>> > either.
>> >
>> > Therefore, the -noexcept tests are basically a copy, but with an
>> > explicit
>> > -fno-exceptions specification.
>> > When I duplicated them in that way I was thinking about making it
>> > clear
>> > that these tests fail in C++ with exceptions enabled, so that we
>> > would
>> > already
>> > have easy-to-spot failing tests to challenge a future exception
>> > support.
>>
>> Ah, OK; let's go with your approach.
>>
>> >
>> > Though perhaps *not* duplicating the tests but rather simply specify
>> > -fno-exceptions,
>> > with a comment "Fails with exceptions" may be better.
>>
>> [...snip...]
>>
>> > > > @@ -45,7 +45,7 @@ void test(int n)
>> > > >struct iter *it = iter_new (0, n, 1);
>> > > >while (!iter_done_p (it))
>> > > >  {
>> > > > -  __analyzer_eval (it->val < n); /* { dg-warning "TRUE"
>> > > > "true" {
>> > > xfail *-*-* } } */
>> > > > +  __analyzer_eval (it->val < n); /* { dg-warning "TRUE"
>> > > > "true" } */
>> > > >/* { dg-bogus "UNKNOWN" "unknown" { xfail *-*-* } .-1 } */
>> > > >/* TODO(xfail^^^): ideally we ought to figure out i > 0
>> > > > after 1st
>> > > iteration.  */
>> > > >
>> > >
>> > > Presumably due to the change to
>> > > region_model::add_constraints_from_binop, right?
>> > > Looking at that dg-bogus "UNKNOWN", do we still get an UNKNOWN
>> > > here, or
>> > > can that line be removed?
>> > > If so, then the 3rd comment can presumably become:
>> > >
>> > >
>> > The bogus here still make sense - without it there is an excess error
>> > -.
>> > I had checked for it because I too thought it could be removed.
>> > If I remember it correctly, we get UNKNOWN during the widening pass.
>>
>> (nods)
>>
>> >
>> >
>> > > >/* TODO: ideally we ought to figure out i > 0 after 1st
>> > > iteration.  */
>> > >
>> > > [...snip...]
>> > >
>> > >
>> > >
>> > [...snip...]
>> >
>> > Thanks for spotting the files I forgot to remove from gcc.dg.
>> > Sorry about them, I had messed up my test folder when checking for
>> > arm-eabi,
>> > and I apparently missed some duplicates when retrieving my save.
>> >
>> > As for the files the likes of inlining-*.c, i.e. noted as Moved
>> > to/...here.
>> > at the end of the ChangeLog, some tests checking for multiline
>> > outputs
>> > are so heavily rewritten than git marks them as Removed/New test
>> > instead of moved. I've manually edited that, but perhaps I shouldn't
>> > ?
>> >
>> > I have successfully regstrapped the improvements you suggested.
>>
>> Thanks.  Did you want me to doublecheck the updated patch?  Otherwise
>> feel free to push it to trunk.
>>
>> Was this patch committed as  r14-3823-g50b5199cff6908?
>
>
Indeed.


> Our CI noticed regression after that revision, on arm-eabi.
> I looked at the logs for out-of-bounds-diagram-11.c, where we have:
> FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c expected multiline
> pattern lines 46-61
> FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c 2 blank line(s) in
> output
> FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c (test for excess
> errors)
>
> After visual inspection, I noticed that we emit:
> write of '(int32_t) 42'
> but expect:
> write of '(int) 42'
> (that is, we emit 'int32_t' and expect 'int')
>
> I didn't check all the regressions, but does that ring a bell?
>
> Thanks,
>
> Christophe
>
>
Thanks for spotting that.
I checked the diff of the aforementioned patch. The variable type has not
been changed
nor the expected multiline-output.

Do you observe the regression in C and/or C++ ?

Thanks,
Benjamin.


[PATCH 11/13] libstdc++: Remove dg-options "-std=gnu++23" from remaining tests

2023-09-11 Thread Jonathan Wakely via Gcc-patches
The testsuite will automatically select C++23 for these tests now, and
removing the hardcoded -std option allows them to be tested for C++26
as well.

libstdc++-v3/ChangeLog:

* testsuite/18_support/headers/limits/synopsis_cxx23.cc: Remove
dg-options.
* testsuite/18_support/headers/stdfloat/types_std.cc: Likewise.
* testsuite/18_support/type_info/constexpr.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/current.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/entry.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/stacktrace.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/synopsis.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/version.cc: Likewise.
* testsuite/20_util/aligned_storage/deprecated-2b.cc: Likewise.
* testsuite/20_util/aligned_union/deprecated-2b.cc: Likewise.
* testsuite/20_util/bitset/access/constexpr.cc: Likewise.
* testsuite/20_util/bitset/cons/constexpr_c++23.cc: Likewise.
* testsuite/20_util/bitset/count/constexpr.cc: Likewise.
* testsuite/20_util/bitset/ext/constexpr.cc: Likewise.
* testsuite/20_util/bitset/operations/constexpr_c++23.cc:
Likewise.
* testsuite/20_util/bitset/version.cc: Likewise.
* testsuite/20_util/from_chars/8.cc: Likewise.
* testsuite/20_util/from_chars/constexpr.cc: Likewise.
* testsuite/20_util/function/cons/deduction_c++23.cc: Likewise.
* testsuite/20_util/function_objects/invoke/4.cc: Likewise.
* testsuite/20_util/function_objects/invoke/dangling_ref.cc:
Likewise.
* testsuite/20_util/is_scoped_enum/value.cc: Likewise.
* testsuite/20_util/is_scoped_enum/version.cc: Likewise.
* testsuite/20_util/move_only_function/call.cc: Likewise.
* testsuite/20_util/move_only_function/cons.cc: Likewise.
* testsuite/20_util/move_only_function/move.cc: Likewise.
* testsuite/20_util/move_only_function/version.cc: Likewise.
* testsuite/20_util/optional/monadic/and_then.cc: Likewise.
* testsuite/20_util/optional/monadic/or_else.cc: Likewise.
* testsuite/20_util/optional/monadic/or_else_neg.cc: Likewise.
* testsuite/20_util/optional/monadic/pr109242.cc: Likewise.
* testsuite/20_util/optional/monadic/transform.cc: Likewise.
* testsuite/20_util/pair/p2321r2.cc: Likewise.
* testsuite/20_util/reference_from_temporary/value.cc: Likewise.
* testsuite/20_util/reference_from_temporary/value2.cc:
Likewise.
* testsuite/20_util/reference_from_temporary/version.cc:
Likewise.
* testsuite/20_util/to_chars/constexpr.cc: Likewise.
* testsuite/20_util/to_chars/float128_c++23.cc: Likewise.
* testsuite/20_util/to_chars/float16_c++23.cc: Likewise.
* testsuite/20_util/to_chars/version.cc: Likewise.
* testsuite/20_util/to_underlying/1.cc: Likewise.
* testsuite/20_util/to_underlying/version.cc: Likewise.
* testsuite/20_util/tuple/p2321r2.cc: Likewise.
* testsuite/20_util/unique_ptr/assign/constexpr.cc: Likewise.
* testsuite/20_util/unique_ptr/comparison/constexpr.cc:
Likewise.
* testsuite/20_util/unique_ptr/cons/constexpr_c++20.cc:
Likewise.
* testsuite/20_util/unique_ptr/creation/constexpr.cc: Likewise.
* testsuite/20_util/unique_ptr/modifiers/constexpr.cc: Likewise.
* testsuite/20_util/unique_ptr/specialized_algorithms/constexpr.cc: 
Likewise.
* testsuite/20_util/unreachable/1.cc: Likewise.
* testsuite/20_util/unreachable/version.cc: Likewise.
* testsuite/20_util/uses_allocator/lwg3677.cc: Likewise.
* 
testsuite/21_strings/basic_string/capacity/char/resize_and_overwrite.cc: 
Likewise.
* testsuite/21_strings/basic_string/operations/contains/char.cc:
Likewise.
* testsuite/21_strings/basic_string/operations/contains/nonnull.cc: 
Likewise.
* testsuite/21_strings/basic_string/operations/contains/wchar_t.cc: 
Likewise.
* testsuite/21_strings/basic_string_view/cons/char/range_c++20.cc: 
Likewise.
* testsuite/21_strings/basic_string_view/cons/wchar_t/range_c++20.cc: 
Likewise.
* testsuite/21_strings/basic_string_view/operations/contains/char.cc: 
Likewise.
* testsuite/21_strings/basic_string_view/operations/contains/char/2.cc: 
Likewise.
* 
testsuite/21_strings/basic_string_view/operations/contains/nonnull.cc: Likewise.
* 
testsuite/21_strings/basic_string_view/operations/contains/wchar_t.cc: Likewise.
* testsuite/23_containers/queue/cons_from_iters.cc: Likewise.
* testsuite/23_containers/stack/cons_from_iters.cc: Likewise.
* testsuite/23_containers/vector/bool/element_access/1.cc:
Likewise.
* testsuite/24_iterators/const_iterator/1.cc: Likewise.
* testsuite/25_algorithms/contains/1.cc: Likewise.

[PATCH 10/13] libstdc++: Remove dg-options "-std=gnu++23" from std::expected tests

2023-09-11 Thread Jonathan Wakely via Gcc-patches
The testsuite will automatically select C++23 for these tests now, and
removing the hardcoded -std option allows them to be tested for C++26
as well.

libstdc++-v3/ChangeLog:

* testsuite/20_util/expected/assign.cc: Remove dg-options.
* testsuite/20_util/expected/bad.cc: Likewise.
* testsuite/20_util/expected/cons.cc: Likewise.
* testsuite/20_util/expected/equality.cc: Likewise.
* testsuite/20_util/expected/illformed_neg.cc: Likewise.
* testsuite/20_util/expected/lwg3877.cc: Likewise.
* testsuite/20_util/expected/lwg3938.cc: Likewise.
* testsuite/20_util/expected/monadic.cc: Likewise.
* testsuite/20_util/expected/observers.cc: Likewise.
* testsuite/20_util/expected/requirements.cc: Likewise.
* testsuite/20_util/expected/swap.cc: Likewise.
* testsuite/20_util/expected/synopsis.cc: Likewise.
* testsuite/20_util/expected/unexpected.cc: Likewise.
* testsuite/20_util/expected/version.cc: Likewise.
---
 libstdc++-v3/testsuite/20_util/expected/assign.cc| 1 -
 libstdc++-v3/testsuite/20_util/expected/bad.cc   | 1 -
 libstdc++-v3/testsuite/20_util/expected/cons.cc  | 1 -
 libstdc++-v3/testsuite/20_util/expected/equality.cc  | 1 -
 libstdc++-v3/testsuite/20_util/expected/illformed_neg.cc | 1 -
 libstdc++-v3/testsuite/20_util/expected/lwg3877.cc   | 1 -
 libstdc++-v3/testsuite/20_util/expected/lwg3938.cc   | 1 -
 libstdc++-v3/testsuite/20_util/expected/monadic.cc   | 1 -
 libstdc++-v3/testsuite/20_util/expected/observers.cc | 1 -
 libstdc++-v3/testsuite/20_util/expected/requirements.cc  | 1 -
 libstdc++-v3/testsuite/20_util/expected/swap.cc  | 1 -
 libstdc++-v3/testsuite/20_util/expected/synopsis.cc  | 1 -
 libstdc++-v3/testsuite/20_util/expected/unexpected.cc| 1 -
 libstdc++-v3/testsuite/20_util/expected/version.cc   | 1 -
 14 files changed, 14 deletions(-)

diff --git a/libstdc++-v3/testsuite/20_util/expected/assign.cc 
b/libstdc++-v3/testsuite/20_util/expected/assign.cc
index bbf5b900f4c..73f5cbcbfcd 100644
--- a/libstdc++-v3/testsuite/20_util/expected/assign.cc
+++ b/libstdc++-v3/testsuite/20_util/expected/assign.cc
@@ -1,4 +1,3 @@
-// { dg-options "-std=gnu++23" }
 // { dg-do run { target c++23 } }
 
 #include 
diff --git a/libstdc++-v3/testsuite/20_util/expected/bad.cc 
b/libstdc++-v3/testsuite/20_util/expected/bad.cc
index e5d7ba4afb0..c629e149da5 100644
--- a/libstdc++-v3/testsuite/20_util/expected/bad.cc
+++ b/libstdc++-v3/testsuite/20_util/expected/bad.cc
@@ -1,4 +1,3 @@
-// { dg-options "-std=gnu++23" }
 // { dg-do compile { target c++23 } }
 
 #include 
diff --git a/libstdc++-v3/testsuite/20_util/expected/cons.cc 
b/libstdc++-v3/testsuite/20_util/expected/cons.cc
index 6946858198c..683174e98df 100644
--- a/libstdc++-v3/testsuite/20_util/expected/cons.cc
+++ b/libstdc++-v3/testsuite/20_util/expected/cons.cc
@@ -1,4 +1,3 @@
-// { dg-options "-std=gnu++23" }
 // { dg-do run { target c++23 } }
 
 #include 
diff --git a/libstdc++-v3/testsuite/20_util/expected/equality.cc 
b/libstdc++-v3/testsuite/20_util/expected/equality.cc
index 1862719e73d..db19b1510a7 100644
--- a/libstdc++-v3/testsuite/20_util/expected/equality.cc
+++ b/libstdc++-v3/testsuite/20_util/expected/equality.cc
@@ -1,4 +1,3 @@
-// { dg-options "-std=gnu++23" }
 // { dg-do compile { target c++23 } }
 
 #include 
diff --git a/libstdc++-v3/testsuite/20_util/expected/illformed_neg.cc 
b/libstdc++-v3/testsuite/20_util/expected/illformed_neg.cc
index f1b0771aeb9..69c13b48a22 100644
--- a/libstdc++-v3/testsuite/20_util/expected/illformed_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/expected/illformed_neg.cc
@@ -1,4 +1,3 @@
-// { dg-options "-std=gnu++23" }
 // { dg-do compile { target c++23 } }
 
 #include 
diff --git a/libstdc++-v3/testsuite/20_util/expected/lwg3877.cc 
b/libstdc++-v3/testsuite/20_util/expected/lwg3877.cc
index 876275bfdb0..1854f5102c6 100644
--- a/libstdc++-v3/testsuite/20_util/expected/lwg3877.cc
+++ b/libstdc++-v3/testsuite/20_util/expected/lwg3877.cc
@@ -1,4 +1,3 @@
-// { dg-options "-std=gnu++23" }
 // { dg-do compile { target c++23 } }
 
 // LWG 3877. Incorrect constraints on const-qualified monadic overloads
diff --git a/libstdc++-v3/testsuite/20_util/expected/lwg3938.cc 
b/libstdc++-v3/testsuite/20_util/expected/lwg3938.cc
index c7e3758a902..3aa2b9d9273 100644
--- a/libstdc++-v3/testsuite/20_util/expected/lwg3938.cc
+++ b/libstdc++-v3/testsuite/20_util/expected/lwg3938.cc
@@ -1,4 +1,3 @@
-// { dg-options "-std=gnu++23" }
 // { dg-do compile { target c++23 } }
 
 // LWG 3938. Cannot use std::expected monadic ops with move-only error_type
diff --git a/libstdc++-v3/testsuite/20_util/expected/monadic.cc 
b/libstdc++-v3/testsuite/20_util/expected/monadic.cc
index d82774b0e1f..40f4907ea88 100644
--- a/libstdc++-v3/testsuite/20_util/expected/monadic.cc
+++ b/libstdc++-v3/testsuite/20_util/expected/monadic.cc
@@ -1,4 +1,3 @@
-// { dg-options "-std=gnu++23" }
 // 

RISC-V: Replace not + bitwise_imm with li + bitwise_not

2023-09-11 Thread Jivan Hakobyan via Gcc-patches
In the case when we have C code like this

int foo (int a) {
   return 100 & ~a;
}

GCC generates the following instruction sequence

foo:
 not a0,a0
 andia0,a0,100
 ret

This patch replaces that with this sequence
foo:
 li a5,100
 andn a0,a5,a0
 ret

The profitability comes from an out-of-order processor being able to
issue the "li a5, 100" at any time after it's fetched while "not a0, a0" has
to wait until any prior setter of a0 has reached completion.


gcc/ChangeLog:
* config/riscv/bitmanip.md (*_not_const): New split
pattern.

gcc/testsuite/ChangeLog:
* gcc.target/riscv/zbb-andn-orn-01.c: New test.
* gcc.target/riscv/zbb-andn-orn-02.c: Likewise.


-- 
With the best regards
Jivan Hakobyan
diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index 7b55528ee49..209b0afb118 100644
--- a/gcc/config/riscv/bitmanip.md
+++ b/gcc/config/riscv/bitmanip.md
@@ -215,6 +215,17 @@ (define_insn "*_not"
   [(set_attr "type" "bitmanip")
(set_attr "mode" "")])
 
+(define_insn_and_split "*_not_const"
+  [(set (match_operand:X 0 "register_operand" "=r")
+   (bitmanip_bitwise:X (not:X (match_operand:X 1 "register_operand" "r"))
+  (match_operand:X 2 "const_arith_operand" "I")))
+  (clobber (match_scratch:X 3 "="))]
+  "TARGET_ZBB || TARGET_ZBKB"
+  "#"
+  "&& reload_completed"
+  [(set (match_dup 3) (match_dup 2))
+   (set (match_dup 0) (bitmanip_bitwise:X (not:X (match_dup 1)) (match_dup 3)))])
+
 ;; '(a >= 0) ? b : 0' is emitted branchless (from if-conversion).  Without a
 ;; bit of extra help for combine (i.e., the below split), we end up emitting
 ;; not/srai/and instead of combining the not into an andn.
diff --git a/gcc/testsuite/gcc.target/riscv/zbb-andn-orn-01.c b/gcc/testsuite/gcc.target/riscv/zbb-andn-orn-01.c
new file mode 100644
index 000..e1c33885913
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/zbb-andn-orn-01.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_zbb -mabi=lp64" } */
+/* { dg-skip-if "" { *-*-* } { "-O0" "-g" } } */
+
+int foo1(int rs1)
+{
+return 100 & ~rs1;
+}
+
+int foo2(int rs1)
+{
+return 100 | ~rs1;
+}
+
+/* { dg-final { scan-assembler-times "andn\t" 1 } } */
+/* { dg-final { scan-assembler-times "orn\t" 1 } } */
+/* { dg-final { scan-assembler-times "li\t" 2 } } */
diff --git a/gcc/testsuite/gcc.target/riscv/zbb-andn-orn-02.c b/gcc/testsuite/gcc.target/riscv/zbb-andn-orn-02.c
new file mode 100644
index 000..b51950cdb7d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/zbb-andn-orn-02.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv32gc_zbb -mabi=ilp32" } */
+/* { dg-skip-if "" { *-*-* } { "-O0" "-g" } } */
+
+int foo1(int rs1)
+{
+return 100 & ~rs1;
+}
+
+int foo2(int rs1)
+{
+return 100 | ~rs1;
+}
+
+/* { dg-final { scan-assembler-times "andn\t" 1 } } */
+/* { dg-final { scan-assembler-times "orn\t" 1 } } */
+/* { dg-final { scan-assembler-times "li\t" 2 } } */


[PATCH 08/13] libstdc++: Remove dg-options "-std=gnu++20" from std::format tests

2023-09-11 Thread Jonathan Wakely via Gcc-patches
The testsuite will automatically select C++20 for these tests now, and
removing the hardcoded -std option allows them to be tested for C++23
and C++26 as well.

libstdc++-v3/ChangeLog:

* testsuite/std/format/arguments/args.cc: Remove dg-options.
* testsuite/std/format/arguments/lwg3810.cc: Likewise. Likewise.
* testsuite/std/format/error.cc: Likewise.
* testsuite/std/format/format_string.cc: Likewise.
* testsuite/std/format/formatter/concept.cc: Likewise.
* testsuite/std/format/formatter/ext_float.cc: Likewise.
* testsuite/std/format/formatter/requirements.cc: Likewise.
* testsuite/std/format/functions/107871.cc: Likewise.
* testsuite/std/format/functions/format.cc: Likewise.
* testsuite/std/format/functions/format_to.cc: Likewise.
* testsuite/std/format/functions/format_to_n.cc: Likewise.
* testsuite/std/format/functions/size.cc: Likewise.
* testsuite/std/format/functions/vformat_to.cc: Likewise.
* testsuite/std/format/parse_ctx.cc: Likewise.
* testsuite/std/format/string.cc: Likewise.
* testsuite/std/format/string_neg.cc: Likewise.
* testsuite/std/format/functions/format_c++23.cc: Removed.
---
 libstdc++-v3/testsuite/std/format/arguments/args.cc | 1 -
 libstdc++-v3/testsuite/std/format/arguments/lwg3810.cc  | 1 -
 libstdc++-v3/testsuite/std/format/error.cc  | 1 -
 libstdc++-v3/testsuite/std/format/format_string.cc  | 1 -
 libstdc++-v3/testsuite/std/format/formatter/concept.cc  | 1 -
 libstdc++-v3/testsuite/std/format/formatter/ext_float.cc| 1 -
 libstdc++-v3/testsuite/std/format/formatter/requirements.cc | 1 -
 libstdc++-v3/testsuite/std/format/functions/107871.cc   | 1 -
 libstdc++-v3/testsuite/std/format/functions/format.cc   | 1 -
 libstdc++-v3/testsuite/std/format/functions/format_c++23.cc | 5 -
 libstdc++-v3/testsuite/std/format/functions/format_to.cc| 1 -
 libstdc++-v3/testsuite/std/format/functions/format_to_n.cc  | 1 -
 libstdc++-v3/testsuite/std/format/functions/size.cc | 1 -
 libstdc++-v3/testsuite/std/format/functions/vformat_to.cc   | 1 -
 libstdc++-v3/testsuite/std/format/parse_ctx.cc  | 1 -
 libstdc++-v3/testsuite/std/format/string.cc | 1 -
 libstdc++-v3/testsuite/std/format/string_neg.cc | 1 -
 17 files changed, 21 deletions(-)
 delete mode 100644 libstdc++-v3/testsuite/std/format/functions/format_c++23.cc

diff --git a/libstdc++-v3/testsuite/std/format/arguments/args.cc 
b/libstdc++-v3/testsuite/std/format/arguments/args.cc
index ae2eab6d560..a45f3fb24df 100644
--- a/libstdc++-v3/testsuite/std/format/arguments/args.cc
+++ b/libstdc++-v3/testsuite/std/format/arguments/args.cc
@@ -1,4 +1,3 @@
-// { dg-options "-std=gnu++20" }
 // { dg-do run { target c++20 } }
 
 #include 
diff --git a/libstdc++-v3/testsuite/std/format/arguments/lwg3810.cc 
b/libstdc++-v3/testsuite/std/format/arguments/lwg3810.cc
index 9ccb654de1b..f89f40203cb 100644
--- a/libstdc++-v3/testsuite/std/format/arguments/lwg3810.cc
+++ b/libstdc++-v3/testsuite/std/format/arguments/lwg3810.cc
@@ -1,4 +1,3 @@
-// { dg-options "-std=gnu++20" }
 // { dg-do compile { target c++20 } }
 
 // LWG 3810. CTAD for std::basic_format_args
diff --git a/libstdc++-v3/testsuite/std/format/error.cc 
b/libstdc++-v3/testsuite/std/format/error.cc
index a6918f5ab2e..878f60e0ec9 100644
--- a/libstdc++-v3/testsuite/std/format/error.cc
+++ b/libstdc++-v3/testsuite/std/format/error.cc
@@ -1,4 +1,3 @@
-// { dg-options "-std=gnu++20" }
 // { dg-do run { target c++20 } }
 
 #include 
diff --git a/libstdc++-v3/testsuite/std/format/format_string.cc 
b/libstdc++-v3/testsuite/std/format/format_string.cc
index 1dd6ca8f125..71c3d5d68f6 100644
--- a/libstdc++-v3/testsuite/std/format/format_string.cc
+++ b/libstdc++-v3/testsuite/std/format/format_string.cc
@@ -1,4 +1,3 @@
-// { dg-options "-std=gnu++20" }
 // { dg-do compile { target c++20 } }
 
 #include 
diff --git a/libstdc++-v3/testsuite/std/format/formatter/concept.cc 
b/libstdc++-v3/testsuite/std/format/formatter/concept.cc
index fe56dc44a68..e28a8c20a87 100644
--- a/libstdc++-v3/testsuite/std/format/formatter/concept.cc
+++ b/libstdc++-v3/testsuite/std/format/formatter/concept.cc
@@ -1,4 +1,3 @@
-// { dg-options "-std=gnu++23" }
 // { dg-do compile { target c++23 } }
 
 #include 
diff --git a/libstdc++-v3/testsuite/std/format/formatter/ext_float.cc 
b/libstdc++-v3/testsuite/std/format/formatter/ext_float.cc
index 89810295b64..82e696fa797 100644
--- a/libstdc++-v3/testsuite/std/format/formatter/ext_float.cc
+++ b/libstdc++-v3/testsuite/std/format/formatter/ext_float.cc
@@ -1,4 +1,3 @@
-// { dg-options "-std=gnu++20" }
 // { dg-do run { target c++20 } }
 
 #include 
diff --git a/libstdc++-v3/testsuite/std/format/formatter/requirements.cc 
b/libstdc++-v3/testsuite/std/format/formatter/requirements.cc
index 7d95f7fafe9..bde67e586ef 100644
--- 

[PATCH 05/13] libstdc++: Remove dg-options "-std=c++20" from and tests

2023-09-11 Thread Jonathan Wakely via Gcc-patches
The testsuite will automatically select C++20 for these tests now, and
removing the hardcoded -std option allows them to be tested for C++23
and C++26 as well.

There doesn't seem to be any reason they need to use strict -std=c++20
mode, so don't add the { dg-add-options strict_std } directive, just let
them use strict or non-strict modes.

libstdc++-v3/ChangeLog:

* testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc:
Remove dg-options.
* testsuite/23_containers/span/contiguous_range_neg.cc:
Likewise.
* testsuite/23_containers/span/everything.cc: Likewise.
---
 .../testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc | 1 -
 .../testsuite/23_containers/span/contiguous_range_neg.cc   | 3 +--
 libstdc++-v3/testsuite/23_containers/span/everything.cc| 3 +--
 3 files changed, 2 insertions(+), 5 deletions(-)

diff --git 
a/libstdc++-v3/testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc 
b/libstdc++-v3/testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc
index df68fb7c82f..1964803cbd1 100644
--- a/libstdc++-v3/testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc
+++ b/libstdc++-v3/testsuite/21_strings/headers/cuchar/functions_std_cxx20.cc
@@ -1,4 +1,3 @@
-// { dg-options "-std=c++20" }
 // { dg-do compile { target c++20 } }
 
 #include 
diff --git a/libstdc++-v3/testsuite/23_containers/span/contiguous_range_neg.cc 
b/libstdc++-v3/testsuite/23_containers/span/contiguous_range_neg.cc
index d5f64922052..2ed44740a86 100644
--- a/libstdc++-v3/testsuite/23_containers/span/contiguous_range_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/span/contiguous_range_neg.cc
@@ -15,8 +15,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-options "-std=c++2a" }
-// { dg-do compile { target c++2a } }
+// { dg-do compile { target c++20 } }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/23_containers/span/everything.cc 
b/libstdc++-v3/testsuite/23_containers/span/everything.cc
index 74f943e937f..31c17346dd3 100644
--- a/libstdc++-v3/testsuite/23_containers/span/everything.cc
+++ b/libstdc++-v3/testsuite/23_containers/span/everything.cc
@@ -15,8 +15,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-options "-std=c++2a" }
-// { dg-do run { target c++2a } }
+// { dg-do run { target c++20 } }
 
 #include 
 
-- 
2.41.0



[PATCH 12/13] libstdc++: Remove dg-options "-std=gnu++2a" from XFAIL std::span tests

2023-09-11 Thread Jonathan Wakely via Gcc-patches
The testsuite will automatically select C++20 for these tests now, and
removing the hardcoded -std option allows them to be tested for C++23
and C++26 as well.

We can also combine the { dg-require-effective-target c++2a } directive
with the dg-do selector.

We need to add the no_pch options for tests that define
_GLIBCXX_ASSERTIONS in the test, otherwise the PCH is included without
that defined.

libstdc++-v3/ChangeLog:

* testsuite/23_containers/span/back_assert_neg.cc: Remove
dg-options and add effective target selector to dg-do. Add
no_pch.
* testsuite/23_containers/span/back_neg.cc: Likewise.
* testsuite/23_containers/span/cons_1_assert_neg.cc: Likewise.
* testsuite/23_containers/span/cons_2_assert_neg.cc: Likewise.
* testsuite/23_containers/span/first_2_assert_neg.cc: Likewise.
* testsuite/23_containers/span/first_assert_neg.cc: Likewise.
* testsuite/23_containers/span/first_neg.cc: Likewise.
* testsuite/23_containers/span/front_assert_neg.cc: Likewise.
* testsuite/23_containers/span/front_neg.cc: Likewise.
* testsuite/23_containers/span/index_op_assert_neg.cc: Likewise.
* testsuite/23_containers/span/index_op_neg.cc: Likewise.
* testsuite/23_containers/span/last_2_assert_neg.cc: Likewise.
* testsuite/23_containers/span/last_assert_neg.cc: Likewise.
* testsuite/23_containers/span/last_neg.cc: Likewise.
* testsuite/23_containers/span/subspan_2_assert_neg.cc:
Likewise.
* testsuite/23_containers/span/subspan_3_assert_neg.cc:
Likewise.
* testsuite/23_containers/span/subspan_4_assert_neg.cc:
Likewise.
* testsuite/23_containers/span/subspan_5_assert_neg.cc:
Likewise.
* testsuite/23_containers/span/subspan_6_assert_neg.cc:
Likewise.
* testsuite/23_containers/span/subspan_assert_neg.cc: Likewise.
* testsuite/23_containers/span/subspan_neg.cc: Likewise.
* testsuite/24_iterators/range_operations/advance_debug_neg.cc:
Likewise.
---
 libstdc++-v3/testsuite/23_containers/span/back_assert_neg.cc | 5 ++---
 libstdc++-v3/testsuite/23_containers/span/back_neg.cc| 3 +--
 .../testsuite/23_containers/span/cons_1_assert_neg.cc| 5 ++---
 .../testsuite/23_containers/span/cons_2_assert_neg.cc| 5 ++---
 .../testsuite/23_containers/span/first_2_assert_neg.cc   | 5 ++---
 .../testsuite/23_containers/span/first_assert_neg.cc | 5 ++---
 libstdc++-v3/testsuite/23_containers/span/first_neg.cc   | 3 +--
 .../testsuite/23_containers/span/front_assert_neg.cc | 5 ++---
 libstdc++-v3/testsuite/23_containers/span/front_neg.cc   | 3 +--
 .../testsuite/23_containers/span/index_op_assert_neg.cc  | 5 ++---
 libstdc++-v3/testsuite/23_containers/span/index_op_neg.cc| 3 +--
 .../testsuite/23_containers/span/last_2_assert_neg.cc| 5 ++---
 libstdc++-v3/testsuite/23_containers/span/last_assert_neg.cc | 5 ++---
 libstdc++-v3/testsuite/23_containers/span/last_neg.cc| 3 +--
 .../testsuite/23_containers/span/subspan_2_assert_neg.cc | 5 ++---
 .../testsuite/23_containers/span/subspan_3_assert_neg.cc | 5 ++---
 .../testsuite/23_containers/span/subspan_4_assert_neg.cc | 5 ++---
 .../testsuite/23_containers/span/subspan_5_assert_neg.cc | 5 ++---
 .../testsuite/23_containers/span/subspan_6_assert_neg.cc | 5 ++---
 .../testsuite/23_containers/span/subspan_assert_neg.cc   | 5 ++---
 libstdc++-v3/testsuite/23_containers/span/subspan_neg.cc | 3 +--
 .../24_iterators/range_operations/advance_debug_neg.cc   | 5 ++---
 22 files changed, 38 insertions(+), 60 deletions(-)

diff --git a/libstdc++-v3/testsuite/23_containers/span/back_assert_neg.cc 
b/libstdc++-v3/testsuite/23_containers/span/back_assert_neg.cc
index 2b4dee6df9a..b42aea3b4b4 100644
--- a/libstdc++-v3/testsuite/23_containers/span/back_assert_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/span/back_assert_neg.cc
@@ -15,9 +15,8 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-options "-std=gnu++2a" }
-// { dg-do run { xfail *-*-* } }
-// { dg-require-effective-target c++2a }
+// { dg-do run { target c++20 xfail *-*-* } }
+// { dg-add-options no_pch }
 
 #undef _GLIBCXX_ASSERTIONS
 #define _GLIBCXX_ASSERTIONS
diff --git a/libstdc++-v3/testsuite/23_containers/span/back_neg.cc 
b/libstdc++-v3/testsuite/23_containers/span/back_neg.cc
index 01083e60168..d3ea4f405f4 100644
--- a/libstdc++-v3/testsuite/23_containers/span/back_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/span/back_neg.cc
@@ -15,8 +15,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-options "-std=gnu++2a" }
-// { dg-do compile { target c++2a } }
+// { dg-do compile { target c++20 } }
 
 #include 
 
diff --git a/libstdc++-v3/testsuite/23_containers/span/cons_1_assert_neg.cc 

[PATCH 09/13] libstdc++: Remove dg-options "-std=gnu++20" from std::chrono tests

2023-09-11 Thread Jonathan Wakely via Gcc-patches
The testsuite will automatically select C++20 for these tests now, and
removing the hardcoded -std option allows them to be tested for C++23
and C++26 as well.

libstdc++-v3/ChangeLog:

* testsuite/20_util/duration/arithmetic/overflow_c++20.cc:
Remove dg-options.
* testsuite/20_util/duration/io.cc: Likewise.
* testsuite/std/time/clock/file/io.cc: Likewise.
* testsuite/std/time/clock/file/members.cc: Likewise.
* testsuite/std/time/clock/file/overview.cc: Likewise.
* testsuite/std/time/clock/gps/1.cc: Likewise.
* testsuite/std/time/clock/gps/io.cc: Likewise.
* testsuite/std/time/clock/local/io.cc: Likewise.
* testsuite/std/time/clock/system/io.cc: Likewise.
* testsuite/std/time/clock/tai/1.cc: Likewise.
* testsuite/std/time/clock/tai/io.cc: Likewise.
* testsuite/std/time/clock/utc/1.cc: Likewise.
* testsuite/std/time/clock/utc/io.cc: Likewise.
* testsuite/std/time/clock/utc/leap_second_info.cc: Likewise.
* testsuite/std/time/day/1.cc: Likewise.
* testsuite/std/time/day/io.cc: Likewise.
* testsuite/std/time/exceptions.cc: Likewise.
* testsuite/std/time/format.cc: Likewise.
* testsuite/std/time/hh_mm_ss/1.cc: Likewise.
* testsuite/std/time/hh_mm_ss/109772.cc: Likewise.
* testsuite/std/time/hh_mm_ss/io.cc: Likewise.
* testsuite/std/time/is_am/1.cc: Likewise.
* testsuite/std/time/is_pm/1.cc: Likewise.
* testsuite/std/time/make12/1.cc: Likewise.
* testsuite/std/time/make24/1.cc: Likewise.
* testsuite/std/time/month/1.cc: Likewise.
* testsuite/std/time/month/io.cc: Likewise.
* testsuite/std/time/month_day/1.cc: Likewise.
* testsuite/std/time/month_day/io.cc: Likewise.
* testsuite/std/time/month_day_last/1.cc: Likewise.
* testsuite/std/time/month_day_last/io.cc: Likewise.
* testsuite/std/time/month_weekday/1.cc: Likewise.
* testsuite/std/time/month_weekday/io.cc: Likewise.
* testsuite/std/time/month_weekday_last/1.cc: Likewise.
* testsuite/std/time/month_weekday_last/io.cc: Likewise.
* testsuite/std/time/parse.cc: Likewise.
* testsuite/std/time/syn_c++20.cc: Likewise.
* testsuite/std/time/time_zone/get_info_local.cc: Likewise.
* testsuite/std/time/time_zone/get_info_sys.cc: Likewise.
* testsuite/std/time/time_zone/requirements.cc: Likewise.
* testsuite/std/time/traits/is_clock.cc: Likewise.
* testsuite/std/time/tzdb/1.cc: Likewise.
* testsuite/std/time/tzdb/leap_seconds.cc: Likewise.
* testsuite/std/time/tzdb_list/1.cc: Likewise.
* testsuite/std/time/tzdb_list/requirements.cc: Likewise.
* testsuite/std/time/weekday/1.cc: Likewise.
* testsuite/std/time/weekday/io.cc: Likewise.
* testsuite/std/time/weekday_indexed/io.cc: Likewise.
* testsuite/std/time/weekday_last/1.cc: Likewise.
* testsuite/std/time/weekday_last/io.cc: Likewise.
* testsuite/std/time/year/1.cc: Likewise.
* testsuite/std/time/year/2.cc: Likewise.
* testsuite/std/time/year/io.cc: Likewise.
* testsuite/std/time/weekday_indexed/1.cc: Likewise.
* testsuite/std/time/year_month/1.cc: Likewise.
* testsuite/std/time/year_month/2.cc: Likewise.
* testsuite/std/time/year_month/io.cc: Likewise.
* testsuite/std/time/year_month_day/1.cc: Likewise.
* testsuite/std/time/year_month_day/2.cc: Likewise.
* testsuite/std/time/year_month_day/3.cc: Likewise.
* testsuite/std/time/year_month_day/4.cc: Likewise.
* testsuite/std/time/year_month_day/io.cc: Likewise.
* testsuite/std/time/year_month_day_last/1.cc: Likewise.
* testsuite/std/time/year_month_day_last/2.cc: Likewise.
* testsuite/std/time/year_month_day_last/io.cc: Likewise.
* testsuite/std/time/year_month_weekday/1.cc: Likewise.
* testsuite/std/time/year_month_weekday/2.cc: Likewise.
* testsuite/std/time/year_month_weekday/3.cc: Likewise.
* testsuite/std/time/year_month_weekday/io.cc: Likewise.
* testsuite/std/time/year_month_weekday_last/1.cc: Likewise.
* testsuite/std/time/year_month_weekday_last/2.cc: Likewise.
* testsuite/std/time/year_month_weekday_last/io.cc: Likewise.
* testsuite/std/time/zoned_time/1.cc: Likewise.
* testsuite/std/time/zoned_time/custom.cc: Likewise.
* testsuite/std/time/zoned_time/deduction.cc: Likewise.
* testsuite/std/time/zoned_time/io.cc: Likewise.
* testsuite/std/time/zoned_time/req_neg.cc: Likewise.
* testsuite/std/time/zoned_time/requirements.cc: Likewise.
* testsuite/std/time/zoned_traits.cc: Likewise.
---
 .../testsuite/20_util/duration/arithmetic/overflow_c++20.cc| 1 -
 libstdc++-v3/testsuite/20_util/duration/io.cc  | 1 -
 

[PATCH 02/13] libstdc++: Replace dg-options "-std=c++11" with dg-add-options strict_std

2023-09-11 Thread Jonathan Wakely via Gcc-patches
These tests can (and should) also be run for later standards, so replace
the { dg-options "-std=c++11" } with { dg-add-options strict_std } and a
target selector for c++11.

libstdc++-v3/ChangeLog:

* testsuite/23_containers/deque/48101-2_neg.cc: Replace
dg-options with target selector.
* testsuite/23_containers/forward_list/48101-2_neg.cc: Likewise.
* testsuite/23_containers/list/48101-2_neg.cc: Likewise.
* testsuite/23_containers/map/48101-2_neg.cc: Likewise.
* testsuite/23_containers/map/48101_neg.cc: Likewise.
* testsuite/23_containers/multimap/48101-2_neg.cc: Likewise.
* testsuite/23_containers/multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/multiset/48101-2_neg.cc: Likewise.
* testsuite/23_containers/set/48101-2_neg.cc: Likewise.
* testsuite/23_containers/unordered_map/48101-2_neg.cc:
Likewise.
* testsuite/23_containers/unordered_multimap/48101-2_neg.cc:
Likewise.
* testsuite/23_containers/unordered_multiset/48101-2_neg.cc:
Likewise.
* testsuite/23_containers/unordered_set/48101-2_neg.cc:
Likewise.
* testsuite/23_containers/vector/48101-2_neg.cc: Likewise.
---
 libstdc++-v3/testsuite/23_containers/deque/48101-2_neg.cc | 4 ++--
 .../testsuite/23_containers/forward_list/48101-2_neg.cc   | 4 ++--
 libstdc++-v3/testsuite/23_containers/list/48101-2_neg.cc  | 4 ++--
 libstdc++-v3/testsuite/23_containers/map/48101-2_neg.cc   | 4 ++--
 libstdc++-v3/testsuite/23_containers/map/48101_neg.cc | 3 +--
 libstdc++-v3/testsuite/23_containers/multimap/48101-2_neg.cc  | 4 ++--
 libstdc++-v3/testsuite/23_containers/multimap/48101_neg.cc| 3 +--
 libstdc++-v3/testsuite/23_containers/multiset/48101-2_neg.cc  | 4 ++--
 libstdc++-v3/testsuite/23_containers/set/48101-2_neg.cc   | 4 ++--
 .../testsuite/23_containers/unordered_map/48101-2_neg.cc  | 4 ++--
 .../testsuite/23_containers/unordered_multimap/48101-2_neg.cc | 4 ++--
 .../testsuite/23_containers/unordered_multiset/48101-2_neg.cc | 4 ++--
 .../testsuite/23_containers/unordered_set/48101-2_neg.cc  | 4 ++--
 libstdc++-v3/testsuite/23_containers/vector/48101-2_neg.cc| 4 ++--
 14 files changed, 26 insertions(+), 28 deletions(-)

diff --git a/libstdc++-v3/testsuite/23_containers/deque/48101-2_neg.cc 
b/libstdc++-v3/testsuite/23_containers/deque/48101-2_neg.cc
index 041f0cb88b3..d5cb13ec4db 100644
--- a/libstdc++-v3/testsuite/23_containers/deque/48101-2_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/deque/48101-2_neg.cc
@@ -15,8 +15,8 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-do compile }
-// { dg-options "-std=c++11" }
+// { dg-do compile { target c++11 } }
+// { dg-add-options strict_std }
 
 #include 
 
diff --git a/libstdc++-v3/testsuite/23_containers/forward_list/48101-2_neg.cc 
b/libstdc++-v3/testsuite/23_containers/forward_list/48101-2_neg.cc
index 2a21876c1cf..d5cc81c6b48 100644
--- a/libstdc++-v3/testsuite/23_containers/forward_list/48101-2_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/forward_list/48101-2_neg.cc
@@ -15,8 +15,8 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-do compile }
-// { dg-options "-std=c++11" }
+// { dg-do compile { target c++11 } }
+// { dg-add-options strict_std }
 
 #include 
 
diff --git a/libstdc++-v3/testsuite/23_containers/list/48101-2_neg.cc 
b/libstdc++-v3/testsuite/23_containers/list/48101-2_neg.cc
index 0e96022cdfe..5cea21992d9 100644
--- a/libstdc++-v3/testsuite/23_containers/list/48101-2_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/list/48101-2_neg.cc
@@ -15,8 +15,8 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-do compile }
-// { dg-options "-std=c++11" }
+// { dg-do compile { target c++11 } }
+// { dg-add-options strict_std }
 
 #include 
 
diff --git a/libstdc++-v3/testsuite/23_containers/map/48101-2_neg.cc 
b/libstdc++-v3/testsuite/23_containers/map/48101-2_neg.cc
index 06c4dc9e9ef..8cda993e2cb 100644
--- a/libstdc++-v3/testsuite/23_containers/map/48101-2_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/map/48101-2_neg.cc
@@ -15,8 +15,8 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-do compile }
-// { dg-options "-std=c++11" }
+// { dg-do compile { target c++11 } }
+// { dg-add-options strict_std }
 
 #include 
 
diff --git a/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc 
b/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
index e9029caad21..81837954125 100644
--- a/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
+++ b/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
@@ -15,8 +15,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-do compile }
-// { dg-options "-std=c++11" }
+// { 

[PATCH 07/13] libstdc++: Remove dg-options "-std=gnu++2a" from constrained algo tests

2023-09-11 Thread Jonathan Wakely via Gcc-patches
The testsuite will automatically select C++20 for these tests now, and
removing the hardcoded -std option allows them to be tested for C++23
and C++26 as well.

libstdc++-v3/ChangeLog:

* testsuite/20_util/function_objects/range.cmp/equal_to.cc:
Remove dg-options.
* testsuite/20_util/function_objects/range.cmp/greater.cc:
Likewise.
* testsuite/20_util/function_objects/range.cmp/greater_equal.cc:
Likewise.
* testsuite/20_util/function_objects/range.cmp/less.cc:
Likewise.
* testsuite/20_util/function_objects/range.cmp/less_equal.cc:
Likewise.
* testsuite/20_util/function_objects/range.cmp/lwg3530.cc:
Likewise.
* testsuite/20_util/function_objects/range.cmp/not_equal_to.cc:
Likewise.
* testsuite/20_util/specialized_algorithms/construct_at/1.cc:
Likewise.
* testsuite/20_util/specialized_algorithms/construct_at/92878_92947.cc:
Likewise.
* testsuite/20_util/specialized_algorithms/construct_at/95788.cc:
Likewise.
* testsuite/20_util/specialized_algorithms/destroy/constrained.cc:
Likewise.
* 
testsuite/20_util/specialized_algorithms/uninitialized_copy/constrained.cc:
Likewise.
* 
testsuite/20_util/specialized_algorithms/uninitialized_default_construct/constrained.cc:
Likewise.
* testsuite/20_util/specialized_algorithms/uninitialized_fill/94017.cc:
Likewise.
* 
testsuite/20_util/specialized_algorithms/uninitialized_fill/constrained.cc:
Likewise.
* 
testsuite/20_util/specialized_algorithms/uninitialized_fill_n/94017.cc:
Likewise.
* 
testsuite/20_util/specialized_algorithms/uninitialized_move/constrained.cc:
Likewise.
* 
testsuite/20_util/specialized_algorithms/uninitialized_value_construct/constrained.cc:
Likewise.
* testsuite/25_algorithms/adjacent_find/constexpr.cc: Likewise.
* testsuite/25_algorithms/adjacent_find/constrained.cc:
Likewise.
* testsuite/25_algorithms/all_of/constexpr.cc: Likewise.
* testsuite/25_algorithms/all_of/constrained.cc: Likewise.
* testsuite/25_algorithms/any_of/constexpr.cc: Likewise.
* testsuite/25_algorithms/any_of/constrained.cc: Likewise.
* testsuite/25_algorithms/binary_search/constexpr.cc: Likewise.
* testsuite/25_algorithms/binary_search/constrained.cc:
Likewise.
* testsuite/25_algorithms/clamp/constrained.cc: Likewise.
* testsuite/25_algorithms/constexpr_macro.cc: Likewise.
* testsuite/25_algorithms/copy/95578.cc: Likewise.
* testsuite/25_algorithms/copy/constexpr.cc: Likewise.
* testsuite/25_algorithms/copy/constrained.cc: Likewise.
* testsuite/25_algorithms/copy/debug/constexpr_neg.cc: Likewise.
* testsuite/25_algorithms/copy_backward/95578.cc: Likewise.
* testsuite/25_algorithms/copy_backward/constexpr.cc: Likewise.
* testsuite/25_algorithms/copy_backward/constrained.cc:
Likewise.
* testsuite/25_algorithms/copy_backward/debug/constexpr_neg.cc:
Likewise.
* testsuite/25_algorithms/copy_if/constexpr.cc: Likewise.
* testsuite/25_algorithms/copy_if/constrained.cc: Likewise.
* testsuite/25_algorithms/copy_n/constexpr.cc: Likewise.
* testsuite/25_algorithms/copy_n/constrained.cc: Likewise.
* testsuite/25_algorithms/count/constexpr.cc: Likewise.
* testsuite/25_algorithms/count/constrained.cc: Likewise.
* testsuite/25_algorithms/count_if/constexpr.cc: Likewise.
* testsuite/25_algorithms/count_if/constrained.cc: Likewise.
* testsuite/25_algorithms/cpp_lib_constexpr.cc: Likewise.
* testsuite/25_algorithms/equal/95578.cc: Likewise.
* testsuite/25_algorithms/equal/constexpr.cc: Likewise.
* testsuite/25_algorithms/equal/constexpr_neg.cc: Likewise.
* testsuite/25_algorithms/equal/constrained.cc: Likewise.
* testsuite/25_algorithms/equal/debug/constexpr_neg.cc:
Likewise.
* testsuite/25_algorithms/equal_range/constexpr.cc: Likewise.
* testsuite/25_algorithms/equal_range/constrained.cc: Likewise.
* testsuite/25_algorithms/fill/94017.cc: Likewise.
* testsuite/25_algorithms/fill/constexpr.cc: Likewise.
* testsuite/25_algorithms/fill/constrained.cc: Likewise.
* testsuite/25_algorithms/fill_n/94017.cc: Likewise.
* testsuite/25_algorithms/fill_n/constexpr.cc: Likewise.
* testsuite/25_algorithms/fill_n/constrained.cc: Likewise.
* testsuite/25_algorithms/find/constexpr.cc: Likewise.
* testsuite/25_algorithms/find/constrained.cc: Likewise.
* testsuite/25_algorithms/find_end/constexpr.cc: Likewise.
* testsuite/25_algorithms/find_end/constrained.cc: Likewise.
* testsuite/25_algorithms/find_first_of/constexpr.cc: Likewise.

[PATCH 04/13] libstdc++: Replace dg-options "-std=c++20" with dg-add-options strict_std

2023-09-11 Thread Jonathan Wakely via Gcc-patches
The testsuite will automatically select C++20 for these tests now, and
removing the hardcoded -std option allows them to be tested for C++23
and C++26 as well. Because they test a problem seen with -std=c++20 add
the new { dg-add-options strict_std } directive so that the test runner
uses -std=c++NN not -std=gnu++NN.

libstdc++-v3/ChangeLog:

* testsuite/24_iterators/reverse_iterator/100639.cc: Remove
dg-options and add dg-add-options strict_std.
* testsuite/std/ranges/iota/93267.cc: Likewise.
* testsuite/std/ranges/iota/96042.cc: Likewise.
* testsuite/std/ranges/iota/size.cc: Likewise.
* testsuite/std/ranges/subrange/96042.cc: Likewise.
---
 .../testsuite/24_iterators/reverse_iterator/100639.cc | 4 ++--
 libstdc++-v3/testsuite/std/ranges/iota/93267.cc   | 4 ++--
 libstdc++-v3/testsuite/std/ranges/iota/96042.cc   | 4 ++--
 libstdc++-v3/testsuite/std/ranges/iota/size.cc| 2 +-
 libstdc++-v3/testsuite/std/ranges/subrange/96042.cc   | 4 ++--
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/libstdc++-v3/testsuite/24_iterators/reverse_iterator/100639.cc 
b/libstdc++-v3/testsuite/24_iterators/reverse_iterator/100639.cc
index 5d0a7f4af27..68bf4e08488 100644
--- a/libstdc++-v3/testsuite/24_iterators/reverse_iterator/100639.cc
+++ b/libstdc++-v3/testsuite/24_iterators/reverse_iterator/100639.cc
@@ -15,8 +15,8 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-options "-std=c++2a" }
-// { dg-do compile { target c++2a } }
+// { dg-do compile { target c++20 } }
+// { dg-add-options strict_std }
 
 // PR libstdc++/100639
 
diff --git a/libstdc++-v3/testsuite/std/ranges/iota/93267.cc 
b/libstdc++-v3/testsuite/std/ranges/iota/93267.cc
index 3bb74bbf485..4306aea4d43 100644
--- a/libstdc++-v3/testsuite/std/ranges/iota/93267.cc
+++ b/libstdc++-v3/testsuite/std/ranges/iota/93267.cc
@@ -15,8 +15,8 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-options "-std=c++2a" }
-// { dg-do compile { target c++2a } }
+// { dg-do compile { target c++20 } }
+// { dg-add-options strict_std }
 
 #include 
 
diff --git a/libstdc++-v3/testsuite/std/ranges/iota/96042.cc 
b/libstdc++-v3/testsuite/std/ranges/iota/96042.cc
index 7070a7d6b10..6c553de9ce9 100644
--- a/libstdc++-v3/testsuite/std/ranges/iota/96042.cc
+++ b/libstdc++-v3/testsuite/std/ranges/iota/96042.cc
@@ -15,8 +15,8 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-options "-std=c++2a" }
-// { dg-do compile { target c++2a } }
+// { dg-do compile { target c++20 } }
+// { dg-add-options strict_std }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/std/ranges/iota/size.cc 
b/libstdc++-v3/testsuite/std/ranges/iota/size.cc
index 958cb5f03c8..28848d55561 100644
--- a/libstdc++-v3/testsuite/std/ranges/iota/size.cc
+++ b/libstdc++-v3/testsuite/std/ranges/iota/size.cc
@@ -15,8 +15,8 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-options "-std=c++2a" }
 // { dg-do compile { target c++2a } }
+// { dg-add-options strict_std }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/std/ranges/subrange/96042.cc 
b/libstdc++-v3/testsuite/std/ranges/subrange/96042.cc
index bc22f999ed8..3856952eeb3 100644
--- a/libstdc++-v3/testsuite/std/ranges/subrange/96042.cc
+++ b/libstdc++-v3/testsuite/std/ranges/subrange/96042.cc
@@ -15,8 +15,8 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-options "-std=c++20" }
-// { dg-do compile { target c++2a } }
+// { dg-do compile { target c++20 } }
+// { dg-add-options strict_std }
 
 #include 
 #include 
-- 
2.41.0



[PATCH 13/13] libstdc++: Simplify dejagnu directives for some tests using threads

2023-09-11 Thread Jonathan Wakely via Gcc-patches
Replace dg-require-effective-target directives with a target selector on
the dg-do directive.

We can also remove { dg-require-effective-target pthread } and the
associated { dg-options "-pthread" } by allowing it to run on
non-pthread targets and conditionally adding -pthread only for pthread
targets.

libstdc++-v3/ChangeLog:

* testsuite/20_util/shared_ptr/atomic/3.cc: Simplify dg
directives.
* testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc:
Likewise.
* testsuite/20_util/shared_ptr/thread/mutex_weaktoshared.cc:
Likewise.
* testsuite/20_util/synchronized_pool_resource/allocate.cc:
Likewise.
* testsuite/20_util/synchronized_pool_resource/allocate_single.cc:
Likewise.
* testsuite/20_util/synchronized_pool_resource/cons.cc:
Likewise.
* testsuite/20_util/synchronized_pool_resource/cons_single.cc:
Likewise.
* testsuite/20_util/synchronized_pool_resource/is_equal.cc:
Likewise.
* testsuite/20_util/synchronized_pool_resource/multithreaded.cc:
Likewise.
* testsuite/20_util/synchronized_pool_resource/options.cc:
Likewise.
* testsuite/20_util/synchronized_pool_resource/release.cc:
Likewise.
* testsuite/20_util/synchronized_pool_resource/release_single.cc:
Likewise.
* testsuite/30_threads/condition_variable_any/stop_token/wait_on.cc:
Likewise.
* testsuite/30_threads/stop_token/stop_callback/deadlock-mt.cc:
Likewise.
* testsuite/30_threads/stop_token/stop_callback/destroy.cc:
Likewise.
---
 libstdc++-v3/testsuite/20_util/shared_ptr/atomic/3.cc   | 3 +--
 .../20_util/shared_ptr/thread/default_weaktoshared.cc   | 3 +--
 .../20_util/shared_ptr/thread/mutex_weaktoshared.cc | 3 +--
 .../20_util/synchronized_pool_resource/allocate.cc  | 6 ++
 .../20_util/synchronized_pool_resource/allocate_single.cc   | 3 +--
 .../testsuite/20_util/synchronized_pool_resource/cons.cc| 6 ++
 .../20_util/synchronized_pool_resource/cons_single.cc   | 3 +--
 .../20_util/synchronized_pool_resource/is_equal.cc  | 6 ++
 .../20_util/synchronized_pool_resource/multithreaded.cc | 6 ++
 .../testsuite/20_util/synchronized_pool_resource/options.cc | 6 ++
 .../testsuite/20_util/synchronized_pool_resource/release.cc | 6 ++
 .../20_util/synchronized_pool_resource/release_single.cc| 3 +--
 .../30_threads/condition_variable_any/stop_token/wait_on.cc | 6 ++
 .../30_threads/stop_token/stop_callback/deadlock-mt.cc  | 5 ++---
 .../30_threads/stop_token/stop_callback/destroy.cc  | 5 ++---
 15 files changed, 24 insertions(+), 46 deletions(-)

diff --git a/libstdc++-v3/testsuite/20_util/shared_ptr/atomic/3.cc 
b/libstdc++-v3/testsuite/20_util/shared_ptr/atomic/3.cc
index 8346191412c..19efcadb7ec 100644
--- a/libstdc++-v3/testsuite/20_util/shared_ptr/atomic/3.cc
+++ b/libstdc++-v3/testsuite/20_util/shared_ptr/atomic/3.cc
@@ -1,6 +1,5 @@
-// { dg-do run }
+// { dg-do run { target c++11 } }
 // { dg-additional-options "-pthread" { target pthread } }
-// { dg-require-effective-target c++11 }
 // { dg-require-gthreads "" }
 
 // Copyright (C) 2014-2023 Free Software Foundation, Inc.
diff --git 
a/libstdc++-v3/testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc 
b/libstdc++-v3/testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc
index 20c910c2fcd..af0e65e9469 100644
--- a/libstdc++-v3/testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc
+++ b/libstdc++-v3/testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc
@@ -17,10 +17,9 @@
 
 // 20.6.6.2 Template class shared_ptr [util.smartptr.shared]
 
-// { dg-do run }
+// { dg-do run { target c++11 } }
 // { dg-additional-options "-pthread" { target pthread } }
 // { dg-add-options libatomic }
-// { dg-require-effective-target c++11 }
 // { dg-require-gthreads "" }
 // { dg-require-cstdint "" }
 
diff --git 
a/libstdc++-v3/testsuite/20_util/shared_ptr/thread/mutex_weaktoshared.cc 
b/libstdc++-v3/testsuite/20_util/shared_ptr/thread/mutex_weaktoshared.cc
index d6c8611aa85..07f7c49bf10 100644
--- a/libstdc++-v3/testsuite/20_util/shared_ptr/thread/mutex_weaktoshared.cc
+++ b/libstdc++-v3/testsuite/20_util/shared_ptr/thread/mutex_weaktoshared.cc
@@ -17,10 +17,9 @@
 
 // 20.6.6.2 Template class shared_ptr [util.smartptr.shared]
 
-// { dg-do run }
+// { dg-do run { target c++11 } }
 // { dg-additional-options "-pthread" { target pthread } }
 // { dg-add-options libatomic }
-// { dg-require-effective-target c++11 }
 // { dg-require-gthreads "" }
 // { dg-require-cstdint "" }
 
diff --git 
a/libstdc++-v3/testsuite/20_util/synchronized_pool_resource/allocate.cc 
b/libstdc++-v3/testsuite/20_util/synchronized_pool_resource/allocate.cc
index f9a4a2f3694..822a410b6c2 100644
--- a/libstdc++-v3/testsuite/20_util/synchronized_pool_resource/allocate.cc
+++ 

[PATCH 06/13] libstdc++: Remove dg-options "-std=gnu++20" from and tests

2023-09-11 Thread Jonathan Wakely via Gcc-patches
The testsuite will automatically select C++20 for these tests now, and
removing the hardcoded -std option allows them to be tested for C++23
and C++26 as well.

libstdc++-v3/ChangeLog:

* testsuite/std/concepts/1.cc: Remove dg-options.
* testsuite/std/concepts/2.cc: Likewise.
* testsuite/std/concepts/concepts.callable/invocable.cc:
Likewise.
* testsuite/std/concepts/concepts.callable/regular_invocable.cc:
Likewise.
* testsuite/std/concepts/concepts.callable/relation.cc:
Likewise.
* testsuite/std/concepts/concepts.callable/strictweakorder.cc:
Likewise.
* 
testsuite/std/concepts/concepts.lang/concept.arithmetic/floating_point.cc: 
Likewise.
* testsuite/std/concepts/concepts.lang/concept.arithmetic/integral.cc: 
Likewise.
* 
testsuite/std/concepts/concepts.lang/concept.arithmetic/signed_integral.cc: 
Likewise.
* 
testsuite/std/concepts/concepts.lang/concept.arithmetic/unsigned_integral.cc: 
Likewise.
* testsuite/std/concepts/concepts.lang/concept.assignable/1.cc:
Likewise.
* testsuite/std/concepts/concepts.lang/concept.common/1.cc:
Likewise.
* testsuite/std/concepts/concepts.lang/concept.commonref/1.cc:
Likewise.
* testsuite/std/concepts/concepts.lang/concept.constructible/1.cc: 
Likewise.
* testsuite/std/concepts/concepts.lang/concept.convertible/1.cc:
Likewise.
* testsuite/std/concepts/concepts.lang/concept.copyconstructible/1.cc: 
Likewise.
* 
testsuite/std/concepts/concepts.lang/concept.defaultinitializable/1.cc: 
Likewise.
* 
testsuite/std/concepts/concepts.lang/concept.defaultinitializable/lwg3149.cc: 
Likewise.
* testsuite/std/concepts/concepts.lang/concept.derived/1.cc:
Likewise.
* testsuite/std/concepts/concepts.lang/concept.destructible/1.cc: 
Likewise.
* testsuite/std/concepts/concepts.lang/concept.moveconstructible/1.cc: 
Likewise.
* testsuite/std/concepts/concepts.lang/concept.same/1.cc:
Likewise.
* testsuite/std/concepts/concepts.lang/concept.swappable/swap.cc: 
Likewise.
* testsuite/std/concepts/concepts.lang/concept.swappable/swappable.cc: 
Likewise.
* 
testsuite/std/concepts/concepts.lang/concept.swappable/swappable_with.cc: 
Likewise.
* testsuite/std/concepts/concepts.object/copyable.cc: Likewise.
* testsuite/std/concepts/concepts.object/movable.cc: Likewise.
* testsuite/std/concepts/concepts.object/regular.cc: Likewise.
* testsuite/std/concepts/concepts.object/semiregular.cc:
Likewise.
* testsuite/std/ranges/97600.cc: Likewise.
* testsuite/std/ranges/access/101782.cc: Likewise.
* testsuite/std/ranges/access/begin.cc: Likewise.
* testsuite/std/ranges/access/begin_neg.cc: Likewise.
* testsuite/std/ranges/access/cbegin.cc: Likewise.
* testsuite/std/ranges/access/cdata.cc: Likewise.
* testsuite/std/ranges/access/cend.cc: Likewise.
* testsuite/std/ranges/access/crbegin.cc: Likewise.
* testsuite/std/ranges/access/crend.cc: Likewise.
* testsuite/std/ranges/access/data.cc: Likewise.
* testsuite/std/ranges/access/empty.cc: Likewise.
* testsuite/std/ranges/access/end.cc: Likewise.
* testsuite/std/ranges/access/end_neg.cc: Likewise.
* testsuite/std/ranges/access/lwg3467.cc: Likewise.
* testsuite/std/ranges/access/p2602.cc: Likewise.
* testsuite/std/ranges/access/rbegin.cc: Likewise.
* testsuite/std/ranges/access/rend.cc: Likewise.
* testsuite/std/ranges/access/size.cc: Likewise.
* testsuite/std/ranges/access/size_neg.cc: Likewise.
* testsuite/std/ranges/access/ssize.cc: Likewise.
* testsuite/std/ranges/adaptors/100479.cc: Likewise.
* testsuite/std/ranges/adaptors/100577.cc: Likewise.
* testsuite/std/ranges/adaptors/93978.cc: Likewise.
* testsuite/std/ranges/adaptors/95322.cc: Likewise.
* testsuite/std/ranges/adaptors/99433.cc: Likewise.
* testsuite/std/ranges/adaptors/all.cc: Likewise.
* testsuite/std/ranges/adaptors/common.cc: Likewise.
* testsuite/std/ranges/adaptors/conditionally_borrowed.cc:
Likewise.
* testsuite/std/ranges/adaptors/counted.cc: Likewise.
* testsuite/std/ranges/adaptors/detail/copyable_box.cc:
Likewise.
* testsuite/std/ranges/adaptors/drop.cc: Likewise.
* testsuite/std/ranges/adaptors/drop_while.cc: Likewise.
* testsuite/std/ranges/adaptors/elements.cc: Likewise.
* testsuite/std/ranges/adaptors/filter.cc: Likewise.
* testsuite/std/ranges/adaptors/join.cc: Likewise.
* testsuite/std/ranges/adaptors/lazy_split.cc: Likewise.
* testsuite/std/ranges/adaptors/lazy_split_neg.cc: Likewise.
* testsuite/std/ranges/adaptors/lwg3286.cc: Likewise.
* 

[PATCH 03/13] libstdc++: Replace dg-options "-std=c++17" with dg-add-options strict_std

2023-09-11 Thread Jonathan Wakely via Gcc-patches
These tests can (and should) also be run for later standards, so replace
the { dg-options "-std=c++17" } with { dg-add-options strict_std }.

* 
testsuite/tr1/5_numerical_facilities/special_functions/07_conf_hyperg/compile_cxx17.cc:
Replace dg-options -std=c++17 with dg-add-options strict_std.
* 
testsuite/tr1/5_numerical_facilities/special_functions/17_hyperg/compile_cxx17.cc:
Likewise.
---
 .../special_functions/07_conf_hyperg/compile_cxx17.cc   | 2 +-
 .../special_functions/17_hyperg/compile_cxx17.cc| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/07_conf_hyperg/compile_cxx17.cc
 
b/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/07_conf_hyperg/compile_cxx17.cc
index 60264ebe3dd..a10ba8e517b 100644
--- 
a/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/07_conf_hyperg/compile_cxx17.cc
+++ 
b/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/07_conf_hyperg/compile_cxx17.cc
@@ -15,8 +15,8 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-options "-std=c++17" }
 // { dg-do compile { target c++17 } }
+// { dg-add-options strict_std }
 
 #include 
 
diff --git 
a/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/17_hyperg/compile_cxx17.cc
 
b/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/17_hyperg/compile_cxx17.cc
index 40ea47c1ca4..91a55883f64 100644
--- 
a/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/17_hyperg/compile_cxx17.cc
+++ 
b/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/17_hyperg/compile_cxx17.cc
@@ -15,8 +15,8 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-options "-std=c++17" }
 // { dg-do compile { target c++17 } }
+// { dg-add-options strict_std }
 
 #include 
 
-- 
2.41.0



[PATCH 00/13] libstdc++: Add support for running tests with multiple -std options

2023-09-11 Thread Jonathan Wakely via Gcc-patches
This patch series replicates the behaviour of the g++ testsuite, so that
libstdc++ tests can easily be run for multiple different -std options in
a single testsuite run.  As described in the updated docs, the -std
options to use for every test can be overridden by setting v3_std_list
in ~/.dejagnurc or $DEJAGNU, or setting $GLIBCXX_TESTSUITE_STDS in the
environment.  If not overridden, the default is just to run with
-std=gnu++17 (so that we don't increase the time taken for a full
testsuite run).

Tests that require a newer standard than C++17 will default to that
newer standard and C++26, so e.g. std::format tests will be run with
both -std=gnu++20 and -std=gnu++26.  This does increase the number of
tests, but only for the subset of tests for C++20/23/26 features.  If
this is too costly for testers, we can change that (this might be
needed, because the C++20 tests for std::ranges and std::format are
particularly slow to compile).

Because a correct default will be chosen for tests that require
something newer than C++17, we no longer need dg-options "-std=gnu++20"
or similar in any tests.  Removing the explicit -std option allows the
test to be run for later standards via the v3_std_list settings, so that
we can verify that C++20 features still work in C++23 and C++26, for
example.  This change already found some tests which failed when run
with a later standard (see r14-3771-gf12e26f3496275).

Patches 2-13 in the series remove those unnecessary dg-options from
about half the relevant tests, but there are more than 500 others that
still need adjusting.

We can remove files like testsuite/std/format/functions/format_c++23.cc
which only exist to duplicate existing tests with a different -std
option.  We can remove that file now, and rely on format.cc being run
with multiple -std options by libstdc++ maintainers.

It might also be useful to add a 'make check-quick' target which runs a
small subset of smoke tests with every standard version in v3_std_list.
This would be a suitable target for CI bots and for packagers who want
to verify that a build of GCC is functional, without running the entire
libstdc++ testsuite.

Any comments or suggestions?

-- >8 --

Jonathan Wakely (13):
  libstdc++: Add support for running tests with multiple -std options
  libstdc++: Replace dg-options "-std=c++11" with dg-add-options
strict_std
  libstdc++: Replace dg-options "-std=c++17" with dg-add-options
strict_std
  libstdc++: Replace dg-options "-std=c++20" with dg-add-options
strict_std
  libstdc++: Remove dg-options "-std=c++20" from  and 
tests
  libstdc++: Remove dg-options "-std=gnu++20" from  and
 tests
  libstdc++: Remove dg-options "-std=gnu++2a" from constrained algo
tests
  libstdc++: Remove dg-options "-std=gnu++20" from std::format tests
  libstdc++: Remove dg-options "-std=gnu++20" from std::chrono tests
  libstdc++: Remove dg-options "-std=gnu++23" from std::expected tests
  libstdc++: Remove dg-options "-std=gnu++23" from remaining tests
  libstdc++: Remove dg-options "-std=gnu++2a" from XFAIL std::span tests
  libstdc++: Simplify dejagnu directives for some tests using threads

 libstdc++-v3/doc/html/manual/test.html|  46 +---
 libstdc++-v3/doc/xml/manual/test.xml  |  52 ++---
 .../headers/limits/synopsis_cxx23.cc  |   1 -
 .../18_support/headers/stdfloat/types_std.cc  |   1 -
 .../18_support/type_info/constexpr.cc |   2 +-
 .../19_diagnostics/stacktrace/current.cc  |   2 +-
 .../19_diagnostics/stacktrace/entry.cc|   2 +-
 .../19_diagnostics/stacktrace/stacktrace.cc   |   2 +-
 .../19_diagnostics/stacktrace/synopsis.cc |   1 -
 .../19_diagnostics/stacktrace/version.cc  |   1 -
 .../20_util/aligned_storage/deprecated-2b.cc  |   1 -
 .../20_util/aligned_union/deprecated-2b.cc|   1 -
 .../20_util/bitset/access/constexpr.cc|   1 -
 .../20_util/bitset/cons/constexpr_c++23.cc|   1 -
 .../20_util/bitset/count/constexpr.cc |   1 -
 .../testsuite/20_util/bitset/ext/constexpr.cc |   1 -
 .../bitset/operations/constexpr_c++23.cc  |   1 -
 .../testsuite/20_util/bitset/version.cc   |   1 -
 .../duration/arithmetic/overflow_c++20.cc |   1 -
 libstdc++-v3/testsuite/20_util/duration/io.cc |   1 -
 .../testsuite/20_util/expected/assign.cc  |   1 -
 .../testsuite/20_util/expected/bad.cc |   1 -
 .../testsuite/20_util/expected/cons.cc|   1 -
 .../testsuite/20_util/expected/equality.cc|   1 -
 .../20_util/expected/illformed_neg.cc |   1 -
 .../testsuite/20_util/expected/lwg3877.cc |   1 -
 .../testsuite/20_util/expected/lwg3938.cc |   1 -
 .../testsuite/20_util/expected/monadic.cc |   1 -
 .../testsuite/20_util/expected/observers.cc   |   1 -
 .../20_util/expected/requirements.cc  |   1 -
 .../testsuite/20_util/expected/swap.cc|   1 -
 .../testsuite/20_util/expected/synopsis.cc|   1 -
 .../testsuite/20_util/expected/unexpected.cc  |   1 -
 

[PATCH 01/13] libstdc++: Add support for running tests with multiple -std options

2023-09-11 Thread Jonathan Wakely via Gcc-patches
This copies the code from the compiler's gcc/testsuite/lib/g++-dg.exp so
that each test can be run multiple times, with different -std options.
This means that we can remove most { dg-options "-std=gnu++20" }
directives from tests, because the testsuite will automatically select
a set of -std options that includes that version.

Tests that should only run for a specific standard (e.g. ones that use
something like { dg-do run { target c++11_only } }) should still specify
that standard with { dg-options "-std=gnu++11" }, which overrides the
automatic selection. But a dg-options that selects a newer standard than
the default can be removed, because that standard will be selected
automatically based on a selector like { target c++20 } in the dg-do
directive. This will allow those tests to be run for more than just the
one they currently hardcode, so that e.g. std::format tests can be run
for all of C++20, C++23 and C++26. Currently that has to be done by
adding a second test file that uses a different dg-options line.

By default most tests will continue to run with only the default dialect
(currently -std=gnu++17) so that the time to run the entire testsuite is
not increased. We can revisit this later if increasing the testsuite
time (and coverage) is acceptable. Libstdc++ developers can easily
override the defaults to run for multiple versions. To test all
versions, either add 'set v3_std_list { 98 11 14 17 20 23 26 }' to
~/.dejagnurc or define GLIBCXX_TESTSUITE_STDS="98,11,14,17,20,23,26" in
the environment.

This should be more efficient than the current way to test with multple
standards, i.e. --target_board=unix{-std=c++14,-std=c++17,-std=c++20},
because today all tests with an explicit -std option hardcoded in them
get run for each target board variation but using the exact same
hardcoded -std every time. With the new approach you can just use the
default --target_board=unix and set GLIBCXX_TESTSUITE_STDS="14,17,20"
and now a test that has { target c++20 } will only run once (and be
UNSUPPORTED twice), instead of running with identical options three
times.

In order to support ~/.dejagnurc and $DEJAGNU files that need to work
with versions of GCC without this change, a new variable is added to
site.tmp to detect whether v3_std_list is supported. That allows e.g.

if { [info exists v3-use-std-list] } {
  set v3_std_list { 11 17 23 }
  set target_list { "unix{,-m32}" }
} else {
  set target_list { "unix{,-std=gnu++2b,-std=gnu++11,-m32}" }
}

libstdc++-v3/ChangeLog:

* doc/xml/manual/test.xml: Update documentation on running and
writing tests.
* doc/html/manual/test.html: Regenerate.
* testsuite/Makefile.am: Add v3-use-std-list to site.tmp
* testsuite/Makefile.in: Regenerate.
* testsuite/lib/dg-options.exp (add_options_for_strict_std): New
proc.
* testsuite/lib/libstdc++.exp (search_for): New utility proc.
(v3-dg-runtest): New proc to replace dg-runtest.
* testsuite/libstdc++-dg/conformance.exp: Use v3-dg-runtest.
---
 libstdc++-v3/doc/html/manual/test.html|  46 +---
 libstdc++-v3/doc/xml/manual/test.xml  |  52 ++---
 libstdc++-v3/testsuite/Makefile.am|   1 +
 libstdc++-v3/testsuite/Makefile.in|   1 +
 libstdc++-v3/testsuite/lib/dg-options.exp |   7 ++
 libstdc++-v3/testsuite/lib/libstdc++.exp  | 107 ++
 .../testsuite/libstdc++-dg/conformance.exp|   3 +-
 7 files changed, 186 insertions(+), 31 deletions(-)

diff --git a/libstdc++-v3/doc/html/manual/test.html 
b/libstdc++-v3/doc/html/manual/test.html
index fadadf249bb..b29c2eb359e 100644
--- a/libstdc++-v3/doc/html/manual/test.html
+++ b/libstdc++-v3/doc/html/manual/test.html
@@ -350,6 +350,16 @@ cat 27_io/objects/char/3_xin.in | 
a.outunix/-O3\"{-std=gnu++98,-std=gnu++11,}\" so 
that
   the third variation would use the default for -std
   (which is -std=gnu++14 as of GCC 6).
+
+  Since GCC 14, the libstdc++ testsuite has built-in support for running
+  tests with more than one -std, similar to 
the G++ tests.
+  Adding set v3_std_list { 11 17 23 } to
+  ~/.dejagnurc or a file named by the
+  DEJAGNU environment variable will cause every 
test to
+  be run three times, using a different -std 
each time.
+  Alternatively, a list of standard versions to test with can be specified
+  as a comma-separated list in the envvarGLIBCXX_TESTSUITE_STDS/envvar
+  environment variable.
 
   To run the libstdc++ test suite under the
   debug mode, use
@@ -467,11 +477,12 @@ cat 27_io/objects/char/3_xin.in | 
a.outonly
 be run for a specific standard (and not later standards) using an
 effective target like c++11_only. However, 
this means
-the test will be skipped by default (because the default mode is
-gnu++14), and so will only run when
--std=gnu++11 or -std=c++11 is used
-explicitly. For tests that require a specific standard it 

Re: [PATCH 2/2] libstdc++: Add dg-require-thread-fence in several tests

2023-09-11 Thread Jonathan Wakely via Gcc-patches
On Mon, 11 Sept 2023 at 16:40, Christophe Lyon
 wrote:
>
>
>
> On Mon, 11 Sept 2023 at 17:22, Jonathan Wakely  wrote:
>>
>> On Mon, 11 Sept 2023 at 14:57, Christophe Lyon
>>  wrote:
>> >
>> >
>> >
>> > On Mon, 11 Sept 2023 at 15:12, Jonathan Wakely  wrote:
>> >>
>> >> On Mon, 11 Sept 2023 at 13:36, Christophe Lyon
>> >>  wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Mon, 11 Sept 2023 at 12:59, Jonathan Wakely  
>> >> > wrote:
>> >> >>
>> >> >> On Sun, 10 Sept 2023 at 20:31, Christophe Lyon
>> >> >>  wrote:
>> >> >> >
>> >> >> > Some targets like arm-eabi with newlib and default settings rely on
>> >> >> > __sync_synchronize() to ensure synchronization.  Newlib does not
>> >> >> > implement it by default, to make users aware they have to take 
>> >> >> > special
>> >> >> > care.
>> >> >> >
>> >> >> > This makes a few tests fail to link.
>> >> >>
>> >> >> Does this mean those features are unusable on the target, or just that
>> >> >> users need to provide their own __sync_synchronize to use them?
>> >> >
>> >> >
>> >> > IIUC the user is expected to provide them.
>> >> > Looks like we discussed this in the past :-)
>> >> > In  https://gcc.gnu.org/legacy-ml/gcc-patches/2016-10/msg01632.html,
>> >> > see the pointer to Ramana's comment: 
>> >> > https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02751.html
>> >>
>> >> Oh yes, thanks for the reminder!
>> >>
>> >> >
>> >> > The default arch for arm-eabi is armv4t which is very old.
>> >> > When running the testsuite with something more recent (either as 
>> >> > default by configuring GCC --with-arch=XXX or by forcing -march/-mcpu 
>> >> > via dejagnu's target-board), the compiler generates barrier 
>> >> > instructions and there are no such errors.
>> >>
>> >> Ah yes, that's fine then.
>> >>
>> >> > For instance, here is a log with the defaults:
>> >> > https://git.linaro.org/toolchain/ci/base-artifacts/tcwg_gnu_embed_check_gcc/master-arm_eabi.git/tree/00-sumfiles?h=linaro-local/ci/tcwg_gnu_embed_check_gcc/master-arm_eabi
>> >> > and a log when we target cortex-m0 which is still a very small cpu but 
>> >> > has barriers:
>> >> > https://git.linaro.org/toolchain/ci/base-artifacts/tcwg_gnu_embed_check_gcc/master-thumb_m0_eabi.git/tree/00-sumfiles?h=linaro-local/ci/tcwg_gnu_embed_check_gcc/master-thumb_m0_eabi
>> >> >
>> >> > I somehow wanted to get rid of such errors with the default 
>> >> > configuration
>> >>
>> >> Yep, that makes sense, and we'll still be testing them for newer
>> >> arches on the target, so it's not completely disabling those parts of
>> >> the testsuite.
>> >>
>> >> But I'm still curious why some of those tests need this change. I
>> >> think the ones I noted below are probably failing for some other
>> >> reasons.
>> >>
>> > Just looked at  23_containers/span/back_assert_neg.cc, the linker says it 
>> > needs
>> > arm-eabi/libstdc++-v3/src/.libs/libstdc++.a(debug.o) to resolve
>> > ./back_assert_neg-back_assert_neg.o (std::__glibcxx_assert_fail(char 
>> > const*, int, char const*, char const*))
>> > and indeed debug.o has a reference to __sync_synchronize
>>
>> Aha, that's just because I put __glibcxx_assert_fail in debug.o, but
>> there are no dependencies on anything else in that file, including the
>> _M_detach member function that uses atomics.
>
> indeed
>
>
>>
>> This would also be solved by -Wl,--gc-sections :-)
>
> :-)
>
>>
>> I think it would be better to move __glibcxx_assert_fail to a new
>> file, so that it doesn't make every assertion unnecessarily depend on
>> __sync_synchronize. I'll do that now.
>
> Sounds like a good idea, thanks.

Done now at r14-3846-g4a2766ed00a479
>
>>
>> We could also make the atomics in debug.o conditional, so that debug
>> mode doesn't depend on __sync_synchronize for single-threaded targets.
>> Does the arm4t arch have pthreads support in newlib?  I didn't bother
>
> No ( grep _GLIBCXX_HAS_GTHREADS 
> $objdir/arm-eabi/libstdc++-v3/include/arm-eabi/bits/c++config returns:
> /* #undef _GLIBCXX_HAS_GTHREADS */
>
>> making the use of atomics conditional, because performance is not
>> really a priority for debug mode bookkeeping. But the problem here
>> isn't just a slight performance overhead of atomics, it's that they
>> aren't even supported for arm4t.
>
> OK thanks.
>
> So finally, this uncovered at least a "bug" that  __glibcxx_assert_fail 
> should be in a dedicated object file :-)
>
> I'll revisit my patch once you have moved __glibcxx_assert_fail

That's done (at r14-3845-gc7db9000fa7cac) and there should be no more
__sync_synchronize from src/c++11/debug.o at all now (at
r14-3846-g4a2766ed00a479). With that second change, it would have been
OK for __glibcxx_assert_fail to stay in that file, but it's not really
related so it's probably better for it to be in a separate file
anyway.

That should remove the need for most of your patch!



[committed] libstdc++: Remove unconditional use of atomics in Debug Mode

2023-09-11 Thread Jonathan Wakely via Gcc-patches
Tested aarch64-linux. Pushed to trunk.

Probably worth backporting too.

-- >8 --

The fix for PR 91910 (r10-3426-gf7a3a382279585) introduced unconditional
uses of atomics into src/c++11/debug.cc, which causes linker errors for
arm4t where GCC emits an unresolved reference to __sync_synchronize.

By making the uses of atomics depend on _GLIBCXX_HAS_GTHREADS we can
avoid those unconditional references to __sync_synchronize for targets
where the atomics are unnecessary. As a minor performance optimization
we can also check the __gnu_cxx::__is_single_threaded function to avoid
atomics for single-threaded programs even where they don't cause linker
errors.

libstdc++-v3/ChangeLog:

* src/c++11/debug.cc (acquire_sequence_ptr_for_lock): New
function.
(reset_sequence_ptr): New function.
(_Safe_iterator_base::_M_detach)
(_Safe_local_iterator_base::_M_detach): Replace bare atomic_load
with acquire_sequence_ptr_for_lock.
(_Safe_iterator_base::_M_reset): Replace bare atomic_store with
reset_sequence_ptr.
---
 libstdc++-v3/src/c++11/debug.cc | 32 +---
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/src/c++11/debug.cc b/libstdc++-v3/src/c++11/debug.cc
index f40e995e0f3..bb0d0db6679 100644
--- a/libstdc++-v3/src/c++11/debug.cc
+++ b/libstdc++-v3/src/c++11/debug.cc
@@ -24,6 +24,7 @@
 
 #include 
 #include 
+#include  // __is_single_threaded
 
 #include 
 #include 
@@ -156,6 +157,31 @@ namespace
__old->_M_reset();
   }
   }
+
+  void*
+  acquire_sequence_ptr_for_lock(__gnu_debug::_Safe_sequence_base*& seq)
+  {
+#ifdef __GTHREADS
+if (!__gnu_cxx::__is_single_threaded())
+  return __atomic_load_n(, __ATOMIC_ACQUIRE);
+#endif
+return seq;
+  }
+
+  void
+  reset_sequence_ptr(__gnu_debug::_Safe_sequence_base*& seq)
+  {
+#ifdef __GTHREADS
+if (!__gnu_cxx::__is_single_threaded())
+  {
+   __atomic_store_n(, (__gnu_debug::_Safe_sequence_base*)nullptr,
+__ATOMIC_RELEASE);
+   return;
+  }
+#endif
+seq = nullptr;
+  }
+
 } // anonymous namespace
 
 namespace __gnu_debug
@@ -439,7 +465,7 @@ namespace __gnu_debug
 // If the sequence destructor runs between loading the pointer and
 // locking the mutex, it will detach this iterator and set _M_sequence
 // to null, and then _M_detach_single() will do nothing.
-if (auto seq = __atomic_load_n(&_M_sequence, __ATOMIC_ACQUIRE))
+if (auto seq = acquire_sequence_ptr_for_lock(_M_sequence))
   {
__gnu_cxx::__scoped_lock sentry(get_safe_base_mutex(seq));
_M_detach_single();
@@ -461,7 +487,7 @@ namespace __gnu_debug
   _Safe_iterator_base::
   _M_reset() throw ()
   {
-__atomic_store_n(&_M_sequence, (_Safe_sequence_base*)0, __ATOMIC_RELEASE);
+reset_sequence_ptr(_M_sequence);
 // Do not reset version, so that a detached iterator does not look like a
 // value-initialized one.
 // _M_version = 0;
@@ -523,7 +549,7 @@ namespace __gnu_debug
   _Safe_local_iterator_base::
   _M_detach()
   {
-if (auto seq = __atomic_load_n(&_M_sequence, __ATOMIC_ACQUIRE))
+if (auto seq = acquire_sequence_ptr_for_lock(_M_sequence))
   {
__gnu_cxx::__scoped_lock sentry(get_safe_base_mutex(seq));
_M_detach_single();
-- 
2.41.0



[committed] libstdc++: Move __glibcxx_assert_fail to its own file

2023-09-11 Thread Jonathan Wakely via Gcc-patches
Tested aarch64-linux. Pushed to trunk.

Maybe worth backporting too.

-- >8 --

This avoids a dependency on the other symbols in src/c++11/debug.o when
linking statically to libstdc++.a without using -Wl,--gc-sections.

libstdc++-v3/ChangeLog:

* src/c++11/Makefile.am: Add new file.
* src/c++11/Makefile.in: Regenerate.
* src/c++11/debug.cc (__glibcxx_assert_fail): Move to ...
* src/c++11/assert_fail.cc: New file.
---
 libstdc++-v3/src/c++11/Makefile.am|  1 +
 libstdc++-v3/src/c++11/Makefile.in|  7 +++--
 libstdc++-v3/src/c++11/assert_fail.cc | 44 +++
 libstdc++-v3/src/c++11/debug.cc   | 18 ---
 4 files changed, 49 insertions(+), 21 deletions(-)
 create mode 100644 libstdc++-v3/src/c++11/assert_fail.cc

diff --git a/libstdc++-v3/src/c++11/Makefile.am 
b/libstdc++-v3/src/c++11/Makefile.am
index 682be1669a4..e7495dcccef 100644
--- a/libstdc++-v3/src/c++11/Makefile.am
+++ b/libstdc++-v3/src/c++11/Makefile.am
@@ -56,6 +56,7 @@ sources_freestanding = \
placeholders.cc
 
 sources = \
+   assert_fail.cc \
chrono.cc \
codecvt.cc \
condition_variable.cc \
diff --git a/libstdc++-v3/src/c++11/Makefile.in 
b/libstdc++-v3/src/c++11/Makefile.in
index e7a09fe3246..a10e05977bc 100644
--- a/libstdc++-v3/src/c++11/Makefile.in
+++ b/libstdc++-v3/src/c++11/Makefile.in
@@ -127,9 +127,9 @@ am__objects_1 = limits.lo placeholders.lo
 @ENABLE_DUAL_ABI_TRUE@ cxx11-ios_failure.lo \
 @ENABLE_DUAL_ABI_TRUE@ cxx11-shim_facets.lo cxx11-stdexcept.lo
 am__objects_3 = ctype_configure_char.lo ctype_members.lo
-am__objects_4 = chrono.lo codecvt.lo condition_variable.lo \
-   cow-stdexcept.lo ctype.lo debug.lo functexcept.lo \
-   functional.lo futex.lo future.lo hash_c++0x.lo \
+am__objects_4 = assert_fail.lo chrono.lo codecvt.lo \
+   condition_variable.lo cow-stdexcept.lo ctype.lo debug.lo \
+   functexcept.lo functional.lo futex.lo future.lo hash_c++0x.lo \
hashtable_c++0x.lo ios.lo ios_errcat.lo mutex.lo random.lo \
regex.lo shared_ptr.lo snprintf_lite.lo system_error.lo \
thread.lo $(am__objects_2) $(am__objects_3)
@@ -475,6 +475,7 @@ sources_freestanding = \
placeholders.cc
 
 sources = \
+   assert_fail.cc \
chrono.cc \
codecvt.cc \
condition_variable.cc \
diff --git a/libstdc++-v3/src/c++11/assert_fail.cc 
b/libstdc++-v3/src/c++11/assert_fail.cc
new file mode 100644
index 000..540e953da2e
--- /dev/null
+++ b/libstdc++-v3/src/c++11/assert_fail.cc
@@ -0,0 +1,44 @@
+// Debugging mode support code -*- C++ -*-
+
+// Copyright (C) 2021-2023 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// .
+
+#include   // for std::fprintf, stderr
+#include  // for std::abort
+
+#ifdef _GLIBCXX_VERBOSE_ASSERT
+namespace std
+{
+  [[__noreturn__]]
+  void
+  __glibcxx_assert_fail(const char* file, int line,
+   const char* function, const char* condition) noexcept
+  {
+if (file && function && condition)
+  fprintf(stderr, "%s:%d: %s: Assertion '%s' failed.\n",
+ file, line, function, condition);
+else if (function)
+  fprintf(stderr, "%s: Undefined behavior detected.\n", function);
+abort();
+  }
+}
+#endif
diff --git a/libstdc++-v3/src/c++11/debug.cc b/libstdc++-v3/src/c++11/debug.cc
index 926e8be6122..f40e995e0f3 100644
--- a/libstdc++-v3/src/c++11/debug.cc
+++ b/libstdc++-v3/src/c++11/debug.cc
@@ -45,24 +45,6 @@
 
 #include "mutex_pool.h"
 
-#ifdef _GLIBCXX_VERBOSE_ASSERT
-namespace std
-{
-  [[__noreturn__]]
-  void
-  __glibcxx_assert_fail(const char* file, int line,
-   const char* function, const char* condition) noexcept
-  {
-if (file && function && condition)
-  fprintf(stderr, "%s:%d: %s: Assertion '%s' failed.\n",
- file, line, function, condition);
-else if (function)
-  fprintf(stderr, "%s: Undefined behavior detected.\n", function);
-abort();
-  }
-}
-#endif
-
 using namespace 

Re: [PATCH] s390: Fix builtins vec_rli and verll

2023-09-11 Thread Andreas Krebbel via Gcc-patches
On 9/11/23 08:56, Stefan Schulze Frielinghaus wrote:
> On Mon, Aug 28, 2023 at 11:33:37AM +0200, Andreas Krebbel wrote:
>> Hi Stefan,
>>
>> do you really need to introduce a new flag for U64 given that the type of 
>> the builtin is unsigned long?
> 
> In function s390_const_operand_ok the immediate is checked whether it is
> valide w.r.t. the flag:
> 
>   tree_to_uhwi (arg) > ((HOST_WIDE_INT_1U << (bitwidth - 1) << 1) - 1)
> 
> Here bitwidth is derived from the flag.

I see, it is about enabling the constant check at all.

Ok, thanks!

Andreas

> 
> Cheers,
> Stefan
> 
>>
>> Andreas
>>
>> On 8/21/23 17:56, Stefan Schulze Frielinghaus wrote:
>>> The second argument of these builtins is an unsigned immediate.  For
>>> vec_rli the API allows immediates up to 64 bits whereas the instruction
>>> verll only allows immediates up to 32 bits.  Since the shift count
>>> equals the immediate modulo vector element size, truncating those
>>> immediates is fine.
>>>
>>> Bootstrapped and regtested on s390.  Ok for mainline?
>>>
>>> gcc/ChangeLog:
>>>
>>> * config/s390/s390-builtins.def (O_U64): New.
>>> (O1_U64): Ditto.
>>> (O2_U64): Ditto.
>>> (O3_U64): Ditto.
>>> (O4_U64): Ditto.
>>> (O_M12): Change bit position.
>>> (O_S2): Ditto.
>>> (O_S3): Ditto.
>>> (O_S4): Ditto.
>>> (O_S5): Ditto.
>>> (O_S8): Ditto.
>>> (O_S12): Ditto.
>>> (O_S16): Ditto.
>>> (O_S32): Ditto.
>>> (O_ELEM): Ditto.
>>> (O_LIT): Ditto.
>>> (OB_DEF_VAR): Add operand constraints.
>>> (B_DEF): Ditto.
>>> * config/s390/s390.cc (s390_const_operand_ok): Honour 64 bit
>>> operands.
>>> ---
>>>  gcc/config/s390/s390-builtins.def | 60 ++-
>>>  gcc/config/s390/s390.cc   |  6 ++--
>>>  2 files changed, 39 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/gcc/config/s390/s390-builtins.def 
>>> b/gcc/config/s390/s390-builtins.def
>>> index a16983b18bd..c829f445a11 100644
>>> --- a/gcc/config/s390/s390-builtins.def
>>> +++ b/gcc/config/s390/s390-builtins.def
>>> @@ -28,6 +28,7 @@
>>>  #undef O_U12
>>>  #undef O_U16
>>>  #undef O_U32
>>> +#undef O_U64
>>>  
>>>  #undef O_M12
>>>  
>>> @@ -88,6 +89,11 @@
>>>  #undef O3_U32
>>>  #undef O4_U32
>>>  
>>> +#undef O1_U64
>>> +#undef O2_U64
>>> +#undef O3_U64
>>> +#undef O4_U64
>>> +
>>>  #undef O1_M12
>>>  #undef O2_M12
>>>  #undef O3_M12
>>> @@ -157,20 +163,21 @@
>>>  #define O_U127 /* unsigned 16 bit literal */
>>>  #define O_U168 /* unsigned 16 bit literal */
>>>  #define O_U329 /* unsigned 32 bit literal */
>>> +#define O_U64   10 /* unsigned 64 bit literal */
>>>  
>>> -#define O_M12   10 /* matches bitmask of 12 */
>>> +#define O_M12   11 /* matches bitmask of 12 */
>>>  
>>> -#define O_S211 /* signed  2 bit literal */
>>> -#define O_S312 /* signed  3 bit literal */
>>> -#define O_S413 /* signed  4 bit literal */
>>> -#define O_S514 /* signed  5 bit literal */
>>> -#define O_S815 /* signed  8 bit literal */
>>> -#define O_S12   16 /* signed 12 bit literal */
>>> -#define O_S16   17 /* signed 16 bit literal */
>>> -#define O_S32   18 /* signed 32 bit literal */
>>> +#define O_S212 /* signed  2 bit literal */
>>> +#define O_S313 /* signed  3 bit literal */
>>> +#define O_S414 /* signed  4 bit literal */
>>> +#define O_S515 /* signed  5 bit literal */
>>> +#define O_S816 /* signed  8 bit literal */
>>> +#define O_S12   17 /* signed 12 bit literal */
>>> +#define O_S16   18 /* signed 16 bit literal */
>>> +#define O_S32   19 /* signed 32 bit literal */
>>>  
>>> -#define O_ELEM  19 /* Element selector requiring modulo arithmetic. */
>>> -#define O_LIT   20 /* Operand must be a literal fitting the target type.  
>>> */
>>> +#define O_ELEM  20 /* Element selector requiring modulo arithmetic. */
>>> +#define O_LIT   21 /* Operand must be a literal fitting the target type.  
>>> */
>>>  
>>>  #define O_SHIFT 5
>>>  
>>> @@ -223,6 +230,11 @@
>>>  #define O3_U32 (O_U32 << (2 * O_SHIFT))
>>>  #define O4_U32 (O_U32 << (3 * O_SHIFT))
>>>  
>>> +#define O1_U64 O_U64
>>> +#define O2_U64 (O_U64 << O_SHIFT)
>>> +#define O3_U64 (O_U64 << (2 * O_SHIFT))
>>> +#define O4_U64 (O_U64 << (3 * O_SHIFT))
>>> +
>>>  #define O1_M12 O_M12
>>>  #define O2_M12 (O_M12 << O_SHIFT)
>>>  #define O3_M12 (O_M12 << (2 * O_SHIFT))
>>> @@ -1989,19 +2001,19 @@ B_DEF  (s390_verllvf,   vrotlv4si3, 
>>> 0,
>>>  B_DEF  (s390_verllvg,   vrotlv2di3, 0, 
>>>  B_VX,   0,  BT_FN_UV2DI_UV2DI_UV2DI)
>>>  
>>>  OB_DEF (s390_vec_rli,   s390_vec_rli_u8,
>>> s390_vec_rli_s64,   B_VX,   BT_FN_OV4SI_OV4SI_ULONG)
>>> -OB_DEF_VAR (s390_vec_rli_u8,s390_verllb,0, 
>>>  0,  BT_OV_UV16QI_UV16QI_ULONG)
>>> -OB_DEF_VAR (s390_vec_rli_s8,s390_verllb,0, 
>>>  0,  BT_OV_V16QI_V16QI_ULONG)

Re: [PATCH] libstdc++ Use _GLIBCXX_USE_BUILTIN_TRAIT

2023-09-11 Thread Patrick Palka via Gcc-patches
On Mon, 11 Sep 2023, Ken Matsui via Gcc-patches wrote:

> This patch uses _GLIBCXX_USE_BUILTIN_TRAIT macro instead of __has_builtin in
> the type_traits header for traits that have a corresponding fallback
> non-built-in implementation. This macro supports to toggle the use of built-in
> traits in the type_traits header through _GLIBCXX_DO_NOT_USE_BUILTIN_TRAITS
> macro, without needing to modify the source code.
> 
> libstdc++-v3/ChangeLog:
> 
>   * include/std/type_traits: Use _GLIBCXX_USE_BUILTIN_TRAIT.

LGTM

> 
> Signed-off-by: Ken Matsui 
> ---
>  libstdc++-v3/include/std/type_traits | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/libstdc++-v3/include/std/type_traits 
> b/libstdc++-v3/include/std/type_traits
> index 677cd934b94..221c809dd6d 100644
> --- a/libstdc++-v3/include/std/type_traits
> +++ b/libstdc++-v3/include/std/type_traits
> @@ -1430,7 +1430,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  : public __bool_constant<__is_base_of(_Base, _Derived)>
>  { };
>  
> -#if __has_builtin(__is_convertible)
> +#if _GLIBCXX_USE_BUILTIN_TRAIT(__is_convertible)
>template
>  struct is_convertible
>  : public __bool_constant<__is_convertible(_From, _To)>
> @@ -1480,7 +1480,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  
>  #ifdef __cpp_lib_is_nothrow_convertible // C++ >= 20
>  
> -#if __has_builtin(__is_nothrow_convertible)
> +#if _GLIBCXX_USE_BUILTIN_TRAIT(__is_nothrow_convertible)
>/// is_nothrow_convertible_v
>template
>  inline constexpr bool is_nothrow_convertible_v
> @@ -1555,7 +1555,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  { using type = _Tp; };
>  
>/// remove_cv
> -#if __has_builtin(__remove_cv)
> +#if _GLIBCXX_USE_BUILTIN_TRAIT(__remove_cv)
>template
>  struct remove_cv
>  { using type = __remove_cv(_Tp); };
> @@ -1621,7 +1621,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>// Reference transformations.
>  
>/// remove_reference
> -#if __has_builtin(__remove_reference)
> +#if _GLIBCXX_USE_BUILTIN_TRAIT(__remove_reference)
>template
>  struct remove_reference
>  { using type = __remove_reference(_Tp); };
> @@ -3427,7 +3427,7 @@ template
> * @{
> */
>  #ifdef __cpp_lib_remove_cvref // C++ >= 20
> -# if __has_builtin(__remove_cvref)
> +# if _GLIBCXX_USE_BUILTIN_TRAIT(__remove_cvref)
>template
>  struct remove_cvref
>  { using type = __remove_cvref(_Tp); };
> -- 
> 2.42.0
> 
> 



Re: [PATCH 2/2] libstdc++: Add dg-require-thread-fence in several tests

2023-09-11 Thread Christophe Lyon via Gcc-patches
On Mon, 11 Sept 2023 at 17:22, Jonathan Wakely  wrote:

> On Mon, 11 Sept 2023 at 14:57, Christophe Lyon
>  wrote:
> >
> >
> >
> > On Mon, 11 Sept 2023 at 15:12, Jonathan Wakely 
> wrote:
> >>
> >> On Mon, 11 Sept 2023 at 13:36, Christophe Lyon
> >>  wrote:
> >> >
> >> >
> >> >
> >> > On Mon, 11 Sept 2023 at 12:59, Jonathan Wakely 
> wrote:
> >> >>
> >> >> On Sun, 10 Sept 2023 at 20:31, Christophe Lyon
> >> >>  wrote:
> >> >> >
> >> >> > Some targets like arm-eabi with newlib and default settings rely on
> >> >> > __sync_synchronize() to ensure synchronization.  Newlib does not
> >> >> > implement it by default, to make users aware they have to take
> special
> >> >> > care.
> >> >> >
> >> >> > This makes a few tests fail to link.
> >> >>
> >> >> Does this mean those features are unusable on the target, or just
> that
> >> >> users need to provide their own __sync_synchronize to use them?
> >> >
> >> >
> >> > IIUC the user is expected to provide them.
> >> > Looks like we discussed this in the past :-)
> >> > In  https://gcc.gnu.org/legacy-ml/gcc-patches/2016-10/msg01632.html,
> >> > see the pointer to Ramana's comment:
> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02751.html
> >>
> >> Oh yes, thanks for the reminder!
> >>
> >> >
> >> > The default arch for arm-eabi is armv4t which is very old.
> >> > When running the testsuite with something more recent (either as
> default by configuring GCC --with-arch=XXX or by forcing -march/-mcpu via
> dejagnu's target-board), the compiler generates barrier instructions and
> there are no such errors.
> >>
> >> Ah yes, that's fine then.
> >>
> >> > For instance, here is a log with the defaults:
> >> >
> https://git.linaro.org/toolchain/ci/base-artifacts/tcwg_gnu_embed_check_gcc/master-arm_eabi.git/tree/00-sumfiles?h=linaro-local/ci/tcwg_gnu_embed_check_gcc/master-arm_eabi
> >> > and a log when we target cortex-m0 which is still a very small cpu
> but has barriers:
> >> >
> https://git.linaro.org/toolchain/ci/base-artifacts/tcwg_gnu_embed_check_gcc/master-thumb_m0_eabi.git/tree/00-sumfiles?h=linaro-local/ci/tcwg_gnu_embed_check_gcc/master-thumb_m0_eabi
> >> >
> >> > I somehow wanted to get rid of such errors with the default
> configuration
> >>
> >> Yep, that makes sense, and we'll still be testing them for newer
> >> arches on the target, so it's not completely disabling those parts of
> >> the testsuite.
> >>
> >> But I'm still curious why some of those tests need this change. I
> >> think the ones I noted below are probably failing for some other
> >> reasons.
> >>
> > Just looked at  23_containers/span/back_assert_neg.cc, the linker says
> it needs
> > arm-eabi/libstdc++-v3/src/.libs/libstdc++.a(debug.o) to resolve
> > ./back_assert_neg-back_assert_neg.o (std::__glibcxx_assert_fail(char
> const*, int, char const*, char const*))
> > and indeed debug.o has a reference to __sync_synchronize
>
> Aha, that's just because I put __glibcxx_assert_fail in debug.o, but
> there are no dependencies on anything else in that file, including the
> _M_detach member function that uses atomics.
>
indeed



> This would also be solved by -Wl,--gc-sections :-)
>
:-)


> I think it would be better to move __glibcxx_assert_fail to a new
> file, so that it doesn't make every assertion unnecessarily depend on
> __sync_synchronize. I'll do that now.
>
Sounds like a good idea, thanks.


> We could also make the atomics in debug.o conditional, so that debug
> mode doesn't depend on __sync_synchronize for single-threaded targets.
> Does the arm4t arch have pthreads support in newlib?  I didn't bother
>
No ( grep _GLIBCXX_HAS_GTHREADS
$objdir/arm-eabi/libstdc++-v3/include/arm-eabi/bits/c++config returns:
/* #undef _GLIBCXX_HAS_GTHREADS */

making the use of atomics conditional, because performance is not
> really a priority for debug mode bookkeeping. But the problem here
> isn't just a slight performance overhead of atomics, it's that they
> aren't even supported for arm4t.
>
OK thanks.

So finally, this uncovered at least a "bug" that  __glibcxx_assert_fail
should be in a dedicated object file :-)

I'll revisit my patch once you have moved __glibcxx_assert_fail

Thanks,

Christophe


[PATCH] libstdc++ Use _GLIBCXX_USE_BUILTIN_TRAIT

2023-09-11 Thread Ken Matsui via Gcc-patches
This patch uses _GLIBCXX_USE_BUILTIN_TRAIT macro instead of __has_builtin in
the type_traits header for traits that have a corresponding fallback
non-built-in implementation. This macro supports to toggle the use of built-in
traits in the type_traits header through _GLIBCXX_DO_NOT_USE_BUILTIN_TRAITS
macro, without needing to modify the source code.

libstdc++-v3/ChangeLog:

* include/std/type_traits: Use _GLIBCXX_USE_BUILTIN_TRAIT.

Signed-off-by: Ken Matsui 
---
 libstdc++-v3/include/std/type_traits | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index 677cd934b94..221c809dd6d 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -1430,7 +1430,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 : public __bool_constant<__is_base_of(_Base, _Derived)>
 { };
 
-#if __has_builtin(__is_convertible)
+#if _GLIBCXX_USE_BUILTIN_TRAIT(__is_convertible)
   template
 struct is_convertible
 : public __bool_constant<__is_convertible(_From, _To)>
@@ -1480,7 +1480,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 #ifdef __cpp_lib_is_nothrow_convertible // C++ >= 20
 
-#if __has_builtin(__is_nothrow_convertible)
+#if _GLIBCXX_USE_BUILTIN_TRAIT(__is_nothrow_convertible)
   /// is_nothrow_convertible_v
   template
 inline constexpr bool is_nothrow_convertible_v
@@ -1555,7 +1555,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 { using type = _Tp; };
 
   /// remove_cv
-#if __has_builtin(__remove_cv)
+#if _GLIBCXX_USE_BUILTIN_TRAIT(__remove_cv)
   template
 struct remove_cv
 { using type = __remove_cv(_Tp); };
@@ -1621,7 +1621,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // Reference transformations.
 
   /// remove_reference
-#if __has_builtin(__remove_reference)
+#if _GLIBCXX_USE_BUILTIN_TRAIT(__remove_reference)
   template
 struct remove_reference
 { using type = __remove_reference(_Tp); };
@@ -3427,7 +3427,7 @@ template
* @{
*/
 #ifdef __cpp_lib_remove_cvref // C++ >= 20
-# if __has_builtin(__remove_cvref)
+# if _GLIBCXX_USE_BUILTIN_TRAIT(__remove_cvref)
   template
 struct remove_cvref
 { using type = __remove_cvref(_Tp); };
-- 
2.42.0



Re: [PATCH 2/2] libstdc++: Add dg-require-thread-fence in several tests

2023-09-11 Thread Richard Earnshaw (lists) via Gcc-patches
On 11/09/2023 16:22, Jonathan Wakely via Gcc-patches wrote:
> On Mon, 11 Sept 2023 at 14:57, Christophe Lyon
>  wrote:
>>
>>
>>
>> On Mon, 11 Sept 2023 at 15:12, Jonathan Wakely  wrote:
>>>
>>> On Mon, 11 Sept 2023 at 13:36, Christophe Lyon
>>>  wrote:



 On Mon, 11 Sept 2023 at 12:59, Jonathan Wakely  wrote:
>
> On Sun, 10 Sept 2023 at 20:31, Christophe Lyon
>  wrote:
>>
>> Some targets like arm-eabi with newlib and default settings rely on
>> __sync_synchronize() to ensure synchronization.  Newlib does not
>> implement it by default, to make users aware they have to take special
>> care.
>>
>> This makes a few tests fail to link.
>
> Does this mean those features are unusable on the target, or just that
> users need to provide their own __sync_synchronize to use them?


 IIUC the user is expected to provide them.
 Looks like we discussed this in the past :-)
 In  https://gcc.gnu.org/legacy-ml/gcc-patches/2016-10/msg01632.html,
 see the pointer to Ramana's comment: 
 https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02751.html
>>>
>>> Oh yes, thanks for the reminder!
>>>

 The default arch for arm-eabi is armv4t which is very old.
 When running the testsuite with something more recent (either as default 
 by configuring GCC --with-arch=XXX or by forcing -march/-mcpu via 
 dejagnu's target-board), the compiler generates barrier instructions and 
 there are no such errors.
>>>
>>> Ah yes, that's fine then.
>>>
 For instance, here is a log with the defaults:
 https://git.linaro.org/toolchain/ci/base-artifacts/tcwg_gnu_embed_check_gcc/master-arm_eabi.git/tree/00-sumfiles?h=linaro-local/ci/tcwg_gnu_embed_check_gcc/master-arm_eabi
 and a log when we target cortex-m0 which is still a very small cpu but has 
 barriers:
 https://git.linaro.org/toolchain/ci/base-artifacts/tcwg_gnu_embed_check_gcc/master-thumb_m0_eabi.git/tree/00-sumfiles?h=linaro-local/ci/tcwg_gnu_embed_check_gcc/master-thumb_m0_eabi

 I somehow wanted to get rid of such errors with the default 
 configuration
>>>
>>> Yep, that makes sense, and we'll still be testing them for newer
>>> arches on the target, so it's not completely disabling those parts of
>>> the testsuite.
>>>
>>> But I'm still curious why some of those tests need this change. I
>>> think the ones I noted below are probably failing for some other
>>> reasons.
>>>
>> Just looked at  23_containers/span/back_assert_neg.cc, the linker says it 
>> needs
>> arm-eabi/libstdc++-v3/src/.libs/libstdc++.a(debug.o) to resolve
>> ./back_assert_neg-back_assert_neg.o (std::__glibcxx_assert_fail(char const*, 
>> int, char const*, char const*))
>> and indeed debug.o has a reference to __sync_synchronize
> 
> Aha, that's just because I put __glibcxx_assert_fail in debug.o, but
> there are no dependencies on anything else in that file, including the
> _M_detach member function that uses atomics.
> 
> This would also be solved by -Wl,--gc-sections :-)
> 
> I think it would be better to move __glibcxx_assert_fail to a new
> file, so that it doesn't make every assertion unnecessarily depend on
> __sync_synchronize. I'll do that now.
> 
> We could also make the atomics in debug.o conditional, so that debug
> mode doesn't depend on __sync_synchronize for single-threaded targets.
> Does the arm4t arch have pthreads support in newlib?  I didn't bother
> making the use of atomics conditional, because performance is not
> really a priority for debug mode bookkeeping. But the problem here
> isn't just a slight performance overhead of atomics, it's that they
> aren't even supported for arm4t.

I might be wrong, but I don't think newlib has any support for pthreads.

R.
> 



RE: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV intrinsic

2023-09-11 Thread Li, Pan2 via Gcc-patches
For function instance with void or void arguments, it is easy as you mentioned 
as below.

For generate API (to get the right hash), you need to build the rvv_type_info, 
predications_type_index and rvv_op_info
from the arglist (aka vec) from hook.

Then we need to construct above parameters from one tree argument. Sorry I not 
sure if I understand correctly but I failed
to locate somewhere has similar usage.

Could you please help to insight me some best practice about the transformation 
from tree to above types?

Pan

From: 钟居哲 
Sent: Monday, September 11, 2023 9:07 PM
To: Li, Pan2 
Cc: kito.cheng ; gcc-patches ; 
Wang, Yanzhang 
Subject: Re: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for 
RVV intrinsic

function_instance
get_read_vl_instance (void)
{
  return function_instance ("read_vl", bases::read_vl, shapes::read_vl,
  none_ops[0], PRED_TYPE_none, _none_void_ops);
}

tree
get_read_vl_decl (void)
{
  function_instance instance = get_read_vl_instance ();
  hashval_t hash = instance.hash ();
  registered_function *rfn = function_table->find_with_hash (instance, hash);
  gcc_assert (rfn);
  return rfn->decl;
}

You should reference it. I don't see why it's hard for use to construct 
instance first, then use that instance hash to get the decl.

juzhe.zh...@rivai.ai

From: Li, Pan2
Date: 2023-09-11 20:26
To: juzhe.zhong
CC: kito.cheng; 
gcc-patches; Wang, 
Yanzhang
Subject: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV 
intrinsic
> No. You must construct instance. 'strcmp' is very ugly.

Strcmp here is defensive code here for early exit if not found (can be removed 
for correctness), which is not required to find the right declaration.

Pan

From: juzhe.zhong mailto:juzhe.zh...@rivai.ai>>
Sent: Monday, September 11, 2023 8:20 PM
To: Li, Pan2 mailto:pan2...@intel.com>>
Cc: kito.cheng mailto:kito.ch...@gmail.com>>; gcc-patches 
mailto:gcc-patches@gcc.gnu.org>>; Wang, Yanzhang 
mailto:yanzhang.w...@intel.com>>
Subject: Re: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV 
intrinsic

No. You must construct instance. 'strcmp' is very ugly.
 Replied Message 
From
Li, Pan2
Date
09/11/2023 20:09
To
juzhe.zh...@rivai.ai,
kito.cheng
Cc
gcc-patches,
Wang, Yanzhang
Subject
RE: Re: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV 
intrinsic
> -if (overloaded_p && instance.pred == PRED_TYPE_m)
> +if (overloaded_p)

Thanks for pointing this out, my misunderstanding for policy function result in 
this change as mistake, will send V2 for this.


> Plz change it into :



Actually, it is not easy to convert to this approach as aarch64 has different 
implementation of types information.

Like type_suffix_info (aarch64 loop type suffix to get the arglist type in 
infer_vector_or_tuple_type) etc.

Thus, it is not easy to construct rvv_type_info, predication_type_index and 
rvv_op_info from arglist, these are required

by function_instance when constructing.



Pan

From: juzhe.zh...@rivai.ai 
mailto:juzhe.zh...@rivai.ai>>
Sent: Monday, September 11, 2023 5:13 PM
To: kito.cheng mailto:kito.ch...@gmail.com>>
Cc: Li, Pan2 mailto:pan2...@intel.com>>; gcc-patches 
mailto:gcc-patches@gcc.gnu.org>>; Wang, Yanzhang 
mailto:yanzhang.w...@intel.com>>
Subject: Re: Re: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for 
RVV intrinsic

>> Just make sure it's the right change?
It seem incorrect to me.

More comments (I just reviewed again):


+tree

+function_resolver::lookup ()

+{

+  unsigned int code_limit = vec_safe_length (registered_functions);

+

+  for (unsigned code = get_sub_code () + 1; code < code_limit; code++)

+{

+  registered_function *rfun = (*registered_functions)[code];

+  function_instance instance = rfun->instance;

+

+  if (strcmp (base_name, instance.base_name) != 0)

+  break;

+

+  if (rfun->overloaded_p)

+  continue;

+

+  unsigned k;

+  const rvv_arg_type_info *args = instance.op_info->args;

+

+  for (k = 0; args[k].base_type != NUM_BASE_TYPES; k++)

+  {

+if (k >= m_arglist.length ())

+  break;

+

+if (TYPE_MODE (instance.get_arg_type (k))

+  != TYPE_MODE (TREE_TYPE (m_arglist[k])))

+  break;

+  }

+

+  if (args[k].base_type == NUM_BASE_TYPES)

+return rfun->decl;

+}

+

+  return NULL_TREE;

+}



Plz change it into :



/* Silently check whether there is an instance of the function with the

   mode suffix given by MODE and the type suffixes given by TYPE0 and TYPE1.

   Return its function decl if so, 

Re: [PATCH 2/2] libstdc++: Add dg-require-thread-fence in several tests

2023-09-11 Thread Jonathan Wakely via Gcc-patches
On Mon, 11 Sept 2023 at 14:57, Christophe Lyon
 wrote:
>
>
>
> On Mon, 11 Sept 2023 at 15:12, Jonathan Wakely  wrote:
>>
>> On Mon, 11 Sept 2023 at 13:36, Christophe Lyon
>>  wrote:
>> >
>> >
>> >
>> > On Mon, 11 Sept 2023 at 12:59, Jonathan Wakely  wrote:
>> >>
>> >> On Sun, 10 Sept 2023 at 20:31, Christophe Lyon
>> >>  wrote:
>> >> >
>> >> > Some targets like arm-eabi with newlib and default settings rely on
>> >> > __sync_synchronize() to ensure synchronization.  Newlib does not
>> >> > implement it by default, to make users aware they have to take special
>> >> > care.
>> >> >
>> >> > This makes a few tests fail to link.
>> >>
>> >> Does this mean those features are unusable on the target, or just that
>> >> users need to provide their own __sync_synchronize to use them?
>> >
>> >
>> > IIUC the user is expected to provide them.
>> > Looks like we discussed this in the past :-)
>> > In  https://gcc.gnu.org/legacy-ml/gcc-patches/2016-10/msg01632.html,
>> > see the pointer to Ramana's comment: 
>> > https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02751.html
>>
>> Oh yes, thanks for the reminder!
>>
>> >
>> > The default arch for arm-eabi is armv4t which is very old.
>> > When running the testsuite with something more recent (either as default 
>> > by configuring GCC --with-arch=XXX or by forcing -march/-mcpu via 
>> > dejagnu's target-board), the compiler generates barrier instructions and 
>> > there are no such errors.
>>
>> Ah yes, that's fine then.
>>
>> > For instance, here is a log with the defaults:
>> > https://git.linaro.org/toolchain/ci/base-artifacts/tcwg_gnu_embed_check_gcc/master-arm_eabi.git/tree/00-sumfiles?h=linaro-local/ci/tcwg_gnu_embed_check_gcc/master-arm_eabi
>> > and a log when we target cortex-m0 which is still a very small cpu but has 
>> > barriers:
>> > https://git.linaro.org/toolchain/ci/base-artifacts/tcwg_gnu_embed_check_gcc/master-thumb_m0_eabi.git/tree/00-sumfiles?h=linaro-local/ci/tcwg_gnu_embed_check_gcc/master-thumb_m0_eabi
>> >
>> > I somehow wanted to get rid of such errors with the default 
>> > configuration
>>
>> Yep, that makes sense, and we'll still be testing them for newer
>> arches on the target, so it's not completely disabling those parts of
>> the testsuite.
>>
>> But I'm still curious why some of those tests need this change. I
>> think the ones I noted below are probably failing for some other
>> reasons.
>>
> Just looked at  23_containers/span/back_assert_neg.cc, the linker says it 
> needs
> arm-eabi/libstdc++-v3/src/.libs/libstdc++.a(debug.o) to resolve
> ./back_assert_neg-back_assert_neg.o (std::__glibcxx_assert_fail(char const*, 
> int, char const*, char const*))
> and indeed debug.o has a reference to __sync_synchronize

Aha, that's just because I put __glibcxx_assert_fail in debug.o, but
there are no dependencies on anything else in that file, including the
_M_detach member function that uses atomics.

This would also be solved by -Wl,--gc-sections :-)

I think it would be better to move __glibcxx_assert_fail to a new
file, so that it doesn't make every assertion unnecessarily depend on
__sync_synchronize. I'll do that now.

We could also make the atomics in debug.o conditional, so that debug
mode doesn't depend on __sync_synchronize for single-threaded targets.
Does the arm4t arch have pthreads support in newlib?  I didn't bother
making the use of atomics conditional, because performance is not
really a priority for debug mode bookkeeping. But the problem here
isn't just a slight performance overhead of atomics, it's that they
aren't even supported for arm4t.



Re: [PATCH v2] libstdc++: Define _GLIBCXX_HAS_BUILTIN_TRAIT

2023-09-11 Thread Ken Matsui via Gcc-patches
On Mon, Sep 11, 2023 at 7:51 AM Jonathan Wakely  wrote:
>
> On Thu, 31 Aug 2023 at 13:33, Ken Matsui  wrote:
> >
> > On Tue, Aug 8, 2023 at 1:23 PM Jonathan Wakely  wrote:
> > >
> > >
> > >
> > > On Wed, 19 Jul 2023 at 20:33, Ken Matsui via Libstdc++ 
> > >  wrote:
> > >>
> > >> This patch defines _GLIBCXX_HAS_BUILTIN_TRAIT macro, which will be used
> > >> as a flag to toggle the use of built-in traits in the type_traits header
> > >> through _GLIBCXX_NO_BUILTIN_TRAITS macro, without needing to modify the
> > >> source code.
> > >>
> > >> libstdc++-v3/ChangeLog:
> > >>
> > >> * include/bits/c++config (_GLIBCXX_HAS_BUILTIN_TRAIT): Define.
> > >> (_GLIBCXX_HAS_BUILTIN): Keep defined.
> > >
> > >
> > > I think this would be a little better as:
> > >
> > > * include/bits/c++config (_GLIBCXX_HAS_BUILTIN): Do not undef.
> > > (_GLIBCXX_HAS_BUILTIN_TRAIT): Define.
> > >
> > > OK for trunk with that change, thanks.
> > >
> > Thank you for your review! Patrick and I were discussing the naming
> > conventions for the macros _GLIBCXX_HAS_BUILTIN_TRAIT and
> > _GLIBCXX_NO_BUILTIN_TRAITS. It was brought to our attention that these
> > namings might be ambiguous, as there are implementations that have
> > corresponding built-ins but do not have fallback. Therefore, we
> > believe that using _GLIBCXX_USE_BUILTIN_TRAIT instead of
> > _GLIBCXX_HAS_BUILTIN_TRAIT would be more appropriate. Similarly, we
> > think that _GLIBCXX_AVOID_BUILTIN_TRAITS would be a better choice than
> > _GLIBCXX_NO_BUILTIN_TRAITS, as the latter implies that there are no
> > built-ins, when in fact it is meant to express that the use of
> > built-ins should be avoided when defining this macro. Could you please
> > let me know your thoughts on these updated namings?
>
> Yes, I agree that makes sense. I think personally I'd go with
> "DISABLE" instead of "AVOID", or even "DO_NOT_USE" (to mirror "USE" in
> the macro for individual traits), but either is OK.

I like the idea of mirroring "USE", so I would choose "DO_NOT_USE".
Thank you for your response!

> > >
> > >>
> > >>
> > >> Signed-off-by: Ken Matsui 
> > >> ---
> > >>  libstdc++-v3/include/bits/c++config | 10 +-
> > >>  1 file changed, 9 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/libstdc++-v3/include/bits/c++config 
> > >> b/libstdc++-v3/include/bits/c++config
> > >> index dd47f274d5f..984985d6fff 100644
> > >> --- a/libstdc++-v3/include/bits/c++config
> > >> +++ b/libstdc++-v3/include/bits/c++config
> > >> @@ -854,7 +854,15 @@ namespace __gnu_cxx
> > >>  # define _GLIBCXX_HAVE_BUILTIN_LAUNDER 1
> > >>  #endif
> > >>
> > >> -#undef _GLIBCXX_HAS_BUILTIN
> > >> +// Returns 1 if _GLIBCXX_NO_BUILTIN_TRAITS is not defined and the 
> > >> compiler
> > >> +// has a corresponding built-in type trait, 0 otherwise.
> > >> +// _GLIBCXX_NO_BUILTIN_TRAITS can be defined to disable the use of 
> > >> built-in
> > >> +// traits.
> > >> +#ifndef _GLIBCXX_NO_BUILTIN_TRAITS
> > >> +# define _GLIBCXX_HAS_BUILTIN_TRAIT(BT) _GLIBCXX_HAS_BUILTIN(BT)
> > >> +#else
> > >> +# define _GLIBCXX_HAS_BUILTIN_TRAIT(BT) 0
> > >> +#endif
> > >>
> > >>  // Mark code that should be ignored by the compiler, but seen by 
> > >> Doxygen.
> > >>  #define _GLIBCXX_DOXYGEN_ONLY(X)
> > >> --
> > >> 2.41.0
> > >>
> >
>


Re: [PATCH v2] libstdc++: Define _GLIBCXX_HAS_BUILTIN_TRAIT

2023-09-11 Thread Jonathan Wakely via Gcc-patches
On Thu, 31 Aug 2023 at 13:33, Ken Matsui  wrote:
>
> On Tue, Aug 8, 2023 at 1:23 PM Jonathan Wakely  wrote:
> >
> >
> >
> > On Wed, 19 Jul 2023 at 20:33, Ken Matsui via Libstdc++ 
> >  wrote:
> >>
> >> This patch defines _GLIBCXX_HAS_BUILTIN_TRAIT macro, which will be used
> >> as a flag to toggle the use of built-in traits in the type_traits header
> >> through _GLIBCXX_NO_BUILTIN_TRAITS macro, without needing to modify the
> >> source code.
> >>
> >> libstdc++-v3/ChangeLog:
> >>
> >> * include/bits/c++config (_GLIBCXX_HAS_BUILTIN_TRAIT): Define.
> >> (_GLIBCXX_HAS_BUILTIN): Keep defined.
> >
> >
> > I think this would be a little better as:
> >
> > * include/bits/c++config (_GLIBCXX_HAS_BUILTIN): Do not undef.
> > (_GLIBCXX_HAS_BUILTIN_TRAIT): Define.
> >
> > OK for trunk with that change, thanks.
> >
> Thank you for your review! Patrick and I were discussing the naming
> conventions for the macros _GLIBCXX_HAS_BUILTIN_TRAIT and
> _GLIBCXX_NO_BUILTIN_TRAITS. It was brought to our attention that these
> namings might be ambiguous, as there are implementations that have
> corresponding built-ins but do not have fallback. Therefore, we
> believe that using _GLIBCXX_USE_BUILTIN_TRAIT instead of
> _GLIBCXX_HAS_BUILTIN_TRAIT would be more appropriate. Similarly, we
> think that _GLIBCXX_AVOID_BUILTIN_TRAITS would be a better choice than
> _GLIBCXX_NO_BUILTIN_TRAITS, as the latter implies that there are no
> built-ins, when in fact it is meant to express that the use of
> built-ins should be avoided when defining this macro. Could you please
> let me know your thoughts on these updated namings?

Yes, I agree that makes sense. I think personally I'd go with
"DISABLE" instead of "AVOID", or even "DO_NOT_USE" (to mirror "USE" in
the macro for individual traits), but either is OK.

> >
> >>
> >>
> >> Signed-off-by: Ken Matsui 
> >> ---
> >>  libstdc++-v3/include/bits/c++config | 10 +-
> >>  1 file changed, 9 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libstdc++-v3/include/bits/c++config 
> >> b/libstdc++-v3/include/bits/c++config
> >> index dd47f274d5f..984985d6fff 100644
> >> --- a/libstdc++-v3/include/bits/c++config
> >> +++ b/libstdc++-v3/include/bits/c++config
> >> @@ -854,7 +854,15 @@ namespace __gnu_cxx
> >>  # define _GLIBCXX_HAVE_BUILTIN_LAUNDER 1
> >>  #endif
> >>
> >> -#undef _GLIBCXX_HAS_BUILTIN
> >> +// Returns 1 if _GLIBCXX_NO_BUILTIN_TRAITS is not defined and the compiler
> >> +// has a corresponding built-in type trait, 0 otherwise.
> >> +// _GLIBCXX_NO_BUILTIN_TRAITS can be defined to disable the use of 
> >> built-in
> >> +// traits.
> >> +#ifndef _GLIBCXX_NO_BUILTIN_TRAITS
> >> +# define _GLIBCXX_HAS_BUILTIN_TRAIT(BT) _GLIBCXX_HAS_BUILTIN(BT)
> >> +#else
> >> +# define _GLIBCXX_HAS_BUILTIN_TRAIT(BT) 0
> >> +#endif
> >>
> >>  // Mark code that should be ignored by the compiler, but seen by Doxygen.
> >>  #define _GLIBCXX_DOXYGEN_ONLY(X)
> >> --
> >> 2.41.0
> >>
>



Re: [PATH] [CLEANUP] Remove trailing whitespace characters

2023-09-11 Thread Arthur Cohen

On 9/11/23 16:43, Eric Gallager via Gcc-patches wrote:

On Mon, Sep 11, 2023 at 9:43 AM Jakub Jelinek via Gcc-patches
 wrote:


On Mon, Sep 11, 2023 at 09:27:48AM -0400, David Malcolm via Gcc-patches wrote:

On Sun, 2023-09-10 at 16:36 +0200, Guillaume Gomez wrote:

When going through the code, I saw a lot of trailing whitespace
characters so I decided to write a small script that would remove
them. I didn't expect there would be so many though... Not sure if
patch with so many changes are accepted like this or if I should send
more focused one.


I'm not sure either.

Some notes on the patch:


IMHO testsuite shouldn't be touched at all, there are certainly tests
which test whether such sources are handled correctly.

Non-C/C++ sources shouldn't be changed this way either.

The ^L stuff should be preserved, not removed.

And even with that, I'm not sure it is a good idea to change it because
it will be a nightmare for git blame.



Some git hosting services have added support for special files to
ignore revisions like this in git blame, for example, on GitHub, it's
called .git-blame-ignore-revs:
https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/
See for example:
https://github.com/cooljeanius/highlight.js/blob/main/.git-blame-ignore-revs


This is also something you can setup locally, without changing the remote:

`git config blame.ignoreRevsFile `

so this could be a good step to add to the `gcc-git-customization.sh` 
script if such a file was created.



The usual way of fixing up formatting if it was committed in a broken way
is only when one is touching with real code changes something, fixing up
formatting on it or around it is fine.

If we decide to fix formatting in bulk, I think we should have a flag day
and change also other formatting mistakes at the same time (say 8 spaces
instead of tabs for start of line indentation (before first non-blank
character), = at the end of line except for static var initializers, etc.
But to make that worthwhile, it would be better to then have a pre-commit
hook that would enforce formatting.  And, we haven't managed to come up with
something like that yet.

 Jakub


Kindly,

Arthur


OpenPGP_0x1B3465B044AD9C65.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATH] [CLEANUP] Remove trailing whitespace characters

2023-09-11 Thread Eric Gallager via Gcc-patches
On Mon, Sep 11, 2023 at 9:43 AM Jakub Jelinek via Gcc-patches
 wrote:
>
> On Mon, Sep 11, 2023 at 09:27:48AM -0400, David Malcolm via Gcc-patches wrote:
> > On Sun, 2023-09-10 at 16:36 +0200, Guillaume Gomez wrote:
> > > When going through the code, I saw a lot of trailing whitespace
> > > characters so I decided to write a small script that would remove
> > > them. I didn't expect there would be so many though... Not sure if
> > > patch with so many changes are accepted like this or if I should send
> > > more focused one.
> >
> > I'm not sure either.
> >
> > Some notes on the patch:
>
> IMHO testsuite shouldn't be touched at all, there are certainly tests
> which test whether such sources are handled correctly.
>
> Non-C/C++ sources shouldn't be changed this way either.
>
> The ^L stuff should be preserved, not removed.
>
> And even with that, I'm not sure it is a good idea to change it because
> it will be a nightmare for git blame.
>

Some git hosting services have added support for special files to
ignore revisions like this in git blame, for example, on GitHub, it's
called .git-blame-ignore-revs:
https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/
See for example:
https://github.com/cooljeanius/highlight.js/blob/main/.git-blame-ignore-revs

> The usual way of fixing up formatting if it was committed in a broken way
> is only when one is touching with real code changes something, fixing up
> formatting on it or around it is fine.
>
> If we decide to fix formatting in bulk, I think we should have a flag day
> and change also other formatting mistakes at the same time (say 8 spaces
> instead of tabs for start of line indentation (before first non-blank
> character), = at the end of line except for static var initializers, etc.
> But to make that worthwhile, it would be better to then have a pre-commit
> hook that would enforce formatting.  And, we haven't managed to come up with
> something like that yet.
>
> Jakub
>


[COMMITTED] gccrs: move functions from rust-gcc-diagnostics to rust-diagnostics.cc

2023-09-11 Thread Arthur Cohen
From: Parthib <94271200+parthib...@users.noreply.github.com>

gcc/rust/ChangeLog:

* Make-lang.in: Removed rust-gcc-diagnostics object file.
* rust-diagnostics.cc (rust_be_get_quotechars): Added from original 
file.
(rust_be_internal_error_at): Likewise.
(rust_be_error_at): Likewise.
(class rust_error_code_rule): Likewise.
(rust_be_warning_at): Likewise.
(rust_be_fatal_error): Likewise.
(rust_be_inform): Likewise.
(rust_be_debug_p): Likewise.

* rust-gcc-diagnostics.cc: Removed.

Signed-off-by: Parthib Datta 

Tested on x86-64 Linux

---
 gcc/rust/Make-lang.in|   1 -
 gcc/rust/rust-diagnostics.cc |  95 +
 gcc/rust/rust-gcc-diagnostics.cc | 117 ---
 3 files changed, 95 insertions(+), 118 deletions(-)
 delete mode 100644 gcc/rust/rust-gcc-diagnostics.cc

diff --git a/gcc/rust/Make-lang.in b/gcc/rust/Make-lang.in
index 3ed0c09e0e7..6449f47564d 100644
--- a/gcc/rust/Make-lang.in
+++ b/gcc/rust/Make-lang.in
@@ -66,7 +66,6 @@ GRS_OBJS = \
 rust/rust-lang.o \
 rust/rust-object-export.o \
 rust/rust-linemap.o \
-rust/rust-gcc-diagnostics.o \
 rust/rust-diagnostics.o \
 rust/rust-gcc.o \
 rust/rust-token.o \
diff --git a/gcc/rust/rust-diagnostics.cc b/gcc/rust/rust-diagnostics.cc
index f29aec67652..16665b058d1 100644
--- a/gcc/rust/rust-diagnostics.cc
+++ b/gcc/rust/rust-diagnostics.cc
@@ -21,6 +21,9 @@
 #include "rust-system.h"
 #include "rust-diagnostics.h"
 
+#include "options.h"
+#include "diagnostic-metadata.h"
+
 static std::string
 mformat_value ()
 {
@@ -130,6 +133,13 @@ expand_message (const char *fmt, va_list ap)
 static const char *cached_open_quote = NULL;
 static const char *cached_close_quote = NULL;
 
+void
+rust_be_get_quotechars (const char **open_qu, const char **close_qu)
+{
+  *open_qu = open_quote;
+  *close_qu = close_quote;
+}
+
 const char *
 rust_open_quote ()
 {
@@ -146,6 +156,16 @@ rust_close_quote ()
   return cached_close_quote;
 }
 
+void
+rust_be_internal_error_at (const Location location, const std::string )
+{
+  std::string loc_str = Linemap::location_to_string (location);
+  if (loc_str.empty ())
+internal_error ("%s", errmsg.c_str ());
+  else
+internal_error ("at %s, %s", loc_str.c_str (), errmsg.c_str ());
+}
+
 void
 rust_internal_error_at (const Location location, const char *fmt, ...)
 {
@@ -156,6 +176,13 @@ rust_internal_error_at (const Location location, const 
char *fmt, ...)
   va_end (ap);
 }
 
+void
+rust_be_error_at (const Location location, const std::string )
+{
+  location_t gcc_loc = location.gcc_location ();
+  error_at (gcc_loc, "%s", errmsg.c_str ());
+}
+
 void
 rust_error_at (const Location location, const char *fmt, ...)
 {
@@ -166,6 +193,38 @@ rust_error_at (const Location location, const char *fmt, 
...)
   va_end (ap);
 }
 
+class rust_error_code_rule : public diagnostic_metadata::rule
+{
+public:
+  rust_error_code_rule (const ErrorCode code) : m_code (code) {}
+
+  char *make_description () const final override
+  {
+return xstrdup (m_code.m_str);
+  }
+
+  char *make_url () const final override
+  {
+return concat ("https://doc.rust-lang.org/error-index.html#;, m_code.m_str,
+  NULL);
+  }
+
+private:
+  const ErrorCode m_code;
+};
+
+void
+rust_be_error_at (const RichLocation , const ErrorCode code,
+ const std::string )
+{
+  /* TODO: 'error_at' would like a non-'const' 'rich_location *'.  */
+  rich_location _loc = const_cast (location.get ());
+  diagnostic_metadata m;
+  rust_error_code_rule rule (code);
+  m.add_rule (rule);
+  error_meta (_loc, m, "%s", errmsg.c_str ());
+}
+
 void
 rust_error_at (const RichLocation , const ErrorCode code,
   const char *fmt, ...)
@@ -177,6 +236,14 @@ rust_error_at (const RichLocation , const 
ErrorCode code,
   va_end (ap);
 }
 
+void
+rust_be_warning_at (const Location location, int opt,
+   const std::string )
+{
+  location_t gcc_loc = location.gcc_location ();
+  warning_at (gcc_loc, opt, "%s", warningmsg.c_str ());
+}
+
 void
 rust_warning_at (const Location location, int opt, const char *fmt, ...)
 {
@@ -187,6 +254,13 @@ rust_warning_at (const Location location, int opt, const 
char *fmt, ...)
   va_end (ap);
 }
 
+void
+rust_be_fatal_error (const Location location, const std::string )
+{
+  location_t gcc_loc = location.gcc_location ();
+  fatal_error (gcc_loc, "%s", fatalmsg.c_str ());
+}
+
 void
 rust_fatal_error (const Location location, const char *fmt, ...)
 {
@@ -197,6 +271,13 @@ rust_fatal_error (const Location location, const char 
*fmt, ...)
   va_end (ap);
 }
 
+void
+rust_be_inform (const Location location, const std::string )
+{
+  location_t gcc_loc = location.gcc_location ();
+  inform (gcc_loc, "%s", infomsg.c_str ());
+}
+
 void
 rust_inform (const Location location, const char *fmt, 

  1   2   >