[Committed] RISC-V: Enhance a testcase

[Juzhe-Zhong]

This test should pass no matter how we adjust cost model.

Remove -fno-vect-cost-model.

Committed.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/fold-min-poly.c: Remove 
-fno-vect-cost-model

---
 gcc/testsuite/gcc.target/riscv/rvv/autovec/fold-min-poly.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/fold-min-poly.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/fold-min-poly.c
index de4c472c76e..3f524dba868 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/fold-min-poly.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/fold-min-poly.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options " -march=rv64gcv_zvl128b -mabi=lp64d -O3 --param 
riscv-autovec-preference=scalable --param riscv-autovec-lmul=m1 
-fno-vect-cost-model" } */
+/* { dg-options " -march=rv64gcv_zvl128b -mabi=lp64d -O3 --param 
riscv-autovec-preference=scalable --param riscv-autovec-lmul=m1" } */
 
 void foo1 (int* restrict a, int* restrict b, int n)
 {
-- 
2.36.3

[PATCH] c++: reject packs on xobj params. [PR113307]

[waffl3x]

Bootstrapped and tested on x86_64-linux with no regressions.

I'm still getting used to things so let me know if the change log
entries are excessive, thanks.From 9dc168e7bcbbd7d515fa28cb9cae28ec113fae0f Mon Sep 17 00:00:00 2001
From: Waffl3x 
Date: Thu, 11 Jan 2024 14:32:46 -0700
Subject: [PATCH] c++: reject packs on xobj params. [PR113307]

Reject and diagnose xobj parameters declared as parameter packs.

	PR c++/113307

gcc/cp/ChangeLog:

	* parser.cc (cp_parser_parameter_declaration): Reject packs
	on xobj params.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp23/explicit-obj-diagnostics3.C: Add test for
	rejection of packs.

Signed-off-by: Waffl3x 
---
 gcc/cp/parser.cc  |  21 +++-
 .../g++.dg/cpp23/explicit-obj-diagnostics3.C  | 106 +-
 2 files changed, 125 insertions(+), 2 deletions(-)

diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 8ab98cc0c23..70fbba09bf8 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -25706,6 +25706,25 @@ cp_parser_parameter_declaration (cp_parser *parser,
  for a C-style variadic function. */
   token = cp_lexer_peek_token (parser->lexer);
 
+  bool const xobj_param_p
+= decl_spec_seq_has_spec_p (_specifiers, ds_this);
+
+  if (xobj_param_p
+  && ((declarator && declarator->parameter_pack_p)
+	  || cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS)))
+{
+  location_t xobj_param
+	= make_location (decl_specifiers.locations[ds_this],
+			 decl_spec_token_start->location,
+			 input_location);
+  error_at(xobj_param,
+	   "an explicit object parameter cannot "
+	   "be a function parameter pack");
+  /* Suppress errors that occur down the line.  */
+  if (declarator)
+	declarator->parameter_pack_p = false;
+}
+
   /* If a function parameter pack was specified and an implicit template
  parameter was introduced during cp_parser_parameter_declaration,
  change any implicit parameters introduced into packs.  */
@@ -25829,7 +25848,7 @@ cp_parser_parameter_declaration (cp_parser *parser,
   if (default_argument)
 STRIP_ANY_LOCATION_WRAPPER (default_argument);
 
-  if (decl_spec_seq_has_spec_p (_specifiers, ds_this))
+  if (xobj_param_p)
 {
   if (default_argument)
 	{
diff --git a/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C b/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C
index ec091d6ca67..304cf029f8f 100644
--- a/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C
+++ b/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics3.C
@@ -1,7 +1,9 @@
 // P0847R7
 // { dg-do compile { target c++23 } }
 
-// rejection and diagnosis of an xobj parameter declared with a default argument
+// rejection and diagnosis of an incorrectly declared xobj parameter
+
+// default argument
 
 struct S {
   void f0(this S = {}) {} // { dg-error "an explicit object parameter may not have a default argument" }
@@ -18,3 +20,105 @@ void S::f2(this S = {}) {} // { dg-error "an explicit object parameter may not h
 void S::f11(this S s) {}
 void S::f12(this S s = {}) {} // { dg-error "an explicit object parameter may not have a default argument" }
 
+// parameter pack
+
+struct S0 {
+  template
+  void f(this Selves...) {} // { dg-error "an explicit object parameter cannot be a function parameter pack" }
+
+  template
+  void g(this Selves... selves) {}  // { dg-error "an explicit object parameter cannot be a function parameter pack" }
+
+  void h(this auto...) {}  // { dg-error "an explicit object parameter cannot be a function parameter pack" }
+  void j(this auto... selves) {}  // { dg-error "an explicit object parameter cannot be a function parameter pack" }
+
+  template
+  void fd(this Selves...);  // { dg-error "an explicit object parameter cannot be a function parameter pack" }
+
+  template
+  void gd(this Selves... selves);  // { dg-error "an explicit object parameter cannot be a function parameter pack" }
+
+  void hd(this auto...);  // { dg-error "an explicit object parameter cannot be a function parameter pack" }
+  void jd(this auto... selves);  // { dg-error "an explicit object parameter cannot be a function parameter pack" }
+};
+
+struct S1 {
+  template
+  void f(this Selves&...) {}  // { dg-error "an explicit object parameter cannot be a function parameter pack" }
+
+  template
+  void g(this Selves&... selves) {}  // { dg-error "an explicit object parameter cannot be a function parameter pack" }
+
+  void h(this auto&...) {}  // { dg-error "an explicit object parameter cannot be a function parameter pack" }
+  void j(this auto&... selves) {}  // { dg-error "an explicit object parameter cannot be a function parameter pack" }
+
+  template
+  void fd(this Selves&...);  // { dg-error "an explicit object parameter cannot be a function parameter pack" }
+
+  template
+  void gd(this Selves&... selves);  // { dg-error "an explicit object parameter cannot be a function parameter pack" }
+
+  void hd(this auto&...);  // { dg-error "an explicit object parameter cannot 

Re: [PATCH v5] RISC-V: Rewrite some instructions using ASM targethook

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

ok.



juzhe.zh...@rivai.ai
 
From: Jun Sha (Joshua)
Date: 2024-01-12 11:24
To: gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw; 
christoph.muellner; juzhe.zhong; Jun Sha (Joshua); Jin Ma; Xianmiao Qu
Subject: [PATCH v5] RISC-V: Rewrite some instructions using ASM targethook
There are some xtheadvector instructions that differ from RVV1.0
apart from simply adding "th." prefix. For example, RVV1.0
load/store instructions will have SEW while xtheadvector not;
RVV1.0 will have "o" for indexed-ordered store instructions while
xtheadvecotr not; xtheadvector and RVV1.0 have different
vnsrl/vnsra/vfncvt suffix (vv/vx/vi vs wv/wx/wi).
 
To address this issue without duplicating patterns, we use ASM
targethook to rewrite the whole string of the instructions. We
identify different instructions from the corresponding attribute.
 
gcc/ChangeLog:
 
* config/riscv/thead.cc
(th_asm_output_opcode): Rewrite some instructions.
 
Co-authored-by: Jin Ma 
Co-authored-by: Xianmiao Qu 
Co-authored-by: Christoph Müllner 
---
gcc/config/riscv/thead.cc | 215 +-
1 file changed, 213 insertions(+), 2 deletions(-)
 
diff --git a/gcc/config/riscv/thead.cc b/gcc/config/riscv/thead.cc
index dc3aed3904d..fb088ebff02 100644
--- a/gcc/config/riscv/thead.cc
+++ b/gcc/config/riscv/thead.cc
@@ -27,6 +27,7 @@
#include "backend.h"
#include "tree.h"
#include "rtl.h"
+#include "insn-attr.h"
#include "explow.h"
#include "memmodel.h"
#include "emit-rtl.h"
@@ -890,8 +891,218 @@ th_asm_output_opcode (FILE *asm_out_file, const char *p)
{
   /* We need to add th. prefix to all the xtheadvector
  instructions here.*/
-  if (current_output_insn != NULL && p[0] == 'v')
-fputs ("th.", asm_out_file);
+  if (current_output_insn != NULL)
+{
+  if (get_attr_type (current_output_insn) == TYPE_VLDE ||
+   get_attr_type (current_output_insn) == TYPE_VSTE ||
+   get_attr_type (current_output_insn) == TYPE_VLDFF)
+ {
+   if (strstr (p, "e8") || strstr (p, "e16") ||
+   strstr (p, "e32") || strstr (p, "e64"))
+ {
+   get_attr_type (current_output_insn) == TYPE_VSTE
+   ? fputs ("th.vse", asm_out_file)
+   : fputs ("th.vle", asm_out_file);
+   if (strstr (p, "e8"))
+ return p+4;
+   else
+ return p+5;
+ }
+ }
+
+  if (get_attr_type (current_output_insn) == TYPE_VLDS ||
+   get_attr_type (current_output_insn) == TYPE_VSTS)
+ {
+   if (strstr (p, "vle8") || strstr (p, "vse8") ||
+   strstr (p, "vle16") || strstr (p, "vse16") ||
+   strstr (p, "vle32") || strstr (p, "vse32") ||
+   strstr (p, "vle64") || strstr (p, "vse64"))
+ {
+   get_attr_type (current_output_insn) == TYPE_VSTS
+   ? fputs ("th.vse", asm_out_file)
+   : fputs ("th.vle", asm_out_file);
+   if (strstr (p, "e8"))
+ return p+4;
+   else
+ return p+5;
+ }
+   else if (strstr (p, "vlse8") || strstr (p, "vsse8") ||
+strstr (p, "vlse16") || strstr (p, "vsse16") ||
+strstr (p, "vlse32") || strstr (p, "vsse32") ||
+strstr (p, "vlse64") || strstr (p, "vsse64"))
+ {
+   get_attr_type (current_output_insn) == TYPE_VSTS
+   ? fputs ("th.vsse", asm_out_file)
+   : fputs ("th.vlse", asm_out_file);
+   if (strstr (p, "e8"))
+ return p+5;
+   else
+ return p+6;
+ }
+ }
+
+  if (get_attr_type (current_output_insn) == TYPE_VLDUX ||
+   get_attr_type (current_output_insn) == TYPE_VLDOX)
+ {
+   if (strstr (p, "ei"))
+ {
+   fputs ("th.vlxe", asm_out_file);
+   if (strstr (p, "ei8"))
+ return p+7;
+   else
+ return p+8;
+ }
+ }
+
+  if (get_attr_type (current_output_insn) == TYPE_VSTUX ||
+   get_attr_type (current_output_insn) == TYPE_VSTOX)
+ {
+   if (strstr (p, "ei"))
+ {
+   get_attr_type (current_output_insn) == TYPE_VSTUX
+ ? fputs ("th.vsuxe", asm_out_file)
+ : fputs ("th.vsxe", asm_out_file);
+   if (strstr (p, "ei8"))
+ return p+7;
+   else
+ return p+8;
+ }
+ }
+
+  if (get_attr_type (current_output_insn) == TYPE_VLSEGDE ||
+   get_attr_type (current_output_insn) == TYPE_VSSEGTE ||
+   get_attr_type (current_output_insn) == TYPE_VLSEGDFF)
+ {
+   get_attr_type (current_output_insn) == TYPE_VSSEGTE
+ ? fputs ("th.vsseg", asm_out_file)
+ : fputs ("th.vlseg", asm_out_file);
+   asm_fprintf (asm_out_file, "%c", p[5]);
+   fputs ("e", asm_out_file);
+   if (strstr (p, "e8"))
+ return p+8;
+   else
+ return p+9;
+ }
+
+  if (get_attr_type (current_output_insn) == TYPE_VLSEGDS ||
+   get_attr_type (current_output_insn) == TYPE_VSSEGTS)
+ {
+   get_attr_type (current_output_insn) == TYPE_VSSEGTS
+ ? fputs ("th.vssseg", asm_out_file)
+ : fputs ("th.vlsseg", asm_out_file);
+   asm_fprintf (asm_out_file, "%c", p[6]);
+   fputs ("e", asm_out_file);
+   if (strstr (p, "e8"))
+ return p+9;
+   else
+ return p+10;
+ }
+
+  if (get_attr_type (current_output_insn) == TYPE_VLSEGDUX ||
+   get_attr_type (current_output_insn) == TYPE_VLSEGDOX)
+ {
+   fputs ("th.vlxseg", asm_out_file);
+ 

Re: [PATCH v6] RISC-V: Fix register overlap issue for some xtheadvector instructions

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

ok.



juzhe.zh...@rivai.ai
 
From: Jun Sha (Joshua)
Date: 2024-01-12 11:23
To: gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw; 
christoph.muellner; juzhe.zhong; Jun Sha (Joshua); Jin Ma; Xianmiao Qu
Subject: [PATCH v6] RISC-V: Fix register overlap issue for some xtheadvector 
instructions
For th.vmadc/th.vmsbc as well as narrowing arithmetic instructions
and floating-point compare instructions, an illegal instruction
exception will be raised if the destination vector register overlaps
a source vector register group.
 
To handle this issue, we add an attribute "spec_restriction" to disable
some alternatives for xtheadvector.
 
gcc/ChangeLog:
 
* config/riscv/riscv.md (none,thv,rvv):
(no,yes): Add an attribute to disable alternative
for xtheadvector or RVV1.0.
* config/riscv/vector.md: 
Disable alternatives that destination register overlaps
source register group for xtheadvector.
 
Co-authored-by: Jin Ma 
Co-authored-by: Xianmiao Qu 
Co-authored-by: Christoph Müllner 
---
gcc/config/riscv/riscv.md  |  22 +++
gcc/config/riscv/vector.md | 314 +
2 files changed, 202 insertions(+), 134 deletions(-)
 
diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index 84212430dc0..23fc32d5cb2 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -579,6 +579,25 @@
 ]
(const_string "yes")))
+;; This attribute marks the alternatives not matching the constraints
+;; described in spec as disabled.
+(define_attr "spec_restriction" "none,thv,rvv"
+  (const_string "none"))
+
+(define_attr "spec_restriction_disabled" "no,yes"
+  (cond [(eq_attr "spec_restriction" "none")
+ (const_string "no")
+
+ (and (eq_attr "spec_restriction" "thv")
+   (match_test "TARGET_XTHEADVECTOR"))
+ (const_string "yes")
+
+ (and (eq_attr "spec_restriction" "rvv")
+   (match_test "TARGET_VECTOR && !TARGET_XTHEADVECTOR"))
+ (const_string "yes")
+ ]
+   (const_string "no")))
+
;; Attribute to control enable or disable instructions.
(define_attr "enabled" "no,yes"
   (cond [
@@ -590,6 +609,9 @@
 (eq_attr "group_overlap_valid" "no")
 (const_string "no")
+
+(eq_attr "spec_restriction_disabled" "yes")
+(const_string "no")
   ]
   (const_string "yes")))
diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
index 3eb6daafbc2..c79416cf0d3 100644
--- a/gcc/config/riscv/vector.md
+++ b/gcc/config/riscv/vector.md
@@ -3260,7 +3260,8 @@
   [(set_attr "type" "vicalu")
(set_attr "mode" "")
(set_attr "vl_op_idx" "4")
-   (set (attr "avl_type_idx") (const_int 5))])
+   (set (attr "avl_type_idx") (const_int 5))
+   (set_attr "spec_restriction" "thv,none,none")])
(define_insn "@pred_msbc"
   [(set (match_operand: 0 "register_operand""=vr, vr, ")
@@ -3279,7 +3280,8 @@
   [(set_attr "type" "vicalu")
(set_attr "mode" "")
(set_attr "vl_op_idx" "4")
-   (set (attr "avl_type_idx") (const_int 5))])
+   (set (attr "avl_type_idx") (const_int 5))
+   (set_attr "spec_restriction" "thv,thv,none")])
(define_insn "@pred_madc_scalar"
   [(set (match_operand: 0 "register_operand" "=vr, ")
@@ -3299,7 +3301,8 @@
   [(set_attr "type" "vicalu")
(set_attr "mode" "")
(set_attr "vl_op_idx" "4")
-   (set (attr "avl_type_idx") (const_int 5))])
+   (set (attr "avl_type_idx") (const_int 5))
+   (set_attr "spec_restriction" "thv,none")])
(define_insn "@pred_msbc_scalar"
   [(set (match_operand: 0 "register_operand" "=vr, ")
@@ -3319,7 +3322,8 @@
   [(set_attr "type" "vicalu")
(set_attr "mode" "")
(set_attr "vl_op_idx" "4")
-   (set (attr "avl_type_idx") (const_int 5))])
+   (set (attr "avl_type_idx") (const_int 5))
+   (set_attr "spec_restriction" "thv,none")])
(define_expand "@pred_madc_scalar"
   [(set (match_operand: 0 "register_operand")
@@ -3368,7 +3372,8 @@
   [(set_attr "type" "vicalu")
(set_attr "mode" "")
(set_attr "vl_op_idx" "4")
-   (set (attr "avl_type_idx") (const_int 5))])
+   (set (attr "avl_type_idx") (const_int 5))
+   (set_attr "spec_restriction" "thv,none")])
(define_insn "*pred_madc_extended_scalar"
   [(set (match_operand: 0 "register_operand" "=vr, ")
@@ -3389,7 +3394,8 @@
   [(set_attr "type" "vicalu")
(set_attr "mode" "")
(set_attr "vl_op_idx" "4")
-   (set (attr "avl_type_idx") (const_int 5))])
+   (set (attr "avl_type_idx") (const_int 5))
+   (set_attr "spec_restriction" "thv,none")])
(define_expand "@pred_msbc_scalar"
   [(set (match_operand: 0 "register_operand")
@@ -3438,7 +3444,8 @@
   [(set_attr "type" "vicalu")
(set_attr "mode" "")
(set_attr "vl_op_idx" "4")
-   (set (attr "avl_type_idx") (const_int 5))])
+   (set (attr "avl_type_idx") (const_int 5))
+   (set_attr "spec_restriction" "thv,none")])
(define_insn "*pred_msbc_extended_scalar"
   [(set (match_operand: 0 "register_operand"  "=vr, ")
@@ -3459,7 +3466,8 @@
   [(set_attr "type" "vicalu")
(set_attr "mode" "")
(set_attr "vl_op_idx" "4")
-   (set 

Re: [PATCH v6] RISC-V: Handle differences between XTheadvector and Vector

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

ok



juzhe.zh...@rivai.ai
 
From: Jun Sha (Joshua)
Date: 2024-01-12 11:22
To: gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw; 
christoph.muellner; juzhe.zhong; Jun Sha (Joshua); Jin Ma; Xianmiao Qu
Subject: [PATCH v6] RISC-V: Handle differences between XTheadvector and Vector
This patch is to handle the differences in instruction generation
between Vector and XTheadVector. In this version, we only support
partial xtheadvector instructions that leverage directly from current
RVV1.0 with simple adding "th." prefix. For different name xtheadvector
instructions but share same patterns as RVV1.0 instructions, we will
use ASM targethook to rewrite the whole string of the instructions in
the following patches. 
 
For some vector patterns that cannot be avoided, we use
"!TARGET_XTHEADVECTOR" to disable them in vector.md in order
not to generate instructions that xtheadvector does not support,
like vmv1r.
 
gcc/ChangeLog:
 
* config.gcc:  Add files for XTheadVector intrinsics.
* config/riscv/autovec.md: Guard XTheadVector.
* config/riscv/predicates.md: Disable immediate vl
for XTheadVector.
* config/riscv/riscv-c.cc (riscv_pragma_intrinsic):
Add pragma for XTheadVector.
* config/riscv/riscv-string.cc (riscv_expand_block_move):
Guard XTheadVector.
* config/riscv/riscv-v.cc (vls_mode_valid_p): 
Avoid autovec.
* config/riscv/riscv-vector-builtins-bases.cc:
Do not normalize vsetvl instructions for XTheadVector.
* config/riscv/riscv-vector-builtins-shapes.cc (check_type):
(build_one): New check type function.
* config/riscv/riscv-vector-switch.def (ENTRY):
Disable fractional mode for the XTheadVector extension.
(TUPLE_ENTRY): Likewise.
* config/riscv/riscv.cc (riscv_v_adjust_bytesize):
Guard XTheadVector.
(riscv_preferred_simd_mode): Likewsie.
(riscv_autovectorize_vector_modes): Likewise.
(riscv_vector_mode_supported_any_target_p): Likewise.
(TARGET_VECTOR_MODE_SUPPORTED_ANY_TARGET_P): Likewise.
* config/riscv/thead.cc (th_asm_output_opcode):
Rewrite vsetvl instructions.
* config/riscv/vector.md: 
Include thead-vector.md and change fractional LMUL
into 1 for vbool.
* config/riscv/riscv_th_vector.h: New file.
* config/riscv/thead-vector.md: New file.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/base/pragma-1.c: Add XTheadVector.
* gcc.target/riscv/rvv/base/abi-1.c: Exclude XTheadVector.
* lib/target-supports.exp: Add target for XTheadVector.
 
Co-authored-by: Jin Ma 
Co-authored-by: Xianmiao Qu 
Co-authored-by: Christoph Müllner 
---
gcc/config.gcc|   2 +-
gcc/config/riscv/autovec.md   |   2 +-
gcc/config/riscv/predicates.md|   4 +-
gcc/config/riscv/riscv-c.cc   |   3 +-
gcc/config/riscv/riscv-string.cc  |   3 +-
gcc/config/riscv/riscv-v.cc   |   2 +-
.../riscv/riscv-vector-builtins-bases.cc  |  48 --
.../riscv/riscv-vector-builtins-shapes.cc |  23 +++
gcc/config/riscv/riscv-vector-switch.def  | 150 +-
gcc/config/riscv/riscv.cc |  20 ++-
gcc/config/riscv/riscv_th_vector.h|  49 ++
gcc/config/riscv/thead-vector.md  | 102 
gcc/config/riscv/thead.cc |  23 ++-
gcc/config/riscv/vector.md|  43 -
.../gcc.target/riscv/rvv/base/abi-1.c |   2 +-
.../gcc.target/riscv/rvv/base/pragma-1.c  |   2 +-
gcc/testsuite/lib/target-supports.exp |  12 ++
17 files changed, 380 insertions(+), 110 deletions(-)
create mode 100644 gcc/config/riscv/riscv_th_vector.h
create mode 100644 gcc/config/riscv/thead-vector.md
 
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 7e583390024..047e4c02cf4 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -549,7 +549,7 @@ riscv*)
extra_objs="${extra_objs} riscv-vector-builtins.o 
riscv-vector-builtins-shapes.o riscv-vector-builtins-bases.o"
extra_objs="${extra_objs} thead.o riscv-target-attr.o"
d_target_objs="riscv-d.o"
- extra_headers="riscv_vector.h"
+ extra_headers="riscv_vector.h riscv_th_vector.h"
target_gtfiles="$target_gtfiles 
\$(srcdir)/config/riscv/riscv-vector-builtins.cc"
target_gtfiles="$target_gtfiles \$(srcdir)/config/riscv/riscv-vector-builtins.h"
;;
diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index 775eaa825b0..0477781cabe 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -2579,7 +2579,7 @@
   [(match_operand  0 "register_operand")
(match_operand  1 "memory_operand")
(match_operand:ANYI 2 "const_int_operand")]
-  "TARGET_VECTOR"
+  "TARGET_VECTOR && !TARGET_XTHEADVECTOR"
   {
 riscv_vector::expand_rawmemchr(mode, operands[0], operands[1],
   operands[2]);
diff --git a/gcc/config/riscv/predicates.md b/gcc/config/riscv/predicates.md
index b1a79cae50a..0337da88284 100644
--- a/gcc/config/riscv/predicates.md
+++ b/gcc/config/riscv/predicates.md
@@ -428,7 +428,9 @@
;; Predicates for the V extension.
(define_special_predicate 

Re: [PATCH v5] RISC-V: Adds the prefix "th." for the instructions of XTheadVector.

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

OK.



juzhe.zh...@rivai.ai
 
From: Jun Sha (Joshua)
Date: 2024-01-12 11:21
To: gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw; 
christoph.muellner; juzhe.zhong; Jun Sha (Joshua); Jin Ma; Xianmiao Qu
Subject: [PATCH v5] RISC-V: Adds the prefix "th." for the instructions of 
XTheadVector.
This patch adds th. prefix to all XTheadVector instructions by
implementing new assembly output functions. We only check the
prefix is 'v', so that no extra attribute is needed.
 
gcc/ChangeLog:
 
* config/riscv/riscv-protos.h (riscv_asm_output_opcode):
Add new function to add assembler insn code prefix/suffix.
(th_asm_output_opcode):
Add Thead function to add assembler insn code prefix/suffix.
* config/riscv/riscv.cc (riscv_asm_output_opcode): 
Implement function to add assembler insn code prefix/suffix.
* config/riscv/riscv.h (ASM_OUTPUT_OPCODE):
Add new function to add assembler insn code prefix/suffix.
* config/riscv/thead.cc (th_asm_output_opcode):
Implement Thead function to add assembler insn code
prefix/suffix.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/xtheadvector/prefix.c: New test.
 
Co-authored-by: Jin Ma 
Co-authored-by: Xianmiao Qu 
Co-authored-by: Christoph Müllner 
---
gcc/config/riscv/riscv-protos.h |  2 ++
gcc/config/riscv/riscv.cc   | 11 +++
gcc/config/riscv/riscv.h|  4 
gcc/config/riscv/thead.cc   | 13 +
.../gcc.target/riscv/rvv/xtheadvector/prefix.c  | 12 
5 files changed, 42 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/prefix.c
 
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 31049ef7523..71724dabdb5 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -102,6 +102,7 @@ struct riscv_address_info {
};
/* Routines implemented in riscv.cc.  */
+extern const char *riscv_asm_output_opcode (FILE *asm_out_file, const char *p);
extern enum riscv_symbol_type riscv_classify_symbolic_expression (rtx);
extern bool riscv_symbolic_constant_p (rtx, enum riscv_symbol_type *);
extern int riscv_float_const_rtx_index_for_fli (rtx);
@@ -717,6 +718,7 @@ extern void th_mempair_prepare_save_restore_operands 
(rtx[4], bool,
  int, HOST_WIDE_INT,
  int, HOST_WIDE_INT);
extern void th_mempair_save_restore_regs (rtx[4], bool, machine_mode);
+extern const char *th_asm_output_opcode (FILE *asm_out_file, const char *p);
#ifdef RTX_CODE
extern const char*
th_mempair_output_move (rtx[4], bool, machine_mode, RTX_CODE);
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 0d1cbc5cb5f..51878797287 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -5636,6 +5636,17 @@ riscv_get_v_regno_alignment (machine_mode mode)
   return lmul;
}
+/* Define ASM_OUTPUT_OPCODE to do anything special before
+   emitting an opcode.  */
+const char *
+riscv_asm_output_opcode (FILE *asm_out_file, const char *p)
+{
+  if (TARGET_XTHEADVECTOR)
+return th_asm_output_opcode (asm_out_file, p);
+
+  return p;
+}
+
/* Implement TARGET_PRINT_OPERAND.  The RISCV-specific operand codes are:
'h' Print the high-part relocation associated with OP, after stripping
diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
index 6df9ec73c5e..c33361a254d 100644
--- a/gcc/config/riscv/riscv.h
+++ b/gcc/config/riscv/riscv.h
@@ -826,6 +826,10 @@ extern enum riscv_cc get_riscv_cc (const rtx use);
   asm_fprintf ((FILE), "%U%s", (NAME)); \
   } while (0)
+#undef ASM_OUTPUT_OPCODE
+#define ASM_OUTPUT_OPCODE(STREAM, PTR) \
+  (PTR) = riscv_asm_output_opcode(STREAM, PTR)
+
#define JUMP_TABLES_IN_TEXT_SECTION 0
#define CASE_VECTOR_MODE SImode
#define CASE_VECTOR_PC_RELATIVE (riscv_cmodel != CM_MEDLOW)
diff --git a/gcc/config/riscv/thead.cc b/gcc/config/riscv/thead.cc
index 20353995931..dc3aed3904d 100644
--- a/gcc/config/riscv/thead.cc
+++ b/gcc/config/riscv/thead.cc
@@ -883,6 +883,19 @@ th_output_move (rtx dest, rtx src)
   return NULL;
}
+/* Define ASM_OUTPUT_OPCODE to do anything special before
+   emitting an opcode.  */
+const char *
+th_asm_output_opcode (FILE *asm_out_file, const char *p)
+{
+  /* We need to add th. prefix to all the xtheadvector
+ instructions here.*/
+  if (current_output_insn != NULL && p[0] == 'v')
+fputs ("th.", asm_out_file);
+
+  return p;
+}
+
/* Implement TARGET_PRINT_OPERAND_ADDRESS for XTheadMemIdx.  */
bool
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/prefix.c 
b/gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/prefix.c
new file mode 100644
index 000..eee727ef6b4
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/prefix.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv32gc_xtheadvector -mabi=ilp32 -O0" } */
+
+#include "riscv_vector.h"
+
+vint32m1_t
+prefix (vint32m1_t vx, vint32m1_t vy, size_t vl)
+{
+  return 

Re: [PATCH v4] RISC-V: Introduce XTheadVector as a subset of V1.0.0

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

This patch needs kito review. I can't approve that.



juzhe.zh...@rivai.ai
 
From: Jun Sha (Joshua)
Date: 2024-01-12 11:20
To: gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw; 
christoph.muellner; juzhe.zhong; kito.cheng; Jun Sha (Joshua); Jin Ma; Xianmiao 
Qu
Subject: [PATCH v4] RISC-V: Introduce XTheadVector as a subset of V1.0.0
This patch is to introduce basic XTheadVector support
(march string parsing and a test for __riscv_xtheadvector)
according to https://github.com/T-head-Semi/thead-extension-spec/
 
gcc/ChangeLog:
 
* common/config/riscv/riscv-common.cc
(riscv_subset_list::parse): Add new vendor extension.
* config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins):
Add test marco.
* config/riscv/riscv.opt:  Add new mask.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/predef-__riscv_th_v_intrinsic.c: New test.
* gcc.target/riscv/rvv/xtheadvector.c: New test.
 
Co-authored-by: Jin Ma 
Co-authored-by: Xianmiao Qu 
Co-authored-by: Christoph Müllner 
---
gcc/common/config/riscv/riscv-common.cc   | 23 +++
gcc/config/riscv/riscv-c.cc   |  8 +--
gcc/config/riscv/riscv.opt|  2 ++
.../riscv/predef-__riscv_th_v_intrinsic.c | 11 +
.../gcc.target/riscv/rvv/xtheadvector.c   | 13 +++
5 files changed, 55 insertions(+), 2 deletions(-)
create mode 100644 
gcc/testsuite/gcc.target/riscv/predef-__riscv_th_v_intrinsic.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector.c
 
diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index 0301d170a41..449722070d4 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -368,6 +368,7 @@ static const struct riscv_ext_version 
riscv_ext_version_table[] =
   {"xtheadmemidx", ISA_SPEC_CLASS_NONE, 1, 0},
   {"xtheadmempair", ISA_SPEC_CLASS_NONE, 1, 0},
   {"xtheadsync", ISA_SPEC_CLASS_NONE, 1, 0},
+  {"xtheadvector", ISA_SPEC_CLASS_NONE, 1, 0},
   {"xventanacondops", ISA_SPEC_CLASS_NONE, 1, 0},
@@ -1251,6 +1252,15 @@ riscv_subset_list::check_conflict_ext ()
   if (lookup ("zcmp"))
error_at (m_loc, "%<-march=%s%>: zcd conflicts with zcmp", m_arch);
 }
+
+  if ((lookup ("v") || lookup ("zve32x")
+ || lookup ("zve64x") || lookup ("zve32f")
+ || lookup ("zve64f") || lookup ("zve64d")
+ || lookup ("zvl32b") || lookup ("zvl64b")
+ || lookup ("zvl128b") || lookup ("zvfh"))
+ && lookup ("xtheadvector"))
+error_at (m_loc, "%<-march=%s%>: xtheadvector conflicts with vector "
+"extension or its sub-extensions", m_arch);
}
/* Parsing function for multi-letter extensions.
@@ -1743,6 +1753,19 @@ static const riscv_ext_flag_table_t 
riscv_ext_flag_table[] =
   {"xtheadmemidx",  _options::x_riscv_xthead_subext, MASK_XTHEADMEMIDX},
   {"xtheadmempair", _options::x_riscv_xthead_subext, MASK_XTHEADMEMPAIR},
   {"xtheadsync",_options::x_riscv_xthead_subext, MASK_XTHEADSYNC},
+  {"xtheadvector",  _options::x_riscv_xthead_subext, MASK_XTHEADVECTOR},
+  {"xtheadvector",  _options::x_riscv_vector_elen_flags, 
MASK_VECTOR_ELEN_32},
+  {"xtheadvector",  _options::x_riscv_vector_elen_flags, 
MASK_VECTOR_ELEN_64},
+  {"xtheadvector",  _options::x_riscv_vector_elen_flags, 
MASK_VECTOR_ELEN_FP_32},
+  {"xtheadvector",  _options::x_riscv_vector_elen_flags, 
MASK_VECTOR_ELEN_FP_64},
+  {"xtheadvector",  _options::x_riscv_vector_elen_flags, 
MASK_VECTOR_ELEN_FP_16},
+  {"xtheadvector",  _options::x_riscv_zvl_flags, MASK_ZVL32B},
+  {"xtheadvector",  _options::x_riscv_zvl_flags, MASK_ZVL64B},
+  {"xtheadvector",  _options::x_riscv_zvl_flags, MASK_ZVL128B},
+  {"xtheadvector",  _options::x_riscv_zf_subext, MASK_ZVFHMIN},
+  {"xtheadvector",  _options::x_riscv_zf_subext, MASK_ZVFH},
+  {"xtheadvector",  _options::x_target_flags, MASK_FULL_V},
+  {"xtheadvector",  _options::x_target_flags, MASK_VECTOR},
   {"xventanacondops", _options::x_riscv_xventana_subext, 
MASK_XVENTANACONDOPS},
diff --git a/gcc/config/riscv/riscv-c.cc b/gcc/config/riscv/riscv-c.cc
index ba60cd8b555..422ddc2c308 100644
--- a/gcc/config/riscv/riscv-c.cc
+++ b/gcc/config/riscv/riscv-c.cc
@@ -142,6 +142,10 @@ riscv_cpu_cpp_builtins (cpp_reader *pfile)
 riscv_ext_version_value (0, 11));
 }
+   if (TARGET_XTHEADVECTOR)
+ builtin_define_with_int_value ("__riscv_th_v_intrinsic",
+  riscv_ext_version_value (0, 11));
+
   /* Define architecture extension test macros.  */
   builtin_define_with_int_value ("__riscv_arch_test", 1);
@@ -195,8 +199,8 @@ riscv_pragma_intrinsic (cpp_reader *)
 {
   if (!TARGET_VECTOR)
{
-   error ("%<#pragma riscv intrinsic%> option %qs needs 'V' extension "
- "enabled",
+   error ("%<#pragma riscv intrinsic%> option %qs needs 'V' or "
+ "'XTHEADVECTOR' extension enabled",
name);
  return;
}
diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
index 44ed6d69da2..bb18a22b693 100644
--- a/gcc/config/riscv/riscv.opt
+++ b/gcc/config/riscv/riscv.opt
@@ -452,6 

Re: [PATCH] libstdc++: Fix std::runtime_format deviations from the spec [PR113320]

[Daniel Krügler]

Am Do., 11. Jan. 2024 um 21:23 Uhr schrieb Jonathan Wakely :
>
> Tested x86_64-linux. Does this look better now?

Yes, thank you.

- Daniel

[PATCH, rs6000] Enable block compare expand on P9 with m32 and mpowerpc64

[HAO CHEN GUI]

Hi,
  On P9 "setb" is used to set the result of block compare. So it works
with m32 and mpowerpc64. On P8, carry bit is used. So it can't work
with m32 and mpowerpc64. This patch enables block compare expand for
m32 and mpowerpc64 on P9.

  Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no
regressions. Is this OK for trunk?

Thanks
Gui Haochen


ChangeLog
rs6000: Enable block compare expand on P9 with m32 and mpowerpc64

gcc/
* config/rs6000/rs6000-string.cc (expand_block_compare): Enable
P9 with m32 and mpowerpc64.

gcc/testsuite/
* gcc.target/powerpc/block-cmp-1.c: Exclude m32 and mpowerpc64.
* gcc.target/powerpc/block-cmp-4.c: Likewise.
* gcc.target/powerpc/block-cmp-8.c: New.

patch.diff
diff --git a/gcc/config/rs6000/rs6000-string.cc 
b/gcc/config/rs6000/rs6000-string.cc
index 018b87f2501..346708071b5 100644
--- a/gcc/config/rs6000/rs6000-string.cc
+++ b/gcc/config/rs6000/rs6000-string.cc
@@ -1677,11 +1677,12 @@ expand_block_compare (rtx operands[])
   /* TARGET_POPCNTD is already guarded at expand cmpmemsi.  */
   gcc_assert (TARGET_POPCNTD);

-  /* This case is complicated to handle because the subtract
- with carry instructions do not generate the 64-bit
- carry and so we must emit code to calculate it ourselves.
- We choose not to implement this yet.  */
-  if (TARGET_32BIT && TARGET_POWERPC64)
+  /* For P8, this case is complicated to handle because the subtract
+ with carry instructions do not generate the 64-bit carry and so
+ we must emit code to calculate it ourselves.  We skip it on P8
+ but setb works well on P9.  */
+  if (TARGET_32BIT && TARGET_POWERPC64
+  && !TARGET_P9_MISC)
 return false;

   /* Allow this param to shut off all expansion.  */
diff --git a/gcc/testsuite/gcc.target/powerpc/block-cmp-1.c 
b/gcc/testsuite/gcc.target/powerpc/block-cmp-1.c
index bcf0cb2ab4f..cd076cf1dce 100644
--- a/gcc/testsuite/gcc.target/powerpc/block-cmp-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/block-cmp-1.c
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -mdejagnu-cpu=power8 -mno-vsx" } */
+/* { dg-skip-if "" { has_arch_ppc64 && ilp32 } } */
 /* { dg-final { scan-assembler-not {\mb[l]? memcmp\M} } }  */

 /* Test that it still can do expand for memcmpsi instead of calling library
diff --git a/gcc/testsuite/gcc.target/powerpc/block-cmp-4.c 
b/gcc/testsuite/gcc.target/powerpc/block-cmp-4.c
index c86febae68a..9373b53a3a4 100644
--- a/gcc/testsuite/gcc.target/powerpc/block-cmp-4.c
+++ b/gcc/testsuite/gcc.target/powerpc/block-cmp-4.c
@@ -1,5 +1,6 @@
 /* { dg-do compile { target be } } */
 /* { dg-options "-O2 -mdejagnu-cpu=power7" } */
+/* { dg-skip-if "" { has_arch_ppc64 && ilp32 } } */
 /* { dg-final { scan-assembler-not {\mb[l]? memcmp\M} } }  */

 /* Test that it does expand for memcmpsi instead of calling library on
diff --git a/gcc/testsuite/gcc.target/powerpc/block-cmp-8.c 
b/gcc/testsuite/gcc.target/powerpc/block-cmp-8.c
new file mode 100644
index 000..b470f873973
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/block-cmp-8.c
@@ -0,0 +1,8 @@
+/* { dg-do run { target ilp32 } } */
+/* { dg-options "-O2 -m32 -mpowerpc64" } */
+/* { dg-require-effective-target has_arch_ppc64 } */
+/* { dg-timeout-factor 2 } */
+
+/* Verify memcmp on m32 mpowerpc64 */
+
+#include "../../gcc.dg/memcmp-1.c"

Re: [PATCH] Do not count unused scalar use when marking STMT_VINFO_LIVE_P [PR113091]

[Feng Xue OS]

Add a depth parameter to limit recursion of vec_slp_has_scalar_use.

Feng
---

 .../gcc.target/aarch64/bb-slp-pr113091.c  |  22 ++
 gcc/tree-vect-slp.cc  | 207 ++
 2 files changed, 190 insertions(+), 39 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/bb-slp-pr113091.c

diff --git a/gcc/testsuite/gcc.target/aarch64/bb-slp-pr113091.c 
b/gcc/testsuite/gcc.target/aarch64/bb-slp-pr113091.c
new file mode 100644
index 000..ff822e90b4a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/bb-slp-pr113091.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-O3 -fdump-tree-slp-details -ftree-slp-vectorize" 
} */
+
+int test(unsigned array[8]);
+
+int foo(char *a, char *b)
+{
+  unsigned array[8];
+
+  array[0] = (a[0] - b[0]);
+  array[1] = (a[1] - b[1]);
+  array[2] = (a[2] - b[2]);
+  array[3] = (a[3] - b[3]);
+  array[4] = (a[4] - b[4]);
+  array[5] = (a[5] - b[5]);
+  array[6] = (a[6] - b[6]);
+  array[7] = (a[7] - b[7]);
+
+  return test(array);
+}
+
+/* { dg-final { scan-tree-dump-times "Basic block will be vectorized using 
SLP" 1 "slp2" } } */
diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index b6cce55ce90..086377a9ac0 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -6418,6 +6418,102 @@ vect_slp_analyze_node_operations (vec_info *vinfo, 
slp_tree node,
   return res;
 }

+/* Given a definition DEF, analyze if it will have any live scalar use after
+   performing SLP vectorization whose information is represented by BB_VINFO,
+   and record result into hash map SCALAR_USE_MAP as cache for later fast
+   check.  If recursion DEPTH exceeds a limit, stop analysis and make a
+   conservative assumption.  Return 0 if no scalar use, 1 if there is, -1
+   means recursion is limited.  */
+
+static int
+vec_slp_has_scalar_use (bb_vec_info bb_vinfo, tree def,
+   hash_map _use_map,
+   int depth = 0)
+{
+  const int depth_limit = 2;
+  imm_use_iterator use_iter;
+  gimple *use_stmt;
+
+  if (int *res = scalar_use_map.get (def))
+return *res;
+
+  int scalar_use = 1;
+
+  FOR_EACH_IMM_USE_STMT (use_stmt, use_iter, def)
+{
+  if (is_gimple_debug (use_stmt))
+   continue;
+
+  stmt_vec_info use_stmt_info = bb_vinfo->lookup_stmt (use_stmt);
+
+  if (!use_stmt_info)
+   break;
+
+  if (PURE_SLP_STMT (vect_stmt_to_vectorize (use_stmt_info)))
+   continue;
+
+  /* Do not step forward when encounter PHI statement, since it may
+involve cyclic reference and cause infinite recursive invocation.  */
+  if (gimple_code (use_stmt) == GIMPLE_PHI)
+   break;
+
+  /* When pattern recognition is involved, a statement whose definition is
+consumed in some pattern, may not be included in the final replacement
+pattern statements, so would be skipped when building SLP graph.
+
+* Original
+ char a_c = *(char *) a;
+ char b_c = *(char *) b;
+ unsigned short a_s = (unsigned short) a_c;
+ int a_i = (int) a_s;
+ int b_i = (int) b_c;
+ int r_i = a_i - b_i;
+
+* After pattern replacement
+ a_s = (unsigned short) a_c;
+ a_i = (int) a_s;
+
+ patt_b_s = (unsigned short) b_c;// b_i = (int) b_c
+ patt_b_i = (int) patt_b_s;  // b_i = (int) b_c
+
+ patt_r_s = widen_minus(a_c, b_c);   // r_i = a_i - b_i
+ patt_r_i = (int) patt_r_s;  // r_i = a_i - b_i
+
+The definitions of a_i(original statement) and b_i(pattern statement)
+are related to, but actually not part of widen_minus pattern.
+Vectorizing the pattern does not cause these definition statements to
+be marked as PURE_SLP.  For this case, we need to recursively check
+whether their uses are all absorbed into vectorized code.  But there
+is an exception that some use may participate in an vectorized
+operation via an external SLP node containing that use as an element.
+The parameter "scalar_use_map" tags such kind of SSA as having scalar
+use in advance.  */
+  tree lhs = gimple_get_lhs (use_stmt);
+
+  if (!lhs || TREE_CODE (lhs) != SSA_NAME)
+   break;
+
+  if (depth_limit && depth >= depth_limit)
+   return -1;
+
+  if ((scalar_use = vec_slp_has_scalar_use (bb_vinfo, lhs, scalar_use_map,
+   depth + 1)))
+   break;
+}
+
+  if (end_imm_use_stmt_p (_iter))
+scalar_use = 0;
+
+  /* If recursion is limited, do not cache result for non-root defs.  */
+  if (!depth || scalar_use >= 0)
+{
+  bool added = scalar_use_map.put (def, scalar_use);
+  gcc_assert (!added);
+}
+
+  return scalar_use;
+}
+
 /* Mark lanes of NODE that are live outside of the basic-block vectorized
region and that can be vectorized using vectorizable_live_operation
with STMT_VINFO_LIVE_P.  Not 

Re: [PATCH] Document refactoring of the option -fcf-protection=x.

[Gerald Pfeifer]

On Wed, 10 Jan 2024, liuhongt wrote:
> To override -fcf-protection, -fcf-protection=none needs to be added
> and then with -fcf-protection=xxx.

I'm afraid I am struggling with the English of this, but need more time to 
untangle and suggest an alternative.

For the time being I pushed the follow-up below. Note that it's
  -fcf-protection
not
  -fcf-protection
i.e.,  closes .

Gerald


commit f834612fa014a65bd0a0380d2167d9ee05626a64
Author: Gerald Pfeifer 
Date:   Fri Jan 12 13:54:52 2024 +0800

gcc-14: Fix markup around -fcf-protection

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index ba57abe8..9c9dfa44 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -41,9 +41,9 @@ a work-in-progress.
   identify all such cases in the source code and modify them.
   
   https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html;>-fcf-protection=[full|branch|return|none|check]
-  is refactored, to override -fcf-protection,
-  -fcf-protection=none needs to be added and then
-  with -fcf-protection=xxx.
+  is refactored, to override -fcf-protection,
+  -fcf-protection=none needs to be added and then
+  with -fcf-protection=xxx.
   
 
 

[r14-7158 Regression] FAIL: gcc.dg/gomp/bad-array-section-c-3.c at line 14 (test for warnings, line 12) on Linux/x86_64

[haochen.jiang]

On Linux/x86_64,

b5476e4c881b0d2bfbbfb84ee38d791123acf8e1 is the first bad commit
commit b5476e4c881b0d2bfbbfb84ee38d791123acf8e1
Author: Julian Brown 
Date:   Mon Nov 15 02:23:49 2021 -0800

OpenMP: lvalue parsing for map/to/from clauses (C)

caused

FAIL: gcc.dg/gomp/bad-array-section-c-3.c  at line 14 (test for warnings, line 
12)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-7158/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="gomp.exp=gcc.dg/gomp/bad-array-section-c-3.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=gcc.dg/gomp/bad-array-section-c-3.c 
--target_board='unix{-m32\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at haochen dot jiang at intel.com.)
(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.)

[Committed] libgcc, nios2: Fix exception handling on nios2 with -fpic

[Sandra Loosemore]

Exception handling on nios2-linux-gnu with -fpic has been broken since
revision 790854ea7670f11c14d431c102a49181d2915965, "Use _dl_find_object
in _Unwind_Find_FDE".  For whatever reason, this doesn't work on nios2.

Nios2 uses the GOT address as the base for DW_EH_PE_datarel
relocations in PIC; see my previous fix to make this work, revision
2d33dcfe9f0494c9b56a8d704c3d27c5a4329ebc, "Support for GOT-relative
DW_EH_PE_datarel encoding".  So this may be a horrible bug in the ABI
or in my interpretation of it or just glibc's implementation of
_dl_find_object for this target, but there's existing code out there
that does things this way; and realistically, nobody is going to
re-engineer this now that the vendor has EOL'ed the nios2
architecture.  So, just skip over the code trying to use
_dl_find_object on this target and fall back to the way that works.

I plan to backport this patch to the GCC 12 and GCC 13 branches as well.

libgcc/ChangeLog
* unwind-dw2-fde-dip.c (_Unwind_Find_FDE): Do not try to use
_dl_find_object on nios2; it doesn't work.
---
 libgcc/unwind-dw2-fde-dip.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libgcc/unwind-dw2-fde-dip.c b/libgcc/unwind-dw2-fde-dip.c
index 2f2ca35d549..57d0c8812b1 100644
--- a/libgcc/unwind-dw2-fde-dip.c
+++ b/libgcc/unwind-dw2-fde-dip.c
@@ -543,8 +543,9 @@ _Unwind_Find_FDE (void *pc, struct dwarf_eh_bases *bases)
 return ret;
 
   /* Use DLFO_STRUCT_HAS_EH_DBASE as a proxy for the existence of a glibc-style
- _dl_find_object function.  */
-#ifdef DLFO_STRUCT_HAS_EH_DBASE
+ _dl_find_object function.  However, do not use _dl_find_object on nios2,
+ which uses the GOT address as the base for DW_EH_PE_datarel instead.  */
+#if defined(DLFO_STRUCT_HAS_EH_DBASE) && !defined(__nios2__)
   {
 struct dl_find_object dlfo;
 if (_dl_find_object (pc, ) == 0 && dlfo.dlfo_eh_frame != NULL)
-- 
2.31.1

Re: [patch,avr,applied] PR target/112952 Fix attribute "io" et al. handling.

[Jan-Benedict Glaw]

On Thu, 2024-01-04 17:28:02 +0100, Georg-Johann Lay  wrote:
> This fixes the avr-specific attributes io, io_low and address,
> that are all basically the same except that io and io_low imply
> assertions on allowed addressing modes.

> --- a/gcc/config/avr/avr.cc
> +++ b/gcc/config/avr/avr.cc
[...]
> @@ -10385,12 +10389,10 @@ avr_handle_addr_attribute (tree *node, tree name, 
> tree args,
>   }
>else if (io_p
>  && (!tree_fits_shwi_p (arg)
> -|| !(strcmp (IDENTIFIER_POINTER (name), "io_low") == 0
> - ? low_io_address_operand : io_address_operand)
> -  (GEN_INT (TREE_INT_CST_LOW (arg)), QImode)))
> +|| ! IN_RANGE (TREE_INT_CST_LOW (arg), io_start, io_end)))
>   {
> -   warning_at (loc, OPT_Wattributes, "%qE attribute address "
> -   "out of range", name);
> +   warning_at (loc, OPT_Wattributes, "%qE attribute address out of "
> +   "range 0x%x...0x%x", name, (int) io_start, (int) io_end);
> *no_add = true;
>   }
>else

Building with a recent GCC, this results in a new warning (here forced
to an error with --enable-werror-alway--enable-werror-always):

/var/lib/laminar/run/gcc-avr-elf/64/local-toolchain-install/bin/g++  -fno-PIE 
-c   -g -O2   -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Wconditionally-supported 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -fno-PIE -I. -I. 
-I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include  
-I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody  
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd 
-I../libdecnumber -I../../gcc/gcc/../libbacktrace   -o avr.o -MT avr.o -MMD -MP 
-MF ./.deps/avr.TPo ../../gcc/gcc/config/avr/avr.cc
../../gcc/gcc/config/avr/avr.cc: In function 'tree_node* 
avr_handle_addr_attribute(tree_node**, tree, tree, int, bool*)':
../../gcc/gcc/config/avr/avr.cc:10391:45: error: unquoted sequence of 3 
consecutive punctuation characters '...' in format [-Werror=format-diag]
10391 |   warning_at (loc, OPT_Wattributes, "%qE attribute address out 
of "
  | 
^~~
10392 |   "range 0x%x...0x%x", name, (int) io_start, (int) 
io_end);
  |   ~~~
cc1plus: all warnings being treated as errors
make[1]: *** [Makefile:2554: avr.o] Error 1
make[1]: Leaving directory 
'/var/lib/laminar/run/gcc-avr-elf/64/toolchain-build/gcc'
make: *** [Makefile:4676: all-gcc] Error 2


I think this should be "%<...%>".

MfG, JBG

-- 


signature.asc
Description: PGP signature

[PATCH v5] RISC-V: Rewrite some instructions using ASM targethook

[Jun Sha (Joshua)]

There are some xtheadvector instructions that differ from RVV1.0
apart from simply adding "th." prefix. For example, RVV1.0
load/store instructions will have SEW while xtheadvector not;
RVV1.0 will have "o" for indexed-ordered store instructions while
xtheadvecotr not; xtheadvector and RVV1.0 have different
vnsrl/vnsra/vfncvt suffix (vv/vx/vi vs wv/wx/wi).

To address this issue without duplicating patterns, we use ASM
targethook to rewrite the whole string of the instructions. We
identify different instructions from the corresponding attribute.

gcc/ChangeLog:

* config/riscv/thead.cc
(th_asm_output_opcode): Rewrite some instructions.

Co-authored-by: Jin Ma 
Co-authored-by: Xianmiao Qu 
Co-authored-by: Christoph Müllner 
---
 gcc/config/riscv/thead.cc | 215 +-
 1 file changed, 213 insertions(+), 2 deletions(-)

diff --git a/gcc/config/riscv/thead.cc b/gcc/config/riscv/thead.cc
index dc3aed3904d..fb088ebff02 100644
--- a/gcc/config/riscv/thead.cc
+++ b/gcc/config/riscv/thead.cc
@@ -27,6 +27,7 @@
 #include "backend.h"
 #include "tree.h"
 #include "rtl.h"
+#include "insn-attr.h"
 #include "explow.h"
 #include "memmodel.h"
 #include "emit-rtl.h"
@@ -890,8 +891,218 @@ th_asm_output_opcode (FILE *asm_out_file, const char *p)
 {
   /* We need to add th. prefix to all the xtheadvector
  instructions here.*/
-  if (current_output_insn != NULL && p[0] == 'v')
-fputs ("th.", asm_out_file);
+  if (current_output_insn != NULL)
+{
+  if (get_attr_type (current_output_insn) == TYPE_VLDE ||
+ get_attr_type (current_output_insn) == TYPE_VSTE ||
+ get_attr_type (current_output_insn) == TYPE_VLDFF)
+   {
+ if (strstr (p, "e8") || strstr (p, "e16") ||
+ strstr (p, "e32") || strstr (p, "e64"))
+   {
+ get_attr_type (current_output_insn) == TYPE_VSTE
+ ? fputs ("th.vse", asm_out_file)
+ : fputs ("th.vle", asm_out_file);
+ if (strstr (p, "e8"))
+   return p+4;
+ else
+   return p+5;
+   }
+   }
+
+  if (get_attr_type (current_output_insn) == TYPE_VLDS ||
+ get_attr_type (current_output_insn) == TYPE_VSTS)
+   {
+ if (strstr (p, "vle8") || strstr (p, "vse8") ||
+ strstr (p, "vle16") || strstr (p, "vse16") ||
+ strstr (p, "vle32") || strstr (p, "vse32") ||
+ strstr (p, "vle64") || strstr (p, "vse64"))
+   {
+ get_attr_type (current_output_insn) == TYPE_VSTS
+ ? fputs ("th.vse", asm_out_file)
+ : fputs ("th.vle", asm_out_file);
+ if (strstr (p, "e8"))
+   return p+4;
+ else
+   return p+5;
+   }
+ else if (strstr (p, "vlse8") || strstr (p, "vsse8") ||
+  strstr (p, "vlse16") || strstr (p, "vsse16") ||
+  strstr (p, "vlse32") || strstr (p, "vsse32") ||
+  strstr (p, "vlse64") || strstr (p, "vsse64"))
+   {
+ get_attr_type (current_output_insn) == TYPE_VSTS
+ ? fputs ("th.vsse", asm_out_file)
+ : fputs ("th.vlse", asm_out_file);
+ if (strstr (p, "e8"))
+   return p+5;
+ else
+   return p+6;
+   }
+   }
+
+  if (get_attr_type (current_output_insn) == TYPE_VLDUX ||
+ get_attr_type (current_output_insn) == TYPE_VLDOX)
+   {
+ if (strstr (p, "ei"))
+   {
+ fputs ("th.vlxe", asm_out_file);
+ if (strstr (p, "ei8"))
+   return p+7;
+ else
+   return p+8;
+   }
+   }
+
+  if (get_attr_type (current_output_insn) == TYPE_VSTUX ||
+ get_attr_type (current_output_insn) == TYPE_VSTOX)
+   {
+ if (strstr (p, "ei"))
+   {
+ get_attr_type (current_output_insn) == TYPE_VSTUX
+   ? fputs ("th.vsuxe", asm_out_file)
+   : fputs ("th.vsxe", asm_out_file);
+ if (strstr (p, "ei8"))
+   return p+7;
+ else
+   return p+8;
+   }
+   }
+
+  if (get_attr_type (current_output_insn) == TYPE_VLSEGDE ||
+ get_attr_type (current_output_insn) == TYPE_VSSEGTE ||
+ get_attr_type (current_output_insn) == TYPE_VLSEGDFF)
+   {
+ get_attr_type (current_output_insn) == TYPE_VSSEGTE
+   ? fputs ("th.vsseg", asm_out_file)
+   : fputs ("th.vlseg", asm_out_file);
+ asm_fprintf (asm_out_file, "%c", p[5]);
+ fputs ("e", asm_out_file);
+ if (strstr (p, "e8"))
+   return p+8;
+ else
+   return p+9;
+   }
+
+  if (get_attr_type 

[PATCH v6] RISC-V: Fix register overlap issue for some xtheadvector instructions

[Jun Sha (Joshua)]

For th.vmadc/th.vmsbc as well as narrowing arithmetic instructions
and floating-point compare instructions, an illegal instruction
exception will be raised if the destination vector register overlaps
a source vector register group.

To handle this issue, we add an attribute "spec_restriction" to disable
some alternatives for xtheadvector.

gcc/ChangeLog:

* config/riscv/riscv.md (none,thv,rvv):
(no,yes): Add an attribute to disable alternative
for xtheadvector or RVV1.0.
* config/riscv/vector.md: 
Disable alternatives that destination register overlaps
source register group for xtheadvector.

Co-authored-by: Jin Ma 
Co-authored-by: Xianmiao Qu 
Co-authored-by: Christoph Müllner 
---
 gcc/config/riscv/riscv.md  |  22 +++
 gcc/config/riscv/vector.md | 314 +
 2 files changed, 202 insertions(+), 134 deletions(-)

diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index 84212430dc0..23fc32d5cb2 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -579,6 +579,25 @@
 ]
(const_string "yes")))
 
+;; This attribute marks the alternatives not matching the constraints
+;; described in spec as disabled.
+(define_attr "spec_restriction" "none,thv,rvv"
+  (const_string "none"))
+
+(define_attr "spec_restriction_disabled" "no,yes"
+  (cond [(eq_attr "spec_restriction" "none")
+(const_string "no")
+
+(and (eq_attr "spec_restriction" "thv")
+ (match_test "TARGET_XTHEADVECTOR"))
+(const_string "yes")
+
+(and (eq_attr "spec_restriction" "rvv")
+ (match_test "TARGET_VECTOR && !TARGET_XTHEADVECTOR"))
+(const_string "yes")
+   ]
+   (const_string "no")))
+
 ;; Attribute to control enable or disable instructions.
 (define_attr "enabled" "no,yes"
   (cond [
@@ -590,6 +609,9 @@
 
 (eq_attr "group_overlap_valid" "no")
 (const_string "no")
+
+(eq_attr "spec_restriction_disabled" "yes")
+(const_string "no")
   ]
   (const_string "yes")))
 
diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
index 3eb6daafbc2..c79416cf0d3 100644
--- a/gcc/config/riscv/vector.md
+++ b/gcc/config/riscv/vector.md
@@ -3260,7 +3260,8 @@
   [(set_attr "type" "vicalu")
(set_attr "mode" "")
(set_attr "vl_op_idx" "4")
-   (set (attr "avl_type_idx") (const_int 5))])
+   (set (attr "avl_type_idx") (const_int 5))
+   (set_attr "spec_restriction" "thv,none,none")])
 
 (define_insn "@pred_msbc"
   [(set (match_operand: 0 "register_operand""=vr, vr, ")
@@ -3279,7 +3280,8 @@
   [(set_attr "type" "vicalu")
(set_attr "mode" "")
(set_attr "vl_op_idx" "4")
-   (set (attr "avl_type_idx") (const_int 5))])
+   (set (attr "avl_type_idx") (const_int 5))
+   (set_attr "spec_restriction" "thv,thv,none")])
 
 (define_insn "@pred_madc_scalar"
   [(set (match_operand: 0 "register_operand" "=vr, ")
@@ -3299,7 +3301,8 @@
   [(set_attr "type" "vicalu")
(set_attr "mode" "")
(set_attr "vl_op_idx" "4")
-   (set (attr "avl_type_idx") (const_int 5))])
+   (set (attr "avl_type_idx") (const_int 5))
+   (set_attr "spec_restriction" "thv,none")])
 
 (define_insn "@pred_msbc_scalar"
   [(set (match_operand: 0 "register_operand" "=vr, ")
@@ -3319,7 +3322,8 @@
   [(set_attr "type" "vicalu")
(set_attr "mode" "")
(set_attr "vl_op_idx" "4")
-   (set (attr "avl_type_idx") (const_int 5))])
+   (set (attr "avl_type_idx") (const_int 5))
+   (set_attr "spec_restriction" "thv,none")])
 
 (define_expand "@pred_madc_scalar"
   [(set (match_operand: 0 "register_operand")
@@ -3368,7 +3372,8 @@
   [(set_attr "type" "vicalu")
(set_attr "mode" "")
(set_attr "vl_op_idx" "4")
-   (set (attr "avl_type_idx") (const_int 5))])
+   (set (attr "avl_type_idx") (const_int 5))
+   (set_attr "spec_restriction" "thv,none")])
 
 (define_insn "*pred_madc_extended_scalar"
   [(set (match_operand: 0 "register_operand" "=vr, ")
@@ -3389,7 +3394,8 @@
   [(set_attr "type" "vicalu")
(set_attr "mode" "")
(set_attr "vl_op_idx" "4")
-   (set (attr "avl_type_idx") (const_int 5))])
+   (set (attr "avl_type_idx") (const_int 5))
+   (set_attr "spec_restriction" "thv,none")])
 
 (define_expand "@pred_msbc_scalar"
   [(set (match_operand: 0 "register_operand")
@@ -3438,7 +3444,8 @@
   [(set_attr "type" "vicalu")
(set_attr "mode" "")
(set_attr "vl_op_idx" "4")
-   (set (attr "avl_type_idx") (const_int 5))])
+   (set (attr "avl_type_idx") (const_int 5))
+   (set_attr "spec_restriction" "thv,none")])
 
 (define_insn "*pred_msbc_extended_scalar"
   [(set (match_operand: 0 "register_operand"  "=vr, ")
@@ -3459,7 +3466,8 @@
   [(set_attr "type" "vicalu")
(set_attr "mode" "")
(set_attr "vl_op_idx" "4")
-   (set (attr "avl_type_idx") (const_int 5))])
+   (set (attr "avl_type_idx") (const_int 5))
+   (set_attr "spec_restriction" "thv,none")])
 
 (define_insn "@pred_madc_overflow"
   [(set 

[PATCH v6] RISC-V: Add support for xtheadvector-specific intrinsics.

[Jun Sha (Joshua)]

This patch only involves the generation of xtheadvector
special load/store instructions and vext instructions.

gcc/ChangeLog:

* config/riscv/riscv-vector-builtins-bases.cc
(class th_loadstore_width): Define new builtin bases.
(class th_extract): Define new builtin bases.
(BASE): Define new builtin bases.
* config/riscv/riscv-vector-builtins-bases.h:
Define new builtin class.
* config/riscv/riscv-vector-builtins-shapes.cc
(struct th_loadstore_width_def): Define new builtin shapes.
(struct th_indexed_loadstore_width_def):
Define new builtin shapes.
(struct th_extract_def): Define new builtin shapes.
(SHAPE): Define new builtin shapes.
* config/riscv/riscv-vector-builtins-shapes.h:
Define new builtin shapes.
* config/riscv/riscv-vector-builtins.cc (DEF_RVV_FUNCTION):
Redefine DEF_RVV_FUNCTION for XTheadVector special intrinsics.
* config/riscv/riscv-vector-builtins.h 
(enum required_ext): Add new XTheadVector member.
(struct function_group_info): Likewise.
* config/riscv/t-riscv: 
Add thead-vector-builtins-functions.def
* config/riscv/thead-vector.md
(@pred_mov_width): Add new patterns.
(*pred_mov_width): Likewise.
(@pred_store_width): Likewise.
(@pred_strided_load_width): Likewise.
(@pred_strided_store_width): Likewise.
(@pred_indexed_load_width): Likewise.
(@pred_th_extract): Likewise.
(*pred_th_extract): Likewise.
* config/riscv/thead-vector-builtins-functions.def: New file.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/xtheadvector/vlb-vsb.c: New test.
* gcc.target/riscv/rvv/xtheadvector/vlbu-vsb.c: New test.
* gcc.target/riscv/rvv/xtheadvector/vlh-vsh.c: New test.
* gcc.target/riscv/rvv/xtheadvector/vlhu-vsh.c: New test.
* gcc.target/riscv/rvv/xtheadvector/vlw-vsw.c: New test.
* gcc.target/riscv/rvv/xtheadvector/vlwu-vsw.c: New test.

Co-authored-by: Jin Ma 
Co-authored-by: Xianmiao Qu 
Co-authored-by: Christoph Müllner 
---
 .../riscv/riscv-vector-builtins-bases.cc  | 139 ++
 .../riscv/riscv-vector-builtins-bases.h   |  31 +++
 .../riscv/riscv-vector-builtins-shapes.cc | 160 +++
 .../riscv/riscv-vector-builtins-shapes.h  |   3 +
 gcc/config/riscv/riscv-vector-builtins.cc |  70 +
 gcc/config/riscv/riscv-vector-builtins.h  |   3 +
 gcc/config/riscv/t-riscv  |   1 +
 .../riscv/thead-vector-builtins-functions.def |  39 +++
 gcc/config/riscv/thead-vector.md  | 250 ++
 .../riscv/rvv/xtheadvector/vlb-vsb.c  |  68 +
 .../riscv/rvv/xtheadvector/vlbu-vsb.c |  68 +
 .../riscv/rvv/xtheadvector/vlh-vsh.c  |  68 +
 .../riscv/rvv/xtheadvector/vlhu-vsh.c |  68 +
 .../riscv/rvv/xtheadvector/vlw-vsw.c  |  68 +
 .../riscv/rvv/xtheadvector/vlwu-vsw.c |  68 +
 15 files changed, 1104 insertions(+)
 create mode 100644 gcc/config/riscv/thead-vector-builtins-functions.def
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/vlb-vsb.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/vlbu-vsb.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/vlh-vsh.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/vlhu-vsh.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/vlw-vsw.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/vlwu-vsw.c

diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc 
b/gcc/config/riscv/riscv-vector-builtins-bases.cc
index 1aa6e3c6665..b6f6e4ff37e 100644
--- a/gcc/config/riscv/riscv-vector-builtins-bases.cc
+++ b/gcc/config/riscv/riscv-vector-builtins-bases.cc
@@ -2141,6 +2141,83 @@ public:
   }
 };
 
+/* Implements
+ * th.vl(b/h/w)[u].v/th.vs(b/h/w)[u].v/th.vls(b/h/w)[u].v/th.vss(b/h/w)[u].v/
+ * th.vlx(b/h/w)[u].v/th.vs[u]x(b/h/w).v
+ * codegen.  */
+template
+class th_loadstore_width : public function_base
+{
+public:
+  bool apply_tail_policy_p () const override { return !STORE_P; }
+  bool apply_mask_policy_p () const override { return !STORE_P; }
+
+  unsigned int call_properties (const function_instance &) const override
+  {
+if (STORE_P)
+  return CP_WRITE_MEMORY;
+else
+  return CP_READ_MEMORY;
+  }
+
+  bool can_be_overloaded_p (enum predication_type_index pred) const override
+  {
+if (STORE_P || LST_TYPE == LST_INDEXED)
+  return true;
+return pred != PRED_TYPE_none;
+  }
+
+  rtx expand (function_expander ) const override
+  {
+gcc_assert (TARGET_XTHEADVECTOR);
+if (LST_TYPE == LST_INDEXED)
+  {
+   if (STORE_P)
+ return e.use_exact_insn (
+   code_for_pred_indexed_store_width (UNSPEC, UNSPEC,
+  e.vector_mode ()));
+  

[PATCH v6] RISC-V: Handle differences between XTheadvector and Vector

[Jun Sha (Joshua)]

This patch is to handle the differences in instruction generation
between Vector and XTheadVector. In this version, we only support
partial xtheadvector instructions that leverage directly from current
RVV1.0 with simple adding "th." prefix. For different name xtheadvector
instructions but share same patterns as RVV1.0 instructions, we will
use ASM targethook to rewrite the whole string of the instructions in
the following patches. 

For some vector patterns that cannot be avoided, we use
"!TARGET_XTHEADVECTOR" to disable them in vector.md in order
not to generate instructions that xtheadvector does not support,
like vmv1r.

gcc/ChangeLog:

* config.gcc:  Add files for XTheadVector intrinsics.
* config/riscv/autovec.md: Guard XTheadVector.
* config/riscv/predicates.md: Disable immediate vl
for XTheadVector.
* config/riscv/riscv-c.cc (riscv_pragma_intrinsic):
Add pragma for XTheadVector.
* config/riscv/riscv-string.cc (riscv_expand_block_move):
Guard XTheadVector.
* config/riscv/riscv-v.cc (vls_mode_valid_p): 
Avoid autovec.
* config/riscv/riscv-vector-builtins-bases.cc:
Do not normalize vsetvl instructions for XTheadVector.
* config/riscv/riscv-vector-builtins-shapes.cc (check_type):
(build_one): New check type function.
* config/riscv/riscv-vector-switch.def (ENTRY):
Disable fractional mode for the XTheadVector extension.
(TUPLE_ENTRY): Likewise.
* config/riscv/riscv.cc (riscv_v_adjust_bytesize):
Guard XTheadVector.
(riscv_preferred_simd_mode): Likewsie.
(riscv_autovectorize_vector_modes): Likewise.
(riscv_vector_mode_supported_any_target_p): Likewise.
(TARGET_VECTOR_MODE_SUPPORTED_ANY_TARGET_P): Likewise.
* config/riscv/thead.cc (th_asm_output_opcode):
Rewrite vsetvl instructions.
* config/riscv/vector.md: 
Include thead-vector.md and change fractional LMUL
into 1 for vbool.
* config/riscv/riscv_th_vector.h: New file.
* config/riscv/thead-vector.md: New file.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pragma-1.c: Add XTheadVector.
* gcc.target/riscv/rvv/base/abi-1.c: Exclude XTheadVector.
* lib/target-supports.exp: Add target for XTheadVector.

Co-authored-by: Jin Ma 
Co-authored-by: Xianmiao Qu 
Co-authored-by: Christoph Müllner 
---
 gcc/config.gcc|   2 +-
 gcc/config/riscv/autovec.md   |   2 +-
 gcc/config/riscv/predicates.md|   4 +-
 gcc/config/riscv/riscv-c.cc   |   3 +-
 gcc/config/riscv/riscv-string.cc  |   3 +-
 gcc/config/riscv/riscv-v.cc   |   2 +-
 .../riscv/riscv-vector-builtins-bases.cc  |  48 --
 .../riscv/riscv-vector-builtins-shapes.cc |  23 +++
 gcc/config/riscv/riscv-vector-switch.def  | 150 +-
 gcc/config/riscv/riscv.cc |  20 ++-
 gcc/config/riscv/riscv_th_vector.h|  49 ++
 gcc/config/riscv/thead-vector.md  | 102 
 gcc/config/riscv/thead.cc |  23 ++-
 gcc/config/riscv/vector.md|  43 -
 .../gcc.target/riscv/rvv/base/abi-1.c |   2 +-
 .../gcc.target/riscv/rvv/base/pragma-1.c  |   2 +-
 gcc/testsuite/lib/target-supports.exp |  12 ++
 17 files changed, 380 insertions(+), 110 deletions(-)
 create mode 100644 gcc/config/riscv/riscv_th_vector.h
 create mode 100644 gcc/config/riscv/thead-vector.md

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 7e583390024..047e4c02cf4 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -549,7 +549,7 @@ riscv*)
extra_objs="${extra_objs} riscv-vector-builtins.o 
riscv-vector-builtins-shapes.o riscv-vector-builtins-bases.o"
extra_objs="${extra_objs} thead.o riscv-target-attr.o"
d_target_objs="riscv-d.o"
-   extra_headers="riscv_vector.h"
+   extra_headers="riscv_vector.h riscv_th_vector.h"
target_gtfiles="$target_gtfiles 
\$(srcdir)/config/riscv/riscv-vector-builtins.cc"
target_gtfiles="$target_gtfiles 
\$(srcdir)/config/riscv/riscv-vector-builtins.h"
;;
diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index 775eaa825b0..0477781cabe 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -2579,7 +2579,7 @@
   [(match_operand  0 "register_operand")
(match_operand  1 "memory_operand")
(match_operand:ANYI 2 "const_int_operand")]
-  "TARGET_VECTOR"
+  "TARGET_VECTOR && !TARGET_XTHEADVECTOR"
   {
 riscv_vector::expand_rawmemchr(mode, operands[0], operands[1],
   operands[2]);
diff --git a/gcc/config/riscv/predicates.md b/gcc/config/riscv/predicates.md
index b1a79cae50a..0337da88284 100644
--- a/gcc/config/riscv/predicates.md
+++ b/gcc/config/riscv/predicates.md
@@ -428,7 +428,9 @@
 

[PATCH v5] RISC-V: Adds the prefix "th." for the instructions of XTheadVector.

[Jun Sha (Joshua)]

This patch adds th. prefix to all XTheadVector instructions by
implementing new assembly output functions. We only check the
prefix is 'v', so that no extra attribute is needed.

gcc/ChangeLog:

* config/riscv/riscv-protos.h (riscv_asm_output_opcode):
Add new function to add assembler insn code prefix/suffix.
(th_asm_output_opcode):
Add Thead function to add assembler insn code prefix/suffix.
* config/riscv/riscv.cc (riscv_asm_output_opcode): 
Implement function to add assembler insn code prefix/suffix.
* config/riscv/riscv.h (ASM_OUTPUT_OPCODE):
Add new function to add assembler insn code prefix/suffix.
* config/riscv/thead.cc (th_asm_output_opcode):
Implement Thead function to add assembler insn code
prefix/suffix.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/xtheadvector/prefix.c: New test.

Co-authored-by: Jin Ma 
Co-authored-by: Xianmiao Qu 
Co-authored-by: Christoph Müllner 
---
 gcc/config/riscv/riscv-protos.h |  2 ++
 gcc/config/riscv/riscv.cc   | 11 +++
 gcc/config/riscv/riscv.h|  4 
 gcc/config/riscv/thead.cc   | 13 +
 .../gcc.target/riscv/rvv/xtheadvector/prefix.c  | 12 
 5 files changed, 42 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/prefix.c

diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 31049ef7523..71724dabdb5 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -102,6 +102,7 @@ struct riscv_address_info {
 };
 
 /* Routines implemented in riscv.cc.  */
+extern const char *riscv_asm_output_opcode (FILE *asm_out_file, const char *p);
 extern enum riscv_symbol_type riscv_classify_symbolic_expression (rtx);
 extern bool riscv_symbolic_constant_p (rtx, enum riscv_symbol_type *);
 extern int riscv_float_const_rtx_index_for_fli (rtx);
@@ -717,6 +718,7 @@ extern void th_mempair_prepare_save_restore_operands 
(rtx[4], bool,
  int, HOST_WIDE_INT,
  int, HOST_WIDE_INT);
 extern void th_mempair_save_restore_regs (rtx[4], bool, machine_mode);
+extern const char *th_asm_output_opcode (FILE *asm_out_file, const char *p);
 #ifdef RTX_CODE
 extern const char*
 th_mempair_output_move (rtx[4], bool, machine_mode, RTX_CODE);
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 0d1cbc5cb5f..51878797287 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -5636,6 +5636,17 @@ riscv_get_v_regno_alignment (machine_mode mode)
   return lmul;
 }
 
+/* Define ASM_OUTPUT_OPCODE to do anything special before
+   emitting an opcode.  */
+const char *
+riscv_asm_output_opcode (FILE *asm_out_file, const char *p)
+{
+  if (TARGET_XTHEADVECTOR)
+return th_asm_output_opcode (asm_out_file, p);
+
+  return p;
+}
+
 /* Implement TARGET_PRINT_OPERAND.  The RISCV-specific operand codes are:
 
'h' Print the high-part relocation associated with OP, after stripping
diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
index 6df9ec73c5e..c33361a254d 100644
--- a/gcc/config/riscv/riscv.h
+++ b/gcc/config/riscv/riscv.h
@@ -826,6 +826,10 @@ extern enum riscv_cc get_riscv_cc (const rtx use);
   asm_fprintf ((FILE), "%U%s", (NAME));\
   } while (0)
 
+#undef ASM_OUTPUT_OPCODE
+#define ASM_OUTPUT_OPCODE(STREAM, PTR) \
+  (PTR) = riscv_asm_output_opcode(STREAM, PTR)
+
 #define JUMP_TABLES_IN_TEXT_SECTION 0
 #define CASE_VECTOR_MODE SImode
 #define CASE_VECTOR_PC_RELATIVE (riscv_cmodel != CM_MEDLOW)
diff --git a/gcc/config/riscv/thead.cc b/gcc/config/riscv/thead.cc
index 20353995931..dc3aed3904d 100644
--- a/gcc/config/riscv/thead.cc
+++ b/gcc/config/riscv/thead.cc
@@ -883,6 +883,19 @@ th_output_move (rtx dest, rtx src)
   return NULL;
 }
 
+/* Define ASM_OUTPUT_OPCODE to do anything special before
+   emitting an opcode.  */
+const char *
+th_asm_output_opcode (FILE *asm_out_file, const char *p)
+{
+  /* We need to add th. prefix to all the xtheadvector
+ instructions here.*/
+  if (current_output_insn != NULL && p[0] == 'v')
+fputs ("th.", asm_out_file);
+
+  return p;
+}
+
 /* Implement TARGET_PRINT_OPERAND_ADDRESS for XTheadMemIdx.  */
 
 bool
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/prefix.c 
b/gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/prefix.c
new file mode 100644
index 000..eee727ef6b4
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/prefix.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv32gc_xtheadvector -mabi=ilp32 -O0" } */
+
+#include "riscv_vector.h"
+
+vint32m1_t
+prefix (vint32m1_t vx, vint32m1_t vy, size_t vl)
+{
+  return __riscv_vadd_vv_i32m1 (vx, vy, vl);
+}
+
+/* { dg-final { scan-assembler {\mth\.v\M} } } 

[PATCH v4] RISC-V: Introduce XTheadVector as a subset of V1.0.0

[Jun Sha (Joshua)]

This patch is to introduce basic XTheadVector support
(march string parsing and a test for __riscv_xtheadvector)
according to https://github.com/T-head-Semi/thead-extension-spec/

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc
(riscv_subset_list::parse): Add new vendor extension.
* config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins):
Add test marco.
* config/riscv/riscv.opt:  Add new mask.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/predef-__riscv_th_v_intrinsic.c: New test.
* gcc.target/riscv/rvv/xtheadvector.c: New test.

Co-authored-by: Jin Ma 
Co-authored-by: Xianmiao Qu 
Co-authored-by: Christoph Müllner 
---
 gcc/common/config/riscv/riscv-common.cc   | 23 +++
 gcc/config/riscv/riscv-c.cc   |  8 +--
 gcc/config/riscv/riscv.opt|  2 ++
 .../riscv/predef-__riscv_th_v_intrinsic.c | 11 +
 .../gcc.target/riscv/rvv/xtheadvector.c   | 13 +++
 5 files changed, 55 insertions(+), 2 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/predef-__riscv_th_v_intrinsic.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector.c

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index 0301d170a41..449722070d4 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -368,6 +368,7 @@ static const struct riscv_ext_version 
riscv_ext_version_table[] =
   {"xtheadmemidx", ISA_SPEC_CLASS_NONE, 1, 0},
   {"xtheadmempair", ISA_SPEC_CLASS_NONE, 1, 0},
   {"xtheadsync", ISA_SPEC_CLASS_NONE, 1, 0},
+  {"xtheadvector", ISA_SPEC_CLASS_NONE, 1, 0},
 
   {"xventanacondops", ISA_SPEC_CLASS_NONE, 1, 0},
 
@@ -1251,6 +1252,15 @@ riscv_subset_list::check_conflict_ext ()
   if (lookup ("zcmp"))
error_at (m_loc, "%<-march=%s%>: zcd conflicts with zcmp", m_arch);
 }
+
+  if ((lookup ("v") || lookup ("zve32x")
+|| lookup ("zve64x") || lookup ("zve32f")
+|| lookup ("zve64f") || lookup ("zve64d")
+|| lookup ("zvl32b") || lookup ("zvl64b")
+|| lookup ("zvl128b") || lookup ("zvfh"))
+&& lookup ("xtheadvector"))
+error_at (m_loc, "%<-march=%s%>: xtheadvector conflicts with vector "
+  "extension or its sub-extensions", m_arch);
 }
 
 /* Parsing function for multi-letter extensions.
@@ -1743,6 +1753,19 @@ static const riscv_ext_flag_table_t 
riscv_ext_flag_table[] =
   {"xtheadmemidx",  _options::x_riscv_xthead_subext, MASK_XTHEADMEMIDX},
   {"xtheadmempair", _options::x_riscv_xthead_subext, MASK_XTHEADMEMPAIR},
   {"xtheadsync",_options::x_riscv_xthead_subext, MASK_XTHEADSYNC},
+  {"xtheadvector",  _options::x_riscv_xthead_subext, MASK_XTHEADVECTOR},
+  {"xtheadvector",  _options::x_riscv_vector_elen_flags, 
MASK_VECTOR_ELEN_32},
+  {"xtheadvector",  _options::x_riscv_vector_elen_flags, 
MASK_VECTOR_ELEN_64},
+  {"xtheadvector",  _options::x_riscv_vector_elen_flags, 
MASK_VECTOR_ELEN_FP_32},
+  {"xtheadvector",  _options::x_riscv_vector_elen_flags, 
MASK_VECTOR_ELEN_FP_64},
+  {"xtheadvector",  _options::x_riscv_vector_elen_flags, 
MASK_VECTOR_ELEN_FP_16},
+  {"xtheadvector",  _options::x_riscv_zvl_flags, MASK_ZVL32B},
+  {"xtheadvector",  _options::x_riscv_zvl_flags, MASK_ZVL64B},
+  {"xtheadvector",  _options::x_riscv_zvl_flags, MASK_ZVL128B},
+  {"xtheadvector",  _options::x_riscv_zf_subext, MASK_ZVFHMIN},
+  {"xtheadvector",  _options::x_riscv_zf_subext, MASK_ZVFH},
+  {"xtheadvector",  _options::x_target_flags, MASK_FULL_V},
+  {"xtheadvector",  _options::x_target_flags, MASK_VECTOR},
 
   {"xventanacondops", _options::x_riscv_xventana_subext, 
MASK_XVENTANACONDOPS},
 
diff --git a/gcc/config/riscv/riscv-c.cc b/gcc/config/riscv/riscv-c.cc
index ba60cd8b555..422ddc2c308 100644
--- a/gcc/config/riscv/riscv-c.cc
+++ b/gcc/config/riscv/riscv-c.cc
@@ -142,6 +142,10 @@ riscv_cpu_cpp_builtins (cpp_reader *pfile)
 riscv_ext_version_value (0, 11));
 }
 
+   if (TARGET_XTHEADVECTOR)
+ builtin_define_with_int_value ("__riscv_th_v_intrinsic",
+riscv_ext_version_value (0, 11));
+
   /* Define architecture extension test macros.  */
   builtin_define_with_int_value ("__riscv_arch_test", 1);
 
@@ -195,8 +199,8 @@ riscv_pragma_intrinsic (cpp_reader *)
 {
   if (!TARGET_VECTOR)
{
- error ("%<#pragma riscv intrinsic%> option %qs needs 'V' extension "
-"enabled",
+ error ("%<#pragma riscv intrinsic%> option %qs needs 'V' or "
+"'XTHEADVECTOR' extension enabled",
 name);
  return;
}
diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
index 44ed6d69da2..bb18a22b693 100644
--- a/gcc/config/riscv/riscv.opt
+++ b/gcc/config/riscv/riscv.opt
@@ -452,6 +452,8 @@ Mask(XTHEADMEMPAIR) Var(riscv_xthead_subext)
 
 Mask(XTHEADSYNC)

Re: [PATCH] Update documents for fcf-protection=

[Hongtao Liu]

On Thu, Jan 11, 2024 at 12:06 AM H.J. Lu  wrote:
>
> On Tue, Jan 9, 2024 at 6:02 PM liuhongt  wrote:
> >
> > After r14-2692-g1c6231c05bdcca, the option is defined as EnumSet and
> > -fcf-protection=branch won't unset any others bits since they're in
> > different groups. So to override -fcf-protection, an explicit
> > -fcf-protection=none needs to be added and then with
> > -fcf-protection=XXX
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> > Ok for trunk?
> >
> > gcc/ChangeLog:
>
> We should mention:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113039
Changed, and committed.
>
> > * doc/invoke.texi (fcf-protection=): Update documents.
> > ---
> >  gcc/doc/invoke.texi | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> > index 68d1f364ac0..d1e6fafb98c 100644
> > --- a/gcc/doc/invoke.texi
> > +++ b/gcc/doc/invoke.texi
> > @@ -17734,6 +17734,9 @@ function.  The value @code{full} is an alias for 
> > specifying both
> >  @code{branch} and @code{return}. The value @code{none} turns off
> >  instrumentation.
> >
> > +To override @option{-fcf-protection}, @option{-fcf-protection=none}
> > +needs to be explicitly added and then with @option{-fcf-protection=xxx}.
> > +
> >  The value @code{check} is used for the final link with link-time
> >  optimization (LTO).  An error is issued if LTO object files are
> >  compiled with different @option{-fcf-protection} values.  The
> > --
> > 2.31.1
> >
>
>
> --
> H.J.



-- 
BR,
Hongtao

Re: [PATCH] i386: Add AVX10.1 related macros

[Hongtao Liu]

On Fri, Jan 12, 2024 at 10:55 AM Jiang, Haochen  wrote:
>
> > -Original Message-
> > From: Richard Biener 
> > Sent: Thursday, January 11, 2024 4:19 PM
> > To: Liu, Hongtao 
> > Cc: Jiang, Haochen ; gcc-patches@gcc.gnu.org;
> > ubiz...@gmail.com; bur...@net-b.de; san...@codesourcery.com
> > Subject: Re: [PATCH] i386: Add AVX10.1 related macros
> >
> > On Thu, Jan 11, 2024 at 2:16 AM Liu, Hongtao 
> > wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Richard Biener 
> > > > Sent: Wednesday, January 10, 2024 5:44 PM
> > > > To: Liu, Hongtao 
> > > > Cc: Jiang, Haochen ;
> > > > gcc-patches@gcc.gnu.org; ubiz...@gmail.com; bur...@net-b.de;
> > > > san...@codesourcery.com
> > > > Subject: Re: [PATCH] i386: Add AVX10.1 related macros
> > > >
> > > > On Wed, Jan 10, 2024 at 9:01 AM Liu, Hongtao 
> > > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Jiang, Haochen 
> > > > > > Sent: Wednesday, January 10, 2024 3:35 PM
> > > > > > To: gcc-patches@gcc.gnu.org
> > > > > > Cc: Liu, Hongtao ; ubiz...@gmail.com;
> > > > > > burnus@net- b.de; san...@codesourcery.com
> > > > > > Subject: [PATCH] i386: Add AVX10.1 related macros
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > This patch aims to add AVX10.1 related macros for libgomp's request.
> > > > > > The request comes following:
> > > > > >
> > > > > > https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642025.ht
> > > > > > ml
> > > > > >
> > > > > > Ok for trunk?
> > > > > >
> > > > > > Thx,
> > > > > > Haochen
> > > > > >
> > > > > > gcc/ChangeLog:
> > > > > >
> > > > > >   PR target/113288
> > > > > >   * config/i386/i386-c.cc (ix86_target_macros_internal):
> > > > > >   Add __AVX10_1__, __AVX10_1_256__ and __AVX10_1_512__.
> > > > > > ---
> > > > > >  gcc/config/i386/i386-c.cc | 7 +++
> > > > > >  1 file changed, 7 insertions(+)
> > > > > >
> > > > > > diff --git a/gcc/config/i386/i386-c.cc
> > > > > > b/gcc/config/i386/i386-c.cc index c3ae984670b..366b560158a
> > > > > > 100644
> > > > > > --- a/gcc/config/i386/i386-c.cc
> > > > > > +++ b/gcc/config/i386/i386-c.cc
> > > > > > @@ -735,6 +735,13 @@ ix86_target_macros_internal
> > (HOST_WIDE_INT
> > > > > > isa_flag,
> > > > > >  def_or_undef (parse_in, "__EVEX512__");
> > > > > >if (isa_flag2 & OPTION_MASK_ISA2_USER_MSR)
> > > > > >  def_or_undef (parse_in, "__USER_MSR__");
> > > > > > +  if (isa_flag2 & OPTION_MASK_ISA2_AVX10_1_256)
> > > > > > +{
> > > > > > +  def_or_undef (parse_in, "__AVX10_1_256__");
> > > > > > +  def_or_undef (parse_in, "__AVX10_1__");
> > > > > I think this is not needed, others LGTM.
> > > >
> > > > So __AVX10_1_256__ and __AVX10_1_512__ are redundant with
> > > > __AVX10_1__ and __EVEX512__, right?
> > > No, I mean __AVX10_1__ is redundant of __AVX10_1_256__ since -
> > mavx10.1 is just alias of -mavx10.1-256.
> > > We want explicit __AVX10_1_256__ and __AVX10_1_512__ and don't want
> > mix __EVEX512__ with AVX10(They are related in their internal
> > implementation, but we don't want the user to control the vector length of
> > avx10 with -mno-evex512, -mno-evex512 is supposed for the existing
> > AVX512).
>
> Let's keep both of them if we prefer __AVX10_1_256__ since I just found
> that LLVM got macro __AVX10_1__.
>
> https://github.com/llvm/llvm-project/pull/67278/files#diff-7435d50346a810555df89deb1f879b767ee985ace43fb3990de17fb23a47f004
>
> in file clang/lib/Basic/Targets/X86.cpp L774-777.
Ok.
>
> Thx,
> Haochen
>
> >
> > Ah, that makes sense.
> >
> > > > > > +}
> > > > > > +  if (isa_flag2 & OPTION_MASK_ISA2_AVX10_1_512)
> > > > > > +def_or_undef (parse_in, "__AVX10_1_512__");
> > > > > >if (TARGET_IAMCU)
> > > > > >  {
> > > > > >def_or_undef (parse_in, "__iamcu");
> > > > > > --
> > > > > > 2.31.1
> > > > >



-- 
BR,
Hongtao

[PATCH v5] RISC-V: Support XTheadVector extension

[Jun Sha (Joshua)]

This patch series presents gcc implementation of the XTheadVector
extension [1].

[1] https://github.com/T-head-Semi/thead-extension-spec/

For some vector patterns that cannot be avoided, we use
"!TARGET_XTHEADVECTOR" to disable them in order not to
generate instructions that xtheadvector does not support,
causing 10 changes in vector.md.

For the th. prefix issue, we use current_output_insn and
the ASM_OUTPUT_OPCODE hook instead of directly modifying
patterns in vector.md.

We have run the GCC test suite and can confirm that there
are no regressions.

Furthermore, we have run the tests in 
https://github.com/riscv-non-isa/rvv-intrinsic-doc/tree/main/examples, 
and all the tests passed.

Co-authored-by: Jin Ma 
Co-authored-by: Xianmiao Qu 
Co-authored-by: Christoph Müllner 

[PATCH v4] RISC-V: Introduce XTheadVector as a subset of V1.0.0
[PATCH v5] RISC-V: Adds the prefix "th." for the instructions of XTheadVector
[PATCH v6] RISC-V: Handle differences between XTheadvector and Vector
[PATCH v6] RISC-V: Add support for xtheadvector-specific intrinsics
[PATCH v6] RISC-V: Fix register overlap issue for some xtheadvector instructions
[PATCH v5] RISC-V: Rewrite some instructions using ASM targethook

Re: [PATCH] strub: Only unbias stack point for SPARC_STACK_BOUNDARY_HACK [PR113100]

[Kewen.Lin]

Hi Alexandre,

on 2024/1/11 17:05, Alexandre Oliva wrote:
> On Jan  7, 2024, "Kewen.Lin"  wrote:
> 
>> As PR113100 shows, the unbiasing introduced by r14-6737 can
>> cause the scrubbing to overrun and screw some critical data
>> on stack like saved toc base consequently cause segfault on
>> Power.
> 
> Ugh.  Sorry about the breakage, and thanks for addressing it during my
> absence.  Happy GNU Year! :-)
> 

No problem!  Happy New Year! :)

>> By checking PR112917, IMHO we should keep this unbiasing
>> guarded under SPARC_STACK_BOUNDARY_HACK (TARGET_ARCH64 &&
>> TARGET_STACK_BIAS), similar to some existing code special
>> treating SPARC stack bias.
> 
> I'm afraid this change will most certainly regress 32-bit sparc, because
> of the large register save area.

Oh, I read the comments and commit logs in PR112917, mainly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112917#{c4,c5,c6},
and the "sparc64" in subject of commit r14-6737 also implies
that this unbiasing is only required for sparc64, so I thought
it should be safe to guard with SPARC_STACK_BOUNDARY_HACK.

CC Rainer (reporter of PR112917), maybe he already noticed if it's
regressed or not.

> 
> I had been hesitant to introduce yet another target configuration knob,
> but it looks like this is what we're going to have to do to accommodate
> all targets.
> 
>> I also expect the culprit commit can
>> affect those ports with nonzero STACK_POINTER_OFFSET.
> 
> IMHO it really shouldn't.  STACK_POINTER_OFFSET should be the "Offset
> from the stack pointer register to the first location at which outgoing
> arguments are placed", which suggests to me that no data that the callee
> couldn't change should go in the area below (or above) %sp+S_P_O.
> 
> ISTM that PPC sets up a save area between the outgoing args and the

Yes, taking 64-bit PowerPC ELF abi 1.9 as example:

  |   Parameter save area(SP + 48)
  |   TOC save area  (SP + 40)
  |   link editor doubleword (SP + 32)
  |   compiler doubleword(SP + 24)
  |   LR save area   (SP + 16)
  |   CR save area   (SP + 8)
SP  --->  +-- Back chain (SP + 0)

https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#STACK

64-bit PowerPC ELF abi v2 drops "link editor doubleword" and "compiler
doubleword".  PR113100 failures mainly suffer from the TOC saved value
changed when it's used for TOC BASE restoring.

> stack pointer; I don't think that's very common, but I suppose other
> targets that do so would also define STACK_POINTER_OFFSET to nonzero so
> as to reserve those bits.  But whether they should be cleared by stack
> scrubbing, as on sparc, or preserved, as on ppc, depends on the ABI
> conventions, so we probably can't help yet another knob :-/

I agree, it really depends on ABI conventions, taking 64-bit PowerPC
ELF abi as example, some of them is safe to be scrubbed like "LR save
area", some of them depends on if they are used like "TOC save area".
It reminds me that even if on somewhere there is no failures with
scrubbing them, it doesn't really mean it's always safe to scrub since
it's possible that there are no enough testing coverage.  For example,
back chain gets cleared but no issues would be exposed if there is no
test case happening to do some jobs with back chain.  From this
perspective, excepting for the special need of sparc unbiasing, without
examining the specific ABIs, IMHO it's more conservative (not risky) not
to scrub this area than scrubbing it?

> 
> I'll take care of that, and update the corresponding documentation.

Nice, thanks!  Welcome back. :-)

BR,
Kewen

RE: [PATCH v1] RISC-V: Update the comments of riscv_v_ext_mode_p [NFC]

[Li, Pan2]

Committed, thanks Juzhe.

Pan

From: juzhe.zh...@rivai.ai 
Sent: Friday, January 12, 2024 10:54 AM
To: Li, Pan2 ; gcc-patches 
Cc: Li, Pan2 ; Wang, Yanzhang ; 
kito.cheng 
Subject: Re: [PATCH v1] RISC-V: Update the comments of riscv_v_ext_mode_p [NFC]

OK


juzhe.zh...@rivai.ai

From: pan2.li
Date: 2024-01-12 10:52
To: gcc-patches
CC: juzhe.zhong; 
pan2.li; 
yanzhang.wang; 
kito.cheng
Subject: [PATCH v1] RISC-V: Update the comments of riscv_v_ext_mode_p [NFC]
From: Pan Li mailto:pan2...@intel.com>>

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_v_ext_mode_p): Update the
comments of predicate func riscv_v_ext_mode_p.

Signed-off-by: Pan Li mailto:pan2...@intel.com>>
---
gcc/config/riscv/riscv.cc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index df9799d9c5e..f829014a589 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -1361,7 +1361,10 @@ riscv_v_ext_vls_mode_p (machine_mode mode)
   return false;
}
-/* Return true if it is either RVV vector mode or RVV tuple mode.  */
+/* Return true if it is either of below modes.
+   1. RVV vector mode.
+   2. RVV tuple mode.
+   3. RVV vls mode.  */
static bool
riscv_v_ext_mode_p (machine_mode mode)
--
2.34.1

RE: [PATCH] i386: Add AVX10.1 related macros

[Jiang, Haochen]

> -Original Message-
> From: Richard Biener 
> Sent: Thursday, January 11, 2024 4:19 PM
> To: Liu, Hongtao 
> Cc: Jiang, Haochen ; gcc-patches@gcc.gnu.org;
> ubiz...@gmail.com; bur...@net-b.de; san...@codesourcery.com
> Subject: Re: [PATCH] i386: Add AVX10.1 related macros
> 
> On Thu, Jan 11, 2024 at 2:16 AM Liu, Hongtao 
> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Richard Biener 
> > > Sent: Wednesday, January 10, 2024 5:44 PM
> > > To: Liu, Hongtao 
> > > Cc: Jiang, Haochen ;
> > > gcc-patches@gcc.gnu.org; ubiz...@gmail.com; bur...@net-b.de;
> > > san...@codesourcery.com
> > > Subject: Re: [PATCH] i386: Add AVX10.1 related macros
> > >
> > > On Wed, Jan 10, 2024 at 9:01 AM Liu, Hongtao 
> > > wrote:
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Jiang, Haochen 
> > > > > Sent: Wednesday, January 10, 2024 3:35 PM
> > > > > To: gcc-patches@gcc.gnu.org
> > > > > Cc: Liu, Hongtao ; ubiz...@gmail.com;
> > > > > burnus@net- b.de; san...@codesourcery.com
> > > > > Subject: [PATCH] i386: Add AVX10.1 related macros
> > > > >
> > > > > Hi all,
> > > > >
> > > > > This patch aims to add AVX10.1 related macros for libgomp's request.
> > > > > The request comes following:
> > > > >
> > > > > https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642025.ht
> > > > > ml
> > > > >
> > > > > Ok for trunk?
> > > > >
> > > > > Thx,
> > > > > Haochen
> > > > >
> > > > > gcc/ChangeLog:
> > > > >
> > > > >   PR target/113288
> > > > >   * config/i386/i386-c.cc (ix86_target_macros_internal):
> > > > >   Add __AVX10_1__, __AVX10_1_256__ and __AVX10_1_512__.
> > > > > ---
> > > > >  gcc/config/i386/i386-c.cc | 7 +++
> > > > >  1 file changed, 7 insertions(+)
> > > > >
> > > > > diff --git a/gcc/config/i386/i386-c.cc
> > > > > b/gcc/config/i386/i386-c.cc index c3ae984670b..366b560158a
> > > > > 100644
> > > > > --- a/gcc/config/i386/i386-c.cc
> > > > > +++ b/gcc/config/i386/i386-c.cc
> > > > > @@ -735,6 +735,13 @@ ix86_target_macros_internal
> (HOST_WIDE_INT
> > > > > isa_flag,
> > > > >  def_or_undef (parse_in, "__EVEX512__");
> > > > >if (isa_flag2 & OPTION_MASK_ISA2_USER_MSR)
> > > > >  def_or_undef (parse_in, "__USER_MSR__");
> > > > > +  if (isa_flag2 & OPTION_MASK_ISA2_AVX10_1_256)
> > > > > +{
> > > > > +  def_or_undef (parse_in, "__AVX10_1_256__");
> > > > > +  def_or_undef (parse_in, "__AVX10_1__");
> > > > I think this is not needed, others LGTM.
> > >
> > > So __AVX10_1_256__ and __AVX10_1_512__ are redundant with
> > > __AVX10_1__ and __EVEX512__, right?
> > No, I mean __AVX10_1__ is redundant of __AVX10_1_256__ since -
> mavx10.1 is just alias of -mavx10.1-256.
> > We want explicit __AVX10_1_256__ and __AVX10_1_512__ and don't want
> mix __EVEX512__ with AVX10(They are related in their internal
> implementation, but we don't want the user to control the vector length of
> avx10 with -mno-evex512, -mno-evex512 is supposed for the existing
> AVX512).

Let's keep both of them if we prefer __AVX10_1_256__ since I just found
that LLVM got macro __AVX10_1__.

https://github.com/llvm/llvm-project/pull/67278/files#diff-7435d50346a810555df89deb1f879b767ee985ace43fb3990de17fb23a47f004

in file clang/lib/Basic/Targets/X86.cpp L774-777.

Thx,
Haochen

> 
> Ah, that makes sense.
> 
> > > > > +}
> > > > > +  if (isa_flag2 & OPTION_MASK_ISA2_AVX10_1_512)
> > > > > +def_or_undef (parse_in, "__AVX10_1_512__");
> > > > >if (TARGET_IAMCU)
> > > > >  {
> > > > >def_or_undef (parse_in, "__iamcu");
> > > > > --
> > > > > 2.31.1
> > > >

Re: [PATCH v1] RISC-V: Update the comments of riscv_v_ext_mode_p [NFC]

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

OK



juzhe.zh...@rivai.ai
 
From: pan2.li
Date: 2024-01-12 10:52
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Update the comments of riscv_v_ext_mode_p [NFC]
From: Pan Li 
 
gcc/ChangeLog:
 
* config/riscv/riscv.cc (riscv_v_ext_mode_p): Update the
comments of predicate func riscv_v_ext_mode_p.
 
Signed-off-by: Pan Li 
---
gcc/config/riscv/riscv.cc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
 
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index df9799d9c5e..f829014a589 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -1361,7 +1361,10 @@ riscv_v_ext_vls_mode_p (machine_mode mode)
   return false;
}
-/* Return true if it is either RVV vector mode or RVV tuple mode.  */
+/* Return true if it is either of below modes.
+   1. RVV vector mode.
+   2. RVV tuple mode.
+   3. RVV vls mode.  */
static bool
riscv_v_ext_mode_p (machine_mode mode)
-- 
2.34.1
 
 

[PATCH v1] RISC-V: Update the comments of riscv_v_ext_mode_p [NFC]

[pan2 . li]

From: Pan Li 

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_v_ext_mode_p): Update the
comments of predicate func riscv_v_ext_mode_p.

Signed-off-by: Pan Li 
---
 gcc/config/riscv/riscv.cc | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index df9799d9c5e..f829014a589 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -1361,7 +1361,10 @@ riscv_v_ext_vls_mode_p (machine_mode mode)
   return false;
 }
 
-/* Return true if it is either RVV vector mode or RVV tuple mode.  */
+/* Return true if it is either of below modes.
+   1. RVV vector mode.
+   2. RVV tuple mode.
+   3. RVV vls mode.  */
 
 static bool
 riscv_v_ext_mode_p (machine_mode mode)
-- 
2.34.1

RE: [PATCH] i386: Remove redundant move in vnni pattern

[Liu, Hongtao]

> -Original Message-
> From: Jiang, Haochen 
> Sent: Friday, January 12, 2024 10:26 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com
> Subject: [PATCH] i386: Remove redundant move in vnni pattern
> 
> Hi all,
> 
> This patch removes all redundant set in vnni patterns.
> 
> Ok for trunk?
Ok.
> 
> Thx,
> Haochen
> 
> gcc/ChangeLog:
> 
>   * config/i386/sse.md (sdot_prod): Remove redundant SET.
>   (usdot_prod): Ditto.
>   (sdot_prod): Ditto.
>   (udot_prod): Ditto.
> ---
>  gcc/config/i386/sse.md | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md index
> 532738dcf94..acd10908d76 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -16174,7 +16174,6 @@
>operands[2] = lowpart_subreg (mode,
>   force_reg (mode, operands[2]),
>   mode);
> -  emit_insn (gen_rtx_SET (operands[0], operands[3]));
>emit_insn (gen_vpdpwssd_ (operands[0],
> operands[3],
>  operands[1], operands[2]));
>  }
> @@ -29963,7 +29962,6 @@
>operands[2] = lowpart_subreg (mode,
>   force_reg (mode, operands[2]),
>   mode);
> -  emit_insn (gen_rtx_SET (operands[0], operands[3]));
>emit_insn (gen_vpdpbusd_ (operands[0],
> operands[3],
> operands[1], operands[2]));
>DONE;
> @@ -30780,7 +30778,6 @@
>operands[2] = lowpart_subreg (mode,
>   force_reg (mode, operands[2]),
>   mode);
> -  emit_insn (gen_rtx_SET (operands[0], operands[3]));
>emit_insn (gen_vpdpbssd_ (operands[0],
> operands[3],
> operands[1], operands[2]));
>  }
> @@ -30857,7 +30854,6 @@
>operands[2] = lowpart_subreg (mode,
>   force_reg (mode, operands[2]),
>   mode);
> -  emit_insn (gen_rtx_SET (operands[0], operands[3]));
>emit_insn (gen_vpdpbuud_ (operands[0],
> operands[3],
> operands[1], operands[2]));
> }
> --
> 2.31.1

Re: Re: [PATCH] RISC-V: Modify ABI-name length of vfloat16m8_t

[Feng Wang]

Committed, thanks.
From: juzhe.zh...@rivai.ai
Date: 2024-01-12 09:38
To: wangfeng; gcc-patches
CC: kito.cheng; jeffreyalaw; wangfeng
Subject: Re: [PATCH] RISC-V: Modify ABI-name length of vfloat16m8_t
Good catch. LGTM.



juzhe.zh...@rivai.ai
 
From: Feng Wang
Date: 2024-01-12 09:35
To: gcc-patches
CC: kito.cheng; jeffreyalaw; juzhe.zhong; Feng Wang
Subject: [PATCH] RISC-V: Modify ABI-name length of vfloat16m8_t
The length of vfloat16m8_t ABI-name should be 17.
gcc/ChangeLog:
 
* config/riscv/riscv-vector-builtins.def (vfloat16m8_t):Modify ABI-name length 
of vfloat16m8_t 
---
gcc/config/riscv/riscv-vector-builtins.def | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
 
diff --git a/gcc/config/riscv/riscv-vector-builtins.def 
b/gcc/config/riscv/riscv-vector-builtins.def
index 055ee8b2ca4..784b54c81a4 100644
--- a/gcc/config/riscv/riscv-vector-builtins.def
+++ b/gcc/config/riscv/riscv-vector-builtins.def
@@ -483,7 +483,7 @@ DEF_RVV_TYPE (vfloat16m4_t, 17, __rvv_float16m4_t, float16, 
RVVM4HF, _f16m4,
/* Define tuple types for SEW = 16, LMUL = M4. */
DEF_RVV_TUPLE_TYPE (vfloat16m4x2_t, 19, __rvv_float16m4x2_t, vfloat16m4_t, 
float16, 2, _f16m4x2)
/* LMUL = 8.  */
-DEF_RVV_TYPE (vfloat16m8_t, 16, __rvv_float16m8_t, float16, RVVM8HF, _f16m8,
+DEF_RVV_TYPE (vfloat16m8_t, 17, __rvv_float16m8_t, float16, RVVM8HF, _f16m8,
  _f16, _e16m8)
/* Disable all when !TARGET_VECTOR_ELEN_FP_32.  */
-- 
2.17.1
 
 

[PATCH] i386: Remove redundant move in vnni pattern

[Haochen Jiang]

Hi all,

This patch removes all redundant set in vnni patterns.

Ok for trunk?

Thx,
Haochen

gcc/ChangeLog:

* config/i386/sse.md (sdot_prod): Remove redundant SET.
(usdot_prod): Ditto.
(sdot_prod): Ditto.
(udot_prod): Ditto.
---
 gcc/config/i386/sse.md | 4 
 1 file changed, 4 deletions(-)

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 532738dcf94..acd10908d76 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -16174,7 +16174,6 @@
   operands[2] = lowpart_subreg (mode,
force_reg (mode, operands[2]),
mode);
-  emit_insn (gen_rtx_SET (operands[0], operands[3]));
   emit_insn (gen_vpdpwssd_ (operands[0], operands[3],
   operands[1], operands[2]));
 }
@@ -29963,7 +29962,6 @@
   operands[2] = lowpart_subreg (mode,
force_reg (mode, operands[2]),
mode);
-  emit_insn (gen_rtx_SET (operands[0], operands[3]));
   emit_insn (gen_vpdpbusd_ (operands[0], operands[3],
  operands[1], operands[2]));
   DONE;
@@ -30780,7 +30778,6 @@
   operands[2] = lowpart_subreg (mode,
force_reg (mode, operands[2]),
mode);
-  emit_insn (gen_rtx_SET (operands[0], operands[3]));
   emit_insn (gen_vpdpbssd_ (operands[0], operands[3],
  operands[1], operands[2]));
 }
@@ -30857,7 +30854,6 @@
   operands[2] = lowpart_subreg (mode,
force_reg (mode, operands[2]),
mode);
-  emit_insn (gen_rtx_SET (operands[0], operands[3]));
   emit_insn (gen_vpdpbuud_ (operands[0], operands[3],
  operands[1], operands[2]));
}
-- 
2.31.1

Re: [Patch, rs6000] Eliminate unnecessary byte swaps for block clear on P8 LE [PR113325]

[HAO CHEN GUI]

Hi Richard,
   Thanks so much for your comments.


>> patch.diff
>> diff --git a/gcc/config/rs6000/rs6000-string.cc 
>> b/gcc/config/rs6000/rs6000-string.cc
>> index 7f777666ba9..4c9b2cbeefc 100644
>> --- a/gcc/config/rs6000/rs6000-string.cc
>> +++ b/gcc/config/rs6000/rs6000-string.cc
>> @@ -140,7 +140,9 @@ expand_block_clear (rtx operands[])
>> }
>>
>>dest = adjust_address (orig_dest, mode, offset);
>> -
>> +  /* Set the alignment of dest to the size of mode in order to
>> +avoid unnecessary byte swaps on LE.  */
>> +  set_mem_align (dest, GET_MODE_SIZE (mode) * BITS_PER_UNIT);
> 
> but the alignment is now wrong which might cause ripple-down
> wrong-code effects, no?
> 
> It's probably bad to hide the byte-swapping in the move patterns (I'm
> just guessing
> you do that)

Here I just change the alignment of "dest" which is temporary used for
move. The orig_dest is untouched and keep the original alignment. The
subsequent insns which use orig_dest are not affected. I am not sure if
it causes ripple-down effects. Do you mean the dest might be reused
later? But I think the alignment is different even though the mode and
offset is the same.

Looking forward to your advice.

Thanks
Gui Haochen

[PATCH v1] LoongArch: testsuite:Fix fail in gen-vect-{2,25}.c file.

[chenxiaolong]

1.Delete "dg-do run".
  When binutils do not support vectorization, an error occurs during
the assembly phase that does not recognize vector instructions.

2.Added "-mlsx" option for vectorization on LoongArch.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/gen-vect-2.c: Remove the program's default setting
run state and add the "-mlsx" compilation option for the additional
LoongArch architecture.
* gcc.dg/tree-ssa/gen-vect-25.c: Dito.
---
 gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c  | 3 ++-
 gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c 
b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c
index b84f3184427..b83e355e93c 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c
@@ -1,6 +1,7 @@
-/* { dg-do run { target vect_cmdline_needed } } */
+/* { target vect_cmdline_needed } */
 /* { dg-options "-O2 -fno-tree-loop-distribute-patterns -ftree-vectorize 
-fdump-tree-vect-details -fvect-cost-model=dynamic" } */
 /* { dg-additional-options "-mno-sse" { target { i?86-*-* x86_64-*-* } } } */
+/* { dg-additional-options "-mlsx" { target { loongarch*-*-* } } } */
 
 #include 
 
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c 
b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c
index 18fe1aa1502..edbc1dce28f 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c
@@ -1,6 +1,7 @@
-/* { dg-do run { target vect_cmdline_needed } } */
+/* { target vect_cmdline_needed } */
 /* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-details 
-fvect-cost-model=dynamic" } */
 /* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-details 
-fvect-cost-model=dynamic -mno-sse" { target { i?86-*-* x86_64-*-* } } } */
+/* { dg-additional-options "-mlsx" { target { loongarch*-*-* } } } */
 
 #include 
 
-- 
2.20.1

[PATCH v1] LoongArch: testsuite:Added additional vectorization "-mlsx" option.

[chenxiaolong]

gcc/testsuite/ChangeLog:

* gcc.dg/pr104992.c: Added additional "-mlsx" compilation options.
* gcc.dg/signbit-2.c: Dito.
* gcc.dg/tree-ssa/scev-16.c: Dito.
* gfortran.dg/graphite/vect-pr40979.f90: Dito.
* gfortran.dg/vect/fast-math-mgrid-resid.f: Dito.
---
 gcc/testsuite/gcc.dg/pr104992.c| 1 +
 gcc/testsuite/gcc.dg/signbit-2.c   | 1 +
 gcc/testsuite/gcc.dg/tree-ssa/scev-16.c| 1 +
 gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90| 1 +
 gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f | 1 +
 5 files changed, 5 insertions(+)

diff --git a/gcc/testsuite/gcc.dg/pr104992.c b/gcc/testsuite/gcc.dg/pr104992.c
index 82f8c75559c..a77992fa491 100644
--- a/gcc/testsuite/gcc.dg/pr104992.c
+++ b/gcc/testsuite/gcc.dg/pr104992.c
@@ -1,6 +1,7 @@
 /* PR tree-optimization/104992 */
 /* { dg-do compile } */
 /* { dg-options "-O2 -Wno-psabi -fdump-tree-optimized" } */
+/* { dg-additional-options "-mlsx" { target loongarch_sx } } */
 
 #define vector __attribute__((vector_size(4*sizeof(int
 
diff --git a/gcc/testsuite/gcc.dg/signbit-2.c b/gcc/testsuite/gcc.dg/signbit-2.c
index 62bb4047d74..5511bb78149 100644
--- a/gcc/testsuite/gcc.dg/signbit-2.c
+++ b/gcc/testsuite/gcc.dg/signbit-2.c
@@ -5,6 +5,7 @@
 /* { dg-additional-options "-msse2 -mno-avx512f" { target { i?86-*-* 
x86_64-*-* } } } */
 /* { dg-additional-options "-march=armv8-a" { target aarch64_sve } } */
 /* { dg-additional-options "-maltivec" { target powerpc_altivec_ok } } */
+/* { dg-additional-options "-mlsx" { target loongarch_sx } } */
 /* { dg-skip-if "no fallback for MVE" { arm_mve } } */
 
 #include 
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c 
b/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
index 120f40c0b6c..acaa1156419 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target vect_int } */
 /* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-details" } */
+/* { dg-additional-options "-mlsx" { target loongarch*-*-* } } */
 
 int A[1024 * 2];
 
diff --git a/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90 
b/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
index a42290948c4..4c251aacbe3 100644
--- a/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
+++ b/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
@@ -1,6 +1,7 @@
 ! { dg-do compile }
 ! { dg-require-effective-target vect_double }
 ! { dg-additional-options "-msse2" { target { { i?86-*-* x86_64-*-* } && ilp32 
} } }
+! { dg-additional-options "-mlsx" { target loongarch*-*-* } }
 
 module mqc_m
 integer, parameter, private :: longreal = selected_real_kind(15,90)
diff --git a/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f 
b/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
index 08965cc5e20..97b88821731 100644
--- a/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
+++ b/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
@@ -2,6 +2,7 @@
 ! { dg-require-effective-target vect_double }
 ! { dg-options "-O3 --param vect-max-peeling-for-alignment=0 
-fpredictive-commoning -fdump-tree-pcom-details -std=legacy" }
 ! { dg-additional-options "-mprefer-avx128" { target { i?86-*-* x86_64-*-* } } 
}
+! { dg-additional-options "-mlsx" { target { loongarch*-*-* } } }
 ! { dg-additional-options "-mzarch" { target { s390*-*-* } } }
 
 *** RESID COMPUTES THE RESIDUAL:  R = V - AU
-- 
2.20.1

Re:[pushed] [PATCH v2 1/2] LoongArch: Redundant sign extension elimination optimization.

[chenglulu]

Pushed to r14-7160 and r14-7161.

在 2024/1/11 下午7:36, Li Wei 写道:

We found that the current combine optimization pass in gcc cannot handle
the following redundant sign extension situations:

(insn 77 76 78 5 (set (reg:SI 143)
 (plus:SI (subreg/s/u:SI (reg/v:DI 104 [ len ]) 0)
 (const_int 1 [0x1]))) {addsi3}
 (expr_list:REG_DEAD (reg/v:DI 104 [ len ])
 (nil)))
(insn 78 77 82 5 (set (reg/v:DI 104 [ len ])
 (sign_extend:DI (reg:SI 143))) {extendsidi2}
 (nil))

Because reg:SI 143 is not died or set in insn 78, no replacement merge will
be performed for the insn sequence. We adjusted the add template to eliminate
redundant sign extensions during the expand pass.
Adjusted based on upstream comments:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641988.html

gcc/ChangeLog:

* config/loongarch/loongarch.md (add3): Removed.
(*addsi3): New.
(addsi3): Ditto.
(adddi3): Ditto.
(*addsi3_extended): Removed.
(addsi3_extended): New.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/sign-extend.c: Moved to...
* gcc.target/loongarch/sign-extend-1.c: ...here.
* gcc.target/loongarch/sign-extend-2.c: New test.
---
  gcc/config/loongarch/loongarch.md | 93 ++-
  .../{sign-extend.c => sign-extend-1.c}|  0
  .../gcc.target/loongarch/sign-extend-2.c  | 59 
  3 files changed, 128 insertions(+), 24 deletions(-)
  rename gcc/testsuite/gcc.target/loongarch/{sign-extend.c => sign-extend-1.c} 
(100%)
  create mode 100644 gcc/testsuite/gcc.target/loongarch/sign-extend-2.c

diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index 497a72e165c..ebc0476ea6f 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -657,42 +657,87 @@ (define_insn "add3"
[(set_attr "type" "fadd")
 (set_attr "mode" "")])
  
-(define_insn_and_split "add3"

-  [(set (match_operand:GPR 0 "register_operand" "=r,r,r,r,r,r,r")
-   (plus:GPR (match_operand:GPR 1 "register_operand" "r,r,r,r,r,r,r")
- (match_operand:GPR 2 "plus__operand"
-  "r,I,La,Lb,Lc,Ld,Le")))]
+(define_insn_and_split "*addsi3"
+  [(set (match_operand:SI 0 "register_operand" "=r,r,r,r,r")
+   (plus:SI (match_operand:SI 1 "register_operand" "r,r,r,r,r")
+ (match_operand:SI 2 "plus_si_operand"
+  "r,I,La,Lb,Le")))]
""
"@
-   add.\t%0,%1,%2
-   addi.\t%0,%1,%2
+   add.w\t%0,%1,%2
+   addi.w\t%0,%1,%2
 #
 * operands[2] = GEN_INT (INTVAL (operands[2]) / 65536); \
   return \"addu16i.d\t%0,%1,%2\";
+   #"
+  "CONST_INT_P (operands[2]) && !IMM12_INT (operands[2]) \
+   && !ADDU16I_OPERAND (INTVAL (operands[2]))"
+  [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3)))
+   (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))]
+  {
+loongarch_split_plus_constant ([2], SImode);
+  }
+  [(set_attr "alu_type" "add")
+   (set_attr "mode" "SI")
+   (set_attr "insn_count" "1,1,2,1,2")])
+
+(define_expand "addsi3"
+  [(set (match_operand:SI 0 "register_operand" "=r,r,r,r,r")
+   (plus:SI (match_operand:SI 1 "register_operand" "r,r,r,r,r")
+(match_operand:SI 2 "plus_si_operand"  "r,I,La,Le,Lb")))]
+  "TARGET_64BIT"
+{
+  if (CONST_INT_P (operands[2]) && !IMM12_INT (operands[2])
+  && ADDU16I_OPERAND (INTVAL (operands[2])))
+{
+  rtx t1 = gen_reg_rtx (DImode);
+  rtx t2 = gen_reg_rtx (DImode);
+  rtx t3 = gen_reg_rtx (DImode);
+  emit_insn (gen_extend_insn (t1, operands[1], DImode, SImode, 0));
+  t2 = operands[2];
+  emit_insn (gen_adddi3 (t3, t1, t2));
+  t3 = gen_lowpart (SImode, t3);
+  emit_move_insn (operands[0], t3);
+  DONE;
+}
+  else
+{
+  rtx t = gen_reg_rtx (DImode);
+  emit_insn (gen_addsi3_extended (t, operands[1], operands[2]));
+  t = gen_lowpart (SImode, t);
+  SUBREG_PROMOTED_VAR_P (t) = 1;
+  SUBREG_PROMOTED_SET (t, SRP_SIGNED);
+  emit_move_insn (operands[0], t);
+  DONE;
+}
+})
+
+(define_insn_and_split "adddi3"
+  [(set (match_operand:DI 0 "register_operand" "=r,r,r,r,r,r")
+   (plus:DI (match_operand:DI 1 "register_operand" "r,r,r,r,r,r")
+ (match_operand:DI 2 "plus_di_operand"
+  "r,I,La,Lb,Lc,Ld")))]
+  "TARGET_64BIT"
+  "@
+   add.d\t%0,%1,%2
+   addi.d\t%0,%1,%2
 #
+   * operands[2] = GEN_INT (INTVAL (operands[2]) / 65536); \
+ return \"addu16i.d\t%0,%1,%2\";
 #
 #"
-  "CONST_INT_P (operands[2]) && !IMM12_INT (operands[2]) \
+  "&& CONST_INT_P (operands[2]) && !IMM12_INT (operands[2]) \
 && !ADDU16I_OPERAND (INTVAL (operands[2]))"
-  [(set (match_dup 0) (plus:GPR (match_dup 1) (match_dup 3)))
-   (set (match_dup 0) (plus:GPR (match_dup 0) (match_dup 4)))]
+  [(set (match_dup 0) (plus:DI (match_dup 1) (match_dup 3)))
+   

Re: [PATCH v2 2/2] LoongArch: When the code model is extreme, the symbol address is obtained through macro instructions regardless of the value of -mexplicit-relocs.

[chenglulu]

I found an issue bootstrapping GCC with -mcmodel=extreme in BOOT_CFLAGS:
we need a target hook to tell the generic code
UNSPEC_LA_PCREL_64_PART{1,2} are just a wrapper around symbols, or we'll
see millions lines of messages like

../../gcc/gcc/tree.h:4171:1: note: non-delegitimized UNSPEC
UNSPEC_LA_PCREL_64_PART1 (42) found in variable location

I build GCC with -mcmodel=extreme in BOOT_CFLAGS, but I haven't 
reproduced the problem you mentioned.


$../configure --host=loongarch64-linux-gnu 
--target=loongarch64-linux-gnu --build=loongarch64-linux-gnu \


    --with-arch=loongarch64 --with-abi=lp64d --enable-tls 
--enable-languages=c,c++,fortran,lto --enable-plugin \


    --disable-multilib --disable-host-shared --enable-bootstrap 
--enable-checking=release


    $ make BOOT_FLAGS="-mcmodel=extreme"

What did I do wrong?:-(

Re: [PATCH] RISC-V: Modify ABI-name length of vfloat16m8_t

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

Good catch. LGTM.



juzhe.zh...@rivai.ai
 
From: Feng Wang
Date: 2024-01-12 09:35
To: gcc-patches
CC: kito.cheng; jeffreyalaw; juzhe.zhong; Feng Wang
Subject: [PATCH] RISC-V: Modify ABI-name length of vfloat16m8_t
The length of vfloat16m8_t ABI-name should be 17.
gcc/ChangeLog:
 
* config/riscv/riscv-vector-builtins.def (vfloat16m8_t):Modify ABI-name length 
of vfloat16m8_t 
---
gcc/config/riscv/riscv-vector-builtins.def | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
 
diff --git a/gcc/config/riscv/riscv-vector-builtins.def 
b/gcc/config/riscv/riscv-vector-builtins.def
index 055ee8b2ca4..784b54c81a4 100644
--- a/gcc/config/riscv/riscv-vector-builtins.def
+++ b/gcc/config/riscv/riscv-vector-builtins.def
@@ -483,7 +483,7 @@ DEF_RVV_TYPE (vfloat16m4_t, 17, __rvv_float16m4_t, float16, 
RVVM4HF, _f16m4,
/* Define tuple types for SEW = 16, LMUL = M4. */
DEF_RVV_TUPLE_TYPE (vfloat16m4x2_t, 19, __rvv_float16m4x2_t, vfloat16m4_t, 
float16, 2, _f16m4x2)
/* LMUL = 8.  */
-DEF_RVV_TYPE (vfloat16m8_t, 16, __rvv_float16m8_t, float16, RVVM8HF, _f16m8,
+DEF_RVV_TYPE (vfloat16m8_t, 17, __rvv_float16m8_t, float16, RVVM8HF, _f16m8,
  _f16, _e16m8)
/* Disable all when !TARGET_VECTOR_ELEN_FP_32.  */
-- 
2.17.1
 
 

[PATCH] RISC-V: Modify ABI-name length of vfloat16m8_t

[Feng Wang]

The length of vfloat16m8_t ABI-name should be 17.
gcc/ChangeLog:

* config/riscv/riscv-vector-builtins.def (vfloat16m8_t):Modify ABI-name 
length of vfloat16m8_t 
---
 gcc/config/riscv/riscv-vector-builtins.def | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/riscv/riscv-vector-builtins.def 
b/gcc/config/riscv/riscv-vector-builtins.def
index 055ee8b2ca4..784b54c81a4 100644
--- a/gcc/config/riscv/riscv-vector-builtins.def
+++ b/gcc/config/riscv/riscv-vector-builtins.def
@@ -483,7 +483,7 @@ DEF_RVV_TYPE (vfloat16m4_t, 17, __rvv_float16m4_t, float16, 
RVVM4HF, _f16m4,
 /* Define tuple types for SEW = 16, LMUL = M4. */
 DEF_RVV_TUPLE_TYPE (vfloat16m4x2_t, 19, __rvv_float16m4x2_t, vfloat16m4_t, 
float16, 2, _f16m4x2)
 /* LMUL = 8.  */
-DEF_RVV_TYPE (vfloat16m8_t, 16, __rvv_float16m8_t, float16, RVVM8HF, _f16m8,
+DEF_RVV_TYPE (vfloat16m8_t, 17, __rvv_float16m8_t, float16, RVVM8HF, _f16m8,
  _f16, _e16m8)
 
 /* Disable all when !TARGET_VECTOR_ELEN_FP_32.  */
-- 
2.17.1

Re: [PATCH RFC] codingconventions: add lambda guidelines

[Gerald Pfeifer]

On Thu, 11 Jan 2024, Jason Merrill wrote:
> Now in patch form!

It appears quite clear to me.

(At first I thought we need to escape the '&' in "[&] (tree arg)" as
"", but checking with validator.w3.org apparently not so in this 
specific context.)

Gerald

Re: [PATCHSET] Fix Rust bootstrap for future libgrust changes

[Thomas Schwinge]

Hi!

On 2024-01-11T15:22:07+0100, Arthur Cohen  wrote:
> Sorry about this - two simple changes to Makefile.def we had missed
> during our first libgrust/ patchset

I don't think those were "missed" but rather "intentionally omitted"?
I'll have to have a more detailed look.

(..., and almost no changes in the top-level build system I'd personally
dare to qualify as "simple"...)  ;-P


Grüße
 Thomas


> plus the associated regen of
> Makefile.in in each commit.
>
> Let me know if I should squash them together. I'll follow them up
> with our entire patchset.
>
> Best,
>
> Arthur

[PATCH] libgccjit: Fix float playback for cross-compilation

[Antoni Boucher]

Hi.
This patch fixes the bug 113343.
I'm wondering if there's a better solution than using mpfr.
The only other solution I found is real_from_string, but that seems
overkill to convert the number to a string.
I could not find a better way to create a real value from a host
double.
If there's no solution, do we lose some precision by using mpfr?
Running Rust's core library tests, there was a difference of one
decimal, so I'm wondering if there's some lost precision, or if it's
just because those tests don't work on m68k which was my test target.
Also, I'm not sure how to write a test this fix. Any ideas?
Thanks for the review.
From 8ddfd4abbe6e46efc256030c2d010f035cd9ecf0 Mon Sep 17 00:00:00 2001
From: Antoni Boucher 
Date: Sat, 21 Oct 2023 11:20:46 -0400
Subject: [PATCH] libgccjit: Fix float playback for cross-compilation

gcc/jit/ChangeLog:
	PR jit/113343
	* jit-playback.cc (new_rvalue_from_const): Fix to have the
	correct value when cross-compiling.
---
 gcc/jit/jit-playback.cc | 21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index 537f3b1..9cb27ee4ef3 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -41,6 +41,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gcc.h"
 #include "diagnostic.h"
 #include "stmt.h"
+#include "realmpfr.h"
 
 #include "jit-playback.h"
 #include "jit-result.h"
@@ -932,22 +933,16 @@ new_rvalue_from_const  (type *type,
   // FIXME: type-checking, or coercion?
   tree inner_type = type->as_tree ();
 
+  mpfr_t mpf_value;
+
+  mpfr_init2 (mpf_value, 64);
+  mpfr_set_d (mpf_value, value, MPFR_RNDN);
+
   /* We have a "double", we want a REAL_VALUE_TYPE.
 
- real.cc:real_from_target appears to require the representation to be
- split into 32-bit values, and then sent as an pair of host long
- ints.  */
+ realmpfr.cc:real_from_mpfr.  */
   REAL_VALUE_TYPE real_value;
-  union
-  {
-double as_double;
-uint32_t as_uint32s[2];
-  } u;
-  u.as_double = value;
-  long int as_long_ints[2];
-  as_long_ints[0] = u.as_uint32s[0];
-  as_long_ints[1] = u.as_uint32s[1];
-  real_from_target (_value, as_long_ints, DFmode);
+  real_from_mpfr (_value, mpf_value, inner_type, MPFR_RNDN);
   tree inner = build_real (inner_type, real_value);
   return new rvalue (this, inner);
 }
-- 
2.43.0

[PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs for pr105314.c

[Maciej W. Rozycki]

Verify that if-conversion succeeded through noce_try_store_flag_mask, as 
per PR rtl-optimization/105314, tightening the test case and making it 
explicit.

gcc/testsuite/
* gcc.target/riscv/pr105314.c: Scan the RTL "ce1" pass too.
---
 gcc/testsuite/gcc.target/riscv/pr105314.c |2 ++
 1 file changed, 2 insertions(+)

gcc-test-riscv-pr105314-rtl.diff
Index: gcc/gcc/testsuite/gcc.target/riscv/pr105314.c
===
--- gcc.orig/gcc/testsuite/gcc.target/riscv/pr105314.c
+++ gcc/gcc/testsuite/gcc.target/riscv/pr105314.c
@@ -1,6 +1,7 @@
 /* PR rtl-optimization/105314 */
 /* { dg-do compile } */
 /* { dg-skip-if "" { *-*-* } { "-O0" "-Og" "-Os" "-Oz" } } */
+/* { dg-options "-fdump-rtl-ce1" } */
 
 long
 foo (long a, long b, long c)
@@ -10,4 +11,5 @@ foo (long a, long b, long c)
   return a;
 }
 
+/* { dg-final { scan-rtl-dump-times "if-conversion succeeded through 
noce_try_store_flag_mask" 1 "ce1" } } */
 /* { dg-final { scan-assembler-not "\\s(?:beq|bne)\\s" } } */

[PATCH 1/2] RISC-V/testsuite: Widen coverage for pr105314.c

[Maciej W. Rozycki]

The optimization levels pr105314.c is iterated over are needlessly 
overridden with "-O2", limiting the coverage of the test case to that 
level, perhaps with additional options the original optimization level 
has been supplied with.  We could prevent the extra iterations other 
than "-O2" from being run, but the transformation made by if-conversion 
is also expected to happen at other optimization levels, so include them 
all, and also make sure no reverse-condition branch appears in output, 
moving the `dg-final' command to the bottom, as with most test cases.

gcc/testsuite/
* gcc.target/riscv/pr105314.c: Replace `dg-options' command with
`dg-skip-if'.  Also reject "bne" with `dg-final'.
---
Hi,

 Technically it's not a single self-contained change and it could be 3
instead, but I think there's little point in splitting it further.

  Maciej
---
 gcc/testsuite/gcc.target/riscv/pr105314.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

gcc-test-riscv-pr105314-levels.diff
Index: gcc/gcc/testsuite/gcc.target/riscv/pr105314.c
===
--- gcc.orig/gcc/testsuite/gcc.target/riscv/pr105314.c
+++ gcc/gcc/testsuite/gcc.target/riscv/pr105314.c
@@ -1,7 +1,6 @@
 /* PR rtl-optimization/105314 */
 /* { dg-do compile } */
-/* { dg-options "-O2" } */
-/* { dg-final { scan-assembler-not "\tbeq\t" } } */
+/* { dg-skip-if "" { *-*-* } { "-O0" "-Og" "-Os" "-Oz" } } */
 
 long
 foo (long a, long b, long c)
@@ -10,3 +9,5 @@ foo (long a, long b, long c)
 a = 0;
   return a;
 }
+
+/* { dg-final { scan-assembler-not "\\s(?:beq|bne)\\s" } } */

[PATCH 0/2] RISC-V/testsuite: A couple of improvements for pr105314.c

[Maciej W. Rozycki]

Hi,

 Here's a pair of further pr105314.c changes I came up with in the course 
of recent RISC-V if-conversion work.  It's not entirely clear to me what 
our policy is for Stages 3 and 4 when it comes to testsuite cleanups or 
improvements, but I think it's worth sharing these updates anyway.

 OK to apply, or shall I wait for Stage 1?

  Maciej

[PATCH] libstdc++: Fix non-portable results from 64-bit std::subtract_with_carry_engine [PR107466]

[Jonathan Wakely]

This fixes a regression introduced by the LWG 3809 change, so is needed
on trunk and gcc-13 and gcc-12.

Tested x86_64-linux and aarch64-linux.

-- >8 --

I implemented the resolution of LWG 3809 in r13-4364-ga64775a0edd469 but
more recently it was noted that the change causes possible truncation
for 64-bit seeds. Whether the truncation occurs (and to what value)
depends on the width of uint_least32_t which is not portable. The new
problem was filed as LWG 4014. I proposed a new change which reduces the
seed by the LCG's modulus before the conversion to uint_least32_t. This
ensures a consistent result across paltforms, and restores the old
behaviour for std::subtract_with_carry_engine specializations using a
64-bit result type (such as std::ranlux48_base).

libstdc++-v3/ChangeLog:

PR libstdc++/107466
* include/bits/random.tcc (subtract_with_carry_engine::seed):
Implement proposed resolution of LWG 4014.
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error
line number.
* 
testsuite/26_numerics/random/subtract_with_carry_engine/cons/lwg3809.cc:
Check for expected result of 64-bit engine with seed that
doesn't fit in 32-bits.
---
 libstdc++-v3/include/bits/random.tcc  |  5 -
 .../26_numerics/random/pr60037-neg.cc |  2 +-
 .../cons/lwg3809.cc   | 19 +--
 3 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/include/bits/random.tcc 
b/libstdc++-v3/include/bits/random.tcc
index 7f4bf5ea183..ade416390b3 100644
--- a/libstdc++-v3/include/bits/random.tcc
+++ b/libstdc++-v3/include/bits/random.tcc
@@ -541,8 +541,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 subtract_with_carry_engine<_UIntType, __w, __s, __r>::
 seed(result_type __value)
 {
+  // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 3809. Is std::subtract_with_carry_engine supposed to work?
+  // 4014. LWG 3809 changes behavior of some existing code
   std::linear_congruential_engine
-   __lcg(__value == 0u ? default_seed : __value);
+   __lcg(__value == 0u ? default_seed : __value % 2147483563u);
 
   const size_t __n = (__w + 31) / 32;
 
diff --git a/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc 
b/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc
index c58f480640f..59cf84adb48 100644
--- a/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc
+++ b/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc
@@ -12,4 +12,4 @@ auto x = std::generate_canonical
 #include 
 
-// LWG 3809. Is std::subtract_with_carry_engine supposed to work?
 // PR 107466 - invalid -Wnarrowing error with std::subtract_with_carry_engine
 
-int main()
+// LWG 3809. Is std::subtract_with_carry_engine supposed to work?
+void
+test_lwg3809()
 {
   // It should be possible to construct this engine with a 16-bit result_type:
   std::subtract_with_carry_engine s16;
@@ -24,3 +25,17 @@ int main()
   for (int i = 0; i < 10; ++i)
 VERIFY( s16() == s32() );
 }
+
+// LWG 4014. LWG 3809 changes behavior of some existing code
+void
+test_lwg4014()
+{
+  std::ranlux48_base g(-1U + 1LL);
+  VERIFY( g() == 22575453646312 );
+}
+
+int main()
+{
+  test_lwg3809();
+  test_lwg4014();
+}
-- 
2.43.0

Re: [PATCH] libstdc++/ranges: Use perfect forwarding in _Pipe and _Partial ctors

[Jonathan Wakely]

On Thu, 11 Jan 2024 at 16:12, Patrick Palka  wrote:
>
> On Thu, 11 Jan 2024, Jonathan Wakely wrote:
>
> > On Wed, 10 Jan 2024 at 21:40, Patrick Palka  wrote:
> > >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> > >
> > > -- >8 --
> > >
> > > This avoids redundant moves when composing and partially applying range
> > > adaptor objects.
> > >
> > > Note that the new constraints on _Partial's constructor templates are
> > > needed so that it's not inadvertently chosen over the copy constructor
> > > when constructing a _Partial object from a non-const _Partial lvalue.
> > >
> > > libstdc++-v3/ChangeLog:
> > >
> > > * include/std/ranges (views::__adaptor::operator|): Perform
> > > perfect forwarding of arguments.
> > > (views::__adaptor::_Partial::_Partial): Likewise.
> > > (views::__adaptor::_Pipe::__Pipe): Likewise.
> > > ---
> > >  libstdc++-v3/include/std/ranges | 65 -
> > >  1 file changed, 39 insertions(+), 26 deletions(-)
> > >
> > > diff --git a/libstdc++-v3/include/std/ranges 
> > > b/libstdc++-v3/include/std/ranges
> > > index 81a857502e3..0734daa42bf 100644
> > > --- a/libstdc++-v3/include/std/ranges
> > > +++ b/libstdc++-v3/include/std/ranges
> > > @@ -957,8 +957,11 @@ namespace views::__adaptor
> > >  requires __is_range_adaptor_closure<_Lhs>
> > >&& __is_range_adaptor_closure<_Rhs>
> > >  constexpr auto
> > > -operator|(_Lhs __lhs, _Rhs __rhs)
> > > -{ return _Pipe<_Lhs, _Rhs>{std::move(__lhs), std::move(__rhs)}; }
> > > +operator|(_Lhs&& __lhs, _Rhs&& __rhs)
> > > +{
> > > +  return _Pipe, 
> > > decay_t<_Rhs>>{std::forward<_Lhs>(__lhs),
> > > +
> > > std::forward<_Rhs>(__rhs)};
> > > +}
> > >
> > >// The base class of every range adaptor non-closure.
> > >//
> > > @@ -1004,10 +1007,12 @@ namespace views::__adaptor
> > >  {
> > >tuple<_Args...> _M_args;
> > >
> > > -  constexpr
> > > -  _Partial(_Args... __args)
> > > -   : _M_args(std::move(__args)...)
> > > -  { }
> > > +  template
> > > +   requires (sizeof...(_Ts) == sizeof...(_Args))
> >
> > Do we also need a !same_as constraint here? If sizeof...(_Args) == 1
> > then this could be chosen instead of a constructor, no?
>
> For the == 1 case we would have used a different partial specialization
> of _Partial (one that doesn't use heavyweight std::tuple).  So checking
> sizeof...(_Ts) == sizof...(_Args) instead is sufficient and simpler.

Aha thanks, I did wonder if that was the case but failed to see the
other partial specialization.

Looks fine for trunk then.

> Checking sizeof...(_Args) > 1 would be sufficient as well.
>
> >
> > Or is
> > > +   constexpr
> > > +   _Partial(_Ts&&... __args)
> > > + : _M_args(std::forward<_Ts>(__args)...)
> > > +   { }
> > >
> > >// Invoke _Adaptor with arguments __r, _M_args... according to the
> > >// value category of this _Partial object.
> > > @@ -1046,10 +1051,12 @@ namespace views::__adaptor
> > >  {
> > >_Arg _M_arg;
> > >
> > > -  constexpr
> > > -  _Partial(_Arg __arg)
> > > -   : _M_arg(std::move(__arg))
> > > -  { }
> > > +  template
> > > +   requires (!same_as, _Partial>)
> > > +   constexpr
> > > +   _Partial(_Tp&& __arg)
> > > + : _M_arg(std::forward<_Tp>(__arg))
> > > +   { }
> > >
> > >template
> > > requires __adaptor_invocable<_Adaptor, _Range, const _Arg&>
> > > @@ -1079,10 +1086,12 @@ namespace views::__adaptor
> > >  {
> > >tuple<_Args...> _M_args;
> > >
> > > -  constexpr
> > > -  _Partial(_Args... __args)
> > > -   : _M_args(std::move(__args)...)
> > > -  { }
> > > +  template
> > > +   requires (sizeof...(_Ts) == sizeof...(_Args))
> > > +   constexpr
> > > +   _Partial(_Ts&&... __args)
> > > + : _M_args(std::forward<_Ts>(__args)...)
> > > +   { }
> > >
> > >// Invoke _Adaptor with arguments __r, const _M_args&... regardless
> > >// of the value category of this _Partial object.
> > > @@ -1109,10 +1118,12 @@ namespace views::__adaptor
> > >  {
> > >_Arg _M_arg;
> > >
> > > -  constexpr
> > > -  _Partial(_Arg __arg)
> > > -   : _M_arg(std::move(__arg))
> > > -  { }
> > > +  template
> > > +   requires (!same_as, _Partial>)
> > > +   constexpr
> > > +   _Partial(_Tp&& __arg)
> > > + : _M_arg(std::forward<_Tp>(__arg))
> > > +   { }
> > >
> > >template
> > > requires __adaptor_invocable<_Adaptor, _Range, const _Arg&>
> > > @@ -1135,10 +1146,11 @@ namespace views::__adaptor
> > >[[no_unique_address]] _Lhs _M_lhs;
> > >[[no_unique_address]] _Rhs _M_rhs;
> > >
> > > -  constexpr
> > > -  _Pipe(_Lhs __lhs, _Rhs __rhs)
> > > -   : _M_lhs(std::move(__lhs)), _M_rhs(std::move(__rhs))
> > > -  { }
> > > 

Re: [PATCH] Add support for function attributes and variable attributes

[David Malcolm]

On Thu, 2024-01-11 at 22:40 +0100, Guillaume Gomez wrote:
> Hi David,
> 
> > The above looks correct, but the patch adds the entrypoint
> > descriptions
> > to topics/types.rst, which seems like the wrong place.  The
> > function-
> > related ones should be in topics/functions.rst in the "Functions"
> > section and the lvalue/variable one in topics/expression.rst after
> > the
> > "Global variables" section.
> 
> Ah indeed. Mix-up on my end. Fixed it.
> 
> > test-restrict.c is a pre-existing testcase, so please don't delete
> > its
> > entry.
> 
> Ah indeed, I went too quickly and thought it was a test I renamed...
> 
> > BTW, the ChangeLog entry mentions adding test-restrict.c, but the
> > patch
> > doesn't add it, so that part of the proposed ChangeLog is wrong.
> > 
> > Does the patch pass ./contrib/gcc-changelog/git_check_commit.py ?
> 
> I messed up a bit, fixed it thanks to you. I didn't run the script in
> my last
> update but just did:
> 
> ```
> $ contrib/gcc-changelog/git_check_commit.py $(git log -1 --format=%h)
> Checking 3849ee2eadf0eeec2b0080a5142ced00be96a60d: OK
> ```
> 
> > Otherwise, looks good, assuming that the patch has been tested with
> > the
> > full jit testsuite.
> 
> When rebasing on upstream yesterday I discovered that two tests
> were not working anymore. For the first one, it was simply because of
> the changes in `dummy-frontend.cc`. For the second one
> (test-noinline-attribute.c), it was because the rules for inlining
> changed
> since we wrote this patch apparently (our fork is very late). Antoni
> discovered
> that we could just add a call to `asm` to prevent this from happening
> so I
> added it.
> 
> So yes, all jit tests are passing as expected. :)

Good.

It sounds like the patch you have locally is ready, but it has some
nontrivial changes compared to the last version you posted to the list.
Please post your latest version to the list.

Do you have push rights, or do you need me to push it for you?

Thanks
Dave

> 
> Le jeu. 11 janv. 2024 à 19:46, David Malcolm  a
> écrit :
> > 
> > On Thu, 2024-01-11 at 01:00 +0100, Guillaume Gomez wrote:
> > > Hi David.
> > > 
> > > Thanks for the review!
> > > 
> > > > > +.. function::  void\
> > > > > +   gcc_jit_lvalue_add_string_attribute
> > > > > (gcc_jit_lvalue *variable,
> > > > > +    enum
> > > > > gcc_jit_fn_attribute attribute,
> > > > 
> > > > ^^
> > > > 
> > > > This got out of sync with the declaration in the header file;
> > > > it
> > > > should
> > > > be enum gcc_jit_variable_attribute attribute
> > > 
> > > Indeed, good catch!
> > > 
> > > > I took a brief look through the handler functions and with the
> > > > above
> > > > caveat I didn't see anything obviously wrong.  I'm going to
> > > > assume
> > > > this
> > > > code is OK given that presumably you've been testing it within
> > > > rustc,
> > > > right?
> > > 
> > > Both in rustc and in the JIT tests we added.
> > > 
> > > [..snip...]
> > > 
> > > I added all the missing `RETURN_IF_FAIL` you mentioned. None of
> > > the
> > > arguments should be `NULL` so it was a mistake not to check it.
> > > 
> > > [..snip...]
> > > 
> > > I removed the tests comments as you mentioned.
> > > 
> > > > Please update jit.dg/all-non-failing-tests.h for the new tests;
> > > > it's
> > > > meant to list all of the (non failing) tests alphabetically.
> > > 
> > > It's not always correctly sorted. Might be worth sending a patch
> > > after this
> > > one gets merged to fix that.
> > > 
> > > > I *think* all of the new tests aren't suitable to be run as
> > > > part of
> > > > a
> > > > shared context (e.g. due to touching the optimization level or
> > > > examining generated asm), so they should be listed in that
> > > > header
> > > > with
> > > > comments explaining why.
> > > 
> > > I added them with a comment on top of each of them.
> > > 
> > > I joined the new patch version.
> > > 
> > > Thanks again for the review!
> > 
> > Thanks for the updated patch.  I noticed a few minor issues:
> > 
> > > diff --git a/gcc/jit/docs/topics/types.rst
> > > b/gcc/jit/docs/topics/types.rst
> > > index bb51f037b7e..b1aedc03787 100644
> > > --- a/gcc/jit/docs/topics/types.rst
> > > +++ b/gcc/jit/docs/topics/types.rst
> > > @@ -553,3 +553,80 @@ Reflection API
> > >     .. code-block:: c
> > > 
> > >    #ifdef LIBGCCJIT_HAVE_gcc_jit_type_get_restrict
> > > +
> > > +.. function::  void\
> > > +   gcc_jit_function_add_attribute (gcc_jit_function
> > > *func,
> > > +   enum
> > > gcc_jit_fn_attribute attribute)
> > > +
> > > + Add an attribute ``attribute`` to a function ``func``.
> > > +
> > > + This is equivalent to the following code:
> > > +
> > > +  .. code-block:: c
> > > +
> > > +    __attribute__((always_inline))
> > > +
> > > +   This entrypoint was added in :ref:`LIBGCCJIT_ABI_26`; you can
> > > test for
> > > +   its presence using
> > > +
> > > +   .. 

Re: [PATCH] libstdc++: Implement P2255R2 dangling checks for std::tuple [PR108822]

[Ville Voutilainen]

On Fri, 12 Jan 2024 at 00:16, Jonathan Wakely  wrote:
>
> I'd like to commit this to trunk for GCC 14. Please take a look.

Without looking at it in excruciating detail, it's pretty much along
the lines of what I have always envisioned
to be a powerful combination of concepts and if-constexpr. My general
principle on this is "looks like an improvement,
so if it passes all the tests, ship it". :)

Sure, I have envisioned going even further with that combination, such
as significantly reducing the number of overloads
and doing more of it as an if-constexpr ladder, but there's a balance
where emulating the effects of overload resolution
in something like that can become such a burden that the benefits are
no longer there. If the field were green, I'd consider
that as the approach from the get-go when initially designing a type
like tuple, instead of doing it as an overload set.

[PATCH] libstdc++: Implement P2255R2 dangling checks for std::tuple [PR108822]

[Jonathan Wakely]

I'd like to commit this to trunk for GCC 14. Please take a look.

-- >8 --

This is the last part of PR libstdc++/108822 implementing P2255R2, which
makes it ill-formed to create a std::tuple that would bind a reference
to a temporary.

The dangling checks are implemented as deleted constructors for C++20
and higher, and as Debug Mode static assertions in the constructor body
for older standards. This is similar to the r13-6084-g916ce577ad109b
changes for std::pair.

As part of this change, I've reimplemented most of std::tuple for C++20,
making use of concepts to replace the enable_if constraints, and using
conditional explicit to avoid duplicating most constructors. We could
use conditional explicit for the C++11 implementation too (with pragmas
to disables the -Wc++17-extensions warnings), but that should be done as
a stage 1 change for GCC 15 rather than now.

The partial specialization for std::tuple is no longer used for
C++20 (or more precisely, for a C++20 compiler that supports concepts
and conditional explicit). The additional constructors and assignment
operators that take std::pair arguments have been added to the C++20
implementation of the primary template, with sizeof...(_Elements)==2
constraints. This avoids reimplementing all the other constructors in
the std::tuple partial specialization to use concepts. This way
we avoid four implementations of every constructor and only have three!
(The primary template has an implementation of each constructor for
C++11 and another for C++20, and the tuple specialization has an
implementation of each for C++11, so that's three for each constructor.)

In order to make the constraints more efficient on the C++20 version of
the default constructor I've also added a variable template for the
__is_implicitly_default_constructible trait, implemented using concepts.

libstdc++-v3/ChangeLog:

PR libstdc++/108822
* include/std/tuple (tuple): Add checks for dangling references.
Reimplement constraints and constant expressions using C++20
features.
* include/std/type_traits [C++20]
(__is_implicitly_default_constructible_v): Define.
(__is_implicitly_default_constructible): Use variable template.
* testsuite/20_util/tuple/dangling_ref.cc: New test.
---
 libstdc++-v3/include/std/tuple| 1021 -
 libstdc++-v3/include/std/type_traits  |   11 +
 .../testsuite/20_util/tuple/dangling_ref.cc   |  105 ++
 3 files changed, 841 insertions(+), 296 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/20_util/tuple/dangling_ref.cc

diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index 50e11843757..cd05b638923 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -752,11 +752,467 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 class tuple : public _Tuple_impl<0, _Elements...>
 {
-  typedef _Tuple_impl<0, _Elements...> _Inherited;
+  using _Inherited = _Tuple_impl<0, _Elements...>;
 
   template
using _TCC = _TupleConstraints<_Cond, _Elements...>;
 
+#if __cpp_concepts && __cpp_conditional_explicit // >= C++20
+  template
+   static consteval bool
+   __constructible()
+   {
+ if constexpr (sizeof...(_UTypes) == sizeof...(_Elements))
+   return (is_constructible_v<_Elements, _UTypes> && ...);
+ else
+   return false;
+   }
+
+  template
+   static consteval bool
+   __nothrow_constructible()
+   {
+ if constexpr (sizeof...(_UTypes) == sizeof...(_Elements))
+   return (is_nothrow_constructible_v<_Elements, _UTypes> && ...);
+ else
+   return false;
+   }
+
+  template
+   static consteval bool
+   __convertible()
+   {
+ if constexpr (sizeof...(_UTypes) == sizeof...(_Elements))
+   return (is_convertible_v<_UTypes, _Elements> && ...);
+ else
+   return false;
+   }
+
+  // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 3121. tuple constructor constraints for UTypes&&... overloads
+  template
+   static consteval bool
+   __disambiguating_constraint()
+   {
+ if constexpr (sizeof...(_Elements) != sizeof...(_UTypes))
+   return false;
+ else if constexpr (sizeof...(_Elements) == 1)
+   {
+ using _U0 = typename _Nth_type<0, _UTypes...>::type;
+ return !is_same_v, tuple>;
+   }
+ else if constexpr (sizeof...(_Elements) < 4)
+   {
+ using _U0 = typename _Nth_type<0, _UTypes...>::type;
+ if constexpr (!is_same_v, allocator_arg_t>)
+   return true;
+ else
+   {
+ using _T0 = typename _Nth_type<0, _Elements...>::type;
+ return is_same_v, allocator_arg_t>;
+   }
+   }
+ return true;
+   }
+
+  // Return true iff sizeof...(Types) 

[pushed] c++: corresponding object parms [PR113191]

[Jason Merrill]

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

-- 8< --

As discussed, our handling of corresponding object parameters needed to
handle the using-declaration case better.  And I took the opportunity to
share code between the add_method and cand_parms_match uses.

This patch specifically doesn't compare reversed parameters, but a follow-up
patch will.

PR c++/113191

gcc/cp/ChangeLog:

* class.cc (xobj_iobj_parameters_correspond): Add context parm.
(object_parms_correspond): Factor out of...
(add_method): ...here.
* method.cc (defaulted_late_check): Use it.
* call.cc (class_of_implicit_object): New.
(object_parms_correspond): Overload taking two candidates.
(cand_parms_match): Use it.
(joust): Check reversed before comparing constraints.
* cp-tree.h (object_parms_correspond): Declare.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-memfun4.C: New test.
---
 gcc/cp/cp-tree.h  |   1 +
 gcc/cp/call.cc|  84 
 gcc/cp/class.cc   | 121 ++
 gcc/cp/method.cc  |  16 +--
 gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C |  97 ++
 5 files changed, 228 insertions(+), 91 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-memfun4.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index f3f265a3db8..83009fc837c 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6853,6 +6853,7 @@ extern bool is_empty_base_ref (tree);
 extern tree build_vtbl_ref (tree, tree);
 extern tree build_vfn_ref  (tree, tree);
 extern tree get_vtable_decl(tree, int);
+extern bool object_parms_correspond(tree, tree, tree);
 extern bool add_method (tree, tree, bool);
 extern tree declared_access(tree);
 extern bool maybe_push_used_methods(tree);
diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 191664ee227..6f024b8abc3 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -12685,6 +12685,51 @@ joust_maybe_elide_copy (z_candidate *cand)
   return false;
 }
 
+/* Return the class that CAND's implicit object parameter refers to.  */
+
+static tree
+class_of_implicit_object (z_candidate *cand)
+{
+  if (!DECL_IOBJ_MEMBER_FUNCTION_P (cand->fn))
+return NULL_TREE;
+
+  /* "For conversion functions that are implicit object member functions,
+ the function is considered to be a member of the class of the implied
+ object argument for the purpose of defining the type of the implicit
+ object parameter."  */
+  if (DECL_CONV_FN_P (cand->fn))
+return TYPE_MAIN_VARIANT (TREE_TYPE (cand->first_arg));
+
+  /* "For non-conversion functions that are implicit object member
+ functions nominated by a using-declaration in a derived class, the
+ function is considered to be a member of the derived class for the
+ purpose of defining the type of the implicit object parameter."
+
+ That derived class is reflected in the conversion_path binfo.  */
+  return BINFO_TYPE (cand->conversion_path);
+}
+
+/* True if candidates C1 and C2 have corresponding object parameters per
+   [basic.scope.scope].  */
+
+static bool
+object_parms_correspond (z_candidate *c1, z_candidate *c2)
+{
+  tree context = class_of_implicit_object (c1);
+  tree ctx2 = class_of_implicit_object (c2);
+  if (!ctx2)
+/* Leave context as is. */;
+  else if (!context)
+context = ctx2;
+  else if (context != ctx2)
+/* This can't happen for normal function calls, since it means finding
+   functions in multiple bases which would fail with an ambiguous lookup,
+   but it can occur with reversed operators.  */
+return false;
+
+  return object_parms_correspond (c1->fn, c2->fn, context);
+}
+
 /* True if the defining declarations of the two candidates have equivalent
parameters.  */
 
@@ -12712,35 +12757,25 @@ cand_parms_match (z_candidate *c1, z_candidate *c2)
 }
   tree parms1 = TYPE_ARG_TYPES (TREE_TYPE (fn1));
   tree parms2 = TYPE_ARG_TYPES (TREE_TYPE (fn2));
-  auto skip_parms = [](tree fn, tree parms){
-  if (DECL_XOBJ_MEMBER_FUNCTION_P (fn))
-   return TREE_CHAIN (parms);
-  else
-   return skip_artificial_parms_for (fn, parms);
-};
   if (!(DECL_FUNCTION_MEMBER_P (fn1)
&& DECL_FUNCTION_MEMBER_P (fn2)))
 /* Early escape.  */;
-  else if ((DECL_STATIC_FUNCTION_P (fn1)
-   != DECL_STATIC_FUNCTION_P (fn2)))
+
+  /* CWG2789 is not adequate, it should specify corresponding object
+ parameters, not same typed object parameters.  */
+  else if (!object_parms_correspond (c1, c2))
+return false;
+  else
 {
-  /* Ignore 'this' when comparing the parameters of a static member
-function with those of a non-static one.  */
-  parms1 = skip_parms (fn1, parms1);
-  parms2 = 

Re: [PATCH RFC] codingconventions: add lambda guidelines

[Marek Polacek]

On Thu, Jan 11, 2024 at 04:33:10PM -0500, Jason Merrill wrote:
> Now in patch form!
> 
> Any further comments?

It looks good to me, but it doesn't say if we want to put a space
after } and before () if we're invoking the lambda (I suppose we
want that space).  As in

  ... = [&] (tree arg) { ... } ();
 

Thanks,

> ---
>  htdocs/codingconventions.html | 60 +++
>  1 file changed, 60 insertions(+)
> 
> diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
> index f5a356a8..2bbf6670 100644
> --- a/htdocs/codingconventions.html
> +++ b/htdocs/codingconventions.html
> @@ -76,6 +76,7 @@ the conventions separately from any other changes to the 
> code.
>  Templates
>  Extern "C"
>  Namespaces
> +Lambdas
>  
>  
>  
> @@ -1488,6 +1489,65 @@ with a right brace, optional closing comment, and a 
> new line.
>  Definitions within the body of a namespace are not indented.
>  
>  
> +Lambdas
> +
> +There should be a space between the lambda-introducer and the parameter
> +  list, if any.
> +Lambdas that do not outlive their enclosing function should
> +  typically use [&] implicit capture.
> +
> +auto l = [&] (tree arg) { ... };
> +
> +
> +If a lambda does not fit on one line, the left brace should be indented 
> like
> +the body of a for-statement.
> +
> +auto l = [&] (tree arg)
> +  {
> +...
> +  };
> +
> +
> +This also applies if the lambda is the last argument, and only lambda
> +argument, to a function.
> +
> +std::for_each (start, end, [&] (tree arg)
> +  {
> +...
> +  });
> +
> +
> +To get the above behavior from
> +https://www.gnu.org/software/emacs/manual/html_mono/ccmode.html;>
> +  GNU Emacs CC Mode, you can add this to your .emacs:
> +
> +(defun lambda-offset (elem)
> +  "If the opening brace of a lambda is on a new line, indent it one step."
> +  (if (assq 'inline-open c-syntactic-context) '+ 0))
> +(add-hook 'c++-mode-hook
> +   '(lambda () (c-set-offset 'inlambda 'lambda-offset)))
> +
> +
> +If the multi-line lambda is not the last argument, or there are multiple
> +lambda arguments, you are encouraged to make them local variables, as
> +the l examples above.  If you do pass them directly, they should
> +be indented like other parameters.
> +
> +my_algo (start, end,
> +  [&] (tree arg)
> +   {
> + thing one...
> +   },
> +  [&] (tree arg)
> +   {
> + thing two...
> +   });
> +
> +
> +See also the
> +   href="https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#Indentation_of_lambdas_as_parameters;>
> +GDB coding standards.
> +
>  Python Language Conventions
>  
>  Python scripts should follow  href="https://peps.python.org/pep-0008/;>PEP 8 – Style Guide for Python 
> Code
> 
> base-commit: 62250c79a7483076f1b2b11496e4a1123c9df6a0
> -- 
> 2.39.3
> 

Marek

Re: [PATCH] Add support for function attributes and variable attributes

[Guillaume Gomez]

Hi David,

> The above looks correct, but the patch adds the entrypoint descriptions
> to topics/types.rst, which seems like the wrong place.  The function-
> related ones should be in topics/functions.rst in the "Functions"
> section and the lvalue/variable one in topics/expression.rst after the
> "Global variables" section.

Ah indeed. Mix-up on my end. Fixed it.

> test-restrict.c is a pre-existing testcase, so please don't delete its
> entry.

Ah indeed, I went too quickly and thought it was a test I renamed...

> BTW, the ChangeLog entry mentions adding test-restrict.c, but the patch
> doesn't add it, so that part of the proposed ChangeLog is wrong.
>
> Does the patch pass ./contrib/gcc-changelog/git_check_commit.py ?

I messed up a bit, fixed it thanks to you. I didn't run the script in my last
update but just did:

```
$ contrib/gcc-changelog/git_check_commit.py $(git log -1 --format=%h)
Checking 3849ee2eadf0eeec2b0080a5142ced00be96a60d: OK
```

> Otherwise, looks good, assuming that the patch has been tested with the
> full jit testsuite.

When rebasing on upstream yesterday I discovered that two tests
were not working anymore. For the first one, it was simply because of
the changes in `dummy-frontend.cc`. For the second one
(test-noinline-attribute.c), it was because the rules for inlining changed
since we wrote this patch apparently (our fork is very late). Antoni discovered
that we could just add a call to `asm` to prevent this from happening so I
added it.

So yes, all jit tests are passing as expected. :)

Le jeu. 11 janv. 2024 à 19:46, David Malcolm  a écrit :
>
> On Thu, 2024-01-11 at 01:00 +0100, Guillaume Gomez wrote:
> > Hi David.
> >
> > Thanks for the review!
> >
> > > > +.. function::  void\
> > > > +   gcc_jit_lvalue_add_string_attribute
> > > > (gcc_jit_lvalue *variable,
> > > > +enum
> > > > gcc_jit_fn_attribute attribute,
> > >
> > > ^^
> > >
> > > This got out of sync with the declaration in the header file; it
> > > should
> > > be enum gcc_jit_variable_attribute attribute
> >
> > Indeed, good catch!
> >
> > > I took a brief look through the handler functions and with the
> > > above
> > > caveat I didn't see anything obviously wrong.  I'm going to assume
> > > this
> > > code is OK given that presumably you've been testing it within
> > > rustc,
> > > right?
> >
> > Both in rustc and in the JIT tests we added.
> >
> > [..snip...]
> >
> > I added all the missing `RETURN_IF_FAIL` you mentioned. None of the
> > arguments should be `NULL` so it was a mistake not to check it.
> >
> > [..snip...]
> >
> > I removed the tests comments as you mentioned.
> >
> > > Please update jit.dg/all-non-failing-tests.h for the new tests;
> > > it's
> > > meant to list all of the (non failing) tests alphabetically.
> >
> > It's not always correctly sorted. Might be worth sending a patch
> > after this
> > one gets merged to fix that.
> >
> > > I *think* all of the new tests aren't suitable to be run as part of
> > > a
> > > shared context (e.g. due to touching the optimization level or
> > > examining generated asm), so they should be listed in that header
> > > with
> > > comments explaining why.
> >
> > I added them with a comment on top of each of them.
> >
> > I joined the new patch version.
> >
> > Thanks again for the review!
>
> Thanks for the updated patch.  I noticed a few minor issues:
>
> > diff --git a/gcc/jit/docs/topics/types.rst b/gcc/jit/docs/topics/types.rst
> > index bb51f037b7e..b1aedc03787 100644
> > --- a/gcc/jit/docs/topics/types.rst
> > +++ b/gcc/jit/docs/topics/types.rst
> > @@ -553,3 +553,80 @@ Reflection API
> > .. code-block:: c
> >
> >#ifdef LIBGCCJIT_HAVE_gcc_jit_type_get_restrict
> > +
> > +.. function::  void\
> > +   gcc_jit_function_add_attribute (gcc_jit_function *func,
> > +   enum gcc_jit_fn_attribute 
> > attribute)
> > +
> > + Add an attribute ``attribute`` to a function ``func``.
> > +
> > + This is equivalent to the following code:
> > +
> > +  .. code-block:: c
> > +
> > +__attribute__((always_inline))
> > +
> > +   This entrypoint was added in :ref:`LIBGCCJIT_ABI_26`; you can test for
> > +   its presence using
> > +
> > +   .. code-block:: c
> > +
> > +  #ifdef LIBGCCJIT_HAVE_ATTRIBUTES
> > +
> > +.. function::  void\
> > +   gcc_jit_function_add_string_attribute (gcc_jit_function 
> > *func,
> > +  enum 
> > gcc_jit_fn_attribute attribute,
> > +  const char *value)
> > +
> > + Add a string attribute ``attribute`` with value ``value`` to a 
> > function
> > + ``func``.
> > +
> > + This is equivalent to the following code:
> > +
> > +  .. code-block:: c
> > +
> > +__attribute__ ((alias ("xxx")))
> > +
> > +   This entrypoint was added in :ref:`LIBGCCJIT_ABI_26`; you can test for
> > 

[PATCH RFC] codingconventions: add lambda guidelines

[Jason Merrill]

Now in patch form!

Any further comments?

---
 htdocs/codingconventions.html | 60 +++
 1 file changed, 60 insertions(+)

diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index f5a356a8..2bbf6670 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -76,6 +76,7 @@ the conventions separately from any other changes to the 
code.
 Templates
 Extern "C"
 Namespaces
+Lambdas
 
 
 
@@ -1488,6 +1489,65 @@ with a right brace, optional closing comment, and a new 
line.
 Definitions within the body of a namespace are not indented.
 
 
+Lambdas
+
+There should be a space between the lambda-introducer and the parameter
+  list, if any.
+Lambdas that do not outlive their enclosing function should
+  typically use [&] implicit capture.
+
+auto l = [&] (tree arg) { ... };
+
+
+If a lambda does not fit on one line, the left brace should be indented like
+the body of a for-statement.
+
+auto l = [&] (tree arg)
+  {
+...
+  };
+
+
+This also applies if the lambda is the last argument, and only lambda
+argument, to a function.
+
+std::for_each (start, end, [&] (tree arg)
+  {
+...
+  });
+
+
+To get the above behavior from
+https://www.gnu.org/software/emacs/manual/html_mono/ccmode.html;>
+  GNU Emacs CC Mode, you can add this to your .emacs:
+
+(defun lambda-offset (elem)
+  "If the opening brace of a lambda is on a new line, indent it one step."
+  (if (assq 'inline-open c-syntactic-context) '+ 0))
+(add-hook 'c++-mode-hook
+ '(lambda () (c-set-offset 'inlambda 'lambda-offset)))
+
+
+If the multi-line lambda is not the last argument, or there are multiple
+lambda arguments, you are encouraged to make them local variables, as
+the l examples above.  If you do pass them directly, they should
+be indented like other parameters.
+
+my_algo (start, end,
+[&] (tree arg)
+   {
+ thing one...
+   },
+[&] (tree arg)
+   {
+ thing two...
+   });
+
+
+See also the
+  https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#Indentation_of_lambdas_as_parameters;>
+GDB coding standards.
+
 Python Language Conventions
 
 Python scripts should follow https://peps.python.org/pep-0008/;>PEP 8 – Style Guide for Python Code

base-commit: 62250c79a7483076f1b2b11496e4a1123c9df6a0
-- 
2.39.3

[committed] libstdc++: Fix spelling mistake in new doc addition

[Jonathan Wakely]

And a follow-up to fix the obvious typo in the first word.

Pushed to trunk and gcc-13.

-- >8 --

libstdc++-v3/ChangeLog:

* doc/xml/manual/evolution.xml: Fix spelling.
* doc/html/manual/api.html: Regenerate.
---
 libstdc++-v3/doc/html/manual/api.html | 6 --
 libstdc++-v3/doc/xml/manual/evolution.xml | 6 --
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/doc/xml/manual/evolution.xml 
b/libstdc++-v3/doc/xml/manual/evolution.xml
index 63666b7b24c..a375ae14b83 100644
--- a/libstdc++-v3/doc/xml/manual/evolution.xml
+++ b/libstdc++-v3/doc/xml/manual/evolution.xml
@@ -1107,8 +1107,10 @@ to provide the symbols for the experimental C++ 
Contracts support.
 
 13.3
 
-Symols for the Filesystem TS and C++23 
stacktrace
-header were added to the static library 
libstdc++exp.a.
+
+Symbols for the Filesystem TS and C++23 stacktrace
+header were added to the static library libstdc++exp.a.
+
 
 
 
-- 
2.43.0

Re: [PATCH V2] RISC-V: Adjust scalar_to_vec cost accurately

[Robin Dapp]

> 1. This patch set scalar_to_vec cost as 2 instead 1 since scalar move
>instruction is slightly more costly than normal rvv instructions (e.g. 
> vadd.vv).

We can go with 2 or 3 (if needed) for now but should later
really incorporate reg-move costs in this IMHO.  Just like e.g.

static const struct cpu_regmove_cost cortexa57_regmove_cost =
{
  1, /* GP2GP  */
  /* Avoid the use of slow int<->fp moves for spilling by setting
 their cost higher than memmov_cost.  */
  5, /* GP2FP  */
  ...
};

we can add V2FP, V2GP and the reverse.  Then add those to
scalar_to_vec (later vec_to_scalar as well) in adjust_stmt_cost
according to the mode.

> 2. Adjust scalar_to_vec cost accurately according to the splat value, for 
> example,
>a value like 32872, needs 2 more scalar instructions:
>so the cost = 2 (scalar instructions) + 2 (scalar move).

>We adjust the cost like this since it doesn need such many instructions in 
> vectorized codes,
>wheras they are not needed in scalar codes.

I'm afraid the issue I mentioned (we don't count the constant
synthesis for scalar but would for vector with the change) is
still present.
Even if it does not cause any regressions or problems now it
certainly might in the future, especially with complex constants.
Basically we would not vectorize something containing several
synthesized constants (like popcount) anymore.
Therefore I would advise against it even though the given
example cannot be "solved" unconditionally then.

Regards
 Robin

[PATCH v2] c++: side effect in nullptr_t conversion fix

[Dmitry Drozodv]

Hello,

You are absolutely right, we can't throw all side-effects away.
Example:
```c++
auto __attribute__ ((noinline)) bar()
{
   volatile int* b = (int *)0xff;
   *b = 10;
   volatile auto n = nullptr;
   return n;   // Problem (1)
}

int* foo_2()
{
  volatile auto a = bar();  // Problem (2)
  return a;
}
```
There are 2 additional places, where std::nullptr_t causes side effects.
(1)
nullptr_t identical conversion produces:
mov QWORD PTR [rsp-8], 0
mov rax, QWORD PTR [rsp-8] // load n
ret

(2)
Initialization by not constant expression:
callbar()
mov QWORD PTR [rsp+8], rax
mov rax, QWORD PTR [rsp+8]
xor eax, eax


---

diff --git a/gcc/cp/cvt.cc b/gcc/cp/cvt.cc
index cbed847b343..24c1ceb4404 100644
--- a/gcc/cp/cvt.cc
+++ b/gcc/cp/cvt.cc
@@ -218,8 +218,11 @@ cp_convert_to_pointer (tree type, tree expr, bool
dofold,
  ? build_int_cst_type (type, -1)
  : build_int_cst (type, 0));

-  return (TREE_SIDE_EFFECTS (expr)
- ? build2 (COMPOUND_EXPR, type, expr, val) : val);
+  /* C++ [conv.lval]p3:
+If T is cv std::nullptr_t, the result is a null pointer constant.
*/
+  return ((TREE_SIDE_EFFECTS (expr) && !CONVERT_EXPR_P (expr))
+  ? build2 (COMPOUND_EXPR, type, expr, val)
+  : val);
 }
   else if (TYPE_PTRMEM_P (type) && INTEGRAL_CODE_P (form))
 {
@@ -743,8 +746,9 @@ ocp_convert (tree type, tree expr, int convtype, int
flags,
 {
   if (complain & tf_warning)
maybe_warn_zero_as_null_pointer_constant (e, loc);
-
-  if (!TREE_SIDE_EFFECTS (e))
+  /* C++ [conv.lval]p3:
+Convert expr from nullptr to nullptr doesn't have side effect. */
+  if (!TREE_SIDE_EFFECTS (e) || CONVERT_EXPR_P (expr))
return nullptr_node;
 }

diff --git a/gcc/cp/typeck2.cc b/gcc/cp/typeck2.cc
index ac0fefa24f2..9c7866d319f 100644
--- a/gcc/cp/typeck2.cc
+++ b/gcc/cp/typeck2.cc
@@ -770,6 +770,15 @@ split_nonconstant_init (tree dest, tree init)
   && array_of_runtime_bound_p (TREE_TYPE (dest)))
 code = build_vec_init (dest, NULL_TREE, init, /*value-init*/false,
   /*from array*/1, tf_warning_or_error);
+  else if (TREE_CODE (TREE_TYPE(init)) == NULLPTR_TYPE)
+{
+  /* C++ [conv.lval]p3:
+If T is cv std::nullptr_t, the result is a null pointer constant.
*/
+  tree val = build_int_cst(TREE_TYPE(dest), 0);
+  tree ie = cp_build_init_expr(dest, val);
+  // remain expr with side effect
+  code = add_stmt_to_compound(init, ie);
+}
   else
 code = cp_build_init_expr (dest, init);

[PATCH] libstdc++: Fix std::runtime_format deviations from the spec [PR113320]

[Jonathan Wakely]

Tested x86_64-linux. Does this look better now?

It also fixes PR113320 that got reported.

-- >8 --

I seem to have implemented this feature based on the P2918R0 revision,
not the final P2918R2 one that was approved for C++26. This commit fixes
it.

The runtime-format-string type should not have a publicly accessible
data member, so add a constructor and make it a friend of
basic_format_string. It should also be non-copyable, so that it can only
be constructed from a prvalue via temporary materialization. Change the
basic_format_string constructor parameter to pass by value. Also add
noexcept to the constructors and runtime_format generator functions.

libstdc++-v3/ChangeLog:

PR libstdc++/113320
* include/std/format (__format::_Runtime_format_string): Add
constructor and disable copy operations.
(basic_format_string(_Runtime_format_string)): Add noexcept and
take parameter by value not rvalue reference.
(runtime_format): Add noexcept.
* testsuite/std/format/runtime_format.cc: Check noexcept. Check
that construction is only possible from prvalues, not xvalues.
---
 libstdc++-v3/include/std/format   | 37 ---
 .../testsuite/std/format/runtime_format.cc| 11 ++
 2 files changed, 35 insertions(+), 13 deletions(-)

diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/include/std/format
index b3b5a0bbdbc..540f8b805f8 100644
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -70,6 +70,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // [format.context], class template basic_format_context
   template class basic_format_context;
 
+  // [format.fmt.string], class template basic_format_string
+  template struct basic_format_string;
+
 /// @cond undocumented
 namespace __format
 {
@@ -83,7 +86,20 @@ namespace __format
 using __format_context = basic_format_context<_Sink_iter<_CharT>, _CharT>;
 
   template
-struct _Runtime_format_string { basic_string_view<_CharT> _M_str; };
+struct _Runtime_format_string
+{
+  [[__gnu__::__always_inline__]]
+  _Runtime_format_string(basic_string_view<_CharT> __s) noexcept
+  : _M_str(__s) { }
+
+  _Runtime_format_string(const _Runtime_format_string&) = delete;
+  void operator=(const _Runtime_format_string&) = delete;
+
+private:
+  basic_string_view<_CharT> _M_str;
+
+  template friend struct std::basic_format_string;
+};
 } // namespace __format
 /// @endcond
 
@@ -104,8 +120,6 @@ namespace __format
   template
 class basic_format_arg;
 
-  // [format.fmt.string], class template basic_format_string
-
   /** A compile-time checked format string for the specified argument types.
*
* @since C++23 but available as an extension in C++20.
@@ -119,7 +133,7 @@ namespace __format
basic_format_string(const _Tp& __s);
 
   [[__gnu__::__always_inline__]]
-  basic_format_string(__format::_Runtime_format_string<_CharT>&& __s)
+  basic_format_string(__format::_Runtime_format_string<_CharT> __s) 
noexcept
   : _M_str(__s._M_str)
   { }
 
@@ -144,14 +158,14 @@ namespace __format
 #if __cplusplus > 202302L
   [[__gnu__::__always_inline__]]
   inline __format::_Runtime_format_string
-  runtime_format(string_view __fmt)
-  { return {__fmt}; }
+  runtime_format(string_view __fmt) noexcept
+  { return __fmt; }
 
 #ifdef _GLIBCXX_USE_WCHAR_T
   [[__gnu__::__always_inline__]]
   inline __format::_Runtime_format_string
-  runtime_format(wstring_view __fmt)
-  { return {__fmt}; }
+  runtime_format(wstring_view __fmt) noexcept
+  { return __fmt; }
 #endif
 #endif // C++26
 
@@ -3652,12 +3666,9 @@ namespace __format
   friend std::basic_format_args<_Context>;
 
   template
-   friend auto
+   friend auto std::
 #if _GLIBCXX_INLINE_VERSION
-   // Needed for PR c++/59526
-   std::__8::
-#else
-   std::
+   __8:: // Needed for PR c++/59256
 #endif
make_format_args(_Argz&...) noexcept;
 
diff --git a/libstdc++-v3/testsuite/std/format/runtime_format.cc 
b/libstdc++-v3/testsuite/std/format/runtime_format.cc
index 174334c7676..f2bfa5b434d 100644
--- a/libstdc++-v3/testsuite/std/format/runtime_format.cc
+++ b/libstdc++-v3/testsuite/std/format/runtime_format.cc
@@ -29,6 +29,17 @@ test_internal_api()
   VERIFY( s == "0x315" );
 }
 
+static_assert( noexcept(std::format_string<>(std::runtime_format(""))) );
+static_assert( noexcept(std::wformat_string<>(std::runtime_format(L""))) );
+static_assert( noexcept(std::format_string(std::runtime_format(""))) );
+static_assert( noexcept(std::wformat_string(std::runtime_format(L""))) );
+// A format string can be constructed from the result of std::runtime_format
+// using copy elision, but cannot be constructed from an xvalue.
+static_assert( !std::is_constructible_v,
+   decltype(std::runtime_format(""))&&> );
+static_assert( !std::is_constructible_v,
+  

[committed] libstdc++: Document addition of libstdc++exp.a

[Jonathan Wakely]

Pushed to trunk. I'll backport to gcc-13 too.

-- >8 --

The API Evolution section of the manual should mention when the
libstdc++exp.a library was added.

libstdc++-v3/ChangeLog:

* doc/xml/manual/evolution.xml: Document addition of
libstdc++exp.a.
* doc/html/*: Regenerate.
---
 libstdc++-v3/doc/html/index.html   |  6 +++---
 libstdc++-v3/doc/html/manual/api.html  |  4 +++-
 libstdc++-v3/doc/html/manual/appendix.html |  2 +-
 libstdc++-v3/doc/html/manual/appendix_porting.html |  2 +-
 libstdc++-v3/doc/html/manual/index.html|  2 +-
 libstdc++-v3/doc/xml/manual/evolution.xml  | 10 ++
 6 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/libstdc++-v3/doc/xml/manual/evolution.xml 
b/libstdc++-v3/doc/xml/manual/evolution.xml
index db70f24f2f9..63666b7b24c 100644
--- a/libstdc++-v3/doc/xml/manual/evolution.xml
+++ b/libstdc++-v3/doc/xml/manual/evolution.xml
@@ -1100,6 +1100,16 @@ Tunables glibcxx.eh_pool.obj_count 
and
 glibcxx.eh_pool.obj_size were added.
 
 
+Static library libstdc++exp.a was added
+to provide the symbols for the experimental C++ Contracts support.
+
+
+
+13.3
+
+Symols for the Filesystem TS and C++23 
stacktrace
+header were added to the static library 
libstdc++exp.a.
+
 
 
 14
-- 
2.43.0

Re: [PATCH] libstdc++: std/ranges - Remove a duplicate define directive

[Jonathan Wakely]

On Wed, 10 Jan 2024 at 23:31, Jonathan Wakely  wrote:
>
> On Wed, 10 Jan 2024 at 21:28, Michael Levine (BLOOMBERG/ 120 PARK)
>  wrote:
> >
> > From a67cfd07ce27a62f764b381268502acb68b6bad9 Mon Sep 17 00:00:00 2001
> > From: Michael Levine 
> > Date: Wed, 10 Jan 2024 15:48:46 -0500
> > Subject: [PATCH 1/2] Removed a duplicate define directive for
> > __glibcxx_want_ranges_iota
> >
> > Signed-off-by: Michael Levine 
> > ---
> > libstdc++-v3/include/std/ranges | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/libstdc++-v3/include/std/ranges 
> > b/libstdc++-v3/include/std/ranges
> > index 81a857502e3..ae857f8c7fc 100644
> > --- a/libstdc++-v3/include/std/ranges
> > +++ b/libstdc++-v3/include/std/ranges
> > @@ -59,7 +59,6 @@
> > #define __glibcxx_want_ranges_chunk_by
> > #define __glibcxx_want_ranges_enumerate
> > #define __glibcxx_want_ranges_iota
> > -#define __glibcxx_want_ranges_iota
> > #define __glibcxx_want_ranges_join_with
> > #define __glibcxx_want_ranges_repeat
> > #define __glibcxx_want_ranges_slide
>
> Thanks for the patch, this looks obviously correct.
>
> Please note that all patches need to go to the gcc-patches list (as
> well as the more specific list, like this one, so e.g. add both to the
> email's To: header, or CC one of them).
>
> Also please don't touch the ChangeLog file in patches. We have been
> auto-generating the ChangeLog files nightly for some years now, so you
> should not edit them manually (and including it in the patch just
> means the patch won't apply cleanly after the next time the file is
> regen'd).
>
> But I can take care of that and apply the patch, there's no need for a
> corrected patch. Thanks again for the contribution.

Pushed to trunk now, thanks again.

[PATCH] OpenMP 5.1: WIP delimited (begin/end) 'declare variant' support

[Julian Brown]

This WIP patch adds preliminary and very lightly-tested support for
the "begin declare variant" and "end declare variant" directives of
OpenMP 5.1.  I am posting it now for logistical reasons, rather than
because I believe it is immediately ready for review.

Some notes follow on the implementation as-is and on my understanding
of what is still to be done.

I have tried to build on top of the existing support for "declare variant"
as far as possible. I also borrowed ideas and some of the implementation
from function versioning support (but see below regarding template
handling).

There are mostly four aspects to the implementation:

1) Inside begin/end "declare variant" blocks, you may define specialised
   versions of functions with the same name as some base function in the
   main part of the program.  The specialised functions must have some way
   of coexisting with other functions with the same name and prototype.

2) Begin/end "declare variant" blocks may be nested, and the OpenMP
   context is formed from a combination of the outer and inner levels
   (in some way that depends on the trait sets, etc. in use).

3) The same-named "declare variant" functions must be resolved to the
   right implementation in some given OpenMP context (including in parts
   of the program not enclosed by OpenMP directives).

4) The same-named, specialized versions of functions must have their
   names mangled by adding a context-specific suffix string.

Taking these in turn:

1. "declare variant" overloading


In C++, this looks somewhat like function overloading, and that is also
how the existing support for function multiversioning is implemented
(https://gcc.gnu.org/wiki/FunctionMultiVersioning).  Unfortunately this
doesn't work with templates at present, so the attached patch has to
do a little more in that regard.  This works in simple cases, but I am
not entirely convinced it is a complete solution yet -- in particular
pt.cc:spec_hasher::equal always considers two functions with the "omp
declare variant overload" attribute to be unequal. Should it be comparing
the context?

Similarly, I am not entirely convinced the logic in call.cc:joust is
correct, though it seems to work for what I've tried it with so far.

In C, which is so-far unimplemented, this scheme will not work so
smoothly.  An alternative might be to mangle function names earlier,
or perhaps mangle with some temporary name ("foo$1", "foo$2", ...) early
in compilation then re-mangle properly later (such functions would need
to be considered "the same" in some places, but not in others. Details
TBD of course).

2. Context merging
--

Contexts are merged eagerly as "begin/end declare variant" directives
are being parsed: hence, a top-level directive will be merged with its
immediate child, and the grandchild will be merged with the combined
"child+parent" context.  So, a function defined at some given point in
the nesting hierarchy will decorated with a copy of the innermost context.

Function decls encountered within the block (or nested block, ...) are
annotated with a new attribute, "omp declare variant overload".  This is
similar to the existing "omp declare variant variant" attribute, but:

  - It records the entire context (as specified on the enclosing "begin
declare variant" block(s)), not just the "contruct" set.

  - It is set immediately for each function within a "declare variant"
block (see below).

Some aspects of context merging need verification against the standard
-- it's not always completely obvious how trait properties should be
combined.

3. Function resolution
--

The current patch tries to adjust function attributes so they are
similar to those used by the existing non-delimited "declare variant"
support. For that, if we have a fragment like this:

  T foo_x86 (T v)
  { ... }

  [...]

  #pragma omp declare variant (foo_x86) match(device={arch(x86)})
  #pragma omp declare variant (foo_powerpc) match(device={arch(powerpc)})
  #pragma omp declare variant (foo_aarch64) match(device={arch(aarch64)})
  T foo (T v)
  {
return v + 1;
  }

The function "foo" is annotated with one "omp declare variant base"
attribute for each named/specialized function version.  The VALUE
field of the attribute is a tuple specifying the *name* of the specialized
function, the context, and a location.  This name is then looked up
in decl.cc:omp_declare_variant_finalize_one, a function call to the
specialized function is synthesized (to mark that function as requiring
template instantiation, amongst other things?), and a "omp declare variant
variant" attribute with *just the construct part* of the context selector
is added to the specialized function.

For the new "overload"-type delimited "declare variant" functions, this
works backwards.  We know the full context for the variant function and
we already have the FUNCTION_DECL for it (so we don't need to look up
the name).

So, 

[r14-7139 Regression] FAIL: gcc.dg/pr15784-1.c scan-tree-dump-times gimple "ABS_EXPR" 0 on Linux/x86_64

[haochen.jiang]

On Linux/x86_64,

897b95a12b7fe549ec2cb8ef3a3f0e4fbabf9737 is the first bad commit
commit 897b95a12b7fe549ec2cb8ef3a3f0e4fbabf9737
Author: Richard Biener 
Date:   Thu Jan 11 12:02:43 2024 +0100

tree-optimization/113126 - vector extension compare optimization

caused

FAIL: gcc.dg/pr15784-1.c scan-tree-dump-times gimple "ABS_EXPR" 0

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-7139/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="dg.exp=gcc.dg/pr15784-1.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr15784-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr15784-1.c 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr15784-1.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at haochen dot jiang at intel.com.)
(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] libgccjit: Add ability to get CPU features

[Antoni Boucher]

Here's an updated patch to include the change from this PATCH:
https://gcc.gnu.org/pipermail/jit/2023q4/001763.html

On Thu, 2023-11-09 at 18:04 -0500, David Malcolm wrote:
> On Thu, 2023-11-09 at 17:27 -0500, Antoni Boucher wrote:
> > Hi.
> > This patch adds support for getting the CPU features in libgccjit
> > (bug
> > 112466)
> > 
> > There's a TODO in the test:
> > I'm not sure how to test that gcc_jit_target_info_arch returns the
> > correct value since it is dependant on the CPU.
> > Any idea on how to improve this?
> > 
> > Also, I created a CStringHash to be able to have a
> > std::unordered_set. Is there any built-in way of
> > doing
> > this?
> 
> Thanks for the patch.
> 
> Some high-level questions:
> 
> Is this specifically about detecting capabilities of the host that
> libgccjit is currently running on? or how the target was configured
> when libgccjit was built?
> 
> One of the benefits of libgccjit is that, in theory, we support all
> of
> the targets that GCC already supports.  Does this patch change that,
> or
> is this more about giving client code the ability to determine
> capabilities of the specific host being compiled for?
> 
> I'm nervous about having per-target jit code.  Presumably there's a
> reason that we can't reuse existing target logic here - can you
> please
> describe what the problem is.  I see that the ChangeLog has:
> 
> > * config/i386/i386-jit.cc: New file.
> 
> where i386-jit.cc has almost 200 lines of nontrivial code.  Where did
> this come from?  Did you base it on existing code in our source tree,
> making modifications to fit the new internal API, or did you write it
> from scratch?  In either case, how onerous would this be for other
> targets?
> 
> I'm not at expert at target hooks (or at the i386 backend), so if we
> do
> go with this approach I'd want someone else to review those parts of
> the patch.
> 
> Have you verified that GCC builds with this patch with jit *not*
> enabled in the enabled languages?
> 
> [...snip...]
> 
> A nitpick:
> 
> > +.. function:: const char * \
> > +  gcc_jit_target_info_arch (gcc_jit_target_info *info)
> > +
> > +   Get the architecture of the currently running CPU.
> 
> What does this string look like?
> How long does the pointer remain valid?
> 
> Thanks again; hope the above makes sense
> Dave
> 

From b1e8df6da7c7876e5cb5c6fde60f0fff854888e3 Mon Sep 17 00:00:00 2001
From: Antoni Boucher 
Date: Mon, 26 Jun 2023 18:29:15 -0400
Subject: [PATCH] libgccjit: Add ability to get CPU features

gcc/ChangeLog:
	PR jit/112466
	* Makefile.in (tm_jit_file_list, tm_jit_include_list, TM_JIT_H,
	JIT_TARGET_DEF, JIT_TARGET_H, JIT_TARGET_OBJS): New variables.
	(tm_jit.h, cs-tm_jit.h, jit/jit-target-hooks-def.h,
	s-jit-target-hooks-def-h, default-jit.o): New rules.
	(s-tm-texi): Also check timestamp on jit-target.def.
	(generated_files): Add TM_JIT_H and jit/jit-target-hooks-def.h.
	(build/genhooks.o): Also depend on JIT_TARGET_DEF.
	* config.gcc (tm_jit_file, jit_target_objs, target_has_targetjitm):
	New variables.
	* config/i386/t-i386 (i386-jit.o): New rule.
	* config/t-linux (linux-jit.o): New rule.
	* configure: Regenerate.
	* configure.ac (tm_jit_file_list, tm_jit_include_list,
	jit_target_objs): Add substitutes.
	* doc/tm.texi: Regenerate.
	* doc/tm.texi.in (targetjitm): Document.
	(target_has_targetjitm): Document.
	* genhooks.cc: Include jit/jit-target.def.
	* config/default-jit.cc: New file.
	* config/i386/i386-jit.cc: New file.
	* config/i386/i386-jit.h: New file.
	* config/linux-jit.cc: New file.

gcc/jit/ChangeLog:
	PR jit/112466
	* Make-lang.in (JIT_OBJS): New variable.
	* jit-playback.cc (replay): Include jit-target.h and initialize
	target.
	* jit-playback.h (class get_target_info): New class.
	* jit-recording.cc (recording::context::get_target_info): New
	method.
	* jit-recording.h (recording::context::get_target_info): New
	method.
	* libgccjit.cc: Include jit-target.h.
	(struct gcc_jit_target_info): New struct.
	(gcc_jit_context_get_target_info, gcc_jit_target_info_release,
	gcc_jit_target_info_cpu_supports, gcc_jit_target_info_arch,
	gcc_jit_target_info_supports_128bit_int): New functions.
	* libgccjit.h (gcc_jit_context_get_target_info,
	gcc_jit_target_info_release, gcc_jit_target_info_cpu_supports,
	gcc_jit_target_info_arch, gcc_jit_target_info_supports_128bit_int):
	New functions.
	* libgccjit.map (LIBGCCJIT_ABI_26): New ABI tag.
	* docs/topics/compilation.rst: Add documentation for the
	functions gcc_jit_context_get_target_info, gcc_jit_target_info_release,
	gcc_jit_target_info_cpu_supports, gcc_jit_target_info_arch,
	gcc_jit_target_info_supports_128bit_int.
	* docs/topics/compatibility.rst (LIBGCCJIT_ABI_26): New ABI tag.
	* jit-target-def.h: New file.
	* jit-target.cc: New file.
	* jit-target.def: New file.
	* jit-target.h: New file.

gcc/testsuite/ChangeLog:
	PR jit/112466
	* jit.dg/all-non-failing-tests.h: Mention
	test-target-info.c.
	* jit.dg/test-target-info.c: New test.

Signed-off-by: Martin 

Re: [PATCH] Add support for function attributes and variable attributes

[David Malcolm]

On Thu, 2024-01-11 at 01:00 +0100, Guillaume Gomez wrote:
> Hi David.
> 
> Thanks for the review!
> 
> > > +.. function::  void\
> > > +   gcc_jit_lvalue_add_string_attribute
> > > (gcc_jit_lvalue *variable,
> > > +    enum
> > > gcc_jit_fn_attribute attribute,
> >   
> > ^^
> > 
> > This got out of sync with the declaration in the header file; it
> > should
> > be enum gcc_jit_variable_attribute attribute
> 
> Indeed, good catch!
> 
> > I took a brief look through the handler functions and with the
> > above
> > caveat I didn't see anything obviously wrong.  I'm going to assume
> > this
> > code is OK given that presumably you've been testing it within
> > rustc,
> > right?
> 
> Both in rustc and in the JIT tests we added.
> 
> [..snip...]
> 
> I added all the missing `RETURN_IF_FAIL` you mentioned. None of the
> arguments should be `NULL` so it was a mistake not to check it.
> 
> [..snip...]
> 
> I removed the tests comments as you mentioned.
> 
> > Please update jit.dg/all-non-failing-tests.h for the new tests;
> > it's
> > meant to list all of the (non failing) tests alphabetically.
> 
> It's not always correctly sorted. Might be worth sending a patch
> after this
> one gets merged to fix that.
> 
> > I *think* all of the new tests aren't suitable to be run as part of
> > a
> > shared context (e.g. due to touching the optimization level or
> > examining generated asm), so they should be listed in that header
> > with
> > comments explaining why.
> 
> I added them with a comment on top of each of them.
> 
> I joined the new patch version.
> 
> Thanks again for the review!

Thanks for the updated patch.  I noticed a few minor issues:

> diff --git a/gcc/jit/docs/topics/types.rst b/gcc/jit/docs/topics/types.rst
> index bb51f037b7e..b1aedc03787 100644
> --- a/gcc/jit/docs/topics/types.rst
> +++ b/gcc/jit/docs/topics/types.rst
> @@ -553,3 +553,80 @@ Reflection API
> .. code-block:: c
>  
>#ifdef LIBGCCJIT_HAVE_gcc_jit_type_get_restrict
> +
> +.. function::  void\
> +   gcc_jit_function_add_attribute (gcc_jit_function *func,
> +   enum gcc_jit_fn_attribute 
> attribute)
> +
> + Add an attribute ``attribute`` to a function ``func``.
> +
> + This is equivalent to the following code:
> +
> +  .. code-block:: c
> +
> +__attribute__((always_inline))
> +
> +   This entrypoint was added in :ref:`LIBGCCJIT_ABI_26`; you can test for
> +   its presence using
> +
> +   .. code-block:: c
> +
> +  #ifdef LIBGCCJIT_HAVE_ATTRIBUTES
> +
> +.. function::  void\
> +   gcc_jit_function_add_string_attribute (gcc_jit_function *func,
> +  enum 
> gcc_jit_fn_attribute attribute,
> +  const char *value)
> +
> + Add a string attribute ``attribute`` with value ``value`` to a function
> + ``func``.
> +
> + This is equivalent to the following code:
> +
> +  .. code-block:: c
> +
> +__attribute__ ((alias ("xxx")))
> +
> +   This entrypoint was added in :ref:`LIBGCCJIT_ABI_26`; you can test for
> +   its presence using
> +
> +   .. code-block:: c
> +
> +  #ifdef LIBGCCJIT_HAVE_ATTRIBUTES
> +
> +.. function::  void\
> +   gcc_jit_function_add_integer_array_attribute 
> (gcc_jit_function *func,
> + enum 
> gcc_jit_fn_attribute attribute,
> + const int 
> *value,
> + size_t length)
> +
> + Add an attribute ``attribute`` with ``length`` integer values ``value`` 
> to a
> + function ``func``. The integer values must be the same as you would 
> write
> + them in a C code.
> +
> + This is equivalent to the following code:
> +
> +  .. code-block:: c
> +
> +__attribute__ ((nonnull (1, 2)))
> +
> +   This entrypoint was added in :ref:`LIBGCCJIT_ABI_26`; you can test for
> +   its presence using
> +
> +   .. code-block:: c
> +
> +  #ifdef LIBGCCJIT_HAVE_ATTRIBUTES
> +
> +.. function::  void\
> +   gcc_jit_lvalue_add_string_attribute (gcc_jit_lvalue *variable,
> +enum 
> gcc_jit_variable_attribute attribute,
> +const char *value)
> +
> + Add an attribute ``attribute`` with value ``value`` to a variable 
> ``variable``.
> +
> +   This entrypoint was added in :ref:`LIBGCCJIT_ABI_26`; you can test for
> +   its presence using
> +
> +   .. code-block:: c
> +
> +  #ifdef LIBGCCJIT_HAVE_ATTRIBUTES

The above looks correct, but the patch adds the entrypoint descriptions
to topics/types.rst, which seems like the wrong place.  The function-
related ones should be in topics/functions.rst 

Re: [PATCH] RISC-V: THEAD: Fix ICE caused by split optimizations for XTheadFMemIdx.

[Christoph Müllner]

On Thu, Jan 11, 2024 at 4:36 PM Kito Cheng  wrote:
>
> LGTM
>
> On Thu, Jan 11, 2024 at 7:23 PM Jin Ma  wrote:
> >
> > Due to the premature split optimizations for XTheadFMemIdx, GPR
> > is allocated when reload allocates registers, resulting in the
> > following insn.

LGTM.
This was most likely not detected so far, because it only affects rv32
(test focus on xthead(f)memidx was rv64).
I've rebased, retested (no regressions) and pushed.

Thanks,
Christoph

> >
> > (insn 66 21 64 5 (set (reg:DF 14 a4 [orig:136  ] [136])
> > (mem:DF (plus:SI (reg/f:SI 15 a5 [141])
> > (ashift:SI (reg/v:SI 10 a0 [orig:137 i ] [137])
> > (const_int 3 [0x3]))) [0  S8 A64])) 218 
> > {*movdf_hardfloat_rv32}
> >  (nil))
> >
> > Since we currently do not support adjustments to th_m_mir/th_m_miu,
> > which will trigger ICE. So it is recommended to place the split
> > optimizations after reload to ensure FPR when registers are allocated.
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/thead.md: Add limits for splits.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/riscv/xtheadfmemidx-medany.c: New test.
> > ---
> >  gcc/config/riscv/thead.md | 22 ---
> >  .../gcc.target/riscv/xtheadfmemidx-medany.c   | 38 +++
> >  2 files changed, 54 insertions(+), 6 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadfmemidx-medany.c
> >
> > diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md
> > index e370774d518..5c7d4beb1b6 100644
> > --- a/gcc/config/riscv/thead.md
> > +++ b/gcc/config/riscv/thead.md
> > @@ -933,14 +933,17 @@ (define_insn_and_split "*th_fmemidx_I_a"
> > && pow2p_hwi (INTVAL (operands[2]))
> > && IN_RANGE (exact_log2 (INTVAL (operands[2])), 1, 3)"
> >"#"
> > -  "&& 1"
> > +  "&& reload_completed"
> >[(set (match_dup 0)
> >  (mem:TH_M_NOEXTF (plus:X
> >(match_dup 3)
> >(ashift:X (match_dup 1) (match_dup 2)]
> >{ operands[2] = GEN_INT (exact_log2 (INTVAL (operands [2])));
> >}
> > -)
> > +  [(set_attr "move_type" "fpload")
> > +   (set_attr "mode" "")
> > +   (set_attr "type" "fmove")
> > +   (set (attr "length") (const_int 16))])
> >
> >  (define_insn_and_split "*th_fmemidx_I_c"
> >[(set (mem:TH_M_ANYF (plus:X
> > @@ -977,7 +980,7 @@ (define_insn_and_split "*th_fmemidx_US_a"
> > && CONST_INT_P (operands[3])
> > && (INTVAL (operands[3]) >> exact_log2 (INTVAL (operands[2]))) == 
> > 0x"
> >"#"
> > -  "&& 1"
> > +  "&& reload_completed"
> >[(set (match_dup 0)
> >  (mem:TH_M_NOEXTF (plus:DI
> >(match_dup 4)
> > @@ -985,7 +988,10 @@ (define_insn_and_split "*th_fmemidx_US_a"
> >{ operands[1] = gen_lowpart (SImode, operands[1]);
> >  operands[2] = GEN_INT (exact_log2 (INTVAL (operands [2])));
> >}
> > -)
> > +  [(set_attr "move_type" "fpload")
> > +   (set_attr "mode" "")
> > +   (set_attr "type" "fmove")
> > +   (set (attr "length") (const_int 16))])
> >
> >  (define_insn_and_split "*th_fmemidx_US_c"
> >[(set (mem:TH_M_ANYF (plus:DI
> > @@ -1020,12 +1026,16 @@ (define_insn_and_split "*th_fmemidx_UZ_a"
> >"TARGET_64BIT && TARGET_XTHEADMEMIDX && TARGET_XTHEADFMEMIDX
> > && (!HARD_REGISTER_NUM_P (REGNO (operands[0])) || HARDFP_REG_P (REGNO 
> > (operands[0])))"
> >"#"
> > -  "&& 1"
> > +  "&& reload_completed"
> >[(set (match_dup 0)
> >  (mem:TH_M_NOEXTF (plus:DI
> >(match_dup 2)
> >(zero_extend:DI (match_dup 1)]
> > -)
> > +  ""
> > +  [(set_attr "move_type" "fpload")
> > +   (set_attr "mode" "")
> > +   (set_attr "type" "fmove")
> > +   (set (attr "length") (const_int 16))])
> >
> >  (define_insn_and_split "*th_fmemidx_UZ_c"
> >[(set (mem:TH_M_ANYF (plus:DI
> > diff --git a/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-medany.c 
> > b/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-medany.c
> > new file mode 100644
> > index 000..0c8060d0632
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-medany.c
> > @@ -0,0 +1,38 @@
> > +/* { dg-do compile } */
> > +/* { dg-skip-if "" { *-*-* } { "-O0" "-O1" "-O3" "-Og" "-Os" "-Oz"} } */
> > +/* { dg-options "-march=rv32gc_xtheadfmemidx_xtheadfmv_xtheadmemidx 
> > -mabi=ilp32d -mcmodel=medany -O2" } */
> > +
> > +typedef union {
> > +  double v;
> > +  unsigned w;
> > +} my_t;
> > +
> > +double z;
> > +
> > +double foo (int i, int j)
> > +{
> > +
> > +  if (j)
> > +{
> > +  switch (i)
> > +   {
> > +   case 0:
> > + return 1;
> > +   case 1:
> > + return 0;
> > +   case 2:
> > + return 3.0;
> > +   }
> > +}
> > +
> > +  if (i == 1)
> > +{
> > +  my_t u;
> > +  u.v = z;
> > +  u.w = 1;
> > +  z = u.v;
> > +}
> > +  return z;
> > +}
> > +
> > +/* { dg-final { scan-assembler-times {\mth\.flrd\M} 1 } } */
> > --
> > 2.17.1
> >

[PATCH] i386: Add "Ws" constraint for symbolic address/label reference [PR105576]

[Fangrui Song]

Printing the raw symbol is useful in inline asm (e.g. in C++ to get the
mangled name).  Similar constraints are available in other targets (e.g.
"S" for aarch64/riscv, "Cs" for m68k).

There isn't a good way for x86 yet, e.g. "i" doesn't work for
PIC/-mcmodel=large.  This patch adds "Ws".  Here are possible use cases:

```
namespace ns { extern int var; }
asm (".pushsection .xxx,\"aw\"; .dc.a %0; .popsection" :: "Ws"());
asm (".reloc ., BFD_RELOC_NONE, %0" :: "Ws"());
```

gcc/ChangeLog:

PR target/105576
* config/i386/constraints.md: Define constraint "Ws".
* doc/md.texi: Document it.

gcc/testsuite/ChangeLog:

* gcc.target/i386/asm-raw-symbol.c: New testcase.

---

This obsoletes 
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642580.html
I initially tried 'z', but Uros requested that a W prefix is used.
---
 gcc/config/i386/constraints.md |  4 
 gcc/doc/md.texi|  4 
 gcc/testsuite/gcc.target/i386/asm-raw-symbol.c | 13 +
 3 files changed, 21 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/i386/asm-raw-symbol.c

diff --git a/gcc/config/i386/constraints.md b/gcc/config/i386/constraints.md
index 0c6e662df25..280e4c8e36c 100644
--- a/gcc/config/i386/constraints.md
+++ b/gcc/config/i386/constraints.md
@@ -348,6 +348,10 @@ (define_constraint "Wf"
to double word size."
   (match_operand 0 "x86_64_dwzext_immediate_operand"))
 
+(define_constraint "Ws"
+  "A symbolic reference or label reference."
+  (match_code "const,symbol_ref,label_ref"))
+
 (define_constraint "Z"
   "32-bit unsigned integer constant, or a symbolic reference known
to fit that range (for immediate operands in zero-extending x86-64
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 47a87d6ceec..b0c61925120 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -4275,6 +4275,10 @@ require non-@code{VOIDmode} immediate operands).
 128-bit integer constant where both the high and low 64-bit word
 satisfy the @code{e} constraint.
 
+@item Ws
+A symbolic reference or label reference.
+You can use the @code{%p} modifier to print the raw symbol.
+
 @item Z
 32-bit unsigned integer constant, or a symbolic reference known
 to fit that range (for immediate operands in zero-extending x86-64
diff --git a/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c 
b/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c
new file mode 100644
index 000..b7854567dd9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/asm-raw-symbol.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+
+extern int var;
+
+void
+func (void)
+{
+  __asm__ ("@ %p0" : : "Ws" (func));
+  __asm__ ("@ %p0" : : "Ws" ( + 1));
+}
+
+/* { dg-final { scan-assembler "@ func" } } */
+/* { dg-final { scan-assembler "@ var\\+4" } } */
-- 
2.43.0.275.g3460e3d667-goog

[PATCH] libstdc++: Make PSTL algorithms accept C++20 iterators [PR110512]

[Jonathan Wakely]

Tested x86_64-linux and aarch64-linux, with TBB 2020.3 only.

Reviews requested.

-- >8 --

This is a step towards implementing the C++23 change P2408R5, "Ranges
iterators as inputs to non-Ranges algorithms". C++20 random access
iterators which do not meet the C==17RandomAccessIterator requirements
will now be recognized by the PSTL algorithms.

We can also optimize the C++17 implementation by using std::__or_, and
use std::__remove_cvref_t and std::__iter_category_t for readability.
This diverges from the upstream PSTL, but since libc++ is no longer
using that upstream (so we're the only consumer of this code) I think
it's reasonable to use libstdc++ extensions in localized places like
this. Rebasing this small header on upstream should not be difficult.

libstdc++-v3/ChangeLog:

PR libstdc++/110512
* include/pstl/execution_impl.h (__are_random_access_iterators):
Recognize C++20 random access iterators, and use more efficient
implementations.
* testsuite/25_algorithms/pstl/110512.cc: New test.
---
 libstdc++-v3/include/pstl/execution_impl.h| 21 ++---
 .../testsuite/25_algorithms/pstl/110512.cc| 31 +++
 2 files changed, 47 insertions(+), 5 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/25_algorithms/pstl/110512.cc

diff --git a/libstdc++-v3/include/pstl/execution_impl.h 
b/libstdc++-v3/include/pstl/execution_impl.h
index 64f6cc4357a..c84061848b9 100644
--- a/libstdc++-v3/include/pstl/execution_impl.h
+++ b/libstdc++-v3/include/pstl/execution_impl.h
@@ -19,13 +19,24 @@ namespace __pstl
 {
 namespace __internal
 {
-
-template 
-using __are_iterators_of = std::conjunction<
-std::is_base_of<_IteratorTag, typename 
std::iterator_traits>::iterator_category>...>;
+#if __glibcxx_concepts
+template
+  concept __is_random_access_iter
+= std::is_base_of_v>
+  || std::random_access_iterator<_Iter>;
 
 template 
-using __are_random_access_iterators = 
__are_iterators_of;
+  using __are_random_access_iterators
+= 
std::bool_constant<(__is_random_access_iter>
 && ...)>;
+#else
+template 
+using __are_random_access_iterators
+= std::__and_<
+   std::is_base_of>>...
+  >;
+#endif
 
 struct __serial_backend_tag
 {
diff --git a/libstdc++-v3/testsuite/25_algorithms/pstl/110512.cc 
b/libstdc++-v3/testsuite/25_algorithms/pstl/110512.cc
new file mode 100644
index 000..188c7c915e5
--- /dev/null
+++ b/libstdc++-v3/testsuite/25_algorithms/pstl/110512.cc
@@ -0,0 +1,31 @@
+// { dg-do compile { target c++17 } }
+
+// Bug 110512 - C++20 random access iterators run sequentially with PSTL
+
+#include 
+#include 
+#include 
+#include 
+
+using InputIter = __gnu_test::input_iterator_wrapper;
+using FwdIter = __gnu_test::forward_iterator_wrapper;
+using RAIter = __gnu_test::random_access_iterator_wrapper;
+
+template
+constexpr bool all_random_access
+  = __pstl::__internal::__are_random_access_iterators::value;
+
+using __pstl::__internal::__are_random_access_iterators;
+static_assert( all_random_access );
+static_assert( all_random_access );
+static_assert( ! all_random_access );
+static_assert( ! all_random_access );
+
+#if __cpp_lib_ranges
+using IotaIter = std::ranges::iterator_t>;
+static_assert( std::random_access_iterator );
+static_assert( all_random_access );
+static_assert( all_random_access );
+static_assert( all_random_access );
+static_assert( ! all_random_access );
+#endif
-- 
2.43.0

Re: [Bug libstdc++/112477] [13/14 Regression] Assignment of value-initialized iterators differs from value-initialization

[Jonathan Wakely]

On Wed, 10 Jan 2024 at 18:28, François Dumont  wrote:
>
> libstdc++: [_GLIBCXX_DEBUG] Fix assignment of value-initialized iterator
> [PR112477]
>
> Now that _M_Detach do not reset iterator _M_version value we need to
> reset it when
> the iterator is attached to a new sequence. Even if this sequencer is
> null like when
> assigning a value-initialized iterator. In this case _M_version shall be
> reset to 0.
>
> libstdc++-v3/ChangeLog:
>
>  PR libstdc++/112477
>  * src/c++11/debug.cc
>  (_Safe_iterator_base::_M_attach): Reset _M_version to 0 if
> attaching to null
>  sequence.
>  (_Safe_iterator_base::_M_attach_single): Likewise.
>  (_Safe_local_iterator_base::_M_attach): Likewise.
>  (_Safe_local_iterator_base::_M_attach_single): Likewise.
>  * testsuite/23_containers/map/debug/112477.cc: New test case.
>
> Tested under Linux x64 _GLIBCXX_DEBUG mode.
>
> Ok to commit and backport to gcc 13 ?

Yes please - thanks for the quick fix.


>
> François
>
> On 09/01/2024 22:47, fdumont at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112477
> >
> > François Dumont  changed:
> >
> > What|Removed |Added
> > 
> > Assignee|unassigned at gcc dot gnu.org  |fdumont at gcc dot 
> > gnu.org
> >
> > --- Comment #8 from François Dumont  ---
> > Hi
> > I'm going to have a look but if you wish to contribute do not hesitate.
> > Thanks for the report.
> >

[committed] libstdc++: Add GDB printer for std::integral_constant

[Jonathan Wakely]

I was finding it frustrating when returning from a function in GDB and
the return value was shown as $1 = {  }, so this makes it
print std::true_type or std::false_type.

There are some contexts where the output isn't ideal, e.g. a type
derived from std::true_type will now show something like:

$2 = {{std::integral_constant = std::true_type}};

But I think in most contexts it's an improvement.

Tested aarch64-linux, pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* python/libstdcxx/v6/printers.py (StdIntegralConstantPrinter):
Add printer for std::integral_constant.
* testsuite/libstdc++-prettyprinters/cxx11.cc: Test it.
---
 libstdc++-v3/python/libstdcxx/v6/printers.py  | 20 +++
 .../libstdc++-prettyprinters/cxx11.cc |  7 +++
 2 files changed, 27 insertions(+)

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py 
b/libstdc++-v3/python/libstdcxx/v6/printers.py
index bf0dc52ab8c..032a7aa58a2 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -2306,6 +2306,23 @@ class StdLocalePrinter(printer_base):
 mod = ' with "{}={}"'.format(cat, other)
 return 'std::locale = "{}"{}'.format(name, mod)
 
+class StdIntegralConstantPrinter(printer_base):
+"""Print a std::true_type or std::false_type."""
+
+def __init__(self, typename, val):
+self._val = val
+self._typename = typename
+
+def to_string(self):
+value_type = self._val.type.template_argument(0)
+value = self._val.type.template_argument(1)
+if value_type.code == gdb.TYPE_CODE_BOOL:
+if value:
+return "std::true_type"
+else:
+return "std::false_type"
+typename = strip_versioned_namespace(self._typename)
+return "{}<{}, {}>".format(typename, value_type, value)
 
 # A "regular expression" printer which conforms to the
 # "SubPrettyPrinter" protocol from gdb.printing.
@@ -2788,6 +2805,9 @@ def build_libstdcxx_dictionary():
 # vector
 libstdcxx_printer.add_version('std::', 'locale', StdLocalePrinter)
 
+libstdcxx_printer.add_version('std::', 'integral_constant',
+  StdIntegralConstantPrinter)
+
 if hasattr(gdb.Value, 'dynamic_type'):
 libstdcxx_printer.add_version('std::', 'error_code',
   StdErrorCodePrinter)
diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc 
b/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc
index bc869fd4122..f867ea18306 100644
--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc
@@ -207,6 +207,13 @@ main()
   std::atomic av{{8, 9}};
   // { dg-final { note-test av {std::atomic = { {i = 8, j = 9} }} } }
 
+  std::integral_constant one;
+  // { dg-final { note-test one {std::integral_constant} } }
+  std::integral_constant truth;
+  // { dg-final { note-test truth {std::true_type} } }
+  std::integral_constant lies;
+  // { dg-final { note-test lies {std::false_type} } }
+
   placeholder(""); // Mark SPOT
   use(efl);
   use(fl);
-- 
2.43.0

Re: [PATCH] libstdc++: Prefer posix_memalign for aligned-new [PR113258]

[Jonathan Wakely]

On Tue, 9 Jan 2024 at 22:00, Jonathan Wakely wrote:
>
> Does anybody see any problem with making this change, so that we avoid
> the problem described in the PR?

Pushed to trunk. We should backport this too.


>
> -- >8 --
>
> As described in PR libstdc++/113258 there are old versions of tcmalloc
> which replace malloc and related APIs, but do not repalce aligned_alloc
> because it didn't exist at the time they were released. This means that
> when operator new(size_t, align_val_t) uses aligned_alloc to obtain
> memory, it comes from libc's aligned_alloc not from tcmalloc. But when
> operator delete(void*, size_t, align_val_t) uses free to deallocate the
> memory, that goes to tcmalloc's replacement version of free, which
> doesn't know how to free it.
>
> If we give preference to the older posix_memalign instead of
> aligned_alloc then we're more likely to use a function that will be
> compatible with the replacement version of free. Because posix_memalign
> has been around for longer, it's more likely that old third-party malloc
> replacements will also replace posix_memalign alongside malloc and free.
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/113258
> * libsupc++/new_opa.cc: Prefer to use posix_memalign if
> available.
> ---
>  libstdc++-v3/libsupc++/new_opa.cc | 26 +++---
>  1 file changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/libstdc++-v3/libsupc++/new_opa.cc 
> b/libstdc++-v3/libsupc++/new_opa.cc
> index 8326b7497fe..35606e1c1b3 100644
> --- a/libstdc++-v3/libsupc++/new_opa.cc
> +++ b/libstdc++-v3/libsupc++/new_opa.cc
> @@ -46,12 +46,12 @@ using std::bad_alloc;
>  using std::size_t;
>  extern "C"
>  {
> -# if _GLIBCXX_HAVE_ALIGNED_ALLOC
> +# if _GLIBCXX_HAVE_POSIX_MEMALIGN
> +  void *posix_memalign(void **, size_t alignment, size_t size);
> +# elif _GLIBCXX_HAVE_ALIGNED_ALLOC
>void *aligned_alloc(size_t alignment, size_t size);
>  # elif _GLIBCXX_HAVE__ALIGNED_MALLOC
>void *_aligned_malloc(size_t size, size_t alignment);
> -# elif _GLIBCXX_HAVE_POSIX_MEMALIGN
> -  void *posix_memalign(void **, size_t alignment, size_t size);
>  # elif _GLIBCXX_HAVE_MEMALIGN
>void *memalign(size_t alignment, size_t size);
>  # else
> @@ -63,13 +63,10 @@ extern "C"
>  #endif
>
>  namespace __gnu_cxx {
> -#if _GLIBCXX_HAVE_ALIGNED_ALLOC
> -using ::aligned_alloc;
> -#elif _GLIBCXX_HAVE__ALIGNED_MALLOC
> -static inline void*
> -aligned_alloc (std::size_t al, std::size_t sz)
> -{ return _aligned_malloc(sz, al); }
> -#elif _GLIBCXX_HAVE_POSIX_MEMALIGN
> +// Prefer posix_memalign if available, because it's older than aligned_alloc
> +// and so more likely to be provided by replacement malloc libraries that
> +// predate the addition of aligned_alloc. See PR libstdc++/113258.
> +#if _GLIBCXX_HAVE_POSIX_MEMALIGN
>  static inline void*
>  aligned_alloc (std::size_t al, std::size_t sz)
>  {
> @@ -83,6 +80,12 @@ aligned_alloc (std::size_t al, std::size_t sz)
>  return ptr;
>return nullptr;
>  }
> +#elif _GLIBCXX_HAVE_ALIGNED_ALLOC
> +using ::aligned_alloc;
> +#elif _GLIBCXX_HAVE__ALIGNED_MALLOC
> +static inline void*
> +aligned_alloc (std::size_t al, std::size_t sz)
> +{ return _aligned_malloc(sz, al); }
>  #elif _GLIBCXX_HAVE_MEMALIGN
>  static inline void*
>  aligned_alloc (std::size_t al, std::size_t sz)
> @@ -128,7 +131,8 @@ operator new (std::size_t sz, std::align_val_t al)
>if (__builtin_expect (sz == 0, false))
>  sz = 1;
>
> -#if _GLIBCXX_HAVE_ALIGNED_ALLOC
> +#if _GLIBCXX_HAVE_POSIX_MEMALIGN
> +#elif _GLIBCXX_HAVE_ALIGNED_ALLOC
>  # if defined _AIX || defined __APPLE__
>/* AIX 7.2.0.0 aligned_alloc incorrectly has posix_memalign's requirement
> * that alignment is a multiple of sizeof(void*).
> --
> 2.43.0
>

Re: [PATCH] PR target/112886, Add %S to print_operand for vector pair support

[Michael Meissner]

On Tue, Jan 09, 2024 at 04:35:22PM -0600, Peter Bergner wrote:
> ...and this is really ugly and hard to read/understand.  Can't we use
> register variables to make it simpler?  Something like the following
> which tests having both FPR and Altivec reg numbers assigned?
> 
> ...
> void
> test (__vector_pair *ptr)
> {
>   register __vector_pair p asm ("vs10");
>   register __vector_pair q asm ("vs42");
>   register __vector_pair r asm ("vs44");
>   q = ptr[1];
>   r = ptr[2];
>   __asm__ ("xvadddp %x0,%x1,%x2\n\txvadddp %S0,%S1,%S2"
>  : "=wa" (p)
>  : "wa" (q), "wa" (r));
>   ptr[2] = p;
> }
> 
> /* { dg-final { scan-assembler-times {\mxvadddp 10,42,44\M} 1 } } */
> /* { dg-final { scan-assembler-times {\mxvadddp 11,43,45\M} 1 } } */
> ...

I have submitted V2 of the patch that changes the test case.  Thank you.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

[PATCH, V2] PR target/112886, Add %S to print_operand for vector pair support.

[Michael Meissner]

This is version 2 of the patch.  The only difference is I made the test case
simpler to read.

In looking at support for load vector pair and store vector pair for the
PowerPC in GCC, I noticed that we were missing a print_operand output modifier
if you are dealing with vector pairs to print the 2nd register in the vector
pair.

If the instruction inside of the asm used the Altivec encoding, then we could
use the %L modifier:

__vector_pair *p, *q, *r;
// ...
__asm__ ("vaddudm %0,%1,%2\n\tvaddudm %L0,%L1,%L2"
 : "=v" (*p)
 : "v" (*q), "v" (*r));

Likewise if we know the value to be in a tradiational FPR register, %L will
work for instructions that use the VSX encoding:

__vector_pair *p, *q, *r;
// ...
__asm__ ("xvadddp %x0,%x1,%x2\n\txvadddp %L0,%L1,%L2"
 : "=f" (*p)
 : "f" (*q), "f" (*r));

But if have a value that is in a traditional Altivec register, and the
instruction uses the VSX encoding, %L will a value between 0 and 31, when it
should give a value between 32 and 63.

This patch adds %S that acts like %x, except that it adds 1 to the
register number.

I have tested this on power10 and power9 little endian systems and on a power9
big endian system.  There were no regressions in the patch.  Can I apply it to
the trunk?

It would be nice if I could apply it to the open branches.  Can I backport it
after a burn-in period?

2024-01-10  Michael Meissner  

gcc/

PR target/112886
* config/rs6000/rs6000.cc (print_operand): Add %S output modifier.
* doc/md.texi (Modifiers): Mention %S can be used like %x.

gcc/testsuite/

PR target/112886
* /gcc.target/powerpc/pr112886.c: New test.
---
 gcc/config/rs6000/rs6000.cc | 10 ---
 gcc/doc/md.texi |  5 ++--
 gcc/testsuite/gcc.target/powerpc/pr112886.c | 29 +
 3 files changed, 39 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr112886.c

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 872df3140e3..6353a7ccfb2 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -14504,13 +14504,17 @@ print_operand (FILE *file, rtx x, int code)
print_operand (file, x, 0);
   return;
 
+case 'S':
 case 'x':
-  /* X is a FPR or Altivec register used in a VSX context.  */
+  /* X is a FPR or Altivec register used in a VSX context.  %x prints
+the VSX register number, %S prints the 2nd register number for
+vector pair, decimal 128-bit floating and IBM 128-bit binary floating
+values.  */
   if (!REG_P (x) || !VSX_REGNO_P (REGNO (x)))
-   output_operand_lossage ("invalid %%x value");
+   output_operand_lossage ("invalid %%%c value", (code == 'S' ? 'S' : 
'x'));
   else
{
- int reg = REGNO (x);
+ int reg = REGNO (x) + (code == 'S' ? 1 : 0);
  int vsx_reg = (FP_REGNO_P (reg)
 ? reg - 32
 : reg - FIRST_ALTIVEC_REGNO + 32);
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 47a87d6ceec..53ec957cb23 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -3386,8 +3386,9 @@ A VSX register (VSR), @code{vs0}@dots{}@code{vs63}.  This 
is either an
 FPR (@code{vs0}@dots{}@code{vs31} are @code{f0}@dots{}@code{f31}) or a VR
 (@code{vs32}@dots{}@code{vs63} are @code{v0}@dots{}@code{v31}).
 
-When using @code{wa}, you should use the @code{%x} output modifier, so that
-the correct register number is printed.  For example:
+When using @code{wa}, you should use either the @code{%x} or @code{%S}
+output modifier, so that the correct register number is printed.  For
+example:
 
 @smallexample
 asm ("xvadddp %x0,%x1,%x2"
diff --git a/gcc/testsuite/gcc.target/powerpc/pr112886.c 
b/gcc/testsuite/gcc.target/powerpc/pr112886.c
new file mode 100644
index 000..4e59dcda6ea
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr112886.c
@@ -0,0 +1,29 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target power10_ok } */
+/* { dg-options "-mdejagnu-cpu=power10 -O2" } */
+
+/* PR target/112886: Test that print_operand %S gives the correct register
+   number for VSX registers (i.e. if the register is an Altivec register, the
+   register number is 32..63 instead of 0..31.  */
+
+void
+test (__vector_pair *ptr1, __vector_pair *ptr2, __vector_pair *ptr3)
+{
+  register __vector_pair p asm ("vs10");
+  register __vector_pair q asm ("vs42");
+  register __vector_pair r asm ("vs44");
+
+  q = *ptr2;
+  r = *ptr3;
+
+  __asm__ ("xvadddp %x0,%x1,%x2\n\txvadddp %S0,%S1,%S2"
+  : "=wa" (p)
+  : "wa"  (q), "wa" (r));
+
+  *ptr1 = p;
+}
+
+/* { dg-final { scan-assembler-times {\mxvadddp 10,42,44\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mxvadddp 11,43,45\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mlxvpx?\M}   2 } } */

Re: [PATCH] libstdc++/ranges: Use perfect forwarding in _Pipe and _Partial ctors

[Patrick Palka]

On Thu, 11 Jan 2024, Jonathan Wakely wrote:

> On Wed, 10 Jan 2024 at 21:40, Patrick Palka  wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > -- >8 --
> >
> > This avoids redundant moves when composing and partially applying range
> > adaptor objects.
> >
> > Note that the new constraints on _Partial's constructor templates are
> > needed so that it's not inadvertently chosen over the copy constructor
> > when constructing a _Partial object from a non-const _Partial lvalue.
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/std/ranges (views::__adaptor::operator|): Perform
> > perfect forwarding of arguments.
> > (views::__adaptor::_Partial::_Partial): Likewise.
> > (views::__adaptor::_Pipe::__Pipe): Likewise.
> > ---
> >  libstdc++-v3/include/std/ranges | 65 -
> >  1 file changed, 39 insertions(+), 26 deletions(-)
> >
> > diff --git a/libstdc++-v3/include/std/ranges 
> > b/libstdc++-v3/include/std/ranges
> > index 81a857502e3..0734daa42bf 100644
> > --- a/libstdc++-v3/include/std/ranges
> > +++ b/libstdc++-v3/include/std/ranges
> > @@ -957,8 +957,11 @@ namespace views::__adaptor
> >  requires __is_range_adaptor_closure<_Lhs>
> >&& __is_range_adaptor_closure<_Rhs>
> >  constexpr auto
> > -operator|(_Lhs __lhs, _Rhs __rhs)
> > -{ return _Pipe<_Lhs, _Rhs>{std::move(__lhs), std::move(__rhs)}; }
> > +operator|(_Lhs&& __lhs, _Rhs&& __rhs)
> > +{
> > +  return _Pipe, decay_t<_Rhs>>{std::forward<_Lhs>(__lhs),
> > +std::forward<_Rhs>(__rhs)};
> > +}
> >
> >// The base class of every range adaptor non-closure.
> >//
> > @@ -1004,10 +1007,12 @@ namespace views::__adaptor
> >  {
> >tuple<_Args...> _M_args;
> >
> > -  constexpr
> > -  _Partial(_Args... __args)
> > -   : _M_args(std::move(__args)...)
> > -  { }
> > +  template
> > +   requires (sizeof...(_Ts) == sizeof...(_Args))
> 
> Do we also need a !same_as constraint here? If sizeof...(_Args) == 1
> then this could be chosen instead of a constructor, no?

For the == 1 case we would have used a different partial specialization
of _Partial (one that doesn't use heavyweight std::tuple).  So checking
sizeof...(_Ts) == sizof...(_Args) instead is sufficient and simpler.
Checking sizeof...(_Args) > 1 would be sufficient as well.

> 
> Or is
> > +   constexpr
> > +   _Partial(_Ts&&... __args)
> > + : _M_args(std::forward<_Ts>(__args)...)
> > +   { }
> >
> >// Invoke _Adaptor with arguments __r, _M_args... according to the
> >// value category of this _Partial object.
> > @@ -1046,10 +1051,12 @@ namespace views::__adaptor
> >  {
> >_Arg _M_arg;
> >
> > -  constexpr
> > -  _Partial(_Arg __arg)
> > -   : _M_arg(std::move(__arg))
> > -  { }
> > +  template
> > +   requires (!same_as, _Partial>)
> > +   constexpr
> > +   _Partial(_Tp&& __arg)
> > + : _M_arg(std::forward<_Tp>(__arg))
> > +   { }
> >
> >template
> > requires __adaptor_invocable<_Adaptor, _Range, const _Arg&>
> > @@ -1079,10 +1086,12 @@ namespace views::__adaptor
> >  {
> >tuple<_Args...> _M_args;
> >
> > -  constexpr
> > -  _Partial(_Args... __args)
> > -   : _M_args(std::move(__args)...)
> > -  { }
> > +  template
> > +   requires (sizeof...(_Ts) == sizeof...(_Args))
> > +   constexpr
> > +   _Partial(_Ts&&... __args)
> > + : _M_args(std::forward<_Ts>(__args)...)
> > +   { }
> >
> >// Invoke _Adaptor with arguments __r, const _M_args&... regardless
> >// of the value category of this _Partial object.
> > @@ -1109,10 +1118,12 @@ namespace views::__adaptor
> >  {
> >_Arg _M_arg;
> >
> > -  constexpr
> > -  _Partial(_Arg __arg)
> > -   : _M_arg(std::move(__arg))
> > -  { }
> > +  template
> > +   requires (!same_as, _Partial>)
> > +   constexpr
> > +   _Partial(_Tp&& __arg)
> > + : _M_arg(std::forward<_Tp>(__arg))
> > +   { }
> >
> >template
> > requires __adaptor_invocable<_Adaptor, _Range, const _Arg&>
> > @@ -1135,10 +1146,11 @@ namespace views::__adaptor
> >[[no_unique_address]] _Lhs _M_lhs;
> >[[no_unique_address]] _Rhs _M_rhs;
> >
> > -  constexpr
> > -  _Pipe(_Lhs __lhs, _Rhs __rhs)
> > -   : _M_lhs(std::move(__lhs)), _M_rhs(std::move(__rhs))
> > -  { }
> > +  template
> > +   constexpr
> > +   _Pipe(_Tp&& __lhs, _Up&& __rhs)
> > + : _M_lhs(std::forward<_Tp>(__lhs)), 
> > _M_rhs(std::forward<_Up>(__rhs))
> > +   { }
> >
> >// Invoke _M_rhs(_M_lhs(__r)) according to the value category of this
> >// range adaptor closure object.
> > @@ -1172,10 +1184,11 @@ namespace views::__adaptor
> >[[no_unique_address]] _Lhs _M_lhs;
> >[[no_unique_address]] _Rhs 

Re: [PATCH] libstdc++: use updated type for __unexpected_handler

[Jonathan Wakely]

On Thu, 11 Jan 2024 at 16:04, Marcus Hähnel wrote:
>
> Forwarding since I forgot to add gcc-patches in the original mail.
> Sorry for the noise.

And I forgot about this one, so thanks for the ping. I'll push it.


>
> -- >8 --
>
> Commit f4130a3eb545ab1aaf3ecb44f3d06b43e3751e04 changed the type of
> __expected_handler in libsupc++/unwind-cxx.h to be a
> std::terminate_handler to avoid a deprecated warning. However, the
> definition in eh_unex_handler.cc still used the old type
> (std::unexpected_handler) and thus causes a warning when compiling
> libstdc++ with -Wdeprecated-declarations (which is the default, for
> example, for clang).
>
> Adapt the definition to match the declaration.
>
> libstdc++-v3/ChangeLog:
> * libsupc++/eh_unex_handler: Adjust definition type to declaration.
> ---
>  libstdc++-v3/libsupc++/eh_unex_handler.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/libsupc++/eh_unex_handler.cc 
> b/libstdc++-v3/libsupc++/eh_unex_handler.cc
> index 0b7fa34e082..879585ee513 100644
> --- a/libstdc++-v3/libsupc++/eh_unex_handler.cc
> +++ b/libstdc++-v3/libsupc++/eh_unex_handler.cc
> @@ -25,5 +25,5 @@
>  #include "unwind-cxx.h"
>
>  /* The current installed user handler.  */
> -std::unexpected_handler __cxxabiv1::__unexpected_handler = std::terminate;
> +std::terminate_handler __cxxabiv1::__unexpected_handler = std::terminate;
>
> --
> 2.42.0
>

Fwd: [PATCH] libstdc++: use updated type for __unexpected_handler

[Marcus Hähnel]

Forwarding since I forgot to add gcc-patches in the original mail.
Sorry for the noise.

-- >8 --

Commit f4130a3eb545ab1aaf3ecb44f3d06b43e3751e04 changed the type of
__expected_handler in libsupc++/unwind-cxx.h to be a
std::terminate_handler to avoid a deprecated warning. However, the
definition in eh_unex_handler.cc still used the old type
(std::unexpected_handler) and thus causes a warning when compiling
libstdc++ with -Wdeprecated-declarations (which is the default, for
example, for clang).

Adapt the definition to match the declaration.

libstdc++-v3/ChangeLog:
* libsupc++/eh_unex_handler: Adjust definition type to declaration.
---
 libstdc++-v3/libsupc++/eh_unex_handler.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/libsupc++/eh_unex_handler.cc 
b/libstdc++-v3/libsupc++/eh_unex_handler.cc
index 0b7fa34e082..879585ee513 100644
--- a/libstdc++-v3/libsupc++/eh_unex_handler.cc
+++ b/libstdc++-v3/libsupc++/eh_unex_handler.cc
@@ -25,5 +25,5 @@
 #include "unwind-cxx.h"
 
 /* The current installed user handler.  */
-std::unexpected_handler __cxxabiv1::__unexpected_handler = std::terminate;
+std::terminate_handler __cxxabiv1::__unexpected_handler = std::terminate;
 
-- 
2.42.0



signature.asc
Description: This is a digitally signed message part

RE: [libatomic PATCH] Fix testsuite regressions on ARM [raspberry pi].

[Roger Sayle]

Hi Richard,
As you've recommended, this issue has now been filed in bugzilla
as PR other/113336.  As explained in the new PR, libatomic's testsuite
used to pass on armv6 (raspberry pi) in previous GCC releases, but
the code was incorrect/non-synchronous; this was reported as
PR target/107567 and PR target/109166.  Now that those issues
have been fixed, we now see that there's a missing dependency in
libatomic that's required to implement this functionality correctly.

I'm more convinced that my fix is correct, but it's perhaps a little
disappointing that libatomic doesn't have a (multi-threaded) run-time
test to search for race conditions, and confirm its implementations
are correctly serializing.

Please let me know what you think.
Best regards,
Roger
--

> -Original Message-
> From: Richard Earnshaw 
> Sent: 10 January 2024 15:34
> To: Roger Sayle ; gcc-patches@gcc.gnu.org
> Subject: Re: [libatomic PATCH] Fix testsuite regressions on ARM [raspberry 
> pi].
> 
> 
> 
> On 08/01/2024 16:07, Roger Sayle wrote:
> >
> > Bootstrapping GCC on arm-linux-gnueabihf with --with-arch=armv6
> > currently has a large number of FAILs in libatomic (regressions since
> > last time I attempted this).  The failure mode is related to IFUNC
> > handling with the file tas_8_2_.o containing an unresolved reference
> > to the function libat_test_and_set_1_i2.
> >
> > Bearing in mind I've no idea what's going on, the following one line
> > change, to build tas_1_2_.o when building tas_8_2_.o, resolves the
> > problem for me and restores the libatomic testsuite to 44 expected
> > passes and 5 unsupported tests [from 22 unexpected failures and 22 
> > unresolved
> testcases].
> >
> > If this looks like the correct fix, I'm not confident with rebuilding
> > Makefile.in with correct version of automake, so I'd very much
> > appreciate it if someone/the reviewer/mainainer could please check this in 
> > for
> me.
> > Thanks in advance.
> >
> >
> > 2024-01-08  Roger Sayle  
> >
> > libatomic/ChangeLog
> >  * Makefile.am: Build tas_1_2_.o on ARCH_ARM_LINUX
> >  * Makefile.in: Regenerate.
> >
> >
> > Roger
> > --
> >
> 
> Hi Roger,
> 
> I don't really understand all this make foo :( so I'm not sure if this is the 
> right fix
> either.  If this is, as you say, a regression, have you been able to track 
> down when
> it first started to occur?  That might also help me to understand what 
> changed to
> cause this.
> 
> Perhaps we should have a PR for this, to make tracking the fixes easier.
> 
> R.

[PATCH] testsuite: remove xfail

[Jason Merrill]

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

-- 8< --

These two lines have been getting XPASS since the test was added.

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/explicit-obj-diagnostics7.C: Remove xfail.
---
 gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics7.C | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics7.C 
b/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics7.C
index 023cdc2e0fe..d30ba5c961a 100644
--- a/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics7.C
+++ b/gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics7.C
@@ -43,11 +43,11 @@ struct S : B {
 
 // these should be suppressed, the wording conflicts with the error
 // the issue is not that they don't override, it's that they do override, and 
that isn't allowed
-// { dg-bogus "marked 'override', but does not override" "" { xfail *-*-* } 
line_f1 }
+// { dg-bogus "marked 'override', but does not override" "" { target *-*-* } 
line_f1 }
 // { dg-bogus "marked 'final', but is not virtual"  "" { xfail *-*-* } 
line_f2 }
 // { dg-bogus "marked '(override|final)'"   "" { xfail *-*-* } 
line_f3 }
 
-// { dg-bogus "marked 'override', but does not override" "" { xfail *-*-* } 
line_f5 }
+// { dg-bogus "marked 'override', but does not override" "" { target *-*-* } 
line_f5 }
 // { dg-bogus "marked 'final', but is not virtual"  "" { xfail *-*-* } 
line_f6 }
 // { dg-bogus "marked '(override|final)'"   "" { xfail *-*-* } 
line_f7 }
 

base-commit: 31461d2b651e1db6114cf7ab64ac1508410cf2f2
-- 
2.39.3

Re: [PATCH] RISC-V: THEAD: Fix ICE caused by split optimizations for XTheadFMemIdx.

[Kito Cheng]

LGTM

On Thu, Jan 11, 2024 at 7:23 PM Jin Ma  wrote:
>
> Due to the premature split optimizations for XTheadFMemIdx, GPR
> is allocated when reload allocates registers, resulting in the
> following insn.
>
> (insn 66 21 64 5 (set (reg:DF 14 a4 [orig:136  ] [136])
> (mem:DF (plus:SI (reg/f:SI 15 a5 [141])
> (ashift:SI (reg/v:SI 10 a0 [orig:137 i ] [137])
> (const_int 3 [0x3]))) [0  S8 A64])) 218 
> {*movdf_hardfloat_rv32}
>  (nil))
>
> Since we currently do not support adjustments to th_m_mir/th_m_miu,
> which will trigger ICE. So it is recommended to place the split
> optimizations after reload to ensure FPR when registers are allocated.
>
> gcc/ChangeLog:
>
> * config/riscv/thead.md: Add limits for splits.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/xtheadfmemidx-medany.c: New test.
> ---
>  gcc/config/riscv/thead.md | 22 ---
>  .../gcc.target/riscv/xtheadfmemidx-medany.c   | 38 +++
>  2 files changed, 54 insertions(+), 6 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadfmemidx-medany.c
>
> diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md
> index e370774d518..5c7d4beb1b6 100644
> --- a/gcc/config/riscv/thead.md
> +++ b/gcc/config/riscv/thead.md
> @@ -933,14 +933,17 @@ (define_insn_and_split "*th_fmemidx_I_a"
> && pow2p_hwi (INTVAL (operands[2]))
> && IN_RANGE (exact_log2 (INTVAL (operands[2])), 1, 3)"
>"#"
> -  "&& 1"
> +  "&& reload_completed"
>[(set (match_dup 0)
>  (mem:TH_M_NOEXTF (plus:X
>(match_dup 3)
>(ashift:X (match_dup 1) (match_dup 2)]
>{ operands[2] = GEN_INT (exact_log2 (INTVAL (operands [2])));
>}
> -)
> +  [(set_attr "move_type" "fpload")
> +   (set_attr "mode" "")
> +   (set_attr "type" "fmove")
> +   (set (attr "length") (const_int 16))])
>
>  (define_insn_and_split "*th_fmemidx_I_c"
>[(set (mem:TH_M_ANYF (plus:X
> @@ -977,7 +980,7 @@ (define_insn_and_split "*th_fmemidx_US_a"
> && CONST_INT_P (operands[3])
> && (INTVAL (operands[3]) >> exact_log2 (INTVAL (operands[2]))) == 
> 0x"
>"#"
> -  "&& 1"
> +  "&& reload_completed"
>[(set (match_dup 0)
>  (mem:TH_M_NOEXTF (plus:DI
>(match_dup 4)
> @@ -985,7 +988,10 @@ (define_insn_and_split "*th_fmemidx_US_a"
>{ operands[1] = gen_lowpart (SImode, operands[1]);
>  operands[2] = GEN_INT (exact_log2 (INTVAL (operands [2])));
>}
> -)
> +  [(set_attr "move_type" "fpload")
> +   (set_attr "mode" "")
> +   (set_attr "type" "fmove")
> +   (set (attr "length") (const_int 16))])
>
>  (define_insn_and_split "*th_fmemidx_US_c"
>[(set (mem:TH_M_ANYF (plus:DI
> @@ -1020,12 +1026,16 @@ (define_insn_and_split "*th_fmemidx_UZ_a"
>"TARGET_64BIT && TARGET_XTHEADMEMIDX && TARGET_XTHEADFMEMIDX
> && (!HARD_REGISTER_NUM_P (REGNO (operands[0])) || HARDFP_REG_P (REGNO 
> (operands[0])))"
>"#"
> -  "&& 1"
> +  "&& reload_completed"
>[(set (match_dup 0)
>  (mem:TH_M_NOEXTF (plus:DI
>(match_dup 2)
>(zero_extend:DI (match_dup 1)]
> -)
> +  ""
> +  [(set_attr "move_type" "fpload")
> +   (set_attr "mode" "")
> +   (set_attr "type" "fmove")
> +   (set (attr "length") (const_int 16))])
>
>  (define_insn_and_split "*th_fmemidx_UZ_c"
>[(set (mem:TH_M_ANYF (plus:DI
> diff --git a/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-medany.c 
> b/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-medany.c
> new file mode 100644
> index 000..0c8060d0632
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/xtheadfmemidx-medany.c
> @@ -0,0 +1,38 @@
> +/* { dg-do compile } */
> +/* { dg-skip-if "" { *-*-* } { "-O0" "-O1" "-O3" "-Og" "-Os" "-Oz"} } */
> +/* { dg-options "-march=rv32gc_xtheadfmemidx_xtheadfmv_xtheadmemidx 
> -mabi=ilp32d -mcmodel=medany -O2" } */
> +
> +typedef union {
> +  double v;
> +  unsigned w;
> +} my_t;
> +
> +double z;
> +
> +double foo (int i, int j)
> +{
> +
> +  if (j)
> +{
> +  switch (i)
> +   {
> +   case 0:
> + return 1;
> +   case 1:
> + return 0;
> +   case 2:
> + return 3.0;
> +   }
> +}
> +
> +  if (i == 1)
> +{
> +  my_t u;
> +  u.v = z;
> +  u.w = 1;
> +  z = u.v;
> +}
> +  return z;
> +}
> +
> +/* { dg-final { scan-assembler-times {\mth\.flrd\M} 1 } } */
> --
> 2.17.1
>

[patch,avr,applied] invoke.texi: Move avr internal options to their own @subsubsection.

[Georg-Johann Lay]

This adds a new @subsubsection "AVR Internal Options" in
"AVR Options".

"Internal" options are options that are not supposed to be
set by the user, but are solely required to ship information
from device-specs to the compiler proper.

(Without device-specs, non of these options would be needed
because then all information would be available in the
compiler proper.)

Johann

--

AVR: invoke.texi: Put internal options in their own @subsubsection.

gcc/
* doc/invoke.texi (AVR Options): Move -mrmw, -mn-flash, -mshort-calls
and -msp8 to...
(AVR Internaö Options): ...this new @subsubsection.diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index c1d01d32c1d..c1bb54b4109 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -23695,11 +23695,6 @@ Do not save registers in @code{main}.  The effect is the same like
 attaching attribute @ref{AVR Function Attributes,,@code{OS_task}}
 to @code{main}. It is activated per default if optimization is on.
 
-@opindex mn-flash
-@item -mn-flash=@var{num}
-Assume that the flash memory has a size of 
-@var{num} times 64@tie{}KiB.
-
 @opindex mno-interrupts
 @item -mno-interrupts
 Generated code is not compatible with hardware interrupts.
@@ -23721,35 +23716,6 @@ differ from instructions in the assembler code.
 Relaxing must be turned on if linker stubs are needed, see the
 section on @code{EIND} and linker stubs below.
 
-@opindex mrmw
-@item -mrmw
-Assume that the device supports the Read-Modify-Write
-instructions @code{XCH}, @code{LAC}, @code{LAS} and @code{LAT}.
-
-@opindex mshort-calls
-@item -mshort-calls
-
-Assume that @code{RJMP} and @code{RCALL} can target the whole
-program memory.
-
-This option is used internally for multilib selection.  It is
-not an optimization option, and you don't need to set it by hand.
-
-@opindex msp8
-@item -msp8
-Treat the stack pointer register as an 8-bit register,
-i.e.@: assume the high byte of the stack pointer is zero.
-In general, you don't need to set this option by hand.
-
-This option is used internally by the compiler to select and
-build multilibs for architectures @code{avr2} and @code{avr25}.
-These architectures mix devices with and without @code{SPH}.
-For any setting other than @option{-mmcu=avr2} or @option{-mmcu=avr25}
-the compiler driver adds or removes this option from the compiler
-proper's command line, because the compiler then knows if the device
-or architecture has an 8-bit stack pointer and thus no @code{SPH}
-register or not.
-
 @opindex mstrict-X
 @item -mstrict-X
 Use address register @code{X} in a way proposed by the hardware.  This means
@@ -24179,6 +24145,45 @@ Reflects the @code{--with-libf7=@{libgcc|math|math-symbols@}}
 
 @end table
 
+@subsubsection AVR Internal Options
+The following options are used internally by the compiler and to communicate
+between device specs files and the compiler proper. You don't need to set these
+options by hand, in particular they are not optimization options.
+Using these options in the wrong way may lead to sub-optimal or wrong code.
+They are documented for completeness, and in order to get a better
+understanding of
+@w{@uref{https://gcc.gnu.org/wiki/avr-gcc#spec-files,device specs}}
+files.
+
+@table @gcctabopt
+
+@opindex mn-flash
+@item -mn-flash=@var{num}
+Assume that the flash memory has a size of @var{num} times 64@tie{}KiB.
+This determines which @code{__flash@var{N}} address spaces are available.
+
+@opindex mrmw
+@item -mrmw
+Assume that the device supports the Read-Modify-Write
+instructions @code{XCH}, @code{LAC}, @code{LAS} and @code{LAT}.
+
+@opindex mshort-calls
+@item -mshort-calls
+
+Assume that @code{RJMP} and @code{RCALL} can target the whole
+program memory. This option is used for multilib generation and selection
+for the devices from architecture @code{avrxmega3}.
+
+@opindex msp8
+@item -msp8
+Treat the stack pointer register as an 8-bit register,
+i.e.@: assume the high byte of the stack pointer is zero.
+This option is used by the compiler to select and
+build multilibs for architectures @code{avr2} and @code{avr25}.
+These architectures mix devices with and without @code{SPH}.
+
+@end table
+
 @node Blackfin Options
 @subsection Blackfin Options
 @cindex Blackfin Options

Re: [PATCH] libstdc++/ranges: Use C++23 deducing this for _Pipe and _Partial

[Jonathan Wakely]

On Thu, 11 Jan 2024 at 00:26, Patrick Palka  wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

OK. Nice to see explicit object functions landing in the library so soon!


>
> -- >8 --
>
> This simplifies the operator() of the _Pipe and _Partial range adaptor
> closure objects using C++23 deducing this, allowing us to condense
> multiple operator() overloads into one.
>
> The new __like_t alias template is similar to the expositional one from
> P0847R6, except it's implemented in terms of forward_like instead of vice
> versa, and thus ours always yields a reference, so e.g.  __like_t
> is char&&.  This shouldn't make a difference in practice, I think..
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/move.h (__like_t): Define.
> * include/std/ranges (views::__adaptor::Partial::operator()):
> Implement using C++23 deducing this when available.
> (views::__adaptor::_Pipe::operator()): Likewise.
> * testsuite/std/ranges/adaptors/100577.cc: Adjust testcase to
> accept "no match for call" errors issued in C++23 mode instead
> of "use of deleted function".
> * testsuite/std/ranges/adaptors/lazy_split_neg.cc: Likewise.
> ---
>  libstdc++-v3/include/bits/move.h  |  3 ++
>  libstdc++-v3/include/std/ranges   | 37 ++-
>  .../testsuite/std/ranges/adaptors/100577.cc   | 18 -
>  .../std/ranges/adaptors/lazy_split_neg.cc |  2 +-
>  4 files changed, 48 insertions(+), 12 deletions(-)
>
> diff --git a/libstdc++-v3/include/bits/move.h 
> b/libstdc++-v3/include/bits/move.h
> index 4e741bcdeb0..bb200c95964 100644
> --- a/libstdc++-v3/include/bits/move.h
> +++ b/libstdc++-v3/include/bits/move.h
> @@ -110,6 +110,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   return static_cast<_Up&>(__x);
>}
>}
> +
> +  template
> +using __like_t = decltype(std::forward_like<_Tp>(std::declval<_Up>()));
>  #endif
>
>/**
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index 0734daa42bf..8d2649cf5b9 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -1016,7 +1016,19 @@ namespace views::__adaptor
>
>// Invoke _Adaptor with arguments __r, _M_args... according to the
>// value category of this _Partial object.
> -  // TODO: use explicit object functions ("deducing this").
> +#if __cpp_explicit_this_parameter
> +  template
> +   requires __adaptor_invocable<_Adaptor, _Range, __like_t<_Self, 
> _Args>...>
> +   constexpr auto
> +   operator()(this _Self&& __self, _Range&& __r)
> +   {
> + auto __forwarder = [&__r] (auto&&... __args) {
> +   return _Adaptor{}(std::forward<_Range>(__r),
> + std::forward(__args)...);
> + };
> + return std::apply(__forwarder, std::forward<_Self>(__self)._M_args);
> +   }
> +#else
>template
> requires __adaptor_invocable<_Adaptor, _Range, const _Args&...>
> constexpr auto
> @@ -1042,6 +1054,7 @@ namespace views::__adaptor
>template
> constexpr auto
> operator()(_Range&& __r) const && = delete;
> +#endif
>  };
>
>// A lightweight specialization of the above primary template for
> @@ -1058,6 +1071,14 @@ namespace views::__adaptor
>   : _M_arg(std::forward<_Tp>(__arg))
> { }
>
> +#if __cpp_explicit_this_parameter
> +  template
> +   requires __adaptor_invocable<_Adaptor, _Range, __like_t<_Self, _Arg>>
> +   constexpr auto
> +   operator()(this _Self&& __self, _Range&& __r)
> +   { return _Adaptor{}(std::forward<_Range>(__r),
> +   std::forward<_Self>(__self)._M_arg); }
> +#else
>template
> requires __adaptor_invocable<_Adaptor, _Range, const _Arg&>
> constexpr auto
> @@ -1073,6 +1094,7 @@ namespace views::__adaptor
>template
> constexpr auto
> operator()(_Range&& __r) const && = delete;
> +#endif
>  };
>
>// Partial specialization of the primary template for the case where the 
> extra
> @@ -1154,7 +1176,17 @@ namespace views::__adaptor
>
>// Invoke _M_rhs(_M_lhs(__r)) according to the value category of this
>// range adaptor closure object.
> -  // TODO: use explicit object functions ("deducing this").
> +#if __cpp_explicit_this_parameter
> +  template
> +   requires __pipe_invocable<__like_t<_Self, _Lhs>, __like_t<_Self, 
> _Rhs>, _Range>
> +   constexpr auto
> +   operator()(this _Self&& __self, _Range&& __r)
> +   {
> + return (std::forward<_Self>(__self)._M_rhs
> + (std::forward<_Self>(__self)._M_lhs
> +  (std::forward<_Range>(__r;
> +   }
> +#else
>template
> requires __pipe_invocable
> constexpr auto
> @@ -1170,6 +1202,7 @@ namespace views::__adaptor
>template
> constexpr auto
> 

Re: [PATCH] libstdc++/ranges: Use perfect forwarding in _Pipe and _Partial ctors

[Jonathan Wakely]

On Wed, 10 Jan 2024 at 21:40, Patrick Palka  wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> This avoids redundant moves when composing and partially applying range
> adaptor objects.
>
> Note that the new constraints on _Partial's constructor templates are
> needed so that it's not inadvertently chosen over the copy constructor
> when constructing a _Partial object from a non-const _Partial lvalue.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (views::__adaptor::operator|): Perform
> perfect forwarding of arguments.
> (views::__adaptor::_Partial::_Partial): Likewise.
> (views::__adaptor::_Pipe::__Pipe): Likewise.
> ---
>  libstdc++-v3/include/std/ranges | 65 -
>  1 file changed, 39 insertions(+), 26 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index 81a857502e3..0734daa42bf 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -957,8 +957,11 @@ namespace views::__adaptor
>  requires __is_range_adaptor_closure<_Lhs>
>&& __is_range_adaptor_closure<_Rhs>
>  constexpr auto
> -operator|(_Lhs __lhs, _Rhs __rhs)
> -{ return _Pipe<_Lhs, _Rhs>{std::move(__lhs), std::move(__rhs)}; }
> +operator|(_Lhs&& __lhs, _Rhs&& __rhs)
> +{
> +  return _Pipe, decay_t<_Rhs>>{std::forward<_Lhs>(__lhs),
> +std::forward<_Rhs>(__rhs)};
> +}
>
>// The base class of every range adaptor non-closure.
>//
> @@ -1004,10 +1007,12 @@ namespace views::__adaptor
>  {
>tuple<_Args...> _M_args;
>
> -  constexpr
> -  _Partial(_Args... __args)
> -   : _M_args(std::move(__args)...)
> -  { }
> +  template
> +   requires (sizeof...(_Ts) == sizeof...(_Args))

Do we also need a !same_as constraint here? If sizeof...(_Args) == 1
then this could be chosen instead of a constructor, no?

Or is
> +   constexpr
> +   _Partial(_Ts&&... __args)
> + : _M_args(std::forward<_Ts>(__args)...)
> +   { }
>
>// Invoke _Adaptor with arguments __r, _M_args... according to the
>// value category of this _Partial object.
> @@ -1046,10 +1051,12 @@ namespace views::__adaptor
>  {
>_Arg _M_arg;
>
> -  constexpr
> -  _Partial(_Arg __arg)
> -   : _M_arg(std::move(__arg))
> -  { }
> +  template
> +   requires (!same_as, _Partial>)
> +   constexpr
> +   _Partial(_Tp&& __arg)
> + : _M_arg(std::forward<_Tp>(__arg))
> +   { }
>
>template
> requires __adaptor_invocable<_Adaptor, _Range, const _Arg&>
> @@ -1079,10 +1086,12 @@ namespace views::__adaptor
>  {
>tuple<_Args...> _M_args;
>
> -  constexpr
> -  _Partial(_Args... __args)
> -   : _M_args(std::move(__args)...)
> -  { }
> +  template
> +   requires (sizeof...(_Ts) == sizeof...(_Args))
> +   constexpr
> +   _Partial(_Ts&&... __args)
> + : _M_args(std::forward<_Ts>(__args)...)
> +   { }
>
>// Invoke _Adaptor with arguments __r, const _M_args&... regardless
>// of the value category of this _Partial object.
> @@ -1109,10 +1118,12 @@ namespace views::__adaptor
>  {
>_Arg _M_arg;
>
> -  constexpr
> -  _Partial(_Arg __arg)
> -   : _M_arg(std::move(__arg))
> -  { }
> +  template
> +   requires (!same_as, _Partial>)
> +   constexpr
> +   _Partial(_Tp&& __arg)
> + : _M_arg(std::forward<_Tp>(__arg))
> +   { }
>
>template
> requires __adaptor_invocable<_Adaptor, _Range, const _Arg&>
> @@ -1135,10 +1146,11 @@ namespace views::__adaptor
>[[no_unique_address]] _Lhs _M_lhs;
>[[no_unique_address]] _Rhs _M_rhs;
>
> -  constexpr
> -  _Pipe(_Lhs __lhs, _Rhs __rhs)
> -   : _M_lhs(std::move(__lhs)), _M_rhs(std::move(__rhs))
> -  { }
> +  template
> +   constexpr
> +   _Pipe(_Tp&& __lhs, _Up&& __rhs)
> + : _M_lhs(std::forward<_Tp>(__lhs)), _M_rhs(std::forward<_Up>(__rhs))
> +   { }
>
>// Invoke _M_rhs(_M_lhs(__r)) according to the value category of this
>// range adaptor closure object.
> @@ -1172,10 +1184,11 @@ namespace views::__adaptor
>[[no_unique_address]] _Lhs _M_lhs;
>[[no_unique_address]] _Rhs _M_rhs;
>
> -  constexpr
> -  _Pipe(_Lhs __lhs, _Rhs __rhs)
> -   : _M_lhs(std::move(__lhs)), _M_rhs(std::move(__rhs))
> -  { }
> +  template
> +   constexpr
> +   _Pipe(_Tp&& __lhs, _Up&& __rhs)
> + : _M_lhs(std::forward<_Tp>(__lhs)), _M_rhs(std::forward<_Up>(__rhs))
> +   { }
>
>template
> requires __pipe_invocable
> --
> 2.43.0.283.ga54a84b333
>

Re: [PATCH] [s390] target/112280 - properly guard permute query

[Andreas Krebbel]

On 1/11/24 14:58, Richard Biener wrote:
> The following adds guards avoiding code generation to
> expand_perm_as_a_vlbr_vstbr_candidate when d.testing_p.
> 
> Built and tested on the testcase in the PR.
> 
> OK to push as obvious?  Otherwise please pick up, test and push.

Ok to commit now. Thanks for the fix!

I've just started a regression test and will take care of any fallout.

Bye,

Andreas

> 
> Thanks,
> Richard.
> 
>   PR target/112280
>   * config/s390/s390.cc (expand_perm_as_a_vlbr_vstbr_candidate):
>   Do not generate code when d.testing_p.
> ---
>  gcc/config/s390/s390.cc | 36 
>  1 file changed, 24 insertions(+), 12 deletions(-)
> 
> diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
> index 748ad9cd932..f182c26e78b 100644
> --- a/gcc/config/s390/s390.cc
> +++ b/gcc/config/s390/s390.cc
> @@ -17867,33 +17867,45 @@ expand_perm_as_a_vlbr_vstbr_candidate (const struct 
> expand_vec_perm_d )
>  
>if (memcmp (d.perm, perm[0], MAX_VECT_LEN) == 0)
>  {
> -  rtx target = gen_rtx_SUBREG (V8HImode, d.target, 0);
> -  rtx op0 = gen_rtx_SUBREG (V8HImode, d.op0, 0);
> -  emit_insn (gen_bswapv8hi (target, op0));
> +  if (!d.testing_p)
> + {
> +   rtx target = gen_rtx_SUBREG (V8HImode, d.target, 0);
> +   rtx op0 = gen_rtx_SUBREG (V8HImode, d.op0, 0);
> +   emit_insn (gen_bswapv8hi (target, op0));
> + }
>return true;
>  }
>  
>if (memcmp (d.perm, perm[1], MAX_VECT_LEN) == 0)
>  {
> -  rtx target = gen_rtx_SUBREG (V4SImode, d.target, 0);
> -  rtx op0 = gen_rtx_SUBREG (V4SImode, d.op0, 0);
> -  emit_insn (gen_bswapv4si (target, op0));
> +  if (!d.testing_p)
> + {
> +   rtx target = gen_rtx_SUBREG (V4SImode, d.target, 0);
> +   rtx op0 = gen_rtx_SUBREG (V4SImode, d.op0, 0);
> +   emit_insn (gen_bswapv4si (target, op0));
> + }
>return true;
>  }
>  
>if (memcmp (d.perm, perm[2], MAX_VECT_LEN) == 0)
>  {
> -  rtx target = gen_rtx_SUBREG (V2DImode, d.target, 0);
> -  rtx op0 = gen_rtx_SUBREG (V2DImode, d.op0, 0);
> -  emit_insn (gen_bswapv2di (target, op0));
> +  if (!d.testing_p)
> + {
> +   rtx target = gen_rtx_SUBREG (V2DImode, d.target, 0);
> +   rtx op0 = gen_rtx_SUBREG (V2DImode, d.op0, 0);
> +   emit_insn (gen_bswapv2di (target, op0));
> + }
>return true;
>  }
>  
>if (memcmp (d.perm, perm[3], MAX_VECT_LEN) == 0)
>  {
> -  rtx target = gen_rtx_SUBREG (V1TImode, d.target, 0);
> -  rtx op0 = gen_rtx_SUBREG (V1TImode, d.op0, 0);
> -  emit_insn (gen_bswapv1ti (target, op0));
> +  if (!d.testing_p)
> + {
> +   rtx target = gen_rtx_SUBREG (V1TImode, d.target, 0);
> +   rtx op0 = gen_rtx_SUBREG (V1TImode, d.op0, 0);
> +   emit_insn (gen_bswapv1ti (target, op0));
> + }
>return true;
>  }
>  

Re: [PATCH v2 7/7] aarch64,arm: Move branch-protection data to targets

[Richard Earnshaw (lists)]

On 11/01/2024 14:43, Szabolcs Nagy wrote:
> The 12/07/2023 13:13, Richard Earnshaw wrote:
>> On 03/11/2023 15:36, Szabolcs Nagy wrote:
>>> * config/aarch64/aarch64.cc (aarch_handle_no_branch_protection): Copy.
>>> (aarch_handle_standard_branch_protection): Copy.
>>> (aarch_handle_pac_ret_protection): Copy.
>>> (aarch_handle_pac_ret_leaf): Copy.
>>> (aarch_handle_pac_ret_b_key): Copy.
>>> (aarch_handle_bti_protection): Copy.
>>
>> I think all of the above functions that have been moved back from
>> aarch-common should be renamed back to aarch64_..., unless they are directly
>> referenced statically by code in aarch-common.c.
> 
> done.
> 
>>> +const struct aarch_branch_protect_type aarch_branch_protect_types[] = {
>>
>> can this be made static now?  And maybe pass the structure as a parameter if
>> that's not done already.
> 
> done in v4.
> 
>> It would be nice if, when we raise an error, we could print out the list of
>> valid options (and modifiers), much like we do on Arm for -march/-mcpu.
>>
>> eg.
>> $ gcc -mcpu=crotex-a8
>> cc1: error: unrecognised -mcpu target: crotex-a8
>> cc1: note: valid arguments are: arm8 arm810 strongarm strongarm110 fa526
>> [...rest of list]; did you mean ‘cortex-a8’?
> 
> i implemented this with candidates_list_and_hint but it does
> not work very well if the typo is in a subtype, so i think
> this should be done in a separate patch if at all.
> 

I'd build the candidates list from all the types + subtypes, so that the 
suggestion code has a full list to pick from; but fair enough.

R.

Re: [PATCH v2 7/7] aarch64,arm: Move branch-protection data to targets

[Szabolcs Nagy]

The 12/07/2023 13:13, Richard Earnshaw wrote:
> On 03/11/2023 15:36, Szabolcs Nagy wrote:
> > * config/aarch64/aarch64.cc (aarch_handle_no_branch_protection): Copy.
> > (aarch_handle_standard_branch_protection): Copy.
> > (aarch_handle_pac_ret_protection): Copy.
> > (aarch_handle_pac_ret_leaf): Copy.
> > (aarch_handle_pac_ret_b_key): Copy.
> > (aarch_handle_bti_protection): Copy.
> 
> I think all of the above functions that have been moved back from
> aarch-common should be renamed back to aarch64_..., unless they are directly
> referenced statically by code in aarch-common.c.

done.

> > +const struct aarch_branch_protect_type aarch_branch_protect_types[] = {
> 
> can this be made static now?  And maybe pass the structure as a parameter if
> that's not done already.

done in v4.

> It would be nice if, when we raise an error, we could print out the list of
> valid options (and modifiers), much like we do on Arm for -march/-mcpu.
> 
> eg.
> $ gcc -mcpu=crotex-a8
> cc1: error: unrecognised -mcpu target: crotex-a8
> cc1: note: valid arguments are: arm8 arm810 strongarm strongarm110 fa526
> [...rest of list]; did you mean ‘cortex-a8’?

i implemented this with candidates_list_and_hint but it does
not work very well if the typo is in a subtype, so i think
this should be done in a separate patch if at all.

[PATCH v2 0/1] RISC-V: Support CORE-V XCVMEM extension

[Mary Bennett]

This patch series presents the comprehensive implementation of the MEM
extension for CORE-V.

Tested with riscv-gnu-toolchain on binutils, ld, gas and gcc testsuites to
ensure its correctness and compatibility with the existing codebase.
However, your input, reviews, and suggestions are invaluable in making this
extension even more robust.

The CORE-V builtins are described in the specification [1] and work can be
found in the OpenHW group's Github repository [2].

[1] 
github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md

[2] github.com/openhwgroup/corev-gcc

Contributors:
  Mary Bennett 
  Nandni Jamnadas 
  Pietra Ferreira 
  Charlie Keaney
  Jessica Mills
  Craig Blackmore 
  Simon Cook 
  Jeremy Bennett 
  Helene Chelin 

RISC-V: Add support for XCVmem extension in CV32E40P

 gcc/common/config/riscv/riscv-common.cc   |   2 +
 gcc/config/riscv/constraints.md   |  29 ++
 gcc/config/riscv/corev.md | 270 ++
 gcc/config/riscv/predicates.md|  20 +-
 gcc/config/riscv/riscv-protos.h   |  12 +-
 gcc/config/riscv/riscv.cc |  48 +++-
 gcc/config/riscv/riscv.h  |   4 +-
 gcc/config/riscv/riscv.md |  26 +-
 gcc/config/riscv/riscv.opt|   2 +
 gcc/doc/sourcebuild.texi  |   3 +
 .../gcc.target/riscv/cv-mem-lb-compile-1.c|  23 ++
 .../gcc.target/riscv/cv-mem-lb-compile-2.c|  24 ++
 .../gcc.target/riscv/cv-mem-lb-compile-3.c|  16 ++
 .../gcc.target/riscv/cv-mem-lbu-compile-1.c   |  23 ++
 .../gcc.target/riscv/cv-mem-lbu-compile-2.c   |  24 ++
 .../gcc.target/riscv/cv-mem-lbu-compile-3.c   |  16 ++
 .../gcc.target/riscv/cv-mem-lh-compile-1.c|  23 ++
 .../gcc.target/riscv/cv-mem-lh-compile-2.c|  24 ++
 .../gcc.target/riscv/cv-mem-lh-compile-3.c|  16 ++
 .../gcc.target/riscv/cv-mem-lhu-compile-1.c   |  23 ++
 .../gcc.target/riscv/cv-mem-lhu-compile-2.c   |  24 ++
 .../gcc.target/riscv/cv-mem-lhu-compile-3.c   |  16 ++
 .../gcc.target/riscv/cv-mem-lw-compile-1.c|  38 +++
 .../gcc.target/riscv/cv-mem-lw-compile-2.c|  38 +++
 .../gcc.target/riscv/cv-mem-lw-compile-3.c|  22 ++
 .../riscv/cv-mem-operand-compile-1.c  |  19 ++
 .../riscv/cv-mem-operand-compile-2.c  |  20 ++
 .../riscv/cv-mem-operand-compile-3.c  |  28 ++
 .../riscv/cv-mem-operand-compile-4.c  |  21 ++
 .../riscv/cv-mem-operand-compile-5.c  |  25 ++
 .../riscv/cv-mem-operand-compile-6.c  |  21 ++
 .../riscv/cv-mem-operand-compile-7.c  |  24 ++
 .../riscv/cv-mem-operand-compile-8.c  |  18 ++
 .../gcc.target/riscv/cv-mem-sb-compile-1.c|  36 +++
 .../gcc.target/riscv/cv-mem-sb-compile-2.c|  38 +++
 .../gcc.target/riscv/cv-mem-sb-compile-3.c|  30 ++
 .../gcc.target/riscv/cv-mem-sh-compile-1.c|  36 +++
 .../gcc.target/riscv/cv-mem-sh-compile-2.c|  38 +++
 .../gcc.target/riscv/cv-mem-sh-compile-3.c|  30 ++
 .../gcc.target/riscv/cv-mem-sw-compile-1.c|  36 +++
 .../gcc.target/riscv/cv-mem-sw-compile-2.c|  38 +++
 .../gcc.target/riscv/cv-mem-sw-compile-3.c|  30 ++
 gcc/testsuite/lib/target-supports.exp |  13 +
 43 files changed, 1247 insertions(+), 20 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-lb-compile-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-lb-compile-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-lb-compile-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-lbu-compile-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-lbu-compile-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-lbu-compile-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-lh-compile-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-lh-compile-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-lh-compile-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-lhu-compile-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-lhu-compile-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-lhu-compile-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-lw-compile-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-lw-compile-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-lw-compile-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-operand-compile-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-operand-compile-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-operand-compile-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-operand-compile-4.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-operand-compile-5.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-operand-compile-6.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/cv-mem-operand-compile-7.c
 create mode 100644 

[PATCH v2 1/1] RISC-V: Add support for XCVmem extension in CV32E40P

[Mary Bennett]

XCVmem adds more loads and stores. To prevent non-XCVmem loads and
stores from generating illegal XCVmem specific operands, constraint
'm' was redefined. 'm' does not accept POST_MODIFY or reg + reg
addresses.

Spec: 
github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md

Contributors:
  Mary Bennett 
  Nandni Jamnadas 
  Pietra Ferreira 
  Charlie Keaney
  Jessica Mills
  Craig Blackmore 
  Simon Cook 
  Jeremy Bennett 
  Helene Chelin 

gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Add the XCVmem
  extension.
* config/riscv/riscv.opt: Likewise.
* config/riscv/corev.md: Likewise.
* config/riscv/predicates.md: Likewise.
* config/riscv/riscv-protos.h: Likewise.
* config/riscv/riscv.cc: Add POST_MODIFY.
* config/riscv/riscv.h: Likewise.
* config/riscv/riscv.md: Prevent XCVmem operands being
  used in non-XCVmem loads and stores.
* config/riscv/constraints.md: Likewise.
* config/riscv/predicates.md: Likewise.
* doc/sourcebuild.texi: Add XCVmem documentation.

gcc/testsuite/ChangeLog:
* gcc.target/riscv/cv-mem-operand-compile-1.c: New test.
* gcc.target/riscv/cv-mem-operand-compile-2.c: New test.
* gcc.target/riscv/cv-mem-operand-compile-3.c: New test.
* gcc.target/riscv/cv-mem-operand-compile-4.c: New test.
* gcc.target/riscv/cv-mem-operand-compile-5.c: New test.
* gcc.target/riscv/cv-mem-operand-compile-6.c: New test.
* gcc.target/riscv/cv-mem-operand-compile-7.c: New test.
* gcc.target/riscv/cv-mem-operand-compile-8.c: New test.
* gcc.target/riscv/cv-mem-lb-compile-1.c: New test.
* gcc.target/riscv/cv-mem-lb-compile-2.c: New test.
* gcc.target/riscv/cv-mem-lb-compile-3.c: New test.
* gcc.target/riscv/cv-mem-lbu-compile-1.c: New test.
* gcc.target/riscv/cv-mem-lbu-compile-2.c: New test.
* gcc.target/riscv/cv-mem-lbu-compile-3.c: New test.
* gcc.target/riscv/cv-mem-lh-compile-1.c: New test.
* gcc.target/riscv/cv-mem-lh-compile-2.c: New test.
* gcc.target/riscv/cv-mem-lh-compile-3.c: New test.
* gcc.target/riscv/cv-mem-lhu-compile-1.c: New test.
* gcc.target/riscv/cv-mem-lhu-compile-2.c: New test.
* gcc.target/riscv/cv-mem-lhu-compile-3.c: New test.
* gcc.target/riscv/cv-mem-lw-compile-1.c: New test.
* gcc.target/riscv/cv-mem-lw-compile-2.c: New test.
* gcc.target/riscv/cv-mem-lw-compile-3.c: New test.
* gcc.target/riscv/cv-mem-sb-compile-1.c: New test.
* gcc.target/riscv/cv-mem-sb-compile-2.c: New test.
* gcc.target/riscv/cv-mem-sb-compile-3.c: New test.
* gcc.target/riscv/cv-mem-sh-compile-1.c: New test.
* gcc.target/riscv/cv-mem-sh-compile-2.c: New test.
* gcc.target/riscv/cv-mem-sh-compile-3.c: New test.
* gcc.target/riscv/cv-mem-sw-compile-1.c: New test.
* gcc.target/riscv/cv-mem-sw-compile-2.c: New test.
* gcc.target/riscv/cv-mem-sw-compile-3.c: New test.
* lib/target-supports.exp: Add proc for XCVmem.

Change the priority of the XCVmem instructions

Returned corev.md to be included at the bottom of riscv.md.

Files Changed:
 * corev.md: Added generic load/ store instructions with lower
   priority than the XCVmem load/ store instructions.
 * riscv.md: Prevent generic load/ store instructions having higher
   priority than XCVmem load/ store if the extension is included.
---
 gcc/common/config/riscv/riscv-common.cc   |   2 +
 gcc/config/riscv/constraints.md   |  29 ++
 gcc/config/riscv/corev.md | 270 ++
 gcc/config/riscv/predicates.md|  20 +-
 gcc/config/riscv/riscv-protos.h   |  12 +-
 gcc/config/riscv/riscv.cc |  48 +++-
 gcc/config/riscv/riscv.h  |   4 +-
 gcc/config/riscv/riscv.md |  26 +-
 gcc/config/riscv/riscv.opt|   2 +
 gcc/doc/sourcebuild.texi  |   3 +
 .../gcc.target/riscv/cv-mem-lb-compile-1.c|  23 ++
 .../gcc.target/riscv/cv-mem-lb-compile-2.c|  24 ++
 .../gcc.target/riscv/cv-mem-lb-compile-3.c|  16 ++
 .../gcc.target/riscv/cv-mem-lbu-compile-1.c   |  23 ++
 .../gcc.target/riscv/cv-mem-lbu-compile-2.c   |  24 ++
 .../gcc.target/riscv/cv-mem-lbu-compile-3.c   |  16 ++
 .../gcc.target/riscv/cv-mem-lh-compile-1.c|  23 ++
 .../gcc.target/riscv/cv-mem-lh-compile-2.c|  24 ++
 .../gcc.target/riscv/cv-mem-lh-compile-3.c|  16 ++
 .../gcc.target/riscv/cv-mem-lhu-compile-1.c   |  23 ++
 .../gcc.target/riscv/cv-mem-lhu-compile-2.c   |  24 ++
 .../gcc.target/riscv/cv-mem-lhu-compile-3.c   |  16 ++
 .../gcc.target/riscv/cv-mem-lw-compile-1.c|  38 +++
 .../gcc.target/riscv/cv-mem-lw-compile-2.c|  38 +++
 .../gcc.target/riscv/cv-mem-lw-compile-3.c|  22 ++
 .../riscv/cv-mem-operand-compile-1.c   

Re: [PATCH 2/2] gccrs: fixup: Fix missing build dependency

[Richard Biener]

On Thu, 11 Jan 2024, Arthur Cohen wrote:

> Hi Richard,
> 
> On 1/11/24 15:23, Richard Biener wrote:
> > On Thu, 11 Jan 2024, Arthur Cohen wrote:
> > 
> >> From: Pierre-Emmanuel Patry 
> >>
> >> Fix the missing dependency between the gcc and libgrust.
> >>
> >> ChangeLog:
> >>
> >>  * Makefile.def: Add a dependency to libgrust for all-gcc.
> >>  * Makefile.in: Regenerate the file.
> >>
> >> Signed-off-by: Pierre-Emmanuel Patry 
> >> ---
> >>   Makefile.def |  1 +
> >>   Makefile.in  | 10 ++
> >>   2 files changed, 11 insertions(+)
> >>
> >> diff --git a/Makefile.def b/Makefile.def
> >> index 1a256db5518..19954e7d731 100644
> >> --- a/Makefile.def
> >> +++ b/Makefile.def
> >> @@ -375,6 +375,7 @@ dependencies = { module=configure-gcc; on=all-ld; };
> >>   dependencies = { module=configure-gcc; on=all-gold; };
> >>   dependencies = { module=configure-gcc; on=all-libiconv; };
> >>   dependencies = { module=all-gcc; on=all-libiberty; hard=true; };
> >> +dependencies = { module=all-gcc; on=all-libgrust; };
> > 
> > That looks wrong?  Why is libgrust both a host and a target module?
> > Is that really necessary?  IIRC the rust frontend isn't written in
> > rust?
> 
> libgrust is both a host and target module as it implements some of the parser
> functionality - we had to split it from the frontend so that users of the
> procedural macro library could use it. So both the host and target link to
> that little bit of parser. Does that make sense?

I see.  OK then.

Richard.

> Best,
> 
> Arthur
> 
> > 
> > The other patch is OK to push.
> > 
> >>   dependencies = { module=all-gcc; on=all-gettext; };
> >>   dependencies = { module=all-gcc; on=all-mpfr; };
> >>   dependencies = { module=all-gcc; on=all-mpc; };
> >> diff --git a/Makefile.in b/Makefile.in
> >> index 263b979609b..edb0c8a9a42 100644
> >> --- a/Makefile.in
> >> +++ b/Makefile.in
> >> @@ -67558,6 +67558,16 @@ all-stagetrain-gcc: all-stagetrain-libiberty
> >>   all-stagefeedback-gcc: all-stagefeedback-libiberty
> >>   all-stageautoprofile-gcc: all-stageautoprofile-libiberty
> >>   all-stageautofeedback-gcc: all-stageautofeedback-libiberty
> >> +all-gcc: maybe-all-libgrust
> >> +all-stage1-gcc: maybe-all-stage1-libgrust
> >> +all-stage2-gcc: maybe-all-stage2-libgrust
> >> +all-stage3-gcc: maybe-all-stage3-libgrust
> >> +all-stage4-gcc: maybe-all-stage4-libgrust
> >> +all-stageprofile-gcc: maybe-all-stageprofile-libgrust
> >> +all-stagetrain-gcc: maybe-all-stagetrain-libgrust
> >> +all-stagefeedback-gcc: maybe-all-stagefeedback-libgrust
> >> +all-stageautoprofile-gcc: maybe-all-stageautoprofile-libgrust
> >> +all-stageautofeedback-gcc: maybe-all-stageautofeedback-libgrust
> >>   all-gcc: maybe-all-gettext
> >>   all-stage1-gcc: maybe-all-stage1-gettext
> >>   all-stage2-gcc: maybe-all-stage2-gettext
> >>
> > 
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)

[PATCH v4] aarch64,arm: Move branch-protection data to targets

[Szabolcs Nagy]

The branch-protection types are target specific, not the same on arm
and aarch64.  This currently affects pac-ret+b-key, but there will be
a new type on aarch64 that is not relevant for arm.

After the move, change aarch_ identifiers to aarch64_ or arm_ as
appropriate.

Refactor aarch_validate_mbranch_protection to take the target specific
branch-protection types as an argument.

In case of invalid input currently no hints are provided: the way
branch-protection types and subtypes can be mixed makes it difficult
without causing confusion.

gcc/ChangeLog:

* config/aarch64/aarch64.md: Rename aarch_ to aarch64_.
* config/aarch64/aarch64.opt: Likewise.
* config/aarch64/aarch64-c.cc (aarch64_update_cpp_builtins): Likewise.
* config/aarch64/aarch64.cc (aarch64_expand_prologue): Likewise.
(aarch64_expand_epilogue): Likewise.
(aarch64_post_cfi_startproc): Likewise.
(aarch64_handle_no_branch_protection): Copy and rename.
(aarch64_handle_standard_branch_protection): Likewise.
(aarch64_handle_pac_ret_protection): Likewise.
(aarch64_handle_pac_ret_leaf): Likewise.
(aarch64_handle_pac_ret_b_key): Likewise.
(aarch64_handle_bti_protection): Likewise.
(aarch64_override_options): Update branch protection validation.
(aarch64_handle_attr_branch_protection): Likewise.
* config/arm/aarch-common-protos.h (aarch_validate_mbranch_protection):
Pass branch protection type description as argument.
(struct aarch_branch_protect_type): Move from aarch-common.h.
* config/arm/aarch-common.cc (aarch_handle_no_branch_protection):
Remove.
(aarch_handle_standard_branch_protection): Remove.
(aarch_handle_pac_ret_protection): Remove.
(aarch_handle_pac_ret_leaf): Remove.
(aarch_handle_pac_ret_b_key): Remove.
(aarch_handle_bti_protection): Remove.
(aarch_validate_mbranch_protection): Pass branch protection type
description as argument.
* config/arm/aarch-common.h (enum aarch_key_type): Remove.
(struct aarch_branch_protect_type): Remove.
* config/arm/arm-c.cc (arm_cpu_builtins): Remove aarch_ra_sign_key.
* config/arm/arm.cc (arm_handle_no_branch_protection): Copy and rename.
(arm_handle_standard_branch_protection): Likewise.
(arm_handle_pac_ret_protection): Likewise.
(arm_handle_pac_ret_leaf): Likewise.
(arm_handle_bti_protection): Likewise.
(arm_configure_build_target): Update branch protection validation.
* config/arm/arm.opt: Remove aarch_ra_sign_key.
---
v4:
- pass types as argument to validation.
- make target specific types data static.

 gcc/config/aarch64/aarch64-c.cc  |  4 +-
 gcc/config/aarch64/aarch64.cc| 75 
 gcc/config/aarch64/aarch64.md|  2 +-
 gcc/config/aarch64/aarch64.opt   |  2 +-
 gcc/config/arm/aarch-common-protos.h | 19 ++-
 gcc/config/arm/aarch-common.cc   | 71 --
 gcc/config/arm/aarch-common.h| 20 
 gcc/config/arm/arm-c.cc  |  2 -
 gcc/config/arm/arm.cc| 55 +---
 gcc/config/arm/arm.opt   |  3 --
 10 files changed, 145 insertions(+), 108 deletions(-)

diff --git a/gcc/config/aarch64/aarch64-c.cc b/gcc/config/aarch64/aarch64-c.cc
index c3bc8c49034..b5a6917d06d 100644
--- a/gcc/config/aarch64/aarch64-c.cc
+++ b/gcc/config/aarch64/aarch64-c.cc
@@ -235,9 +235,9 @@ aarch64_update_cpp_builtins (cpp_reader *pfile)
   if (aarch_ra_sign_scope != AARCH_FUNCTION_NONE)
 {
   int v = 0;
-  if (aarch_ra_sign_key == AARCH_KEY_A)
+  if (aarch64_ra_sign_key == AARCH64_KEY_A)
v |= 1;
-  if (aarch_ra_sign_key == AARCH_KEY_B)
+  if (aarch64_ra_sign_key == AARCH64_KEY_B)
v |= 2;
   if (aarch_ra_sign_scope == AARCH_FUNCTION_ALL)
v |= 4;
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index a5a6b52730d..3ae8fc1878f 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -9478,12 +9478,12 @@ aarch64_expand_prologue (void)
   /* Sign return address for functions.  */
   if (aarch64_return_address_signing_enabled ())
 {
-  switch (aarch_ra_sign_key)
+  switch (aarch64_ra_sign_key)
{
- case AARCH_KEY_A:
+ case AARCH64_KEY_A:
insn = emit_insn (gen_paciasp ());
break;
- case AARCH_KEY_B:
+ case AARCH64_KEY_B:
insn = emit_insn (gen_pacibsp ());
break;
  default:
@@ -9897,12 +9897,12 @@ aarch64_expand_epilogue (rtx_call_insn *sibcall)
   if (aarch64_return_address_signing_enabled ()
   && (sibcall || !TARGET_ARMV8_3))
 {
-  switch (aarch_ra_sign_key)
+  switch (aarch64_ra_sign_key)
{
- case AARCH_KEY_A:
+ case AARCH64_KEY_A:
insn = emit_insn (gen_autiasp 

[pushed][PR112918][LRA]: Fixing IRA ICE on m68k

[Vladimir Makarov]

The following patch fixes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918

The patch was successfully bootstrapped and tested on x86_64, aarch64, 
ppc64le
commit 902a5931a1fbb04c65b48ca8b0f3827f6ff3b43e
Author: Vladimir N. Makarov 
Date:   Thu Jan 11 08:46:26 2024 -0500

[PR112918][LRA]: Fixing IRA ICE on m68k

Some GCC tests on m68K port of LRA is failed on `maximum number of
generated reload insns per insn achieved`.  The problem is in that for
subreg reload LRA can not narrow reg class more from ALL_REGS to
GENERAL_REGS and then to data regs or address regs.  The patch permits
narrowing reg class from reload insns if this results in successful
matching of reg operand.  This is the second version of the patch to
fix the PR.  This version adds matching with and without narrowing reg
class and preferring match without narrowing classes.

gcc/ChangeLog:

PR rtl-optimization/112918
* lra-constraints.cc (SMALL_REGISTER_CLASS_P): Move before in_class_p.
(in_class_p): Restrict condition for narrowing class in case of
allow_all_reload_class_changes_p.
(process_alt_operands): Try to match operand without and with
narrowing reg class.  Discourage narrowing the class.  Finish insn
matching only if there is no class narrowing.
(curr_insn_transform): Pass true to in_class_p for reg operand win.

diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc
index da7e1748d75..6132cd9844a 100644
--- a/gcc/lra-constraints.cc
+++ b/gcc/lra-constraints.cc
@@ -261,6 +261,13 @@ enough_allocatable_hard_regs_p (enum reg_class reg_class,
   return false;
 }
 
+/* True if C is a non-empty register class that has too few registers
+   to be safely used as a reload target class.	*/
+#define SMALL_REGISTER_CLASS_P(C)		\
+  (ira_class_hard_regs_num [(C)] == 1		\
+   || (ira_class_hard_regs_num [(C)] >= 1	\
+   && targetm.class_likely_spilled_p (C)))
+
 /* Return true if REG satisfies (or will satisfy) reg class constraint
CL.  Use elimination first if REG is a hard register.  If REG is a
reload pseudo created by this constraints pass, assume that it will
@@ -318,7 +325,11 @@ in_class_p (rtx reg, enum reg_class cl, enum reg_class *new_class,
   common_class = ira_reg_class_subset[rclass][cl];
   if (new_class != NULL)
 	*new_class = common_class;
-  return enough_allocatable_hard_regs_p (common_class, reg_mode);
+  return (enough_allocatable_hard_regs_p (common_class, reg_mode)
+	  /* Do not permit reload insn operand matching (new_class == NULL
+		 case) if the new class is too small.  */
+	  && (new_class != NULL || common_class == rclass
+		  || !SMALL_REGISTER_CLASS_P (common_class)));
 }
 }
 
@@ -923,13 +934,6 @@ operands_match_p (rtx x, rtx y, int y_hard_regno)
&& GET_MODE_SIZE (MODE).is_constant ()	\
&& !targetm.cannot_force_const_mem (MODE, X))
 
-/* True if C is a non-empty register class that has too few registers
-   to be safely used as a reload target class.	*/
-#define SMALL_REGISTER_CLASS_P(C)		\
-  (ira_class_hard_regs_num [(C)] == 1		\
-   || (ira_class_hard_regs_num [(C)] >= 1	\
-   && targetm.class_likely_spilled_p (C)))
-
 /* If REG is a reload pseudo, try to make its class satisfying CL.  */
 static void
 narrow_reload_pseudo_class (rtx reg, enum reg_class cl)
@@ -2137,6 +2141,7 @@ process_alt_operands (int only_alternative)
   /* True if output stack pointer reload should be generated for the current
  alternative.  */
   bool curr_alt_out_sp_reload_p;
+  bool curr_alt_class_change_p;
   rtx op;
   /* The register when the operand is a subreg of register, otherwise the
  operand itself.  */
@@ -2223,6 +2228,7 @@ process_alt_operands (int only_alternative)
   early_clobbered_regs_num = 0;
   curr_alt_out_sp_reload_p = false;
   curr_reuse_alt_p = true;
+  curr_alt_class_change_p = false;
   
   for (nop = 0; nop < n_operands; nop++)
 	{
@@ -2247,6 +2253,7 @@ process_alt_operands (int only_alternative)
 	  bool scratch_p;
 	  machine_mode mode;
 	  enum constraint_num cn;
+	  bool class_change_p = false;
 
 	  opalt_num = nalt * n_operands + nop;
 	  if (curr_static_id->operand_alternative[opalt_num].anything_ok)
@@ -2630,9 +2637,16 @@ process_alt_operands (int only_alternative)
    (this_alternative_exclude_start_hard_regs,
 hard_regno[nop]
 			win = true;
-		  else if (hard_regno[nop] < 0
-			   && in_class_p (op, this_alternative, NULL))
-			win = true;
+		  else if (hard_regno[nop] < 0)
+			{
+			  if (in_class_p (op, this_alternative, NULL))
+			win = true;
+			  else if (in_class_p (op, this_alternative, NULL, true))
+			{
+			  class_change_p = true;
+			  win = true;
+			}
+			}
 		}
 		  break;
 		}
@@ -2647,6 +2661,15 @@ process_alt_operands (int only_alternative)
 	  if (win)
 	{
 	  this_alternative_win = 

Re: [PATCH 2/2] gccrs: fixup: Fix missing build dependency

[Arthur Cohen]

Hi Richard,

On 1/11/24 15:23, Richard Biener wrote:

On Thu, 11 Jan 2024, Arthur Cohen wrote:


From: Pierre-Emmanuel Patry 

Fix the missing dependency between the gcc and libgrust.

ChangeLog:

* Makefile.def: Add a dependency to libgrust for all-gcc.
* Makefile.in: Regenerate the file.

Signed-off-by: Pierre-Emmanuel Patry 
---
  Makefile.def |  1 +
  Makefile.in  | 10 ++
  2 files changed, 11 insertions(+)

diff --git a/Makefile.def b/Makefile.def
index 1a256db5518..19954e7d731 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -375,6 +375,7 @@ dependencies = { module=configure-gcc; on=all-ld; };
  dependencies = { module=configure-gcc; on=all-gold; };
  dependencies = { module=configure-gcc; on=all-libiconv; };
  dependencies = { module=all-gcc; on=all-libiberty; hard=true; };
+dependencies = { module=all-gcc; on=all-libgrust; };


That looks wrong?  Why is libgrust both a host and a target module?
Is that really necessary?  IIRC the rust frontend isn't written in
rust?


libgrust is both a host and target module as it implements some of the 
parser functionality - we had to split it from the frontend so that 
users of the procedural macro library could use it. So both the host and 
target link to that little bit of parser. Does that make sense?


Best,

Arthur



The other patch is OK to push.


  dependencies = { module=all-gcc; on=all-gettext; };
  dependencies = { module=all-gcc; on=all-mpfr; };
  dependencies = { module=all-gcc; on=all-mpc; };
diff --git a/Makefile.in b/Makefile.in
index 263b979609b..edb0c8a9a42 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -67558,6 +67558,16 @@ all-stagetrain-gcc: all-stagetrain-libiberty
  all-stagefeedback-gcc: all-stagefeedback-libiberty
  all-stageautoprofile-gcc: all-stageautoprofile-libiberty
  all-stageautofeedback-gcc: all-stageautofeedback-libiberty
+all-gcc: maybe-all-libgrust
+all-stage1-gcc: maybe-all-stage1-libgrust
+all-stage2-gcc: maybe-all-stage2-libgrust
+all-stage3-gcc: maybe-all-stage3-libgrust
+all-stage4-gcc: maybe-all-stage4-libgrust
+all-stageprofile-gcc: maybe-all-stageprofile-libgrust
+all-stagetrain-gcc: maybe-all-stagetrain-libgrust
+all-stagefeedback-gcc: maybe-all-stagefeedback-libgrust
+all-stageautoprofile-gcc: maybe-all-stageautoprofile-libgrust
+all-stageautofeedback-gcc: maybe-all-stageautofeedback-libgrust
  all-gcc: maybe-all-gettext
  all-stage1-gcc: maybe-all-stage1-gettext
  all-stage2-gcc: maybe-all-stage2-gettext





--
Arthur Cohen 

Toolchain Engineer

Embecosm GmbH

Geschäftsführer: Jeremy Bennett
Niederlassung: Nürnberg
Handelsregister: HR-B 36368
www.embecosm.de

Fürther Str. 27
90429 Nürnberg


Tel.: 091 - 128 707 040
Fax: 091 - 128 707 077


OpenPGP_0x1B3465B044AD9C65.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/2] gccrs: fixup: Fix missing build dependency

[Richard Biener]

On Thu, 11 Jan 2024, Arthur Cohen wrote:

> From: Pierre-Emmanuel Patry 
> 
> Fix the missing dependency between the gcc and libgrust.
> 
> ChangeLog:
> 
>   * Makefile.def: Add a dependency to libgrust for all-gcc.
>   * Makefile.in: Regenerate the file.
> 
> Signed-off-by: Pierre-Emmanuel Patry 
> ---
>  Makefile.def |  1 +
>  Makefile.in  | 10 ++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/Makefile.def b/Makefile.def
> index 1a256db5518..19954e7d731 100644
> --- a/Makefile.def
> +++ b/Makefile.def
> @@ -375,6 +375,7 @@ dependencies = { module=configure-gcc; on=all-ld; };
>  dependencies = { module=configure-gcc; on=all-gold; };
>  dependencies = { module=configure-gcc; on=all-libiconv; };
>  dependencies = { module=all-gcc; on=all-libiberty; hard=true; };
> +dependencies = { module=all-gcc; on=all-libgrust; };

That looks wrong?  Why is libgrust both a host and a target module?
Is that really necessary?  IIRC the rust frontend isn't written in
rust?

The other patch is OK to push.

>  dependencies = { module=all-gcc; on=all-gettext; };
>  dependencies = { module=all-gcc; on=all-mpfr; };
>  dependencies = { module=all-gcc; on=all-mpc; };
> diff --git a/Makefile.in b/Makefile.in
> index 263b979609b..edb0c8a9a42 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -67558,6 +67558,16 @@ all-stagetrain-gcc: all-stagetrain-libiberty
>  all-stagefeedback-gcc: all-stagefeedback-libiberty
>  all-stageautoprofile-gcc: all-stageautoprofile-libiberty
>  all-stageautofeedback-gcc: all-stageautofeedback-libiberty
> +all-gcc: maybe-all-libgrust
> +all-stage1-gcc: maybe-all-stage1-libgrust
> +all-stage2-gcc: maybe-all-stage2-libgrust
> +all-stage3-gcc: maybe-all-stage3-libgrust
> +all-stage4-gcc: maybe-all-stage4-libgrust
> +all-stageprofile-gcc: maybe-all-stageprofile-libgrust
> +all-stagetrain-gcc: maybe-all-stagetrain-libgrust
> +all-stagefeedback-gcc: maybe-all-stagefeedback-libgrust
> +all-stageautoprofile-gcc: maybe-all-stageautoprofile-libgrust
> +all-stageautofeedback-gcc: maybe-all-stageautofeedback-libgrust
>  all-gcc: maybe-all-gettext
>  all-stage1-gcc: maybe-all-stage1-gettext
>  all-stage2-gcc: maybe-all-stage2-gettext
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)

[PATCH 2/2] gccrs: fixup: Fix missing build dependency

[Arthur Cohen]

From: Pierre-Emmanuel Patry 

Fix the missing dependency between the gcc and libgrust.

ChangeLog:

* Makefile.def: Add a dependency to libgrust for all-gcc.
* Makefile.in: Regenerate the file.

Signed-off-by: Pierre-Emmanuel Patry 
---
 Makefile.def |  1 +
 Makefile.in  | 10 ++
 2 files changed, 11 insertions(+)

diff --git a/Makefile.def b/Makefile.def
index 1a256db5518..19954e7d731 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -375,6 +375,7 @@ dependencies = { module=configure-gcc; on=all-ld; };
 dependencies = { module=configure-gcc; on=all-gold; };
 dependencies = { module=configure-gcc; on=all-libiconv; };
 dependencies = { module=all-gcc; on=all-libiberty; hard=true; };
+dependencies = { module=all-gcc; on=all-libgrust; };
 dependencies = { module=all-gcc; on=all-gettext; };
 dependencies = { module=all-gcc; on=all-mpfr; };
 dependencies = { module=all-gcc; on=all-mpc; };
diff --git a/Makefile.in b/Makefile.in
index 263b979609b..edb0c8a9a42 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -67558,6 +67558,16 @@ all-stagetrain-gcc: all-stagetrain-libiberty
 all-stagefeedback-gcc: all-stagefeedback-libiberty
 all-stageautoprofile-gcc: all-stageautoprofile-libiberty
 all-stageautofeedback-gcc: all-stageautofeedback-libiberty
+all-gcc: maybe-all-libgrust
+all-stage1-gcc: maybe-all-stage1-libgrust
+all-stage2-gcc: maybe-all-stage2-libgrust
+all-stage3-gcc: maybe-all-stage3-libgrust
+all-stage4-gcc: maybe-all-stage4-libgrust
+all-stageprofile-gcc: maybe-all-stageprofile-libgrust
+all-stagetrain-gcc: maybe-all-stagetrain-libgrust
+all-stagefeedback-gcc: maybe-all-stagefeedback-libgrust
+all-stageautoprofile-gcc: maybe-all-stageautoprofile-libgrust
+all-stageautofeedback-gcc: maybe-all-stageautofeedback-libgrust
 all-gcc: maybe-all-gettext
 all-stage1-gcc: maybe-all-stage1-gettext
 all-stage2-gcc: maybe-all-stage2-gettext
-- 
2.42.1

[PATCH 1/2] gccrs: fixup: Fix bootstrap build

[Arthur Cohen]

From: Pierre-Emmanuel Patry 

The bootstrap was failing due to a missing target which was not
available during the bootstrap.

ChangeLog:

* Makefile.def: Add libgrust target to bootstrap.
* Makefile.in: Regenerate.

Signed-off-by: Pierre-Emmanuel Patry 
---
 Makefile.def |   2 +-
 Makefile.in  | 816 +--
 2 files changed, 799 insertions(+), 19 deletions(-)

diff --git a/Makefile.def b/Makefile.def
index b889020afc6..1a256db5518 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -164,7 +164,7 @@ host_modules= { module= libcc1; 
extra_configure_flags=--enable-shared; };
 host_modules= { module= gotools; };
 host_modules= { module= libctf; bootstrap=true; };
 host_modules= { module= libsframe; bootstrap=true; };
-host_modules= { module= libgrust; };
+host_modules= { module= libgrust; bootstrap=true; };
 
 target_modules = { module= libstdc++-v3;
   bootstrap=true;
diff --git a/Makefile.in b/Makefile.in
index a1f64a2ab5a..263b979609b 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -1318,7 +1318,9 @@ all-host: maybe-all-libctf
 @if libsframe-no-bootstrap
 all-host: maybe-all-libsframe
 @endif libsframe-no-bootstrap
+@if libgrust-no-bootstrap
 all-host: maybe-all-libgrust
+@endif libgrust-no-bootstrap
 
 .PHONY: all-target
 
@@ -43995,7 +43997,6 @@ configure-libgrust: stage_current
 @if libgrust
 maybe-configure-libgrust: configure-libgrust
 configure-libgrust: 
-   @: $(MAKE); $(unstage)
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
test ! -f $(HOST_SUBDIR)/libgrust/Makefile || exit 0; \
@@ -44019,6 +44020,304 @@ configure-libgrust:
 
 
 
+.PHONY: configure-stage1-libgrust maybe-configure-stage1-libgrust
+maybe-configure-stage1-libgrust:
+@if libgrust-bootstrap
+maybe-configure-stage1-libgrust: configure-stage1-libgrust
+configure-stage1-libgrust:
+   @[ $(current_stage) = stage1 ] || $(MAKE) stage1-start
+   @$(SHELL) $(srcdir)/mkinstalldirs $(HOST_SUBDIR)/libgrust
+   @r=`${PWD_COMMAND}`; export r; \
+   s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
+   TFLAGS="$(STAGE1_TFLAGS)"; \
+   test ! -f $(HOST_SUBDIR)/libgrust/Makefile || exit 0; \
+   $(HOST_EXPORTS) \
+   CFLAGS="$(STAGE1_CFLAGS)"; export CFLAGS; \
+   CXXFLAGS="$(STAGE1_CXXFLAGS)"; export CXXFLAGS; \
+   LIBCFLAGS="$(LIBCFLAGS)"; export LIBCFLAGS;  \
+   echo Configuring stage 1 in $(HOST_SUBDIR)/libgrust; \
+   $(SHELL) $(srcdir)/mkinstalldirs $(HOST_SUBDIR)/libgrust; \
+   cd $(HOST_SUBDIR)/libgrust || exit 1; \
+   case $(srcdir) in \
+ /* | [A-Za-z]:[\\/]*) topdir=$(srcdir) ;; \
+ *) topdir=`echo $(HOST_SUBDIR)/libgrust/ | \
+   sed -e 's,\./,,g' -e 's,[^/]*/,../,g' `$(srcdir) ;; \
+   esac; \
+   module_srcdir=libgrust; \
+   $(SHELL) $$s/$$module_srcdir/configure \
+ --srcdir=$${topdir}/$$module_srcdir \
+ $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
+ --target=${target_alias} \
+  \
+ $(STAGE1_CONFIGURE_FLAGS)
+@endif libgrust-bootstrap
+
+.PHONY: configure-stage2-libgrust maybe-configure-stage2-libgrust
+maybe-configure-stage2-libgrust:
+@if libgrust-bootstrap
+maybe-configure-stage2-libgrust: configure-stage2-libgrust
+configure-stage2-libgrust:
+   @[ $(current_stage) = stage2 ] || $(MAKE) stage2-start
+   @$(SHELL) $(srcdir)/mkinstalldirs $(HOST_SUBDIR)/libgrust
+   @r=`${PWD_COMMAND}`; export r; \
+   s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
+   TFLAGS="$(STAGE2_TFLAGS)"; \
+   test ! -f $(HOST_SUBDIR)/libgrust/Makefile || exit 0; \
+   $(HOST_EXPORTS) \
+   $(POSTSTAGE1_HOST_EXPORTS) \
+   CFLAGS="$(STAGE2_CFLAGS)"; export CFLAGS; \
+   CXXFLAGS="$(STAGE2_CXXFLAGS)"; export CXXFLAGS; \
+   LIBCFLAGS="$(STAGE2_CFLAGS)"; export LIBCFLAGS;  \
+   echo Configuring stage 2 in $(HOST_SUBDIR)/libgrust; \
+   $(SHELL) $(srcdir)/mkinstalldirs $(HOST_SUBDIR)/libgrust; \
+   cd $(HOST_SUBDIR)/libgrust || exit 1; \
+   case $(srcdir) in \
+ /* | [A-Za-z]:[\\/]*) topdir=$(srcdir) ;; \
+ *) topdir=`echo $(HOST_SUBDIR)/libgrust/ | \
+   sed -e 's,\./,,g' -e 's,[^/]*/,../,g' `$(srcdir) ;; \
+   esac; \
+   module_srcdir=libgrust; \
+   $(SHELL) $$s/$$module_srcdir/configure \
+ --srcdir=$${topdir}/$$module_srcdir \
+ $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
+ --target=${target_alias} \
+ --with-build-libsubdir=$(HOST_SUBDIR) \
+ $(STAGE2_CONFIGURE_FLAGS)
+@endif libgrust-bootstrap
+
+.PHONY: configure-stage3-libgrust maybe-configure-stage3-libgrust
+maybe-configure-stage3-libgrust:
+@if libgrust-bootstrap
+maybe-configure-stage3-libgrust: configure-stage3-libgrust
+configure-stage3-libgrust:
+   @[ $(current_stage) = stage3 ] || $(MAKE) stage3-start
+   @$(SHELL) $(srcdir)/mkinstalldirs 

[PATCHSET] Fix Rust bootstrap for future libgrust changes

[Arthur Cohen]

Hi everyone,

Sorry about this - two simple changes to Makefile.def we had missed
during our first libgrust/ patchset, plus the associated regen of
Makefile.in in each commit.

Let me know if I should squash them together. I'll follow them up
with our entire patchset.

Best,

Arthur

Re: [PATCH]middle-end testsuite: remove -save-temps from many tests [PR113319]

[Richard Biener]

On Thu, 11 Jan 2024, Tamar Christina wrote:

> Hi All,
> 
> This removes -save-temps from the tests I've introduced to fix the LTO
> mismatches.
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
> and no issue
> 
> Ok for master?

OK.

Richard.

> Thanks,
> Tamar
> 
> gcc/testsuite/ChangeLog:
> 
>   PR testsuite/113319
>   * gcc.dg/bic-bitmask-13.c: Remove -save-temps.
>   * gcc.dg/bic-bitmask-14.c: Likewise.
>   * gcc.dg/bic-bitmask-15.c: Likewise.
>   * gcc.dg/bic-bitmask-16.c: Likewise.
>   * gcc.dg/bic-bitmask-17.c: Likewise.
>   * gcc.dg/bic-bitmask-18.c: Likewise.
>   * gcc.dg/bic-bitmask-19.c: Likewise.
>   * gcc.dg/bic-bitmask-20.c: Likewise.
>   * gcc.dg/bic-bitmask-21.c: Likewise.
>   * gcc.dg/bic-bitmask-22.c: Likewise.
>   * gcc.dg/bic-bitmask-7.c: Likewise.
>   * gcc.dg/vect/vect-early-break-run_1.c: Likewise.
>   * gcc.dg/vect/vect-early-break-run_10.c: Likewise.
>   * gcc.dg/vect/vect-early-break-run_2.c: Likewise.
>   * gcc.dg/vect/vect-early-break-run_3.c: Likewise.
>   * gcc.dg/vect/vect-early-break-run_4.c: Likewise.
>   * gcc.dg/vect/vect-early-break-run_5.c: Likewise.
>   * gcc.dg/vect/vect-early-break-run_6.c: Likewise.
>   * gcc.dg/vect/vect-early-break-run_7.c: Likewise.
>   * gcc.dg/vect/vect-early-break-run_8.c: Likewise.
>   * gcc.dg/vect/vect-early-break-run_9.c: Likewise.
> 
> --- inline copy of patch -- 
> diff --git a/gcc/testsuite/gcc.dg/bic-bitmask-13.c 
> b/gcc/testsuite/gcc.dg/bic-bitmask-13.c
> index 
> bac86c2cfcebb4fd83eef1ea276026af97bcb096..141b03d6df772e9bdfaaf832287a1e91ebc6be0d
>  100644
> --- a/gcc/testsuite/gcc.dg/bic-bitmask-13.c
> +++ b/gcc/testsuite/gcc.dg/bic-bitmask-13.c
> @@ -1,5 +1,5 @@
>  /* { dg-do run } */
> -/* { dg-options "-O0 -save-temps -fdump-tree-dce" } */
> +/* { dg-options "-O0 -fdump-tree-dce" } */
>  
>  #include 
>  
> diff --git a/gcc/testsuite/gcc.dg/bic-bitmask-14.c 
> b/gcc/testsuite/gcc.dg/bic-bitmask-14.c
> index 
> ec3bd6a7e04de93e60b0a606ec4cabf5bb90af22..59a008c01e22b21cbe4b8d15e411046d7940a7cf
>  100644
> --- a/gcc/testsuite/gcc.dg/bic-bitmask-14.c
> +++ b/gcc/testsuite/gcc.dg/bic-bitmask-14.c
> @@ -1,5 +1,5 @@
>  /* { dg-do run } */
> -/* { dg-options "-O1 -save-temps -fdump-tree-dce" } */
> +/* { dg-options "-O1 -fdump-tree-dce" } */
>  
>  #include 
>  
> diff --git a/gcc/testsuite/gcc.dg/bic-bitmask-15.c 
> b/gcc/testsuite/gcc.dg/bic-bitmask-15.c
> index 
> 8bdf1ea4eb2e5117c6d84b0d6cdf95798c4b8e2c..c28d9b13f4eb300414cdf19ab0550a888b8edeec
>  100644
> --- a/gcc/testsuite/gcc.dg/bic-bitmask-15.c
> +++ b/gcc/testsuite/gcc.dg/bic-bitmask-15.c
> @@ -1,5 +1,5 @@
>  /* { dg-do run } */
> -/* { dg-options "-O1 -save-temps -fdump-tree-dce" } */
> +/* { dg-options "-O1 -fdump-tree-dce" } */
>  
>  #include 
>  
> diff --git a/gcc/testsuite/gcc.dg/bic-bitmask-16.c 
> b/gcc/testsuite/gcc.dg/bic-bitmask-16.c
> index 
> cfea925b59104ad5c84beea90cea5e6ec9b1e787..f93912f0cc579b3c56e24577b36d755ec3737ed6
>  100644
> --- a/gcc/testsuite/gcc.dg/bic-bitmask-16.c
> +++ b/gcc/testsuite/gcc.dg/bic-bitmask-16.c
> @@ -1,5 +1,5 @@
>  /* { dg-do run } */
> -/* { dg-options "-O1 -save-temps -fdump-tree-dce" } */
> +/* { dg-options "-O1 -fdump-tree-dce" } */
>  
>  #include 
>  
> diff --git a/gcc/testsuite/gcc.dg/bic-bitmask-17.c 
> b/gcc/testsuite/gcc.dg/bic-bitmask-17.c
> index 
> 86873b97f27c5fe6e1495ac0cf3471b7782a8067..f8d651b829b4f3c771bc2db056f15aa385c8302e
>  100644
> --- a/gcc/testsuite/gcc.dg/bic-bitmask-17.c
> +++ b/gcc/testsuite/gcc.dg/bic-bitmask-17.c
> @@ -1,5 +1,5 @@
>  /* { dg-do run } */
> -/* { dg-options "-O1 -save-temps -fdump-tree-dce" } */
> +/* { dg-options "-O1 -fdump-tree-dce" } */
>  
>  #include 
>  
> diff --git a/gcc/testsuite/gcc.dg/bic-bitmask-18.c 
> b/gcc/testsuite/gcc.dg/bic-bitmask-18.c
> index 
> 70bab0c520321ba13c6dd7969d1b51708dc3c71f..d6242fe3c19b8e958e4eca5ae8a633c376f09794
>  100644
> --- a/gcc/testsuite/gcc.dg/bic-bitmask-18.c
> +++ b/gcc/testsuite/gcc.dg/bic-bitmask-18.c
> @@ -1,5 +1,5 @@
>  /* { dg-do run } */
> -/* { dg-options "-O1 -save-temps -fdump-tree-dce" } */
> +/* { dg-options "-O1 -fdump-tree-dce" } */
>  
>  #include 
>  
> diff --git a/gcc/testsuite/gcc.dg/bic-bitmask-19.c 
> b/gcc/testsuite/gcc.dg/bic-bitmask-19.c
> index 
> c4620dfaad3b8fdbb0ba214bbd69b975f37c68db..aa139da5c1ede2aa422c7e56956051c3b854f983
>  100644
> --- a/gcc/testsuite/gcc.dg/bic-bitmask-19.c
> +++ b/gcc/testsuite/gcc.dg/bic-bitmask-19.c
> @@ -1,5 +1,5 @@
>  /* { dg-do run } */
> -/* { dg-options "-O1 -save-temps -fdump-tree-dce" } */
> +/* { dg-options "-O1 -fdump-tree-dce" } */
>  
>  #include 
>  
> diff --git a/gcc/testsuite/gcc.dg/bic-bitmask-20.c 
> b/gcc/testsuite/gcc.dg/bic-bitmask-20.c
> index 
> a114122e075eab6be651b4e0954f084a2fd427c9..849eca4e51489b7f68f6695de3389ed5a0697ef2
>  100644
> --- a/gcc/testsuite/gcc.dg/bic-bitmask-20.c
> +++ b/gcc/testsuite/gcc.dg/bic-bitmask-20.c
> @@ -1,5 +1,5 @@
>  /* { dg-do 

Re: [PATCH]middle-end: make memory analysis for early break more deterministic [PR113135]

[Richard Biener]

On Thu, 11 Jan 2024, Tamar Christina wrote:

> Hi All,
> 
> Instead of searching for where to move stores to, they should always be in
> exit belonging to the latch.  We can only ever delay stores and even if we
> pick a different exit than the latch one as the main one, effects still
> happen in program order when vectorized.  If we don't move the stores to the
> latch exit but instead to whever we pick as the "main" exit then we can
> perform incorrect memory accesses (luckily these are trapped by verify_ssa).
> 
> We used to iterate over the conds and check the loads and stores inside them.
> However this relies on the conds being ordered in program order.  Additionally
> if there is a basic block between two conds we would not have analyzed it.
> 
> Instead this now walks from the preds of the destination basic block up to the
> loop header and analyzes every block along the way.  As a later optimization 
> we
> could stop as soon as we've seen all the BBs we have conds for.  For now the
> header will always contain the first cond, but this can change when we support
> arbitrary control flow.
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
> and no issues normally and with --enable-checking=release --enable-lto
> --with-build-config=bootstrap-O3 --enable-checking=yes,rtl,extra.
> 
> Ok for master?
> 
> Thanks,
> Tamar
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/113135
>   * tree-vect-data-refs.cc (vect_analyze_early_break_dependences): Rework
>   dependency analysis.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/113135
>   * gcc.dg/vect/vect-early-break_103-pr113135.c: New test.
> 
> --- inline copy of patch -- 
> diff --git a/gcc/testsuite/gcc.dg/vect/vect-early-break_103-pr113135.c 
> b/gcc/testsuite/gcc.dg/vect/vect-early-break_103-pr113135.c
> new file mode 100644
> index 
> ..bbad7ee2cb18086e470f4a2a2dc0a2b345bbdd71
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/vect/vect-early-break_103-pr113135.c
> @@ -0,0 +1,14 @@
> +/* { dg-do compile } */
> +/* { dg-add-options vect_early_break } */
> +/* { dg-require-effective-target vect_early_break } */
> +/* { dg-require-effective-target vect_int } */
> +/* { dg-additional-options "-w" } */
> +
> +char UnpackReadTables_BitLength[20];
> +int UnpackReadTables_ZeroCount;
> +void UnpackReadTables() {
> +  for (unsigned I = 0; I < 20;)
> +while (UnpackReadTables_ZeroCount-- &&
> +   I < sizeof(UnpackReadTables_BitLength))
> +  UnpackReadTables_BitLength[I++] = 0;
> +}
> diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
> index 
> 3d9673fb0b580ff21ff151dc5c199840df41a1cd..6b76eee72cb7d09de5f443589b4fc3a0e8c2584f
>  100644
> --- a/gcc/tree-vect-data-refs.cc
> +++ b/gcc/tree-vect-data-refs.cc
> @@ -671,13 +671,18 @@ vect_analyze_early_break_dependences (loop_vec_info 
> loop_vinfo)
>"loop contains multiple exits, analyzing"
>" statement dependencies.\n");
>  
> -  for (gimple *c : LOOP_VINFO_LOOP_CONDS (loop_vinfo))
> -{
> -  stmt_vec_info loop_cond_info = loop_vinfo->lookup_stmt (c);
> -  if (STMT_VINFO_TYPE (loop_cond_info) != loop_exit_ctrl_vec_info_type)
> - continue;
> +  /* Since we don't support general control flow, the location we'll move the
> + side-effects to is always the latch connected exit.  When we support
> + general control flow we can do better but for now this is fine.  */
> +  dest_bb = single_pred (loop->latch);
> +  auto_vec  workset;
> +  for (auto e: dest_bb->preds)
> +workset.safe_push (e);

If you handle an arbitrary number of preds here ...

> -  gimple_stmt_iterator gsi = gsi_for_stmt (c);
> +  while (!workset.is_empty ())
> +{
> +  basic_block bb = workset.pop ()->src;
> +  gimple_stmt_iterator gsi = gsi_last_bb (bb);
>  
>/* Now analyze all the remaining statements and try to determine which
>instructions are allowed/needed to be moved.  */
> @@ -705,10 +710,10 @@ vect_analyze_early_break_dependences (loop_vec_info 
> loop_vinfo)
>   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
>"early breaks only supported on statically"
>" allocated objects.\n");
> -   return opt_result::failure_at (c,
> +   return opt_result::failure_at (stmt,
>"can't safely apply code motion to "
>"dependencies of %G to vectorize "
> -  "the early exit.\n", c);
> +  "the early exit.\n", stmt);
>   }
>  
> tree refop = TREE_OPERAND (obj, 0);
> @@ -720,10 +725,10 @@ vect_analyze_early_break_dependences (loop_vec_info 
> loop_vinfo)
>   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
>"early breaks only supported on"
>   

[PATCH] tree-optimization/113126 - vector extension compare optimization

[Richard Biener]

The following makes sure the resulting boolean type is the same
when eliding a float extension.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

PR tree-optimization/113126
* match.pd ((double)float CMP (double)float -> float CMP float):
Make sure the boolean type is the same.
* fold-const.cc (fold_binary_loc): Likewise.

* gcc.dg/torture/pr113126.c: New testcase.
---
 gcc/fold-const.cc   |  3 ++-
 gcc/match.pd|  9 +
 gcc/testsuite/gcc.dg/torture/pr113126.c | 15 +++
 3 files changed, 22 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr113126.c

diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 3a9d78b0c11..585c5099a37 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -12900,7 +12900,8 @@ fold_binary_loc (location_t loc, enum tree_code code, 
tree type,
if (element_precision (TREE_TYPE (targ1)) > element_precision (newtype))
  newtype = TREE_TYPE (targ1);
 
-   if (element_precision (newtype) < element_precision (TREE_TYPE (arg0)))
+   if (element_precision (newtype) < element_precision (TREE_TYPE (arg0))
+   && is_truth_type_for (newtype, type))
  return fold_build2_loc (loc, code, type,
  fold_convert_loc (loc, newtype, targ0),
  fold_convert_loc (loc, newtype, targ1));
diff --git a/gcc/match.pd b/gcc/match.pd
index 876a9d1c06e..abbd03742f9 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -6792,11 +6792,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   && exact_real_truncate (TYPE_MODE (double_type_node), ))
 type1 = double_type_node;
 }
-  tree newtype
-= (element_precision (TREE_TYPE (@00)) > element_precision (type1)
-  ? TREE_TYPE (@00) : type1);
+   tree newtype
+= (element_precision (TREE_TYPE (@00)) > element_precision (type1)
+   ? TREE_TYPE (@00) : type1);
  }
- (if (element_precision (TREE_TYPE (@0)) > element_precision (newtype))
+ (if (element_precision (TREE_TYPE (@0)) > element_precision (newtype)
+ && is_truth_type_for (newtype, type))
   (cmp (convert:newtype @00) (convert:newtype @10
 
 
diff --git a/gcc/testsuite/gcc.dg/torture/pr113126.c 
b/gcc/testsuite/gcc.dg/torture/pr113126.c
new file mode 100644
index 000..4aa38e0a255
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr113126.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+
+typedef float __attribute__((__vector_size__ (8))) F;
+typedef double __attribute__((__vector_size__ (16))) G;
+
+F f;
+G g;
+
+F
+foo (void)
+{
+  G h = __builtin_convertvector (f, G);
+  g = h <= h;
+  return f;
+}
-- 
2.35.3

[PATCH] tree-optimization/112505 - bit-precision induction vectorization

[Richard Biener]

Vectorization of bit-precision inductions isn't implemented but we
don't check this, instead we ICE during transform.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

PR tree-optimization/112505
* tree-vect-loop.cc (vectorizable_induction): Reject
bit-precision induction.

* gcc.dg/vect/pr112505.c: New testcase.
---
 gcc/testsuite/gcc.dg/vect/pr112505.c | 14 ++
 gcc/tree-vect-loop.cc|  9 +
 2 files changed, 23 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/vect/pr112505.c

diff --git a/gcc/testsuite/gcc.dg/vect/pr112505.c 
b/gcc/testsuite/gcc.dg/vect/pr112505.c
new file mode 100644
index 000..56546c1095a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr112505.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-O3" } */
+
+short int w9;
+struct T {
+  short a : 14;
+  int b;
+};
+struct T v;
+void zc()
+{
+  for(int i = 0; i < 4; i ++)
+w9 *= v.b ? v.a-- < 0 : 0;
+}
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 1bdad0fbe0f..38bd8267ee1 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -10037,6 +10037,15 @@ vectorizable_induction (loop_vec_info loop_vinfo,
 
   step_expr = STMT_VINFO_LOOP_PHI_EVOLUTION_PART (stmt_info);
   gcc_assert (step_expr != NULL_TREE);
+  if (INTEGRAL_TYPE_P (TREE_TYPE (step_expr))
+  && !type_has_mode_precision_p (TREE_TYPE (step_expr)))
+{
+  if (dump_enabled_p ())
+   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+"bit-precision induction vectorization not "
+"supported.\n");
+  return false;
+}
   tree step_vectype = get_same_sized_vectype (TREE_TYPE (step_expr), vectype);
 
   /* Check for backend support of PLUS/MINUS_EXPR. */
-- 
2.35.3

Re：Re：[PATCH v5] RISC-V: Add support for xtheadvector-specific intrinsics.

[joshua]

Is the patch with !TARGET_XTHEADVECTOR for sext/zext
patterns removed OK to commit?
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642657.html




--
发件人：juzhe.zh...@rivai.ai 
发送时间：2024年1月11日(星期四) 18:56
收件人："cooper.joshua"; 
"gcc-patches"
抄　送：Jim Wilson; palmer; 
andrew; "philipp.tomsich"; 
jeffreyalaw; 
"christoph.muellner"; 
jinma; "cooper.qu"
主　题：Re: Re：[PATCH v5] RISC-V: Add support for xtheadvector-specific intrinsics.


Yes.


juzhe.zh...@rivai.ai

 
发件人： joshua
发送时间： 2024-01-11 18:54
收件人： juzhe.zh...@rivai.ai; gcc-patches
抄送： Jim Wilson; palmer; andrew; philipp.tomsich; jeffreyalaw; 
christoph.muellner; jinma; cooper.qu
主题： Re：[PATCH v5] RISC-V: Add support for xtheadvector-specific intrinsics.

Do you mean removing TARGET_XTHEADVECTOR for sext/zext patterns
and then resending the  "RISC-V: Handle differences between XTheadvector
and Vector" patch?
 
 
 
 
 
--
发件人：juzhe.zh...@rivai.ai 
发送时间：2024年1月11日(星期四) 17:57
收件人："cooper.joshua"; 
"gcc-patches"
抄　送：Jim Wilson; palmer; 
andrew; "philipp.tomsich"; 
jeffreyalaw; 
"christoph.muellner"; 
"cooper.joshua"; 
jinma; "cooper.qu"
主　题：Re: [PATCH v5] RISC-V: Add support for xtheadvector-specific intrinsics.
 
 
LGTM. Could you resend the patch "RISC-V: Handle differences between 
XTheadvector and Vector
 
 
Thanks.
juzhe.zh...@rivai.ai
 
 
From: Jun Sha (Joshua)
Date: 2024-01-11 17:52
To: gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw; 
christoph.muellner; juzhe.zhong; Jun Sha (Joshua); Jin Ma; Xianmiao Qu
Subject: [PATCH v5] RISC-V: Add support for xtheadvector-specific intrinsics.
 
This patch only involves the generation of xtheadvector
special load/store instructions and vext instructions.
 
gcc/ChangeLog:
 
* config/riscv/riscv-vector-builtins-bases.cc
(class th_loadstore_width): Define new builtin bases.
(class th_extract): Define new builtin bases.
(BASE): Define new builtin bases.
* config/riscv/riscv-vector-builtins-bases.h:
Define new builtin class.
* config/riscv/riscv-vector-builtins-shapes.cc
(struct th_loadstore_width_def): Define new builtin shapes.
(struct th_indexed_loadstore_width_def):
Define new builtin shapes.
(struct th_extract_def): Define new builtin shapes.
(SHAPE): Define new builtin shapes.
* config/riscv/riscv-vector-builtins-shapes.h:
Define new builtin shapes.
* config/riscv/riscv-vector-builtins.cc (DEF_RVV_FUNCTION):
* config/riscv/riscv-vector-builtins.h (enum required_ext):
(struct function_group_info):
* config/riscv/t-riscv: Add thead-vector-builtins-functions.def
* config/riscv/thead-vector.md
(@pred_mov_width): Add new patterns.
(*pred_mov_width): Likewise.
(@pred_store_width): Likewise.
(@pred_strided_load_width): Likewise.
(@pred_strided_store_width): Likewise.
(@pred_indexed_load_width): Likewise.
(@pred_indexed_store_width):
(@pred_th_extract): Likewise.
(*pred_th_extract): Likewise.
* config/riscv/thead-vector-builtins-functions.def: New file.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/xtheadvector/vlb-vsb.c: New test.
* gcc.target/riscv/rvv/xtheadvector/vlbu-vsb.c: New test.
* gcc.target/riscv/rvv/xtheadvector/vlh-vsh.c: New test.
* gcc.target/riscv/rvv/xtheadvector/vlhu-vsh.c: New test.
* gcc.target/riscv/rvv/xtheadvector/vlw-vsw.c: New test.
* gcc.target/riscv/rvv/xtheadvector/vlwu-vsw.c: New test.

Co-authored-by: Jin Ma 
Co-authored-by: Xianmiao Qu 
Co-authored-by: Christoph Müllner 
---
 .../riscv/riscv-vector-builtins-bases.cc  | 139 ++
 .../riscv/riscv-vector-builtins-bases.h   |  31 +++
 .../riscv/riscv-vector-builtins-shapes.cc | 160 +++
 .../riscv/riscv-vector-builtins-shapes.h  |   3 +
 gcc/config/riscv/riscv-vector-builtins.cc |  70 +
 gcc/config/riscv/riscv-vector-builtins.h  |   3 +
 gcc/config/riscv/t-riscv  |   1 +
 .../riscv/thead-vector-builtins-functions.def |  39 +++
 gcc/config/riscv/thead-vector.md  | 250 ++
 .../riscv/rvv/xtheadvector/vlb-vsb.c  |  68 +
 .../riscv/rvv/xtheadvector/vlbu-vsb.c |  68 +
 .../riscv/rvv/xtheadvector/vlh-vsh.c  |  68 +
 .../riscv/rvv/xtheadvector/vlhu-vsh.c |  68 +
 .../riscv/rvv/xtheadvector/vlw-vsw.c  |  68 +
 .../riscv/rvv/xtheadvector/vlwu-vsw.c |  68 +
 15 files changed, 1104 insertions(+)
 create mode 100644 gcc/config/riscv/thead-vector-builtins-functions.def
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/vlb-vsb.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/xtheadvector/vlbu-vsb.c
 create mode 100644 

[PATCH] [s390] target/112280 - properly guard permute query

[Richard Biener]

The following adds guards avoiding code generation to
expand_perm_as_a_vlbr_vstbr_candidate when d.testing_p.

Built and tested on the testcase in the PR.

OK to push as obvious?  Otherwise please pick up, test and push.

Thanks,
Richard.

PR target/112280
* config/s390/s390.cc (expand_perm_as_a_vlbr_vstbr_candidate):
Do not generate code when d.testing_p.
---
 gcc/config/s390/s390.cc | 36 
 1 file changed, 24 insertions(+), 12 deletions(-)

diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
index 748ad9cd932..f182c26e78b 100644
--- a/gcc/config/s390/s390.cc
+++ b/gcc/config/s390/s390.cc
@@ -17867,33 +17867,45 @@ expand_perm_as_a_vlbr_vstbr_candidate (const struct 
expand_vec_perm_d )
 
   if (memcmp (d.perm, perm[0], MAX_VECT_LEN) == 0)
 {
-  rtx target = gen_rtx_SUBREG (V8HImode, d.target, 0);
-  rtx op0 = gen_rtx_SUBREG (V8HImode, d.op0, 0);
-  emit_insn (gen_bswapv8hi (target, op0));
+  if (!d.testing_p)
+   {
+ rtx target = gen_rtx_SUBREG (V8HImode, d.target, 0);
+ rtx op0 = gen_rtx_SUBREG (V8HImode, d.op0, 0);
+ emit_insn (gen_bswapv8hi (target, op0));
+   }
   return true;
 }
 
   if (memcmp (d.perm, perm[1], MAX_VECT_LEN) == 0)
 {
-  rtx target = gen_rtx_SUBREG (V4SImode, d.target, 0);
-  rtx op0 = gen_rtx_SUBREG (V4SImode, d.op0, 0);
-  emit_insn (gen_bswapv4si (target, op0));
+  if (!d.testing_p)
+   {
+ rtx target = gen_rtx_SUBREG (V4SImode, d.target, 0);
+ rtx op0 = gen_rtx_SUBREG (V4SImode, d.op0, 0);
+ emit_insn (gen_bswapv4si (target, op0));
+   }
   return true;
 }
 
   if (memcmp (d.perm, perm[2], MAX_VECT_LEN) == 0)
 {
-  rtx target = gen_rtx_SUBREG (V2DImode, d.target, 0);
-  rtx op0 = gen_rtx_SUBREG (V2DImode, d.op0, 0);
-  emit_insn (gen_bswapv2di (target, op0));
+  if (!d.testing_p)
+   {
+ rtx target = gen_rtx_SUBREG (V2DImode, d.target, 0);
+ rtx op0 = gen_rtx_SUBREG (V2DImode, d.op0, 0);
+ emit_insn (gen_bswapv2di (target, op0));
+   }
   return true;
 }
 
   if (memcmp (d.perm, perm[3], MAX_VECT_LEN) == 0)
 {
-  rtx target = gen_rtx_SUBREG (V1TImode, d.target, 0);
-  rtx op0 = gen_rtx_SUBREG (V1TImode, d.op0, 0);
-  emit_insn (gen_bswapv1ti (target, op0));
+  if (!d.testing_p)
+   {
+ rtx target = gen_rtx_SUBREG (V1TImode, d.target, 0);
+ rtx op0 = gen_rtx_SUBREG (V1TImode, d.op0, 0);
+ emit_insn (gen_bswapv1ti (target, op0));
+   }
   return true;
 }
 
-- 
2.35.3

Re: [PATCH][_GLIBCXX_INLINE_VERSION] Fix friend declarations

[Jonathan Wakely]

On Wed, 13 Sept 2023 at 21:50, Jonathan Wakely  wrote:
>
> On Wed, 13 Sept 2023 at 21:47, François Dumont  wrote:
> >
> > It's working and what's I've committed.
>
> Nice, thanks!
>
>
> >
> > Thanks
> >
> > On 12/09/2023 19:04, Jonathan Wakely wrote:
> > > On Tue, 12 Sept 2023 at 17:47, Jonathan Wakely  wrote:
> > >> On Wed, 23 Aug 2023 at 18:35, François Dumont via Libstdc++
> > >>  wrote:
> > >>> Hi
> > >>>
> > >>> The few tests that are failing in versioned namespace mode are due to
> > >>> those friend declarations.
> > >>>
> > >>> This is a fix proposal even if I considered 2 other options:
> > >>>
> > >>> 1. Make __format::_Arg_store a struct and so do not bother with friend
> > >>> declarations.
> > >>>
> > >>> 2. Consider it as a compiler bug and do nothing. In this case I think we
> > >>> might still need this patch to avoid a non-working format library in
> > >>> versioned namespace mode in gcc 14 if compiler bug is not fixed.
> > >> It definitely is a compiler bug, this is PR c++/59256.
> > >>
> > >> Please add a comment to the new macro definition, so we remember to
> > >> remove it when it's not needed:
> > >>
> > >>
> > >> #if _GLIBCXX_INLINE_VERSION
> > >> // Needed because of PR c++/59526
> > >> # define _GLIBCXX_STD_V std::__8
> > >> #else
> > >> # define _GLIBCXX_STD_V std
> > >> #endif
> > >>
> > >>
> > >> OK with that change, thanks.
> > > Actually, are you sure the friend std::basic_format_args declaration
> > > needs to change?
> > >
> > > I only see errors for the friend function, not the friend class. So
> > > this seems to fix it:
> > >
> > > --- a/libstdc++-v3/include/std/format
> > > +++ b/libstdc++-v3/include/std/format
> > > @@ -3437,7 +3437,13 @@ namespace __format
> > >
> > >template
> > > friend auto
> > > -   std::make_format_args(_Argz&&...) noexcept;
> > > +#if _GLIBCXX_INLINE_VERSION
> > > +   // Needed for PR c++/59526

Except that should be 59256 :-(

My fault, I'll fix it.


> > > +   std::__8::
> > > +#else
> > > +   std::
> > > +#endif
> > > +   make_format_args(_Argz&&...) noexcept;
> > >
> > >// For a sufficiently small number of arguments we only store 
> > > values.
> > >// basic_format_args can get the types from the _Args pack.
> > >
> > >
> > >
> > >
> > >>
> > >>> I can also define _GLIBCXX_STD_V at  level to limit impact.
> > >>>
> > >>>   libstdc++: [_GLIBCXX_INLINE_VERSION] Fix  friend 
> > >>> declarations
> > >>>
> > >>>   GCC do not consider the inline namespace in friend declarations. 
> > >>> We
> > >>> need
> > >>>   to explicit this namespace.
> > >>>
> > >>>   libstdc++-v3/ChangeLog:
> > >>>
> > >>>   * include/bits/c++config (_GLIBCXX_STD_V): New macro 
> > >>> giving
> > >>> current
> > >>>   std namespace with optionally the version namespace.
> > >>>   * include/std/format (std::__format::_Arg_store): Use
> > >>> latter on friend
> > >>>   declarations.
> > >>>
> > >>> Tested under versioned mode.
> > >>>
> > >>> Ok to commit ?
> > >>>
> > >>> François
> >