Re: [PATCH] RISC-V: Use dominance analysis in global vsetvl elimination

[Kito Cheng via Gcc-patches]

LGTM, and I guess you will remove get_all_predecessors once LMUL cost
model can use dominator info as well?


On Mon, Sep 11, 2023 at 11:34 AM Juzhe-Zhong  wrote:
>
> I found that it's more reasonable to use existing dominance analysis.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vsetvl.cc 
> (pass_vsetvl::global_eliminate_vsetvl_insn): Use dominance analysis.
> (pass_vsetvl::init): Ditto.
> (pass_vsetvl::done): Ditto.
>
> ---
>  gcc/config/riscv/riscv-vsetvl.cc | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config/riscv/riscv-vsetvl.cc 
> b/gcc/config/riscv/riscv-vsetvl.cc
> index 134b97737ae..f81361c4ccd 100644
> --- a/gcc/config/riscv/riscv-vsetvl.cc
> +++ b/gcc/config/riscv/riscv-vsetvl.cc
> @@ -4054,7 +4054,7 @@ pass_vsetvl::global_eliminate_vsetvl_insn (const 
> bb_info *bb) const
>  }
>
>/* Step1: Reshape the VL/VTYPE status to make sure everything compatible.  
> */
> -  hash_set pred_cfg_bbs = get_all_predecessors (cfg_bb);
> +  auto_vec pred_cfg_bbs = get_dominated_by 
> (CDI_POST_DOMINATORS, cfg_bb);
>FOR_EACH_EDGE (e, ei, cfg_bb->preds)
>  {
>sbitmap avout = m_vector_manager->vector_avout[e->src->index];
> @@ -4243,6 +4243,7 @@ pass_vsetvl::init (void)
>  {
>/* Initialization of RTL_SSA.  */
>calculate_dominance_info (CDI_DOMINATORS);
> +  calculate_dominance_info (CDI_POST_DOMINATORS);
>df_analyze ();
>crtl->ssa = new function_info (cfun);
>  }
> @@ -4264,6 +4265,7 @@ pass_vsetvl::done (void)
>  {
>/* Finalization of RTL_SSA.  */
>free_dominance_info (CDI_DOMINATORS);
> +  free_dominance_info (CDI_POST_DOMINATORS);
>if (crtl->ssa->perform_pending_updates ())
> cleanup_cfg (0);
>delete crtl->ssa;
> --
> 2.36.3
>

Re: Re: [PATCH] RISC-V: Use dominance analysis in global vsetvl elimination

[juzhe.zh...@rivai.ai]

Committed. Thanks kito.


>> I guess you will remove get_all_predecessors once LMUL cost
>> model can use dominator info as well?
Yes. I am trying but there is a failed case for dynamic LMUL.
Not sure whether it can work now.



juzhe.zh...@rivai.ai
 
From: Kito Cheng
Date: 2023-09-11 15:03
To: Juzhe-Zhong
CC: gcc-patches; kito.cheng
Subject: Re: [PATCH] RISC-V: Use dominance analysis in global vsetvl elimination
LGTM, and I guess you will remove get_all_predecessors once LMUL cost
model can use dominator info as well?
 
 
On Mon, Sep 11, 2023 at 11:34 AM Juzhe-Zhong  wrote:
>
> I found that it's more reasonable to use existing dominance analysis.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vsetvl.cc 
> (pass_vsetvl::global_eliminate_vsetvl_insn): Use dominance analysis.
> (pass_vsetvl::init): Ditto.
> (pass_vsetvl::done): Ditto.
>
> ---
>  gcc/config/riscv/riscv-vsetvl.cc | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config/riscv/riscv-vsetvl.cc 
> b/gcc/config/riscv/riscv-vsetvl.cc
> index 134b97737ae..f81361c4ccd 100644
> --- a/gcc/config/riscv/riscv-vsetvl.cc
> +++ b/gcc/config/riscv/riscv-vsetvl.cc
> @@ -4054,7 +4054,7 @@ pass_vsetvl::global_eliminate_vsetvl_insn (const 
> bb_info *bb) const
>  }
>
>/* Step1: Reshape the VL/VTYPE status to make sure everything compatible.  
> */
> -  hash_set pred_cfg_bbs = get_all_predecessors (cfg_bb);
> +  auto_vec pred_cfg_bbs = get_dominated_by 
> (CDI_POST_DOMINATORS, cfg_bb);
>FOR_EACH_EDGE (e, ei, cfg_bb->preds)
>  {
>sbitmap avout = m_vector_manager->vector_avout[e->src->index];
> @@ -4243,6 +4243,7 @@ pass_vsetvl::init (void)
>  {
>/* Initialization of RTL_SSA.  */
>calculate_dominance_info (CDI_DOMINATORS);
> +  calculate_dominance_info (CDI_POST_DOMINATORS);
>df_analyze ();
>crtl->ssa = new function_info (cfun);
>  }
> @@ -4264,6 +4265,7 @@ pass_vsetvl::done (void)
>  {
>/* Finalization of RTL_SSA.  */
>free_dominance_info (CDI_DOMINATORS);
> +  free_dominance_info (CDI_POST_DOMINATORS);
>if (crtl->ssa->perform_pending_updates ())
> cleanup_cfg (0);
>delete crtl->ssa;
> --
> 2.36.3
>
 

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

[Pan Li via Gcc-patches]

From: Pan Li 

This patch would like add the framework to support the RVV overloaded
intrinsic API in riscv-xxx-xxx-gcc, like riscv-xxx-xxx-g++ did.

However, it almost leverage the hook TARGET_RESOLVE_OVERLOADED_BUILTIN
with below steps.

* Register overloaded functions.
* Add function_resolver for overloaded function resolving.
* Add resolve API for function shape with default implementation.
* Implement HOOK for navigating the overloaded API to non-overloaded API.

We validated this framework by the vmv_v intrinsic API(s), and we will
add more intrins API support in the underlying patches.

gcc/ChangeLog:

* config/riscv/riscv-c.cc
(riscv_resolve_overloaded_builtin): New function for the hook.
(riscv_register_pragmas): Register the hook
* config/riscv/riscv-protos.h (resolve_overloaded_builtin): New decl.
* config/riscv/riscv-vector-builtins-shapes.cc (build_one):
Register overloaded function.
(struct overloaded_base): New struct for overloaded shape.
(struct non_overloaded_base): New struct for non overloaded shape.
(struct move_def): Inherit overloaded shape.
* config/riscv/riscv-vector-builtins.cc
(function_builder::add_function): Add overloaded arg.
(function_builder::add_overloaded_function): New function impl.
(function_resolver::function_resolver): New constructor.
(function_resolver::get_sub_code): New API impl.
(function_resolver::resolve): New API impl.
(function_resolver::lookup): New API impl.
(resolve_overloaded_builtin): New func impl.
* config/riscv/riscv-vector-builtins.h
(class function_resolver): New class.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/overloaded_rv32_vmv_v.c: New test.
* gcc.target/riscv/rvv/base/overloaded_rv64_vmv_v.c: New test.
* gcc.target/riscv/rvv/base/overloaded_vmv_v.h: New test.

Signed-off-by: Pan Li 
---
 gcc/config/riscv/riscv-c.cc   |  36 +
 gcc/config/riscv/riscv-protos.h   |   1 +
 .../riscv/riscv-vector-builtins-shapes.cc |  22 ++-
 gcc/config/riscv/riscv-vector-builtins.cc | 138 +-
 gcc/config/riscv/riscv-vector-builtins.h  |  30 +++-
 .../riscv/rvv/base/overloaded_rv32_vmv_v.c|   4 +
 .../riscv/rvv/base/overloaded_rv64_vmv_v.c|   4 +
 .../riscv/rvv/base/overloaded_vmv_v.h |  17 +++
 8 files changed, 248 insertions(+), 4 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/base/overloaded_rv32_vmv_v.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/base/overloaded_rv64_vmv_v.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/overloaded_vmv_v.h

diff --git a/gcc/config/riscv/riscv-c.cc b/gcc/config/riscv/riscv-c.cc
index 283052ae313..060edd3129d 100644
--- a/gcc/config/riscv/riscv-c.cc
+++ b/gcc/config/riscv/riscv-c.cc
@@ -220,11 +220,47 @@ riscv_check_builtin_call (location_t loc, vec 
arg_loc, tree fndecl,
   gcc_unreachable ();
 }
 
+/* Implement TARGET_RESOLVE_OVERLOADED_BUILTIN.  */
+static tree
+riscv_resolve_overloaded_builtin (unsigned int uncast_location, tree fndecl,
+ void *uncast_arglist)
+{
+  vec empty = {};
+  location_t loc = (location_t) uncast_location;
+  vec *arglist = (vec *) uncast_arglist;
+  unsigned int code = DECL_MD_FUNCTION_CODE (fndecl);
+  unsigned int subcode = code >> RISCV_BUILTIN_SHIFT;
+  tree new_fndecl = NULL_TREE;
+
+  if (!arglist)
+arglist = ∅
+
+  switch (code & RISCV_BUILTIN_CLASS)
+{
+case RISCV_BUILTIN_GENERAL:
+  break;
+case RISCV_BUILTIN_VECTOR:
+  new_fndecl = riscv_vector::resolve_overloaded_builtin (loc, subcode,
+arglist);
+  break;
+default:
+  gcc_unreachable ();
+}
+
+  if (new_fndecl == NULL_TREE)
+return new_fndecl;
+
+  return build_function_call_vec (loc, vNULL, new_fndecl, arglist, NULL,
+ fndecl);
+}
+
 /* Implement REGISTER_TARGET_PRAGMAS.  */
 
 void
 riscv_register_pragmas (void)
 {
+  targetm.resolve_overloaded_builtin = riscv_resolve_overloaded_builtin;
   targetm.check_builtin_call = riscv_check_builtin_call;
+
   c_register_pragma ("riscv", "intrinsic", riscv_pragma_intrinsic);
 }
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 6dbf6b9f943..5d2492dd031 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -381,6 +381,7 @@ gimple *gimple_fold_builtin (unsigned int, 
gimple_stmt_iterator *, gcall *);
 rtx expand_builtin (unsigned int, tree, rtx);
 bool check_builtin_call (location_t, vec, unsigned int,
   tree, unsigned int, tree *);
+tree resolve_overloaded_builtin (location_t, unsigned int, vec *);
 bool const_vec_all_same_in_range_p (rtx, HOST_WIDE_INT, HOST_WIDE_INT);
 bool legitimize_move (rtx, rtx);
 void emit_vlmax_vsetvl (machine_mode

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

[Jiang, Haochen via Gcc-patches]

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 v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV intrinsic

[juzhe.zh...@rivai.ai]

Thanks for supporting it even though I don't like this feature :).
The framework is LGTM.

Let's wait for kito's more comments.



juzhe.zh...@rivai.ai
 
From: pan2.li
Date: 2023-09-11 15:57
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV 
intrinsic
From: Pan Li 
 
This patch would like add the framework to support the RVV overloaded
intrinsic API in riscv-xxx-xxx-gcc, like riscv-xxx-xxx-g++ did.
 
However, it almost leverage the hook TARGET_RESOLVE_OVERLOADED_BUILTIN
with below steps.
 
* Register overloaded functions.
* Add function_resolver for overloaded function resolving.
* Add resolve API for function shape with default implementation.
* Implement HOOK for navigating the overloaded API to non-overloaded API.
 
We validated this framework by the vmv_v intrinsic API(s), and we will
add more intrins API support in the underlying patches.
 
gcc/ChangeLog:
 
* config/riscv/riscv-c.cc
(riscv_resolve_overloaded_builtin): New function for the hook.
(riscv_register_pragmas): Register the hook
* config/riscv/riscv-protos.h (resolve_overloaded_builtin): New decl.
* config/riscv/riscv-vector-builtins-shapes.cc (build_one):
Register overloaded function.
(struct overloaded_base): New struct for overloaded shape.
(struct non_overloaded_base): New struct for non overloaded shape.
(struct move_def): Inherit overloaded shape.
* config/riscv/riscv-vector-builtins.cc
(function_builder::add_function): Add overloaded arg.
(function_builder::add_overloaded_function): New function impl.
(function_resolver::function_resolver): New constructor.
(function_resolver::get_sub_code): New API impl.
(function_resolver::resolve): New API impl.
(function_resolver::lookup): New API impl.
(resolve_overloaded_builtin): New func impl.
* config/riscv/riscv-vector-builtins.h
(class function_resolver): New class.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/base/overloaded_rv32_vmv_v.c: New test.
* gcc.target/riscv/rvv/base/overloaded_rv64_vmv_v.c: New test.
* gcc.target/riscv/rvv/base/overloaded_vmv_v.h: New test.
 
Signed-off-by: Pan Li 
---
gcc/config/riscv/riscv-c.cc   |  36 +
gcc/config/riscv/riscv-protos.h   |   1 +
.../riscv/riscv-vector-builtins-shapes.cc |  22 ++-
gcc/config/riscv/riscv-vector-builtins.cc | 138 +-
gcc/config/riscv/riscv-vector-builtins.h  |  30 +++-
.../riscv/rvv/base/overloaded_rv32_vmv_v.c|   4 +
.../riscv/rvv/base/overloaded_rv64_vmv_v.c|   4 +
.../riscv/rvv/base/overloaded_vmv_v.h |  17 +++
8 files changed, 248 insertions(+), 4 deletions(-)
create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/base/overloaded_rv32_vmv_v.c
create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/base/overloaded_rv64_vmv_v.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/overloaded_vmv_v.h
 
diff --git a/gcc/config/riscv/riscv-c.cc b/gcc/config/riscv/riscv-c.cc
index 283052ae313..060edd3129d 100644
--- a/gcc/config/riscv/riscv-c.cc
+++ b/gcc/config/riscv/riscv-c.cc
@@ -220,11 +220,47 @@ riscv_check_builtin_call (location_t loc, vec 
arg_loc, tree fndecl,
   gcc_unreachable ();
}
+/* Implement TARGET_RESOLVE_OVERLOADED_BUILTIN.  */
+static tree
+riscv_resolve_overloaded_builtin (unsigned int uncast_location, tree fndecl,
+   void *uncast_arglist)
+{
+  vec empty = {};
+  location_t loc = (location_t) uncast_location;
+  vec *arglist = (vec *) uncast_arglist;
+  unsigned int code = DECL_MD_FUNCTION_CODE (fndecl);
+  unsigned int subcode = code >> RISCV_BUILTIN_SHIFT;
+  tree new_fndecl = NULL_TREE;
+
+  if (!arglist)
+arglist = ∅
+
+  switch (code & RISCV_BUILTIN_CLASS)
+{
+case RISCV_BUILTIN_GENERAL:
+  break;
+case RISCV_BUILTIN_VECTOR:
+  new_fndecl = riscv_vector::resolve_overloaded_builtin (loc, subcode,
+  arglist);
+  break;
+default:
+  gcc_unreachable ();
+}
+
+  if (new_fndecl == NULL_TREE)
+return new_fndecl;
+
+  return build_function_call_vec (loc, vNULL, new_fndecl, arglist, NULL,
+   fndecl);
+}
+
/* Implement REGISTER_TARGET_PRAGMAS.  */
void
riscv_register_pragmas (void)
{
+  targetm.resolve_overloaded_builtin = riscv_resolve_overloaded_builtin;
   targetm.check_builtin_call = riscv_check_builtin_call;
+
   c_register_pragma ("riscv", "intrinsic", riscv_pragma_intrinsic);
}
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 6dbf6b9f943..5d2492dd031 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -381,6 +381,7 @@ gimple *gimple_fold_builtin (unsigned int, 
gimple_stmt_iterator *, gcall *);
rtx expand_builtin (unsigned int, tree, rtx);
bool check_builtin_call (location_t, vec, unsigned int,
   tree, unsigned int, tree *);
+tree resolve_overloaded_builtin (location_t, unsigned int, vec *);
bool const_vec_all_same_in_range_p (rtx, HOST_WIDE_INT, HOST_WIDE_INT);
bool legitimize_move (rtx, rtx);
void emit_vlmax_vsetvl (

Re: [PATCH v2] analyzer: Call off a superseding when diagnostics are unrelated [PR110830]

[Andreas Schwab via Gcc-patches]

../../gcc/analyzer/diagnostic-manager.cc: In function 'bool 
ana::compatible_epath_p(const exploded_path*, const exploded_path*)':
../../gcc/analyzer/diagnostic-manager.cc:969:1: warning: control reaches end of 
non-void function [-Wreturn-type]

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

RE: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook

[Li, Pan2 via Gcc-patches]

Hi Jeff,

Kindly ping for the Patch V2 as below.

https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628508.html

Pan

-Original Message-
From: Li, Pan2  
Sent: Friday, August 25, 2023 8:45 PM
To: Li, Pan2 ; Jeff Law ; 
gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Wang, Yanzhang ; 
kito.ch...@gmail.com
Subject: RE: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook

Hi Jeff,

> You might also peek at the RTL gcse/pre code which is also LCM based and 
> has the same class of problems.

I found a similar approach to take care of this in gcse.cc/pre_edge_insert with 
some comments as below.

  /* We can't insert anything on an abnormal and
   critical edge, so we insert the insn at the end of
   the previous block. There are several alternatives
   detailed in Morgans book P277 (sec 10.5) for
   handling this situation.  This one is easiest for
   now.  */

if (eg->flags & EDGE_ABNORMAL)
  insert_insn_end_basic_block (index_map[j], bb);
else
  {
  insn = process_insert_insn (index_map[j]);
  insert_insn_on_edge (insn, eg);
  }

It looks the insert_insn_end_basic_block is designed to handle the ABNORMAL 
edge by inserting at end of previous block from the comments.

Pan

-Original Message-
From: Gcc-patches  On Behalf 
Of Li, Pan2 via Gcc-patches
Sent: Thursday, August 24, 2023 12:54 PM
To: Jeff Law ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Wang, Yanzhang ; 
kito.ch...@gmail.com
Subject: RE: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook

Thanks Jeff.

> That implies a save/restore pair around the call (possibly optimized so 
> that we minimize the number of save/restores).  I would have expected 
> x86 to already be doing this.  But maybe there's some ABI thing around 
> mmx vs x86 state that allows it to be avoided

Very similar to save/restore but optional.
If no static rounding mode instrinsic here, it is unnecessary to add 
save/restore
pair around the call. I bet mode-switching take care of this already.

Pan

-Original Message-
From: Jeff Law  
Sent: Thursday, August 24, 2023 7:27 AM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Wang, Yanzhang ; 
kito.ch...@gmail.com
Subject: Re: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook



On 8/23/23 08:54, Li, Pan2 wrote:
> Thanks Jeff for comments.
> 
>> Understood.  So the natural question is why does x86/sh not need this
>> for its mode switching?   Don't all the same issues exist on those
>> targets as well?
> 
> AFAIK, it comes from the different design principle between the risc-v and 
> x86/arm intrinsic API.
> The risc-v rvv FP rounding mode intrinsic API has one abstract level above 
> the insn itself, while
> the x86/arm only indicates the semantics of the insn.
> 
> For example, if one vector instruction VFADD doesn't have static rounding 
> mode (aka encoding rm in insn),
> there is no such a intrinsic API contains rounding mode argument in x86/arm. 
> While the risc-v fp
> vector intrinsic will always have static rounding mode API if the frm is 
> honored.
> 
> In short, the risc-v intrinsic API is closer to the end-user, while the 
> x86/arm instrinsic API is closer to insn itself.
OK, but I'm still strugging to see how the distinction is important 
here.  Ultimately there's a state at a call site.  We need to make sure 
that state from the current function doesn't impact the callee and we 
need to make sure that the callee doesn't impact the state in the caller.

That implies a save/restore pair around the call (possibly optimized so 
that we minimize the number of save/restores).  I would have expected 
x86 to already be doing this.  But maybe there's some ABI thing around 
mmx vs x86 state that allows it to be avoided

> 
> For the rest part, will have a try based on your suggestion soon as I am in 
> the middle of something.
No problem.  Get to it when you can.  I think it affects you more than 
me :-)

jeff

Re: [PATCH] pretty-print: Fix up pp_wide_int [PR111329]

[Richard Sandiford via Gcc-patches]

Jakub Jelinek  writes:
> Hi!
>
> The recent pp_wide_int changes for _BitInt support (because not all
> wide_ints fit into the small fixed size digit_buffer anymore) apparently
> broke
> +FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c (test for excess 
> errors)
> +FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c 2 blank line(s) in 
> output
> +FAIL: gcc.dg/analyzer/out-of-bounds-diagram-1-debug.c expected multiline 
> pattern lines 17-39
> (and I couldn't reproduce that in bisect seed (which is -O0 compiled) and
> thought it would be some analyzer diagnostic bug).
>
> The problem is that analyzer uses pp_wide_int with a function call in the
> second argument.  Previously, when pp_wide_int macro just did
>   print_dec (W, pp_buffer (PP)->digit_buffer, SGN);
>   pp_string (PP, pp_buffer (PP)->digit_buffer);
> it worked, because the const wide_int_ref & first argument to print_dec
> bound to a temporary, which was only destructed at the end of the full
> statement after print_dec was called.
> But with my changes where I need to first compare the precision of the
> const wide_int_ref & to decide whether to use digit_buffer or XALLOCAVEC
> something larger, this means that pp_wide_int_ref binds to a temporary
> which is destroyed at the end of full statement which is the
>   const wide_int_ref &pp_wide_int_ref = (W);
> declaration, so then invokes UB accessing a destructed temporary.
>
> The following patch fixes it by rewriting pp_wide_int into an inline
> function, so that the end of the full statement is the end of the inline
> function call.  As functions using alloca aren't normally inlined, I've
> also split that part into a separate out of line function.  Putting that
> into pretty-print.cc didn't work, e.g. the gm2 binary doesn't link,
> because pretty-print.o is in libcommon.a, but wide-print-print.o which
> defines print_dec is not.  So I've put that out of line function into
> wide-int-print.cc instead.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2023-09-08  Jakub Jelinek  
>
>   PR middle-end/111329
>   * pretty-print.h (pp_wide_int): Rewrite from macro into inline
>   function.  For printing values which don't fit into digit_buffer
>   use out-of-line function.
>   * wide-int-print.h (pp_wide_int_large): Declare.
>   * wide-int-print.cc: Include pretty-print.h.
>   (pp_wide_int_large): Define.

OK, thanks.

Richard

> --- gcc/pretty-print.h.jj 2023-09-06 14:36:53.485246347 +0200
> +++ gcc/pretty-print.h2023-09-08 11:11:21.173649942 +0200
> @@ -333,28 +333,6 @@ pp_get_prefix (const pretty_printer *pp)
>  #define pp_decimal_int(PP, I)  pp_scalar (PP, "%d", I)
>  #define pp_unsigned_wide_integer(PP, I) \
> pp_scalar (PP, HOST_WIDE_INT_PRINT_UNSIGNED, (unsigned HOST_WIDE_INT) I)
> -#define pp_wide_int(PP, W, SGN)  \
> -  do \
> -{\
> -  const wide_int_ref &pp_wide_int_ref = (W); \
> -  unsigned int pp_wide_int_prec  \
> - = pp_wide_int_ref.get_precision (); \
> -  if ((pp_wide_int_prec + 3) / 4 \
> -   > sizeof (pp_buffer (PP)->digit_buffer) - 3)  \
> - {   \
> -   char *pp_wide_int_buf \
> - = XALLOCAVEC (char, (pp_wide_int_prec + 3) / 4 + 3);\
> -   print_dec (pp_wide_int_ref, pp_wide_int_buf, SGN);\
> -   pp_string (PP, pp_wide_int_buf);  \
> - }   \
> -  else   \
> - {   \
> -   print_dec (pp_wide_int_ref,   \
> -  pp_buffer (PP)->digit_buffer, SGN);\
> -   pp_string (PP, pp_buffer (PP)->digit_buffer); \
> - }   \
> -}\
> -  while (0)
>  #define pp_vrange(PP, R) \
>do \
>  {\
> @@ -453,6 +431,19 @@ pp_wide_integer (pretty_printer *pp, HOS
>pp_scalar (pp, HOST_WIDE_INT_PRINT_DEC, i);
>  }
>  
> +inline void
> +pp_wide_int (pretty_printer *pp, const wide_int_ref &w, signop sgn)
> +{
> +  unsigned int prec = w.get_precision ();
> +  if (UNLIKELY ((prec + 3) / 4 > sizeof (pp_buffer (pp)->digit_buffer) - 3))
> +pp_wide_int_large (pp, w, sgn);
> +  else
> +{
> +  print_dec (w, pp_buffer (pp)->digit_buffer, sgn);
> +  pp_string (pp, pp_buffer (pp)->digit_buffer);
> +}
> +}
> +
>  template
>  voi

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

[Kito Cheng via Gcc-patches]

> @@ -545,7 +563,7 @@ struct move_def : public build_base
>  /* According to rvv-intrinsic-doc, it does not add "_m" suffix
> for vop_m C++ overloaded API.  */
> -if (overloaded_p && instance.pred == PRED_TYPE_m)
> +if (overloaded_p)

Just make sure it's the right change?

>return b.finish_name ();
>  b.append_name (predication_suffixes[instance.pred]);
>  return b.finish_name ();

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

[juzhe.zh...@rivai.ai]

>> 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 return null.  */
tree
function_resolver::lookup_form (mode_suffix_index mode,
type_suffix_index type0,
type_suffix_index type1)
{
  type_suffix_pair types = { type0, type1 };
  function_instance instance (base_name, base, shape, mode, types, pred);
  registered_function *rfn
= function_table->find_with_hash (instance, instance.hash ());
  return rfn ? rfn->decl : NULL_TREE;
}


juzhe.zh...@rivai.ai
 
From: Kito Cheng
Date: 2023-09-11 17:04
To: juzhe.zh...@rivai.ai
CC: pan2.li; gcc-patches; yanzhang.wang
Subject: Re: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV 
intrinsic
> @@ -545,7 +563,7 @@ struct move_def : public build_base
>  /* According to rvv-intrinsic-doc, it does not add "_m" suffix
> for vop_m C++ overloaded API.  */
> -if (overloaded_p && instance.pred == PRED_TYPE_m)
> +if (overloaded_p)
 
Just make sure it's the right change?
 
>return b.finish_name ();
>  b.append_name (predication_suffixes[instance.pred]);
>  return b.finish_name ();
 

[PATCH] RISC-V: Remove redundant functions

[Juzhe-Zhong]

I just finished V2 version of LMUL cost model.
Turns out we don't these redundant functions.

Remove them.

gcc/ChangeLog:

* config/riscv/riscv-protos.h (get_all_predecessors): Remove.
(get_all_successors): Ditto.
* config/riscv/riscv-v.cc (get_all_predecessors): Ditto.
(get_all_successors): Ditto.

---
 gcc/config/riscv/riscv-protos.h |  2 --
 gcc/config/riscv/riscv-v.cc | 48 -
 2 files changed, 50 deletions(-)

diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 46d77ef927c..e91a55ec057 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -498,8 +498,6 @@ enum floating_point_rounding_mode get_frm_mode (rtx);
 opt_machine_mode vectorize_related_mode (machine_mode, scalar_mode,
 poly_uint64);
 unsigned int autovectorize_vector_modes (vec *, bool);
-hash_set get_all_predecessors (basic_block);
-hash_set get_all_successors (basic_block);
 bool cmp_lmul_le_one (machine_mode);
 bool cmp_lmul_gt_one (machine_mode);
 }
diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index 3cd1f61de0e..4d95bd773a2 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -3388,54 +3388,6 @@ expand_fold_extract_last (rtx *ops)
   emit_label (end_label);
 }
 
-hash_set
-get_all_predecessors (basic_block bb)
-{
-  hash_set blocks;
-  auto_vec work_list;
-  hash_set visited_list;
-  work_list.safe_push (bb);
-
-  while (!work_list.is_empty ())
-{
-  basic_block new_bb = work_list.pop ();
-  visited_list.add (new_bb);
-  edge e;
-  edge_iterator ei;
-  FOR_EACH_EDGE (e, ei, new_bb->preds)
-   {
- if (!visited_list.contains (e->src))
-   work_list.safe_push (e->src);
- blocks.add (e->src);
-   }
-}
-  return blocks;
-}
-
-hash_set
-get_all_successors (basic_block bb)
-{
-  hash_set blocks;
-  auto_vec work_list;
-  hash_set visited_list;
-  work_list.safe_push (bb);
-
-  while (!work_list.is_empty ())
-{
-  basic_block new_bb = work_list.pop ();
-  visited_list.add (new_bb);
-  edge e;
-  edge_iterator ei;
-  FOR_EACH_EDGE (e, ei, new_bb->succs)
-   {
- if (!visited_list.contains (e->dest))
-   work_list.safe_push (e->dest);
- blocks.add (e->dest);
-   }
-}
-  return blocks;
-}
-
 /* Return true if the LMUL of comparison less than or equal to one.  */
 bool
 cmp_lmul_le_one (machine_mode mode)
-- 
2.36.3

Re: [PATCH] RISC-V: Remove redundant functions

[Kito Cheng via Gcc-patches]

LGTM

On Mon, Sep 11, 2023 at 5:20 PM Juzhe-Zhong  wrote:
>
> I just finished V2 version of LMUL cost model.
> Turns out we don't these redundant functions.
>
> Remove them.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-protos.h (get_all_predecessors): Remove.
> (get_all_successors): Ditto.
> * config/riscv/riscv-v.cc (get_all_predecessors): Ditto.
> (get_all_successors): Ditto.
>
> ---
>  gcc/config/riscv/riscv-protos.h |  2 --
>  gcc/config/riscv/riscv-v.cc | 48 -
>  2 files changed, 50 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
> index 46d77ef927c..e91a55ec057 100644
> --- a/gcc/config/riscv/riscv-protos.h
> +++ b/gcc/config/riscv/riscv-protos.h
> @@ -498,8 +498,6 @@ enum floating_point_rounding_mode get_frm_mode (rtx);
>  opt_machine_mode vectorize_related_mode (machine_mode, scalar_mode,
>  poly_uint64);
>  unsigned int autovectorize_vector_modes (vec *, bool);
> -hash_set get_all_predecessors (basic_block);
> -hash_set get_all_successors (basic_block);
>  bool cmp_lmul_le_one (machine_mode);
>  bool cmp_lmul_gt_one (machine_mode);
>  }
> diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
> index 3cd1f61de0e..4d95bd773a2 100644
> --- a/gcc/config/riscv/riscv-v.cc
> +++ b/gcc/config/riscv/riscv-v.cc
> @@ -3388,54 +3388,6 @@ expand_fold_extract_last (rtx *ops)
>emit_label (end_label);
>  }
>
> -hash_set
> -get_all_predecessors (basic_block bb)
> -{
> -  hash_set blocks;
> -  auto_vec work_list;
> -  hash_set visited_list;
> -  work_list.safe_push (bb);
> -
> -  while (!work_list.is_empty ())
> -{
> -  basic_block new_bb = work_list.pop ();
> -  visited_list.add (new_bb);
> -  edge e;
> -  edge_iterator ei;
> -  FOR_EACH_EDGE (e, ei, new_bb->preds)
> -   {
> - if (!visited_list.contains (e->src))
> -   work_list.safe_push (e->src);
> - blocks.add (e->src);
> -   }
> -}
> -  return blocks;
> -}
> -
> -hash_set
> -get_all_successors (basic_block bb)
> -{
> -  hash_set blocks;
> -  auto_vec work_list;
> -  hash_set visited_list;
> -  work_list.safe_push (bb);
> -
> -  while (!work_list.is_empty ())
> -{
> -  basic_block new_bb = work_list.pop ();
> -  visited_list.add (new_bb);
> -  edge e;
> -  edge_iterator ei;
> -  FOR_EACH_EDGE (e, ei, new_bb->succs)
> -   {
> - if (!visited_list.contains (e->dest))
> -   work_list.safe_push (e->dest);
> - blocks.add (e->dest);
> -   }
> -}
> -  return blocks;
> -}
> -
>  /* Return true if the LMUL of comparison less than or equal to one.  */
>  bool
>  cmp_lmul_le_one (machine_mode mode)
> --
> 2.36.3
>

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

[Juzhe-Zhong]

This patch support dynamic LMUL cost modeling with 
--param=riscv-autovec-lmul=dynamic.

Consider this following case:
void
foo (int32_t *__restrict a, int32_t *__restrict b,int32_t *__restrict c,
  int32_t *__restrict a2, int32_t *__restrict b2, int32_t *__restrict c2,
  int32_t *__restrict a3, int32_t *__restrict b3, int32_t *__restrict c3,
  int32_t *__restrict a4, int32_t *__restrict b4, int32_t *__restrict c4,
  int32_t *__restrict a5, int32_t *__restrict b5, int32_t *__restrict c5,
  int32_t *__restrict d,
  int32_t *__restrict d2,
  int32_t *__restrict d3,
  int32_t *__restrict d4,
  int32_t *__restrict d5,
  int n)
{
  for (int i = 0; i < n; i++)
{
  a[i] = b[i] + c[i];
  b5[i] = b[i] + c[i];
  a2[i] = b2[i] + c2[i];
  a3[i] = b3[i] + c3[i];
  a4[i] = b4[i] + c4[i];
  a5[i] = a[i] + a4[i];
  d2[i] = a2[i] + c2[i];
  d3[i] = a3[i] + c3[i];
  d4[i] = a4[i] + c4[i];
  d5[i] = a[i] + a4[i];
  a[i] = a5[i] + b5[i] + a[i];

  c2[i] = a[i] + c[i];
  c3[i] = b5[i] * a5[i];
  c4[i] = a2[i] * a3[i];
  c5[i] = b5[i] * a2[i];
  c[i] = a[i] + c3[i];
  c2[i] = a[i] + c4[i];
  a5[i] = a[i] + a4[i];
  a[i] = a[i] + b5[i] + a[i] * a2[i] * a3[i] * a4[i]
  * a5[i] * c[i] * c2[i] * c3[i] * c4[i] * c5[i]
  * d[i] * d2[i] * d3[i] * d4[i] * d5[i];
}
}

Demo: https://godbolt.org/z/x1acoMxGT

You can see it will produce register spilling if you specify LMUL >= 4

Now, with --param=riscv-autovec-lmul=dynamic.

GCC is able to pick LMUL = 2 to optimized this case.

This feature is supported by linear scan based local live ranges analysis and
compute maximum live V_REGS in specific program point of the function to 
determine the VF/LMUL.

Note that this patch can well handle both SLP and non-SLP loop.

Currenty approach didn't consider the later instruction scheduler which may 
improve the register pressure.
In this case, we are conservatively applying smaller VF/LMUL. (Not sure whether 
we should support live range shrink for such corner case since we don't known 
whether it can improve performance a lot.)

gcc/ChangeLog:

* config/riscv/riscv-vector-costs.cc (get_last_live_range): New 
function.
(compute_nregs_for_mode): Ditto.
(live_range_conflict_p): Ditto.
(max_number_of_live_regs): Ditto.
(compute_lmul): Ditto.
(costs::prefer_new_lmul_p): Ditto.
(costs::better_main_loop_than_p): Ditto.
* config/riscv/riscv-vector-costs.h (struct stmt_point): New struct.
(struct var_live_range): Ditto.
(struct autovec_info): Ditto.
* config/riscv/t-riscv: Update makefile for COST model.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul-mixed-1.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-1.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-2.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-3.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-4.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-5.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-6.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-7.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-1.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-2.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-3.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-4.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-5.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-6.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-1.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-2.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-3.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-4.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-5.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-7.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-1.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-10.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-2.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-3.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-4.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-5.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-6.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-7.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-8.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/

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

[Juzhe-Zhong]

This patch support dynamic LMUL cost modeling with 
--param=riscv-autovec-lmul=dynamic.

Consider this following case:
void
foo (int32_t *__restrict a, int32_t *__restrict b,int32_t *__restrict c,
  int32_t *__restrict a2, int32_t *__restrict b2, int32_t *__restrict c2,
  int32_t *__restrict a3, int32_t *__restrict b3, int32_t *__restrict c3,
  int32_t *__restrict a4, int32_t *__restrict b4, int32_t *__restrict c4,
  int32_t *__restrict a5, int32_t *__restrict b5, int32_t *__restrict c5,
  int32_t *__restrict d,
  int32_t *__restrict d2,
  int32_t *__restrict d3,
  int32_t *__restrict d4,
  int32_t *__restrict d5,
  int n)
{
  for (int i = 0; i < n; i++)
{
  a[i] = b[i] + c[i];
  b5[i] = b[i] + c[i];
  a2[i] = b2[i] + c2[i];
  a3[i] = b3[i] + c3[i];
  a4[i] = b4[i] + c4[i];
  a5[i] = a[i] + a4[i];
  d2[i] = a2[i] + c2[i];
  d3[i] = a3[i] + c3[i];
  d4[i] = a4[i] + c4[i];
  d5[i] = a[i] + a4[i];
  a[i] = a5[i] + b5[i] + a[i];

  c2[i] = a[i] + c[i];
  c3[i] = b5[i] * a5[i];
  c4[i] = a2[i] * a3[i];
  c5[i] = b5[i] * a2[i];
  c[i] = a[i] + c3[i];
  c2[i] = a[i] + c4[i];
  a5[i] = a[i] + a4[i];
  a[i] = a[i] + b5[i] + a[i] * a2[i] * a3[i] * a4[i]
  * a5[i] * c[i] * c2[i] * c3[i] * c4[i] * c5[i]
  * d[i] * d2[i] * d3[i] * d4[i] * d5[i];
}
}

Demo: https://godbolt.org/z/x1acoMxGT

You can see it will produce register spilling if you specify LMUL >= 4

Now, with --param=riscv-autovec-lmul=dynamic.

GCC is able to pick LMUL = 2 to optimized this case.

This feature is supported by linear scan based local live ranges analysis and
compute maximum live V_REGS in specific program point of the function to 
determine the VF/LMUL.

Note that this patch can well handle both SLP and non-SLP loop.

Currenty approach didn't consider the later instruction scheduler which may 
improve the register pressure.
In this case, we are conservatively applying smaller VF/LMUL. (Not sure whether 
we should support live range shrink for such corner case since we don't known 
whether it can improve performance a lot.)

gcc/ChangeLog:

* config/riscv/riscv-vector-costs.cc (get_last_live_range): New 
function.
(compute_nregs_for_mode): Ditto.
(live_range_conflict_p): Ditto.
(max_number_of_live_regs): Ditto.
(compute_lmul): Ditto.
(costs::prefer_new_lmul_p): Ditto.
(costs::better_main_loop_than_p): Ditto.
* config/riscv/riscv-vector-costs.h (struct stmt_point): New struct.
(struct var_live_range): Ditto.
(struct autovec_info): Ditto.
* config/riscv/t-riscv: Update makefile for COST model.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul-mixed-1.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-1.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-2.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-3.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-4.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-5.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-6.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul1-7.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-1.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-2.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-3.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-4.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-5.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-6.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-1.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-2.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-3.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-4.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-5.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-7.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-8.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-1.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-10.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-2.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-3.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-4.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-5.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-6.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-7.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-8.c: New test.
* gcc.dg/vect/costmodel/riscv/rvv/

RE: [PATCH] RISC-V: Remove redundant functions

[Li, Pan2 via Gcc-patches]

Committed, thanks Kito.

Pan

-Original Message-
From: Gcc-patches  On Behalf 
Of Kito Cheng via Gcc-patches
Sent: Monday, September 11, 2023 5:26 PM
To: Juzhe-Zhong 
Cc: gcc-patches@gcc.gnu.org; kito.ch...@gmail.com
Subject: Re: [PATCH] RISC-V: Remove redundant functions

LGTM

On Mon, Sep 11, 2023 at 5:20 PM Juzhe-Zhong  wrote:
>
> I just finished V2 version of LMUL cost model.
> Turns out we don't these redundant functions.
>
> Remove them.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-protos.h (get_all_predecessors): Remove.
> (get_all_successors): Ditto.
> * config/riscv/riscv-v.cc (get_all_predecessors): Ditto.
> (get_all_successors): Ditto.
>
> ---
>  gcc/config/riscv/riscv-protos.h |  2 --
>  gcc/config/riscv/riscv-v.cc | 48 -
>  2 files changed, 50 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
> index 46d77ef927c..e91a55ec057 100644
> --- a/gcc/config/riscv/riscv-protos.h
> +++ b/gcc/config/riscv/riscv-protos.h
> @@ -498,8 +498,6 @@ enum floating_point_rounding_mode get_frm_mode (rtx);
>  opt_machine_mode vectorize_related_mode (machine_mode, scalar_mode,
>  poly_uint64);
>  unsigned int autovectorize_vector_modes (vec *, bool);
> -hash_set get_all_predecessors (basic_block);
> -hash_set get_all_successors (basic_block);
>  bool cmp_lmul_le_one (machine_mode);
>  bool cmp_lmul_gt_one (machine_mode);
>  }
> diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
> index 3cd1f61de0e..4d95bd773a2 100644
> --- a/gcc/config/riscv/riscv-v.cc
> +++ b/gcc/config/riscv/riscv-v.cc
> @@ -3388,54 +3388,6 @@ expand_fold_extract_last (rtx *ops)
>emit_label (end_label);
>  }
>
> -hash_set
> -get_all_predecessors (basic_block bb)
> -{
> -  hash_set blocks;
> -  auto_vec work_list;
> -  hash_set visited_list;
> -  work_list.safe_push (bb);
> -
> -  while (!work_list.is_empty ())
> -{
> -  basic_block new_bb = work_list.pop ();
> -  visited_list.add (new_bb);
> -  edge e;
> -  edge_iterator ei;
> -  FOR_EACH_EDGE (e, ei, new_bb->preds)
> -   {
> - if (!visited_list.contains (e->src))
> -   work_list.safe_push (e->src);
> - blocks.add (e->src);
> -   }
> -}
> -  return blocks;
> -}
> -
> -hash_set
> -get_all_successors (basic_block bb)
> -{
> -  hash_set blocks;
> -  auto_vec work_list;
> -  hash_set visited_list;
> -  work_list.safe_push (bb);
> -
> -  while (!work_list.is_empty ())
> -{
> -  basic_block new_bb = work_list.pop ();
> -  visited_list.add (new_bb);
> -  edge e;
> -  edge_iterator ei;
> -  FOR_EACH_EDGE (e, ei, new_bb->succs)
> -   {
> - if (!visited_list.contains (e->dest))
> -   work_list.safe_push (e->dest);
> - blocks.add (e->dest);
> -   }
> -}
> -  return blocks;
> -}
> -
>  /* Return true if the LMUL of comparison less than or equal to one.  */
>  bool
>  cmp_lmul_le_one (machine_mode mode)
> --
> 2.36.3
>

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

[Jonathan Wakely via Gcc-patches]

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?

>
> This patch requires the missing thread-fence effective target in the
> tests that need it, making them UNSUPPORTED instead of FAIL and
> UNRESOLVED.

Some of the modified tests should not be using
__gnu_debug::_Safe_sequence_base::_M_detach_all(), because they don't
use the Debug Mode. I don't know where those linker errors come from.
For example, the 23_containers/span/*assert_neg.cc and
26_numerics/valarray/* tests shouldn't use debug iterators or atomics.
Neither should 25_algorithms/sample/2.cc nor
26_numerics/bit/bit.pow.two/bit_ceil_neg.cc

The last three in the patch shouldn't use it either:

> diff --git a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc 
> b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> index cb818708aef..372ed6e0c00 100644
> --- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> +++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> @@ -18,6 +18,7 @@
>  // { dg-do run { target c++14 } }
>  // { dg-add-options libatomic }
>  // { dg-xfail-if "poll not available" { *-*-rtems* } }
> +// { dg-require-thread-fence "" } // needed by 
> __gnu_debug::_Safe_sequence_base::_M_detach_all()
>
>  #include 
>  #include 
> diff --git a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc 
> b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> index ae51979c3b4..8383e0be6a4 100644
> --- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> +++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> @@ -18,6 +18,7 @@
>  // { dg-do run { target c++14 } }
>  // { dg-add-options libatomic }
>  // { dg-xfail-if "poll not available" { *-*-rtems* } }
> +// { dg-require-thread-fence "" } // needed by 
> __gnu_debug::_Safe_sequence_base::_M_detach_all()
>
>  #include 
>  #include 
> diff --git 
> a/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc 
> b/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
> index 960c1d253b5..42de45619a8 100644
> --- 
> a/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
> +++ 
> b/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
> @@ -16,6 +16,7 @@
>  // .
>
>  // { dg-do run { target c++14 } }
> +// { dg-require-thread-fence "" } // needed by 
> __gnu_debug::_Safe_sequence_base::_M_detach_all()
>
>  #include 
>  #include 


I'm concerned with how much of the testsuite is being completely
disabled for this target.

Any tests with "debug" in the path are probably relying on the debug
mode, and any that use -D_GLIBCXX_DEBUG in dg-options are. And I
suppose it's expected that 29_atomics/* tests rely on atomic
synchronization, but it's unfortunate that those now can't be tested
for arm-eabi, and I don't understand why it only affects eight of the
atomics tests not all the other ones.

Something doesn't seem right here.

[PATCH] libstdc++: Check if getent is available in git config script [PR111359]

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux, powerpc-aix, and minimally tested on macOS 12.6
(darwin 21.6.0).

OK for trunk?

-- >8 --

contrib/ChangeLog:

PR other/111359
* gcc-git-customization.sh: Check for getent before using it.
Use id on macOS.
---
 contrib/gcc-git-customization.sh | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index 914d868f7bd..2e173e859d7 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -46,7 +46,11 @@ set_email=$(git config --get "user.email")
 if [ "x$set_user" = "x" ]
 then
 # Try to guess the user's name by looking it up in the password file
-new_user=$(getent passwd $(whoami) | awk -F: '{ print $5 }')
+if type getent >/dev/null 2>&1; then
+  new_user=$(getent passwd $(whoami) | awk -F: '{ print $5 }')
+elif [ $(uname -s) = Darwin ]; then
+  new_user=$(id -F 2>/dev/null)
+fi
 if [ "x$new_user" = "x" ]
 then
new_user="(no default)"
-- 
2.41.0

Re: [PATCH] libstdc++: Check if getent is available in git config script [PR111359]

[Jakub Jelinek via Gcc-patches]

On Mon, Sep 11, 2023 at 12:06:19PM +0100, Jonathan Wakely via Gcc-patches wrote:
> Tested x86_64-linux, powerpc-aix, and minimally tested on macOS 12.6
> (darwin 21.6.0).
> 
> OK for trunk?
> 
> -- >8 --
> 
> contrib/ChangeLog:
> 
>   PR other/111359
>   * gcc-git-customization.sh: Check for getent before using it.
>   Use id on macOS.

Ok, thanks.

Jakub

[Patch] OpenMP (C only): omp allocate - extend parsing support, improve diagnostic (was: [Patch] OpenMP (C only): omp allocate - handle stack vars, improve diagnostic)

[Tobias Burnus]

The patch adds more check and fixes some minor FE bits, but it now has a
'sorry' for automatic/stack variables in the middle end.

I think it is useful by itself as it completes the C FE part and adds
diagnostic, even if the actual code generation is disabled.

Comments, remarks, suggestions?

The actual code generation works fine (see previous patch) but it fails
with OpenMP privatization and mapping; I have locally an incomplete WIP
patch to fix this. But until it works, the 'sorry' makes more sense.
Besides solving that issue, C++ needs to be updated to be on par with C
and my (not yet posted) Fortran patch also needs some changes for the C
and ME changes.

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
OpenMP (C only): omp allocate - extend parsing support, improve diagnostic

The 'allocate' directive can be used for both stack and static variables.
While the parser in C and C++ was pre-existing, it missed several
diagnostics, which this commit adds - for now only for C.

While the "sorry, unimplemented" for static variables is still issues
during parsing, the sorry for stack variables is now issued in the
middle end, preparing for the actual implementation. (Again: only for C.)

gcc/c/ChangeLog:

	* c-parser.cc (c_parser_omp_construct): Move call to
	c_parser_omp_allocate to ...
	(c_parser_pragma): ... here.
	(c_parser_omp_allocate): Avoid ICE is allocator could not be
	parsed; set 'omp allocate' attribute for stack/automatic variables
	and only reject static variables; add several additional
	restriction checks.
	* c-tree.h (c_mark_decl_jump_unsafe_in_current_scope): New prototype.
	* c-decl.cc (decl_jump_unsafe): Return true for omp-allocated decls.
	(c_mark_decl_jump_unsafe_in_current_scope): New.
	(warn_about_goto, c_check_switch_jump_warnings): Add error for
	omp-allocated decls.

gcc/ChangeLog:

	* gimplify.cc (gimplify_bind_expr): Check for
	insertion after variable cleanup.  Convert 'omp allocate'
	var-decl attribute to GOMP_alloc/GOMP_free calls.

gcc/testsuite/ChangeLog:

	* c-c++-common/gomp/allocate-5.c: Fix testcase; make some
	dg-messages for 'sorry' as c++, only.
	* c-c++-common/gomp/directive-1.c: Make a 'sorry' c++ only.
	* c-c++-common/gomp/allocate-9.c: New test.
	* c-c++-common/gomp/allocate-11.c: New test.
	* c-c++-common/gomp/allocate-12.c: New test.
	* c-c++-common/gomp/allocate-14.c: New test.
	* c-c++-common/gomp/allocate-15.c: New test.

 gcc/c/c-decl.cc   |  23 ++
 gcc/c/c-parser.cc | 112 +++---
 gcc/c/c-tree.h|   1 +
 gcc/gimplify.cc   |  40 +
 gcc/testsuite/c-c++-common/gomp/allocate-11.c |  40 +
 gcc/testsuite/c-c++-common/gomp/allocate-12.c |  46 +++
 gcc/testsuite/c-c++-common/gomp/allocate-14.c |  26 ++
 gcc/testsuite/c-c++-common/gomp/allocate-15.c |  28 +++
 gcc/testsuite/c-c++-common/gomp/allocate-5.c  |  60 +++---
 gcc/testsuite/c-c++-common/gomp/allocate-9.c  |  96 ++
 gcc/testsuite/c-c++-common/gomp/directive-1.c |   2 +-
 11 files changed, 432 insertions(+), 42 deletions(-)

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 649c5ae66c2..05fdb9240ae 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -681,6 +681,11 @@ decl_jump_unsafe (tree decl)
   if (VAR_P (decl) && C_DECL_COMPOUND_LITERAL_P (decl))
 return false;
 
+  if (flag_openmp
+  && VAR_P (decl)
+  && lookup_attribute ("omp allocate", DECL_ATTRIBUTES (decl)))
+return true;
+
   /* Always warn about crossing variably modified types.  */
   if ((VAR_P (decl) || TREE_CODE (decl) == TYPE_DECL)
   && c_type_variably_modified_p (TREE_TYPE (decl)))
@@ -724,6 +729,12 @@ c_print_identifier (FILE *file, tree node, int indent)
   c_binding_oracle = save;
 }
 
+void
+c_mark_decl_jump_unsafe_in_current_scope ()
+{
+  current_scope->has_jump_unsafe_decl = 1;
+}
+
 /* Establish a binding between NAME, an IDENTIFIER_NODE, and DECL,
which may be any of several kinds of DECL or TYPE or error_mark_node,
in the scope SCOPE.  */
@@ -3974,6 +3985,9 @@ warn_about_goto (location_t goto_loc, tree label, tree decl)
   if (c_type_variably_modified_p (TREE_TYPE (decl)))
 error_at (goto_loc,
 	  "jump into scope of identifier with variably modified type");
+  else if (flag_openmp
+	   && lookup_attribute ("omp allocate", DECL_ATTRIBUTES (decl)))
+error_at (goto_loc, "jump skips OpenMP % allocation");
   else
 if (!warning_at (goto_loc, OPT_Wjump_misses_init,
 		 "jump skips variable initialization"))
@@ -4253,6 +4267,15 @@ c_check_switch_jump_warnings (struct c_spot_bindings *switch_bindings,
 			 "variably modified type"));
 		  emitted = true;
 		}
+	  

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

[Jonathan Wakely via Gcc-patches]

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.

>
> 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:
>
>  * 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: TC 
>
> Ok to commit and backport to GCC 11, 12, 13 branches ?
>
> François
>

Re: [Patch] OpenMP (C only): omp allocate - extend parsing support, improve diagnostic (was: [Patch] OpenMP (C only): omp allocate - handle stack vars, improve diagnostic)

[Jakub Jelinek via Gcc-patches]

Hi!

One question to David below, CCed.

On Mon, Sep 11, 2023 at 01:44:07PM +0200, Tobias Burnus wrote:
> --- a/gcc/c/c-decl.cc
> +++ b/gcc/c/c-decl.cc
> @@ -681,6 +681,11 @@ decl_jump_unsafe (tree decl)
>if (VAR_P (decl) && C_DECL_COMPOUND_LITERAL_P (decl))
>  return false;
>  
> +  if (flag_openmp
> +  && VAR_P (decl)
> +  && lookup_attribute ("omp allocate", DECL_ATTRIBUTES (decl)))
> +return true;
> +
>/* Always warn about crossing variably modified types.  */
>if ((VAR_P (decl) || TREE_CODE (decl) == TYPE_DECL)
>&& c_type_variably_modified_p (TREE_TYPE (decl)))
> @@ -724,6 +729,12 @@ c_print_identifier (FILE *file, tree node, int indent)
>c_binding_oracle = save;
>  }
>  

I think we want a function comment here.

> +void
> +c_mark_decl_jump_unsafe_in_current_scope ()
> +{
> +  current_scope->has_jump_unsafe_decl = 1;
> +}
> +
> +   if (DECL_SOURCE_LOCATION (allocator) > DECL_SOURCE_LOCATION (var))
> + {
> +   error_at (OMP_CLAUSE_LOCATION (nl),
> + "allocator variable %qD must be declared before %qD",
> + allocator, var);
> +   inform (DECL_SOURCE_LOCATION (allocator), "declared here");
> +   inform (DECL_SOURCE_LOCATION (var), "declared here");

I think this will be confusing to users when the inform is the same in both
cases.  I'd use "allocator declared here" in the first case.

And, am really not sure if one can just simply compare location_t like that.
Isn't there some function which determines what source location is before
another one?  David?

> +  if (EXPR_LOCATION (*l) < DECL_SOURCE_LOCATION (var))
> +break;

Likewise.

> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/gomp/allocate-12.c
> @@ -0,0 +1,46 @@
> +/* TODO: enable for C++ once implemented. */
> +/* { dg-do compile { target c } } */
> +
> +typedef enum omp_allocator_handle_t

I think all the c-c++-common tests declaring
omp_allocator_handle_t should have
#if __cplusplus >= 201103L
: __UINTPTR_TYPE__
#endif
here (even if they are just { target c } for now, we'd certainly
forget to adjust them).


Jakub

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

[Li, Pan2 via Gcc-patches]

> -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 
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 return null.  */

tree

function_resolver::lookup_form (mode_suffix_index mode,

type_suffix_index type0,

type_suffix_index type1)

{

  type_suffix_pair types = { type0, type1 };

  function_instance instance (base_name, base, shape, mode, types, pred);

  registered_function *rfn

= function_table->find_with_hash (instance, instance.hash ());

  return rfn ? rfn->decl : NULL_TREE;

}


juzhe.zh...@rivai.ai

From: Kito Cheng
Date: 2023-09-11 17:04
To: juzhe.zh...@rivai.ai
CC: pan2.li; 
gcc-patches; 
yanzhang.wang
Subject: Re: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV 
intrinsic
> @@ -545,7 +563,7 @@ struct move_def : public build_base
>  /* According to rvv-intrinsic-doc, it does not add "_m" suffix
> for vop_m C++ overloaded API.  */
> -if (overloaded_p && instance.pred == PRED_TYPE_m)
> +if (overloaded_p)

Just make sure it's the right change?

>return b.finish_name ();
>  b.append_name (predication_suffixes[instance.pred]);
>  return b.finish_name ();

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

[Li, Pan2 via Gcc-patches]

> 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 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, otherwise return null.  */

tree

function_resolver::lookup_form (mode_suffix_index mode,

type_suffix_index type0,

type_suffix_index type1)

{

  type_suffix_pair types = { type0, type1 };

  function_instance instance (base_name, base, shape, mode, types, pred);

  registered_function *rfn

= function_table->find_with_hash (instance, instance.hash ());

  return rfn ? rfn->decl : NULL_TREE;

}


juzhe.zh...@rivai.ai

From: Kito Cheng
Date: 2023-09-11 17:04
To: juzhe.zh...@rivai.ai
CC: pan2.li; 
gcc-patches; 
yanzhang.wang
Subject: Re: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV 
intrinsic
> @@ -545,7 +563,7 @@ struct move_def : public build_base
>  /* According to rvv-intrinsic-doc, it does not add "_m" suffix
> for vop_m C++ overloaded API.  */
> -if (overloaded_p && instance.pred == PRED_TYPE_m)
> +if (overloaded_p)

Just make sure it's the right change?

>return b.finish_name ();
>  b.append_name (predication_suffixes[instance.pred]);
>  return b.finish_name ();

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

[Christophe Lyon via Gcc-patches]

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

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.

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


> >
> > This patch requires the missing thread-fence effective target in the
> > tests that need it, making them UNSUPPORTED instead of FAIL and
> > UNRESOLVED.
>
> Some of the modified tests should not be using
> __gnu_debug::_Safe_sequence_base::_M_detach_all(), because they don't
> use the Debug Mode. I don't know where those linker errors come from.
> For example, the 23_containers/span/*assert_neg.cc and
> 26_numerics/valarray/* tests shouldn't use debug iterators or atomics.
> Neither should 25_algorithms/sample/2.cc nor
> 26_numerics/bit/bit.pow.two/bit_ceil_neg.cc
>

Ouch!  I had the feeling this patch wouldn't count as obvious :-)

I confess I didn't analyze the linker map for every single test updated by
this patch
I can have a deeper look based on your comment below, excluding those that
look "OK"


> The last three in the patch shouldn't use it either:
>
> > diff --git
> a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> > index cb818708aef..372ed6e0c00 100644
> > --- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> > +++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> > @@ -18,6 +18,7 @@
> >  // { dg-do run { target c++14 } }
> >  // { dg-add-options libatomic }
> >  // { dg-xfail-if "poll not available" { *-*-rtems* } }
> > +// { dg-require-thread-fence "" } // needed by
> __gnu_debug::_Safe_sequence_base::_M_detach_all()
> >
> >  #include 
> >  #include 
> > diff --git
> a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> > index ae51979c3b4..8383e0be6a4 100644
> > --- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> > +++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> > @@ -18,6 +18,7 @@
> >  // { dg-do run { target c++14 } }
> >  // { dg-add-options libatomic }
> >  // { dg-xfail-if "poll not available" { *-*-rtems* } }
> > +// { dg-require-thread-fence "" } // needed by
> __gnu_debug::_Safe_sequence_base::_M_detach_all()
> >
> >  #include 
> >  #include 
> > diff --git
> a/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
> b/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
> > index 960c1d253b5..42de45619a8 100644
> > ---
> a/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
> > +++
> b/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
> > @@ -16,6 +16,7 @@
> >  // .
> >
> >  // { dg-do run { target c++14 } }
> > +// { dg-require-thread-fence "" } // needed by
> __gnu_debug::_Safe_sequence_base::_M_detach_all()
> >
> >  #include 
> >  #include 
>
>
> I'm concerned with how much of the testsuite is being completely
> disabled for this target.
>
I think that depends on which "flavour" of arm-eabi we are looking at.
I'm trying to cleanup some of the "obvious" failures, and that proves to be
tedious:
- quite a few gcc/g++ tests have problems when overriding -mcpu/-march with
dejagnu's target-board
- so I thought a first step could be to clean the default configuration,
but as said above it targets a very old architecture


>
> Any tests with "debug" in the path are probably relying on the debug
> mode, an

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

[Mikael Morin via Gcc-patches]

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?

-- >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 *&sym)
 }
 
 
-/* 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 *&sym)
 {
   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)
 
   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 (&ns->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 (&p->ns->sym_root,gfc_dt_upper_string (p->name));
-  else
-   gfc_delete_symtree (&p->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
+it from the procedure body namespace as well as from the outer
+namespace.  */
+ if (!freed
+ &

Re: [PATCH] libgomp: Fix build for -fshort-enums

[Sebastian Huber]

On 04.07.23 08:20, Sebastian Huber wrote:

On 22.05.23 14:51, Sebastian Huber wrote:
Make sure that the API enums have at least the size of int.  Otherwise 
the

following build error may occur:

In file included from gcc/libgomp/env.c:34:
./libgomp_f.h: In function 'omp_check_defines':
./libgomp_f.h:77:8: error: size of array 'test' is negative
    77 |   char test[(28 != sizeof (omp_lock_t)
   |    ^~~~

libgomp/ChangeLog:

* omp.h.in (omp_alloctrait_key_t):  Add __omp_alloctrait_key_t_max__
with a value of the int type maximum.
---
  libgomp/omp.h.in | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libgomp/omp.h.in b/libgomp/omp.h.in
index bd1286c2a3f..3b1612fcb15 100644
--- a/libgomp/omp.h.in
+++ b/libgomp/omp.h.in
@@ -146,7 +146,8 @@ typedef enum omp_alloctrait_key_t
    omp_atk_fallback = 5,
    omp_atk_fb_data = 6,
    omp_atk_pinned = 7,
-  omp_atk_partition = 8
+  omp_atk_partition = 8,
+  __omp_alloctrait_key_t_max__ = __INT_MAX__
  } omp_alloctrait_key_t;
  typedef enum omp_alloctrait_value_t


Could someone please have a look at this.


Ping.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: [PATCH] libatomic: Provide gthr.h default implementation

[Sebastian Huber]

On 31.05.23 09:27, Richard Biener wrote:

On Wed, May 31, 2023 at 7:31 AM Sebastian Huber
 wrote:


On 30.05.23 13:17, Richard Biener wrote:

The alternative would be to provide the required subset of atomic
library functions from libgcov.a and emit calls to that directly?
The locked data isn't part of any ABI so no compatibility guarantee
needs to be maintained?


So, if atomic operations are not available in hardware, then I should
emit calls to libgcov.a which would use gthr.h to implement them? I
guess that I can to this, but it needs a bit of time.


Before doing that it would be nice to get buy-in from others - maybe
my ABI concern for libatomic isn't shared by others.


I would be nice if I could add the multi-threaded gcov support for 
targets lacking atomic operations in GCC 14 (for example 32-bit RISC-V). 
I need a direction how to implement this. Should it be done through a 
generic libatomic implementation based on gthr.h or through a special 
function provided by libgcov?





Should I add the libgcov functions to builtin_decl_explicit()?


No, they shouldn't be any different from other libgcov functions.


Ok.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

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, &p_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 return null.  */
tree
function_resolver::lookup_form (mode_suffix_index mode,
type_suffix_index type0,
type_suffix_index type1)
{
  type_suffix_pair types = { type0, type1 };
  function_instance instance (base_name, base, shape, mode, types, pred);
  registered_function *rfn
= function_table->find_with_hash (instance, instance.hash ());
  return rfn ? rfn->decl : NULL_TREE;
}


juzhe.zh...@rivai.ai
 
From: Kito Cheng
Date: 2023-09-11 17:04
To: juzhe.zh...@rivai.ai
CC: pan2.li; gcc-patches; yanzhang.wang
Subject: Re: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV 
intrinsic
> @@ -545,7 +563,7 @@ struct move_def : public build_base
>  /* According to rvv-intrinsic-doc, it does not add "_m" suffix
> for vop_m C++ overloaded API.  */
> -if (overloaded_p && instance.pred == PRED_TYPE_m)
> +if (overloaded_p)
 
Just make sure it's the right change?
 
>return b.finish_name ();
>  b.append_name (predication_suffixes[instance.pred]);
>  return b.finish_name ();
 

Re: [Patch] OpenMP (C only): omp allocate - extend parsing support, improve diagnostic (was: [Patch] OpenMP (C only): omp allocate - handle stack vars, improve diagnostic)

[David Malcolm via Gcc-patches]

On Mon, 2023-09-11 at 13:54 +0200, Jakub Jelinek wrote:
> Hi!
> 
> One question to David below, CCed.
> 
> On Mon, Sep 11, 2023 at 01:44:07PM +0200, Tobias Burnus wrote:

[...]

> 
> > +
> > + if (DECL_SOURCE_LOCATION (allocator) >
> > DECL_SOURCE_LOCATION (var))
> > +   {
> > + error_at (OMP_CLAUSE_LOCATION (nl),
> > +   "allocator variable %qD must be declared
> > before %qD",
> > +   allocator, var);
> > + inform (DECL_SOURCE_LOCATION (allocator), "declared
> > here");
> > + inform (DECL_SOURCE_LOCATION (var), "declared here");
> 
> I think this will be confusing to users when the inform is the same
> in both
> cases.  I'd use "allocator declared here" in the first case.
> 
> And, am really not sure if one can just simply compare location_t
> like that.
> Isn't there some function which determines what source location is
> before
> another one?  David?

Indeed, the numerical ordering of location_t values doesn't fully
correspond to declaration order.

Please use
  linemap_compare_locations
or
  linemap_location_before_p

> 
> > +    if (EXPR_LOCATION (*l) < DECL_SOURCE_LOCATION
> > (var))
> > +  break;
> 
> Likewise.
> 


Dave
> 

Re: [PATCH] RISC-V: Enable RVV scalable vectorization by default[PR111311]

[Jeff Law via Gcc-patches]

On 9/10/23 21:42, juzhe.zh...@rivai.ai wrote:

Ping this patch.

I think it's time to enable scalable vectorization by default and do the 
whole regression every time (except vect.exp that we didn't enable yet)


Update current FAILs status:

Real FAILS (ICE and execution FAIL):

FAIL: gcc.dg/pr70252.c (internal compiler error: in 
gimple_expand_vec_cond_expr, at gimple-isel.cc:284)

FAIL: gcc.dg/pr70252.c (test for excess errors)
FAIL: gcc.dg/pr92301.c execution test

Robin is working on these 3 issues and will be solved soon.

FAIL: g++.dg/torture/vshuf-v4df.C   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (internal compiler error: in as_a, at machmode.h:381)
FAIL: g++.dg/torture/vshuf-v4df.C   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (test for excess errors)
FAIL: g++.dg/torture/vshuf-v4df.C   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  (internal compiler error: in as_a, at machmode.h:381)
FAIL: g++.dg/torture/vshuf-v4df.C   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  (test for excess errors)

This is a long time known issue I have mentioned many times, we need 
help for LTO since it's caused by mode bits extension.


The rest bogus FAILs:
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "Not unrolling loop, 
doesn't roll"

FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "likely upper bound: 6"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "realistic bound: -1"
FAIL: gcc.dg/var-expand1.c scan-rtl-dump loop2_unroll "Expanding 
Accumulator"
FAIL: gcc.dg/tree-ssa/cunroll-16.c scan-tree-dump cunroll "optimized: 
loop with [0-9]+ iterations completely unrolled"

FAIL: gcc.dg/tree-ssa/cunroll-16.c scan-tree-dump-not optimized "foo"
FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized 
"BIT_FIELD_REF" 0
FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized 
"BIT_INSERT_EXPR" 0
FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized 
"BIT_FIELD_REF" 0
FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized 
"BIT_INSERT_EXPR" 1
FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vect 
"vectorized 0 loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vect 
"vectorized 0 loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect "Alignment 
of access forced using peeling" 1
FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect "Alignment 
of access forced using peeling" 1

FAIL: gcc.dg/tree-ssa/loop-bound-1.c scan-tree-dump ivopts "bounded by 254"
FAIL: gcc.dg/tree-ssa/loop-bound-2.c scan-tree-dump ivopts "bounded by 254"
FAIL: gcc.dg/tree-ssa/predcom-2.c scan-tree-dump-times pcom "Unrolling 2 
times." 2

FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom "Combination" 1
FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom "Unrolling 3 
times." 1

FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom "Combination" 2
FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom "Unrolling 3 
times." 1
FAIL: gcc.dg/tree-ssa/predcom-9.c scan-tree-dump pcom "Executing 
predictive commoning without unrolling"
FAIL: gcc.dg/tree-ssa/reassoc-46.c scan-tree-dump-times optimized 
"(?:vect_)?sum_[\\d._]+ = (?:(?:vect_)?_[\\d._]+ \\+ 
(?:vect_)?sum_[\\d._]+|(?:v   ect_)?sum_[\\d._]+ \\+ (?:vect_)?_[\\d._]+)" 1
FAIL: gcc.dg/tree-ssa/scev-10.c scan-tree-dump-times ivopts " 
  Type:\\tREFERENCE ADDRESS\n" 1
FAIL: gcc.dg/tree-ssa/scev-11.c scan-tree-dump-times ivopts " 
  Type:\\tREFERENCE ADDRESS\n" 2
FAIL: gcc.dg/tree-ssa/scev-14.c scan-tree-dump ivopts "Overflowness wrto 
loop niter:\tNo-overflow"
FAIL: gcc.dg/tree-ssa/scev-9.c scan-tree-dump-times ivopts " 
  Type:\\tREFERENCE ADDRESS\n" 1
FAIL: gcc.dg/tree-ssa/split-path-11.c scan-tree-dump-times split-paths 
"join point for if-convertable half-diamond" 1


These are bogus dump FAILs and I have 100% confirm each of them, we are 
having same behavior as SVE.


So is this patch ok for trunk ?

Yes, this is OK for the trunk.

Jeff

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

[Jonathan Wakely via Gcc-patches]

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.

>
>>
>> >
>> > This patch requires the missing thread-fence effective target in the
>> > tests that need it, making them UNSUPPORTED instead of FAIL and
>> > UNRESOLVED.
>>
>> Some of the modified tests should not be using
>> __gnu_debug::_Safe_sequence_base::_M_detach_all(), because they don't
>> use the Debug Mode. I don't know where those linker errors come from.
>> For example, the 23_containers/span/*assert_neg.cc and
>> 26_numerics/valarray/* tests shouldn't use debug iterators or atomics.
>> Neither should 25_algorithms/sample/2.cc nor
>> 26_numerics/bit/bit.pow.two/bit_ceil_neg.cc
>
>
> Ouch!  I had the feeling this patch wouldn't count as obvious :-)
>
> I confess I didn't analyze the linker map for every single test updated by 
> this patch
> I can have a deeper look based on your comment below, excluding those that 
> look "OK"
>
>>
>> The last three in the patch shouldn't use it either:
>>
>> > diff --git 
>> > a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc 
>> > b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
>> > index cb818708aef..372ed6e0c00 100644
>> > --- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
>> > +++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
>> > @@ -18,6 +18,7 @@
>> >  // { dg-do run { target c++14 } }
>> >  // { dg-add-options libatomic }
>> >  // { dg-xfail-if "poll not available" { *-*-rtems* } }
>> > +// { dg-require-thread-fence "" } // needed by 
>> > __gnu_debug::_Safe_sequence_base::_M_detach_all()
>> >
>> >  #include 
>> >  #include 
>> > diff --git a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc 
>> > b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
>> > index ae51979c3b4..8383e0be6a4 100644
>> > --- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
>> > +++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
>> > @@ -18,6 +18,7 @@
>> >  // { dg-do run { target c++14 } }
>> >  // { dg-add-options libatomic }
>> >  // { dg-xfail-if "poll not available" { *-*-rtems* } }
>> > +// { dg-require-thread-fence "" } // needed by 
>> > __gnu_debug::_Safe_sequence_base::_M_detach_all()
>> >
>> >  #include 
>> >  #include 
>> > diff --git 
>> > a/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
>> >  
>> > b/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
>> > index 960c1d253b5..42de45619a8 100644
>> > --- 
>> > a/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
>> > +++ 
>> > b/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
>> > @@ -16,6 +16,7 @@
>> >  // .
>> >
>> >  // { dg-do run { target c++14 } }
>> > +// { dg-require-thread-fence "" } // needed by 
>> > __gnu_debug::_Safe_sequence_base::_M_detach_all()
>> >
>> >  #includ

Re: [Patch] OpenMP (C only): omp allocate - extend parsing support, improve diagnostic (was: [Patch] OpenMP (C only): omp allocate - handle stack vars, improve diagnostic)

[Tobias Burnus]

Hi,

thanks for the comments and for the line-number thing. (I wanted to
re-check it myself but then totally forgot about it.)

Attached is the updated patch, fixing the line-number comparison, the
C++ addition to the enum decl in two of the testcases, and adding
"allocator" to the one inform (both to the code and to one testcase).

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
OpenMP (C only): omp allocate - extend parsing support, improve diagnostic

The 'allocate' directive can be used for both stack and static variables.
While the parser in C and C++ was pre-existing, it missed several
diagnostics, which this commit adds - for now only for C.

While the "sorry, unimplemented" for static variables is still issues
during parsing, the sorry for stack variables is now issued in the
middle end, preparing for the actual implementation. (Again: only for C.)

gcc/c/ChangeLog:

	* c-parser.cc (c_parser_omp_construct): Move call to
	c_parser_omp_allocate to ...
	(c_parser_pragma): ... here.
	(c_parser_omp_allocate): Avoid ICE is allocator could not be
	parsed; set 'omp allocate' attribute for stack/automatic variables
	and only reject static variables; add several additional
	restriction checks.
	* c-tree.h (c_mark_decl_jump_unsafe_in_current_scope): New prototype.
	* c-decl.cc (decl_jump_unsafe): Return true for omp-allocated decls.
	(c_mark_decl_jump_unsafe_in_current_scope): New.
	(warn_about_goto, c_check_switch_jump_warnings): Add error for
	omp-allocated decls.

gcc/ChangeLog:

	* gimplify.cc (gimplify_bind_expr): Check for
	insertion after variable cleanup.  Convert 'omp allocate'
	var-decl attribute to GOMP_alloc/GOMP_free calls.

gcc/testsuite/ChangeLog:

	* c-c++-common/gomp/allocate-5.c: Fix testcase; make some
	dg-messages for 'sorry' as c++, only.
	* c-c++-common/gomp/directive-1.c: Make a 'sorry' c++ only.
	* c-c++-common/gomp/allocate-9.c: New test.
	* c-c++-common/gomp/allocate-11.c: New test.
	* c-c++-common/gomp/allocate-12.c: New test.
	* c-c++-common/gomp/allocate-14.c: New test.
	* c-c++-common/gomp/allocate-15.c: New test.

 gcc/c/c-decl.cc   |  26 ++
 gcc/c/c-parser.cc | 115 +++---
 gcc/c/c-tree.h|   1 +
 gcc/gimplify.cc   |  40 +
 gcc/testsuite/c-c++-common/gomp/allocate-11.c |  40 +
 gcc/testsuite/c-c++-common/gomp/allocate-12.c |  49 +++
 gcc/testsuite/c-c++-common/gomp/allocate-14.c |  26 ++
 gcc/testsuite/c-c++-common/gomp/allocate-15.c |  28 +++
 gcc/testsuite/c-c++-common/gomp/allocate-5.c  |  60 +++---
 gcc/testsuite/c-c++-common/gomp/allocate-9.c  |  99 ++
 gcc/testsuite/c-c++-common/gomp/directive-1.c |   2 +-
 11 files changed, 444 insertions(+), 42 deletions(-)

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 649c5ae66c2..5822faf01b4 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -681,6 +681,11 @@ decl_jump_unsafe (tree decl)
   if (VAR_P (decl) && C_DECL_COMPOUND_LITERAL_P (decl))
 return false;
 
+  if (flag_openmp
+  && VAR_P (decl)
+  && lookup_attribute ("omp allocate", DECL_ATTRIBUTES (decl)))
+return true;
+
   /* Always warn about crossing variably modified types.  */
   if ((VAR_P (decl) || TREE_CODE (decl) == TYPE_DECL)
   && c_type_variably_modified_p (TREE_TYPE (decl)))
@@ -724,6 +729,15 @@ c_print_identifier (FILE *file, tree node, int indent)
   c_binding_oracle = save;
 }
 
+/* Establish that the scope contains declarations that are sensitive to
+   jumps that cross a binding.  Together with decl_jump_unsafe, this is
+   used to diagnose such jumps.  */
+void
+c_mark_decl_jump_unsafe_in_current_scope ()
+{
+  current_scope->has_jump_unsafe_decl = 1;
+}
+
 /* Establish a binding between NAME, an IDENTIFIER_NODE, and DECL,
which may be any of several kinds of DECL or TYPE or error_mark_node,
in the scope SCOPE.  */
@@ -3974,6 +3988,9 @@ warn_about_goto (location_t goto_loc, tree label, tree decl)
   if (c_type_variably_modified_p (TREE_TYPE (decl)))
 error_at (goto_loc,
 	  "jump into scope of identifier with variably modified type");
+  else if (flag_openmp
+	   && lookup_attribute ("omp allocate", DECL_ATTRIBUTES (decl)))
+error_at (goto_loc, "jump skips OpenMP % allocation");
   else
 if (!warning_at (goto_loc, OPT_Wjump_misses_init,
 		 "jump skips variable initialization"))
@@ -4253,6 +4270,15 @@ c_check_switch_jump_warnings (struct c_spot_bindings *switch_bindings,
 			 "variably modified type"));
 		  emitted = true;
 		}
+	  else if (flag_openmp
+		   && lookup_attribute ("omp allocate",
+	DECL_ATTRIBUTES (b->decl)))
+		{
+		  saw_error = true;
+		  error_at (ca

RE: [PATCH] RISC-V: Enable RVV scalable vectorization by default[PR111311]

[Li, Pan2 via Gcc-patches]

Committed, thanks Jeff.

Pan

-Original Message-
From: Gcc-patches  On Behalf 
Of Jeff Law via Gcc-patches
Sent: Monday, September 11, 2023 9:12 PM
To: juzhe.zh...@rivai.ai; gcc-patches 
Cc: Kito.cheng ; kito.cheng 
Subject: Re: [PATCH] RISC-V: Enable RVV scalable vectorization by 
default[PR111311]



On 9/10/23 21:42, juzhe.zh...@rivai.ai wrote:
> Ping this patch.
> 
> I think it's time to enable scalable vectorization by default and do the 
> whole regression every time (except vect.exp that we didn't enable yet)
> 
> Update current FAILs status:
> 
> Real FAILS (ICE and execution FAIL):
> 
> FAIL: gcc.dg/pr70252.c (internal compiler error: in 
> gimple_expand_vec_cond_expr, at gimple-isel.cc:284)
> FAIL: gcc.dg/pr70252.c (test for excess errors)
> FAIL: gcc.dg/pr92301.c execution test
> 
> Robin is working on these 3 issues and will be solved soon.
> 
> FAIL: g++.dg/torture/vshuf-v4df.C   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  (internal compiler error: in as_a, at machmode.h:381)
> FAIL: g++.dg/torture/vshuf-v4df.C   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  (test for excess errors)
> FAIL: g++.dg/torture/vshuf-v4df.C   -O2 -flto -fuse-linker-plugin 
> -fno-fat-lto-objects  (internal compiler error: in as_a, at machmode.h:381)
> FAIL: g++.dg/torture/vshuf-v4df.C   -O2 -flto -fuse-linker-plugin 
> -fno-fat-lto-objects  (test for excess errors)
> 
> This is a long time known issue I have mentioned many times, we need 
> help for LTO since it's caused by mode bits extension.
> 
> The rest bogus FAILs:
> FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "Not unrolling loop, 
> doesn't roll"
> FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "likely upper bound: 6"
> FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "realistic bound: -1"
> FAIL: gcc.dg/var-expand1.c scan-rtl-dump loop2_unroll "Expanding 
> Accumulator"
> FAIL: gcc.dg/tree-ssa/cunroll-16.c scan-tree-dump cunroll "optimized: 
> loop with [0-9]+ iterations completely unrolled"
> FAIL: gcc.dg/tree-ssa/cunroll-16.c scan-tree-dump-not optimized "foo"
> FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized 
> "BIT_FIELD_REF" 0
> FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized 
> "BIT_INSERT_EXPR" 0
> FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized 
> "BIT_FIELD_REF" 0
> FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized 
> "BIT_INSERT_EXPR" 1
> FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vect 
> "vectorized 0 loops" 1
> FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vect 
> "vectorized 0 loops" 1
> FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect "Alignment 
> of access forced using peeling" 1
> FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect "Alignment 
> of access forced using peeling" 1
> FAIL: gcc.dg/tree-ssa/loop-bound-1.c scan-tree-dump ivopts "bounded by 254"
> FAIL: gcc.dg/tree-ssa/loop-bound-2.c scan-tree-dump ivopts "bounded by 254"
> FAIL: gcc.dg/tree-ssa/predcom-2.c scan-tree-dump-times pcom "Unrolling 2 
> times." 2
> FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom "Combination" 1
> FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom "Unrolling 3 
> times." 1
> FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom "Combination" 2
> FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom "Unrolling 3 
> times." 1
> FAIL: gcc.dg/tree-ssa/predcom-9.c scan-tree-dump pcom "Executing 
> predictive commoning without unrolling"
> FAIL: gcc.dg/tree-ssa/reassoc-46.c scan-tree-dump-times optimized 
> "(?:vect_)?sum_[\\d._]+ = (?:(?:vect_)?_[\\d._]+ \\+ 
> (?:vect_)?sum_[\\d._]+|(?:v   ect_)?sum_[\\d._]+ \\+ (?:vect_)?_[\\d._]+)" 1
> FAIL: gcc.dg/tree-ssa/scev-10.c scan-tree-dump-times ivopts " 
>   Type:\\tREFERENCE ADDRESS\n" 1
> FAIL: gcc.dg/tree-ssa/scev-11.c scan-tree-dump-times ivopts " 
>   Type:\\tREFERENCE ADDRESS\n" 2
> FAIL: gcc.dg/tree-ssa/scev-14.c scan-tree-dump ivopts "Overflowness wrto 
> loop niter:\tNo-overflow"
> FAIL: gcc.dg/tree-ssa/scev-9.c scan-tree-dump-times ivopts " 
>   Type:\\tREFERENCE ADDRESS\n" 1
> FAIL: gcc.dg/tree-ssa/split-path-11.c scan-tree-dump-times split-paths 
> "join point for if-convertable half-diamond" 1
> 
> These are bogus dump FAILs and I have 100% confirm each of them, we are 
> having same behavior as SVE.
> 
> So is this patch ok for trunk ?
Yes, this is OK for the trunk.

Jeff

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

[David Malcolm via Gcc-patches]

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:

- the ChangeLog sensibly makes use of "Likewise", but for the initial
file in each ChangeLog it incorrectly also says "Likewise".  When these
are copied into the individual ChangeLog files by the "Daily bump"
cronjob, the Subject line from the commit won't be visible [1], so the
thing that "Likewise" refers to won't be present.  So that initial file
in each category should read "Remove trailing whitespace characters".

- the patch touches the testsuite.  Note that not all source files in
the testsuite are UTF-8 encoded, and we want the testsuite to contain a
variety of source formatting idioms (and examples of badly formatted
source code).

- some of our source files use U+000C, the form feed character, and the
patch eliminates these.  I think this is an old convention used to
indicate a major change of topic within the source file.  Perhaps it
leads to a page break when printing the source file?  Personally I
dislike this convention, and feel a suitable big comment line would be
clearer such as:

/* Name of new topic.

   General comments about the new topic, where useful.  */

for such "high-level" source file organizational bounaries, but perhaps
people like and use the form feed characters?

Hope this is constructive
Dave

[1] see e.g. a134b6ce8e5c589f8c1b58cdf124cd4a916b0e8c


> 
> Anyway, for posterity, here is the python script I used:
> 
> ```
> from os import listdir
> from os.path import isfile, join
> 
> 
> def clean_file(p):
>     if not p.endswith(".cc") and not p.endswith(".h"):
>     return
>     with open(p, 'r', encoding='utf8') as f:
>     content = f.read().split('\n')
>     updated = 0
>     i = 0
>     while i < len(content):
>     s = content[i].rstrip()
>     if s != content[i]:
>     updated += 1
>     content[i] = s
>     i += 1
>     if updated == 0:
>     return
>     with open(p, 'w', encoding='utf8') as f:
>     f.write('\n'.join(content))
> 
> 
> def recur_read(p):
>     for f in listdir(p):
>     full_path = join(p, f)
>     if isfile(full_path):
>     clean_file(full_path)
>     else:
>     recur_read(full_path)
> 
> recur_read(".")
> ```
> 
> Cordially.

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

[Guillaume Gomez via Gcc-patches]

Hi David.

Thanks for the feedback! Well, I think at this point, better to get
"global approval" on the idea and on what you suggested (which I agree
with) before I make any additional changes considering how big the
patch is.
Let's wait for others to also express their opinion here.

Re: [Patch] OpenMP (C only): omp allocate - extend parsing support, improve diagnostic (was: [Patch] OpenMP (C only): omp allocate - handle stack vars, improve diagnostic)

[Jakub Jelinek via Gcc-patches]

On Mon, Sep 11, 2023 at 03:21:54PM +0200, Tobias Burnus wrote:
> +  if (TREE_STATIC (var))
> + {
> +   if (allocator == NULL_TREE && allocator_loc == UNKNOWN_LOCATION)
> + error_at (loc, "% clause required for "
> +"static variable %qD", var);
> +   else if (allocator
> +&& (tree_int_cst_sgn (allocator) != 1
> +|| tree_to_shwi (allocator) > 8))

Has anything checked that in this case allocator is actually INTEGER_CST
which fits into shwi?  Otherwise tree_to_shwi will ICE.
Consider say allocator argument of
329857234985743598347598437598347594835743895743wb
or (((unsigned __int128) 0x123456789abcdef0) << 64)
Either tree_fits_shwi_p (allocator) check would do it, or perhaps
else if (allocator
 && TREE_CODE (allocator) == INTEGER_CST
 && wi::to_widest (allocator) > 0
 && wi::to_widest (allocator) <= 8)
?

> +  if (allocator
> +   && TREE_CODE (allocator) == VAR_DECL
> +   && c_check_in_current_scope (var))
> + {
> +   if (linemap_location_before_p (line_table, DECL_SOURCE_LOCATION (var),
> +  DECL_SOURCE_LOCATION (allocator)))
> + {
> +   error_at (OMP_CLAUSE_LOCATION (nl),
> + "allocator variable %qD must be declared before %qD",
> + allocator, var);
> +   inform (DECL_SOURCE_LOCATION (allocator),
> +   "allocator declared here");
> +   inform (DECL_SOURCE_LOCATION (var), "declared here");
> + }
> +   else
> +{
> +  gcc_assert (cur_stmt_list
> +  && TREE_CODE (cur_stmt_list) == STATEMENT_LIST);
> +  tree_stmt_iterator l = tsi_last (cur_stmt_list);
> +  while (!tsi_end_p (l))
> +{
> +  if (linemap_location_before_p (line_table, EXPR_LOCATION (*l),
> + DECL_SOURCE_LOCATION (var)))
> +break;
> +  if (TREE_CODE (*l) == MODIFY_EXPR
> +  && TREE_OPERAND (*l, 0) == allocator)
> +{
> +  error_at (EXPR_LOCATION (*l),
> +"allocator variable %qD, used in the "
> +"% directive for %qD, must not be "
> +"modified between declaration of %qD and its "
> +"% directive",
> +allocator, var, var);
> +  inform (DECL_SOURCE_LOCATION (var), "declared here");
> +  inform (OMP_CLAUSE_LOCATION (nl), "used here");
> +  break;
> +   }
> + --l;
> +  }
> +}

BTW, it doesn't necessarily have to be just the simple case which you catch
here, namely that allocator is a VAR_DECL defined after var in current
scope.
One can have an expression which uses those other vars, say
  int v;
  int a = 1;
  int b[n]; // VLA
  b[a] = 5;
  #pragma omp allocate (v) allocator (foo (a, &b[a]))
where foo would be some function which returns omp_allocator_handle_t.
Or it could be e.g. lambda declared later, etc.
I bet we can't catch everything, but perhaps e.g. doing the first
diagnostics from within walk_tree might be better.

Jakub

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

[Jakub Jelinek via Gcc-patches]

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.

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

[PATCH v2 1/2] c++: Initial support for P0847R7 (Deducing This) [PR102609]

[waffl3x via Gcc-patches]

Bootstrapped and tested on x86_64-linux with no regressions.

Hopefully I fixed all the issues. I also took the opportunity to remove the
small mistake present in v1, so that is no longer a concern.

Thanks again for all the patience.
  -AlexFrom 0db52146880faf20e7a7b786dad47c686a5f26d6 Mon Sep 17 00:00:00 2001
From: Waffl3x 
Date: Mon, 11 Sep 2023 04:21:10 -0600
Subject: [PATCH] c++: Initial support for C++23 P0847R7 (Deducing This)
 [PR102609]

This patch implements initial support for P0847R7, without additions to
diagnostics.  Almost everything should work correctly, barring a few
limitations which are listed below.  I attempted to minimize changes to the
existing code, treating explicit object member functions as static functions,
while flagging them to give them extra powers seemed to be the best way of
achieving this.  For this patch, the flag is only utilized in call.cc for
resolving overloads and making the actual function call.  To achieve this,
conversion of a FUNC_TYPE to a METHOD_TYPE is suppressed when the first
parameter of the FUNC_TYPE is an explicit object parameter, this appears to be
sufficient.  I opted to create a new variable to achieve this instead of
using "staticp" to avoid any possible confusion.

As for the previously mentioned limitations, lambdas do not work correctly yet,
but I suspect that a few tweaks are all it will take to have them fully
functional.  User defined conversion functions are not called when an explicit
object member function with an explicit object parameter of an unrelated type
is called.  The following case does not behave correctly because of this.

struct S {
  operator size_t() {
return 42;
  }
  size_t f(this size_t n) {
return n;
  }
};

int main()
{
  S s{};
  size_t a = s.f();
}

Currently, it appears that the object argument is simply reinterpreted as
a size_t instead of properly calling the user defined conversion function.
The validity of such a conversion is still considered however, if there is no
way to convert S to a size_t an appropriate compile error will be emitted.
I have an idea of what changes need to be made to fix this, but I did not
persue this for the initial implementation patch.
This bug can be observed in the explicit-object-param4.C test case, while
explicit-object-param3.C demonstrates the non functioning lambdas.

	PR c++/102609

gcc/cp/ChangeLog:

	PR c++/102609
	Initial support for C++23 P0847R7 - Deducing this.
	* call.cc (add_candidates): Check if fn is an xobj member function.
	(build_over_call): Ditto.
	* cp-tree.h (struct lang_decl_base::xobj_flag): New data member.
	(DECL_FUNC_XOBJ_FLAG): Define.
	(DECL_PARM_XOBJ_FLAG): Define.
	(DECL_IS_XOBJ_MEMBER_FUNC): Define.
	(enum cp_decl_spec): Add ds_this.
	* decl.cc (grokfndecl): Set xobj_flag if first param is an xobj param.
	(grokdeclarator): For xobj member functions, Don't change type to
	METHOD_TYPE, leave it as FUNC_TYPE. For PARM decl_context, set
	decl_flag_3 if param is an xobj param.
	* parser.cc (cp_parser_decl_specifier_seq): Handle this specifier.
	(set_and_check_decl_spec_loc): Add "this".

gcc/ChangeLog:

	PR c++/102609
	Initial support for C++23 P0847R7 - Deducing this.
	* tree-core.h (struct tree_decl_common): Comment use of decl_flag_3.

gcc/testsuite/ChangeLog:

	PR c++/102609
	Initial support for C++23 P0847R7 - Deducing this.
	* g++.dg/cpp23/explicit-object-param1.C: New test.
	* g++.dg/cpp23/explicit-object-param2.C: New test.
	* g++.dg/cpp23/explicit-object-param3.C: New test.
	* g++.dg/cpp23/explicit-object-param4.C: New test.

Signed-off-by: Waffl3x 
---
 gcc/cp/call.cc|   6 +-
 gcc/cp/cp-tree.h  |  21 +++-
 gcc/cp/decl.cc|  24 
 gcc/cp/parser.cc  |  15 ++-
 .../g++.dg/cpp23/explicit-object-param1.C | 114 ++
 .../g++.dg/cpp23/explicit-object-param2.C |  28 +
 .../g++.dg/cpp23/explicit-object-param3.C |  15 +++
 .../g++.dg/cpp23/explicit-object-param4.C |  33 +
 gcc/tree-core.h   |   3 +-
 9 files changed, 254 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp23/explicit-object-param1.C
 create mode 100644 gcc/testsuite/g++.dg/cpp23/explicit-object-param2.C
 create mode 100644 gcc/testsuite/g++.dg/cpp23/explicit-object-param3.C
 create mode 100644 gcc/testsuite/g++.dg/cpp23/explicit-object-param4.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 399345307ea..37690fdae25 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -6547,7 +6547,8 @@ add_candidates (tree fns, tree first_arg, const vec *args,
   tree fn_first_arg = NULL_TREE;
   const vec *fn_args = args;
 
-  if (DECL_NONSTATIC_MEMBER_FUNCTION_P (fn))
+  if (DECL_NONSTATIC_MEMBER_FUNCTION_P (fn)
+	  || DECL_IS_XOBJ_MEMBER_FUNC (fn))
 	{
 	  /* Figure out where the object arg comes from.  If this
 	 function is a non-static member and we didn't get an
@@

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

[Christophe Lyon via Gcc-patches]

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




>
> >>
> >> >
> >> > This patch requires the missing thread-fence effective target in the
> >> > tests that need it, making them UNSUPPORTED instead of FAIL and
> >> > UNRESOLVED.
> >>
> >> Some of the modified tests should not be using
> >> __gnu_debug::_Safe_sequence_base::_M_detach_all(), because they don't
> >> use the Debug Mode. I don't know where those linker errors come from.
> >> For example, the 23_containers/span/*assert_neg.cc and
> >> 26_numerics/valarray/* tests shouldn't use debug iterators or atomics.
> >> Neither should 25_algorithms/sample/2.cc nor
> >> 26_numerics/bit/bit.pow.two/bit_ceil_neg.cc
> >
> >
> > Ouch!  I had the feeling this patch wouldn't count as obvious :-)
> >
> > I confess I didn't analyze the linker map for every single test updated
> by this patch
> > I can have a deeper look based on your comment below, excluding those
> that look "OK"
> >
> >>
> >> The last three in the patch shouldn't use it either:
> >>
> >> > diff --git
> a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> >> > index cb818708aef..372ed6e0c00 100644
> >> > --- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> >> > +++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> >> > @@ -18,6 +18,7 @@
> >> >  // { dg-do run { target c++14 } }
> >> >  // { dg-add-options libatomic }
> >> >  // { dg-xfail-if "poll not available" { *-*-rtems* } }
> >> > +// { dg-require-thread-fence "" } // needed by
> __gnu_debug::_Safe_sequence_base::_M_detach_all()
> >> >
> >> >  #include 
> >> >  #include 
> >> > diff --git
> a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> >> > index ae51979c3b4..8383e0be6a4 100644
> >> > --- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> >> > +++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> >> > @@ -18,6 +18,7 @@
> >> >  // { dg-do run { target c++14 } }
> >> >  // { dg-add-options libatomic }
> >> >  // { dg-xfail-if "poll not available" { *-*-rtems* } }
> >> > +// { dg-require-thread-fence "" } // needed by
> __gnu_debug::_Safe_sequence_base::_M_detach_all()
> >> >
> >> >  #include 
> >> >  #include 
> >> > diff --git
> a/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
> b/libstdc++-v3/

[committed] libstdc++: Formatting std::thread::id and std::stacktrace (P2693R1)

[Jonathan Wakely via Gcc-patches]

Tested aarch64-linux. Pushed to trunk.

-- >8 --

New std::formatter specializations for C++23.

libstdc++-v3/ChangeLog:

* include/bits/version.def (__cpp_lib_formatters): Define.
* include/bits/version.h: Regenerate.
* include/std/stacktrace (formatter)
(formatter>): Define.
* include/std/thread (formatter): Define.
* testsuite/19_diagnostics/stacktrace/output.cc: New test.
* testsuite/19_diagnostics/stacktrace/synopsis.cc: Add
std::formatter specializations.
* testsuite/19_diagnostics/stacktrace/version.cc: Check
__cpp_lib_formatters macro.
* testsuite/30_threads/thread/id/hash.cc: Remove gthreads
dependency.
* testsuite/30_threads/thread/id/operators.cc: Likewise.
* testsuite/30_threads/thread/id/operators_c++20.cc: Likewise.
* testsuite/30_threads/thread/id/output.cc: New test.
---
 libstdc++-v3/include/bits/version.def |   9 ++
 libstdc++-v3/include/bits/version.h   |  25 +++--
 libstdc++-v3/include/std/stacktrace   |  80 ++
 libstdc++-v3/include/std/thread   |  62 +++
 .../19_diagnostics/stacktrace/output.cc   |  58 ++
 .../19_diagnostics/stacktrace/synopsis.cc |   3 +
 .../19_diagnostics/stacktrace/version.cc  |   6 +
 .../testsuite/30_threads/thread/id/hash.cc|   2 -
 .../30_threads/thread/id/operators.cc |   1 -
 .../30_threads/thread/id/operators_c++20.cc   |   1 -
 .../testsuite/30_threads/thread/id/output.cc  | 103 ++
 11 files changed, 339 insertions(+), 11 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/19_diagnostics/stacktrace/output.cc
 create mode 100644 libstdc++-v3/testsuite/30_threads/thread/id/output.cc

diff --git a/libstdc++-v3/include/bits/version.def 
b/libstdc++-v3/include/bits/version.def
index da8d067dd1a..8d9b2f71a2e 100644
--- a/libstdc++-v3/include/bits/version.def
+++ b/libstdc++-v3/include/bits/version.def
@@ -1526,6 +1526,15 @@ ftms = {
   };
 };
 
+ftms = {
+  name = formatters;
+  values = {
+v = 202302;
+cxxmin = 23;
+hosted = yes;
+  };
+};
+
 ftms = {
   name = ios_noreplace;
   values = {
diff --git a/libstdc++-v3/include/std/stacktrace 
b/libstdc++-v3/include/std/stacktrace
index 358a81b82e5..da0e48d3532 100644
--- a/libstdc++-v3/include/std/stacktrace
+++ b/libstdc++-v3/include/std/stacktrace
@@ -31,10 +31,12 @@
 #include 
 
 #define __glibcxx_want_stacktrace
+#define __glibcxx_want_formatters
 #include 
 
 #ifdef __cpp_lib_stacktrace // C++ >= 23 && hosted && HAVE_STACKTRACE
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -692,6 +694,84 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   return std::move(__os).str();
 }
 
+  template<>
+class formatter
+{
+public:
+  constexpr typename basic_format_parse_context::iterator
+  parse(basic_format_parse_context& __pc)
+  {
+   __format::_Spec __spec{};
+   const auto __last = __pc.end();
+   auto __first = __pc.begin();
+
+   auto __finalize = [this, &__spec] {
+ _M_spec = __spec;
+   };
+
+   auto __finished = [&] {
+ if (__first == __last || *__first == '}')
+   {
+ __finalize();
+ return true;
+   }
+ return false;
+   };
+
+   if (__finished())
+ return __first;
+
+   __first = __spec._M_parse_fill_and_align(__first, __last);
+   if (__finished())
+ return __first;
+
+   __first = __spec._M_parse_width(__first, __last, __pc);
+   if (__finished())
+ return __first;
+
+   __throw_format_error("format error: invalid format-spec for "
+"std::stacktrace_entry");
+  }
+
+  template
+   typename basic_format_context<_Out, char>::iterator
+   format(const stacktrace_entry& __x,
+  basic_format_context<_Out, char>& __fc) const
+   {
+ std::ostringstream __os;
+ __os << __x;
+ return __format::__write(__fc.out(), __os.view());
+   }
+
+private:
+  __format::_Spec _M_spec;
+};
+
+  template
+class formatter>
+{
+public:
+  constexpr typename basic_format_parse_context::iterator
+  parse(basic_format_parse_context& __pc)
+  {
+   const auto __first = __pc.begin();
+   if (__first == __pc.end() || *__first == '}')
+ return __first;
+   __throw_format_error("format error: invalid format-spec for "
+"std::basic_stacktrace");
+  }
+
+  template
+   typename basic_format_context<_Out, char>::iterator
+   format(const basic_stacktrace<_Allocator>& __x,
+  basic_format_context<_Out, char>& __fc) const
+   {
+ std::ostringstream __os;
+ __os << __x;
+ return __format::__write(__fc.out(), __os.view());
+   }
+};
+
   namespace pmr
   {
 using stacktrace
diff --git a/libstdc++-v3/include/std/

Re: [PATCH 1/2] c++: refine dependent_alias_template_spec_p [PR90679]

[Patrick Palka via Gcc-patches]

On Thu, 1 Jun 2023, Patrick Palka wrote:

> For a complex alias template-id, dependent_alias_template_spec_p returns
> true if any template argument of the template-id is dependent.  This
> predicate indicates that substitution into the template-id may behave
> differently with respect to SFINAE than substitution into the expanded
> alias, and so the alias is in a way non-transparent.  For example
> 'first_t' in
> 
>   template using first_t = T;
>   template first_t f();
> 
> is such an alias template-id since first_t doesn't use its second
> template parameter and so the substitution into the expanded alias would
> discard the SFINAE effects of the corresponding (dependent) argument 'T&'.
> 
> But this predicate is overly conservative since what really matters for
> sake of SFINAE equivalence is whether a template argument corresponding
> to an _unused_ template parameter is dependent.  So the predicate should
> return false for e.g. 'first_t' or 'first_t'.
> 
> This patch refines the predicate appropriately.  We need to be able to
> efficiently determine which template parameters of a complex alias
> template are unused, so to that end we add a new out parameter to
> complex_alias_template_p and cache its result in an on-the-side
> hash_map that replaces the existing TEMPLATE_DECL_COMPLEX_ALIAS_P
> flag.  And in doing so, we fix a latent bug that this flag wasn't
> being propagated during partial instantiation, and so we were treating
> all partially instantiated member alias templates as non-complex.
> 
>   PR c++/90679
> 
> gcc/cp/ChangeLog:
> 
>   * cp-tree.h (TEMPLATE_DECL_COMPLEX_ALIAS_P): Remove.
>   (most_general_template): Constify parameter.
>   * pt.cc (push_template_decl): Adjust after removing
>   TEMPLATE_DECL_COMPLEX_ALIAS_P.
>   (complex_alias_tmpl_info): New hash_map.
>   (uses_all_template_parms_data::seen): Change type to
>   tree* from bool*.
>   (complex_alias_template_r): Adjust accordingly.
>   (complex_alias_template_p): Add 'seen_out' out parameter.
>   Call most_general_template and check PRIMARY_TEMPLATE_P.
>   Use complex_alias_tmpl_info to cache the result and set
>   '*seen_out' accordigly.
>   (dependent_alias_template_spec_p): Add !processing_template_decl
>   early exit test.  Consider dependence of only template arguments
>   corresponding to seen template parameters as per
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/cpp0x/alias-decl-75.C: New test.

Ping.

> ---
>  gcc/cp/cp-tree.h   |   7 +-
>  gcc/cp/pt.cc   | 101 +++--
>  gcc/testsuite/g++.dg/cpp0x/alias-decl-75.C |  24 +
>  3 files changed, 100 insertions(+), 32 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-75.C
> 
> diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> index a1b882f11fe..5330d1e1f62 100644
> --- a/gcc/cp/cp-tree.h
> +++ b/gcc/cp/cp-tree.h
> @@ -543,7 +543,6 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX];
> 2: DECL_THIS_EXTERN (in VAR_DECL, FUNCTION_DECL or PARM_DECL)
>DECL_IMPLICIT_TYPEDEF_P (in a TYPE_DECL)
>DECL_CONSTRAINT_VAR_P (in a PARM_DECL)
> -  TEMPLATE_DECL_COMPLEX_ALIAS_P (in TEMPLATE_DECL)
>DECL_INSTANTIATING_NSDMI_P (in a FIELD_DECL)
>USING_DECL_UNRELATED_P (in USING_DECL)
> 3: DECL_IN_AGGR_P.
> @@ -3655,10 +3654,6 @@ struct GTY(()) lang_decl {
>  #define TYPE_DECL_ALIAS_P(NODE) \
>DECL_LANG_FLAG_6 (TYPE_DECL_CHECK (NODE))
>  
> -/* Nonzero for TEMPLATE_DECL means that it is a 'complex' alias template.  */
> -#define TEMPLATE_DECL_COMPLEX_ALIAS_P(NODE) \
> -  DECL_LANG_FLAG_2 (TEMPLATE_DECL_CHECK (NODE))
> -
>  /* Nonzero for a type which is an alias for another type; i.e, a type
> which declaration was written 'using name-of-type =
> another-type'.  */
> @@ -7403,7 +7398,7 @@ extern tree tsubst_argument_pack(tree, 
> tree, tsubst_flags_t, tree);
>  extern tree tsubst_template_args (tree, tree, tsubst_flags_t, 
> tree);
>  extern tree tsubst_template_arg  (tree, tree, 
> tsubst_flags_t, tree);
>  extern tree tsubst_function_parms(tree, tree, tsubst_flags_t, 
> tree);
> -extern tree most_general_template(tree);
> +extern tree most_general_template(const_tree);
>  extern tree get_mostly_instantiated_function_type (tree);
>  extern bool problematic_instantiation_changed(void);
>  extern void record_last_problematic_instantiation (void);
> diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> index 7fb3e75bceb..1b28195e10d 100644
> --- a/gcc/cp/pt.cc
> +++ b/gcc/cp/pt.cc
> @@ -211,7 +211,6 @@ static tree listify (tree);
>  static tree listify_autos (tree, tree);
>  static tree tsubst_template_parm (tree, tree, tsubst_flags_t);
>  static tree instantiate_alias_template (tree, tree, tsubst_flags_t);
> -static bool complex_alias_template_p (const_tree tmpl);
>  static tree get_underlying_templa

Re: [PATCH 2/2] c++: partial ordering and dep alias tmpl specs [PR90679]

[Patrick Palka via Gcc-patches]

On Thu, 1 Jun 2023, Patrick Palka wrote:

> During partial ordering, we want to look through dependent alias
> template specializations within template arguments and otherwise
> treat them as opaque in other contexts (see e.g. r7-7116-g0c942f3edab108
> and r11-7011-g6e0a231a4aa240).  To that end template_args_equal was
> given a partial_order flag that controls this behavior.  This flag
> does the right thing when a dependent alias template specialization
> appears as template argument of the partial specialization, e.g. in
> 
>   template using first_t = T;
>   template struct traits;
>   template struct traits> { }; // #1
>   template struct traits> { }; // #2
> 
> we correctly consider #2 to be more specialized than #1.  But if
> the alias specialization appears as a template argument of another
> class template specialization, e.g. in
> 
>   template struct traits>> { }; // #1
>   template struct traits>> { }; // #2
> 
> then we incorrectly consider #1 and #2 to be unordered.  This is because
> 
>   1. we don't propagate the flag to recursive template_args_equal calls
>   2. we don't use structural equality for class template specializations
>  written in terms of dependent alias template specializations
> 
> This patch fixes the first issue by turning the partial_order flag into
> a global.  This patch fixes the second issue by making us propagate
> structural equality appropriately when building a class template
> specialization.  In passing this patch also improves hashing of
> specializations that use structural equality.
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?

Ping.

> 
>   PR c++/90679
> 
> gcc/cp/ChangeLog:
> 
>   * cp-tree.h (comp_template_args): Remove partial_order
>   parameter.
>   (template_args_equal): Likewise.
>   * pt.cc (iterative_hash_template_arg) : Hash
>   the template and arguments for specializations that use
>   structural equality.
>   (comparing_for_partial_ordering): New flag.
>   (template_args_equal): Remove partial order parameter and
>   use comparing_for_partial_ordering instead.
>   (comp_template_args): Likewise.
>   (comp_template_args_porder): Set comparing_for_partial_ordering
>   instead.  Make static.
>   (any_template_arguments_need_structural_equality_p): Return true
>   for an argument that's a dependent alias template specialization
>   or a class template specialization that itself needs structural
>   equality.
>   * tree.cc (cp_tree_equal) : Adjust call to
>   comp_template_args.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/cpp0x/alias-decl-75a.C: New test.
>   * g++.dg/cpp0x/alias-decl-75b.C: New test.
> ---
>  gcc/cp/cp-tree.h|  4 +--
>  gcc/cp/pt.cc| 40 +
>  gcc/cp/tree.cc  |  2 +-
>  gcc/testsuite/g++.dg/cpp0x/alias-decl-75a.C | 26 ++
>  gcc/testsuite/g++.dg/cpp0x/alias-decl-75b.C | 26 ++
>  5 files changed, 88 insertions(+), 10 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-75a.C
>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-75b.C
> 
> diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> index 5330d1e1f62..f08e5630a5c 100644
> --- a/gcc/cp/cp-tree.h
> +++ b/gcc/cp/cp-tree.h
> @@ -7381,8 +7381,8 @@ extern int template_class_depth (tree);
>  extern int is_specialization_of  (tree, tree);
>  extern bool is_specialization_of_friend  (tree, tree);
>  extern bool comp_template_args   (tree, tree, tree * = 
> NULL,
> -  tree * = NULL, bool = false);
> -extern int template_args_equal  (tree, tree, bool = false);
> +  tree * = NULL);
> +extern int template_args_equal  (tree, tree);
>  extern tree maybe_process_partial_specialization (tree);
>  extern tree most_specialized_instantiation   (tree);
>  extern tree most_specialized_partial_spec   (tree, tsubst_flags_t);
> diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> index 1b28195e10d..1a32f10b22b 100644
> --- a/gcc/cp/pt.cc
> +++ b/gcc/cp/pt.cc
> @@ -1913,6 +1913,11 @@ iterative_hash_template_arg (tree arg, hashval_t val)
>   default:
> if (tree canonical = TYPE_CANONICAL (arg))
>   val = iterative_hash_object (TYPE_HASH (canonical), val);
> +   else if (tree ti = TYPE_TEMPLATE_INFO (arg))
> + {
> +   val = iterative_hash_template_arg (TI_TEMPLATE (ti), val);
> +   val = iterative_hash_template_arg (TI_ARGS (ti), val);
> + }
> break;
>   }
>  
> @@ -9296,6 +9301,12 @@ coerce_template_parms (tree parms,
>return return_full_args ? new_args : new_inner_args;
>  }
>  
> +/* Whether we are comparing template arguments during partial ordering
> +   (and therefore

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

[Christophe Lyon via Gcc-patches]

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?

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


> > Part 3 of this serie of patches I hope will be regstrapped for
> > Friday.
>
> Thanks; I'm impressed at how much progress you've made on this problem.
>
> Dave
>
>

[PATCH] MATCH: [PR111349] add missing :c to cmp in the `(a CMP CST1) ? max : a` pattern

[Andrew Pinski via Gcc-patches]

When I added this pattern in r14-1411-g17cca3c43e2f49, 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/111349

gcc/ChangeLog:

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

gcc/testsuite/ChangeLog:

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

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

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

[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 &errmsg)
+{
+  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 &errmsg)
+{
+  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 &location, const ErrorCode code,
+ const std::string &errmsg)
+{
+  /* TODO: 'error_at' would like a non-'const' 'rich_location *'.  */
+  rich_location &gcc_loc = const_cast (location.get ());
+  diagnostic_metadata m;
+  rust_error_code_rule rule (code);
+  m.add_rule (rule);
+  error_meta (&gcc_loc, m, "%s", errmsg.c_str ());
+}
+
 void
 rust_error_at (const RichLocation &location, const ErrorCode code,
   const char *fmt, ...)
@@ -177,6 +236,14 @@ rust_error_at (const RichLocation &location, const 
ErrorCode code,
   va_end (ap);
 }
 
+void
+rust_be_warning_at (const Location location, int opt,
+   const std::string &warningmsg)
+{
+  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 &fatalmsg)
+{
+  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 &infomsg)
+{
+  location_t gcc_loc = location.gcc_location ();
+  inform (gcc_loc, "%s", inf

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

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

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

[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: [PATCH v2] libstdc++: Define _GLIBCXX_HAS_BUILTIN_TRAIT

[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: [PATCH v2] libstdc++: Define _GLIBCXX_HAS_BUILTIN_TRAIT

[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 2/2] libstdc++: Add dg-require-thread-fence in several tests

[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: RE: [PATCH v1] RISC-V: Implement RESOLVE_OVERLOADED_BUILTIN for RVV intrinsic

[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, &p_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, other

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

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

[PATCH] libstdc++ Use _GLIBCXX_USE_BUILTIN_TRAIT

[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

[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

Re: [PATCH] libstdc++ Use _GLIBCXX_USE_BUILTIN_TRAIT

[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] s390: Fix builtins vec_rli and verll

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

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

[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 

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

[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(&seq, __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(&seq, (__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

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

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

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

[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 GLIBCXX_TESTSUITE_STDS
+  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 i

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

[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 -
 .../test

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

[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 06/13] libstdc++: Remove dg-options "-std=gnu++20" from and tests

[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.
* testsuite/

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

[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
+++ b/libstdc++-v3/testsuite/20_u

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

[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 07/13] libstdc++: Remove dg-options "-std=gnu++2a" from constrained algo tests

[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 02/13] libstdc++: Replace dg-options "-std=c++11" with dg-add-options strict_std

[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" }
+// { dg-do

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

[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 -
 libstdc++-v3/

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

[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 
b/li

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

[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 08/13] libstdc++: Remove dg-options "-std=gnu++20" from std::format tests

[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
--- a/libstdc++-v3/testsuite/std/

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

[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 "=&r"))]
+  "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 10/13] libstdc++: Remove dg-options "-std=gnu++23" from std::expected tests

[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" }
 // {

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

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

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

[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 0/2] Optimize is_member_function_pointer trait performance

[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

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

[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 1/2] c++: Implement __is_member_function_pointer built-in trait

[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.
+SA_TEST_CATEGORY(__is_member_function_point

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

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

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

[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: [r14-3823 Regression] FAIL: c-c++-common/analyzer/compound-assignment-1.c -std=c++98 (test for warnings, line 72) on Linux/x86_64

[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.)
>

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

[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: [PATCH v2 1/5][Committed] RISC-V: Update Types for Vector Instructions

[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] small _BitInt tweaks

[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 3/5][Committed] RISC-V: Add Types to Un-Typed Zicond Instructions

[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

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

[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] fortran: Undo new symbols in all namespaces [PR110996]

[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 *&sym)
  }


-/* 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 *&sym)
  {
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)

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 (&ns->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 (&p->ns->sym_root,gfc_dt_upper_string (p->name));
-  else
-   gfc_delete_symtree (&p->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 subrou

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

[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] analyzer: implement symbolic value support for CPython plugin's refcnt checker [PR107646]

[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

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

[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: [C PATCH 1/6 v2] c: reorganize recursive type checking

[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: [PATCH V3] RISC-V: Support Dynamic LMUL Cost model

[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: [PATCH] gimple-match: Do not try UNCOND optimization with COND_LEN.

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

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

[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: [r14-3823 Regression] FAIL: c-c++-common/analyzer/compound-assignment-1.c -std=c++98 (test for warnings, line 72) on Linux/x86_64

[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

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

[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)
> <1f

[PATCH 0/2] Optimize is_unbounded_array trait performance

[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

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

[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);
+SA_TEST_CATEGORY(__is_unbounded_arr

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

[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] RISC-V: Finish Typing Un-Typed Instructions and Turn on Assert

[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