[PATCH v2] RISC-V: Fix fortran ICE/PR111546 when RV32 vec_init

2023-09-23 Thread pan2 . li
From: Pan Li 

When broadcast the reperated element, we take the mask_int_mode
by mistake. This patch would like to fix it by leveraging the machine
mode of the element.

The below test case in RV32 will be fixed.

* gcc/testsuite/gfortran.dg/overload_5.f90

PR target/111546

gcc/ChangeLog:

* config/riscv/riscv-v.cc
(expand_vector_init_merge_repeating_sequence): Bugfix

Signed-off-by: Pan Li 
---
 gcc/config/riscv/riscv-v.cc | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index c2466b1354f..a1ffefb23f3 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -2054,12 +2054,17 @@ static void
 expand_vector_init_merge_repeating_sequence (rtx target,
 const rvv_builder )
 {
-  machine_mode dup_mode = get_repeating_sequence_dup_machine_mode (builder);
-  machine_mode mask_mode = get_mask_mode (builder.mode ());
+  /* We can't use BIT mode (BI) directly to generate mask = 0b01010...
+ since we don't have such instruction in RVV.
+ Instead, we should use INT mode (QI/HI/SI/DI) with integer move
+ instruction to generate the mask data we want.  */
+  machine_mode mask_int_mode
+= get_repeating_sequence_dup_machine_mode (builder);
+  machine_mode mask_bit_mode = get_mask_mode (builder.mode ());
   uint64_t full_nelts = builder.full_nelts ().to_constant ();
 
   /* Step 1: Broadcast the first pattern.  */
-  rtx ops[] = {target, force_reg (GET_MODE_INNER (dup_mode), builder.elt (0))};
+  rtx ops[] = {target, force_reg (builder.inner_mode (), builder.elt (0))};
   emit_vlmax_insn (code_for_pred_broadcast (builder.mode ()),
UNARY_OP, ops);
   /* Step 2: Merge the rest iteration of pattern.  */
@@ -2067,8 +2072,8 @@ expand_vector_init_merge_repeating_sequence (rtx target,
 {
   /* Step 2-1: Generate mask register v0 for each merge.  */
   rtx merge_mask = builder.get_merge_scalar_mask (i);
-  rtx mask = gen_reg_rtx (mask_mode);
-  rtx dup = gen_reg_rtx (dup_mode);
+  rtx mask = gen_reg_rtx (mask_bit_mode);
+  rtx dup = gen_reg_rtx (mask_int_mode);
 
   if (full_nelts <= builder.inner_bits_size ()) /* vmv.s.x.  */
{
@@ -2078,14 +2083,15 @@ expand_vector_init_merge_repeating_sequence (rtx target,
}
   else /* vmv.v.x.  */
{
- rtx ops[] = {dup, force_reg (GET_MODE_INNER (dup_mode), merge_mask)};
+ rtx ops[] = {dup,
+  force_reg (GET_MODE_INNER (mask_int_mode), merge_mask)};
  rtx vl = gen_int_mode (CEIL (full_nelts, builder.inner_bits_size ()),
 Pmode);
- emit_nonvlmax_insn (code_for_pred_broadcast (dup_mode), UNARY_OP,
+ emit_nonvlmax_insn (code_for_pred_broadcast (mask_int_mode), UNARY_OP,
   ops, vl);
}
 
-  emit_move_insn (mask, gen_lowpart (mask_mode, dup));
+  emit_move_insn (mask, gen_lowpart (mask_bit_mode, dup));
 
   /* Step 2-2: Merge pattern according to the mask.  */
   rtx ops[] = {target, target, builder.elt (i), mask};
-- 
2.34.1



Re: [PATCH v1] RISC-V: Fix fortran ICE/PR111546 when RV32 vec_init

2023-09-23 Thread 钟居哲
The codes here are quite confusing.
Plz rename it:

  /* We can't use BIT mode (BI) directly to generate mask = 0b01010...
 since we don't have such instruction in RVV.
 Instead, we should use INT mode (QI/HI/SI/DI) with integer move instruction
 to generate the mask data we want.  */
  machine_mode mask_int_mode = get_repeating_sequence_dup_machine_mode 
(builder);
  machine_mode mask_bit_mode = get_mask_mode (builder.mode ());



juzhe.zh...@rivai.ai
 
From: pan2.li
Date: 2023-09-24 11:45
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng; patrick
Subject: [PATCH v1] RISC-V: Fix fortran ICE/PR111546 when RV32 vec_init
From: Pan Li 
 
When broadcast the reperated element, we take the mask machine mode
by mistake. This patch would like to fix it by leveraging the machine
mode of the element.
 
The below test case in RV32 will be fixed.
 
* gcc/testsuite/gfortran.dg/overload_5.f90
 
PR target/111546
 
gcc/ChangeLog:
 
* config/riscv/riscv-v.cc
(expand_vector_init_merge_repeating_sequence): Bugfix
 
Signed-off-by: Pan Li 
---
gcc/config/riscv/riscv-v.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
 
diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index c2466b1354f..6fcbd1622af 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -2059,7 +2059,7 @@ expand_vector_init_merge_repeating_sequence (rtx target,
   uint64_t full_nelts = builder.full_nelts ().to_constant ();
   /* Step 1: Broadcast the first pattern.  */
-  rtx ops[] = {target, force_reg (GET_MODE_INNER (dup_mode), builder.elt (0))};
+  rtx ops[] = {target, force_reg (builder.inner_mode (), builder.elt (0))};
   emit_vlmax_insn (code_for_pred_broadcast (builder.mode ()),
UNARY_OP, ops);
   /* Step 2: Merge the rest iteration of pattern.  */
-- 
2.34.1
 
 


[PATCH v1] RISC-V: Fix fortran ICE/PR111546 when RV32 vec_init

2023-09-23 Thread pan2 . li
From: Pan Li 

When broadcast the reperated element, we take the mask machine mode
by mistake. This patch would like to fix it by leveraging the machine
mode of the element.

The below test case in RV32 will be fixed.

* gcc/testsuite/gfortran.dg/overload_5.f90

PR target/111546

gcc/ChangeLog:

* config/riscv/riscv-v.cc
(expand_vector_init_merge_repeating_sequence): Bugfix

Signed-off-by: Pan Li 
---
 gcc/config/riscv/riscv-v.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index c2466b1354f..6fcbd1622af 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -2059,7 +2059,7 @@ expand_vector_init_merge_repeating_sequence (rtx target,
   uint64_t full_nelts = builder.full_nelts ().to_constant ();
 
   /* Step 1: Broadcast the first pattern.  */
-  rtx ops[] = {target, force_reg (GET_MODE_INNER (dup_mode), builder.elt (0))};
+  rtx ops[] = {target, force_reg (builder.inner_mode (), builder.elt (0))};
   emit_vlmax_insn (code_for_pred_broadcast (builder.mode ()),
UNARY_OP, ops);
   /* Step 2: Merge the rest iteration of pattern.  */
-- 
2.34.1



[PATCH] RISC-V: Fix AVL/VL bug of VSETVL PASS[PR111548]

2023-09-23 Thread Juzhe-Zhong
This patch fixes that AVL/VL reg incorrect fetch in VSETVL PASS.

C/C++ regression passed.

But gfortran didn't run yet. I am still finding a way to run it.

Will commit it when I pass the fortran regression.

PR target/111548

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc (earliest_pred_can_be_fused_p):

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr111548.c: New test.

---
 gcc/config/riscv/riscv-vsetvl.cc  | 16 +---
 .../gcc.target/riscv/rvv/autovec/pr111548.c   | 25 +++
 2 files changed, 31 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/pr111548.c

diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc
index e0f61148ef3..7af33e7ea6f 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -1514,7 +1514,6 @@ earliest_pred_can_be_fused_p (const bb_info 
*earliest_pred,
  const vector_insn_info _info,
  const vector_insn_info , rtx *vlmax_vl)
 {
-  rtx vl = NULL_RTX;
   /* Backward VLMAX VL:
bb 3:
 vsetivli zero, 1 ... -> vsetvli t1, zero
@@ -1526,10 +1525,9 @@ earliest_pred_can_be_fused_p (const bb_info 
*earliest_pred,
We should forward "t1".  */
   if (!earliest_info.has_avl_reg () && expr.has_avl_reg ())
 {
-  rtx avl = expr.get_avl ();
+  rtx avl_or_vl_reg = expr.get_avl_or_vl_reg ();
+  gcc_assert (avl_or_vl_reg);
   const insn_info *last_insn = earliest_info.get_insn ();
-  if (vlmax_avl_p (avl))
-   vl = get_vl (expr.get_insn ()->rtl ());
   /* To fuse demand on earlest edge, we make sure AVL/VL
 didn't change from the consume insn to the predecessor
 of the edge.  */
@@ -1538,17 +1536,15 @@ earliest_pred_can_be_fused_p (const bb_info 
*earliest_pred,
   && after_or_same_p (i, last_insn);
   i = i->prev_nondebug_insn ())
{
- if (!vl && find_access (i->defs (), REGNO (avl)))
+ if (find_access (i->defs (), REGNO (avl_or_vl_reg)))
return false;
- if (vl && find_access (i->defs (), REGNO (vl)))
-   return false;
- if (vl && find_access (i->uses (), REGNO (vl)))
+ if (find_access (i->uses (), REGNO (avl_or_vl_reg)))
return false;
}
+  if (vlmax_vl && vlmax_avl_p (expr.get_avl ()))
+   *vlmax_vl = avl_or_vl_reg;
 }
 
-  if (vlmax_vl)
-*vlmax_vl = vl;
   return true;
 }
 
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr111548.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr111548.c
new file mode 100644
index 000..9bdf42dbed8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr111548.c
@@ -0,0 +1,25 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -Ofast -Wno-implicit-int 
-Wno-implicit-function-declaration -Wno-int-conversion" } */
+
+a, c, d; /* { dg-warning "data definition has no type or storage class" } */
+*b; /* { dg-warning "data definition has no type or storage class" } */
+h() {
+  int e;
+  i();
+  for (;;) {
+unsigned f;
+char *g;
+f = a;
+for (; f; f--) {
+  if (*g == '"')
+e = !e;
+  *b = g++;
+}
+if (c)
+  break;
+f = d;
+for (; d;)
+  if (e)
+b++;
+  }
+}
-- 
2.36.3



[PATCH 1/1] gcc/d: add LoongArch64 support for D frontend

2023-09-23 Thread liushuyu
gcc/ChangeLog:

* config.gcc: add loongarch-d.o to d_target_objs for LoongArch
architecture.

gcc/config/ChangeLog:

* loongarch/loongarch-d.cc
(loongarch_d_target_versions): add interface function to define builtin
D versions for LoongArch architecture.
(loongarch_d_handle_target_float_abi): add interface function to define
builtin D traits for LoongArch architecture.
(loongarch_d_register_target_info): add interface function to register
loongarch_d_handle_target_float_abi function.
* loongarch/loongarch-d.h:
(loongarch_d_target_versions): add function prototype.
(loongarch_d_register_target_info): Likewise.
* loongarch/t-loongarch: add object target for loongarch-d.cc.

gcc/testsuite/ChangeLog:

* gdc.test/fail_compilation/reserved_version.d: add reserved version
tests for LoongArch architecture and also updated expected output.
* gdc.test/fail_compilation/reserved_version_switch.d: Likewise.

libphobos/ChangeLog:

* configure.tgt: enable libphobos for LoongArch architecture.
* configure: Regenerate.
* libdruntime/gcc/sections/elf.d: add TLS_DTV_OFFSET constant for
LoongArch64.
* libdruntime/gcc/unwind/generic.d: add __aligned__ constant for
LoongArch64.
* libdruntime/Makefile.in: Regenerate.

Signed-off-by: Zixing Liu 
---
 gcc/config.gcc|  1 +
 gcc/config/loongarch/loongarch-d.cc   | 82 
 gcc/config/loongarch/loongarch-d.h| 26 +
 gcc/config/loongarch/t-loongarch  |  4 +
 .../fail_compilation/reserved_version.d   | 98 +++
 .../reserved_version_switch.d | 12 +++
 libphobos/configure.tgt   |  3 +
 libphobos/libdruntime/gcc/sections/elf.d  |  2 +
 libphobos/libdruntime/gcc/unwind/generic.d|  1 +
 9 files changed, 186 insertions(+), 43 deletions(-)
 create mode 100644 gcc/config/loongarch/loongarch-d.cc
 create mode 100644 gcc/config/loongarch/loongarch-d.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index ee46d96bf62..782d933b497 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -480,6 +480,7 @@ mips*-*-*)
;;
 loongarch*-*-*)
cpu_type=loongarch
+   d_target_objs="loongarch-d.o"
extra_headers="larchintrin.h lsxintrin.h lasxintrin.h"
extra_objs="loongarch-c.o loongarch-builtins.o loongarch-cpu.o 
loongarch-opts.o loongarch-def.o"
extra_gcc_objs="loongarch-driver.o loongarch-cpu.o loongarch-opts.o 
loongarch-def.o"
diff --git a/gcc/config/loongarch/loongarch-d.cc 
b/gcc/config/loongarch/loongarch-d.cc
new file mode 100644
index 000..d7875079212
--- /dev/null
+++ b/gcc/config/loongarch/loongarch-d.cc
@@ -0,0 +1,82 @@
+/* Subroutines for the D front end on the LoongArch architecture.
+   Copyright (C) 2017-2023 Free Software Foundation, Inc.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#define IN_TARGET_CODE 1
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm_d.h"
+#include "d/d-target.h"
+#include "d/d-target-def.h"
+
+/* Implement TARGET_D_CPU_VERSIONS for LoongArch targets.  */
+
+void
+loongarch_d_target_versions (void)
+{
+  if (TARGET_64BIT)
+d_add_builtin_version ("LoongArch64");
+  else
+d_add_builtin_version ("LoongArch32");
+
+  if (TARGET_ABI_LP64)
+d_add_builtin_version ("D_LP64");
+  else
+d_add_builtin_version ("D_LP32");
+
+  if (TARGET_HARD_FLOAT_ABI)
+{
+  d_add_builtin_version ("LoongArch_HardFloat");
+  d_add_builtin_version ("D_HardFloat");
+}
+  else if (TARGET_SOFT_FLOAT_ABI)
+{
+  d_add_builtin_version ("LoongArch_SoftFloat");
+  d_add_builtin_version ("D_SoftFloat");
+}
+}
+
+/* Handle a call to `__traits(getTargetInfo, "floatAbi")'.  */
+
+static tree
+loongarch_d_handle_target_float_abi (void)
+{
+  const char *abi;
+
+  if (TARGET_HARD_FLOAT_ABI)
+abi = "hard";
+  else if (TARGET_SOFT_FLOAT_ABI)
+abi = "soft";
+  else
+abi = "";
+
+  return build_string_literal (strlen (abi) + 1, abi);
+}
+
+/* Implement TARGET_D_REGISTER_CPU_TARGET_INFO.  */
+
+void
+loongarch_d_register_target_info (void)
+{
+  const struct d_target_info_spec handlers[] = {
+{"floatAbi", loongarch_d_handle_target_float_abi},
+{NULL, NULL},
+  };
+
+  d_add_target_info_handlers 

[PATCH 0/1] Add LoongArch64 support for D frontend

2023-09-23 Thread liushuyu
From: Zixing Liu 

This patch adds the LoongArch64 support for GCC D frontend.

The runtime support is submitted as a separate patch here:
https://github.com/dlang/dmd/pull/15628.

You can find more information about the LoongArch architecture on this
website:
https://loongson.github.io/LoongArch-Documentation/README-EN.html.

Zixing Liu (1):
  gcc/d: add LoongArch64 support for D frontend

 gcc/config.gcc|  1 +
 gcc/config/loongarch/loongarch-d.cc   | 82 
 gcc/config/loongarch/loongarch-d.h| 26 +
 gcc/config/loongarch/t-loongarch  |  4 +
 .../fail_compilation/reserved_version.d   | 98 +++
 .../reserved_version_switch.d | 12 +++
 libphobos/configure.tgt   |  3 +
 libphobos/libdruntime/gcc/sections/elf.d  |  2 +
 libphobos/libdruntime/gcc/unwind/generic.d|  1 +
 9 files changed, 186 insertions(+), 43 deletions(-)
 create mode 100644 gcc/config/loongarch/loongarch-d.cc
 create mode 100644 gcc/config/loongarch/loongarch-d.h

-- 
2.42.0



[PATCH 1/1] gcc/d: add LoongArch64 support for D frontend

2023-09-23 Thread liushuyu



gcc/ChangeLog:

* config.gcc: add loongarch-d.o to d_target_objs for LoongArch
architecture.

gcc/config/ChangeLog:

* loongarch/loongarch-d.cc
(loongarch_d_target_versions): add interface function to define builtin
D versions for LoongArch architecture.
(loongarch_d_handle_target_float_abi): add interface function to define
builtin D traits for LoongArch architecture.
(loongarch_d_register_target_info): add interface function to register
loongarch_d_handle_target_float_abi function.
* loongarch/loongarch-d.h:
(loongarch_d_target_versions): add function prototype.
(loongarch_d_register_target_info): Likewise.
* loongarch/t-loongarch: add object target for loongarch-d.cc.

gcc/testsuite/ChangeLog:

* gdc.test/fail_compilation/reserved_version.d: add reserved version
tests for LoongArch architecture and also updated expected output.
* gdc.test/fail_compilation/reserved_version_switch.d: Likewise.

libphobos/ChangeLog:

* configure.tgt: enable libphobos for LoongArch architecture.
* configure: Regenerate.
* libdruntime/gcc/sections/elf.d: add TLS_DTV_OFFSET constant for
LoongArch64.
* libdruntime/gcc/unwind/generic.d: add __aligned__ constant for
LoongArch64.
* libdruntime/Makefile.in: Regenerate.

Signed-off-by: Zixing Liu 
---
 gcc/config.gcc|  1 +
 gcc/config/loongarch/loongarch-d.cc   | 82 
 gcc/config/loongarch/loongarch-d.h| 26 +
 gcc/config/loongarch/t-loongarch  |  4 +
 .../fail_compilation/reserved_version.d   | 98 +++
 .../reserved_version_switch.d | 12 +++
 libphobos/configure.tgt   |  3 +
 libphobos/libdruntime/gcc/sections/elf.d  |  2 +
 libphobos/libdruntime/gcc/unwind/generic.d|  1 +
 9 files changed, 186 insertions(+), 43 deletions(-)
 create mode 100644 gcc/config/loongarch/loongarch-d.cc
 create mode 100644 gcc/config/loongarch/loongarch-d.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index ee46d96bf62..782d933b497 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -480,6 +480,7 @@ mips*-*-*)
;;
 loongarch*-*-*)
cpu_type=loongarch
+   d_target_objs="loongarch-d.o"
extra_headers="larchintrin.h lsxintrin.h lasxintrin.h"
 	extra_objs="loongarch-c.o loongarch-builtins.o loongarch-cpu.o 
loongarch-opts.o loongarch-def.o"
 	extra_gcc_objs="loongarch-driver.o loongarch-cpu.o loongarch-opts.o 
loongarch-def.o"
diff --git a/gcc/config/loongarch/loongarch-d.cc 
b/gcc/config/loongarch/loongarch-d.cc

new file mode 100644
index 000..d7875079212
--- /dev/null
+++ b/gcc/config/loongarch/loongarch-d.cc
@@ -0,0 +1,82 @@
+/* Subroutines for the D front end on the LoongArch architecture.
+   Copyright (C) 2017-2023 Free Software Foundation, Inc.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#define IN_TARGET_CODE 1
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm_d.h"
+#include "d/d-target.h"
+#include "d/d-target-def.h"
+
+/* Implement TARGET_D_CPU_VERSIONS for LoongArch targets.  */
+
+void
+loongarch_d_target_versions (void)
+{
+  if (TARGET_64BIT)
+d_add_builtin_version ("LoongArch64");
+  else
+d_add_builtin_version ("LoongArch32");
+
+  if (TARGET_ABI_LP64)
+d_add_builtin_version ("D_LP64");
+  else
+d_add_builtin_version ("D_LP32");
+
+  if (TARGET_HARD_FLOAT_ABI)
+{
+  d_add_builtin_version ("LoongArch_HardFloat");
+  d_add_builtin_version ("D_HardFloat");
+}
+  else if (TARGET_SOFT_FLOAT_ABI)
+{
+  d_add_builtin_version ("LoongArch_SoftFloat");
+  d_add_builtin_version ("D_SoftFloat");
+}
+}
+
+/* Handle a call to `__traits(getTargetInfo, "floatAbi")'.  */
+
+static tree
+loongarch_d_handle_target_float_abi (void)
+{
+  const char *abi;
+
+  if (TARGET_HARD_FLOAT_ABI)
+abi = "hard";
+  else if (TARGET_SOFT_FLOAT_ABI)
+abi = "soft";
+  else
+abi = "";
+
+  return build_string_literal (strlen (abi) + 1, abi);
+}
+
+/* Implement TARGET_D_REGISTER_CPU_TARGET_INFO.  */
+
+void
+loongarch_d_register_target_info (void)
+{
+  const struct d_target_info_spec handlers[] = {
+{"floatAbi", loongarch_d_handle_target_float_abi},
+{NULL, NULL},
+  };
+
+  d_add_target_info_handlers 

[PATCH 0/1] Add LoongArch64 support for D frontend

2023-09-23 Thread liushuyu



This patch adds the LoongArch64 support for GCC D frontend.

The runtime support is submitted as a separate patch here:
https://github.com/dlang/dmd/pull/15628.

You can find more information about the LoongArch architecture on this
website:
https://loongson.github.io/LoongArch-Documentation/README-EN.html.

Zixing Liu (1):
  gcc/d: add LoongArch64 support for D frontend

 gcc/config.gcc|  1 +
 gcc/config/loongarch/loongarch-d.cc   | 82 
 gcc/config/loongarch/loongarch-d.h| 26 +
 gcc/config/loongarch/t-loongarch  |  4 +
 .../fail_compilation/reserved_version.d   | 98 +++
 .../reserved_version_switch.d | 12 +++
 libphobos/configure.tgt   |  3 +
 libphobos/libdruntime/gcc/sections/elf.d  |  2 +
 libphobos/libdruntime/gcc/unwind/generic.d|  1 +
 9 files changed, 186 insertions(+), 43 deletions(-)
 create mode 100644 gcc/config/loongarch/loongarch-d.cc
 create mode 100644 gcc/config/loongarch/loongarch-d.h

--
2.42.0



Re: RISC-V: Added support for CRC.

2023-09-23 Thread Joern Rennecke
Mariam Harutyunyan:
+++ b/gcc/ChangeLog
@@ -1,3 +1,45 @@
+2023-08-03  Mariam Arutunian  
+

It is common courtesy to include all authors in the list of authors
for the ChangeLog; also,
this may help people in the future understand the history of the code better.
While must of your patch is new, it still contains non-trivial parts of mine
( https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591744.html )
.And stripping out the comment why, currently,  we can't use linkonce
for crc tables on the the RISC-V target is
not helpful to someone who wants to understand the code.

See also the discussion to put this into loop distribution:
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591821.html
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591866.html

Mariam Harutyunyan:
> It adds internal
> functions and built-ins specifically designed to handle CRC computations
> efficiently.

This sounds like this is a finished work, although defining built-in
functions to calculate the CRC of single data elements and recognizers
for some C idioms that do these calculations,
is just a starting point.

Alexander Monakov :

> Jeff, as I understand this all is happening only because Coremark contains
> use of bitwise CRC that affects benchmark scores. In another universe where
> - Coremark was careful to checksum outputs outside of timed sections, or
> - implemented CRC in a manner that is not transparent to the compiler, or
> - did not use CRC at all
> we would not be spending effort on this, correct?

It is a stated goal of coremark to test performance for CRC.  They do
not use a library call
to implement CRC, but a specific bit-banging algorithm they have
chosen.  That algorithm is,
for the vast majority of processors, not representative of the targets
performance potential in calculating CRCs, thus if a compiler fails to
translate this into the CRC implementation that
would be used for performance code, the compiler frustrates this goal
of coremark to give a measure of CRC calculation performance.

> At best we might have
> a discussion on providing a __builtin_clmul for carry-less multiplication
> (which _is_ a fundamental primitive, unlike __builtin_crc), and move on.

Some processors have specialized instructions for CRC computations.

> Instead, efficient CRC loops have the following structure:
> - they carry an unreduced remainder in the loop, performing final reduction
>  modulo polynomial only once after the loop — this halves the CLMUL count;
> - they overlap multiple CLMUL chains to make the loop throughput-bound
> rather than latency-bound. The typical unroll factor is about 4x-8x.

If you want to recognize a loop that does a CRC on a block, it makes
sense to start with recognizing the CRC computation for single array
elements first.  We have to learn to
walk before we can run.

Nore that my initial patch already contained a match.pd stanza to
recognize two chained single-element CRC calculations.

Jeff Law:
> The intention is to provide a useful
> builtin_crc while at the same time putting one side of the
> infrastructure we need for automatic detection of CRC loops and turning
> them into table lookups or CLMULs.

Note that when optimizing for size, for a target with tiny memory, or
when using a non-constant (or constant but undiscoverable by the
compiler) polynom, we can't use the table lookup.  But still, even if
we don't have CLmul, we can generally speed up CRC computation over
the coremark algorithm by using something more suited to the target,
like the crcu16_1 function I
put into comments in my patch.

Alexander Monakov :
> So... just provide a library? A library code is easier to develop and audit,
> it can be released independently, people can use it with their compiler of
> choice. Not everything needs to be in libgcc.

A library can be used to implement built-ins in gcc (we still need to
define one for block operations, one step at a time...).
However, someone or something needs to rewrite the existing code to
use the library.
It is commonly accepted that an efficient way to do this is to make a
compiler do the
necessary transformations, as long as it can be made to churn out good
enough code.

Alexander Monakov:
> Useful to whom? The Linux kernel? zlib, bzip2, xz-utils? ffmpeg?
> These consumers need high-performance blockwise CRC, offering them
> a latency-bound elementwise CRC primitive is a disservice. And what
> should they use as a fallback when __builtin_crc is unavailable?

We can provide a fallback implementation for all targets with table
lookup and/or shifts .

Alexander Monakov:
> I think offering a conventional library for CRC has substantial advantages.
Are you volunteering?  It would make our work to emit code for block
CRC easier if we could
just use a library call when we recognize a block CRC (although making
that recognizer is likely still considerable work if we want to get
good coverage over different coding styles).

Although maybe Oleg Endo's library, as mentioned 

[PATCH] Fix coroutine tests for libstdc++ gnu-version-namespace mode

2023-09-23 Thread François Dumont
I'm eventually fixing those tests the same way we manage this problem in 
libstdc++ testsuite.


   testsuite: Add optional libstdc++ version namespace in expected 
diagnostic


    When libstdc++ is build with 
--enable-symvers=gnu-versioned-namespace diagnostics are

    showing this namespace, currently __8.

    gcc/testsuite/ChangeLog:

    * 
testsuite/g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C: Add optional

    '__8' version namespace in expected diagnostic.
    * 
testsuite/g++.dg/coroutines/coro-bad-alloc-01-bad-op-del.C: Likewise.
    * 
testsuite/g++.dg/coroutines/coro-bad-alloc-02-no-op-new-nt.C: Likewise.
    * 
testsuite/g++.dg/coroutines/coro-bad-grooaf-01-grooaf-expected.C: Likewise.

    * testsuite/g++.dg/coroutines/pr97438.C: Likewise.
    * testsuite/g++.dg/coroutines/ramp-return-b.C: Likewise.

Tested under Linux x86_64.

I'm contributing to libstdc++ so I already have write access.

Ok to commit ?

François
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 73e7f381020..c44b71a04cb 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -4867,7 +4867,7 @@ dnl
 dnl Control whether the library should define symbols for old and new ABIs.
 dnl This affects definitions of strings, stringstreams and locale facets.
 dnl
-dnl --disable-libstdcxx-dual-abi will use old ABI for all types.
+dnl --disable-libstdcxx-dual-abi will use new ABI for all types.
 dnl
 dnl Defines:
 dnl  _GLIBCXX_USE_DUAL_ABI (always defined, either to 1 or 0)
@@ -4883,7 +4883,7 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_DUAL_ABI], [
   else
 if test x"$enable_libstdcxx_dual_abi" != xyes; then
   AC_MSG_NOTICE([dual ABI is disabled])
-  default_libstdcxx_abi="gcc4-compatible"
+  default_libstdcxx_abi="new"
 fi
   fi
   GLIBCXX_CONDITIONAL(ENABLE_DUAL_ABI, test $enable_libstdcxx_dual_abi = yes)
@@ -4898,7 +4898,6 @@ dnl Defines:
 dnl  _GLIBCXX_USE_CXX11_ABI (always defined, either to 1 or 0)
 dnl
 AC_DEFUN([GLIBCXX_DEFAULT_ABI], [
-  if test x$enable_libstdcxx_dual_abi = xyes; then
   AC_MSG_CHECKING([for default std::string ABI to use])
   AC_ARG_WITH([default-libstdcxx-abi],
 AS_HELP_STRING([--with-default-libstdcxx-abi],
@@ -4912,7 +4911,6 @@ AC_DEFUN([GLIBCXX_DEFAULT_ABI], [
  ],
 [default_libstdcxx_abi="new"])
   AC_MSG_RESULT(${default_libstdcxx_abi})
-  fi
   if test $default_libstdcxx_abi = "new"; then
 glibcxx_cxx11_abi=1
 glibcxx_cxx98_abi=0
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 6e9a532a359..14f9569597a 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -70712,13 +70712,12 @@ $as_echo "$as_me: dual ABI is disabled" >&6;}
 if test x"$enable_libstdcxx_dual_abi" != xyes; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: dual ABI is disabled" >&5
 $as_echo "$as_me: dual ABI is disabled" >&6;}
-  default_libstdcxx_abi="gcc4-compatible"
+  default_libstdcxx_abi="new"
 fi
   fi
 
 
 
-  if test x$enable_libstdcxx_dual_abi = xyes; then
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for default std::string ABI to use" >&5
 $as_echo_n "checking for default std::string ABI to use... " >&6; }
 
@@ -70737,7 +70736,6 @@ fi
 
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: ${default_libstdcxx_abi}" >&5
 $as_echo "${default_libstdcxx_abi}" >&6; }
-  fi
   if test $default_libstdcxx_abi = "new"; then
 glibcxx_cxx11_abi=1
 glibcxx_cxx98_abi=0


[PATCH] MATCH: Add `(X & ~Y) & Y` and `(X | ~Y) | Y`

2023-09-23 Thread Andrew Pinski
Even though this gets optimized by reassociation, catching it more often
will always be better.

Note the reason why I didn't add `(X ^ ~Y) ^ Y` is that it gets caught
by prefering `~(X ^ Y)` to `(X ^ ~Y)` which then it is caught by the
the pattern for `(X ^ Y) ^ Y` already.

PR tree-optimization/111543

gcc/ChangeLog:

* match.pd (`(X & ~Y) & Y`, `(X | ~Y) | Y`): New patterns.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/bitops-4.c: New test.
---
 gcc/match.pd | 17 +
 gcc/testsuite/gcc.dg/tree-ssa/bitops-4.c | 18 ++
 2 files changed, 35 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/bitops-4.c

diff --git a/gcc/match.pd b/gcc/match.pd
index 0aa815f4118..a17778fbaa6 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1806,6 +1806,23 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (simplify
  (bit_xor:c (convert1? (bit_xor:c @0 @@1)) (convert2? @1))
  (convert @0))
+
+/* (X & ~Y) & Y -> 0 */
+(simplify
+ (bit_and:c (bit_and @0 @1) @2)
+ (with { bool wascmp; }
+  (if (bitwise_inverted_equal_p (@0, @2, wascmp)
+   || bitwise_inverted_equal_p (@1, @2, wascmp))
+   { wascmp ? constant_boolean_node (false, type) : build_zero_cst (type); })))
+/* (X | ~Y) | Y -> -1 */
+(simplify
+ (bit_ior:c (bit_ior @0 @1) @2)
+ (with { bool wascmp; }
+  (if ((bitwise_inverted_equal_p (@0, @2, wascmp)
+|| bitwise_inverted_equal_p (@1, @2, wascmp))
+   && (!wascmp || element_precision (type) == 1))
+   { build_all_ones_cst (TREE_TYPE (@0)); })))
+
 /* (X & Y) & (X & Z) -> (X & Y) & Z
(X | Y) | (X | Z) -> (X | Y) | Z  */
 (for op (bit_and bit_ior)
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/bitops-4.c 
b/gcc/testsuite/gcc.dg/tree-ssa/bitops-4.c
new file mode 100644
index 000..73c8f39d28f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/bitops-4.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -fdump-tree-optimized -fdump-tree-ccp1" } */
+/* PR tree-optimization/111543 */
+
+void f_or(int a, int b, int *por)
+{
+int c = ~a;
+*por = (c | b) | a;
+}
+void f_and(int a, int b, int *pand)
+{
+int c = ~a;
+*pand = (c & b) & a;
+}
+/* { dg-final { scan-tree-dump-times "pand_\[0-9\]+.D. = 0" 1 "optimized" } } 
*/
+/* { dg-final { scan-tree-dump-times "por_\[0-9\]+.D. = -1" 1 "optimized" } } 
*/
+/* { dg-final { scan-tree-dump-times "pand_\[0-9\]+.D. = 0" 1 "ccp1" } } */
+/* { dg-final { scan-tree-dump-times "por_\[0-9\]+.D. = -1" 1 "ccp1" } } */
-- 
2.31.1



[committed] d: Merge upstream dmd, druntime 4574d1728d, phobos d7e79f024.

2023-09-23 Thread Iain Buclaw
Hi,

This patch merges the D front-end and run-time library with upstream dmd
4574d1728d, and standard library with phobos d7e79f024.

Updating the latest changes from the v2.105.0 release.

D front-end changes:

- Import dmd v2.105.0.
- Catch clause must take only `const' or mutable exceptions.
- Creating a `scope' class instance with a non-scope constructor
  is now `@system' only with `-fpreview=dip1000'.
- Global `const' variables can no longer be initialized from a
  non-shared static constructor

D runtime changes:

- Import druntime v2.105.0.

Phobos changes:

- Import phobos v2.105.0.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32, committed
to mainline.

Regards,
Iain.

---
gcc/d/ChangeLog:

* dmd/MERGE: Merge upstream dmd 4574d1728d.
* dmd/VERSION: Bump version to v2.105.0.
* d-diagnostic.cc (verror): Remove.
(verrorSupplemental): Remove.
(vwarning): Remove.
(vwarningSupplemental): Remove.
(vdeprecation): Remove.
(vdeprecationSupplemental): Remove.
(vmessage): Remove.
(vtip): Remove.
(verrorReport): New function.
(verrorReportSupplemental): New function.
* d-lang.cc (d_parse_file): Update for new front-end interface.
* decl.cc (d_mangle_decl): Update for new front-end interface.
* intrinsics.cc (maybe_set_intrinsic): Update for new front-end
interface.

libphobos/ChangeLog:

* libdruntime/MERGE: Merge upstream druntime 4574d1728d.
* src/MERGE: Merge upstream phobos d7e79f024.
---
 gcc/d/d-diagnostic.cc | 199 +---
 gcc/d/d-lang.cc   |   6 +-
 gcc/d/decl.cc |   2 +-
 gcc/d/dmd/MERGE   |   2 +-
 gcc/d/dmd/README.md   |   3 +-
 gcc/d/dmd/VERSION |   2 +-
 gcc/d/dmd/access.d|   1 -
 gcc/d/dmd/aggregate.d |   2 +-
 gcc/d/dmd/aliasthis.d |   3 +-
 gcc/d/dmd/arrayop.d   |  10 +-
 gcc/d/dmd/attrib.d|  47 ++-
 gcc/d/dmd/blockexit.d |   1 -
 gcc/d/dmd/canthrow.d  |   3 +-
 gcc/d/dmd/common/file.d   |   8 +
 gcc/d/dmd/common/outbuffer.d  |  12 +-
 gcc/d/dmd/common/string.d |   5 +-
 gcc/d/dmd/cond.d  |  16 +-
 gcc/d/dmd/constfold.d |   4 +-
 gcc/d/dmd/cppmangle.d |  18 +-
 gcc/d/dmd/ctfeexpr.d  |  24 +-
 gcc/d/dmd/ctorflow.d  |   8 +-
 gcc/d/dmd/dclass.d|   2 +-
 gcc/d/dmd/declaration.d   |  30 +-
 gcc/d/dmd/declaration.h   |   4 +-
 gcc/d/dmd/delegatize.d|   4 +-
 gcc/d/dmd/dinterpret.d|  17 +-
 gcc/d/dmd/dmangle.d   |  66 ++--
 gcc/d/dmd/dmodule.d   |   6 +-
 gcc/d/dmd/doc.d   |  99 +++---
 gcc/d/dmd/doc.h   |   3 +-
 gcc/d/dmd/dscope.d|  15 +-
 gcc/d/dmd/dsymbol.d   |  52 +--
 gcc/d/dmd/dsymbolsem.d|  30 +-
 gcc/d/dmd/dtemplate.d |  22 +-
 gcc/d/dmd/dtoh.d  |  23 +-
 gcc/d/dmd/dversion.d  |   8 +-
 gcc/d/dmd/errors.d| 180 ---
 gcc/d/dmd/errors.h|  20 +-
 gcc/d/dmd/errorsink.d |   6 +
 gcc/d/dmd/escape.d|   2 +-
 gcc/d/dmd/expression.d| 303 +-
 gcc/d/dmd/expression.h|   1 +
 gcc/d/dmd/expressionsem.d |  49 ++-
 gcc/d/dmd/foreachvar.d|   2 +-
 gcc/d/dmd/func.d  |  17 +-
 gcc/d/dmd/globals.d   |  18 +-
 gcc/d/dmd/globals.h   |   2 +-
 gcc/d/dmd/hdrgen.d|  16 +-
 gcc/d/dmd/id.d|   8 +-
 gcc/d/dmd/identifier.d|   6 +-
 gcc/d/dmd/imphint.d   |   2 +-
 gcc/d/dmd/init.d  |  14 +-
 gcc/d/dmd/intrange.d  |  50 +--
 gcc/d/dmd/json.d  |   2 +-
 gcc/d/dmd/lambdacomp.d|   2 +-
 gcc/d/dmd/lexer.d |   2 +-
 gcc/d/dmd/location.d  |   6 +-
 gcc/d/dmd/mangle.h|   8 +-
 gcc/d/dmd/mtype.d |  76 ++---
 

Re: [PATCH] libstdc++: Ensure active union member is correctly set

2023-09-23 Thread Jonathan Wakely
On Sat, 23 Sept 2023, 08:30 Nathaniel Shead, 
wrote:

> On Sat, Sep 23, 2023 at 07:40:48AM +0100, Jonathan Wakely wrote:
> > On Sat, 23 Sept 2023, 01:39 Nathaniel Shead via Libstdc++, <
> > libstd...@gcc.gnu.org> wrote:
> >
> > > Now that bootstrap has finished, I have gotten regressions in the
> > > following libstdc++ tests:
> > >
> > > Running libstdc++:libstdc++-dg/conformance.exp ...
> > > FAIL: 20_util/bitset/access/constexpr.cc -std=gnu++23 (test for excess
> > > errors)
> > > FAIL: 20_util/bitset/access/constexpr.cc -std=gnu++26 (test for excess
> > > errors)
> > > FAIL: 20_util/variant/constexpr.cc -std=gnu++20 (test for excess
> errors)
> > > FAIL: 20_util/variant/constexpr.cc -std=gnu++26 (test for excess
> errors)
> > > FAIL: 21_strings/basic_string/cons/char/constexpr.cc -std=gnu++20 (test
> > > for excess errors)
> > > FAIL: 21_strings/basic_string/cons/char/constexpr.cc -std=gnu++26 (test
> > > for excess errors)
> > > FAIL: 21_strings/basic_string/cons/wchar_t/constexpr.cc -std=gnu++20
> (test
> > > for excess errors)
> > > FAIL: 21_strings/basic_string/cons/wchar_t/constexpr.cc -std=gnu++26
> (test
> > > for excess errors)
> > > FAIL: 21_strings/basic_string/modifiers/swap/constexpr-wchar_t.cc
> > > -std=gnu++20 (test for excess errors)
> > > FAIL: 21_strings/basic_string/modifiers/swap/constexpr-wchar_t.cc
> > > -std=gnu++26 (test for excess errors)
> > > FAIL: 21_strings/basic_string/modifiers/swap/constexpr.cc -std=gnu++20
> > > (test for excess errors)
> > > FAIL: 21_strings/basic_string/modifiers/swap/constexpr.cc -std=gnu++26
> > > (test for excess errors)
> > > FAIL: std/ranges/adaptors/join_with/1.cc -std=gnu++23 (test for excess
> > > errors)
> > > UNRESOLVED: std/ranges/adaptors/join_with/1.cc -std=gnu++23 compilation
> > > failed to produce executable
> > > FAIL: std/ranges/adaptors/join_with/1.cc -std=gnu++26 (test for excess
> > > errors)
> > > UNRESOLVED: std/ranges/adaptors/join_with/1.cc -std=gnu++26 compilation
> > > failed to produce executable
> > >
> > > On investigation though it looks like the issue might be with libstdc++
> > > rather than the patch itself; running the failing tests using clang
> with
> > > libstdc++ also produces similar errors, and my reading of the code
> > > suggests that this is correct.
> > >
> > > What's the way forward here? Should I look at creating a patch to fix
> > > the libstdc++ issues before resubmitting this patch for the C++
> > > frontend? Or should I submit a version of this patch without the
> > > `std::construct_at` changes and wait till libstdc++ gets fixed for
> that?
> > >
> >
> > I think we should fix libstdc++. There are probably only a few places
> that
> > need a fix, which cause all those failures.
> >
> > I can help with those fixes. I'll look into it after the weekend.
> >
>
> Thanks. I did end up getting a chance to look at it earlier today, and
> with the following patch I had no regressions when applying the frontend
> changes. Bootstrapped and regtested on x86_64-pc-linux-gnu.
>

Nice, thanks! This looks good at first glance, I'll review it properly ASAP.



> -- >8 --
>
> This patch ensures that the union members for std::string and
> std::variant are always properly set when a change occurs.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/basic_string.h: (basic_string(basic_string&&)):
> Activate _M_local_buf when needed.
> (basic_string(basic_string&&, const _Alloc&)): Likewise.
> * include/bits/basic_string.tcc: (basic_string::swap): Likewise.
> * include/std/variant: (__detail::__variant::__construct_n): New.
> (__detail::_variant::__emplace): Use __construct_n.
>
> Signed-off-by: Nathaniel Shead 
> ---
>  libstdc++-v3/include/bits/basic_string.h   |  7 +++--
>  libstdc++-v3/include/bits/basic_string.tcc |  8 +++---
>  libstdc++-v3/include/std/variant   | 32 --
>  3 files changed, 38 insertions(+), 9 deletions(-)
>
> diff --git a/libstdc++-v3/include/bits/basic_string.h
> b/libstdc++-v3/include/bits/basic_string.h
> index 09fd62afa66..7c342879827 100644
> --- a/libstdc++-v3/include/bits/basic_string.h
> +++ b/libstdc++-v3/include/bits/basic_string.h
> @@ -678,7 +678,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
>{
> if (__str._M_is_local())
>   {
> -   traits_type::copy(_M_local_buf, __str._M_local_buf,
> +   traits_type::copy(_M_use_local_data(), __str._M_local_buf,
>   __str.length() + 1);
>   }
> else
> @@ -691,7 +691,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
> // basic_stringbuf relies on writing into unallocated capacity so
> // we mess up the contents if we put a '\0' in the string.
> _M_length(__str.length());
> -   __str._M_data(__str._M_local_data());
> +   __str._M_data(__str._M_use_local_data());
> __str._M_set_length(0);
>}
>
> @@ -717,6 +717,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
>{
> if 

RE: [PATCH v1] RISC-V: Remove FP run test for ceil.

2023-09-23 Thread Li, Pan2
Sure, will re-visit this part later.

Pan

-Original Message-
From: Kito Cheng  
Sent: Saturday, September 23, 2023 3:47 PM
To: Li, Pan2 
Cc: 钟居哲 ; gcc-patches ; Wang, 
Yanzhang 
Subject: Re: [PATCH v1] RISC-V: Remove FP run test for ceil.

I guess it just needs more checks than `target { riscv_vector }`,
maybe something like `target { riscv_vector_zvfh }`, but anyway I am
fine to drop this for now.

On Sat, Sep 23, 2023 at 2:11 AM Li, Pan2  wrote:
>
> Committed, thanks Juzhe.
>
>
>
> Pan
>
>
>
> From: 钟居哲 
> Sent: Saturday, September 23, 2023 9:07 AM
> To: Li, Pan2 ; gcc-patches 
> Cc: Li, Pan2 ; Wang, Yanzhang ; 
> kito.cheng 
> Subject: Re: [PATCH v1] RISC-V: Remove FP run test for ceil.
>
>
>
> Ok
>
>
>
> 
>
> juzhe.zh...@rivai.ai
>
>
>
> From: pan2.li
>
> Date: 2023-09-23 09:06
>
> To: gcc-patches
>
> CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
>
> Subject: [PATCH v1] RISC-V: Remove FP run test for ceil.
>
> From: Pan Li 
>
>
>
> FP16 is not well reconciled when linking.
>
>
>
> gcc/testsuite/ChangeLog:
>
>
>
> * gcc.target/riscv/rvv/autovec/unop/math-ceil-run-0.c: Remove.
>
>
>
> Signed-off-by: Pan Li 
>
> ---
>
> .../riscv/rvv/autovec/unop/math-ceil-run-0.c  | 39 ---
>
> 1 file changed, 39 deletions(-)
>
> delete mode 100644 
> gcc/testsuite/gcc.target/riscv/rvv/autovec/unop/math-ceil-run-0.c
>
>
>
> diff --git 
> a/gcc/testsuite/gcc.target/riscv/rvv/autovec/unop/math-ceil-run-0.c 
> b/gcc/testsuite/gcc.target/riscv/rvv/autovec/unop/math-ceil-run-0.c
>
> deleted file mode 100644
>
> index 600c161159d..000
>
> --- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/unop/math-ceil-run-0.c
>
> +++ /dev/null
>
> @@ -1,39 +0,0 @@
>
> -/* { dg-do run { target { riscv_vector } } } */
>
> -/* { dg-additional-options "-std=c2x -O3 -ftree-vectorize 
> -fno-vect-cost-model -ffast-math" } */
>
> -
>
> -#include "test-math.h"
>
> -
>
> -#define ARRAY_SIZE 128
>
> -
>
> -_Float16 in[ARRAY_SIZE];
>
> -_Float16 out[ARRAY_SIZE];
>
> -_Float16 ref[ARRAY_SIZE];
>
> -
>
> -TEST_UNARY_CALL (_Float16, __builtin_ceilf16)
>
> -TEST_ASSERT (_Float16)
>
> -
>
> -TEST_INIT (_Float16, 1.2, 2.0, 1)
>
> -TEST_INIT (_Float16, -1.2, -1.0, 2)
>
> -TEST_INIT (_Float16, 3.0, 3.0, 3)
>
> -TEST_INIT (_Float16, 1023.5, 1024.0, 4)
>
> -TEST_INIT (_Float16, 1025.0, 1025.0, 5)
>
> -TEST_INIT (_Float16, 0.0, 0.0, 6)
>
> -TEST_INIT (_Float16, -0.0, -0.0, 7)
>
> -TEST_INIT (_Float16, -1023.5, -1023.0, 8)
>
> -TEST_INIT (_Float16, -1024.0, -1024.0, 9)
>
> -
>
> -int
>
> -main ()
>
> -{
>
> -  RUN_TEST (_Float16, 1, __builtin_ceilf16, in, out, ref, ARRAY_SIZE);
>
> -  RUN_TEST (_Float16, 2, __builtin_ceilf16, in, out, ref, ARRAY_SIZE);
>
> -  RUN_TEST (_Float16, 3, __builtin_ceilf16, in, out, ref, ARRAY_SIZE);
>
> -  RUN_TEST (_Float16, 4, __builtin_ceilf16, in, out, ref, ARRAY_SIZE);
>
> -  RUN_TEST (_Float16, 5, __builtin_ceilf16, in, out, ref, ARRAY_SIZE);
>
> -  RUN_TEST (_Float16, 6, __builtin_ceilf16, in, out, ref, ARRAY_SIZE);
>
> -  RUN_TEST (_Float16, 7, __builtin_ceilf16, in, out, ref, ARRAY_SIZE);
>
> -  RUN_TEST (_Float16, 8, __builtin_ceilf16, in, out, ref, ARRAY_SIZE);
>
> -  RUN_TEST (_Float16, 9, __builtin_ceilf16, in, out, ref, ARRAY_SIZE);
>
> -
>
> -  return 0;
>
> -}
>
> --
>
> 2.34.1
>
>
>
>


Re: [PATCH 2/2] RISC-V: Add support for XCValu extension in CV32E40P

2023-09-23 Thread Kito Cheng
Hi Mary:

Several inline comments, mostly are related to the RTX pattern. I
guess we don't really need those unspec except clip*.

> diff --git a/gcc/config/riscv/corev.md b/gcc/config/riscv/corev.md
> index 59aeafe485f..30c8bcbe476 100644
> --- a/gcc/config/riscv/corev.md
> +++ b/gcc/config/riscv/corev.md
> @@ -17,6 +17,27 @@
>  ;; along with GCC; see the file COPYING3.  If not see
>  ;; .
>
> +(define_c_enum "unspec" [
> +
> +  ;;CORE-V ALU
> +  UNSPEC_CV_ALU_CLIP
> +  UNSPEC_CV_ALU_CLIPR
> +  UNSPEC_CV_ALU_CLIPU
> +  UNSPEC_CV_ALU_CLIPUR
> +  UNSPEC_CV_ALU_ADDN
> +  UNSPEC_CV_ALU_ADDUN
> +  UNSPEC_CV_ALU_ADDRN
> +  UNSPEC_CV_ALU_ADDURN
> +  UNSPEC_CV_ALU_SUBN
> +  UNSPEC_CV_ALU_SUBUN
> +  UNSPEC_CV_ALU_SUBRN
> +  UNSPEC_CV_ALU_SUBURN
> +  UNSPEC_CV_ALU_EXTHS
> +  UNSPEC_CV_ALU_EXTHZ
> +  UNSPEC_CV_ALU_EXTBS
> +  UNSPEC_CV_ALU_EXTBZ
> +])
> +
>  ;; XCVMAC extension.
>
>  (define_insn "riscv_cv_mac_mac"
> @@ -388,3 +409,267 @@
>"cv.machhsRN\t%0,%1,%2,%4"
>[(set_attr "type" "arith")
>(set_attr "mode" "SI")])
> +
> +;; XCVALU builtins
> +
> +(define_insn "riscv_cv_alu_slet"
> +  [(set (match_operand:SI 0 "register_operand" "=r")
> +(if_then_else
> +  (gt:SI
> +(match_operand:SI 1 "register_operand" "r")
> +(match_operand:SI 2 "register_operand" "r"))
> +  (const_int 0)
> +  (const_int 1)))]

Maybe just something like that? slt instruction using similar pattern like that.
(set (match_operand:SI 0 "register_operand" "=r")
   (gt:SI
 (match_operand:SI 1 "register_operand" "r")
 (match_operand:SI 2 "register_operand" "r")))


> +
> +  "TARGET_XCVALU && !TARGET_64BIT"
> +  "cv.slet\t%0, %1, %2"
> +  [(set_attr "type" "arith")
> +  (set_attr "mode" "SI")])
> +
> +(define_insn "riscv_cv_alu_sletu"
> +  [(set (match_operand:SI 0 "register_operand" "=r")
> +(if_then_else
> +  (gtu:SI
> +(match_operand:SI 1 "register_operand" "r")
> +(match_operand:SI 2 "register_operand" "r"))
> +  (const_int 0)
> +  (const_int 1)))]

Same comment as riscv_cv_alu_slet.

> +  "TARGET_XCVALU && !TARGET_64BIT"
> +  "cv.sletu\t%0, %1, %2"
> +  [(set_attr "type" "arith")
> +  (set_attr "mode" "SI")])
> +
> +(define_insn "riscv_cv_alu_min"
> +  [(set (match_operand:SI 0 "register_operand" "=r")
> +(if_then_else
> +  (gt:SI
> +(match_operand:SI 1 "register_operand" "r")
> +(match_operand:SI 2 "register_operand" "r"))
> +  (match_dup:SI 2)
> +  (match_dup:SI 1)))]

Maybe something like that?

(set (match_operand:SI 0 "register_operand" "=r")
   (min
 (match_operand:SI 1 "register_operand" "r")
 (match_operand:SI 2 "register_operand" "r")))

> +
> +  "TARGET_XCVALU && !TARGET_64BIT"
> +  "cv.min\t%0, %1, %2"
> +  [(set_attr "type" "arith")
> +  (set_attr "mode" "SI")])
> +
> +(define_insn "riscv_cv_alu_minu"
> +  [(set (match_operand:SI 0 "register_operand" "=r")
> +(if_then_else
> +  (gtu:SI
> +(match_operand:SI 1 "register_operand" "r")
> +(match_operand:SI 2 "register_operand" "r"))
> +  (match_dup:SI 2)
> +  (match_dup:SI 1)))]


(set (match_operand:SI 0 "register_operand" "=r")
   (minu
 (match_operand:SI 1 "register_operand" "r")
 (match_operand:SI 2 "register_operand" "r")))


> +  "TARGET_XCVALU && !TARGET_64BIT"
> +  "cv.minu\t%0, %1, %2"
> +  [(set_attr "type" "arith")
> +  (set_attr "mode" "SI")])
> +
> +(define_insn "riscv_cv_alu_max"
> +  [(set (match_operand:SI 0 "register_operand" "=r")
> +(if_then_else
> +  (gt:SI
> +(match_operand:SI 1 "register_operand" "r")
> +(match_operand:SI 2 "register_operand" "r"))
> +  (match_dup:SI 1)
> +  (match_dup:SI 2)))]

(set (match_operand:SI 0 "register_operand" "=r")
   (max
 (match_operand:SI 1 "register_operand" "r")
 (match_operand:SI 2 "register_operand" "r")))


> +  "TARGET_XCVALU && !TARGET_64BIT"
> +  "cv.max\t%0, %1, %2"
> +  [(set_attr "type" "arith")
> +  (set_attr "mode" "SI")])
> +
> +(define_insn "riscv_cv_alu_maxu"
> +  [(set (match_operand:SI 0 "register_operand" "=r")
> +(if_then_else
> +  (gtu:SI
> +(match_operand:SI 1 "register_operand" "r")
> +(match_operand:SI 2 "register_operand" "r"))


(set (match_operand:SI 0 "register_operand" "=r")
   (maxu
 (match_operand:SI 1 "register_operand" "r")
 (match_operand:SI 2 "register_operand" "r")))


> +  (match_dup:SI 1)
> +  (match_dup:SI 2)))]
> +
> +  "TARGET_XCVALU && !TARGET_64BIT"
> +  "cv.maxu\t%0, %1, %2"
> +  [(set_attr "type" "arith")
> +  (set_attr "mode" "SI")])
> +
> +(define_insn "riscv_cv_alu_exths"
> +  [(set (match_operand:SI 0 "register_operand" "=r")
> +   (unspec:SI [(match_operand:HI 1 "register_operand" "r")]
> +UNSPEC_CV_ALU_EXTHS))]

It's sign-extension from HI to SI?

if so that should just using sign_extend rather than unspec

  [(set (match_operand:SI 0 "register_operand" "=r")
(sign_extend:SI 

Re: [PATCH v1] RISC-V: Remove FP run test for ceil.

2023-09-23 Thread Kito Cheng
I guess it just needs more checks than `target { riscv_vector }`,
maybe something like `target { riscv_vector_zvfh }`, but anyway I am
fine to drop this for now.

On Sat, Sep 23, 2023 at 2:11 AM Li, Pan2  wrote:
>
> Committed, thanks Juzhe.
>
>
>
> Pan
>
>
>
> From: 钟居哲 
> Sent: Saturday, September 23, 2023 9:07 AM
> To: Li, Pan2 ; gcc-patches 
> Cc: Li, Pan2 ; Wang, Yanzhang ; 
> kito.cheng 
> Subject: Re: [PATCH v1] RISC-V: Remove FP run test for ceil.
>
>
>
> Ok
>
>
>
> 
>
> juzhe.zh...@rivai.ai
>
>
>
> From: pan2.li
>
> Date: 2023-09-23 09:06
>
> To: gcc-patches
>
> CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
>
> Subject: [PATCH v1] RISC-V: Remove FP run test for ceil.
>
> From: Pan Li 
>
>
>
> FP16 is not well reconciled when linking.
>
>
>
> gcc/testsuite/ChangeLog:
>
>
>
> * gcc.target/riscv/rvv/autovec/unop/math-ceil-run-0.c: Remove.
>
>
>
> Signed-off-by: Pan Li 
>
> ---
>
> .../riscv/rvv/autovec/unop/math-ceil-run-0.c  | 39 ---
>
> 1 file changed, 39 deletions(-)
>
> delete mode 100644 
> gcc/testsuite/gcc.target/riscv/rvv/autovec/unop/math-ceil-run-0.c
>
>
>
> diff --git 
> a/gcc/testsuite/gcc.target/riscv/rvv/autovec/unop/math-ceil-run-0.c 
> b/gcc/testsuite/gcc.target/riscv/rvv/autovec/unop/math-ceil-run-0.c
>
> deleted file mode 100644
>
> index 600c161159d..000
>
> --- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/unop/math-ceil-run-0.c
>
> +++ /dev/null
>
> @@ -1,39 +0,0 @@
>
> -/* { dg-do run { target { riscv_vector } } } */
>
> -/* { dg-additional-options "-std=c2x -O3 -ftree-vectorize 
> -fno-vect-cost-model -ffast-math" } */
>
> -
>
> -#include "test-math.h"
>
> -
>
> -#define ARRAY_SIZE 128
>
> -
>
> -_Float16 in[ARRAY_SIZE];
>
> -_Float16 out[ARRAY_SIZE];
>
> -_Float16 ref[ARRAY_SIZE];
>
> -
>
> -TEST_UNARY_CALL (_Float16, __builtin_ceilf16)
>
> -TEST_ASSERT (_Float16)
>
> -
>
> -TEST_INIT (_Float16, 1.2, 2.0, 1)
>
> -TEST_INIT (_Float16, -1.2, -1.0, 2)
>
> -TEST_INIT (_Float16, 3.0, 3.0, 3)
>
> -TEST_INIT (_Float16, 1023.5, 1024.0, 4)
>
> -TEST_INIT (_Float16, 1025.0, 1025.0, 5)
>
> -TEST_INIT (_Float16, 0.0, 0.0, 6)
>
> -TEST_INIT (_Float16, -0.0, -0.0, 7)
>
> -TEST_INIT (_Float16, -1023.5, -1023.0, 8)
>
> -TEST_INIT (_Float16, -1024.0, -1024.0, 9)
>
> -
>
> -int
>
> -main ()
>
> -{
>
> -  RUN_TEST (_Float16, 1, __builtin_ceilf16, in, out, ref, ARRAY_SIZE);
>
> -  RUN_TEST (_Float16, 2, __builtin_ceilf16, in, out, ref, ARRAY_SIZE);
>
> -  RUN_TEST (_Float16, 3, __builtin_ceilf16, in, out, ref, ARRAY_SIZE);
>
> -  RUN_TEST (_Float16, 4, __builtin_ceilf16, in, out, ref, ARRAY_SIZE);
>
> -  RUN_TEST (_Float16, 5, __builtin_ceilf16, in, out, ref, ARRAY_SIZE);
>
> -  RUN_TEST (_Float16, 6, __builtin_ceilf16, in, out, ref, ARRAY_SIZE);
>
> -  RUN_TEST (_Float16, 7, __builtin_ceilf16, in, out, ref, ARRAY_SIZE);
>
> -  RUN_TEST (_Float16, 8, __builtin_ceilf16, in, out, ref, ARRAY_SIZE);
>
> -  RUN_TEST (_Float16, 9, __builtin_ceilf16, in, out, ref, ARRAY_SIZE);
>
> -
>
> -  return 0;
>
> -}
>
> --
>
> 2.34.1
>
>
>
>


[PATCH] libstdc++: Ensure active union member is correctly set

2023-09-23 Thread Nathaniel Shead
On Sat, Sep 23, 2023 at 07:40:48AM +0100, Jonathan Wakely wrote:
> On Sat, 23 Sept 2023, 01:39 Nathaniel Shead via Libstdc++, <
> libstd...@gcc.gnu.org> wrote:
> 
> > Now that bootstrap has finished, I have gotten regressions in the
> > following libstdc++ tests:
> >
> > Running libstdc++:libstdc++-dg/conformance.exp ...
> > FAIL: 20_util/bitset/access/constexpr.cc -std=gnu++23 (test for excess
> > errors)
> > FAIL: 20_util/bitset/access/constexpr.cc -std=gnu++26 (test for excess
> > errors)
> > FAIL: 20_util/variant/constexpr.cc -std=gnu++20 (test for excess errors)
> > FAIL: 20_util/variant/constexpr.cc -std=gnu++26 (test for excess errors)
> > FAIL: 21_strings/basic_string/cons/char/constexpr.cc -std=gnu++20 (test
> > for excess errors)
> > FAIL: 21_strings/basic_string/cons/char/constexpr.cc -std=gnu++26 (test
> > for excess errors)
> > FAIL: 21_strings/basic_string/cons/wchar_t/constexpr.cc -std=gnu++20 (test
> > for excess errors)
> > FAIL: 21_strings/basic_string/cons/wchar_t/constexpr.cc -std=gnu++26 (test
> > for excess errors)
> > FAIL: 21_strings/basic_string/modifiers/swap/constexpr-wchar_t.cc
> > -std=gnu++20 (test for excess errors)
> > FAIL: 21_strings/basic_string/modifiers/swap/constexpr-wchar_t.cc
> > -std=gnu++26 (test for excess errors)
> > FAIL: 21_strings/basic_string/modifiers/swap/constexpr.cc -std=gnu++20
> > (test for excess errors)
> > FAIL: 21_strings/basic_string/modifiers/swap/constexpr.cc -std=gnu++26
> > (test for excess errors)
> > FAIL: std/ranges/adaptors/join_with/1.cc -std=gnu++23 (test for excess
> > errors)
> > UNRESOLVED: std/ranges/adaptors/join_with/1.cc -std=gnu++23 compilation
> > failed to produce executable
> > FAIL: std/ranges/adaptors/join_with/1.cc -std=gnu++26 (test for excess
> > errors)
> > UNRESOLVED: std/ranges/adaptors/join_with/1.cc -std=gnu++26 compilation
> > failed to produce executable
> >
> > On investigation though it looks like the issue might be with libstdc++
> > rather than the patch itself; running the failing tests using clang with
> > libstdc++ also produces similar errors, and my reading of the code
> > suggests that this is correct.
> >
> > What's the way forward here? Should I look at creating a patch to fix
> > the libstdc++ issues before resubmitting this patch for the C++
> > frontend? Or should I submit a version of this patch without the
> > `std::construct_at` changes and wait till libstdc++ gets fixed for that?
> >
> 
> I think we should fix libstdc++. There are probably only a few places that
> need a fix, which cause all those failures.
> 
> I can help with those fixes. I'll look into it after the weekend.
> 

Thanks. I did end up getting a chance to look at it earlier today, and
with the following patch I had no regressions when applying the frontend
changes. Bootstrapped and regtested on x86_64-pc-linux-gnu.

-- >8 --

This patch ensures that the union members for std::string and
std::variant are always properly set when a change occurs.

libstdc++-v3/ChangeLog:

* include/bits/basic_string.h: (basic_string(basic_string&&)):
Activate _M_local_buf when needed.
(basic_string(basic_string&&, const _Alloc&)): Likewise.
* include/bits/basic_string.tcc: (basic_string::swap): Likewise.
* include/std/variant: (__detail::__variant::__construct_n): New.
(__detail::_variant::__emplace): Use __construct_n.

Signed-off-by: Nathaniel Shead 
---
 libstdc++-v3/include/bits/basic_string.h   |  7 +++--
 libstdc++-v3/include/bits/basic_string.tcc |  8 +++---
 libstdc++-v3/include/std/variant   | 32 --
 3 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/libstdc++-v3/include/bits/basic_string.h 
b/libstdc++-v3/include/bits/basic_string.h
index 09fd62afa66..7c342879827 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -678,7 +678,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   {
if (__str._M_is_local())
  {
-   traits_type::copy(_M_local_buf, __str._M_local_buf,
+   traits_type::copy(_M_use_local_data(), __str._M_local_buf,
  __str.length() + 1);
  }
else
@@ -691,7 +691,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
// basic_stringbuf relies on writing into unallocated capacity so
// we mess up the contents if we put a '\0' in the string.
_M_length(__str.length());
-   __str._M_data(__str._M_local_data());
+   __str._M_data(__str._M_use_local_data());
__str._M_set_length(0);
   }
 
@@ -717,6 +717,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   {
if (__str._M_is_local())
  {
+   _M_use_local_data();
traits_type::copy(_M_local_buf, __str._M_local_buf,
  __str.length() + 1);
_M_length(__str.length());
@@ -728,7 +729,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
_M_data(__str._M_data());
_M_length(__str.length());
  

Re: [PATCH v4] c++: Check for indirect change of active union member in constexpr [PR101631,PR102286]

2023-09-23 Thread Jonathan Wakely
On Sat, 23 Sept 2023, 01:39 Nathaniel Shead via Libstdc++, <
libstd...@gcc.gnu.org> wrote:

> Now that bootstrap has finished, I have gotten regressions in the
> following libstdc++ tests:
>
> Running libstdc++:libstdc++-dg/conformance.exp ...
> FAIL: 20_util/bitset/access/constexpr.cc -std=gnu++23 (test for excess
> errors)
> FAIL: 20_util/bitset/access/constexpr.cc -std=gnu++26 (test for excess
> errors)
> FAIL: 20_util/variant/constexpr.cc -std=gnu++20 (test for excess errors)
> FAIL: 20_util/variant/constexpr.cc -std=gnu++26 (test for excess errors)
> FAIL: 21_strings/basic_string/cons/char/constexpr.cc -std=gnu++20 (test
> for excess errors)
> FAIL: 21_strings/basic_string/cons/char/constexpr.cc -std=gnu++26 (test
> for excess errors)
> FAIL: 21_strings/basic_string/cons/wchar_t/constexpr.cc -std=gnu++20 (test
> for excess errors)
> FAIL: 21_strings/basic_string/cons/wchar_t/constexpr.cc -std=gnu++26 (test
> for excess errors)
> FAIL: 21_strings/basic_string/modifiers/swap/constexpr-wchar_t.cc
> -std=gnu++20 (test for excess errors)
> FAIL: 21_strings/basic_string/modifiers/swap/constexpr-wchar_t.cc
> -std=gnu++26 (test for excess errors)
> FAIL: 21_strings/basic_string/modifiers/swap/constexpr.cc -std=gnu++20
> (test for excess errors)
> FAIL: 21_strings/basic_string/modifiers/swap/constexpr.cc -std=gnu++26
> (test for excess errors)
> FAIL: std/ranges/adaptors/join_with/1.cc -std=gnu++23 (test for excess
> errors)
> UNRESOLVED: std/ranges/adaptors/join_with/1.cc -std=gnu++23 compilation
> failed to produce executable
> FAIL: std/ranges/adaptors/join_with/1.cc -std=gnu++26 (test for excess
> errors)
> UNRESOLVED: std/ranges/adaptors/join_with/1.cc -std=gnu++26 compilation
> failed to produce executable
>
> On investigation though it looks like the issue might be with libstdc++
> rather than the patch itself; running the failing tests using clang with
> libstdc++ also produces similar errors, and my reading of the code
> suggests that this is correct.
>
> What's the way forward here? Should I look at creating a patch to fix
> the libstdc++ issues before resubmitting this patch for the C++
> frontend? Or should I submit a version of this patch without the
> `std::construct_at` changes and wait till libstdc++ gets fixed for that?
>

I think we should fix libstdc++. There are probably only a few places that
need a fix, which cause all those failures.

I can help with those fixes. I'll look into it after the weekend.



> On Sat, Sep 23, 2023 at 01:01:20AM +1000, Nathaniel Shead wrote:
> > On Fri, Sep 22, 2023 at 02:21:15PM +0100, Jason Merrill wrote:
> > > On 9/21/23 09:41, Nathaniel Shead wrote:
> > > > I've updated the error messages, and also fixed another bug I found
> > > > while retesting (value-initialised unions weren't considered to have
> any
> > > > active member yet).
> > > >
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu.
> > > >
> > > > -- >8 --
> > > >
> > > > This patch adds checks for attempting to change the active member of
> a
> > > > union by methods other than a member access expression.
> > > >
> > > > To be able to properly distinguish `*() = ` from `u.a = `, this
> > > > patch redoes the solution for c++/59950 to avoid extranneous *&; it
> > > > seems that the only case that needed the workaround was when copying
> > > > empty classes.
> > > >
> > > > This patch also ensures that constructors for a union field mark that
> > > > field as the active member before entering the call itself; this
> ensures
> > > > that modifications of the field within the constructor's body don't
> > > > cause false positives (as these will not appear to be member access
> > > > expressions). This means that we no longer need to start the
> lifetime of
> > > > empty union members after the constructor body completes.
> > > >
> > > > As a drive-by fix, this patch also ensures that value-initialised
> unions
> > > > are considered to have activated their initial member for the
> purpose of
> > > > checking stores, which catches some additional mistakes pre-C++20.
> > > >
> > > >   PR c++/101631
> > > >
> > > > gcc/cp/ChangeLog:
> > > >
> > > >   * call.cc (build_over_call): Fold more indirect refs for trivial
> > > >   assignment op.
> > > >   * class.cc (type_has_non_deleted_trivial_default_ctor): Create.
> > > >   * constexpr.cc (cxx_eval_call_expression): Start lifetime of
> > > >   union member before entering constructor.
> > > >   (cxx_eval_store_expression): Activate member for
> > > >   value-initialised union. Check for accessing inactive union
> > > >   member indirectly.
> > > >   * cp-tree.h (type_has_non_deleted_trivial_default_ctor):
> > > >   Forward declare.
> > > >
> > > > gcc/testsuite/ChangeLog:
> > > >
> > > >   * g++.dg/cpp1y/constexpr-89336-3.C: Fix union initialisation.
> > > >   * g++.dg/cpp1y/constexpr-union6.C: New test.
> > > >   * g++.dg/cpp2a/constexpr-union2.C: New test.
> > > >   * g++.dg/cpp2a/constexpr-union3.C: New test.
> > > >   *