Re: [PATCH] ppc: testsuite: vec-mul requires vsx runtime

[Kewen.Lin]

on 2024/4/22 17:35, Alexandre Oliva wrote:
> Ping?
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593947.html
> 
> 
> vec-mul is an execution test, but it only requires a powerpc_vsx_ok
> effective target, which is enough only for compile tests.  In order to
> To check for runtime and execution environment support, we need to
> require vsx_hw.  Make that a condition for execution, but still
> perform a compile test if the condition is not satisfied.
> 
> Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu.  Also tested with
> gcc-13 on ppc64-vx7r2 and ppc-vx7r2.  Ok to install?
> 
> 
> for  gcc/testsuite/ChangeLog
> 
>   * gcc.target/powerpc/vec-mul.c: Run on target vsx_hw, just
>   compile otherwise.
> ---
>  gcc/testsuite/gcc.target/powerpc/vec-mul.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/testsuite/gcc.target/powerpc/vec-mul.c 
> b/gcc/testsuite/gcc.target/powerpc/vec-mul.c
> index bfcaf80719d1d..11da86159723f 100644
> --- a/gcc/testsuite/gcc.target/powerpc/vec-mul.c
> +++ b/gcc/testsuite/gcc.target/powerpc/vec-mul.c
> @@ -1,4 +1,5 @@
> -/* { dg-do run } */
> +/* { dg-do compile { target { ! vsx_hw } } } */
> +/* { dg-do run { target vsx_hw } } */
>  /* { dg-require-effective-target powerpc_vsx_ok } */

Nit: It's useless to check powerpc_vsx_ok for vsx_hw, so powerpc_vsx_ok check
can be moved to be with ! vsx_hw.

OK with this nit tweaked, thanks!

BR,
Kewen

>  /* { dg-options "-mvsx -O3" } */
> 
> 
> 

RE: [PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d and e65aaf8efe1

[Li, Pan2]

Hi Patrick,

After some investigation and double confirm, I think the 
gcc.dg/graphite/pr111878.c ice may have nothing to do
with the patches of revert series as it exists for quit a while. It may related 
to below commit 

2e7abd09621a4401d44f4513adf126bce4b4828b RISC-V: Block VLSmodes according to 
TARGET_MAX_LMUL and BITS_PER_RISCV_VECTOR

Could you please help to double check about it *manually*? Here is my step(s) 
for your reference and I will take care of this failure soon.

../__RISC-V_INSTALL___RV64/bin/riscv64-unknown-elf-gcc --version  
riscv64-unknown-elf-gcc (GCC) 14.0.0 20231205 (experimental)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

1. download isl-0.24, let isl -> /some-where/riscv-gnu-toolchain/gcc/isl-0.24
2. mkdir __BUILD__ && cd __BUILD__ && ../configure \
  --target=riscv64-unknown-elf \
  --prefix=${INSTALL_DIR} \
  --disable-shared \
  --enable-threads \
  --enable-tls \
  --enable-languages=c,c++,fortran \
  --with-system-zlib \
  --with-newlib \
  --disable-libmudflap \
  --disable-libssp \
  --disable-libquadmath \
  --disable-libgomp \
  --enable-nls \
  --disable-tm-clone-registry \
  --src=`pwd`/../ \
  --with-abi=lp64d \
  --with-arch=rv64gcv \
  --with-tune=rocket \
  --with-isa-spec=20191213 \
  CFLAGS_FOR_BUILD="-O0 -g" \
  CXXFLAGS_FOR_BUILD="-O0 -g" \
  CFLAGS_FOR_TARGET="-O0  -g" \
  CXXFLAGS_FOR_TARGET="-O0 -g" \
  BOOT_CFLAGS="-O0 -g" \
  CFLAGS="-O0 -g" \
  CXXFLAGS="-O0 -g" \
  GM2FLAGS_FOR_TARGET="-O0 -g" \
  GOCFLAGS_FOR_TARGET="-O0 -g" \
  GDCFLAGS_FOR_TARGET="-O0 -g"
make -j $(nproc) all-gcc && make install-gcc
3. ../__RISC-V_INSTALL___RV64/bin/riscv64-unknown-elf-gcc 
gcc/testsuite/gcc.dg/graphite/pr111878.c -O3 -fgraphite-identity 
-fsave-optimization-record -march=rv64gcv -mabi=lp64d -c -S -o -

Pan

-Original Message-
From: Li, Pan2 
Sent: Tuesday, April 23, 2024 10:32 AM
To: Patrick O'Neill ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; rdapp@gmail.com
Subject: RE: [PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d 
and e65aaf8efe1

Thanks Patrick.

Turn out that the make report cannot tell the error like below and then the 
graphite.exp test will never run.
That explains why I missed test failures, will take care of it ASAP.

sorry, unimplemented: Graphite loop optimizations cannot be used (isl is not 
available)

Pan

-Original Message-
From: Patrick O'Neill  
Sent: Tuesday, April 23, 2024 8:32 AM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; rdapp@gmail.com
Subject: Re: [PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d 
and e65aaf8efe1

This patch in particular does not cause any more regressions. It's one 
of the other reverts from the weekend.

Before the reverts [1]:
                     |  gcc |  
g++ | gfortran |
     rv64gcv/  lp64d/ medlow |   48/    32 |     12/    3|   12 /    2

After the reverts:
                     |  gcc |  
g++ | gfortran |
     rv64gcv/  lp64d/ medlow |   50 /    33 |   12 / 3 |   26 / 7 |


gcc new fails:
FAIL: gcc.dg/graphite/pr111878.c (internal compiler error: in 
extract_insn, at recog.cc:2812)
FAIL: gcc.dg/graphite/pr111878.c (test for excess errors)

gfortran new fails:
FAIL: gfortran.dg/graphite/id-27.f90   -O  (internal compiler error: in 
extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/id-27.f90   -O  (test for excess errors)
FAIL: gfortran.dg/graphite/pr14741.f90   -O  (internal compiler error: 
in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr14741.f90   -O  (test for excess errors)
FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal 
compiler error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for 
excess errors)
FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -g  (internal compiler 
error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal 
compiler error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for 
excess errors)
FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -g  (internal compiler 
error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/graphite/vect-pr40979.f90   -O  (internal compiler 
error: in extract_insn, at recog.cc:2812

Re: [PATCH] Request check for hw support in ppc run tests with -maltivec/-mvsx

[Kewen.Lin]

on 2024/4/22 17:31, Alexandre Oliva wrote:
> 
> From: Olivier Hainque 
> 
> Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu.  Also tested with
> gcc-13 on ppc64-vx7r2 and ppc-vx7r2.  Ok to install?

OK, thanks!

BR,
Kewen

> 
> for  gcc/testsuite/ChangeLog
> 
>   * gcc.target/powerpc/swaps-p8-20.c: Change powerpc_altivec_ok
>   require-effective-target test into vmx_hw.
>   * gcc.target/powerpc/vsx-vector-5.c: Change powerpc_vsx_ok
>   require-effective-target test into vsx_hw.
> ---
>  gcc/testsuite/gcc.target/powerpc/swaps-p8-20.c  |2 +-
>  gcc/testsuite/gcc.target/powerpc/vsx-vector-5.c |5 +
>  2 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.target/powerpc/swaps-p8-20.c 
> b/gcc/testsuite/gcc.target/powerpc/swaps-p8-20.c
> index 564e8acb1f421..755519bfe847d 100644
> --- a/gcc/testsuite/gcc.target/powerpc/swaps-p8-20.c
> +++ b/gcc/testsuite/gcc.target/powerpc/swaps-p8-20.c
> @@ -1,5 +1,5 @@
>  /* { dg-do run } */
> -/* { dg-require-effective-target powerpc_altivec_ok } */
> +/* { dg-require-effective-target vmx_hw } */
>  /* { dg-options "-O2 -mdejagnu-cpu=power8 -maltivec" } */
>  
>  /* The expansion for vector character multiply introduces a vperm operation.
> diff --git a/gcc/testsuite/gcc.target/powerpc/vsx-vector-5.c 
> b/gcc/testsuite/gcc.target/powerpc/vsx-vector-5.c
> index dcc88b1f3a4c6..37a324b6f897d 100644
> --- a/gcc/testsuite/gcc.target/powerpc/vsx-vector-5.c
> +++ b/gcc/testsuite/gcc.target/powerpc/vsx-vector-5.c
> @@ -1,11 +1,8 @@
>  /* { dg-do run { target lp64 } } */
>  /* { dg-skip-if "" { powerpc*-*-darwin* } } */
> -/* { dg-require-effective-target powerpc_vsx_ok } */
> +/* { dg-require-effective-target vsx_hw } */
>  /* { dg-options "-mvsx -O2" } */
>  
> -/* This will run, and someday we should add the support to test whether we 
> are
> -   running on VSX hardware.  */
> -
>  #include 
>  #include 
>  
> 

Re: [PATCH] disable ldist for test, to restore vectorizing-candidate loop

[Kewen.Lin]

on 2024/4/22 17:27, Alexandre Oliva wrote:
> Ping?
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566524.html
> 
> The loop we're supposed to try to vectorize in
> gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c is turned into a memset
> before the vectorizer runs.
> 
> Various other tests in this set have already run into this, and the
> solution has been to disable this loop distribution transformation,
> enabled at -O2, so that the vectorizer gets a chance to transform the
> loop and, in this testcase, fail to do so.
> 
> Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu.  Also tested with
> gcc-13 on ppc64-vx7r2 and ppc-vx7r2.  Ok to install?

OK, thanks!

BR,
Kewen

> 
> 
> for  gcc/testsuite/ChangeLog
> 
>   * gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Disable
>   ldist.
> ---
>  .../gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c 
> b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
> index 454a714a30916..90b5d5a7f400b 100644
> --- a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
> +++ b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
> @@ -1,4 +1,5 @@
>  /* { dg-require-effective-target vect_int } */
> +/* { dg-additional-options "-fno-tree-loop-distribute-patterns" } */
> 
>  #include 
>  #include "../../tree-vect.h"
> 

Re: [PATCH] [testsuite] [ppc64] expect error on vxworks too

[Kewen.Lin]

on 2024/4/22 17:23, Alexandre Oliva wrote:
> 
> These ppc lp64 tests check for errors or warnings on -mno-powerpc64.
> On powerpc64-*-vxworks* we get the same errors as on most other
> covered platforms, but the tests did not mark them as expected for
> this target.  On powerpc-*-vxworks*, the tests are skipped because
> lp64 is not satisfied, so I'm naming powerpc*-*-vxworks* rather than
> something more specific.
> 
> Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu.  Also tested with
> gcc-13 on ppc64-vx7r2 and ppc-vx7r2.  Ok to install?

OK, thanks!

BR,
Kewen

> 
> 
> for  gcc/testsuite/ChangeLog
> 
>   * gcc.target/powerpc/pr106680-1.c: Error on vxworks too.
>   * gcc.target/powerpc/pr106680-2.c: Likewise.
>   * gcc.target/powerpc/pr106680-3.c: Likewise.
> ---
>  gcc/testsuite/gcc.target/powerpc/pr106680-1.c |2 +-
>  gcc/testsuite/gcc.target/powerpc/pr106680-2.c |2 +-
>  gcc/testsuite/gcc.target/powerpc/pr106680-3.c |2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr106680-1.c 
> b/gcc/testsuite/gcc.target/powerpc/pr106680-1.c
> index d624d43230a7a..aadaa614cfeba 100644
> --- a/gcc/testsuite/gcc.target/powerpc/pr106680-1.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr106680-1.c
> @@ -8,6 +8,6 @@ int foo ()
>return 1;
>  }
> 
> -/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target 
> powerpc*-*-linux* powerpc*-*-freebsd* powerpc-*-rtems* } 0 } */
> +/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target 
> powerpc*-*-linux* powerpc*-*-freebsd* powerpc-*-rtems* powerpc*-*-vxworks* } 
> 0 } */
>  /* { dg-warning "'-m64' requires PowerPC64 architecture, enabling" 
> "PR106680" { target powerpc*-*-darwin* } 0 } */
>  /* { dg-warning "'-maix64' requires PowerPC64 architecture remain enabled" 
> "PR106680" { target powerpc*-*-aix* } 0 } */
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr106680-2.c 
> b/gcc/testsuite/gcc.target/powerpc/pr106680-2.c
> index a9ed73726ef0c..f0758e303350a 100644
> --- a/gcc/testsuite/gcc.target/powerpc/pr106680-2.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr106680-2.c
> @@ -9,6 +9,6 @@ int foo ()
>return 1;
>  }
> 
> -/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target 
> powerpc*-*-linux* powerpc*-*-freebsd* powerpc-*-rtems* } 0 } */
> +/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target 
> powerpc*-*-linux* powerpc*-*-freebsd* powerpc-*-rtems* powerpc*-*-vxworks* } 
> 0 } */
>  /* { dg-warning "'-m64' requires PowerPC64 architecture, enabling" 
> "PR106680" { target powerpc*-*-darwin* } 0 } */
>  /* { dg-warning "'-maix64' requires PowerPC64 architecture remain enabled" 
> "PR106680" { target powerpc*-*-aix* } 0 } */
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr106680-3.c 
> b/gcc/testsuite/gcc.target/powerpc/pr106680-3.c
> index b642d5c7a008d..bca012e2cf663 100644
> --- a/gcc/testsuite/gcc.target/powerpc/pr106680-3.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr106680-3.c
> @@ -8,6 +8,6 @@ int foo ()
>return 1;
>  }
> 
> -/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target 
> powerpc*-*-linux* powerpc*-*-freebsd* powerpc-*-rtems* } 0 } */
> +/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target 
> powerpc*-*-linux* powerpc*-*-freebsd* powerpc-*-rtems* powerpc*-*-vxworks* } 
> 0 } */
>  /* { dg-warning "'-m64' requires PowerPC64 architecture, enabling" 
> "PR106680" { target powerpc*-*-darwin* } 0 } */
>  /* { dg-warning "'-maix64' requires PowerPC64 architecture remain enabled" 
> "PR106680" { target powerpc*-*-aix* } 0 } */
> 

[PATCH] RISC-V: Add -X to link spec

[Fangrui Song]

From: Fangrui Song 

--discard-locals (-X) instructs the linker to remove local .L* symbols,
which occur a lot due to label differences for linker relaxation. The
arm port has a similar need and passes -X to ld.

In contrast, the RISC-V port does not pass -X to ld and rely on the
default --discard-locals in GNU ld's riscv port. The arm way is more
conventional (compiler driver instead of the linker customizes the
default behavior) and works with lld.
---
 gcc/config/riscv/elf.h | 1 +
 gcc/config/riscv/freebsd.h | 1 +
 gcc/config/riscv/linux.h   | 1 +
 3 files changed, 3 insertions(+)

diff --git a/gcc/config/riscv/elf.h b/gcc/config/riscv/elf.h
index f533764d9f8..c97f13c0cca 100644
--- a/gcc/config/riscv/elf.h
+++ b/gcc/config/riscv/elf.h
@@ -20,6 +20,7 @@ along with GCC; see the file COPYING3.  If not see
 #define LINK_SPEC "\
 -melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv \
 %{mno-relax:--no-relax} \
+-X \
 %{mbig-endian:-EB} \
 %{mlittle-endian:-EL} \
 %{shared}"
diff --git a/gcc/config/riscv/freebsd.h b/gcc/config/riscv/freebsd.h
index bd08a985285..5dd4d51c42b 100644
--- a/gcc/config/riscv/freebsd.h
+++ b/gcc/config/riscv/freebsd.h
@@ -44,6 +44,7 @@ along with GCC; see the file COPYING3.  If not see
   %{p:%nconsider using `-pg' instead of `-p' with gprof (1)}   \
   %{v:-V}  \
   %{assert*} %{R*} %{rpath*} %{defsym*}\
+  -X   \
   %{mbig-endian:-EB}   \
   %{mlittle-endian:-EL}\
   %{shared:-Bshareable %{h*} %{soname*}}   \
diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
index 15851f653bc..3c356227134 100644
--- a/gcc/config/riscv/linux.h
+++ b/gcc/config/riscv/linux.h
@@ -50,6 +50,7 @@ along with GCC; see the file COPYING3.  If not see
 #define LINK_SPEC "\
 -melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv" LD_EMUL_SUFFIX " \
 %{mno-relax:--no-relax} \
+-X \
 %{mbig-endian:-EB} \
 %{mlittle-endian:-EL} \
 %{shared} \
-- 
2.44.0.769.g3c40516874-goog

[PATCH] wwwdocs: gcc-14/changes.html: Add Loongarch changes.

[Lulu Cheng]

---
 htdocs/gcc-14/changes.html | 156 +
 1 file changed, 156 insertions(+)

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 9509487c..f0f0efe0 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -877,6 +877,162 @@ __asm (".global __flmap_lock"  "\n\t"
   
 
 
+LoongArch
+
+  Support for the following
+  https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Options.html#index-march-7";>
+  -march parameters has been added:
+  
+la64v1.0
+la64v1.1
+la664
+  
+  It is now recommended to use -march=la64v1.0 as the only
+  compiler option to describe the target ISA when building binaries for
+  distribution. For more information on LoongArch ISA versions, see
+  https://github.com/loongson/la-toolchain-conventions/";>
+  Toolchain Conventions of the LoongArch™ Architecture.
+  
+  Support for the following
+  https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Options.html#index-mtune-8";>
+  -mtune parameters has been added:
+  
+generic
+la664
+  
+  
+  New ISA Extension
+
+  LSX (Loongson SIMD Extension): Support 128-bit vector instructions
+  and the intrinsics.
+  
+  LASX (Loongson Advanced SIMD Extension): Support 256-bit vector
+  instructions and the intrinsics.
+  
+  FRECIPE: Support frecipe.{s/d} and
+  frsqrte.{s/d} instructions and the intrinsics.
+  
+  DIV32: Support div.w[u] and mod.w[u]
+  instructions with inputs not sign-extended.
+  
+  LAM_BH: Support am{swap/add}[_db].{b/h} instructions.
+  
+  LAMCAS: Support amcas[_db].{b/h/w/d} instructions.
+  
+
+  
+  New Built-in Macros
+
+  __loongarch_arch: Target ISA preset as specified by
+  -march=. For example, compiling with
+  -march=la64v1.0, the value of 
__loongarch_arch
+  is "la64v1.0".
+  
+  __loongarch_tune: Processor model as specified by
+  -mtune or its default value.
+  
+  __loongarch_{simd,sx,asx}: These macros are not defined,
+  or defined as 1.
+  
+  __loongarch_simd_width: The maximum SIMD bit-width
+  enabled by the compiler. (128 for lsx, and 256 for lasx).
+  
+  __loongarch_frecipe: It's defined to 1 or undefined.
+  
+  __loongarch_div32: It's defined to 1 or undefined.
+  __loongarch_lam_bh: It's defined to 1 or undefined.
+  __loongarch_lamcas: It's defined to 1 or undefined.
+  __loongarch_ld_seq_sa: It's defined to 1 or undefined.
+  
+  __loongarch_version_major:
+  The minimally required LoongArch ISA version (major) to run the
+  compiled program, defined to 1 or undefined (iff no such version is
+  known to the compiler).
+  
+  __loongarch_version_minor:
+  The minimally required LoongArch ISA version (minor) to run the
+  compiled program, defined to 0 1 or undefined (iff
+  __loongarch_version_major is undefined).
+  
+  __FLOAT128_TYPE: It's defined to 1.
+
+  
+  New Intrinsics
+
+  https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Base-Built-in-Functions.html";>
+  __builtin_thread_pointer
+  
+  https://gcc.gnu.org/onlinedocs/gcc/LoongArch-SX-Vector-Intrinsics.html";>
+  __lsx_*
+  
+  https://gcc.gnu.org/onlinedocs/gcc/LoongArch-ASX-Vector-Intrinsics.html";>
+  __lasx_*
+  
+  https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Base-Built-in-Functions.html";>
+  __frecipe_{s/d} and __frsqrte_{s/d}
+  
+
+  
+  New Compiler Option
+
+  https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Options.html#index-ml_005ba_005dsx";>
+  -m[no-]lsx
+  
+  https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Options.html#index-ml_005ba_005dsx";>
+  -m[no-]lasx
+  
+  https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Options.html#index-mfrecipe";>
+  -m[no-]frecipe
+  
+  https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Options.html#index-mdiv32";>
+  -m[no-]div32
+  
+  https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Options.html#index-mlam-bh";>
+  -m[no-]lam-bh
+  
+  https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Options.html#index-mlamcas";>
+  -m[no-]lamcas
+  
+  https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Options.html#index-mld-seq-sa";>
+  -m[no-]ld-seq-sa
+  
+  https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Options.html#index-mrecip_003dopt";>
+  -mrecip=
+  
+  https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Options.html#index-mrecip";>
+  -m[no-]recip
+  
+  https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Options.html#index-mexplicit-relocs-1";>
+  -mexplicit-relocs={none,always,auto}
+  
+  https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Options.html#index-mrelax-2";>
+  -m[no-]re

Re:[pushed] [PATCH v4 1/2] LoongArch: Define ISA versions

[Lulu Cheng]

Pushed to r14-10083.

在 2024/4/23 上午10:42, Yang Yujie 写道:

These ISA versions are defined as -march= parameters and
are recommended for building binaries for distribution.

Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.

gcc/ChangeLog:

* config.gcc: Make la64v1.0 the default ISA preset of the lp64d ABI.
* config/loongarch/genopts/loongarch-strings: Define la64v1.0, la64v1.1.
* config/loongarch/genopts/loongarch.opt.in: Likewise.
* config/loongarch/loongarch-c.cc (LARCH_CPP_SET_PROCESSOR): Likewise.
(loongarch_cpu_cpp_builtins): Likewise.
* config/loongarch/loongarch-cpu.cc (get_native_prid): Likewise.
(fill_native_cpu_config): Likewise.
* config/loongarch/loongarch-def.cc (array_tune): Likewise.
* config/loongarch/loongarch-def.h: Likewise.
* config/loongarch/loongarch-driver.cc (driver_set_m_parm): Likewise.
(driver_get_normalized_m_opts): Likewise.
* config/loongarch/loongarch-opts.cc (default_tune_for_arch): Likewise.
(TUNE_FOR_ARCH): Likewise.
(arch_str): Likewise.
(loongarch_target_option_override): Likewise.
* config/loongarch/loongarch-opts.h (TARGET_uARCH_LA464): Likewise.
(TARGET_uARCH_LA664): Likewise.
* config/loongarch/loongarch-str.h (STR_CPU_ABI_DEFAULT): Likewise.
(STR_ARCH_ABI_DEFAULT): Likewise.
(STR_TUNE_GENERIC): Likewise.
(STR_ARCH_LA64V1_0): Likewise.
(STR_ARCH_LA64V1_1): Likewise.
* config/loongarch/loongarch.cc 
(loongarch_cpu_sched_reassociation_width): Likewise.
(loongarch_asm_code_end): Likewise.
* config/loongarch/loongarch.opt: Likewise.
* doc/invoke.texi: Likewise.
---
  gcc/config.gcc| 34 
  .../loongarch/genopts/loongarch-strings   |  5 +-
  gcc/config/loongarch/genopts/loongarch.opt.in | 43 --
  gcc/config/loongarch/loongarch-c.cc   | 37 +++--
  gcc/config/loongarch/loongarch-cpu.cc | 35 
  gcc/config/loongarch/loongarch-def.cc | 83 +--
  gcc/config/loongarch/loongarch-def.h  | 37 ++---
  gcc/config/loongarch/loongarch-driver.cc  |  8 +-
  gcc/config/loongarch/loongarch-opts.cc| 66 +++
  gcc/config/loongarch/loongarch-opts.h |  4 +-
  gcc/config/loongarch/loongarch-str.h  |  5 +-
  gcc/config/loongarch/loongarch.cc | 11 +--
  gcc/config/loongarch/loongarch.opt| 43 --
  gcc/doc/invoke.texi   | 57 -
  14 files changed, 300 insertions(+), 168 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 5df3c52f8e9..929695c25ab 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -5072,7 +5072,7 @@ case "${target}" in
  
  		# Perform initial sanity checks on --with-* options.

case ${with_arch} in
-   "" | abi-default | loongarch64 | la[46]64) ;; # OK, append here.
+   "" | la64v1.[01] | abi-default | loongarch64 | la[46]64) ;; # 
OK, append here.
native)
if test x${host} != x${target}; then
echo "--with-arch=native is illegal for 
cross-compiler." 1>&2
@@ -5119,10 +5119,18 @@ case "${target}" in
  
  		# Infer ISA-related default options from the ABI: pass 1

case ${abi_base}/${abi_ext} in
-   lp64*/base)
+   lp64d/base)
# architectures that support lp64* ABI
-   arch_pattern="native|abi-default|loongarch64|la[46]64"
-   # default architecture for lp64* ABI
+   
arch_pattern="native|abi-default|la64v1.[01]|loongarch64|la[46]64"
+
+   # default architecture for lp64d ABI
+   arch_default="la64v1.0"
+   ;;
+   lp64[fs]/base)
+   # architectures that support lp64* ABI
+   
arch_pattern="native|abi-default|la64v1.[01]|loongarch64|la[46]64"
+
+   # default architecture for lp64[fs] ABI
arch_default="abi-default"
;;
*)
@@ -5194,15 +5202,7 @@ case "${target}" in
  
  
  		# Check default with_tune configuration using with_arch.

-   case ${with_arch} in
-   loongarch64)
-   tune_pattern="native|abi-default|loongarch64|la[46]64"
-   ;;
-   *)
-   # By default, $with_tune == $with_arch
-   tune_pattern="*"
-   ;;
-   esac
+   tune_pattern="native|generic|loongarch64|la[46]64"
  
  		case ${with_tune} in

"") ;; # OK
@@ -5252,7 +5252,7 @@ case "${tar

Re: [pushed][PATCH v4 2/2] LoongArch: Define builtin macros for ISA evolutions

[Lulu Cheng]

Pushed to r14-10084.

在 2024/4/23 上午10:42, Yang Yujie 写道:

Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.

gcc/ChangeLog:

* config.gcc: Add loongarch-evolution.o.
* config/loongarch/genopts/genstr.sh: Enable generation of
loongarch-evolution.[cc,h].
* config/loongarch/t-loongarch: Likewise.
* config/loongarch/genopts/gen-evolution.awk: New file.
* config/loongarch/genopts/isa-evolution.in: Mark ISA version
of introduction for each ISA evolution feature.
* config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins):
Define builtin macros for enabled ISA evolutions and the ISA
version.
* config/loongarch/loongarch-cpu.cc: Use loongarch-evolution.h.
* config/loongarch/loongarch.h: Likewise.
* config/loongarch/loongarch-cpucfg-map.h: Delete.
* config/loongarch/loongarch-evolution.cc: New file.
* config/loongarch/loongarch-evolution.h: New file.
* config/loongarch/loongarch-opts.h (ISA_HAS_FRECIPE): Define.
(ISA_HAS_DIV32): Likewise.
(ISA_HAS_LAM_BH): Likewise.
(ISA_HAS_LAMCAS): Likewise.
(ISA_HAS_LD_SEQ_SA): Likewise.
---
  gcc/config.gcc|   2 +-
  .../loongarch/genopts/gen-evolution.awk   | 230 ++
  gcc/config/loongarch/genopts/genstr.sh|  82 ++-
  gcc/config/loongarch/genopts/isa-evolution.in |  10 +-
  gcc/config/loongarch/loongarch-c.cc   |  23 ++
  gcc/config/loongarch/loongarch-cpu.cc |   2 +-
  gcc/config/loongarch/loongarch-evolution.cc   |  60 +
  ...rch-cpucfg-map.h => loongarch-evolution.h} |  46 +++-
  gcc/config/loongarch/loongarch-opts.h |  11 -
  gcc/config/loongarch/loongarch.h  |   1 +
  gcc/config/loongarch/t-loongarch  |  26 +-
  11 files changed, 398 insertions(+), 95 deletions(-)
  create mode 100644 gcc/config/loongarch/genopts/gen-evolution.awk
  create mode 100644 gcc/config/loongarch/loongarch-evolution.cc
  rename gcc/config/loongarch/{loongarch-cpucfg-map.h => loongarch-evolution.h} 
(52%)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 929695c25ab..3364fc27524 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -485,7 +485,7 @@ 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_objs="loongarch-c.o loongarch-builtins.o loongarch-cpu.o 
loongarch-opts.o loongarch-def.o loongarch-evolution.o"
extra_gcc_objs="loongarch-driver.o loongarch-cpu.o loongarch-opts.o 
loongarch-def.o"
extra_options="${extra_options} g.opt fused-madd.opt"
;;
diff --git a/gcc/config/loongarch/genopts/gen-evolution.awk 
b/gcc/config/loongarch/genopts/gen-evolution.awk
new file mode 100644
index 000..4d105afa906
--- /dev/null
+++ b/gcc/config/loongarch/genopts/gen-evolution.awk
@@ -0,0 +1,230 @@
+#!/usr/bin/gawk
+#
+# A simple script that generates loongarch-evolution.h
+# from genopts/isa-evolution.in
+#
+# Copyright (C) 2021-2024 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify it under
+# the terms of the GNU General Public License as published by the Free
+# Software Foundation; either version 3, or (at your option) any later
+# version.
+#
+# GCC is distributed in the hope that it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+# or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+# License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+BEGIN {
+# isa_version_major[]
+# isa_version_minor[]
+# cpucfg_word[]
+# cpucfg_bit_in_word[]
+# name_capitalized[]
+# comment[]
+}
+
+{
+cpucfg_word[NR] = $1
+cpucfg_bit_in_word[NR] = $2
+name[NR] = gensub(/-/, "_", "g", $3)
+name_capitalized[NR] = toupper(name[NR])
+isa_version_major[NR] = gensub(/^([1-9][0-9]*)\.([0-9]+)$/, "\\1", 1, $4)
+isa_version_minor[NR] = gensub(/^([1-9][0-9]*)\.([0-9]+)$/, "\\2", 1, $4)
+
+$1 = $2 = $3 = $4 = ""
+sub (/^\s*/, "")
+comment[NR] = $0
+}
+
+function copyright_header(from_year,to_year)
+{
+print "   Copyright (C) " from_year "-" to_year \
+  " Free Software Foundation, Inc."
+print ""
+print "This file is part of GCC."
+print ""
+print "GCC is free software; you can redistribute it and/or modify"
+print "it under the terms of the GNU General Public License as published 
by"
+print "the Free Software Foundation; either version 3, or (at yo

Re: [PATCH] c++: Check if allocation functions are xobj members [PR114078]

[Jason Merrill]

On 4/21/24 19:59, Patrick Palka wrote:

On Sat, 20 Apr 2024, Nathaniel Shead wrote:


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

-- >8 --

A class allocation member function is implicitly 'static' by
[class.free] p3, so cannot have an explicit object parameter.

PR c++/114078

gcc/cp/ChangeLog:

* decl.cc (grokdeclarator): Check allocation functions for xobj
parameters.

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/explicit-obj-ops-alloc.C: New test.


LGTM


Agreed, OK.

Re: [PATCH] c++, v2: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

[Jason Merrill]

On 4/22/24 08:42, Jakub Jelinek wrote:

On Wed, Apr 17, 2024 at 09:42:47AM +0200, Jakub Jelinek wrote:

When expand_or_defer_fn is called at_eof time, it calls import_export_decl
and then maybe_clone_body, which uses DECL_ONE_ONLY and comdat name in a
couple of places to try to optimize cdtors which are known to have the
same body by making the complete cdtor an alias to base cdtor (and in
that case also uses *[CD]5* as comdat group name instead of the normal
comdat group names specific to each mangled name).
Now, this optimization depends on DECL_ONE_ONLY and DECL_INTERFACE_KNOWN,
maybe_clone_body and can_alias_cdtor use:
   if (DECL_ONE_ONLY (fn))
 cgraph_node::get_create (clone)->set_comdat_group (cxx_comdat_group 
(clone));
...
   bool can_alias = can_alias_cdtor (fn);
...
   /* Tell cgraph if both ctors or both dtors are known to have
  the same body.  */
   if (can_alias
   && fns[0]
   && idx == 1
   && cgraph_node::get_create (fns[0])->create_same_body_alias
(clone, fns[0]))
 {
   alias = true;
   if (DECL_ONE_ONLY (fns[0]))
 {
   /* For comdat base and complete cdtors put them
  into the same, *[CD]5* comdat group instead of
  *[CD][12]*.  */
   comdat_group = cdtor_comdat_group (fns[1], fns[0]);
   cgraph_node::get_create (fns[0])->set_comdat_group 
(comdat_group);
   if (symtab_node::get (clone)->same_comdat_group)
 symtab_node::get (clone)->remove_from_same_comdat_group ();
   symtab_node::get (clone)->add_to_same_comdat_group
 (symtab_node::get (fns[0]));
 }
 }
and
   /* Don't use aliases for weak/linkonce definitions unless we can put both
  symbols in the same COMDAT group.  */
   return (DECL_INTERFACE_KNOWN (fn)
   && (SUPPORTS_ONE_ONLY || !DECL_WEAK (fn))
   && (!DECL_ONE_ONLY (fn)
   || (HAVE_COMDAT_GROUP && DECL_WEAK (fn;
The following testcase regressed with Marek's r14-5979 change,
when pr113208_0.C is compiled where the ctor is marked constexpr,
we no longer perform this optimization, where
_ZN6vectorI12QualityValueEC2ERKS1_ was emitted in the
_ZN6vectorI12QualityValueEC5ERKS1_ comdat group and
_ZN6vectorI12QualityValueEC1ERKS1_ was made an alias to it,
instead we emit _ZN6vectorI12QualityValueEC2ERKS1_ in
_ZN6vectorI12QualityValueEC2ERKS1_ comdat group and the same
content _ZN6vectorI12QualityValueEC1ERKS1_ as separate symbol in
_ZN6vectorI12QualityValueEC1ERKS1_ comdat group.


This seems like an ABI bug that could use a non-LTO testcase.


Now, the linker seems to somehow cope with that, eventhough it
probably keeps both copies of the ctor, but seems LTO can't cope
with that and Honza doesn't know what it should do in that case
(linker decides that the prevailing symbol is
_ZN6vectorI12QualityValueEC2ERKS1_ (from the
_ZN6vectorI12QualityValueEC2ERKS1_ comdat group) and
_ZN6vectorI12QualityValueEC1ERKS1_ alias (from the other TU,
from _ZN6vectorI12QualityValueEC5ERKS1_ comdat group)).

Note, the case where some constructor is marked constexpr in one
TU and not in another one happens pretty often in libstdc++ when
one mixes -std= flags used to compile different compilation units.

The reason the optimization doesn't trigger when the constructor is
constexpr is that expand_or_defer_fn is called in that case much earlier
than when it is not constexpr; in the former case it is called when we
try to constant evaluate that constructor.  But DECL_INTERFACE_KNOWN
is false in that case and comdat_linkage hasn't been called either
(I think it is desirable, because comdat group is stored in the cgraph
node and am not sure it is a good idea to create cgraph nodes for
something that might not be needed later on at all), so maybe_clone_body
clones the bodies, but doesn't make them as aliases.


Hmm, cloning the bodies and then discarding them later seems like more 
extra work than creating the cgraph nodes.


Jason

Re: [PATCH] c++: Copy over DECL_DISREGARD_INLINE_LIMITS flag to inheriting ctors [PR114784]

[Jason Merrill]

On 4/22/24 08:54, Jakub Jelinek wrote:

Hi!

The following testcase is rejected with
error: inlining failed in call to 'always_inline' '...': call is unlikely and 
code size would grow
errors.  The problem is that starting with the r14-2149 change
we try to copy most of the attributes from the inherited to
inheriting ctor, but don't copy associated flags that decl_attributes
sets.

Now, the other clone_attrs user, cp/optimize.cc (maybe_clone_body)
copies over
   DECL_COMDAT (clone) = DECL_COMDAT (fn);
   DECL_WEAK (clone) = DECL_WEAK (fn);
   if (DECL_ONE_ONLY (fn))
 cgraph_node::get_create (clone)->set_comdat_group (cxx_comdat_group 
(clone));
   DECL_USE_TEMPLATE (clone) = DECL_USE_TEMPLATE (fn);
   DECL_EXTERNAL (clone) = DECL_EXTERNAL (fn);
   DECL_INTERFACE_KNOWN (clone) = DECL_INTERFACE_KNOWN (fn);
   DECL_NOT_REALLY_EXTERN (clone) = DECL_NOT_REALLY_EXTERN (fn);
   DECL_VISIBILITY (clone) = DECL_VISIBILITY (fn);
   DECL_VISIBILITY_SPECIFIED (clone) = DECL_VISIBILITY_SPECIFIED (fn);
   DECL_DLLIMPORT_P (clone) = DECL_DLLIMPORT_P (fn);
   DECL_DISREGARD_INLINE_LIMITS (clone) = DECL_DISREGARD_INLINE_LIMITS (fn);
The following patch just copies DECL_DISREGARD_INLINE_LIMITS to fix
this exact bug, not really sure which other flags should be copied
and which shouldn't.
Plus there are tons of other flags, some of which might need to be copied
too, some of which might not, perhaps in both places, like:
DECL_UNINLINABLE, maybe DECL_PRESERVE_P, TREE_USED, maybe
DECL_USER_ALIGN/DECL_ALIGN, maybe DECL_WEAK, maybe
DECL_NO_INSTRUMENT_FUNCTION_ENTRY_EXIT, DECL_NO_LIMIT_STACK.
TREE_READONLY, DECL_PURE_P, TREE_THIS_VOLATILE (for const, pure and
noreturn attributes) probably makes no sense, DECL_IS_RETURNS_TWICE neither
(returns_twice ctor?).  What about TREE_NOTHROW?
DECL_FUNCTION_SPECIFIC_OPTIMIZATION, DECL_FUNCTION_SPECIFIC_TARGET...

Anyway, another problem is that if inherited_ctor is a TEMPLATE_DECL, as
also can be seen in the using D::D; case in the testcase, then
DECL_ATTRIBUTES (fn) = clone_attrs (DECL_ATTRIBUTES (inherited_ctor));
attempts to copy the attributes from the TEMPLATE_DECL which doesn't have
them.  The following patch copies them from STRIP_TEMPLATE (inherited_ctor)
which does.  E.g. DECL_DECLARED_CONSTEXPR_P works fine as the macro
itself uses STRIP_TEMPLATE too, but not 100% sure about other macros used
on inherited_ctor earlier.

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


OK.


Do you want to copy other flags (and which ones and in which places),
is that ok to be deferred till stage 1?


Most of the others don't seem like they should be copied, but rather 
determined from the function body as usual.  Maybe 
DECL_FUNCTION_SPECIFIC_TARGET would make sense.  Either way, it can wait 
for stage 1.



2024-04-22  Jakub Jelinek  

PR c++/114784
* method.cc (implicitly_declare_fn): Call clone_attrs
on DECL_ATTRIBUTES on STRIP_TEMPLATE (inherited_ctor) rather than
inherited_ctor.  Also copy DECL_DISREGARD_INLINE_LIMITS flag from it.

* g++.dg/cpp0x/inh-ctor39.C: New test.

--- gcc/cp/method.cc.jj 2024-04-20 00:02:56.702387748 +0200
+++ gcc/cp/method.cc2024-04-22 12:51:36.395722484 +0200
@@ -3307,8 +3307,11 @@ implicitly_declare_fn (special_function_
/* Copy constexpr from the inherited constructor even if the
 inheriting constructor doesn't satisfy the requirements.  */
constexpr_p = DECL_DECLARED_CONSTEXPR_P (inherited_ctor);
+  tree inherited_ctor_fn = STRIP_TEMPLATE (inherited_ctor);
/* Also copy any attributes.  */
-  DECL_ATTRIBUTES (fn) = clone_attrs (DECL_ATTRIBUTES (inherited_ctor));
+  DECL_ATTRIBUTES (fn) = clone_attrs (DECL_ATTRIBUTES (inherited_ctor_fn));
+  DECL_DISREGARD_INLINE_LIMITS (fn)
+   = DECL_DISREGARD_INLINE_LIMITS (inherited_ctor_fn);
  }
  
/* Add the "this" parameter.  */

--- gcc/testsuite/g++.dg/cpp0x/inh-ctor39.C.jj  2024-04-22 13:02:10.490836357 
+0200
+++ gcc/testsuite/g++.dg/cpp0x/inh-ctor39.C 2024-04-22 13:01:50.088122255 
+0200
@@ -0,0 +1,55 @@
+// PR c++/114784
+// { dg-do compile { target c++11 } }
+// { dg-additional-options "-O2" }
+
+template 
+struct A {
+  [[gnu::always_inline]] A (int t) { foo ().bar (t, {}); }
+  [[gnu::always_inline]] A (long long t) { foo ().bar (t, {}); }
+  T foo ();
+};
+
+struct B : A {
+  using A::A;
+  [[gnu::always_inline]] B (long long v) : A (v) {}
+  template 
+  void bar (T &&, int);
+  char b;
+};
+
+struct C {
+  C (int v) : a(v) { }
+  C (long long v) : a(v) { }
+  B a;
+};
+
+static C
+baz ()
+{
+  C x(0);
+  C y(0LL);
+  return 0;
+}
+
+[[gnu::cold]] int
+qux ()
+{
+  baz ();
+  return 0;
+}
+
+template 
+struct D {
+  template 
+  [[gnu::always_inline]] D (T) { d = sizeof (T); }
+  D();
+  int d;
+};
+template 
+struct E : D {
+  using D::D;
+};
+
+E c = {};
+E d = 1;
+E e = 1.0;

Jakub

Re: [PATCH] c++: constexpr union member access folding [PR114709]

[Jason Merrill]

On 4/22/24 15:18, Patrick Palka wrote:

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


OK with a rationale comment.


-- >8 --

The object/offset canonicalization performed in cxx_fold_indirect_ref
is undesirable for union member accesses because it loses information
about the member being accessed which we may later need to diagnose an
inactive-member access.  So this patch restricts the canonicalization
accordingly.

PR c++/114709

gcc/cp/ChangeLog:

* constexpr.cc (cxx_fold_indirect_ref): Restrict object/offset
canonicalization to RECORD_TYPE member accesses.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-union8.C: New test.
---
  gcc/cp/constexpr.cc   | 1 +
  gcc/testsuite/g++.dg/cpp0x/constexpr-union8.C | 8 
  2 files changed, 9 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-union8.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index fcc847d85df..941a478e889 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -5797,6 +5797,7 @@ cxx_fold_indirect_ref (const constexpr_ctx *ctx, 
location_t loc, tree type,
   more folding opportunities.  */
auto canonicalize_obj_off = [] (tree& obj, tree& off) {
  while (TREE_CODE (obj) == COMPONENT_REF
+  && TREE_CODE (TREE_TYPE (TREE_OPERAND (obj, 0))) == RECORD_TYPE
   && (tree_int_cst_sign_bit (off) || integer_zerop (off)))
{
tree field = TREE_OPERAND (obj, 1);
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-union8.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-union8.C
new file mode 100644
index 000..34c264944b6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-union8.C
@@ -0,0 +1,8 @@
+// PR c++/114709
+// { dg-do compile { target c++11 } }
+
+struct T1 { int a, b; };
+struct T2 { int c; double d; };
+union U { T1 t1; T2 t2; };
+
+constexpr int v = U{{1,2}}.t2.*&T2::c; // { dg-error "accessing 'U::t2'" }

Re: [PATCH v4 1/2] LoongArch: Define ISA versions

[Yang Yujie]

v1 -> v2: 
- Fixed build issues of runtime libraries caused by the new header.
- Restored the default ARCH of lp64f/lp64s ABI to "abi-default".

v2 -> v3:
- Fixed libobjc build.
- Modify "LoongArch v1.1 features" to "LoongArch v1.1 instructions"
in invoke.texi.

v3 -> v4:
- Do not define __loongarch_version_* when LASX is enabled.
- Fixed the condition to define builtin macros for evolution features.

[PATCH v4 1/2] LoongArch: Define ISA versions

[Yang Yujie]

These ISA versions are defined as -march= parameters and
are recommended for building binaries for distribution.

Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.

gcc/ChangeLog:

* config.gcc: Make la64v1.0 the default ISA preset of the lp64d ABI.
* config/loongarch/genopts/loongarch-strings: Define la64v1.0, la64v1.1.
* config/loongarch/genopts/loongarch.opt.in: Likewise.
* config/loongarch/loongarch-c.cc (LARCH_CPP_SET_PROCESSOR): Likewise.
(loongarch_cpu_cpp_builtins): Likewise.
* config/loongarch/loongarch-cpu.cc (get_native_prid): Likewise.
(fill_native_cpu_config): Likewise.
* config/loongarch/loongarch-def.cc (array_tune): Likewise.
* config/loongarch/loongarch-def.h: Likewise.
* config/loongarch/loongarch-driver.cc (driver_set_m_parm): Likewise.
(driver_get_normalized_m_opts): Likewise.
* config/loongarch/loongarch-opts.cc (default_tune_for_arch): Likewise.
(TUNE_FOR_ARCH): Likewise.
(arch_str): Likewise.
(loongarch_target_option_override): Likewise.
* config/loongarch/loongarch-opts.h (TARGET_uARCH_LA464): Likewise.
(TARGET_uARCH_LA664): Likewise.
* config/loongarch/loongarch-str.h (STR_CPU_ABI_DEFAULT): Likewise.
(STR_ARCH_ABI_DEFAULT): Likewise.
(STR_TUNE_GENERIC): Likewise.
(STR_ARCH_LA64V1_0): Likewise.
(STR_ARCH_LA64V1_1): Likewise.
* config/loongarch/loongarch.cc 
(loongarch_cpu_sched_reassociation_width): Likewise.
(loongarch_asm_code_end): Likewise.
* config/loongarch/loongarch.opt: Likewise.
* doc/invoke.texi: Likewise.
---
 gcc/config.gcc| 34 
 .../loongarch/genopts/loongarch-strings   |  5 +-
 gcc/config/loongarch/genopts/loongarch.opt.in | 43 --
 gcc/config/loongarch/loongarch-c.cc   | 37 +++--
 gcc/config/loongarch/loongarch-cpu.cc | 35 
 gcc/config/loongarch/loongarch-def.cc | 83 +--
 gcc/config/loongarch/loongarch-def.h  | 37 ++---
 gcc/config/loongarch/loongarch-driver.cc  |  8 +-
 gcc/config/loongarch/loongarch-opts.cc| 66 +++
 gcc/config/loongarch/loongarch-opts.h |  4 +-
 gcc/config/loongarch/loongarch-str.h  |  5 +-
 gcc/config/loongarch/loongarch.cc | 11 +--
 gcc/config/loongarch/loongarch.opt| 43 --
 gcc/doc/invoke.texi   | 57 -
 14 files changed, 300 insertions(+), 168 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 5df3c52f8e9..929695c25ab 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -5072,7 +5072,7 @@ case "${target}" in
 
# Perform initial sanity checks on --with-* options.
case ${with_arch} in
-   "" | abi-default | loongarch64 | la[46]64) ;; # OK, append here.
+   "" | la64v1.[01] | abi-default | loongarch64 | la[46]64) ;; # 
OK, append here.
native)
if test x${host} != x${target}; then
echo "--with-arch=native is illegal for 
cross-compiler." 1>&2
@@ -5119,10 +5119,18 @@ case "${target}" in
 
# Infer ISA-related default options from the ABI: pass 1
case ${abi_base}/${abi_ext} in
-   lp64*/base)
+   lp64d/base)
# architectures that support lp64* ABI
-   arch_pattern="native|abi-default|loongarch64|la[46]64"
-   # default architecture for lp64* ABI
+   
arch_pattern="native|abi-default|la64v1.[01]|loongarch64|la[46]64"
+
+   # default architecture for lp64d ABI
+   arch_default="la64v1.0"
+   ;;
+   lp64[fs]/base)
+   # architectures that support lp64* ABI
+   
arch_pattern="native|abi-default|la64v1.[01]|loongarch64|la[46]64"
+
+   # default architecture for lp64[fs] ABI
arch_default="abi-default"
;;
*)
@@ -5194,15 +5202,7 @@ case "${target}" in
 
 
# Check default with_tune configuration using with_arch.
-   case ${with_arch} in
-   loongarch64)
-   tune_pattern="native|abi-default|loongarch64|la[46]64"
-   ;;
-   *)
-   # By default, $with_tune == $with_arch
-   tune_pattern="*"
-   ;;
-   esac
+   tune_pattern="native|generic|loongarch64|la[46]64"
 
case ${with_tune} in
"") ;; # OK
@@ -5252,7 +5252,7 @@ case "${target}" in
   

[PATCH v4 2/2] LoongArch: Define builtin macros for ISA evolutions

[Yang Yujie]

Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.

gcc/ChangeLog:

* config.gcc: Add loongarch-evolution.o.
* config/loongarch/genopts/genstr.sh: Enable generation of
loongarch-evolution.[cc,h].
* config/loongarch/t-loongarch: Likewise.
* config/loongarch/genopts/gen-evolution.awk: New file.
* config/loongarch/genopts/isa-evolution.in: Mark ISA version
of introduction for each ISA evolution feature.
* config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins):
Define builtin macros for enabled ISA evolutions and the ISA
version.
* config/loongarch/loongarch-cpu.cc: Use loongarch-evolution.h.
* config/loongarch/loongarch.h: Likewise.
* config/loongarch/loongarch-cpucfg-map.h: Delete.
* config/loongarch/loongarch-evolution.cc: New file.
* config/loongarch/loongarch-evolution.h: New file.
* config/loongarch/loongarch-opts.h (ISA_HAS_FRECIPE): Define.
(ISA_HAS_DIV32): Likewise.
(ISA_HAS_LAM_BH): Likewise.
(ISA_HAS_LAMCAS): Likewise.
(ISA_HAS_LD_SEQ_SA): Likewise.
---
 gcc/config.gcc|   2 +-
 .../loongarch/genopts/gen-evolution.awk   | 230 ++
 gcc/config/loongarch/genopts/genstr.sh|  82 ++-
 gcc/config/loongarch/genopts/isa-evolution.in |  10 +-
 gcc/config/loongarch/loongarch-c.cc   |  23 ++
 gcc/config/loongarch/loongarch-cpu.cc |   2 +-
 gcc/config/loongarch/loongarch-evolution.cc   |  60 +
 ...rch-cpucfg-map.h => loongarch-evolution.h} |  46 +++-
 gcc/config/loongarch/loongarch-opts.h |  11 -
 gcc/config/loongarch/loongarch.h  |   1 +
 gcc/config/loongarch/t-loongarch  |  26 +-
 11 files changed, 398 insertions(+), 95 deletions(-)
 create mode 100644 gcc/config/loongarch/genopts/gen-evolution.awk
 create mode 100644 gcc/config/loongarch/loongarch-evolution.cc
 rename gcc/config/loongarch/{loongarch-cpucfg-map.h => loongarch-evolution.h} 
(52%)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 929695c25ab..3364fc27524 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -485,7 +485,7 @@ 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_objs="loongarch-c.o loongarch-builtins.o loongarch-cpu.o 
loongarch-opts.o loongarch-def.o loongarch-evolution.o"
extra_gcc_objs="loongarch-driver.o loongarch-cpu.o loongarch-opts.o 
loongarch-def.o"
extra_options="${extra_options} g.opt fused-madd.opt"
;;
diff --git a/gcc/config/loongarch/genopts/gen-evolution.awk 
b/gcc/config/loongarch/genopts/gen-evolution.awk
new file mode 100644
index 000..4d105afa906
--- /dev/null
+++ b/gcc/config/loongarch/genopts/gen-evolution.awk
@@ -0,0 +1,230 @@
+#!/usr/bin/gawk
+#
+# A simple script that generates loongarch-evolution.h
+# from genopts/isa-evolution.in
+#
+# Copyright (C) 2021-2024 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify it under
+# the terms of the GNU General Public License as published by the Free
+# Software Foundation; either version 3, or (at your option) any later
+# version.
+#
+# GCC is distributed in the hope that it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+# or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+# License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+BEGIN {
+# isa_version_major[]
+# isa_version_minor[]
+# cpucfg_word[]
+# cpucfg_bit_in_word[]
+# name_capitalized[]
+# comment[]
+}
+
+{
+cpucfg_word[NR] = $1
+cpucfg_bit_in_word[NR] = $2
+name[NR] = gensub(/-/, "_", "g", $3)
+name_capitalized[NR] = toupper(name[NR])
+isa_version_major[NR] = gensub(/^([1-9][0-9]*)\.([0-9]+)$/, "\\1", 1, $4)
+isa_version_minor[NR] = gensub(/^([1-9][0-9]*)\.([0-9]+)$/, "\\2", 1, $4)
+
+$1 = $2 = $3 = $4 = ""
+sub (/^\s*/, "")
+comment[NR] = $0
+}
+
+function copyright_header(from_year,to_year)
+{
+print "   Copyright (C) " from_year "-" to_year \
+  " Free Software Foundation, Inc."
+print ""
+print "This file is part of GCC."
+print ""
+print "GCC is free software; you can redistribute it and/or modify"
+print "it under the terms of the GNU General Public License as published 
by"
+print "the Free Software Foundation; either version 3, or (at your option)"
+print "any later version."
+print ""
+print "GCC i

RE: [PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d and e65aaf8efe1

[Li, Pan2]

Thanks Patrick.

Turn out that the make report cannot tell the error like below and then the 
graphite.exp test will never run.
That explains why I missed test failures, will take care of it ASAP.

sorry, unimplemented: Graphite loop optimizations cannot be used (isl is not 
available)

Pan

-Original Message-
From: Patrick O'Neill  
Sent: Tuesday, April 23, 2024 8:32 AM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; rdapp@gmail.com
Subject: Re: [PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d 
and e65aaf8efe1

This patch in particular does not cause any more regressions. It's one 
of the other reverts from the weekend.

Before the reverts [1]:
                     |  gcc |  
g++ | gfortran |
     rv64gcv/  lp64d/ medlow |   48/    32 |     12/    3|   12 /    2

After the reverts:
                     |  gcc |  
g++ | gfortran |
     rv64gcv/  lp64d/ medlow |   50 /    33 |   12 / 3 |   26 / 7 |


gcc new fails:
FAIL: gcc.dg/graphite/pr111878.c (internal compiler error: in 
extract_insn, at recog.cc:2812)
FAIL: gcc.dg/graphite/pr111878.c (test for excess errors)

gfortran new fails:
FAIL: gfortran.dg/graphite/id-27.f90   -O  (internal compiler error: in 
extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/id-27.f90   -O  (test for excess errors)
FAIL: gfortran.dg/graphite/pr14741.f90   -O  (internal compiler error: 
in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr14741.f90   -O  (test for excess errors)
FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal 
compiler error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for 
excess errors)
FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -g  (internal compiler 
error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal 
compiler error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for 
excess errors)
FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -g  (internal compiler 
error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/graphite/vect-pr40979.f90   -O  (internal compiler 
error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/vect-pr40979.f90   -O  (test for excess errors)


For future reference, the precommit does not do well with many unrelated 
patches that are dependent on eachother.
In the future sending these as a series would allow precommit to 
properly test them (as always you can see the testing results on 
patchworks).

Thanks,
Patrick

[1] https://github.com/patrick-rivos/gcc-postcommit-ci/issues/801

On 4/22/24 12:55, Patrick O'Neill wrote:
> Hi Pan,
>
> I was running the testsuite for this and noticed an ICE scroll by when 
> this patch is applied to cacc55a4c0be8d0bc7417b6a28924eadbbe428e3 for 
> rv64gcv:
>
> FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -fomit-frame-pointer 
> -funroll-loops -fpeel-loops -ftracer -finline-functions  (internal 
> compiler error: in extract_insn, at recog.cc:2812)
>
> I'll send the full list of new failures once the runs finish.
>
> Thanks,
> Patrick
>
> On 4/22/24 06:47, pan2...@intel.com wrote:
>> From: Pan Li 
>>
>> After we reverted below 2 commits, the reference to attr need some
>> adjustment as the group_overlap is no longer available.
>>
>> * RISC-V: Robostify the W43, W86, W87 constraint enabled attribute
>> * RISC-V: Rename vconstraint into group_overlap
>>
>> The below tests are passed for this patch.
>>
>> * The rv64gcv fully regression tests.
>>
>> gcc/ChangeLog:
>>
>> * config/riscv/vector-crypto.md:
>>
>> Signed-off-by: Pan Li 
>> ---
>>   gcc/config/riscv/vector-crypto.md | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/config/riscv/vector-crypto.md 
>> b/gcc/config/riscv/vector-crypto.md
>> index 519c6a10d94..23dc549e5b8 100755
>> --- a/gcc/config/riscv/vector-crypto.md
>> +++ b/gcc/config/riscv/vector-crypto.md
>> @@ -322,7 +322,7 @@ (define_insn "@pred_vwsll_scalar"
>>     "vwsll.v%o4\t%0,%3,%4%p1"
>>     [(set_attr "type" "vwsll")
>>  (set_attr "mode" "")
>> -   (set_attr "group_overlap" 
>> "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,none,none")])
>> +   (set_attr "vconstraint" 
>> "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,no,no")])
>>     ;; vbrev.v vbrev8.v vrev8.v
>>   (define_insn "@pred_v"

RE: Re: [PATCH v1] RISC-V: Revert RVV wv instructions overlap and xfail tests

[Li, Pan2]

> Sure, reverting something that has a bug is reasonable.  The problem is 
> how this happened: this code clearly did not get tested, as it doesn't 
> even build and re-introduces a bunch of ICEs.  We're very late in stage 
> 4 and this is the second time the entire port has been broken in as many 
> weeks.  That's a really bad time to be breaking things.

Thanks Palmer to point this out. Let me share more details about the process.
The revert is not just a git command like git revert commit-id. Consider below 
scenario.

Day-1: commit-A: rename a attribute.
Day-2: commit-B: other patches reference this renamed attribute but no need to 
revert.

To follow the suggestion of Robin that keeping the revert commit pure, I 
followed below step(s)

1. Revert commit-A locally, and address the reference issue.
2. Run fully test to see if any surprise (take 80-90 mins for 64 cores. Sorry 
again only c/c++ parts, Fortran is missing here).
3. Revert commit-A to upstream (of course it will result in built failure).
4. File patch to address the reference attribute issue.

The other revert almost take similar step(s) but looks some mistake here.
Sorry for that each test result is comparing between code change and upstream, 
and it will be missed after
we moving on.

> Do you guys have a fix for the regressions that showed up over the 
> weekend?

Understand current we are in the sensitive stage, will take care of the 
failures ASAP.

Pan

-Original Message-
From: Palmer Dabbelt  
Sent: Tuesday, April 23, 2024 8:43 AM
To: juzhe.zh...@rivai.ai
Cc: Patrick O'Neill ; Li, Pan2 ; Robin 
Dapp ; gcc-patches@gcc.gnu.org; Kito Cheng 

Subject: Re: Re: [PATCH v1] RISC-V: Revert RVV wv instructions overlap and 
xfail tests

On Mon, 22 Apr 2024 15:07:59 PDT (-0700), juzhe.zh...@rivai.ai wrote:
> Apologize that we didn't post our (me, kito and Li Pan) disscussions.

Some amount of off-list discussion is inevitable, but as far as I can 
tell here we ended up with some code committed that wasn't even posted 
to the lists and didn't even build.  I don't know exactly where the bar 
for public discussions is, but it's got to be somewhere higher than 
that.

> This is the story:
> We found that my previous patches which support highpart register overlap 
> with register filter for instructions like (vwadd.wv)
> cause ICE reported by:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714
> and this is obviously a regression (No ICE on GCC 13.2, but ICE on GCC 14)
> 
> We have tried several fixes to work around this ICE, however, we failed.
> And also I found my previous patches are quite wrong which is not the perfect 
> solution to support register group overlap
> for vwadd.wv. 
> So, finally we decide to revert those patches.

Sure, reverting something that has a bug is reasonable.  The problem is 
how this happened: this code clearly did not get tested, as it doesn't 
even build and re-introduces a bunch of ICEs.  We're very late in stage 
4 and this is the second time the entire port has been broken in as many 
weeks.  That's a really bad time to be breaking things.

I think we're really set the wrong precedent on what the bar is for 
review here.  We had a lot of breakages early on in the 14 development 
cycle and never really dug into that, I was hoping that getting CI set 
up would be a strong enough hint to stop the breakages.  Clearly that 
didn't work, though, so:

Please stop breaking the port.

It's exceedingly rare that any patch needs to be committed minutes after 
it's posted.  These port-wide breakages are really the only thing where 
it could be agreed that's the way to go, but as we can see here rushing 
is as likely to dig a bigger hole as it is to fix things.  I get the 
testsuite can be kind of hard to run, but if you don't want to run it 
locally you can just wait for the CI to do it for you.  That's not 
really asking for very much.

> Kito knows the details of this story, kito can share more details in GNU 
> patche meeting.

Ya, we can talk tomorrow morning.

Do you guys have a fix for the regressions that showed up over the 
weekend?

Either way I'd prefer to go with reverting all this and then taking 
Robin's more self-contained fix.  If you guys want to do a bigger change 
later that's fine, we're just really close to the release and it's not a 
good time to risk breaking things.  We've only had a few days of a 
functioning port over the last week or two, that's already put us behind 
on the distro prerelases/RCs so I'm kind of worried something else has 
slipped in.

> 
> Thanks.
> 
> 
> juzhe.zh...@rivai.ai
>  
> From: Patrick O'Neill
> Date: 2024-04-23 01:20
> To: Li, Pan2; Robin Dapp; gcc-patches@gcc.gnu.org
> CC: juzhe.zh...@rivai.ai; kito.ch...@gmail.com
> Subject: Re: [PATCH v1] RISC-V: Revert RVV wv instructions overlap and xfail 
> tests
> Hi Pan,
> I'm not sure I'm following.  Did we miss something that should have been
> covered?  Like only an overlap on the srcs but not the dest?
> Are there te

Re: Re: [PATCH v1] RISC-V: Revert RVV wv instructions overlap and xfail tests

[Palmer Dabbelt]

On Mon, 22 Apr 2024 15:07:59 PDT (-0700), juzhe.zh...@rivai.ai wrote:

Apologize that we didn't post our (me, kito and Li Pan) disscussions.


Some amount of off-list discussion is inevitable, but as far as I can 
tell here we ended up with some code committed that wasn't even posted 
to the lists and didn't even build.  I don't know exactly where the bar 
for public discussions is, but it's got to be somewhere higher than 
that.



This is the story:
We found that my previous patches which support highpart register overlap with 
register filter for instructions like (vwadd.wv)
cause ICE reported by:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714
and this is obviously a regression (No ICE on GCC 13.2, but ICE on GCC 14)

We have tried several fixes to work around this ICE, however, we failed.
And also I found my previous patches are quite wrong which is not the perfect 
solution to support register group overlap
for vwadd.wv. 
So, finally we decide to revert those patches.


Sure, reverting something that has a bug is reasonable.  The problem is 
how this happened: this code clearly did not get tested, as it doesn't 
even build and re-introduces a bunch of ICEs.  We're very late in stage 
4 and this is the second time the entire port has been broken in as many 
weeks.  That's a really bad time to be breaking things.


I think we're really set the wrong precedent on what the bar is for 
review here.  We had a lot of breakages early on in the 14 development 
cycle and never really dug into that, I was hoping that getting CI set 
up would be a strong enough hint to stop the breakages.  Clearly that 
didn't work, though, so:


Please stop breaking the port.

It's exceedingly rare that any patch needs to be committed minutes after 
it's posted.  These port-wide breakages are really the only thing where 
it could be agreed that's the way to go, but as we can see here rushing 
is as likely to dig a bigger hole as it is to fix things.  I get the 
testsuite can be kind of hard to run, but if you don't want to run it 
locally you can just wait for the CI to do it for you.  That's not 
really asking for very much.



Kito knows the details of this story, kito can share more details in GNU patche 
meeting.


Ya, we can talk tomorrow morning.

Do you guys have a fix for the regressions that showed up over the 
weekend?


Either way I'd prefer to go with reverting all this and then taking 
Robin's more self-contained fix.  If you guys want to do a bigger change 
later that's fine, we're just really close to the release and it's not a 
good time to risk breaking things.  We've only had a few days of a 
functioning port over the last week or two, that's already put us behind 
on the distro prerelases/RCs so I'm kind of worried something else has 
slipped in.




Thanks.


juzhe.zh...@rivai.ai
 
From: Patrick O'Neill

Date: 2024-04-23 01:20
To: Li, Pan2; Robin Dapp; gcc-patches@gcc.gnu.org
CC: juzhe.zh...@rivai.ai; kito.ch...@gmail.com
Subject: Re: [PATCH v1] RISC-V: Revert RVV wv instructions overlap and xfail 
tests
Hi Pan,
I'm not sure I'm following.  Did we miss something that should have been
covered?  Like only an overlap on the srcs but not the dest?
Are there testcases that fail?  If so we should definitely have one.
Can you give some additional information on why these reverts are needed?
+1 to the request for a failing testcase if there is one. Patrick If something 
is broken then indeed we should revert it.
Yes, we may need to support these in gcc-15.
... why not just revert everything and xfail all the tests in a
follow up?  Your patch is essentially a revert but doesn't look like
it.  I'd rather we let a revert be a revert and adjust the tests
separately so it becomes clear.
Sure, will revert b3b2799b872 and then file the patch for the xfail tests.
Pan

Re: [PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d and e65aaf8efe1

[Patrick O'Neill]

This patch in particular does not cause any more regressions. It's one 
of the other reverts from the weekend.


Before the reverts [1]:
                    |  gcc |  
g++ | gfortran |

    rv64gcv/  lp64d/ medlow |   48/    32 |     12/    3|   12 /    2

After the reverts:
                    |  gcc |  
g++ | gfortran |

    rv64gcv/  lp64d/ medlow |   50 /    33 |   12 / 3 |   26 / 7 |


gcc new fails:
FAIL: gcc.dg/graphite/pr111878.c (internal compiler error: in 
extract_insn, at recog.cc:2812)

FAIL: gcc.dg/graphite/pr111878.c (test for excess errors)

gfortran new fails:
FAIL: gfortran.dg/graphite/id-27.f90   -O  (internal compiler error: in 
extract_insn, at recog.cc:2812)

FAIL: gfortran.dg/graphite/id-27.f90   -O  (test for excess errors)
FAIL: gfortran.dg/graphite/pr14741.f90   -O  (internal compiler error: 
in extract_insn, at recog.cc:2812)

FAIL: gfortran.dg/graphite/pr14741.f90   -O  (test for excess errors)
FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal 
compiler error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for 
excess errors)
FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -g  (internal compiler 
error: in extract_insn, at recog.cc:2812)

FAIL: gfortran.dg/graphite/pr29581.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal 
compiler error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for 
excess errors)
FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -g  (internal compiler 
error: in extract_insn, at recog.cc:2812)

FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/graphite/vect-pr40979.f90   -O  (internal compiler 
error: in extract_insn, at recog.cc:2812)

FAIL: gfortran.dg/graphite/vect-pr40979.f90   -O  (test for excess errors)


For future reference, the precommit does not do well with many unrelated 
patches that are dependent on eachother.
In the future sending these as a series would allow precommit to 
properly test them (as always you can see the testing results on 
patchworks).


Thanks,
Patrick

[1] https://github.com/patrick-rivos/gcc-postcommit-ci/issues/801

On 4/22/24 12:55, Patrick O'Neill wrote:

Hi Pan,

I was running the testsuite for this and noticed an ICE scroll by when 
this patch is applied to cacc55a4c0be8d0bc7417b6a28924eadbbe428e3 for 
rv64gcv:


FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal 
compiler error: in extract_insn, at recog.cc:2812)


I'll send the full list of new failures once the runs finish.

Thanks,
Patrick

On 4/22/24 06:47, pan2...@intel.com wrote:

From: Pan Li 

After we reverted below 2 commits, the reference to attr need some
adjustment as the group_overlap is no longer available.

* RISC-V: Robostify the W43, W86, W87 constraint enabled attribute
* RISC-V: Rename vconstraint into group_overlap

The below tests are passed for this patch.

* The rv64gcv fully regression tests.

gcc/ChangeLog:

* config/riscv/vector-crypto.md:

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

diff --git a/gcc/config/riscv/vector-crypto.md 
b/gcc/config/riscv/vector-crypto.md

index 519c6a10d94..23dc549e5b8 100755
--- a/gcc/config/riscv/vector-crypto.md
+++ b/gcc/config/riscv/vector-crypto.md
@@ -322,7 +322,7 @@ (define_insn "@pred_vwsll_scalar"
    "vwsll.v%o4\t%0,%3,%4%p1"
    [(set_attr "type" "vwsll")
 (set_attr "mode" "")
-   (set_attr "group_overlap" 
"W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,none,none")])
+   (set_attr "vconstraint" 
"W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,no,no")])

    ;; vbrev.v vbrev8.v vrev8.v
  (define_insn "@pred_v"

RE: Re: [PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d and e65aaf8efe1

[Li, Pan2]

Sure thing. Sorry for that Fortran is not fully tested for this change, will 
take a look into it ASAP.

Pan

From: 钟居哲 
Sent: Tuesday, April 23, 2024 6:06 AM
To: patrick ; Li, Pan2 ; gcc-patches 

Cc: kito.cheng ; rdapp.gcc 
Subject: Re: Re: [PATCH v1] RISC-V: Adjust overlap attr after revert 
d3544cea63d and e65aaf8efe1

I think the revert patch exposes latent bug, Li Pan will look into it.


juzhe.zh...@rivai.ai

From: Patrick O'Neill
Date: 2024-04-23 03:55
To: pan2.li; 
gcc-patches
CC: juzhe.zhong; 
kito.cheng; rdapp.gcc
Subject: Re: [PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d 
and e65aaf8efe1
Hi Pan,

I was running the testsuite for this and noticed an ICE scroll by when
this patch is applied to cacc55a4c0be8d0bc7417b6a28924eadbbe428e3 for
rv64gcv:

FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal
compiler error: in extract_insn, at recog.cc:2812)

I'll send the full list of new failures once the runs finish.

Thanks,
Patrick

On 4/22/24 06:47, pan2...@intel.com wrote:
> From: Pan Li mailto:pan2...@intel.com>>
>
> After we reverted below 2 commits, the reference to attr need some
> adjustment as the group_overlap is no longer available.
>
> * RISC-V: Robostify the W43, W86, W87 constraint enabled attribute
> * RISC-V: Rename vconstraint into group_overlap
>
> The below tests are passed for this patch.
>
> * The rv64gcv fully regression tests.
>
> gcc/ChangeLog:
>
> * config/riscv/vector-crypto.md:
>
> Signed-off-by: Pan Li mailto:pan2...@intel.com>>
> ---
>   gcc/config/riscv/vector-crypto.md | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/riscv/vector-crypto.md 
> b/gcc/config/riscv/vector-crypto.md
> index 519c6a10d94..23dc549e5b8 100755
> --- a/gcc/config/riscv/vector-crypto.md
> +++ b/gcc/config/riscv/vector-crypto.md
> @@ -322,7 +322,7 @@ (define_insn "@pred_vwsll_scalar"
> "vwsll.v%o4\t%0,%3,%4%p1"
> [(set_attr "type" "vwsll")
>  (set_attr "mode" "")
> -   (set_attr "group_overlap" 
> "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,none,none")])
> +   (set_attr "vconstraint" 
> "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,no,no")])
>
>   ;; vbrev.v vbrev8.v vrev8.v
>   (define_insn "@pred_v"

[PATCH] c++: constexpr union member access folding [PR114709]

[Patrick Palka]

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

-- >8 --

The object/offset canonicalization performed in cxx_fold_indirect_ref
is undesirable for union member accesses because it loses information
about the member being accessed which we may later need to diagnose an
inactive-member access.  So this patch restricts the canonicalization
accordingly.

PR c++/114709

gcc/cp/ChangeLog:

* constexpr.cc (cxx_fold_indirect_ref): Restrict object/offset
canonicalization to RECORD_TYPE member accesses.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-union8.C: New test.
---
 gcc/cp/constexpr.cc   | 1 +
 gcc/testsuite/g++.dg/cpp0x/constexpr-union8.C | 8 
 2 files changed, 9 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-union8.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index fcc847d85df..941a478e889 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -5797,6 +5797,7 @@ cxx_fold_indirect_ref (const constexpr_ctx *ctx, 
location_t loc, tree type,
  more folding opportunities.  */
   auto canonicalize_obj_off = [] (tree& obj, tree& off) {
 while (TREE_CODE (obj) == COMPONENT_REF
+  && TREE_CODE (TREE_TYPE (TREE_OPERAND (obj, 0))) == RECORD_TYPE
   && (tree_int_cst_sign_bit (off) || integer_zerop (off)))
   {
tree field = TREE_OPERAND (obj, 1);
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-union8.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-union8.C
new file mode 100644
index 000..34c264944b6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-union8.C
@@ -0,0 +1,8 @@
+// PR c++/114709
+// { dg-do compile { target c++11 } }
+
+struct T1 { int a, b; };
+struct T2 { int c; double d; };
+union U { T1 t1; T2 t2; };
+
+constexpr int v = U{{1,2}}.t2.*&T2::c; // { dg-error "accessing 'U::t2'" }
-- 
2.45.0.rc0

Re: [PATCH] Spelling fixes for translatable strings

[Palmer Dabbelt]

On Mon, 22 Apr 2024 14:30:21 PDT (-0700), ja...@redhat.com wrote:

Hi!

I've run aspell on gcc.pot (just quickly skimming, so pressing
I key hundreds of times and just stopping when I catch something that
looks like a misspelling).

I plan to commit this tomorrow as obvious unless somebody finds some
issues in it, you know, I'm not a native English speaker.
Yes, I know favour is valid UK spelling, but we spell the US way I think.
I've left some *ise* -> *ize* cases (recognise, initialise), those
had too many hits, though in translatable strings just 4, so maybe
worth changing too:
msgid "recognise the specified suffix as a definition module filename"
msgid "recognise the specified suffix as implementation and module filenames"
"initialiser for a dylib."
msgid "%qE attribute argument %qE is not recognised"

2024-04-22  Jakub Jelinek  

* config/epiphany/epiphany.opt (may-round-for-trunc): Spelling fix:
floatig -> floating.
* config/riscv/riscv.opt (mcsr-check): Spelling fix: CRS -> CSR.
* params.opt (-param=ipa-cp-profile-count-base=): Spelling fix:
frequncy -> frequency.
gcc/c-family/
* c.opt (Wstrict-flex-arrays): Spelling fix: inproper -> improper.
gcc/cp/
* parser.cc (cp_parser_using_declaration): Spelling fix: favour
-> favor.
gcc/m2/
* lang.opt (fuse-list=): Spelling fix: finalializations ->
finalizations.

--- gcc/config/epiphany/epiphany.opt.jj 2024-01-03 11:51:47.489509710 +0100
+++ gcc/config/epiphany/epiphany.opt2024-04-22 22:53:56.581549745 +0200
@@ -105,7 +105,7 @@ Enum(attr_fp_mode) String(int) Value(FP_

 may-round-for-trunc
 Target Mask(MAY_ROUND_FOR_TRUNC)
-A floatig point to integer truncation may be replaced with rounding to save 
mode switching.
+A floating point to integer truncation may be replaced with rounding to save 
mode switching.

 mvect-double
 Target Mask(VECT_DOUBLE)
--- gcc/config/riscv/riscv.opt.jj   2024-04-09 08:12:29.379449739 +0200
+++ gcc/config/riscv/riscv.opt  2024-04-22 22:52:06.780080712 +0200
@@ -152,7 +152,7 @@ required to materialize symbol addresses

 mcsr-check
 Target Var(riscv_mcsr_check) Init(0)
-Enable the CSR checking for the ISA-dependent CRS and the read-only CSR.
+Enable the CSR checking for the ISA-dependent CSR and the read-only CSR.
 The ISA-dependent CSR are only valid when the specific ISA is set.  The
 read-only CSR can not be written by the CSR instructions.


This came up on IRC.

Acked-by: Palmer Dabbelt 
Reviewed-by: Palmer Dabbelt 

In case you want to merge it with the rest of thus, but I think it 
should be something more like


   mcsr-check
   Target Var(riscv_mcsr_check) Init(0)
   Turn on (or off) stricter checking for CSR accesses.  With CSR 
   checking enabled a warning will be raised when a CSR access that is 
   not allowed by the currently enabled ISA is performed.  Checks 
   include writing a read-only CSR, and accessing a CSR that requires a 
   currently disabled base ISA or extension.  CSR checking is performed 
   at assembler-time, see the assembler documentation for more 
   information.


I can send that along later if you merge this, no big deal either way on 
my end.  Looks like the binutils docs are the same, so we should updote 
those as well...


Thanks!


--- gcc/cp/parser.cc.jj 2024-04-22 18:12:35.326282135 +0200
+++ gcc/cp/parser.cc2024-04-22 23:14:11.928605442 +0200
@@ -22431,7 +22431,7 @@ cp_parser_using_declaration (cp_parser*
   if (access_declaration_p && errorcount == oldcount)
 warning_at (diag_token->location, OPT_Wdeprecated,
"access declarations are deprecated "
-   "in favour of using-declarations; "
+   "in favor of using-declarations; "
"suggestion: add the % keyword");

   return true;
--- gcc/m2/lang.opt.jj  2024-04-03 09:58:33.538770735 +0200
+++ gcc/m2/lang.opt 2024-04-22 22:47:59.120533842 +0200
@@ -260,7 +260,7 @@ optimize non var unbounded parameters by

 fuse-list=
 Modula-2 Joined
-orders the initialization/finalializations for scaffold-static or force 
linking of modules if scaffold-dynamic
+orders the initialization/finalizations for scaffold-static or force linking 
of modules if scaffold-dynamic

 fversion
 Modula-2
--- gcc/c-family/c.opt.jj   2024-04-15 10:16:58.571245875 +0200
+++ gcc/c-family/c.opt  2024-04-22 22:41:48.188705755 +0200
@@ -1320,7 +1320,7 @@ C ObjC C++ ObjC++ LangEnabledBy(C ObjC C

 Wstrict-flex-arrays
 C C++ Var(warn_strict_flex_arrays) Warning
-Warn about inproper usages of flexible array members
+Warn about improper usages of flexible array members
 according to the level of -fstrict-flex-arrays.

 Wstrict-null-sentinel
--- gcc/params.opt.jj   2024-01-03 11:51:22.563855655 +0100
+++ gcc/params.opt  2024-04-22 23:06:47.466804309 +0200
@@ -263,7 +263,7 @@ Maximum size of a list of values associa

 -param=ipa-cp-profile-count-base=
 Common Joined UInteger Var(param_ipa_cp_profile_count_base) Init(10) 
Integ

Re: Re: [PATCH v1] RISC-V: Revert RVV wv instructions overlap and xfail tests

[钟居哲]

Apologize that we didn't post our (me, kito and Li Pan) disscussions.

This is the story:
We found that my previous patches which support highpart register overlap with 
register filter for instructions like (vwadd.wv)
cause ICE reported by:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714
and this is obviously a regression (No ICE on GCC 13.2, but ICE on GCC 14)

We have tried several fixes to work around this ICE, however, we failed.
And also I found my previous patches are quite wrong which is not the perfect 
solution to support register group overlap
for vwadd.wv. 
So, finally we decide to revert those patches.

Kito knows the details of this story, kito can share more details in GNU patche 
meeting.

Thanks.


juzhe.zh...@rivai.ai
 
From: Patrick O'Neill
Date: 2024-04-23 01:20
To: Li, Pan2; Robin Dapp; gcc-patches@gcc.gnu.org
CC: juzhe.zh...@rivai.ai; kito.ch...@gmail.com
Subject: Re: [PATCH v1] RISC-V: Revert RVV wv instructions overlap and xfail 
tests
Hi Pan,
I'm not sure I'm following.  Did we miss something that should have been
covered?  Like only an overlap on the srcs but not the dest?
Are there testcases that fail?  If so we should definitely have one.
Can you give some additional information on why these reverts are needed?
+1 to the request for a failing testcase if there is one. Patrick If something 
is broken then indeed we should revert it.
Yes, we may need to support these in gcc-15.
... why not just revert everything and xfail all the tests in a
follow up?  Your patch is essentially a revert but doesn't look like
it.  I'd rather we let a revert be a revert and adjust the tests
separately so it becomes clear.
Sure, will revert b3b2799b872 and then file the patch for the xfail tests.
Pan

Re: Re: [PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d and e65aaf8efe1

[钟居哲]

I think the revert patch exposes latent bug, Li Pan will look into it.



juzhe.zh...@rivai.ai
 
From: Patrick O'Neill
Date: 2024-04-23 03:55
To: pan2.li; gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc
Subject: Re: [PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d 
and e65aaf8efe1
Hi Pan,
 
I was running the testsuite for this and noticed an ICE scroll by when 
this patch is applied to cacc55a4c0be8d0bc7417b6a28924eadbbe428e3 for 
rv64gcv:
 
FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal 
compiler error: in extract_insn, at recog.cc:2812)
 
I'll send the full list of new failures once the runs finish.
 
Thanks,
Patrick
 
On 4/22/24 06:47, pan2...@intel.com wrote:
> From: Pan Li 
>
> After we reverted below 2 commits, the reference to attr need some
> adjustment as the group_overlap is no longer available.
>
> * RISC-V: Robostify the W43, W86, W87 constraint enabled attribute
> * RISC-V: Rename vconstraint into group_overlap
>
> The below tests are passed for this patch.
>
> * The rv64gcv fully regression tests.
>
> gcc/ChangeLog:
>
> * config/riscv/vector-crypto.md:
>
> Signed-off-by: Pan Li 
> ---
>   gcc/config/riscv/vector-crypto.md | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/riscv/vector-crypto.md 
> b/gcc/config/riscv/vector-crypto.md
> index 519c6a10d94..23dc549e5b8 100755
> --- a/gcc/config/riscv/vector-crypto.md
> +++ b/gcc/config/riscv/vector-crypto.md
> @@ -322,7 +322,7 @@ (define_insn "@pred_vwsll_scalar"
> "vwsll.v%o4\t%0,%3,%4%p1"
> [(set_attr "type" "vwsll")
>  (set_attr "mode" "")
> -   (set_attr "group_overlap" 
> "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,none,none")])
> +   (set_attr "vconstraint" 
> "W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,no,no")])
>   
>   ;; vbrev.v vbrev8.v vrev8.v
>   (define_insn "@pred_v"
 

Re: [PATCH v9 1/5] Provide counted_by attribute to flexible array member field (PR108896)

[Qing Zhao]

Thanks a lot.

Qing

> On Apr 22, 2024, at 16:38, Joseph Myers  wrote:
> 
> This version of patch 1/5 is OK for GCC 15.
> 
> -- 
> Joseph S. Myers
> josmy...@redhat.com
> 

[PATCH] libstdc++: Implement ranges::concat_view from P2542R7

[Patrick Palka]

Tested on x86_64-pc-linux-gnu, does this look OK for trunk?  More tests
are needed but I figured I'd submit this now for possible consideration into
GCC 14 since we're getting close to release..  All changes are confined to
C++26.

-- >8 --

libstdc++-v3/ChangeLog:

* include/bits/version.def (ranges_concat): Define.
* include/bits/version.h: Regenerate.
* include/std/ranges (__detail::__concat_reference_t): Define
for C++26.
(__detail::__concat_value_t): Likewise.
(__detail::__concat_rvalue_reference_t): Likewise.
(__detail::__concat_indirectly_readable_impl): Likewise.
(__detail::__concat_indirectly_readable): Likewise.
(__detail::__concatable): Likewise.
(__detail::__all_but_last_common): Likewise.
(__detail::__concat_is_random_access): Likewise.
(__detail::__concat_is_bidirectional): Likewise.
(__detail::__last_is_common): Likewise.
(concat_view): Likewise.
(__detail::__concat_view_iter_cat): Likewise.
(concat_view::iterator): Likewise.
(views::__detail::__can_concat_view): Likewise.
(views::_Concat, views::concat): Likewise.
* testsuite/std/ranges/concat/1.cc: New test.
---
 libstdc++-v3/include/bits/version.def |   8 +
 libstdc++-v3/include/bits/version.h   |  10 +
 libstdc++-v3/include/std/ranges   | 584 ++
 libstdc++-v3/testsuite/std/ranges/concat/1.cc |  61 ++
 4 files changed, 663 insertions(+)
 create mode 100644 libstdc++-v3/testsuite/std/ranges/concat/1.cc

diff --git a/libstdc++-v3/include/bits/version.def 
b/libstdc++-v3/include/bits/version.def
index 5c0477fb61e..af13090c094 100644
--- a/libstdc++-v3/include/bits/version.def
+++ b/libstdc++-v3/include/bits/version.def
@@ -1796,6 +1796,14 @@ ftms = {
   };
 };
 
+ftms = {
+  name = ranges_concat;
+  values = {
+v = 202403;
+cxxmin = 26;
+  };
+};
+
 // Standard test specifications.
 stds[97] = ">= 199711L";
 stds[03] = ">= 199711L";
diff --git a/libstdc++-v3/include/bits/version.h 
b/libstdc++-v3/include/bits/version.h
index 65e708c73fb..1f27bfe050d 100644
--- a/libstdc++-v3/include/bits/version.h
+++ b/libstdc++-v3/include/bits/version.h
@@ -2003,4 +2003,14 @@
 #endif /* !defined(__cpp_lib_to_string) && defined(__glibcxx_want_to_string) */
 #undef __glibcxx_want_to_string
 
+#if !defined(__cpp_lib_ranges_concat)
+# if (__cplusplus >  202302L)
+#  define __glibcxx_ranges_concat 202403L
+#  if defined(__glibcxx_want_all) || defined(__glibcxx_want_ranges_concat)
+#   define __cpp_lib_ranges_concat 202403L
+#  endif
+# endif
+#endif /* !defined(__cpp_lib_ranges_concat) && 
defined(__glibcxx_want_ranges_concat) */
+#undef __glibcxx_want_ranges_concat
+
 #undef __glibcxx_want_all
diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index afce818376b..28a39bf6f34 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -55,6 +55,7 @@
 #define __glibcxx_want_ranges_as_const
 #define __glibcxx_want_ranges_as_rvalue
 #define __glibcxx_want_ranges_cartesian_product
+#define __glibcxx_want_ranges_concat
 #define __glibcxx_want_ranges_chunk
 #define __glibcxx_want_ranges_chunk_by
 #define __glibcxx_want_ranges_enumerate
@@ -9514,6 +9515,589 @@ namespace __detail
 } // namespace ranges
 #endif // __cpp_lib_ranges_to_container
 
+#if __cpp_lib_ranges_concat // C++ >= C++26
+namespace ranges
+{
+  namespace __detail
+  {
+template
+  using __concat_reference_t = 
common_reference_t...>;
+
+template
+  using __concat_value_t = common_type_t...>;
+
+template
+  using __concat_rvalue_reference_t
+   = common_reference_t...>;
+
+template
+  concept __concat_indirectly_readable_impl = requires (const _It __it) {
+   { *__it } -> convertible_to<_Ref>;
+   { ranges::iter_move(__it) } -> convertible_to<_RRef>;
+  };
+
+template
+  concept __concat_indirectly_readable
+   = common_reference_with<__concat_reference_t<_Rs...>&&, 
__concat_value_t<_Rs...>&>
+ && common_reference_with<__concat_reference_t<_Rs...>&&,
+  __concat_rvalue_reference_t<_Rs...>&&>
+ && common_reference_with<__concat_rvalue_reference_t<_Rs...>&&,
+  __concat_value_t<_Rs...> const&>
+ && (__concat_indirectly_readable_impl<__concat_reference_t<_Rs...>,
+   
__concat_rvalue_reference_t<_Rs...>,
+   iterator_t<_Rs>>
+ && ...);
+
+template
+  concept __concatable = requires {
+   typename __concat_reference_t<_Rs...>;
+   typename __concat_value_t<_Rs...>;
+   typename __concat_rvalue_reference_t<_Rs...>;
+  } && __concat_indirectly_readable<_Rs...>;
+
+template
+  struct __all_but_last_common
+  {
+   static inline constexpr bool value
+ = requires { re

[PATCH] Spelling fixes for translatable strings

[Jakub Jelinek]

Hi!

I've run aspell on gcc.pot (just quickly skimming, so pressing
I key hundreds of times and just stopping when I catch something that
looks like a misspelling).

I plan to commit this tomorrow as obvious unless somebody finds some
issues in it, you know, I'm not a native English speaker.
Yes, I know favour is valid UK spelling, but we spell the US way I think.
I've left some *ise* -> *ize* cases (recognise, initialise), those
had too many hits, though in translatable strings just 4, so maybe
worth changing too:
msgid "recognise the specified suffix as a definition module filename"
msgid "recognise the specified suffix as implementation and module filenames"
"initialiser for a dylib."
msgid "%qE attribute argument %qE is not recognised"

2024-04-22  Jakub Jelinek  

* config/epiphany/epiphany.opt (may-round-for-trunc): Spelling fix:
floatig -> floating.
* config/riscv/riscv.opt (mcsr-check): Spelling fix: CRS -> CSR.
* params.opt (-param=ipa-cp-profile-count-base=): Spelling fix:
frequncy -> frequency.
gcc/c-family/
* c.opt (Wstrict-flex-arrays): Spelling fix: inproper -> improper.
gcc/cp/
* parser.cc (cp_parser_using_declaration): Spelling fix: favour
-> favor.
gcc/m2/
* lang.opt (fuse-list=): Spelling fix: finalializations ->
finalizations.

--- gcc/config/epiphany/epiphany.opt.jj 2024-01-03 11:51:47.489509710 +0100
+++ gcc/config/epiphany/epiphany.opt2024-04-22 22:53:56.581549745 +0200
@@ -105,7 +105,7 @@ Enum(attr_fp_mode) String(int) Value(FP_
 
 may-round-for-trunc
 Target Mask(MAY_ROUND_FOR_TRUNC)
-A floatig point to integer truncation may be replaced with rounding to save 
mode switching.
+A floating point to integer truncation may be replaced with rounding to save 
mode switching.
 
 mvect-double
 Target Mask(VECT_DOUBLE)
--- gcc/config/riscv/riscv.opt.jj   2024-04-09 08:12:29.379449739 +0200
+++ gcc/config/riscv/riscv.opt  2024-04-22 22:52:06.780080712 +0200
@@ -152,7 +152,7 @@ required to materialize symbol addresses
 
 mcsr-check
 Target Var(riscv_mcsr_check) Init(0)
-Enable the CSR checking for the ISA-dependent CRS and the read-only CSR.
+Enable the CSR checking for the ISA-dependent CSR and the read-only CSR.
 The ISA-dependent CSR are only valid when the specific ISA is set.  The
 read-only CSR can not be written by the CSR instructions.
 
--- gcc/cp/parser.cc.jj 2024-04-22 18:12:35.326282135 +0200
+++ gcc/cp/parser.cc2024-04-22 23:14:11.928605442 +0200
@@ -22431,7 +22431,7 @@ cp_parser_using_declaration (cp_parser*
   if (access_declaration_p && errorcount == oldcount)
 warning_at (diag_token->location, OPT_Wdeprecated,
"access declarations are deprecated "
-   "in favour of using-declarations; "
+   "in favor of using-declarations; "
"suggestion: add the % keyword");
 
   return true;
--- gcc/m2/lang.opt.jj  2024-04-03 09:58:33.538770735 +0200
+++ gcc/m2/lang.opt 2024-04-22 22:47:59.120533842 +0200
@@ -260,7 +260,7 @@ optimize non var unbounded parameters by
 
 fuse-list=
 Modula-2 Joined
-orders the initialization/finalializations for scaffold-static or force 
linking of modules if scaffold-dynamic
+orders the initialization/finalizations for scaffold-static or force linking 
of modules if scaffold-dynamic
 
 fversion
 Modula-2
--- gcc/c-family/c.opt.jj   2024-04-15 10:16:58.571245875 +0200
+++ gcc/c-family/c.opt  2024-04-22 22:41:48.188705755 +0200
@@ -1320,7 +1320,7 @@ C ObjC C++ ObjC++ LangEnabledBy(C ObjC C
 
 Wstrict-flex-arrays
 C C++ Var(warn_strict_flex_arrays) Warning
-Warn about inproper usages of flexible array members
+Warn about improper usages of flexible array members
 according to the level of -fstrict-flex-arrays.
 
 Wstrict-null-sentinel
--- gcc/params.opt.jj   2024-01-03 11:51:22.563855655 +0100
+++ gcc/params.opt  2024-04-22 23:06:47.466804309 +0200
@@ -263,7 +263,7 @@ Maximum size of a list of values associa
 
 -param=ipa-cp-profile-count-base=
 Common Joined UInteger Var(param_ipa_cp_profile_count_base) Init(10) 
IntegerRange(0, 100) Param Optimization
-When using profile feedback, use the edge at this percentage position in 
frequncy histogram as the bases for IPA-CP heuristics.
+When using profile feedback, use the edge at this percentage position in 
frequency histogram as the bases for IPA-CP heuristics.
 
 -param=ipa-jump-function-lookups=
 Common Joined UInteger Var(param_ipa_jump_function_lookups) Init(8) Param 
Optimization

Jakub

Re: [pushed] c++/modules: make bits_in/out move-constructible

[Patrick Palka]

On Mon, 22 Apr 2024, Christophe Lyon wrote:

> Hi Patrick,
> 
> On Sat, 13 Apr 2024 at 22:12, Patrick Palka  wrote:
> >
> > Pushed as obvious after verifying C++11 bootstrap is restored.
> 
> I guess this also fixes the bootstrap_ubsan breakage on aarch64
> reported by Linaro CI?
> See https://linaro.atlassian.net/browse/GNU-1199
> (I think you also received a notification about this a few days ago?)

Yes, sorry for the breakage.  r14-9955-g436ab7e8e8b broke bootstrap
due to relying on C++17 copy elision semantics, and this followup
patch trivially fixed that.

> 
> Thanks,
> 
> Christophe
> 
> >
> > -- >8 --
> >
> > gcc/cp/ChangeLog:
> >
> > * module.cc (struct bytes_in::bits_in): Define defaulted
> > move ctor.
> > (struct bytes_out::bits_out): Likewise.
> > ---
> >  gcc/cp/module.cc | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> > index bbed82652d4..c6f71e11515 100644
> > --- a/gcc/cp/module.cc
> > +++ b/gcc/cp/module.cc
> > @@ -706,6 +706,7 @@ struct bytes_in::bits_in {
> >  bflush ();
> >}
> >
> > +  bits_in(bits_in&&) = default;
> >bits_in(const bits_in&) = delete;
> >bits_in& operator=(const bits_in&) = delete;
> >
> > @@ -752,6 +753,7 @@ struct bytes_out::bits_out {
> >  bflush ();
> >}
> >
> > +  bits_out(bits_out&&) = default;
> >bits_out(const bits_out&) = delete;
> >bits_out& operator=(const bits_out&) = delete;
> >
> > --
> > 2.44.0.591.g8f7582d995
> >
> 
> 

[PATCH] RISC-V: Revert this weekend's changes

[Palmer Dabbelt]

Looks like we had a bunch of commits over the weekend that didn't get
tested/reviewed.  Some didn't even make it to the lists so it's hard to
tell exactly what happened, but the result was a trunk that doesn't even
build and a bunch of ICEs after some trivial fix ups landed on the
lists.

So let's just go back to what worked.  We're bumping up right next to a
release, it's a really bad time to be breaking stuff this badly.  It's
still not clear exactly what was broken here, so if something's wrong
then we should still fix it -- let's just at least build things until
GCC-14 branches.

gcc/ChangeLog:

* config/riscv/constraints.md (TARGET_VECTOR ? V_REGS :
NO_REGS): Revert to 90ded7512e1 ("Daily bump.").
* config/riscv/riscv.md (none,W21,W42,W84,W43,W86,W87,W0):
Likewise.
(no,W21,W42,W84,W41,W81,W82): Likewise.
(no,yes): Likewise.
* config/riscv/vector.md: Likewise.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul8-11.c: Revert to
90ded7512e1 ("Daily bump.").
* gcc.target/riscv/rvv/base/pr112431-10.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-11.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-12.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-13.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-16.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-17.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-18.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-22.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-23.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-24.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-25.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-26.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-27.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-28.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-29.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-30.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-31.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-32.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-33.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-37.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-38.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-39.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-40.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-41.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-42.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-7.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-8.c: Likewise.
* gcc.target/riscv/rvv/base/pr112431-9.c: Likewise.

Fixes: cacc55a4c0b ("Revert "RISC-V: Rename vconstraint into group_overlap"")
Fixes: b78c88438cf ("Revert "RISC-V: Robostify the W43, W86, W87 constraint 
enabled attribute"")
Fixes: b991193eb8a ("RISC-V: Add xfail test case for highpart overlap 
floating-point widen insn")
Fixes: 4df96b4ec78 ("Revert "RISC-V: Support highpart overlap for 
floating-point widen instructions"")
Fixes: a367b99f916 ("RISC-V: Add xfail test case for indexed load overlap with 
SRC EEW < DEST EEW")
Fixes: 9257c7a7205 ("Revert "RISC-V: Support highpart overlap for indexed load 
with SRC EEW < DEST EEW"")
Fixes: c7506847c02 ("RISC-V: Add xfail test case for highest-number regno 
ternary overlap")
Fixes: cc46b6d4f3b ("Revert "RISC-V: Support highest-number regno overlap for 
widen ternary"")
Fixes: c4fdbdac122 ("RISC-V: Add xfail test case for widening register overlap 
of vf4/vf8")
Fixes: ec78916bb37 ("Revert "RISC-V: Support widening register overlap for 
vf4/vf8"")
Fixes: 338640fbee2 ("RISC-V: Add xfail test case for highpart register overlap 
of vx/vf widen")
Fixes: ef2392236ec ("Revert "RISC-V: Support highpart register overlap for 
widen vx/vf instructions"")
Fixes: d37b34fe82e ("RISC-V: Add xfail test case for incorrect overlap on v0")
Fixes: 3afcb04bd7d ("Revert "RISC-V: Fix overlap group incorrect overlap on 
v0"")
Fixes: 1690e47e101 ("RISC-V: Add xfail test case for wv insn highest overlap")
Fixes: f5447eae72f ("Revert "RISC-V: Support highest overlap for wv 
instructions"")
Fixes: 9f10005dbc9 ("RISC-V: Add xfail test case for wv insn register overlap")
Fixes: 0cbeafe2651 ("Revert "RISC-V: Support one more overlap for wv 
instructions"")
---

I haven't even built this one myself so I'm definately not going to
commit it, but I figured it'd be best to get something on the lists as
we're pretty broken.  If someone has a patch stack that gets things
building and fixes the ICEs then I'm happy to look at that, but it's not
even clear what we were trying to fix in the first place.

Either way, I think we've found a pretty major issue with our
development process here.
---
 gcc/config/riscv/constraints.md   |  12 +-
 gcc/config/riscv/riscv.md |  40 +-
 gcc/config/riscv/vector.md

Re: [PATCH v9 1/5] Provide counted_by attribute to flexible array member field (PR108896)

[Joseph Myers]

This version of patch 1/5 is OK for GCC 15.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: [PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d and e65aaf8efe1

[Patrick O'Neill]

Hi Pan,

I was running the testsuite for this and noticed an ICE scroll by when 
this patch is applied to cacc55a4c0be8d0bc7417b6a28924eadbbe428e3 for 
rv64gcv:


FAIL: gfortran.dg/graphite/pr29832.f90   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal 
compiler error: in extract_insn, at recog.cc:2812)


I'll send the full list of new failures once the runs finish.

Thanks,
Patrick

On 4/22/24 06:47, pan2...@intel.com wrote:

From: Pan Li 

After we reverted below 2 commits, the reference to attr need some
adjustment as the group_overlap is no longer available.

* RISC-V: Robostify the W43, W86, W87 constraint enabled attribute
* RISC-V: Rename vconstraint into group_overlap

The below tests are passed for this patch.

* The rv64gcv fully regression tests.

gcc/ChangeLog:

* config/riscv/vector-crypto.md:

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

diff --git a/gcc/config/riscv/vector-crypto.md 
b/gcc/config/riscv/vector-crypto.md
index 519c6a10d94..23dc549e5b8 100755
--- a/gcc/config/riscv/vector-crypto.md
+++ b/gcc/config/riscv/vector-crypto.md
@@ -322,7 +322,7 @@ (define_insn "@pred_vwsll_scalar"
"vwsll.v%o4\t%0,%3,%4%p1"
[(set_attr "type" "vwsll")
 (set_attr "mode" "")
-   (set_attr "group_overlap" 
"W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,none,none")])
+   (set_attr "vconstraint" 
"W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,no,no")])
  
  ;; vbrev.v vbrev8.v vrev8.v

  (define_insn "@pred_v"

Re: [PATCH] decay vect tests from run to link for pr95401

[Richard Biener]

On Mon, Apr 22, 2024 at 12:05 PM Alexandre Oliva  wrote:
>
> Ping?-ish for the full version of the RFC posted at
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566588.html
>
> On Mar 11, 2021, Richard Biener  wrote:
>
> > On Thu, Mar 11, 2021 at 9:03 AM Alexandre Oliva  wrote:
>
> >> So I'm leaning towards this proposed change, just extended to other
> >> platforms that also decay from run to compile rather than link, and thus
> >> run into this problem in g++.dg/vect/pr95401.cc.  Would this be
> >> acceptable?
>
> > I think that's OK.  It's probably difficult to make the test UNSUPPORTED
> > when dg-additional-sources is discovered with a dg-do compile test?
>
> Thanks, here's a completed version.
>
>
> When vect.exp finds our configuration disables altivec by default, it
> disables the execution of vectorization tests, assuming the test
> hardware doesn't support it.
>
> Tests become just compile tests, but compile tests won't work
> correctly when additional sources are named, e.g. pr95401.cc, because
> GCC refuses to compile multiple files into the same asm output.
>
> With this patch, the default for when execution is not possible
> becomes link.
>
> Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu.  Also tested with
> gcc-13 on ppc64-vx7r2 and ppc-vx7r2.  Ok to install?

That makes sense.  OK

Thanks,
Richard.

>
> for  gcc/testsuite/ChangeLog
>
> * lib/target-supports.exp (check_vect_support_and_set_flags):
> Decay to link rather than compile.
> ---
>  gcc/testsuite/lib/target-supports.exp |   18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index 3a5713d98691f..54a55585371b0 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -11625,7 +11625,7 @@ proc check_vect_support_and_set_flags { } {
>  if [check_750cl_hw_available] {
>  set dg-do-what-default run
>  } else {
> -set dg-do-what-default compile
> +set dg-do-what-default link
>  }
>  } elseif [istarget powerpc*-*-*] {
>  # Skip targets not supporting -maltivec.
> @@ -11655,14 +11655,14 @@ proc check_vect_support_and_set_flags { } {
>  # some other cpu type specified above.
> set DEFAULT_VECTCFLAGS [linsert $DEFAULT_VECTCFLAGS 0 
> "-mcpu=970"]
>  }
> -set dg-do-what-default compile
> +set dg-do-what-default link
>  }
>  } elseif { [istarget i?86-*-*] || [istarget x86_64-*-*] } {
>  lappend DEFAULT_VECTCFLAGS "-msse2"
>  if { [check_effective_target_sse2_runtime] } {
>  set dg-do-what-default run
>  } else {
> -set dg-do-what-default compile
> +set dg-do-what-default link
>  }
>  } elseif { [istarget mips*-*-*]
>&& [check_effective_target_nomips16] } {
> @@ -11681,7 +11681,7 @@ proc check_vect_support_and_set_flags { } {
>  if [check_effective_target_ultrasparc_hw] {
>  set dg-do-what-default run
>  } else {
> -set dg-do-what-default compile
> +set dg-do-what-default link
>  }
>  } elseif [istarget alpha*-*-*] {
>  # Alpha's vectorization capabilities are extremely limited.
> @@ -11694,7 +11694,7 @@ proc check_vect_support_and_set_flags { } {
>  if [check_alpha_max_hw_available] {
>  set dg-do-what-default run
>  } else {
> -set dg-do-what-default compile
> +set dg-do-what-default link
>  }
>  } elseif [istarget ia64-*-*] {
>  set dg-do-what-default run
> @@ -11707,7 +11707,7 @@ proc check_vect_support_and_set_flags { } {
>  if [is-effective-target arm_neon_hw] {
>  set dg-do-what-default run
>  } else {
> -set dg-do-what-default compile
> +set dg-do-what-default link
>  }
>  } elseif [istarget aarch64*-*-*] {
>  set dg-do-what-default run
> @@ -11731,7 +11731,7 @@ proc check_vect_support_and_set_flags { } {
>  set dg-do-what-default run
>  } else {
> lappend DEFAULT_VECTCFLAGS "-march=z14" "-mzarch"
> -set dg-do-what-default compile
> +set dg-do-what-default link
>  }
>  } elseif [istarget amdgcn-*-*] {
>  set dg-do-what-default run
> @@ -11742,7 +11742,7 @@ proc check_vect_support_and_set_flags { } {
> foreach item [add_options_for_riscv_v ""] {
> lappend DEFAULT_VECTCFLAGS $item
> }
> -   set dg-do-what-default compile
> +   set dg-do-what-default link
> }
>  } elseif [istarget loongarch*-*-*] {
># Set the default vectorization option to "-mlsx" due to the problem
> @@ -11751,7 +11751,7 @@ proc check_vect_support_and_set_flags { } {
>if [

Re: [PATCH] s390: testsuite: Fix forwprop-4{0,1}.c

[Richard Biener]

On Mon, Apr 22, 2024 at 10:47 AM Andreas Krebbel  wrote:
>
> Hi Stefan,
>
> due to that missed optimization we currently generate silly code for these 
> two tests and should
> really fix this (after gcc entering stage1). So just skipping it on s390x 
> would definitely be the
> wrong choice I think.
>
> I think our vectorize_vec_perm_const correctly rejects this permute pattern, 
> since it would require
> a load from literal pool. Question is why we do have to rely on this being 
> turned into a permute
> first to get rid of the obviously redundant assignments. Shouldn't fwprop be 
> able to handle this
> without it?

We do not detect "redundant" BIT_INSERT, but the match.pd pattern
could eventually detect
this case (ISTR we have one doing that but I may be mistaken).

> I'm ok with your patch, but please also open a BZ for it and perhaps mention 
> it in the comment close
> to the xfail.
>
> Thanks!
>
> Andreas
>
> On 4/22/24 08:23, Stefan Schulze Frielinghaus wrote:
> > The tests fail on s390 since can_vec_perm_const_p fails and therefore
> > the bit insert/ref survive which r14-3381-g27de9aa152141e aims for.
> > Strictly speaking, the tests only fail in case the target supports
> > vectors, i.e., for targets prior z13 or in case of -mesa the emulated
> > vector operations are optimized out.
> >
> > Easiest would be to skip the entire test for s390.  Another solution
> > would be to xfail in case of vector support hoping that eventually we
> > end up with an xpass for a future machine generation or if gcc advances.
> > That is implemented by this patch.  In order to do so I implemented a
> > new target test s390_mvx which tests whether vector support is available
> > or not.  Maybe this is already over-engineered for a simple test?  Any
> > thoughts?
> > ---
> >  gcc/testsuite/gcc.dg/tree-ssa/forwprop-40.c |  4 ++--
> >  gcc/testsuite/gcc.dg/tree-ssa/forwprop-41.c |  4 ++--
> >  gcc/testsuite/lib/target-supports.exp   | 14 ++
> >  3 files changed, 18 insertions(+), 4 deletions(-)
> >
> > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-40.c 
> > b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-40.c
> > index 7513497f552..b67e3e93a7f 100644
> > --- a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-40.c
> > +++ b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-40.c
> > @@ -10,5 +10,5 @@ vector int g(vector int a)
> >return a;
> >  }
> >
> > -/* { dg-final { scan-tree-dump-times "BIT_INSERT_EXPR" 0 "optimized" } } */
> > -/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 0 "optimized" } } */
> > +/* { dg-final { scan-tree-dump-times "BIT_INSERT_EXPR" 0 "optimized" { 
> > xfail s390_mvx } } } */
> > +/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 0 "optimized" { xfail 
> > s390_mvx } } } */
> > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-41.c 
> > b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-41.c
> > index b1e75797a90..0f119675207 100644
> > --- a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-41.c
> > +++ b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-41.c
> > @@ -11,6 +11,6 @@ vector int g(vector int a, int c)
> >return a;
> >  }
> >
> > -/* { dg-final { scan-tree-dump-times "BIT_INSERT_EXPR" 1 "optimized" } } */
> > -/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 0 "optimized" } } */
> > +/* { dg-final { scan-tree-dump-times "BIT_INSERT_EXPR" 1 "optimized" { 
> > xfail s390_mvx } } } */
> > +/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 0 "optimized" { xfail 
> > s390_mvx } } } */
> >  /* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR" 0 "optimized" } } */
> > diff --git a/gcc/testsuite/lib/target-supports.exp 
> > b/gcc/testsuite/lib/target-supports.exp
> > index edce672c0e2..5a692baa8ef 100644
> > --- a/gcc/testsuite/lib/target-supports.exp
> > +++ b/gcc/testsuite/lib/target-supports.exp
> > @@ -12380,6 +12380,20 @@ proc check_effective_target_profile_update_atomic 
> > {} {
> >  } "-fprofile-update=atomic -fprofile-generate"]
> >  }
> >
> > +# Return 1 if the target has a vector facility.
> > +proc check_effective_target_s390_mvx { } {
> > +if ![istarget s390*-*-*] then {
> > + return 0;
> > +}
> > +
> > +return [check_no_compiler_messages_nocache s390_mvx assembly {
> > + #if !defined __VX__
> > + #error no vector facility.
> > + #endif
> > + int dummy;
> > +} [current_compiler_flags]]
> > +}
> > +
> >  # Return 1 if vector (va - vector add) instructions are understood by
> >  # the assembler and can be executed.  This also covers checking for
> >  # the VX kernel feature.  A kernel without that feature does not
>

Re: [PATCH] Add rvalue::get_name method (and its C equivalent)

[Guillaume Gomez]

`param` is also inheriting from `lvalue`. I don't think adding this
check is a good idea
because it will not evolve nicely if more changes are done in libgccjit.

Le lun. 22 avr. 2024 à 17:19, Antoni Boucher  a écrit :
>
> For your new API endpoint, please add a check like:
>
>RETURN_IF_FAIL (lvalue->is_global () || lvalue->is_local (),
>   NULL,
>   NULL,
>   "lvalue should be a variable");
>
>
> Le 2024-04-22 à 09 h 16, Guillaume Gomez a écrit :
> > Good point!
> >
> > New patch attached.
> >
> > Le lun. 22 avr. 2024 à 15:13, Antoni Boucher  a écrit :
> >>
> >> Please move the function to be on lvalue since there are no rvalue types
> >> that are not lvalues that have a name.
> >>
> >> Le 2024-04-22 à 09 h 04, Guillaume Gomez a écrit :
> >>> Hey Arthur :)
> >>>
>  Is there any reason for that getter to return a mutable pointer to the
>  name? Would something like this work instead if you're just looking at
>  getting the name?
> 
>  +  virtual string * get_name () const { return NULL; }
> 
>  With of course adequate modifications to the inheriting classes.
> >>>
> >>> Good catch, thanks!
> >>>
> >>> Updated the patch and attached the new version to this email.
> >>>
> >>> Cordially.
> >>>
> >>> Le lun. 22 avr. 2024 à 11:51, Arthur Cohen  a 
> >>> écrit :
> 
>  Hey Guillaume :)
> 
>  On 4/20/24 01:05, Guillaume Gomez wrote:
> > Hi,
> >
> > I just encountered the need to retrieve the name of an `rvalue` (if
> > there is one) while working on the Rust GCC backend.
> >
> > This patch adds a getter to retrieve the information.
> >
> > Cordially.
> 
> >  virtual bool get_wide_int (wide_int *) const { return false; }
> >
> > +  virtual string * get_name () { return NULL; }
> > +
> >private:
> >  virtual enum precedence get_precedence () const = 0;
> 
>  Is there any reason for that getter to return a mutable pointer to the
>  name? Would something like this work instead if you're just looking at
>  getting the name?
> 
>  +  virtual string * get_name () const { return NULL; }
> 
>  With of course adequate modifications to the inheriting classes.
> 
>  Best,
> 
>  Arthur

Re: [PATCH v1] RISC-V: Revert RVV wv instructions overlap and xfail tests

[Patrick O'Neill]

Hi Pan,


I'm not sure I'm following.  Did we miss something that should have been
covered?  Like only an overlap on the srcs but not the dest?
Are there testcases that fail?  If so we should definitely have one.

Can you give some additional information on why these reverts are needed?
+1 to the request for a failing testcase if there is one.Patrick

If something is broken then indeed we should revert it.

Yes, we may need to support these in gcc-15.


... why not just revert everything and xfail all the tests in a
follow up?  Your patch is essentially a revert but doesn't look like
it.  I'd rather we let a revert be a revert and adjust the tests
separately so it becomes clear.

Sure, will revert b3b2799b872 and then file the patch for the xfail tests.

Pan

Re: [PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d and e65aaf8efe1

[Palmer Dabbelt]

On Mon, 22 Apr 2024 06:47:34 PDT (-0700), pan2...@intel.com wrote:

From: Pan Li 

After we reverted below 2 commits, the reference to attr need some
adjustment as the group_overlap is no longer available.

* RISC-V: Robostify the W43, W86, W87 constraint enabled attribute
* RISC-V: Rename vconstraint into group_overlap


That landed as cacc55a4c0b ("Revert "RISC-V: Rename vconstraint into 
group_overlap""), but I can't find a review on the lists and the commit 
appears to not even build.


Did I miss the reviews or something?


The below tests are passed for this patch.

* The rv64gcv fully regression tests.

gcc/ChangeLog:

* config/riscv/vector-crypto.md:

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

diff --git a/gcc/config/riscv/vector-crypto.md 
b/gcc/config/riscv/vector-crypto.md
index 519c6a10d94..23dc549e5b8 100755
--- a/gcc/config/riscv/vector-crypto.md
+++ b/gcc/config/riscv/vector-crypto.md
@@ -322,7 +322,7 @@ (define_insn "@pred_vwsll_scalar"
   "vwsll.v%o4\t%0,%3,%4%p1"
   [(set_attr "type" "vwsll")
(set_attr "mode" "")
-   (set_attr "group_overlap" 
"W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,none,none")])
+   (set_attr "vconstraint" 
"W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,no,no")])

 ;; vbrev.v vbrev8.v vrev8.v
 (define_insn "@pred_v"

Re: [PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d and e65aaf8efe1

[钟居哲]

lgtm



juzhe.zh...@rivai.ai
 
From: pan2.li
Date: 2024-04-22 21:47
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d and 
e65aaf8efe1
From: Pan Li 
 
After we reverted below 2 commits, the reference to attr need some
adjustment as the group_overlap is no longer available.
 
* RISC-V: Robostify the W43, W86, W87 constraint enabled attribute
* RISC-V: Rename vconstraint into group_overlap
 
The below tests are passed for this patch.
 
* The rv64gcv fully regression tests.
 
gcc/ChangeLog:
 
* config/riscv/vector-crypto.md:
 
Signed-off-by: Pan Li 
---
gcc/config/riscv/vector-crypto.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
 
diff --git a/gcc/config/riscv/vector-crypto.md 
b/gcc/config/riscv/vector-crypto.md
index 519c6a10d94..23dc549e5b8 100755
--- a/gcc/config/riscv/vector-crypto.md
+++ b/gcc/config/riscv/vector-crypto.md
@@ -322,7 +322,7 @@ (define_insn "@pred_vwsll_scalar"
   "vwsll.v%o4\t%0,%3,%4%p1"
   [(set_attr "type" "vwsll")
(set_attr "mode" "")
-   (set_attr "group_overlap" 
"W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,none,none")])
+   (set_attr "vconstraint" 
"W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,no,no")])
;; vbrev.v vbrev8.v vrev8.v
(define_insn "@pred_v"
-- 
2.34.1
 
 

Re: [RFC][PATCH v1 1/4] Documentation change

[Qing Zhao]

> On Apr 19, 2024, at 16:54, Tom Tromey  wrote:
> 
>> Qing Zhao  writes:
> 
>> +The size of the union is as if the flexiable array member were omitted
>> +except that it may have more trailing padding than the omission would imply.
>> +
>> +If all the members of a union are flexiable array member, the size of
> 
> There's a couple of spots that say "flexiable" which should say "flexible".

Thanks for catching those typo, I will fix them.

Qing
> 
> thanks,
> Tom

Re: [PATCH] Add rvalue::get_name method (and its C equivalent)

[Guillaume Gomez]

Good point!

New patch attached.

Le lun. 22 avr. 2024 à 15:13, Antoni Boucher  a écrit :
>
> Please move the function to be on lvalue since there are no rvalue types
> that are not lvalues that have a name.
>
> Le 2024-04-22 à 09 h 04, Guillaume Gomez a écrit :
> > Hey Arthur :)
> >
> >> Is there any reason for that getter to return a mutable pointer to the
> >> name? Would something like this work instead if you're just looking at
> >> getting the name?
> >>
> >> +  virtual string * get_name () const { return NULL; }
> >>
> >> With of course adequate modifications to the inheriting classes.
> >
> > Good catch, thanks!
> >
> > Updated the patch and attached the new version to this email.
> >
> > Cordially.
> >
> > Le lun. 22 avr. 2024 à 11:51, Arthur Cohen  a 
> > écrit :
> >>
> >> Hey Guillaume :)
> >>
> >> On 4/20/24 01:05, Guillaume Gomez wrote:
> >>> Hi,
> >>>
> >>> I just encountered the need to retrieve the name of an `rvalue` (if
> >>> there is one) while working on the Rust GCC backend.
> >>>
> >>> This patch adds a getter to retrieve the information.
> >>>
> >>> Cordially.
> >>
> >>> virtual bool get_wide_int (wide_int *) const { return false; }
> >>>
> >>> +  virtual string * get_name () { return NULL; }
> >>> +
> >>>   private:
> >>> virtual enum precedence get_precedence () const = 0;
> >>
> >> Is there any reason for that getter to return a mutable pointer to the
> >> name? Would something like this work instead if you're just looking at
> >> getting the name?
> >>
> >> +  virtual string * get_name () const { return NULL; }
> >>
> >> With of course adequate modifications to the inheriting classes.
> >>
> >> Best,
> >>
> >> Arthur
From 79a5af70787509f0f23dc131a39ed32a88d8f8fc Mon Sep 17 00:00:00 2001
From: Guillaume Gomez 
Date: Sat, 20 Apr 2024 01:02:20 +0200
Subject: [PATCH] [PATCH] Add rvalue::get_name method

gcc/jit/ChangeLog:

	* jit-recording.h: Add rvalue::get_name method
	* libgccjit.cc (gcc_jit_rvalue_get_name): Likewise
	* libgccjit.h (gcc_jit_rvalue_get_name): Likewise
	* libgccjit.map: Likewise

gcc/testsuite/ChangeLog:

	* jit.dg/test-tls.c: Add test for gcc_jit_rvalue_get_name
---
 gcc/jit/jit-recording.h |  7 +++
 gcc/jit/libgccjit.cc| 16 
 gcc/jit/libgccjit.h |  4 
 gcc/jit/libgccjit.map   |  5 +
 gcc/testsuite/jit.dg/test-tls.c |  2 ++
 5 files changed, 34 insertions(+)

diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
index d8d16f4fe29..a80327b26ba 100644
--- a/gcc/jit/jit-recording.h
+++ b/gcc/jit/jit-recording.h
@@ -1267,6 +1267,7 @@ public:
   void set_register_name (const char *reg_name);
   void set_alignment (unsigned bytes);
   unsigned get_alignment () const { return m_alignment; }
+  virtual string * get_name () const { return NULL; }
 
 protected:
   string *m_link_section;
@@ -1305,6 +1306,8 @@ public:
   const char *access_as_rvalue (reproducer &r) final override;
   const char *access_as_lvalue (reproducer &r) final override;
 
+  string * get_name () const final override { return m_name; }
+
 private:
   string * make_debug_string () final override { return m_name; }
   void write_reproducer (reproducer &r) final override;
@@ -1558,6 +1561,8 @@ public:
 
   void set_rvalue_init (rvalue *val) { m_rvalue_init = val; }
 
+  string * get_name () const final override { return m_name; }
+
 private:
   string * make_debug_string () final override { return m_name; }
   template 
@@ -2148,6 +2153,8 @@ public:
 
   void write_to_dump (dump &d) final override;
 
+  string * get_name () const final override { return m_name; }
+
 private:
   string * make_debug_string () final override { return m_name; }
   void write_reproducer (reproducer &r) final override;
diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
index 445c0d0e0e3..ea03afcd2c5 100644
--- a/gcc/jit/libgccjit.cc
+++ b/gcc/jit/libgccjit.cc
@@ -4377,3 +4377,19 @@ gcc_jit_context_add_top_level_asm (gcc_jit_context *ctxt,
   RETURN_IF_FAIL (asm_stmts, ctxt, NULL, "NULL asm_stmts");
   ctxt->add_top_level_asm (loc, asm_stmts);
 }
+
+/* Public entrypoint.  See description in libgccjit.h.
+
+   After error-checking, this calls the trivial
+   gcc::jit::recording::lvalue::get_name method, in jit-recording.h.  */
+
+extern const char *
+gcc_jit_lvalue_get_name (gcc_jit_lvalue *lvalue)
+{
+  RETURN_NULL_IF_FAIL (lvalue, NULL, NULL, "NULL lvalue");
+  auto name = lvalue->get_name ();
+
+  if (!name)
+return NULL;
+  return name->c_str ();
+}
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index 74e847b2dec..2ea85f5a4c3 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -2066,6 +2066,10 @@ gcc_jit_lvalue_add_string_attribute (gcc_jit_lvalue *variable,
  enum gcc_jit_variable_attribute attribute,
  const char* value);
 
+/* Returns the name of the `lvalue`, if any. Returns NULL otherwise.  */
+extern const char *
+gcc_jit_lvalue_get_name (gcc_jit_lvalue *lvalue);
+
 #ifdef __cplusplus
 }
 #end

Re: [PATCH] testsuite: prune -freport-bug output

[Jakub Jelinek]

On Fri, Apr 19, 2024 at 05:54:11PM -0400, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> I can defer to 15 if needed, of course.
> 
> -- >8 --
> When the compiler defaults to -freport-bug, a few dg-ice tests fail
> with:
> 
> Excess errors:
> Preprocessed source stored into /tmp/cc6hldZ0.out file, please attach this to 
> your bugreport.
> 
> We could add -fno-report-bug to those tests.  But it seems to me that a
> better fix would be to prune the "Preprocessed source stored..." message
> in prune_gcc_output.
> 
> gcc/testsuite/ChangeLog:
> 
>   * lib/prune.exp (prune_gcc_output): Also prune -freport-bug output.

LGTM.
> --- a/gcc/testsuite/lib/prune.exp
> +++ b/gcc/testsuite/lib/prune.exp
> @@ -51,6 +51,7 @@ proc prune_gcc_output { text } {
>  regsub -all "(^|\n)\[^\n\]*: re(compiling|linking)\[^\n\]*" $text "" text
>  regsub -all "(^|\n)Please submit.*instructions\[^\n\]*" $text "" text
>  regsub -all "(^|\n)\[0-9\]\[0-9\]* errors\." $text "" text
> +regsub -all "(^|\n)Preprocessed.*bugreport\[^\n\]*" $text "" text
>  
>  # Diagnostic inclusion stack
>  regsub -all "(^|\n)(In file)?\[ \]+included from \[^\n\]*" $text "" text
> 
> base-commit: d86472a6f041ccf3d1be0cf6bb15d1e0ad8f6dbe
> -- 
> 2.44.0

Jakub

[PATCH v1] RISC-V: Adjust overlap attr after revert d3544cea63d and e65aaf8efe1

[pan2 . li]

From: Pan Li 

After we reverted below 2 commits, the reference to attr need some
adjustment as the group_overlap is no longer available.

* RISC-V: Robostify the W43, W86, W87 constraint enabled attribute
* RISC-V: Rename vconstraint into group_overlap

The below tests are passed for this patch.

* The rv64gcv fully regression tests.

gcc/ChangeLog:

* config/riscv/vector-crypto.md:

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

diff --git a/gcc/config/riscv/vector-crypto.md 
b/gcc/config/riscv/vector-crypto.md
index 519c6a10d94..23dc549e5b8 100755
--- a/gcc/config/riscv/vector-crypto.md
+++ b/gcc/config/riscv/vector-crypto.md
@@ -322,7 +322,7 @@ (define_insn "@pred_vwsll_scalar"
   "vwsll.v%o4\t%0,%3,%4%p1"
   [(set_attr "type" "vwsll")
(set_attr "mode" "")
-   (set_attr "group_overlap" 
"W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,none,none")])
+   (set_attr "vconstraint" 
"W21,W21,W21,W21,W42,W42,W42,W42,W84,W84,W84,W84,no,no")])
 
 ;; vbrev.v vbrev8.v vrev8.v
 (define_insn "@pred_v"
-- 
2.34.1

Re: [PATCH] Add rvalue::get_name method (and its C equivalent)

[Guillaume Gomez]

... I most definitely forgot. Thanks! ^^'

Le lun. 22 avr. 2024 à 15:19, Antoni Boucher  a écrit :

> I believe you forgot to regenerate the ChangeLog.
>
> Le 2024-04-22 à 09 h 16, Guillaume Gomez a écrit :
> > Good point!
> >
> > New patch attached.
> >
> > Le lun. 22 avr. 2024 à 15:13, Antoni Boucher  a écrit
> :
> >>
> >> Please move the function to be on lvalue since there are no rvalue types
> >> that are not lvalues that have a name.
> >>
> >> Le 2024-04-22 à 09 h 04, Guillaume Gomez a écrit :
> >>> Hey Arthur :)
> >>>
>  Is there any reason for that getter to return a mutable pointer to the
>  name? Would something like this work instead if you're just looking at
>  getting the name?
> 
>  +  virtual string * get_name () const { return NULL; }
> 
>  With of course adequate modifications to the inheriting classes.
> >>>
> >>> Good catch, thanks!
> >>>
> >>> Updated the patch and attached the new version to this email.
> >>>
> >>> Cordially.
> >>>
> >>> Le lun. 22 avr. 2024 à 11:51, Arthur Cohen 
> a écrit :
> 
>  Hey Guillaume :)
> 
>  On 4/20/24 01:05, Guillaume Gomez wrote:
> > Hi,
> >
> > I just encountered the need to retrieve the name of an `rvalue` (if
> > there is one) while working on the Rust GCC backend.
> >
> > This patch adds a getter to retrieve the information.
> >
> > Cordially.
> 
> >  virtual bool get_wide_int (wide_int *) const { return false; }
> >
> > +  virtual string * get_name () { return NULL; }
> > +
> >private:
> >  virtual enum precedence get_precedence () const = 0;
> 
>  Is there any reason for that getter to return a mutable pointer to the
>  name? Would something like this work instead if you're just looking at
>  getting the name?
> 
>  +  virtual string * get_name () const { return NULL; }
> 
>  With of course adequate modifications to the inheriting classes.
> 
>  Best,
> 
>  Arthur
>
From 79a5af70787509f0f23dc131a39ed32a88d8f8fc Mon Sep 17 00:00:00 2001
From: Guillaume Gomez 
Date: Sat, 20 Apr 2024 01:02:20 +0200
Subject: [PATCH] [PATCH] Add lvalue::get_name method

gcc/jit/ChangeLog:

	* jit-recording.h: Add lvalue::get_name method
	* libgccjit.cc (gcc_jit_lvalue_get_name): Likewise
	* libgccjit.h (gcc_jit_lvalue_get_name): Likewise
	* libgccjit.map: Likewise

gcc/testsuite/ChangeLog:

	* jit.dg/test-tls.c: Add test for gcc_jit_lvalue_get_name
---
 gcc/jit/jit-recording.h |  7 +++
 gcc/jit/libgccjit.cc| 16 
 gcc/jit/libgccjit.h |  4 
 gcc/jit/libgccjit.map   |  5 +
 gcc/testsuite/jit.dg/test-tls.c |  2 ++
 5 files changed, 34 insertions(+)

diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
index d8d16f4fe29..a80327b26ba 100644
--- a/gcc/jit/jit-recording.h
+++ b/gcc/jit/jit-recording.h
@@ -1267,6 +1267,7 @@ public:
   void set_register_name (const char *reg_name);
   void set_alignment (unsigned bytes);
   unsigned get_alignment () const { return m_alignment; }
+  virtual string * get_name () const { return NULL; }
 
 protected:
   string *m_link_section;
@@ -1305,6 +1306,8 @@ public:
   const char *access_as_rvalue (reproducer &r) final override;
   const char *access_as_lvalue (reproducer &r) final override;
 
+  string * get_name () const final override { return m_name; }
+
 private:
   string * make_debug_string () final override { return m_name; }
   void write_reproducer (reproducer &r) final override;
@@ -1558,6 +1561,8 @@ public:
 
   void set_rvalue_init (rvalue *val) { m_rvalue_init = val; }
 
+  string * get_name () const final override { return m_name; }
+
 private:
   string * make_debug_string () final override { return m_name; }
   template 
@@ -2148,6 +2153,8 @@ public:
 
   void write_to_dump (dump &d) final override;
 
+  string * get_name () const final override { return m_name; }
+
 private:
   string * make_debug_string () final override { return m_name; }
   void write_reproducer (reproducer &r) final override;
diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
index 445c0d0e0e3..ea03afcd2c5 100644
--- a/gcc/jit/libgccjit.cc
+++ b/gcc/jit/libgccjit.cc
@@ -4377,3 +4377,19 @@ gcc_jit_context_add_top_level_asm (gcc_jit_context *ctxt,
   RETURN_IF_FAIL (asm_stmts, ctxt, NULL, "NULL asm_stmts");
   ctxt->add_top_level_asm (loc, asm_stmts);
 }
+
+/* Public entrypoint.  See description in libgccjit.h.
+
+   After error-checking, this calls the trivial
+   gcc::jit::recording::lvalue::get_name method, in jit-recording.h.  */
+
+extern const char *
+gcc_jit_lvalue_get_name (gcc_jit_lvalue *lvalue)
+{
+  RETURN_NULL_IF_FAIL (lvalue, NULL, NULL, "NULL lvalue");
+  auto name = lvalue->get_name ();
+
+  if (!name)
+return NULL;
+  return name->c_str ();
+}
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index 74e847b2dec..2ea85f5a4c3 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -206

Re: [PATCH] libstdc++: Silence irrelevant warnings in

[Jonathan Wakely]

On Mon, 22 Apr 2024 at 16:30, Matthias Kretz  wrote:
>
> Tested on x86_64-linux-gnu, powerpc64le-linux-gnu, aarch64-linux-gnu, arm-
> linux-gnueabihf
>
> OK for trunk and backports?

OK, thanks


>
> - 8< -
>
>
> Avoid
> -Wnarrowing in C code;
> -Wtautological-compare in unconditional static_assert (necessary for
> faking a dependency on a template parameter)
>
> Signed-off-by: Matthias Kretz 
>
> libstdc++-v3/ChangeLog:
>
> * include/experimental/bits/simd.h: Ignore -Wnarrowing for
> arm_neon.h.
> (__int_for_sizeof): Replace tautological compare with checking
> for invalid template parameter value.
> * include/experimental/bits/simd_builtin.h (__extract_part):
> Remove tautological compare by combining two static_assert.
> ---
>  libstdc++-v3/include/experimental/bits/simd.h | 8 +++-
>  libstdc++-v3/include/experimental/bits/simd_builtin.h | 3 +--
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/libstdc++-v3/include/experimental/bits/simd.h b/libstdc++-v3/
> include/experimental/bits/simd.h
> index 03c2e17a326..6ef9c955cfa 100644
> --- a/libstdc++-v3/include/experimental/bits/simd.h
> +++ b/libstdc++-v3/include/experimental/bits/simd.h
> @@ -44,7 +44,12 @@
>  #if _GLIBCXX_SIMD_X86INTRIN
>  #include 
>  #elif _GLIBCXX_SIMD_HAVE_NEON
> +#pragma GCC diagnostic push
> +// narrowing conversion of '__a' from 'uint64_t' {aka 'long long unsigned
> int'} to
> +//   'int64x1_t' {aka 'long long int'} [-Wnarrowing]
> +#pragma GCC diagnostic ignored "-Wnarrowing"
>  #include 
> +#pragma GCC diagnostic pop
>  #endif
>  #if _GLIBCXX_SIMD_HAVE_SVE
>  #include 
> @@ -598,6 +603,7 @@ struct __is_bitmask
>constexpr auto
>__int_for_sizeof()
>{
> +static_assert(_Bytes > 0);
>  if constexpr (_Bytes == sizeof(int))
>return int();
>#ifdef __clang__
> @@ -663,7 +669,7 @@ struct _Ip
> return _Ip{};
>}
>  else
> -  static_assert(_Bytes != _Bytes, "this should be unreachable");
> +  static_assert(_Bytes == 0, "this should be unreachable");
>}
>  #pragma GCC diagnostic pop
>
> diff --git a/libstdc++-v3/include/experimental/bits/simd_builtin.h b/libstdc+
> +-v3/include/experimental/bits/simd_builtin.h
> index af0c4886108..49c7c7e1c70 100644
> --- a/libstdc++-v3/include/experimental/bits/simd_builtin.h
> +++ b/libstdc++-v3/include/experimental/bits/simd_builtin.h
> @@ -278,8 +278,7 @@ __extract_part(const _SimdWrapper<_Tp, _Np> __x)
>__extract_part(const _SimdWrapper __x)
>{
>  static_assert(_Combine == 1, "_Combine != 1 not implemented");
> -static_assert(__have_avx512f && _Np == _Np);
> -static_assert(_Total >= 2 && _Index + _Combine <= _Total && _Index >= 0);
> +static_assert(__have_avx512f && _Total >= 2 && _Index + _Combine <=
> _Total && _Index >= 0);
>  return __x._M_data >> (_Index * _Np / _Total);
>}
>
> --
> ──
>  Dr. Matthias Kretz   https://mattkretz.github.io
>  GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
>  stdₓ::simd
> ──
>

Re: [PATCH] libstdc++: Fix conversion of simd to vector builtin

[Jonathan Wakely]

On Mon, 22 Apr 2024 at 16:30, Matthias Kretz  wrote:
>
> Tested on x86_64-linux-gnu, powerpc64le-linux-gnu, aarch64-linux-gnu, arm-
> linux-gnueabihf
>
> OK for trunk and backports?

OK


>
> - 8< -
>
> Signed-off-by: Matthias Kretz 
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/114803
> * include/experimental/bits/simd_builtin.h
> (_SimdBase2::operator __vector_type_t): There is no __builtin()
> function in _SimdWrapper, instead use its conversion operator.
> * testsuite/experimental/simd/pr114803_vecbuiltin_cvt.cc: New
> test.
> ---
>  .../include/experimental/bits/simd_builtin.h  |   2 +-
>  .../simd/pr114803_vecbuiltin_cvt.cc   | 105 ++
>  2 files changed, 106 insertions(+), 1 deletion(-)
>  create mode 100644 libstdc++-v3/testsuite/experimental/simd/
> pr114803_vecbuiltin_cvt.cc
>
> diff --git a/libstdc++-v3/include/experimental/bits/simd_builtin.h b/libstdc+
> +-v3/include/experimental/bits/simd_builtin.h
> index 49c7c7e1c70..4ceeb423894 100644
> --- a/libstdc++-v3/include/experimental/bits/simd_builtin.h
> +++ b/libstdc++-v3/include/experimental/bits/simd_builtin.h
> @@ -841,7 +841,7 @@ struct _SimdBase2
>
>_GLIBCXX_SIMD_ALWAYS_INLINE explicit
>operator __vector_type_t<_Tp, _Np>() const
> -  { return static_cast*>(this)-
> >_M_data.__builtin(); }
> +  { return __data(*static_cast*>(this)); }
>  };
>
>  struct _SimdBase1
> diff --git a/libstdc++-v3/testsuite/experimental/simd/
> pr114803_vecbuiltin_cvt.cc b/libstdc++-v3/testsuite/experimental/simd/
> pr114803_vecbuiltin_cvt.cc
> new file mode 100644
> index 000..103dd19394c
> --- /dev/null
> +++ b/libstdc++-v3/testsuite/experimental/simd/pr114803_vecbuiltin_cvt.cc
> @@ -0,0 +1,105 @@
> +// { dg-options "-std=gnu++17" }
> +// { dg-do compile { target c++17 } }
> +
> +#include 
> +
> +template 
> +  void
> +  maybe_test()
> +  {
> +using V = std::experimental::simd std::experimental::simd_abi::_VecBuiltin<16>>;
> +if constexpr (std::is_destructible_v)
> +  {
> +   using V2 [[gnu::vector_size(16)]] = T;
> +   V x = {};
> +   V2 x2 = static_cast(x);
> +   x = static_cast(x2);
> +   for (unsigned i = 0; i < V::size(); ++i)
> + {
> +   if (x2[i] != 0)
> + __builtin_abort();
> + }
> +#ifdef __SSE__
> +   if constexpr (std::is_same_v)
> + x = static_cast(static_cast<__m128>(x));
> +   else if constexpr (std::is_same_v)
> + x = static_cast(static_cast<__m128d>(x));
> +   else if constexpr (std::is_integral_v)
> + x = static_cast(static_cast<__m128i>(x));
> +#elif __ALTIVEC__
> +   if constexpr (std::is_same_v)
> + x = static_cast(static_cast<__vector float>(x));
> +#ifdef __VSX__
> +   else if constexpr (std::is_same_v)
> + x = static_cast(static_cast<__vector double>(x));
> +#endif
> +   else if constexpr (std::is_integral_v && sizeof(T) ==
> sizeof(signed char)
> +&& std::is_signed_v)
> + x = static_cast(static_cast<__vector signed char>(x));
> +   else if constexpr (std::is_integral_v && sizeof(T) ==
> sizeof(signed char))
> + x = static_cast(static_cast<__vector unsigned char>(x));
> +   else if constexpr (std::is_integral_v && sizeof(T) ==
> sizeof(short)
> +&& std::is_signed_v)
> + x = static_cast(static_cast<__vector signed short>(x));
> +   else if constexpr (std::is_integral_v && sizeof(T) ==
> sizeof(short))
> + x = static_cast(static_cast<__vector unsigned short>(x));
> +   else if constexpr (std::is_integral_v && sizeof(T) == sizeof(int)
> +&& std::is_signed_v)
> + x = static_cast(static_cast<__vector signed int>(x));
> +   else if constexpr (std::is_integral_v && sizeof(T) == sizeof(int))
> + x = static_cast(static_cast<__vector unsigned int>(x));
> +#ifdef __VSX__
> +   else if constexpr (std::is_integral_v && sizeof(T) == sizeof(long
> long)
> +&& std::is_signed_v)
> + x = static_cast(static_cast<__vector signed long long>(x));
> +   else if constexpr (std::is_integral_v && sizeof(T) == sizeof(long
> long))
> + x = static_cast(static_cast<__vector unsigned long long>(x));
> +#endif
> +#elif __ARM_NEON
> +   if constexpr (std::is_same_v)
> + x = static_cast(static_cast(x));
> +#ifdef __aarch64__
> +   else if constexpr (std::is_same_v)
> + x = static_cast(static_cast(x));
> +#endif
> +   else if constexpr (std::is_integral_v && sizeof(T) == 1 &&
> std::is_signed_v)
> + x = static_cast(static_cast(x));
> +   else if constexpr (std::is_integral_v && sizeof(T) == 1)
> + x = static_cast(static_cast(x));
> +   else if constexpr (std::is_integral_v && sizeof(T) == 2 &&
> std::is_signed_v)
> + x 

[PATCH] c++: Copy over DECL_DISREGARD_INLINE_LIMITS flag to inheriting ctors [PR114784]

[Jakub Jelinek]

Hi!

The following testcase is rejected with
error: inlining failed in call to 'always_inline' '...': call is unlikely and 
code size would grow
errors.  The problem is that starting with the r14-2149 change
we try to copy most of the attributes from the inherited to
inheriting ctor, but don't copy associated flags that decl_attributes
sets.

Now, the other clone_attrs user, cp/optimize.cc (maybe_clone_body)
copies over
  DECL_COMDAT (clone) = DECL_COMDAT (fn);
  DECL_WEAK (clone) = DECL_WEAK (fn);
  if (DECL_ONE_ONLY (fn))
cgraph_node::get_create (clone)->set_comdat_group (cxx_comdat_group 
(clone));
  DECL_USE_TEMPLATE (clone) = DECL_USE_TEMPLATE (fn);
  DECL_EXTERNAL (clone) = DECL_EXTERNAL (fn);
  DECL_INTERFACE_KNOWN (clone) = DECL_INTERFACE_KNOWN (fn);
  DECL_NOT_REALLY_EXTERN (clone) = DECL_NOT_REALLY_EXTERN (fn);
  DECL_VISIBILITY (clone) = DECL_VISIBILITY (fn);
  DECL_VISIBILITY_SPECIFIED (clone) = DECL_VISIBILITY_SPECIFIED (fn);
  DECL_DLLIMPORT_P (clone) = DECL_DLLIMPORT_P (fn);
  DECL_DISREGARD_INLINE_LIMITS (clone) = DECL_DISREGARD_INLINE_LIMITS (fn);
The following patch just copies DECL_DISREGARD_INLINE_LIMITS to fix
this exact bug, not really sure which other flags should be copied
and which shouldn't.
Plus there are tons of other flags, some of which might need to be copied
too, some of which might not, perhaps in both places, like:
DECL_UNINLINABLE, maybe DECL_PRESERVE_P, TREE_USED, maybe
DECL_USER_ALIGN/DECL_ALIGN, maybe DECL_WEAK, maybe
DECL_NO_INSTRUMENT_FUNCTION_ENTRY_EXIT, DECL_NO_LIMIT_STACK.
TREE_READONLY, DECL_PURE_P, TREE_THIS_VOLATILE (for const, pure and
noreturn attributes) probably makes no sense, DECL_IS_RETURNS_TWICE neither
(returns_twice ctor?).  What about TREE_NOTHROW?
DECL_FUNCTION_SPECIFIC_OPTIMIZATION, DECL_FUNCTION_SPECIFIC_TARGET...

Anyway, another problem is that if inherited_ctor is a TEMPLATE_DECL, as
also can be seen in the using D::D; case in the testcase, then
DECL_ATTRIBUTES (fn) = clone_attrs (DECL_ATTRIBUTES (inherited_ctor));
attempts to copy the attributes from the TEMPLATE_DECL which doesn't have
them.  The following patch copies them from STRIP_TEMPLATE (inherited_ctor)
which does.  E.g. DECL_DECLARED_CONSTEXPR_P works fine as the macro
itself uses STRIP_TEMPLATE too, but not 100% sure about other macros used
on inherited_ctor earlier.

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

Do you want to copy other flags (and which ones and in which places),
is that ok to be deferred till stage 1? 

2024-04-22  Jakub Jelinek  

PR c++/114784
* method.cc (implicitly_declare_fn): Call clone_attrs
on DECL_ATTRIBUTES on STRIP_TEMPLATE (inherited_ctor) rather than
inherited_ctor.  Also copy DECL_DISREGARD_INLINE_LIMITS flag from it.

* g++.dg/cpp0x/inh-ctor39.C: New test.

--- gcc/cp/method.cc.jj 2024-04-20 00:02:56.702387748 +0200
+++ gcc/cp/method.cc2024-04-22 12:51:36.395722484 +0200
@@ -3307,8 +3307,11 @@ implicitly_declare_fn (special_function_
   /* Copy constexpr from the inherited constructor even if the
 inheriting constructor doesn't satisfy the requirements.  */
   constexpr_p = DECL_DECLARED_CONSTEXPR_P (inherited_ctor);
+  tree inherited_ctor_fn = STRIP_TEMPLATE (inherited_ctor);
   /* Also copy any attributes.  */
-  DECL_ATTRIBUTES (fn) = clone_attrs (DECL_ATTRIBUTES (inherited_ctor));
+  DECL_ATTRIBUTES (fn) = clone_attrs (DECL_ATTRIBUTES (inherited_ctor_fn));
+  DECL_DISREGARD_INLINE_LIMITS (fn)
+   = DECL_DISREGARD_INLINE_LIMITS (inherited_ctor_fn);
 }
 
   /* Add the "this" parameter.  */
--- gcc/testsuite/g++.dg/cpp0x/inh-ctor39.C.jj  2024-04-22 13:02:10.490836357 
+0200
+++ gcc/testsuite/g++.dg/cpp0x/inh-ctor39.C 2024-04-22 13:01:50.088122255 
+0200
@@ -0,0 +1,55 @@
+// PR c++/114784
+// { dg-do compile { target c++11 } }
+// { dg-additional-options "-O2" }
+
+template 
+struct A {
+  [[gnu::always_inline]] A (int t) { foo ().bar (t, {}); }
+  [[gnu::always_inline]] A (long long t) { foo ().bar (t, {}); }
+  T foo ();
+};
+
+struct B : A {
+  using A::A;
+  [[gnu::always_inline]] B (long long v) : A (v) {}
+  template 
+  void bar (T &&, int);
+  char b;
+};
+
+struct C {
+  C (int v) : a(v) { }
+  C (long long v) : a(v) { }
+  B a;
+};
+
+static C
+baz ()
+{
+  C x(0);
+  C y(0LL);
+  return 0;
+}
+
+[[gnu::cold]] int
+qux ()
+{
+  baz ();
+  return 0;
+}
+
+template 
+struct D {
+  template 
+  [[gnu::always_inline]] D (T) { d = sizeof (T); }
+  D();
+  int d;
+};
+template 
+struct E : D {
+  using D::D;
+};
+
+E c = {};
+E d = 1;
+E e = 1.0;

Jakub

[PATCH] c++, v2: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208]

[Jakub Jelinek]

On Wed, Apr 17, 2024 at 09:42:47AM +0200, Jakub Jelinek wrote:
> When expand_or_defer_fn is called at_eof time, it calls import_export_decl
> and then maybe_clone_body, which uses DECL_ONE_ONLY and comdat name in a
> couple of places to try to optimize cdtors which are known to have the
> same body by making the complete cdtor an alias to base cdtor (and in
> that case also uses *[CD]5* as comdat group name instead of the normal
> comdat group names specific to each mangled name).
> Now, this optimization depends on DECL_ONE_ONLY and DECL_INTERFACE_KNOWN,
> maybe_clone_body and can_alias_cdtor use:
>   if (DECL_ONE_ONLY (fn))
> cgraph_node::get_create (clone)->set_comdat_group (cxx_comdat_group 
> (clone));
> ...
>   bool can_alias = can_alias_cdtor (fn);
> ...
>   /* Tell cgraph if both ctors or both dtors are known to have
>  the same body.  */
>   if (can_alias
>   && fns[0]
>   && idx == 1
>   && cgraph_node::get_create (fns[0])->create_same_body_alias
>(clone, fns[0]))
> {
>   alias = true;
>   if (DECL_ONE_ONLY (fns[0]))
> {
>   /* For comdat base and complete cdtors put them
>  into the same, *[CD]5* comdat group instead of
>  *[CD][12]*.  */
>   comdat_group = cdtor_comdat_group (fns[1], fns[0]);
>   cgraph_node::get_create (fns[0])->set_comdat_group 
> (comdat_group);
>   if (symtab_node::get (clone)->same_comdat_group)
> symtab_node::get (clone)->remove_from_same_comdat_group ();
>   symtab_node::get (clone)->add_to_same_comdat_group
> (symtab_node::get (fns[0]));
> }
> }
> and
>   /* Don't use aliases for weak/linkonce definitions unless we can put both
>  symbols in the same COMDAT group.  */
>   return (DECL_INTERFACE_KNOWN (fn)
>   && (SUPPORTS_ONE_ONLY || !DECL_WEAK (fn))
>   && (!DECL_ONE_ONLY (fn)
>   || (HAVE_COMDAT_GROUP && DECL_WEAK (fn;
> The following testcase regressed with Marek's r14-5979 change,
> when pr113208_0.C is compiled where the ctor is marked constexpr,
> we no longer perform this optimization, where
> _ZN6vectorI12QualityValueEC2ERKS1_ was emitted in the
> _ZN6vectorI12QualityValueEC5ERKS1_ comdat group and
> _ZN6vectorI12QualityValueEC1ERKS1_ was made an alias to it,
> instead we emit _ZN6vectorI12QualityValueEC2ERKS1_ in
> _ZN6vectorI12QualityValueEC2ERKS1_ comdat group and the same
> content _ZN6vectorI12QualityValueEC1ERKS1_ as separate symbol in
> _ZN6vectorI12QualityValueEC1ERKS1_ comdat group.
> Now, the linker seems to somehow cope with that, eventhough it
> probably keeps both copies of the ctor, but seems LTO can't cope
> with that and Honza doesn't know what it should do in that case
> (linker decides that the prevailing symbol is
> _ZN6vectorI12QualityValueEC2ERKS1_ (from the
> _ZN6vectorI12QualityValueEC2ERKS1_ comdat group) and
> _ZN6vectorI12QualityValueEC1ERKS1_ alias (from the other TU,
> from _ZN6vectorI12QualityValueEC5ERKS1_ comdat group)).
> 
> Note, the case where some constructor is marked constexpr in one
> TU and not in another one happens pretty often in libstdc++ when
> one mixes -std= flags used to compile different compilation units.
> 
> The reason the optimization doesn't trigger when the constructor is
> constexpr is that expand_or_defer_fn is called in that case much earlier
> than when it is not constexpr; in the former case it is called when we
> try to constant evaluate that constructor.  But DECL_INTERFACE_KNOWN
> is false in that case and comdat_linkage hasn't been called either
> (I think it is desirable, because comdat group is stored in the cgraph
> node and am not sure it is a good idea to create cgraph nodes for
> something that might not be needed later on at all), so maybe_clone_body
> clones the bodies, but doesn't make them as aliases.
> 
> The following patch is an attempt to redo this optimization when
> import_export_decl is called at_eof time on the base/complete cdtor
> (or deleting dtor).  It will not do anything if maybe_clone_body
> hasn't been called uyet (the TREE_ASM_WRITTEN check on the
> DECL_MAYBE_IN_CHARGE_CDTOR_P), or when one or both of the base/complete
> cdtors have been lowered already, or when maybe_clone_body called
> maybe_thunk_body and it was successful.  Otherwise retries the
> can_alias_cdtor check and makes the complete cdtor alias to the
> base cdtor with adjustments to the comdat group.

Here is an updated version of the patch which changes
-  DECL_SAVED_TREE (fns[1]) = NULL_TREE;
+  release_function_body (fns[1]);
as suggested by Honza.

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

2024-04-22  Jakub Jelinek  

PR lto/113208
* cp-tree.h (maybe_optimize_cdtor): Declare.
* decl2.cc (import_export_decl): Call it for cloned cdtors.
* optimize.cc (maybe_optimi

Re: [PATCH] libstdc++: Workaround kernel-headers on s390x-linux

[Jonathan Wakely]

On Mon, 22 Apr 2024 at 16:37, Jakub Jelinek  wrote:
>
> Hi!
>
> We see
> FAIL: 17_intro/headers/c++1998/all_attributes.cc   (test for excess errors)
> FAIL: 17_intro/headers/c++2011/all_attributes.cc   (test for excess errors)
> FAIL: 17_intro/headers/c++2014/all_attributes.cc   (test for excess errors)
> FAIL: 17_intro/headers/c++2017/all_attributes.cc   (test for excess errors)
> FAIL: 17_intro/headers/c++2020/all_attributes.cc   (test for excess errors)
> FAIL: 17_intro/names.cc  -std=gnu++17 (test for excess errors)
> on s390x-linux.
> The first 5 are due to kernel-headers not using uglified attribute names,
> where  contains
> __attribute__((packed, aligned(4)))
> I've filed a downstream bugreport for this in
> https://bugzilla.redhat.com/show_bug.cgi?id=2276084
> (not really sure where to report kernel-headers issues upstream), while the
> last one is due to  from glibc containing:
>   #ifdef __USE_MISC
>   # define __ctx(fld) fld
>   #else
>   # define __ctx(fld) __ ## fld
>   #endif
>   ...
>   typedef union
> {
>   double  __ctx(d);
>   float   __ctx(f);
> } fpreg_t;
> and g++ predefining -D_GNU_SOURCE which implies define __USE_MISC.
>
> The following patch adds a workaround for this on the libstdc++ testsuite
> side, ok for trunk?

OK, thanks.


>
> 2024-04-22  Jakub Jelinek  
>
> * testsuite/17_intro/names.cc (d, f): Undefine on s390*-linux*.
> * testsuite/17_intro/headers/c++1998/all_attributes.cc (packed): Don't
> define on s390.
> * testsuite/17_intro/headers/c++2011/all_attributes.cc (packed):
> Likewise.
> * testsuite/17_intro/headers/c++2014/all_attributes.cc (packed):
> Likewise.
> * testsuite/17_intro/headers/c++2017/all_attributes.cc (packed):
> Likewise.
> * testsuite/17_intro/headers/c++2020/all_attributes.cc (packed):
> Likewise.
>
> --- libstdc++-v3/testsuite/17_intro/names.cc.jj 2024-02-02 22:13:29.575359165 
> +0100
> +++ libstdc++-v3/testsuite/17_intro/names.cc2024-04-22 16:54:35.696710752 
> +0200
> @@ -270,6 +270,12 @@
>  #undef u
>  #endif
>
> +#if defined (__linux__) && defined (__s390__)
> +//  defines fpreg_t::d and fpreg_t::f
> +#undef d
> +#undef f
> +#endif
> +
>  #if defined (__linux__) && defined (__sparc__)
>  #undef y
>  #endif
> --- libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc.jj  
>   2024-01-03 12:08:09.603789437 +0100
> +++ libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc   
> 2024-04-22 17:11:04.734990469 +0200
> @@ -29,7 +29,11 @@
>  # define noreturn 1
>  # define visibility 1
>  #endif
> +#ifndef __s390__
> +// kernel-headers  uses __attribute__((packed,aligned(4))) on
> +// S390.
>  #define packed 1
> +#endif
>  #define pure 1
>  // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
>  #ifndef __arm__
> --- libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc.jj  
>   2024-04-22 17:11:20.028805205 +0200
> +++ libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc   
> 2024-04-22 17:12:01.531302456 +0200
> @@ -29,7 +29,11 @@
>  # define visibility 1
>  #endif
>  #define no_unique_address 1
> +#ifndef __s390__
> +// kernel-headers  uses __attribute__((packed,aligned(4))) on
> +// S390.
>  #define packed 1
> +#endif
>  #define pure 1
>  // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
>  #ifndef __arm__
> --- libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc.jj  
>   2024-01-03 12:08:09.556790095 +0100
> +++ libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc   
> 2024-04-22 17:12:20.630071099 +0200
> @@ -29,7 +29,11 @@
>  # define visibility 1
>  #endif
>  #define no_unique_address 1
> +#ifndef __s390__
> +// kernel-headers  uses __attribute__((packed,aligned(4))) on
> +// S390.
>  #define packed 1
> +#endif
>  #define pure 1
>  // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
>  #ifndef __arm__
> --- libstdc++-v3/testsuite/17_intro/headers/c++2017/all_attributes.cc.jj  
>   2024-01-03 12:08:09.506790795 +0100
> +++ libstdc++-v3/testsuite/17_intro/headers/c++2017/all_attributes.cc   
> 2024-04-22 17:12:38.751851577 +0200
> @@ -28,7 +28,11 @@
>  # define visibility 1
>  #endif
>  #define no_unique_address 1
> +#ifndef __s390__
> +// kernel-headers  uses __attribute__((packed,aligned(4))) on
> +// S390.
>  #define packed 1
> +#endif
>  #define pure 1
>  // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
>  #ifndef __arm__
> --- libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc.jj  
>   2024-01-03 12:08:09.502790851 +0100
> +++ libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc   
> 2024-04-22 17:12:56.043642110 +0200
> @@ -27,7 +27,11 @@
>  # define cold 1
>  # define visibility 1
>  #endif
> +#ifndef __s390__
> +// kernel-headers  uses __attribute__((packed,aligned(4))) on
> +// S390.
>  #define packed 1
> +#endif
>  #define pure 

Re: [PATCH] Add rvalue::get_name method (and its C equivalent)

[Antoni Boucher]

For your new API endpoint, please add a check like:

  RETURN_IF_FAIL (lvalue->is_global () || lvalue->is_local (),
  NULL,
  NULL,
  "lvalue should be a variable");


Le 2024-04-22 à 09 h 16, Guillaume Gomez a écrit :

Good point!

New patch attached.

Le lun. 22 avr. 2024 à 15:13, Antoni Boucher  a écrit :


Please move the function to be on lvalue since there are no rvalue types
that are not lvalues that have a name.

Le 2024-04-22 à 09 h 04, Guillaume Gomez a écrit :

Hey Arthur :)


Is there any reason for that getter to return a mutable pointer to the
name? Would something like this work instead if you're just looking at
getting the name?

+  virtual string * get_name () const { return NULL; }

With of course adequate modifications to the inheriting classes.


Good catch, thanks!

Updated the patch and attached the new version to this email.

Cordially.

Le lun. 22 avr. 2024 à 11:51, Arthur Cohen  a écrit :


Hey Guillaume :)

On 4/20/24 01:05, Guillaume Gomez wrote:

Hi,

I just encountered the need to retrieve the name of an `rvalue` (if
there is one) while working on the Rust GCC backend.

This patch adds a getter to retrieve the information.

Cordially.



 virtual bool get_wide_int (wide_int *) const { return false; }

+  virtual string * get_name () { return NULL; }
+
   private:
 virtual enum precedence get_precedence () const = 0;


Is there any reason for that getter to return a mutable pointer to the
name? Would something like this work instead if you're just looking at
getting the name?

+  virtual string * get_name () const { return NULL; }

With of course adequate modifications to the inheriting classes.

Best,

Arthur

Re: [PATCH] Add rvalue::get_name method (and its C equivalent)

[Antoni Boucher]

I believe you forgot to regenerate the ChangeLog.

Le 2024-04-22 à 09 h 16, Guillaume Gomez a écrit :

Good point!

New patch attached.

Le lun. 22 avr. 2024 à 15:13, Antoni Boucher  a écrit :


Please move the function to be on lvalue since there are no rvalue types
that are not lvalues that have a name.

Le 2024-04-22 à 09 h 04, Guillaume Gomez a écrit :

Hey Arthur :)


Is there any reason for that getter to return a mutable pointer to the
name? Would something like this work instead if you're just looking at
getting the name?

+  virtual string * get_name () const { return NULL; }

With of course adequate modifications to the inheriting classes.


Good catch, thanks!

Updated the patch and attached the new version to this email.

Cordially.

Le lun. 22 avr. 2024 à 11:51, Arthur Cohen  a écrit :


Hey Guillaume :)

On 4/20/24 01:05, Guillaume Gomez wrote:

Hi,

I just encountered the need to retrieve the name of an `rvalue` (if
there is one) while working on the Rust GCC backend.

This patch adds a getter to retrieve the information.

Cordially.



 virtual bool get_wide_int (wide_int *) const { return false; }

+  virtual string * get_name () { return NULL; }
+
   private:
 virtual enum precedence get_precedence () const = 0;


Is there any reason for that getter to return a mutable pointer to the
name? Would something like this work instead if you're just looking at
getting the name?

+  virtual string * get_name () const { return NULL; }

With of course adequate modifications to the inheriting classes.

Best,

Arthur

[PATCH] libstdc++: Workaround kernel-headers on s390x-linux

[Jakub Jelinek]

Hi!

We see
FAIL: 17_intro/headers/c++1998/all_attributes.cc   (test for excess errors)
FAIL: 17_intro/headers/c++2011/all_attributes.cc   (test for excess errors)
FAIL: 17_intro/headers/c++2014/all_attributes.cc   (test for excess errors)
FAIL: 17_intro/headers/c++2017/all_attributes.cc   (test for excess errors)
FAIL: 17_intro/headers/c++2020/all_attributes.cc   (test for excess errors)
FAIL: 17_intro/names.cc  -std=gnu++17 (test for excess errors)
on s390x-linux.
The first 5 are due to kernel-headers not using uglified attribute names,
where  contains
__attribute__((packed, aligned(4)))
I've filed a downstream bugreport for this in
https://bugzilla.redhat.com/show_bug.cgi?id=2276084
(not really sure where to report kernel-headers issues upstream), while the
last one is due to  from glibc containing:
  #ifdef __USE_MISC
  # define __ctx(fld) fld
  #else
  # define __ctx(fld) __ ## fld
  #endif
  ...
  typedef union
{
  double  __ctx(d);
  float   __ctx(f);
} fpreg_t;
and g++ predefining -D_GNU_SOURCE which implies define __USE_MISC.

The following patch adds a workaround for this on the libstdc++ testsuite
side, ok for trunk?

2024-04-22  Jakub Jelinek  

* testsuite/17_intro/names.cc (d, f): Undefine on s390*-linux*.
* testsuite/17_intro/headers/c++1998/all_attributes.cc (packed): Don't
define on s390.
* testsuite/17_intro/headers/c++2011/all_attributes.cc (packed):
Likewise.
* testsuite/17_intro/headers/c++2014/all_attributes.cc (packed):
Likewise.
* testsuite/17_intro/headers/c++2017/all_attributes.cc (packed):
Likewise.
* testsuite/17_intro/headers/c++2020/all_attributes.cc (packed):
Likewise.

--- libstdc++-v3/testsuite/17_intro/names.cc.jj 2024-02-02 22:13:29.575359165 
+0100
+++ libstdc++-v3/testsuite/17_intro/names.cc2024-04-22 16:54:35.696710752 
+0200
@@ -270,6 +270,12 @@
 #undef u
 #endif
 
+#if defined (__linux__) && defined (__s390__)
+//  defines fpreg_t::d and fpreg_t::f
+#undef d
+#undef f
+#endif
+
 #if defined (__linux__) && defined (__sparc__)
 #undef y
 #endif
--- libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc.jj
2024-01-03 12:08:09.603789437 +0100
+++ libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc   
2024-04-22 17:11:04.734990469 +0200
@@ -29,7 +29,11 @@
 # define noreturn 1
 # define visibility 1
 #endif
+#ifndef __s390__
+// kernel-headers  uses __attribute__((packed,aligned(4))) on
+// S390.
 #define packed 1
+#endif
 #define pure 1
 // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
 #ifndef __arm__
--- libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc.jj
2024-04-22 17:11:20.028805205 +0200
+++ libstdc++-v3/testsuite/17_intro/headers/c++2011/all_attributes.cc   
2024-04-22 17:12:01.531302456 +0200
@@ -29,7 +29,11 @@
 # define visibility 1
 #endif
 #define no_unique_address 1
+#ifndef __s390__
+// kernel-headers  uses __attribute__((packed,aligned(4))) on
+// S390.
 #define packed 1
+#endif
 #define pure 1
 // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
 #ifndef __arm__
--- libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc.jj
2024-01-03 12:08:09.556790095 +0100
+++ libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc   
2024-04-22 17:12:20.630071099 +0200
@@ -29,7 +29,11 @@
 # define visibility 1
 #endif
 #define no_unique_address 1
+#ifndef __s390__
+// kernel-headers  uses __attribute__((packed,aligned(4))) on
+// S390.
 #define packed 1
+#endif
 #define pure 1
 // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
 #ifndef __arm__
--- libstdc++-v3/testsuite/17_intro/headers/c++2017/all_attributes.cc.jj
2024-01-03 12:08:09.506790795 +0100
+++ libstdc++-v3/testsuite/17_intro/headers/c++2017/all_attributes.cc   
2024-04-22 17:12:38.751851577 +0200
@@ -28,7 +28,11 @@
 # define visibility 1
 #endif
 #define no_unique_address 1
+#ifndef __s390__
+// kernel-headers  uses __attribute__((packed,aligned(4))) on
+// S390.
 #define packed 1
+#endif
 #define pure 1
 // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
 #ifndef __arm__
--- libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc.jj
2024-01-03 12:08:09.502790851 +0100
+++ libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc   
2024-04-22 17:12:56.043642110 +0200
@@ -27,7 +27,11 @@
 # define cold 1
 # define visibility 1
 #endif
+#ifndef __s390__
+// kernel-headers  uses __attribute__((packed,aligned(4))) on
+// S390.
 #define packed 1
+#endif
 #define pure 1
 // glibc's sysdeps/unix/sysv/linux/arm/sys/ucontext.h uses this on ARM.
 #ifndef __arm__

Jakub

[PATCH] libstdc++: Fix conversion of simd to vector builtin

[Matthias Kretz]

Tested on x86_64-linux-gnu, powerpc64le-linux-gnu, aarch64-linux-gnu, arm-
linux-gnueabihf

OK for trunk and backports?

- 8< -

Signed-off-by: Matthias Kretz 

libstdc++-v3/ChangeLog:

PR libstdc++/114803
* include/experimental/bits/simd_builtin.h
(_SimdBase2::operator __vector_type_t): There is no __builtin()
function in _SimdWrapper, instead use its conversion operator.
* testsuite/experimental/simd/pr114803_vecbuiltin_cvt.cc: New
test.
---
 .../include/experimental/bits/simd_builtin.h  |   2 +-
 .../simd/pr114803_vecbuiltin_cvt.cc   | 105 ++
 2 files changed, 106 insertions(+), 1 deletion(-)
 create mode 100644 libstdc++-v3/testsuite/experimental/simd/
pr114803_vecbuiltin_cvt.cc

diff --git a/libstdc++-v3/include/experimental/bits/simd_builtin.h b/libstdc+
+-v3/include/experimental/bits/simd_builtin.h
index 49c7c7e1c70..4ceeb423894 100644
--- a/libstdc++-v3/include/experimental/bits/simd_builtin.h
+++ b/libstdc++-v3/include/experimental/bits/simd_builtin.h
@@ -841,7 +841,7 @@ struct _SimdBase2
 
   _GLIBCXX_SIMD_ALWAYS_INLINE explicit
   operator __vector_type_t<_Tp, _Np>() const
-  { return static_cast*>(this)-
>_M_data.__builtin(); }
+  { return __data(*static_cast*>(this)); }
 };
 
 struct _SimdBase1
diff --git a/libstdc++-v3/testsuite/experimental/simd/
pr114803_vecbuiltin_cvt.cc b/libstdc++-v3/testsuite/experimental/simd/
pr114803_vecbuiltin_cvt.cc
new file mode 100644
index 000..103dd19394c
--- /dev/null
+++ b/libstdc++-v3/testsuite/experimental/simd/pr114803_vecbuiltin_cvt.cc
@@ -0,0 +1,105 @@
+// { dg-options "-std=gnu++17" }
+// { dg-do compile { target c++17 } }
+
+#include 
+
+template 
+  void
+  maybe_test()
+  {
+using V = std::experimental::simd>;
+if constexpr (std::is_destructible_v)
+  {
+   using V2 [[gnu::vector_size(16)]] = T;
+   V x = {};
+   V2 x2 = static_cast(x);
+   x = static_cast(x2);
+   for (unsigned i = 0; i < V::size(); ++i)
+ {
+   if (x2[i] != 0)
+ __builtin_abort();
+ }
+#ifdef __SSE__
+   if constexpr (std::is_same_v)
+ x = static_cast(static_cast<__m128>(x));
+   else if constexpr (std::is_same_v)
+ x = static_cast(static_cast<__m128d>(x));
+   else if constexpr (std::is_integral_v)
+ x = static_cast(static_cast<__m128i>(x));
+#elif __ALTIVEC__
+   if constexpr (std::is_same_v)
+ x = static_cast(static_cast<__vector float>(x));
+#ifdef __VSX__
+   else if constexpr (std::is_same_v)
+ x = static_cast(static_cast<__vector double>(x));
+#endif
+   else if constexpr (std::is_integral_v && sizeof(T) == 
sizeof(signed char)
+&& std::is_signed_v)
+ x = static_cast(static_cast<__vector signed char>(x));
+   else if constexpr (std::is_integral_v && sizeof(T) == 
sizeof(signed char))
+ x = static_cast(static_cast<__vector unsigned char>(x));
+   else if constexpr (std::is_integral_v && sizeof(T) == 
sizeof(short)
+&& std::is_signed_v)
+ x = static_cast(static_cast<__vector signed short>(x));
+   else if constexpr (std::is_integral_v && sizeof(T) == 
sizeof(short))
+ x = static_cast(static_cast<__vector unsigned short>(x));
+   else if constexpr (std::is_integral_v && sizeof(T) == sizeof(int)
+&& std::is_signed_v)
+ x = static_cast(static_cast<__vector signed int>(x));
+   else if constexpr (std::is_integral_v && sizeof(T) == sizeof(int))
+ x = static_cast(static_cast<__vector unsigned int>(x));
+#ifdef __VSX__
+   else if constexpr (std::is_integral_v && sizeof(T) == sizeof(long 
long)
+&& std::is_signed_v)
+ x = static_cast(static_cast<__vector signed long long>(x));
+   else if constexpr (std::is_integral_v && sizeof(T) == sizeof(long 
long))
+ x = static_cast(static_cast<__vector unsigned long long>(x));
+#endif
+#elif __ARM_NEON
+   if constexpr (std::is_same_v)
+ x = static_cast(static_cast(x));
+#ifdef __aarch64__
+   else if constexpr (std::is_same_v)
+ x = static_cast(static_cast(x));
+#endif
+   else if constexpr (std::is_integral_v && sizeof(T) == 1 && 
std::is_signed_v)
+ x = static_cast(static_cast(x));
+   else if constexpr (std::is_integral_v && sizeof(T) == 1)
+ x = static_cast(static_cast(x));
+   else if constexpr (std::is_integral_v && sizeof(T) == 2 && 
std::is_signed_v)
+ x = static_cast(static_cast(x));
+   else if constexpr (std::is_integral_v && sizeof(T) == 2)
+ x = static_cast(static_cast(x));
+   else if constexpr (std::is_integral_v && sizeof(T) == 4 && 
std::is_signed_v)
+ x = static_cast(static_cast(x));
+   else if constexpr (std::is_integral_v && sizeof(T) == 4)
+

[PATCH] libstdc++: Silence irrelevant warnings in

[Matthias Kretz]

Tested on x86_64-linux-gnu, powerpc64le-linux-gnu, aarch64-linux-gnu, arm-
linux-gnueabihf

OK for trunk and backports?

- 8< -


Avoid
-Wnarrowing in C code;
-Wtautological-compare in unconditional static_assert (necessary for
faking a dependency on a template parameter)

Signed-off-by: Matthias Kretz 

libstdc++-v3/ChangeLog:

* include/experimental/bits/simd.h: Ignore -Wnarrowing for
arm_neon.h.
(__int_for_sizeof): Replace tautological compare with checking
for invalid template parameter value.
* include/experimental/bits/simd_builtin.h (__extract_part):
Remove tautological compare by combining two static_assert.
---
 libstdc++-v3/include/experimental/bits/simd.h | 8 +++-
 libstdc++-v3/include/experimental/bits/simd_builtin.h | 3 +--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/include/experimental/bits/simd.h b/libstdc++-v3/
include/experimental/bits/simd.h
index 03c2e17a326..6ef9c955cfa 100644
--- a/libstdc++-v3/include/experimental/bits/simd.h
+++ b/libstdc++-v3/include/experimental/bits/simd.h
@@ -44,7 +44,12 @@
 #if _GLIBCXX_SIMD_X86INTRIN
 #include 
 #elif _GLIBCXX_SIMD_HAVE_NEON
+#pragma GCC diagnostic push
+// narrowing conversion of '__a' from 'uint64_t' {aka 'long long unsigned 
int'} to
+//   'int64x1_t' {aka 'long long int'} [-Wnarrowing]
+#pragma GCC diagnostic ignored "-Wnarrowing"
 #include 
+#pragma GCC diagnostic pop
 #endif
 #if _GLIBCXX_SIMD_HAVE_SVE
 #include 
@@ -598,6 +603,7 @@ struct __is_bitmask
   constexpr auto
   __int_for_sizeof()
   {
+static_assert(_Bytes > 0);
 if constexpr (_Bytes == sizeof(int))
   return int();
   #ifdef __clang__
@@ -663,7 +669,7 @@ struct _Ip
return _Ip{};
   }
 else
-  static_assert(_Bytes != _Bytes, "this should be unreachable");
+  static_assert(_Bytes == 0, "this should be unreachable");
   }
 #pragma GCC diagnostic pop
 
diff --git a/libstdc++-v3/include/experimental/bits/simd_builtin.h b/libstdc+
+-v3/include/experimental/bits/simd_builtin.h
index af0c4886108..49c7c7e1c70 100644
--- a/libstdc++-v3/include/experimental/bits/simd_builtin.h
+++ b/libstdc++-v3/include/experimental/bits/simd_builtin.h
@@ -278,8 +278,7 @@ __extract_part(const _SimdWrapper<_Tp, _Np> __x)
   __extract_part(const _SimdWrapper __x)
   {
 static_assert(_Combine == 1, "_Combine != 1 not implemented");
-static_assert(__have_avx512f && _Np == _Np);
-static_assert(_Total >= 2 && _Index + _Combine <= _Total && _Index >= 0);
+static_assert(__have_avx512f && _Total >= 2 && _Index + _Combine <= 
_Total && _Index >= 0);
 return __x._M_data >> (_Index * _Np / _Total);
   }
 
-- 
──
 Dr. Matthias Kretz   https://mattkretz.github.io
 GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
 stdₓ::simd
──



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

Re: [PATCH] Add rvalue::get_name method (and its C equivalent)

[Antoni Boucher]

Please move the function to be on lvalue since there are no rvalue types 
that are not lvalues that have a name.


Le 2024-04-22 à 09 h 04, Guillaume Gomez a écrit :

Hey Arthur :)


Is there any reason for that getter to return a mutable pointer to the
name? Would something like this work instead if you're just looking at
getting the name?

+  virtual string * get_name () const { return NULL; }

With of course adequate modifications to the inheriting classes.


Good catch, thanks!

Updated the patch and attached the new version to this email.

Cordially.

Le lun. 22 avr. 2024 à 11:51, Arthur Cohen  a écrit :


Hey Guillaume :)

On 4/20/24 01:05, Guillaume Gomez wrote:

Hi,

I just encountered the need to retrieve the name of an `rvalue` (if
there is one) while working on the Rust GCC backend.

This patch adds a getter to retrieve the information.

Cordially.



virtual bool get_wide_int (wide_int *) const { return false; }

+  virtual string * get_name () { return NULL; }
+
  private:
virtual enum precedence get_precedence () const = 0;


Is there any reason for that getter to return a mutable pointer to the
name? Would something like this work instead if you're just looking at
getting the name?

+  virtual string * get_name () const { return NULL; }

With of course adequate modifications to the inheriting classes.

Best,

Arthur

Re: [PATCH] Add rvalue::get_name method (and its C equivalent)

[Guillaume Gomez]

Hey Arthur :)

> Is there any reason for that getter to return a mutable pointer to the
> name? Would something like this work instead if you're just looking at
> getting the name?
>
> +  virtual string * get_name () const { return NULL; }
>
> With of course adequate modifications to the inheriting classes.

Good catch, thanks!

Updated the patch and attached the new version to this email.

Cordially.

Le lun. 22 avr. 2024 à 11:51, Arthur Cohen  a écrit :
>
> Hey Guillaume :)
>
> On 4/20/24 01:05, Guillaume Gomez wrote:
> > Hi,
> >
> > I just encountered the need to retrieve the name of an `rvalue` (if
> > there is one) while working on the Rust GCC backend.
> >
> > This patch adds a getter to retrieve the information.
> >
> > Cordially.
>
> >virtual bool get_wide_int (wide_int *) const { return false; }
> >
> > +  virtual string * get_name () { return NULL; }
> > +
> >  private:
> >virtual enum precedence get_precedence () const = 0;
>
> Is there any reason for that getter to return a mutable pointer to the
> name? Would something like this work instead if you're just looking at
> getting the name?
>
> +  virtual string * get_name () const { return NULL; }
>
> With of course adequate modifications to the inheriting classes.
>
> Best,
>
> Arthur
From a8ae68e337bec3e55a60997c5325e2270fd75962 Mon Sep 17 00:00:00 2001
From: Guillaume Gomez 
Date: Sat, 20 Apr 2024 01:02:20 +0200
Subject: [PATCH] [PATCH] Add rvalue::get_name method

gcc/jit/ChangeLog:

	* jit-recording.h: Add rvalue::get_name method
	* libgccjit.cc (gcc_jit_rvalue_get_name): Likewise
	* libgccjit.h (gcc_jit_rvalue_get_name): Likewise
	* libgccjit.map: Likewise

gcc/testsuite/ChangeLog:

	* jit.dg/test-tls.c: Add test for gcc_jit_rvalue_get_name
---
 gcc/jit/jit-recording.h |  8 
 gcc/jit/libgccjit.cc| 16 
 gcc/jit/libgccjit.h |  4 
 gcc/jit/libgccjit.map   |  5 +
 gcc/testsuite/jit.dg/test-tls.c |  3 +++
 5 files changed, 36 insertions(+)

diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
index d8d16f4fe29..2190b68 100644
--- a/gcc/jit/jit-recording.h
+++ b/gcc/jit/jit-recording.h
@@ -1213,6 +1213,8 @@ public:
   virtual bool is_constant () const { return false; }
   virtual bool get_wide_int (wide_int *) const { return false; }
 
+  virtual string * get_name () const { return NULL; }
+
 private:
   virtual enum precedence get_precedence () const = 0;
 
@@ -1305,6 +1307,8 @@ public:
   const char *access_as_rvalue (reproducer &r) final override;
   const char *access_as_lvalue (reproducer &r) final override;
 
+  string * get_name () const final override { return m_name; }
+
 private:
   string * make_debug_string () final override { return m_name; }
   void write_reproducer (reproducer &r) final override;
@@ -1558,6 +1562,8 @@ public:
 
   void set_rvalue_init (rvalue *val) { m_rvalue_init = val; }
 
+  string * get_name () const final override { return m_name; }
+
 private:
   string * make_debug_string () final override { return m_name; }
   template 
@@ -2148,6 +2154,8 @@ public:
 
   void write_to_dump (dump &d) final override;
 
+  string * get_name () const final override { return m_name; }
+
 private:
   string * make_debug_string () final override { return m_name; }
   void write_reproducer (reproducer &r) final override;
diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
index 445c0d0e0e3..2b8706dc7fd 100644
--- a/gcc/jit/libgccjit.cc
+++ b/gcc/jit/libgccjit.cc
@@ -4377,3 +4377,19 @@ gcc_jit_context_add_top_level_asm (gcc_jit_context *ctxt,
   RETURN_IF_FAIL (asm_stmts, ctxt, NULL, "NULL asm_stmts");
   ctxt->add_top_level_asm (loc, asm_stmts);
 }
+
+/* Public entrypoint.  See description in libgccjit.h.
+
+   After error-checking, this calls the trivial
+   gcc::jit::recording::rvalue::get_name method, in jit-recording.h.  */
+
+extern const char *
+gcc_jit_rvalue_get_name (gcc_jit_rvalue *rvalue)
+{
+  RETURN_NULL_IF_FAIL (rvalue, NULL, NULL, "NULL rvalue");
+  auto name = rvalue->get_name ();
+
+  if (!name)
+return NULL;
+  return name->c_str ();
+}
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index 74e847b2dec..d4094610a16 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -2066,6 +2066,10 @@ gcc_jit_lvalue_add_string_attribute (gcc_jit_lvalue *variable,
  enum gcc_jit_variable_attribute attribute,
  const char* value);
 
+/* Returns the name of the `rvalue`, if any. Returns NULL otherwise.  */
+extern const char *
+gcc_jit_rvalue_get_name (gcc_jit_rvalue *rvalue);
+
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
diff --git a/gcc/jit/libgccjit.map b/gcc/jit/libgccjit.map
index 99aa5970be1..bbed8024263 100644
--- a/gcc/jit/libgccjit.map
+++ b/gcc/jit/libgccjit.map
@@ -289,3 +289,8 @@ LIBGCCJIT_ABI_27 {
   global:
 gcc_jit_context_new_sizeof;
 } LIBGCCJIT_ABI_26;
+
+LIBGCCJIT_ABI_28 {
+  global:
+gcc_jit_rvalue_get_name;
+} LIBGCCJIT_ABI_27;
diff --git a/gcc/testsuite/jit.dg/test-

Re: [PATCH][wwwdocs] Improve grammar for AVR changes in GCC 14

[Georg-Johann Lay]

Am 22.04.24 um 12:04 schrieb Jonathan Wakely:

OK for wwwdocs?


For me it's ok (I am not a native speaker though,
which is the reason the typos are there to begin with).

Johann


  htdocs/gcc-14/changes.html | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 9509487c..21d33db8 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -696,13 +696,13 @@ a work-in-progress.
  AVR
  
On AVR64* and AVR128* devices, read-only data is now located in program
-memory per default and no more in RAM.
+memory per default and no longer in RAM.
  
Only a 32 KiB block of program memory can be used to store
and access .rodata in that way. Which block is used can be selected
-   by defining symbol __flmap.
+   by defining the symbol __flmap.
As an alternative, the byte address of the block can be specified
-   by symbol __RODATA_FLASH_START__ which takes
+   by the symbol __RODATA_FLASH_START__ which takes
precedence over __flmap.
For example, linking with
-Wl,--defsym,__RODATA_FLASH_START__=32k
@@ -715,9 +715,9 @@ a work-in-progress.
href="https://github.com/avrdudes/avr-libc/issues/931";>#931
can be used. The latter initializes NVMCTRL_CTRLB.FLMAP
in the startup code and according to the value
-   of __flmap resp.
+   of __flmap or
__RODATA_FLASH_START__.
-  When AVR-LibC with #931 is used, then defining symbol
+  When AVR-LibC with #931 is used, then defining the symbol
__flmap_lock to a non-zero value will set bit
NVMCTRL_CTRLB.FLMAPLOCK. This will protect
NVMCTRL_CTRLB.FLMAP from any further changes —
@@ -726,7 +726,7 @@ a work-in-progress.
can be used:
  __asm (".global __flmap_lock"  "\n\t"
 "__flmap_lock = 1");
-  When you do not want the code from #931, then define global
+  When you do not want the code from #931, then define a global
symbol __do_flmap_init and the linker will not pull in
that code from libmcu.a any more.
In order to return to the old placement of read-only data in RAM,
@@ -736,7 +736,7 @@ __asm (".global __flmap_lock"  "\n\t"
  functionality.

Read-only data is located in output section .rodata,
-   wheras it is part of .text when located in RAM.
+   whereas it is part of .text when located in RAM.
The feature is only available when the compiler is configured
with a version of Binutils that implements
https://sourceware.org/PR31124";>PR31124, which is the
@@ -784,7 +784,7 @@ __asm (".global __flmap_lock"  "\n\t"

  On the Reduced Tiny devices,
  the meaning of register constraint "w" has been changed.
-It containts now the registers R24…R31 like it is the case for all
+It now constrains the registers R24…R31 as is the case for all
  the other devices.

  

[PATCH] s390: testsuite: Xfail forwprop-4{0,1}.c

[Stefan Schulze Frielinghaus]

Hi Andreas,

Ok then I will proceed with the patch as is.  Opened PR114802.

Cheers,
Stefan

--

The tests fail on s390 since can_vec_perm_const_p fails and therefore
the bit insert/ref survive which r14-3381-g27de9aa152141e aims for.
Strictly speaking, the tests only fail in case the target supports
vectors, i.e., for targets prior z13 or in case of -mesa the emulated
vector operations are optimized out.

Set to xfail and tracked by PR114802.
---
 gcc/testsuite/gcc.dg/tree-ssa/forwprop-40.c |  4 ++--
 gcc/testsuite/gcc.dg/tree-ssa/forwprop-41.c |  4 ++--
 gcc/testsuite/lib/target-supports.exp   | 14 ++
 3 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-40.c 
b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-40.c
index 7513497f552..0c5233a68f4 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-40.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-40.c
@@ -10,5 +10,5 @@ vector int g(vector int a)
   return a;
 }
 
-/* { dg-final { scan-tree-dump-times "BIT_INSERT_EXPR" 0 "optimized" } } */
-/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 0 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "BIT_INSERT_EXPR" 0 "optimized" { xfail 
s390_mvx } } } Xfail: PR114802 */
+/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 0 "optimized" { xfail 
s390_mvx } } } Xfail: PR114802 */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-41.c 
b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-41.c
index b1e75797a90..a1f08289dd6 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-41.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-41.c
@@ -11,6 +11,6 @@ vector int g(vector int a, int c)
   return a;
 }
 
-/* { dg-final { scan-tree-dump-times "BIT_INSERT_EXPR" 1 "optimized" } } */
-/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 0 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "BIT_INSERT_EXPR" 1 "optimized" { xfail 
s390_mvx } } } Xfail PR114802 */
+/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 0 "optimized" { xfail 
s390_mvx } } } Xfail PR114802 */
 /* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR" 0 "optimized" } } */
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 3a5713d9869..3a55b2a4159 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -12392,6 +12392,20 @@ proc check_effective_target_profile_update_atomic {} {
 } "-fprofile-update=atomic -fprofile-generate"]
 }
 
+# Return 1 if the target has a vector facility.
+proc check_effective_target_s390_mvx { } {
+if ![istarget s390*-*-*] then {
+   return 0;
+}
+
+return [check_no_compiler_messages_nocache s390_mvx assembly {
+   #if !defined __VX__
+   #error no vector facility.
+   #endif
+   int dummy;
+} [current_compiler_flags]]
+}
+
 # Return 1 if vector (va - vector add) instructions are understood by
 # the assembler and can be executed.  This also covers checking for
 # the VX kernel feature.  A kernel without that feature does not
-- 
2.44.0

[PATCH v2] [testsuite] [powerpc] adjust -m32 counts for fold-vec-extract*

[Alexandre Oliva]

Ping?-ish
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619678.html

It's that time of the year again.  The good news is that this is the
last patch in my ppc*-vxworks7* set ;-)

On May 25, 2023, Segher Boessenkool  wrote:

> On Thu, May 25, 2023 at 10:55:37AM -0300, Alexandre Oliva wrote:
>> I've actually identified the corresponding change to the
>> lp64 tests, compared the effects of the codegen changes, and concluded
>> the tests needed this changing for ilp32 to keep on testing for the same
>> thing after code changes brought about by changes that AFAICT had been
>> well understood when making the lp64 adjustments.

>> /* -m32 target has an 'add' in place of one of the 'addi'. */
>> -/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 2 { target lp64 } } 
>> } */
>> -/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 3 { target ilp32 } 
>> } } */
>> +/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 2 } } */

> Just {\madd} or more conservative {\maddi?\M} then?

I've made these changes in the v2 below.

Codegen changes caused add instruction count mismatches on
ppc-*-linux-gnu and other 32-bit ppc targets.  At some point the
expected counts were adjusted for lp64, but ilp32 differences
remained, and published test results confirm it.

Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu.  Also tested with
gcc-13 on ppc64-vx7r2 and ppc-vx7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

PR testsuite/101169
* gcc.target/powerpc/fold-vec-extract-double.p7.c: Adjust addi
counts for ilp32.
* gcc.target/powerpc/fold-vec-extract-float.p7.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-float.p8.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-int.p7.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-int.p8.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-short.p7.c: Likewise.
* gcc.target/powerpc/fold-vec-extract-short.p8.c: Likewise.
---
 .../powerpc/fold-vec-extract-double.p7.c   |5 ++---
 .../gcc.target/powerpc/fold-vec-extract-float.p7.c |5 ++---
 .../gcc.target/powerpc/fold-vec-extract-float.p8.c |2 +-
 .../gcc.target/powerpc/fold-vec-extract-int.p7.c   |3 +--
 .../gcc.target/powerpc/fold-vec-extract-int.p8.c   |2 +-
 .../gcc.target/powerpc/fold-vec-extract-short.p7.c |3 +--
 .../gcc.target/powerpc/fold-vec-extract-short.p8.c |2 +-
 7 files changed, 9 insertions(+), 13 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-double.p7.c 
b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-double.p7.c
index 3cae644b90b71..e69d9253e2d28 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-double.p7.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-double.p7.c
@@ -13,12 +13,11 @@
 /* { dg-final { scan-assembler-times {\mxxpermdi\M} 1 } } */
 /* { dg-final { scan-assembler-times {\mli\M} 1 } } */
 /* -m32 target has an 'add' in place of one of the 'addi'. */
-/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 2 { target lp64 } } } 
*/
-/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 3 { target ilp32 } } } 
*/
+/* { dg-final { scan-assembler-times {\maddi?\M} 2 } } */
 /* -m32 target has a rlwinm in place of a rldic .  */
 /* { dg-final { scan-assembler-times {\mrldic\M|\mrlwinm\M} 1 } } */
 /* { dg-final { scan-assembler-times {\mstxvd2x\M} 1 } } */
-/* { dg-final { scan-assembler-times {\mlfdx\M|\mlfd\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mlfdx?\M} 1 } } */
 
 #include 
 
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p7.c 
b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p7.c
index 59a4979457dcb..9ff197a704906 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p7.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p7.c
@@ -12,13 +12,12 @@
 /* { dg-final { scan-assembler-times {\mxscvspdp\M} 1 } } */
 /* { dg-final { scan-assembler-times {\mli\M} 1 } } */
 /* -m32 as an add in place of an addi. */
-/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 2 { target lp64 } } } 
*/
-/* { dg-final { scan-assembler-times {\maddi\M|\madd\M} 3 { target ilp32 } } } 
*/
+/* { dg-final { scan-assembler-times {\maddi?\M} 2 } } */
 /* { dg-final { scan-assembler-times {\mstxvd2x\M|\mstvx\M|\mstxv\M} 1 } } */
 /* -m32 uses rlwinm in place of rldic */
 /* { dg-final { scan-assembler-times {\mrldic\M|\mrlwinm\M} 1 } } */
 /* -m32 has lfs in place of lfsx */
-/* { dg-final { scan-assembler-times {\mlfsx\M|\mlfs\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mlfsx?\M} 1 } } */
 
 #include 
 
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p8.c 
b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p8.c
index ce4e43c1fb462..cd80c5e1b19c6 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p8.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-float.p8.c
@@ -26,7 +26,7 @@
 /* { dg-final { scan-assembler-times {\m

[PATCH] decay vect tests from run to link for pr95401

[Alexandre Oliva]

Ping?-ish for the full version of the RFC posted at
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566588.html

On Mar 11, 2021, Richard Biener  wrote:

> On Thu, Mar 11, 2021 at 9:03 AM Alexandre Oliva  wrote:

>> So I'm leaning towards this proposed change, just extended to other
>> platforms that also decay from run to compile rather than link, and thus
>> run into this problem in g++.dg/vect/pr95401.cc.  Would this be
>> acceptable?

> I think that's OK.  It's probably difficult to make the test UNSUPPORTED
> when dg-additional-sources is discovered with a dg-do compile test?

Thanks, here's a completed version.


When vect.exp finds our configuration disables altivec by default, it
disables the execution of vectorization tests, assuming the test
hardware doesn't support it.

Tests become just compile tests, but compile tests won't work
correctly when additional sources are named, e.g. pr95401.cc, because
GCC refuses to compile multiple files into the same asm output.

With this patch, the default for when execution is not possible
becomes link.

Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu.  Also tested with
gcc-13 on ppc64-vx7r2 and ppc-vx7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

* lib/target-supports.exp (check_vect_support_and_set_flags):
Decay to link rather than compile.
---
 gcc/testsuite/lib/target-supports.exp |   18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 3a5713d98691f..54a55585371b0 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -11625,7 +11625,7 @@ proc check_vect_support_and_set_flags { } {
 if [check_750cl_hw_available] {
 set dg-do-what-default run
 } else {
-set dg-do-what-default compile
+set dg-do-what-default link
 }
 } elseif [istarget powerpc*-*-*] {
 # Skip targets not supporting -maltivec.
@@ -11655,14 +11655,14 @@ proc check_vect_support_and_set_flags { } {
 # some other cpu type specified above.
set DEFAULT_VECTCFLAGS [linsert $DEFAULT_VECTCFLAGS 0 
"-mcpu=970"]
 }
-set dg-do-what-default compile
+set dg-do-what-default link
 }
 } elseif { [istarget i?86-*-*] || [istarget x86_64-*-*] } {
 lappend DEFAULT_VECTCFLAGS "-msse2"
 if { [check_effective_target_sse2_runtime] } {
 set dg-do-what-default run
 } else {
-set dg-do-what-default compile
+set dg-do-what-default link
 }
 } elseif { [istarget mips*-*-*]
   && [check_effective_target_nomips16] } {
@@ -11681,7 +11681,7 @@ proc check_vect_support_and_set_flags { } {
 if [check_effective_target_ultrasparc_hw] {
 set dg-do-what-default run
 } else {
-set dg-do-what-default compile
+set dg-do-what-default link
 }
 } elseif [istarget alpha*-*-*] {
 # Alpha's vectorization capabilities are extremely limited.
@@ -11694,7 +11694,7 @@ proc check_vect_support_and_set_flags { } {
 if [check_alpha_max_hw_available] {
 set dg-do-what-default run
 } else {
-set dg-do-what-default compile
+set dg-do-what-default link
 }
 } elseif [istarget ia64-*-*] {
 set dg-do-what-default run
@@ -11707,7 +11707,7 @@ proc check_vect_support_and_set_flags { } {
 if [is-effective-target arm_neon_hw] {
 set dg-do-what-default run
 } else {
-set dg-do-what-default compile
+set dg-do-what-default link
 }
 } elseif [istarget aarch64*-*-*] {
 set dg-do-what-default run
@@ -11731,7 +11731,7 @@ proc check_vect_support_and_set_flags { } {
 set dg-do-what-default run
 } else {
lappend DEFAULT_VECTCFLAGS "-march=z14" "-mzarch"
-set dg-do-what-default compile
+set dg-do-what-default link
 }
 } elseif [istarget amdgcn-*-*] {
 set dg-do-what-default run
@@ -11742,7 +11742,7 @@ proc check_vect_support_and_set_flags { } {
foreach item [add_options_for_riscv_v ""] {
lappend DEFAULT_VECTCFLAGS $item
}
-   set dg-do-what-default compile
+   set dg-do-what-default link
}
 } elseif [istarget loongarch*-*-*] {
   # Set the default vectorization option to "-mlsx" due to the problem
@@ -11751,7 +11751,7 @@ proc check_vect_support_and_set_flags { } {
   if [check_effective_target_loongarch_sx_hw] {
  set dg-do-what-default run
   } else {
- set dg-do-what-default compile
+ set dg-do-what-default link
   }
 } else {
 return 0


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist 

[PATCH][wwwdocs] Improve grammar for AVR changes in GCC 14

[Jonathan Wakely]

OK for wwwdocs?


---
 htdocs/gcc-14/changes.html | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index 9509487c..21d33db8 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -696,13 +696,13 @@ a work-in-progress.
 AVR
 
   On AVR64* and AVR128* devices, read-only data is now located in program
-memory per default and no more in RAM.
+memory per default and no longer in RAM.
 
   Only a 32 KiB block of program memory can be used to store
and access .rodata in that way. Which block is used can be selected
-   by defining symbol __flmap.
+   by defining the symbol __flmap.
As an alternative, the byte address of the block can be specified
-   by symbol __RODATA_FLASH_START__ which takes
+   by the symbol __RODATA_FLASH_START__ which takes
precedence over __flmap.
For example, linking with
-Wl,--defsym,__RODATA_FLASH_START__=32k
@@ -715,9 +715,9 @@ a work-in-progress.
href="https://github.com/avrdudes/avr-libc/issues/931";>#931
can be used. The latter initializes NVMCTRL_CTRLB.FLMAP
in the startup code and according to the value
-   of __flmap resp.
+   of __flmap or
__RODATA_FLASH_START__.
-  When AVR-LibC with #931 is used, then defining symbol
+  When AVR-LibC with #931 is used, then defining the symbol
__flmap_lock to a non-zero value will set bit
NVMCTRL_CTRLB.FLMAPLOCK. This will protect
NVMCTRL_CTRLB.FLMAP from any further changes —
@@ -726,7 +726,7 @@ a work-in-progress.
can be used:
 __asm (".global __flmap_lock"  "\n\t"
"__flmap_lock = 1");
-  When you do not want the code from #931, then define global
+  When you do not want the code from #931, then define a global
symbol __do_flmap_init and the linker will not pull in
that code from libmcu.a any more.
   In order to return to the old placement of read-only data in RAM,
@@ -736,7 +736,7 @@ __asm (".global __flmap_lock"  "\n\t"
  functionality.
   
   Read-only data is located in output section .rodata,
-   wheras it is part of .text when located in RAM.
+   whereas it is part of .text when located in RAM.
   The feature is only available when the compiler is configured
with a version of Binutils that implements
https://sourceware.org/PR31124";>PR31124, which is the
@@ -784,7 +784,7 @@ __asm (".global __flmap_lock"  "\n\t"
   
 On the Reduced Tiny devices,
 the meaning of register constraint "w" has been changed.
-It containts now the registers R24…R31 like it is the case for all
+It now constrains the registers R24…R31 as is the case for all
 the other devices.
   
 
-- 
2.44.0

[PATCH v2] xfail fetestexcept test - ppc always uses fcmpu

[Alexandre Oliva]

On Mar 10, 2021, Joseph Myers  wrote:

> On Wed, 10 Mar 2021, Alexandre Oliva wrote:
>> operand exception for quiet NaN.  I couldn't find any evidence that
>> the rs6000 backend ever outputs fcmpo.  Therefore, I'm adding the same
>> execution xfail marker to this test.

> In my view, such an XFAIL (for a GCC bug as opposed to an environmental 
> issue) should have a comment pointing to a corresponding open bug in GCC 
> Bugzilla.  In this case, that's bug 58684.

Thanks for the suggestion, yeah, that makes sense.  Fixed in v2 below.
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566523.html
Ping?-ish


gcc.dg/torture/pr91323.c tests that a compare with NaNf doesn't set an
exception using builtin compare intrinsics, and that it does when
using regular compare operators.

That doesn't seem to be expected to work on powerpc targets.  It fails
on GNU/Linux, it's marked to be skipped on AIX, and a similar test,
gcc.dg/torture/pr93133.c, has the execution test xfailed for all of
powerpc*-*-*.

In this test, the functions that use intrinsics for the compare end up
with the same code as the one that uses compare operators, using
fcmpu, a floating compare that, unlike fcmpo, does not set the invalid
operand exception for quiet NaN.  I couldn't find any evidence that
the rs6000 backend ever outputs fcmpo.  Therefore, I'm adding the same
execution xfail marker to this test.

Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu.  Also tested with
gcc-13 on ppc64-vx7r2 and ppc-vx7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

PR target/58684
* gcc.dg/torture/pr91323.c: Expect execution fail on
powerpc*-*-*.
---
 gcc/testsuite/gcc.dg/torture/pr91323.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/torture/pr91323.c 
b/gcc/testsuite/gcc.dg/torture/pr91323.c
index 1411fcaa3966c..f188faa3ccf47 100644
--- a/gcc/testsuite/gcc.dg/torture/pr91323.c
+++ b/gcc/testsuite/gcc.dg/torture/pr91323.c
@@ -1,4 +1,5 @@
-/* { dg-do run } */
+/* { dg-do run { xfail powerpc*-*-* } } */
+/* The ppc xfail is because of PR target/58684.  */
 /* { dg-add-options ieee } */
 /* { dg-require-effective-target fenv_exceptions } */
 /* { dg-skip-if "fenv" { powerpc-ibm-aix* } } */


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH v2] [testsuite] require sqrt_insn effective target where needed

[Alexandre Oliva]

This patch takes feedback received for 3 earlier patches, and adopts a
simpler approach to skip the still-failing tests, that I believe to be
in line with ppc maintainers' expressed preferences.
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565939.html
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566617.html
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566521.html
Ping?-ish :-)


Some tests fail on ppc and ppc64 when testing a compiler [with options
for] for a CPU [emulator] that doesn't support the sqrt insn.

The gcc.dg/cdce3.c is one in which the expected shrink-wrap
optimization only takes place when the target CPU supports a sqrt
insn.

The gcc.target/powerpc/pr46728-1[0-4].c tests use -mpowerpc-gpopt and
call sqrt(), which involves the sqrt insn that the target CPU under
test may not support.

Require a sqrt_insn effective target for all the affected tests.

Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu.  Also testing
with gcc-13 on ppc64-vx7r2 and ppc-vx7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.dg/cdce3.c: Require sqrt_insn effective target.
* gcc.target/powerpc/pr46728-10.c: Likewise.
* gcc.target/powerpc/pr46728-11.c: Likewise.
* gcc.target/powerpc/pr46728-13.c: Likewise.
* gcc.target/powerpc/pr46728-14.c: Likewise.
---
 gcc/testsuite/gcc.dg/cdce3.c  |3 ++-
 gcc/testsuite/gcc.target/powerpc/pr46728-10.c |1 +
 gcc/testsuite/gcc.target/powerpc/pr46728-11.c |1 +
 gcc/testsuite/gcc.target/powerpc/pr46728-13.c |1 +
 gcc/testsuite/gcc.target/powerpc/pr46728-14.c |1 +
 5 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/cdce3.c b/gcc/testsuite/gcc.dg/cdce3.c
index 601ddf055fd71..f759a95972e8b 100644
--- a/gcc/testsuite/gcc.dg/cdce3.c
+++ b/gcc/testsuite/gcc.dg/cdce3.c
@@ -1,7 +1,8 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target hard_float } */
+/* { dg-require-effective-target sqrt_insn } */
 /* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details 
-fdump-tree-optimized" } */
-/* { dg-final { scan-tree-dump "cdce3.c:11: \[^\n\r]* function call is 
shrink-wrapped into error conditions\." "cdce" } } */
+/* { dg-final { scan-tree-dump "cdce3.c:12: \[^\n\r]* function call is 
shrink-wrapped into error conditions\." "cdce" } } */
 /* { dg-final { scan-tree-dump "sqrtf \\(\[^\n\r]*\\); \\\[tail call\\\]" 
"optimized" } } */
 /* { dg-skip-if "doesn't have a sqrtf insn" { mmix-*-* } } */
 
diff --git a/gcc/testsuite/gcc.target/powerpc/pr46728-10.c 
b/gcc/testsuite/gcc.target/powerpc/pr46728-10.c
index 3be4728d333a4..7e9bb638106c2 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr46728-10.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr46728-10.c
@@ -1,6 +1,7 @@
 /* { dg-do run } */
 /* { dg-skip-if "-mpowerpc-gpopt not supported" { powerpc*-*-darwin* } } */
 /* { dg-options "-O2 -ffast-math -fno-inline -fno-unroll-loops -lm 
-mpowerpc-gpopt" } */
+/* { dg-require-effective-target sqrt_insn } */
 
 #include 
 
diff --git a/gcc/testsuite/gcc.target/powerpc/pr46728-11.c 
b/gcc/testsuite/gcc.target/powerpc/pr46728-11.c
index 43b6728a4b812..5bfa25925675a 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr46728-11.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr46728-11.c
@@ -1,6 +1,7 @@
 /* { dg-do run } */
 /* { dg-skip-if "-mpowerpc-gpopt not supported" { powerpc*-*-darwin* } } */
 /* { dg-options "-O2 -ffast-math -fno-inline -fno-unroll-loops -lm 
-mpowerpc-gpopt" } */
+/* { dg-require-effective-target sqrt_insn } */
 
 #include 
 
diff --git a/gcc/testsuite/gcc.target/powerpc/pr46728-13.c 
b/gcc/testsuite/gcc.target/powerpc/pr46728-13.c
index b9fd63973b728..b66d0209a5e54 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr46728-13.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr46728-13.c
@@ -1,6 +1,7 @@
 /* { dg-do run } */
 /* { dg-skip-if "-mpowerpc-gpopt not supported" { powerpc*-*-darwin* } } */
 /* { dg-options "-O2 -ffast-math -fno-inline -fno-unroll-loops -lm 
-mpowerpc-gpopt" } */
+/* { dg-require-effective-target sqrt_insn } */
 
 #include 
 
diff --git a/gcc/testsuite/gcc.target/powerpc/pr46728-14.c 
b/gcc/testsuite/gcc.target/powerpc/pr46728-14.c
index 5a13bdb6c..71a1a70c4e7a2 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr46728-14.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr46728-14.c
@@ -1,6 +1,7 @@
 /* { dg-do run } */
 /* { dg-skip-if "-mpowerpc-gpopt not supported" { powerpc*-*-darwin* } } */
 /* { dg-options "-O2 -ffast-math -fno-inline -fno-unroll-loops -lm 
-mpowerpc-gpopt" } */
+/* { dg-require-effective-target sqrt_insn } */
 
 #include 
 

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

Re: [PATCH] Add rvalue::get_name method (and its C equivalent)

[Arthur Cohen]

Hey Guillaume :)

On 4/20/24 01:05, Guillaume Gomez wrote:

Hi,

I just encountered the need to retrieve the name of an `rvalue` (if
there is one) while working on the Rust GCC backend.

This patch adds a getter to retrieve the information.

Cordially.



   virtual bool get_wide_int (wide_int *) const { return false; }
 
+  virtual string * get_name () { return NULL; }

+
 private:
   virtual enum precedence get_precedence () const = 0;


Is there any reason for that getter to return a mutable pointer to the 
name? Would something like this work instead if you're just looking at 
getting the name?


+  virtual string * get_name () const { return NULL; }

With of course adequate modifications to the inheriting classes.

Best,

Arthur


OpenPGP_0x1B3465B044AD9C65.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: enable sqrt insns for cdce3.c

[Alexandre Oliva]

[Revamped version of this patch, combined with others, to follow]

On Mar 10, 2021, Hans-Peter Nilsson  wrote:

> On Wed, 10 Mar 2021, Alexandre Oliva wrote:
>> 
>> The test expects shrink-wrapping of the fsqrt call, but that will only
>> occur when there is a usable sqrt insn.
>> 
>> Arrange for dejagnu to add the options that enable the sqrt insn, if
>> one is available, and to skip the test otherwise.
>> 
>> 
>> H-P, this *should* obviate the mmix-specific dg-skip-if.

> Unfortunately it doesn't.

>> Would it be
>> easy for you to confirm that this is the case and, if so, drop it?

> About as easy as for anyone (this is a compile-test), but no
> problem.  Unfortunately I get, with your patch applied and the
> dg-skip-if removed:

> FAIL: gcc.dg/cdce3.c scan-tree-dump cdce "cdce3.c:12: [^\n\r]*
> function call is shrink-wrapped into error conditions."

Is mmix a sqrt_insn effective target?  proc
check_effective_target_sqrt_insn in
gcc/testsuite/lib/target-supports.exp suggests it shouldn't pass, so I'm
surprised it would still try to run the test despite the added
/* { dg-require-effective-target sqrt_insn } */ directive.


> The dump files and assembly file show no obvious clues to me as
> to what is supposed to happen; attached.

cdce3 is supposed to shrink-wrap the sqrtf(x) call into something like
(x >= 0 ? .SQRT(x) : sqrtf(x)), where .SQRT stands for a square root
instruction.

Since we don't know why it still runs for you, I'm keeping the mmix
explicit skip in the new version of the patch.

Thanks,

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH v2] add explicit ABI and align options to pr88233.c

[Alexandre Oliva]

Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566530.html
(modified version follows)


We've observed failures of this test on powerpc configurations that
default to different calling conventions and alignment requirements.
Both settings are needed for the original expectations to be met.

The test was later modified to have different expectations for big and
little endian code generation.  This patch restores the original
codegen expectations, that, with the explicit options, don't vary any
more.

Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu.  Also tested with
gcc-13 on ppc64-vx7r2 and ppc-vx7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/pr88233.c: Make some alignment strictness
and calling conventions assumptions explicit.  Restore uniform
codegen expectations
---
 gcc/testsuite/gcc.target/powerpc/pr88233.c |7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr88233.c 
b/gcc/testsuite/gcc.target/powerpc/pr88233.c
index 27c73717a3f79..46a3ebfa28775 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr88233.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr88233.c
@@ -1,5 +1,5 @@
 /* { dg-require-effective-target lp64 } */
-/* { dg-options "-O2 -mdejagnu-cpu=power8" } */
+/* { dg-options "-O2 -mdejagnu-cpu=power8 -mno-strict-align 
-fpcc-struct-return" } */
 
 typedef struct { double a[2]; } A;
 A
@@ -9,6 +9,5 @@ foo (const A *a)
 }
 
 /* { dg-final { scan-assembler-not {\mmtvsr} } } */
-/* { dg-final { scan-assembler-times {\mlxvd2x\M} 1 { target { be } } } } */
-/* { dg-final { scan-assembler-times {\mstxvd2x\M} 1 { target { be } } } } */
-/* { dg-final { scan-assembler-times {\mlfd\M} 2 { target { le } } } } */
+/* { dg-final { scan-assembler-times {\mlxvd2x\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mstxvd2x\M} 1 } } */


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] ppc: testsuite: vec-mul requires vsx runtime

[Alexandre Oliva]

Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593947.html


vec-mul is an execution test, but it only requires a powerpc_vsx_ok
effective target, which is enough only for compile tests.  In order to
To check for runtime and execution environment support, we need to
require vsx_hw.  Make that a condition for execution, but still
perform a compile test if the condition is not satisfied.

Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu.  Also tested with
gcc-13 on ppc64-vx7r2 and ppc-vx7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/vec-mul.c: Run on target vsx_hw, just
compile otherwise.
---
 gcc/testsuite/gcc.target/powerpc/vec-mul.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/vec-mul.c 
b/gcc/testsuite/gcc.target/powerpc/vec-mul.c
index bfcaf80719d1d..11da86159723f 100644
--- a/gcc/testsuite/gcc.target/powerpc/vec-mul.c
+++ b/gcc/testsuite/gcc.target/powerpc/vec-mul.c
@@ -1,4 +1,5 @@
-/* { dg-do run } */
+/* { dg-do compile { target { ! vsx_hw } } } */
+/* { dg-do run { target vsx_hw } } */
 /* { dg-require-effective-target powerpc_vsx_ok } */
 /* { dg-options "-mvsx -O3" } */
 


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] Request check for hw support in ppc run tests with -maltivec/-mvsx

[Alexandre Oliva]

From: Olivier Hainque 

Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu.  Also tested with
gcc-13 on ppc64-vx7r2 and ppc-vx7r2.  Ok to install?

for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/swaps-p8-20.c: Change powerpc_altivec_ok
require-effective-target test into vmx_hw.
* gcc.target/powerpc/vsx-vector-5.c: Change powerpc_vsx_ok
require-effective-target test into vsx_hw.
---
 gcc/testsuite/gcc.target/powerpc/swaps-p8-20.c  |2 +-
 gcc/testsuite/gcc.target/powerpc/vsx-vector-5.c |5 +
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/swaps-p8-20.c 
b/gcc/testsuite/gcc.target/powerpc/swaps-p8-20.c
index 564e8acb1f421..755519bfe847d 100644
--- a/gcc/testsuite/gcc.target/powerpc/swaps-p8-20.c
+++ b/gcc/testsuite/gcc.target/powerpc/swaps-p8-20.c
@@ -1,5 +1,5 @@
 /* { dg-do run } */
-/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-require-effective-target vmx_hw } */
 /* { dg-options "-O2 -mdejagnu-cpu=power8 -maltivec" } */
 
 /* The expansion for vector character multiply introduces a vperm operation.
diff --git a/gcc/testsuite/gcc.target/powerpc/vsx-vector-5.c 
b/gcc/testsuite/gcc.target/powerpc/vsx-vector-5.c
index dcc88b1f3a4c6..37a324b6f897d 100644
--- a/gcc/testsuite/gcc.target/powerpc/vsx-vector-5.c
+++ b/gcc/testsuite/gcc.target/powerpc/vsx-vector-5.c
@@ -1,11 +1,8 @@
 /* { dg-do run { target lp64 } } */
 /* { dg-skip-if "" { powerpc*-*-darwin* } } */
-/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-require-effective-target vsx_hw } */
 /* { dg-options "-mvsx -O2" } */
 
-/* This will run, and someday we should add the support to test whether we are
-   running on VSX hardware.  */
-
 #include 
 #include 
 

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] adjust vectorization expectations for ppc costmodel 76b

[Alexandre Oliva]

Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566525.html


This test expects vectorization at power8+ because strict alignment is
not required for vectors.  For power7, vectorization is not to take
place because it's not deemed profitable: 12 iterations would be
required to make it so.

But for power6 and below, the test's 10 iterations are enough to make
vectorization profitable, but the test doesn't expect this.  Assuming
the decision is indeed appropriate, I'm adjusting the expectations.


for  gcc/testsuite/ChangeLog

* gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c: Adjust
expectations for cpus below power7.
---
 .../gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c 
b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c
index cbbfbb24658f8..0dab2c08acdb4 100644
--- a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c
+++ b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c
@@ -46,9 +46,10 @@ int main (void)
   return 0;
 }
 
-/* Peeling to align the store is used. Overhead of peeling is too high.  */
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" { target { 
vector_alignment_reachable && {! vect_no_align} } } } } */
-/* { dg-final { scan-tree-dump-times "vectorization not profitable" 1 "vect" { 
target { vector_alignment_reachable && {! vect_hw_misalign} } } } } */
+/* Peeling to align the store is used. Overhead of peeling is too high
+   for power7, but acceptable for earlier architectures.  */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" { target { 
has_arch_pwr7 && { vector_alignment_reachable && {! vect_no_align} } } } } } */
+/* { dg-final { scan-tree-dump-times "vectorization not profitable" 1 "vect" { 
target { has_arch_pwr7 && { vector_alignment_reachable && {! vect_hw_misalign} 
} } } } } */
 
 /* Versioning to align the store is used. Overhead of versioning is not too 
high.  */
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target { 
vect_no_align || {! vector_alignment_reachable} } } } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target { 
vect_no_align || { {! vector_alignment_reachable} || {! has_arch_pwr7 } } } } } 
} */


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] disable ldist for test, to restore vectorizing-candidate loop

[Alexandre Oliva]

Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566524.html

The loop we're supposed to try to vectorize in
gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c is turned into a memset
before the vectorizer runs.

Various other tests in this set have already run into this, and the
solution has been to disable this loop distribution transformation,
enabled at -O2, so that the vectorizer gets a chance to transform the
loop and, in this testcase, fail to do so.

Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu.  Also tested with
gcc-13 on ppc64-vx7r2 and ppc-vx7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Disable
ldist.
---
 .../gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c 
b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
index 454a714a30916..90b5d5a7f400b 100644
--- a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
+++ b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
@@ -1,4 +1,5 @@
 /* { dg-require-effective-target vect_int } */
+/* { dg-additional-options "-fno-tree-loop-distribute-patterns" } */
 
 #include 
 #include "../../tree-vect.h"

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

[PATCH] [testsuite] [ppc64] expect error on vxworks too

[Alexandre Oliva]

These ppc lp64 tests check for errors or warnings on -mno-powerpc64.
On powerpc64-*-vxworks* we get the same errors as on most other
covered platforms, but the tests did not mark them as expected for
this target.  On powerpc-*-vxworks*, the tests are skipped because
lp64 is not satisfied, so I'm naming powerpc*-*-vxworks* rather than
something more specific.

Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu.  Also tested with
gcc-13 on ppc64-vx7r2 and ppc-vx7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/pr106680-1.c: Error on vxworks too.
* gcc.target/powerpc/pr106680-2.c: Likewise.
* gcc.target/powerpc/pr106680-3.c: Likewise.
---
 gcc/testsuite/gcc.target/powerpc/pr106680-1.c |2 +-
 gcc/testsuite/gcc.target/powerpc/pr106680-2.c |2 +-
 gcc/testsuite/gcc.target/powerpc/pr106680-3.c |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pr106680-1.c 
b/gcc/testsuite/gcc.target/powerpc/pr106680-1.c
index d624d43230a7a..aadaa614cfeba 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr106680-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr106680-1.c
@@ -8,6 +8,6 @@ int foo ()
   return 1;
 }
 
-/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target 
powerpc*-*-linux* powerpc*-*-freebsd* powerpc-*-rtems* } 0 } */
+/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target 
powerpc*-*-linux* powerpc*-*-freebsd* powerpc-*-rtems* powerpc*-*-vxworks* } 0 
} */
 /* { dg-warning "'-m64' requires PowerPC64 architecture, enabling" "PR106680" 
{ target powerpc*-*-darwin* } 0 } */
 /* { dg-warning "'-maix64' requires PowerPC64 architecture remain enabled" 
"PR106680" { target powerpc*-*-aix* } 0 } */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr106680-2.c 
b/gcc/testsuite/gcc.target/powerpc/pr106680-2.c
index a9ed73726ef0c..f0758e303350a 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr106680-2.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr106680-2.c
@@ -9,6 +9,6 @@ int foo ()
   return 1;
 }
 
-/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target 
powerpc*-*-linux* powerpc*-*-freebsd* powerpc-*-rtems* } 0 } */
+/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target 
powerpc*-*-linux* powerpc*-*-freebsd* powerpc-*-rtems* powerpc*-*-vxworks* } 0 
} */
 /* { dg-warning "'-m64' requires PowerPC64 architecture, enabling" "PR106680" 
{ target powerpc*-*-darwin* } 0 } */
 /* { dg-warning "'-maix64' requires PowerPC64 architecture remain enabled" 
"PR106680" { target powerpc*-*-aix* } 0 } */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr106680-3.c 
b/gcc/testsuite/gcc.target/powerpc/pr106680-3.c
index b642d5c7a008d..bca012e2cf663 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr106680-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr106680-3.c
@@ -8,6 +8,6 @@ int foo ()
   return 1;
 }
 
-/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target 
powerpc*-*-linux* powerpc*-*-freebsd* powerpc-*-rtems* } 0 } */
+/* { dg-error "'-m64' requires a PowerPC64 cpu" "PR106680" { target 
powerpc*-*-linux* powerpc*-*-freebsd* powerpc-*-rtems* powerpc*-*-vxworks* } 0 
} */
 /* { dg-warning "'-m64' requires PowerPC64 architecture, enabling" "PR106680" 
{ target powerpc*-*-darwin* } 0 } */
 /* { dg-warning "'-maix64' requires PowerPC64 architecture remain enabled" 
"PR106680" { target powerpc*-*-aix* } 0 } */

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

Re: [PATCH v3 1/2] LoongArch: Define ISA versions

[Yang Yujie]

v1 -> v2: 
- Fixed build issues of runtime libraries caused by the new header.
- Restored the default ARCH of lp64f/lp64s ABI to "abi-default".

v2 -> v3:
- Fixed libobjc build.
- Modify "LoongArch v1.1 features" to "LoongArch v1.1 instructions"
in invoke.texi.

[PATCH v3 2/2] LoongArch: Define builtin macros for ISA evolutions

[Yang Yujie]

Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.

gcc/ChangeLog:

* config.gcc: Add loongarch-evolution.o.
* config/loongarch/genopts/genstr.sh: Enable generation of
loongarch-evolution.[cc,h].
* config/loongarch/t-loongarch: Likewise.
* config/loongarch/genopts/gen-evolution.awk: New file.
* config/loongarch/genopts/isa-evolution.in: Mark ISA version
of introduction for each ISA evolution feature.
* config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins):
Define builtin macros for enabled ISA evolutions and the ISA
version.
* config/loongarch/loongarch-cpu.cc: Use loongarch-evolution.h.
* config/loongarch/loongarch.h: Likewise.
* config/loongarch/loongarch-cpucfg-map.h: Delete.
* config/loongarch/loongarch-evolution.cc: New file.
* config/loongarch/loongarch-evolution.h: New file.
* config/loongarch/loongarch-opts.h (ISA_HAS_FRECIPE): Define.
(ISA_HAS_DIV32): Likewise.
(ISA_HAS_LAM_BH): Likewise.
(ISA_HAS_LAMCAS): Likewise.
(ISA_HAS_LD_SEQ_SA): Likewise.
---
 gcc/config.gcc|   2 +-
 .../loongarch/genopts/gen-evolution.awk   | 230 ++
 gcc/config/loongarch/genopts/genstr.sh|  82 ++-
 gcc/config/loongarch/genopts/isa-evolution.in |  10 +-
 gcc/config/loongarch/loongarch-c.cc   |  20 ++
 gcc/config/loongarch/loongarch-cpu.cc |   2 +-
 gcc/config/loongarch/loongarch-evolution.cc   |  60 +
 ...rch-cpucfg-map.h => loongarch-evolution.h} |  46 +++-
 gcc/config/loongarch/loongarch-opts.h |  11 -
 gcc/config/loongarch/loongarch.h  |   1 +
 gcc/config/loongarch/t-loongarch  |  26 +-
 11 files changed, 395 insertions(+), 95 deletions(-)
 create mode 100644 gcc/config/loongarch/genopts/gen-evolution.awk
 create mode 100644 gcc/config/loongarch/loongarch-evolution.cc
 rename gcc/config/loongarch/{loongarch-cpucfg-map.h => loongarch-evolution.h} 
(52%)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 929695c25ab..3364fc27524 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -485,7 +485,7 @@ 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_objs="loongarch-c.o loongarch-builtins.o loongarch-cpu.o 
loongarch-opts.o loongarch-def.o loongarch-evolution.o"
extra_gcc_objs="loongarch-driver.o loongarch-cpu.o loongarch-opts.o 
loongarch-def.o"
extra_options="${extra_options} g.opt fused-madd.opt"
;;
diff --git a/gcc/config/loongarch/genopts/gen-evolution.awk 
b/gcc/config/loongarch/genopts/gen-evolution.awk
new file mode 100644
index 000..4d105afa906
--- /dev/null
+++ b/gcc/config/loongarch/genopts/gen-evolution.awk
@@ -0,0 +1,230 @@
+#!/usr/bin/gawk
+#
+# A simple script that generates loongarch-evolution.h
+# from genopts/isa-evolution.in
+#
+# Copyright (C) 2021-2024 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify it under
+# the terms of the GNU General Public License as published by the Free
+# Software Foundation; either version 3, or (at your option) any later
+# version.
+#
+# GCC is distributed in the hope that it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+# or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+# License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+BEGIN {
+# isa_version_major[]
+# isa_version_minor[]
+# cpucfg_word[]
+# cpucfg_bit_in_word[]
+# name_capitalized[]
+# comment[]
+}
+
+{
+cpucfg_word[NR] = $1
+cpucfg_bit_in_word[NR] = $2
+name[NR] = gensub(/-/, "_", "g", $3)
+name_capitalized[NR] = toupper(name[NR])
+isa_version_major[NR] = gensub(/^([1-9][0-9]*)\.([0-9]+)$/, "\\1", 1, $4)
+isa_version_minor[NR] = gensub(/^([1-9][0-9]*)\.([0-9]+)$/, "\\2", 1, $4)
+
+$1 = $2 = $3 = $4 = ""
+sub (/^\s*/, "")
+comment[NR] = $0
+}
+
+function copyright_header(from_year,to_year)
+{
+print "   Copyright (C) " from_year "-" to_year \
+  " Free Software Foundation, Inc."
+print ""
+print "This file is part of GCC."
+print ""
+print "GCC is free software; you can redistribute it and/or modify"
+print "it under the terms of the GNU General Public License as published 
by"
+print "the Free Software Foundation; either version 3, or (at your option)"
+print "any later version."
+print ""
+print "GCC i

[PATCH v3 1/2] LoongArch: Define ISA versions

[Yang Yujie]

These ISA versions are defined as -march= parameters and
are recommended for building binaries for distribution.

Detailed description of these definitions can be found at
https://github.com/loongson/la-toolchain-conventions, which
the LoongArch GCC port aims to conform to.

gcc/ChangeLog:

* config.gcc: Make la64v1.0 the default ISA preset of the lp64d ABI.
* config/loongarch/genopts/loongarch-strings: Define la64v1.0, la64v1.1.
* config/loongarch/genopts/loongarch.opt.in: Likewise.
* config/loongarch/loongarch-c.cc (LARCH_CPP_SET_PROCESSOR): Likewise.
(loongarch_cpu_cpp_builtins): Likewise.
* config/loongarch/loongarch-cpu.cc (get_native_prid): Likewise.
(fill_native_cpu_config): Likewise.
* config/loongarch/loongarch-def.cc (array_tune): Likewise.
* config/loongarch/loongarch-def.h: Likewise.
* config/loongarch/loongarch-driver.cc (driver_set_m_parm): Likewise.
(driver_get_normalized_m_opts): Likewise.
* config/loongarch/loongarch-opts.cc (default_tune_for_arch): Likewise.
(TUNE_FOR_ARCH): Likewise.
(arch_str): Likewise.
(loongarch_target_option_override): Likewise.
* config/loongarch/loongarch-opts.h (TARGET_uARCH_LA464): Likewise.
(TARGET_uARCH_LA664): Likewise.
* config/loongarch/loongarch-str.h (STR_CPU_ABI_DEFAULT): Likewise.
(STR_ARCH_ABI_DEFAULT): Likewise.
(STR_TUNE_GENERIC): Likewise.
(STR_ARCH_LA64V1_0): Likewise.
(STR_ARCH_LA64V1_1): Likewise.
* config/loongarch/loongarch.cc 
(loongarch_cpu_sched_reassociation_width): Likewise.
(loongarch_asm_code_end): Likewise.
* config/loongarch/loongarch.opt: Likewise.
* doc/invoke.texi: Likewise.
---
 gcc/config.gcc| 34 
 .../loongarch/genopts/loongarch-strings   |  5 +-
 gcc/config/loongarch/genopts/loongarch.opt.in | 43 --
 gcc/config/loongarch/loongarch-c.cc   | 37 +++--
 gcc/config/loongarch/loongarch-cpu.cc | 35 
 gcc/config/loongarch/loongarch-def.cc | 83 +--
 gcc/config/loongarch/loongarch-def.h  | 37 ++---
 gcc/config/loongarch/loongarch-driver.cc  |  8 +-
 gcc/config/loongarch/loongarch-opts.cc| 66 +++
 gcc/config/loongarch/loongarch-opts.h |  4 +-
 gcc/config/loongarch/loongarch-str.h  |  5 +-
 gcc/config/loongarch/loongarch.cc | 11 +--
 gcc/config/loongarch/loongarch.opt| 43 --
 gcc/doc/invoke.texi   | 57 -
 14 files changed, 300 insertions(+), 168 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 5df3c52f8e9..929695c25ab 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -5072,7 +5072,7 @@ case "${target}" in
 
# Perform initial sanity checks on --with-* options.
case ${with_arch} in
-   "" | abi-default | loongarch64 | la[46]64) ;; # OK, append here.
+   "" | la64v1.[01] | abi-default | loongarch64 | la[46]64) ;; # 
OK, append here.
native)
if test x${host} != x${target}; then
echo "--with-arch=native is illegal for 
cross-compiler." 1>&2
@@ -5119,10 +5119,18 @@ case "${target}" in
 
# Infer ISA-related default options from the ABI: pass 1
case ${abi_base}/${abi_ext} in
-   lp64*/base)
+   lp64d/base)
# architectures that support lp64* ABI
-   arch_pattern="native|abi-default|loongarch64|la[46]64"
-   # default architecture for lp64* ABI
+   
arch_pattern="native|abi-default|la64v1.[01]|loongarch64|la[46]64"
+
+   # default architecture for lp64d ABI
+   arch_default="la64v1.0"
+   ;;
+   lp64[fs]/base)
+   # architectures that support lp64* ABI
+   
arch_pattern="native|abi-default|la64v1.[01]|loongarch64|la[46]64"
+
+   # default architecture for lp64[fs] ABI
arch_default="abi-default"
;;
*)
@@ -5194,15 +5202,7 @@ case "${target}" in
 
 
# Check default with_tune configuration using with_arch.
-   case ${with_arch} in
-   loongarch64)
-   tune_pattern="native|abi-default|loongarch64|la[46]64"
-   ;;
-   *)
-   # By default, $with_tune == $with_arch
-   tune_pattern="*"
-   ;;
-   esac
+   tune_pattern="native|generic|loongarch64|la[46]64"
 
case ${with_tune} in
"") ;; # OK
@@ -5252,7 +5252,7 @@ case "${target}" in
   

[Committed] s390x: Do not default to -mvx for -mesa

[Andreas Krebbel]

We currently enable the vector extensions also for -march=z13 -m31
mesa which is very wrong.

Not a regression but an obvious fix, so I've committed it to mainline
now. Will have to cherry-pick it for stable branches as well.

gcc/ChangeLog:

* config/s390/s390.cc (s390_option_override_internal): Check zarch
flag before enabling -mvx.
---
 gcc/config/s390/s390.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
index bf46eab2d63..5968808fcb6 100644
--- a/gcc/config/s390/s390.cc
+++ b/gcc/config/s390/s390.cc
@@ -16104,7 +16104,7 @@ s390_option_override_internal (struct gcc_options *opts,
 }
   else
 {
-  if (TARGET_CPU_VX_P (opts))
+  if (TARGET_CPU_VX_P (opts) && TARGET_ZARCH_P (opts->x_target_flags))
/* Enable vector support if available and not explicitly disabled
   by user.  E.g. with -m31 -march=z13 -mzarch */
opts->x_target_flags |= MASK_OPT_VX;
-- 
2.44.0

[PATCH] i386: Fix Sierra Forest auto dispatch

[Haochen Jiang]

Hi all,

This patch fixes an bug in mapping which caused auto dispatch failed.
Sierra Forest is in processor_types enum, but not processor_subtypes.

Committed as obvious and backport to GCC13.

Thx,
Haochen

gcc/ChangeLog:

* common/config/i386/i386-common.cc (processor_alias_table):
Let Sierra Forest map to CPU_TYPE enum.
---
 gcc/common/config/i386/i386-common.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/common/config/i386/i386-common.cc 
b/gcc/common/config/i386/i386-common.cc
index f814df8385b..77b154663bc 100644
--- a/gcc/common/config/i386/i386-common.cc
+++ b/gcc/common/config/i386/i386-common.cc
@@ -2302,7 +2302,7 @@ const pta processor_alias_table[] =
   {"gracemont", PROCESSOR_ALDERLAKE, CPU_HASWELL, PTA_ALDERLAKE,
M_CPU_SUBTYPE (INTEL_COREI7_ALDERLAKE), P_PROC_AVX2},
   {"sierraforest", PROCESSOR_SIERRAFOREST, CPU_HASWELL, PTA_SIERRAFOREST,
-M_CPU_SUBTYPE (INTEL_SIERRAFOREST), P_PROC_AVX2},
+M_CPU_TYPE (INTEL_SIERRAFOREST), P_PROC_AVX2},
   {"grandridge", PROCESSOR_GRANDRIDGE, CPU_HASWELL, PTA_GRANDRIDGE,
 M_CPU_TYPE (INTEL_GRANDRIDGE), P_PROC_AVX2},
   {"clearwaterforest", PROCESSOR_CLEARWATERFOREST, CPU_HASWELL,
-- 
2.31.1

Re: [PATCH v2 1/2] LoongArch: Define ISA versions

[Xi Ruoyao]

On Sat, 2024-04-20 at 18:47 +0800, Yang Yujie wrote:
> +@item la664
> +LoongArch LA664-based processor with LSX, LASX and all LoongArch v1.1
> features.

I still prefer "v1.1 instructions" instead of "v1.1 features" because
LA664 (at least all launched LA664 CPUs) does not support HPTW, which
**is** a v1.1 feature.

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: [PATCH] s390: testsuite: Fix forwprop-4{0,1}.c

[Andreas Krebbel]

Hi Stefan,

due to that missed optimization we currently generate silly code for these two 
tests and should
really fix this (after gcc entering stage1). So just skipping it on s390x would 
definitely be the
wrong choice I think.

I think our vectorize_vec_perm_const correctly rejects this permute pattern, 
since it would require
a load from literal pool. Question is why we do have to rely on this being 
turned into a permute
first to get rid of the obviously redundant assignments. Shouldn't fwprop be 
able to handle this
without it?

I'm ok with your patch, but please also open a BZ for it and perhaps mention it 
in the comment close
to the xfail.

Thanks!

Andreas

On 4/22/24 08:23, Stefan Schulze Frielinghaus wrote:
> The tests fail on s390 since can_vec_perm_const_p fails and therefore
> the bit insert/ref survive which r14-3381-g27de9aa152141e aims for.
> Strictly speaking, the tests only fail in case the target supports
> vectors, i.e., for targets prior z13 or in case of -mesa the emulated
> vector operations are optimized out.
> 
> Easiest would be to skip the entire test for s390.  Another solution
> would be to xfail in case of vector support hoping that eventually we
> end up with an xpass for a future machine generation or if gcc advances.
> That is implemented by this patch.  In order to do so I implemented a
> new target test s390_mvx which tests whether vector support is available
> or not.  Maybe this is already over-engineered for a simple test?  Any
> thoughts?
> ---
>  gcc/testsuite/gcc.dg/tree-ssa/forwprop-40.c |  4 ++--
>  gcc/testsuite/gcc.dg/tree-ssa/forwprop-41.c |  4 ++--
>  gcc/testsuite/lib/target-supports.exp   | 14 ++
>  3 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-40.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-40.c
> index 7513497f552..b67e3e93a7f 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-40.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-40.c
> @@ -10,5 +10,5 @@ vector int g(vector int a)
>return a;
>  }
>  
> -/* { dg-final { scan-tree-dump-times "BIT_INSERT_EXPR" 0 "optimized" } } */
> -/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 0 "optimized" } } */
> +/* { dg-final { scan-tree-dump-times "BIT_INSERT_EXPR" 0 "optimized" { xfail 
> s390_mvx } } } */
> +/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 0 "optimized" { xfail 
> s390_mvx } } } */
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-41.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-41.c
> index b1e75797a90..0f119675207 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-41.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-41.c
> @@ -11,6 +11,6 @@ vector int g(vector int a, int c)
>return a;
>  }
>  
> -/* { dg-final { scan-tree-dump-times "BIT_INSERT_EXPR" 1 "optimized" } } */
> -/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 0 "optimized" } } */
> +/* { dg-final { scan-tree-dump-times "BIT_INSERT_EXPR" 1 "optimized" { xfail 
> s390_mvx } } } */
> +/* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 0 "optimized" { xfail 
> s390_mvx } } } */
>  /* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR" 0 "optimized" } } */
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index edce672c0e2..5a692baa8ef 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -12380,6 +12380,20 @@ proc check_effective_target_profile_update_atomic {} 
> {
>  } "-fprofile-update=atomic -fprofile-generate"]
>  }
>  
> +# Return 1 if the target has a vector facility.
> +proc check_effective_target_s390_mvx { } {
> +if ![istarget s390*-*-*] then {
> + return 0;
> +}
> +
> +return [check_no_compiler_messages_nocache s390_mvx assembly {
> + #if !defined __VX__
> + #error no vector facility.
> + #endif
> + int dummy;
> +} [current_compiler_flags]]
> +}
> +
>  # Return 1 if vector (va - vector add) instructions are understood by
>  # the assembler and can be executed.  This also covers checking for
>  # the VX kernel feature.  A kernel without that feature does not

Re: [PATCH v1] RISC-V: Add xfail test case for highpart overlap floating-point widen insn

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

lgtm



juzhe.zh...@rivai.ai
 
From: pan2.li
Date: 2024-04-22 16:27
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Add xfail test case for highpart overlap 
floating-point widen insn
From: Pan Li 
 
We reverted below patch for register group overlap, add the related
insn test and mark it as xfail.  And we will remove the xfail
after we support the register overlap in GCC-15.
 
8614cbb2534 RISC-V: Support highpart overlap for floating-point widen 
instructions
 
The below test suites are passed.
* The rv64gcv fully regression test.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/base/pr112431-10.c: New test.
* gcc.target/riscv/rvv/base/pr112431-11.c: New test.
* gcc.target/riscv/rvv/base/pr112431-12.c: New test.
* gcc.target/riscv/rvv/base/pr112431-13.c: New test.
* gcc.target/riscv/rvv/base/pr112431-14.c: New test.
* gcc.target/riscv/rvv/base/pr112431-15.c: New test.
* gcc.target/riscv/rvv/base/pr112431-7.c: New test.
* gcc.target/riscv/rvv/base/pr112431-8.c: New test.
* gcc.target/riscv/rvv/base/pr112431-9.c: New test.
 
Signed-off-by: Pan Li 
---
.../gcc.target/riscv/rvv/base/pr112431-10.c   | 104 ++
.../gcc.target/riscv/rvv/base/pr112431-11.c   |  68 +++
.../gcc.target/riscv/rvv/base/pr112431-12.c   |  51 +
.../gcc.target/riscv/rvv/base/pr112431-13.c   | 188 ++
.../gcc.target/riscv/rvv/base/pr112431-14.c   | 119 +++
.../gcc.target/riscv/rvv/base/pr112431-15.c   |  86 
.../gcc.target/riscv/rvv/base/pr112431-7.c| 104 ++
.../gcc.target/riscv/rvv/base/pr112431-8.c|  68 +++
.../gcc.target/riscv/rvv/base/pr112431-9.c|  51 +
9 files changed, 839 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-10.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-11.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-12.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-13.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-14.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-15.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-7.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-8.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-9.c
 
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-10.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-10.c
new file mode 100644
index 000..5d3f2fbe46d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-10.c
@@ -0,0 +1,104 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -O3" } */
+
+#include "riscv_vector.h"
+
+double __attribute__ ((noinline))
+sumation (double sum0, double sum1, double sum2, double sum3, double sum4,
+   double sum5, double sum6, double sum7, double sum8, double sum9,
+   double sum10, double sum11, double sum12, double sum13, double sum14,
+   double sum15)
+{
+  return sum0 + sum1 + sum2 + sum3 + sum4 + sum5 + sum6 + sum7 + sum8 + sum9
+ + sum10 + sum11 + sum12 + sum13 + sum14 + sum15;
+}
+
+double
+foo (char const *buf, size_t len)
+{
+  double sum = 0;
+  size_t vl = __riscv_vsetvlmax_e8m8 ();
+  size_t step = vl * 4;
+  const char *it = buf, *end = buf + len;
+  for (; it + step <= end;)
+{
+  vint32m1_t v0 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v1 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v2 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v3 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v4 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v5 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v6 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v7 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v8 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v9 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v10 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v11 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v12 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v13 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v14 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v15 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  
+  asm volatile("nop" ::: "memory");
+  vfloat64m2_t vw0 = __riscv_vfwcvt_f_x_v_f64m2 (v0, vl);
+  vfloat64m2_t vw1 = __riscv_vfwcvt_f_x_v_f64m2 (v1, vl);
+  vfloat64m2_t vw2 = __riscv_vfwcvt_f_x_v_f64m2 (v2, vl);
+  vfloat64m2_t vw3 = __riscv_vfwcvt_f_x_v_f64m2 (v3, vl);
+  vfloat64m2_t vw4 = __riscv_v

[PATCH v1] RISC-V: Add xfail test case for highpart overlap floating-point widen insn

[pan2 . li]

From: Pan Li 

We reverted below patch for register group overlap, add the related
insn test and mark it as xfail.  And we will remove the xfail
after we support the register overlap in GCC-15.

8614cbb2534 RISC-V: Support highpart overlap for floating-point widen 
instructions

The below test suites are passed.
* The rv64gcv fully regression test.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr112431-10.c: New test.
* gcc.target/riscv/rvv/base/pr112431-11.c: New test.
* gcc.target/riscv/rvv/base/pr112431-12.c: New test.
* gcc.target/riscv/rvv/base/pr112431-13.c: New test.
* gcc.target/riscv/rvv/base/pr112431-14.c: New test.
* gcc.target/riscv/rvv/base/pr112431-15.c: New test.
* gcc.target/riscv/rvv/base/pr112431-7.c: New test.
* gcc.target/riscv/rvv/base/pr112431-8.c: New test.
* gcc.target/riscv/rvv/base/pr112431-9.c: New test.

Signed-off-by: Pan Li 
---
 .../gcc.target/riscv/rvv/base/pr112431-10.c   | 104 ++
 .../gcc.target/riscv/rvv/base/pr112431-11.c   |  68 +++
 .../gcc.target/riscv/rvv/base/pr112431-12.c   |  51 +
 .../gcc.target/riscv/rvv/base/pr112431-13.c   | 188 ++
 .../gcc.target/riscv/rvv/base/pr112431-14.c   | 119 +++
 .../gcc.target/riscv/rvv/base/pr112431-15.c   |  86 
 .../gcc.target/riscv/rvv/base/pr112431-7.c| 104 ++
 .../gcc.target/riscv/rvv/base/pr112431-8.c|  68 +++
 .../gcc.target/riscv/rvv/base/pr112431-9.c|  51 +
 9 files changed, 839 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-10.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-11.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-12.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-13.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-14.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-15.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-7.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-8.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-9.c

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-10.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-10.c
new file mode 100644
index 000..5d3f2fbe46d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-10.c
@@ -0,0 +1,104 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -O3" } */
+
+#include "riscv_vector.h"
+
+double __attribute__ ((noinline))
+sumation (double sum0, double sum1, double sum2, double sum3, double sum4,
+ double sum5, double sum6, double sum7, double sum8, double sum9,
+ double sum10, double sum11, double sum12, double sum13, double sum14,
+ double sum15)
+{
+  return sum0 + sum1 + sum2 + sum3 + sum4 + sum5 + sum6 + sum7 + sum8 + sum9
++ sum10 + sum11 + sum12 + sum13 + sum14 + sum15;
+}
+
+double
+foo (char const *buf, size_t len)
+{
+  double sum = 0;
+  size_t vl = __riscv_vsetvlmax_e8m8 ();
+  size_t step = vl * 4;
+  const char *it = buf, *end = buf + len;
+  for (; it + step <= end;)
+{
+  vint32m1_t v0 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v1 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v2 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v3 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v4 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v5 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v6 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v7 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v8 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v9 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v10 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v11 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v12 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v13 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v14 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  vint32m1_t v15 = __riscv_vle32_v_i32m1 ((void *) it, vl);
+  it += vl;
+  
+  asm volatile("nop" ::: "memory");
+  vfloat64m2_t vw0 = __riscv_vfwcvt_f_x_v_f64m2 (v0, vl);
+  vfloat64m2_t vw1 = __riscv_vfwcvt_f_x_v_f64m2 (v1, vl);
+  vfloat64m2_t vw2 = __riscv_vfwcvt_f_x_v_f64m2 (v2, vl);
+  vfloat64m2_t vw3 = __riscv_vfwcvt_f_x_v_f64m2 (v3, vl);
+  vfloat64m2_t vw4 = __riscv_vfwcvt_f_x_v_f64m2 (v4, vl);
+  vfloat64m2_t vw5 = __riscv_vfwcvt_f_x_v_f64m2 (v5, vl);
+  vfloat64m2_t vw6 = _

Re: [PATCH v2] RISC-V: Add xfail test case for indexed load overlap with SRC EEW < DEST EEW

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

LGTM



juzhe.zh...@rivai.ai
 
From: pan2.li
Date: 2024-04-22 15:43
To: gcc-patches
CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li
Subject: [PATCH v2] RISC-V: Add xfail test case for indexed load overlap with 
SRC EEW < DEST EEW
From: Pan Li 
 
Update in v2:
* Add change log to pr112431-34.c.
 
Original log:
 
We reverted below patch for register group overlap, add the related
insn test and mark it as xfail.  And we will remove the xfail
after we support the register overlap in GCC-15.
 
4418d55bcd1 RISC-V: Support highpart overlap for indexed load with SRC EEW < 
DEST EEW
 
The below test suites are passed.
* The rv64gcv fully regression test.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/base/pr112431-34.c: Remove xfail for vluxei8 check.
* gcc.target/riscv/rvv/base/pr112431-28.c: New test.
* gcc.target/riscv/rvv/base/pr112431-29.c: New test.
* gcc.target/riscv/rvv/base/pr112431-30.c: New test.
* gcc.target/riscv/rvv/base/pr112431-31.c: New test.
* gcc.target/riscv/rvv/base/pr112431-32.c: New test.
* gcc.target/riscv/rvv/base/pr112431-33.c: New test.
 
Signed-off-by: Pan Li 
---
.../gcc.target/riscv/rvv/base/pr112431-28.c   | 104 ++
.../gcc.target/riscv/rvv/base/pr112431-29.c   |  68 
.../gcc.target/riscv/rvv/base/pr112431-30.c   |  51 +
.../gcc.target/riscv/rvv/base/pr112431-31.c   |  68 
.../gcc.target/riscv/rvv/base/pr112431-32.c   |  51 +
.../gcc.target/riscv/rvv/base/pr112431-33.c   |  51 +
.../gcc.target/riscv/rvv/base/pr112431-34.c   |   2 +-
7 files changed, 394 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-28.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-29.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-30.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-31.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-32.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-33.c
 
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-28.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-28.c
new file mode 100644
index 000..c16cbdfe9f9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-28.c
@@ -0,0 +1,104 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -O3" } */
+
+#include "riscv_vector.h"
+
+size_t __attribute__ ((noinline))
+sumation (size_t sum0, size_t sum1, size_t sum2, size_t sum3, size_t sum4,
+   size_t sum5, size_t sum6, size_t sum7, size_t sum8, size_t sum9,
+   size_t sum10, size_t sum11, size_t sum12, size_t sum13, size_t sum14,
+   size_t sum15)
+{
+  return sum0 + sum1 + sum2 + sum3 + sum4 + sum5 + sum6 + sum7 + sum8 + sum9
+ + sum10 + sum11 + sum12 + sum13 + sum14 + sum15;
+}
+
+size_t
+foo (char const *buf, size_t len)
+{
+  size_t sum = 0;
+  size_t vl = __riscv_vsetvlmax_e8m8 ();
+  size_t step = vl * 4;
+  const char *it = buf, *end = buf + len;
+  for (; it + step <= end;)
+{
+  vuint8m1_t v0 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v1 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v2 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v3 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v4 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v5 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v6 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v7 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v8 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v9 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v10 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v11 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v12 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v13 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v14 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v15 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  
+  asm volatile("nop" ::: "memory");
+  vint16m2_t vw0 = __riscv_vluxei8_v_i16m2 ((void *) it, v0, vl);
+  vint16m2_t vw1 = __riscv_vluxei8_v_i16m2 ((void *) it, v1, vl);
+  vint16m2_t vw2 = __riscv_vluxei8_v_i16m2 ((void *) it, v2, vl);
+  vint16m2_t vw3 = __riscv_vluxei8_v_i16m2 ((void *) it, v3, vl);
+  vint16m2_t vw4 = __riscv_vluxei8_v_i16m2 ((void *) it, v4, vl);
+  vint16m2_t vw5 = __riscv_vluxei8_v_i16m2 ((void *) it, v5, vl);
+  vint16m2_t vw6 = __riscv_vluxei8_v_i16m2 ((void *) it, v6, vl);
+  vint16m2_t vw7 = __riscv_vluxei8_v_i16m2 ((void *) it, v7, vl);
+  vint16m2_t vw8 = __riscv_vluxei8_v_i16m2 ((void *) it, v8, vl);
+ 

[PATCH v2] RISC-V: Add xfail test case for indexed load overlap with SRC EEW < DEST EEW

[pan2 . li]

From: Pan Li 

Update in v2:
* Add change log to pr112431-34.c.

Original log:

We reverted below patch for register group overlap, add the related
insn test and mark it as xfail.  And we will remove the xfail
after we support the register overlap in GCC-15.

4418d55bcd1 RISC-V: Support highpart overlap for indexed load with SRC EEW < 
DEST EEW

The below test suites are passed.
* The rv64gcv fully regression test.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr112431-34.c: Remove xfail for vluxei8 
check.
* gcc.target/riscv/rvv/base/pr112431-28.c: New test.
* gcc.target/riscv/rvv/base/pr112431-29.c: New test.
* gcc.target/riscv/rvv/base/pr112431-30.c: New test.
* gcc.target/riscv/rvv/base/pr112431-31.c: New test.
* gcc.target/riscv/rvv/base/pr112431-32.c: New test.
* gcc.target/riscv/rvv/base/pr112431-33.c: New test.

Signed-off-by: Pan Li 
---
 .../gcc.target/riscv/rvv/base/pr112431-28.c   | 104 ++
 .../gcc.target/riscv/rvv/base/pr112431-29.c   |  68 
 .../gcc.target/riscv/rvv/base/pr112431-30.c   |  51 +
 .../gcc.target/riscv/rvv/base/pr112431-31.c   |  68 
 .../gcc.target/riscv/rvv/base/pr112431-32.c   |  51 +
 .../gcc.target/riscv/rvv/base/pr112431-33.c   |  51 +
 .../gcc.target/riscv/rvv/base/pr112431-34.c   |   2 +-
 7 files changed, 394 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-28.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-29.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-30.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-31.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-32.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-33.c

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-28.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-28.c
new file mode 100644
index 000..c16cbdfe9f9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-28.c
@@ -0,0 +1,104 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -O3" } */
+
+#include "riscv_vector.h"
+
+size_t __attribute__ ((noinline))
+sumation (size_t sum0, size_t sum1, size_t sum2, size_t sum3, size_t sum4,
+ size_t sum5, size_t sum6, size_t sum7, size_t sum8, size_t sum9,
+ size_t sum10, size_t sum11, size_t sum12, size_t sum13, size_t sum14,
+ size_t sum15)
+{
+  return sum0 + sum1 + sum2 + sum3 + sum4 + sum5 + sum6 + sum7 + sum8 + sum9
++ sum10 + sum11 + sum12 + sum13 + sum14 + sum15;
+}
+
+size_t
+foo (char const *buf, size_t len)
+{
+  size_t sum = 0;
+  size_t vl = __riscv_vsetvlmax_e8m8 ();
+  size_t step = vl * 4;
+  const char *it = buf, *end = buf + len;
+  for (; it + step <= end;)
+{
+  vuint8m1_t v0 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v1 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v2 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v3 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v4 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v5 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v6 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v7 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v8 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v9 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v10 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v11 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v12 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v13 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v14 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v15 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  
+  asm volatile("nop" ::: "memory");
+  vint16m2_t vw0 = __riscv_vluxei8_v_i16m2 ((void *) it, v0, vl);
+  vint16m2_t vw1 = __riscv_vluxei8_v_i16m2 ((void *) it, v1, vl);
+  vint16m2_t vw2 = __riscv_vluxei8_v_i16m2 ((void *) it, v2, vl);
+  vint16m2_t vw3 = __riscv_vluxei8_v_i16m2 ((void *) it, v3, vl);
+  vint16m2_t vw4 = __riscv_vluxei8_v_i16m2 ((void *) it, v4, vl);
+  vint16m2_t vw5 = __riscv_vluxei8_v_i16m2 ((void *) it, v5, vl);
+  vint16m2_t vw6 = __riscv_vluxei8_v_i16m2 ((void *) it, v6, vl);
+  vint16m2_t vw7 = __riscv_vluxei8_v_i16m2 ((void *) it, v7, vl);
+  vint16m2_t vw8 = __riscv_vluxei8_v_i16m2 ((void *) it, v8, vl);
+  vint16m2_t vw9 = __riscv_vluxei8_v_i16m2 ((void *) it, v9, vl);
+  vint16m2_t vw10 = __riscv_vluxei8_v_i16m2 ((void *) it, v10, vl);
+   

[PATCH v1] RISC-V: Add xfail test case for indexed load overlap with SRC EEW < DEST EEW

[pan2 . li]

From: Pan Li 

We reverted below patch for register group overlap, add the related
insn test and mark it as xfail.  And we will remove the xfail
after we support the register overlap in GCC-15.

4418d55bcd1 RISC-V: Support highpart overlap for indexed load with SRC EEW < 
DEST EEW

The below test suites are passed.
* The rv64gcv fully regression test.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr112431-34.c:
* gcc.target/riscv/rvv/base/pr112431-28.c: New test.
* gcc.target/riscv/rvv/base/pr112431-29.c: New test.
* gcc.target/riscv/rvv/base/pr112431-30.c: New test.
* gcc.target/riscv/rvv/base/pr112431-31.c: New test.
* gcc.target/riscv/rvv/base/pr112431-32.c: New test.
* gcc.target/riscv/rvv/base/pr112431-33.c: New test.

Signed-off-by: Pan Li 
---
 .../gcc.target/riscv/rvv/base/pr112431-28.c   | 104 ++
 .../gcc.target/riscv/rvv/base/pr112431-29.c   |  68 
 .../gcc.target/riscv/rvv/base/pr112431-30.c   |  51 +
 .../gcc.target/riscv/rvv/base/pr112431-31.c   |  68 
 .../gcc.target/riscv/rvv/base/pr112431-32.c   |  51 +
 .../gcc.target/riscv/rvv/base/pr112431-33.c   |  51 +
 .../gcc.target/riscv/rvv/base/pr112431-34.c   |   2 +-
 7 files changed, 394 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-28.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-29.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-30.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-31.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-32.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-33.c

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-28.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-28.c
new file mode 100644
index 000..c16cbdfe9f9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-28.c
@@ -0,0 +1,104 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -O3" } */
+
+#include "riscv_vector.h"
+
+size_t __attribute__ ((noinline))
+sumation (size_t sum0, size_t sum1, size_t sum2, size_t sum3, size_t sum4,
+ size_t sum5, size_t sum6, size_t sum7, size_t sum8, size_t sum9,
+ size_t sum10, size_t sum11, size_t sum12, size_t sum13, size_t sum14,
+ size_t sum15)
+{
+  return sum0 + sum1 + sum2 + sum3 + sum4 + sum5 + sum6 + sum7 + sum8 + sum9
++ sum10 + sum11 + sum12 + sum13 + sum14 + sum15;
+}
+
+size_t
+foo (char const *buf, size_t len)
+{
+  size_t sum = 0;
+  size_t vl = __riscv_vsetvlmax_e8m8 ();
+  size_t step = vl * 4;
+  const char *it = buf, *end = buf + len;
+  for (; it + step <= end;)
+{
+  vuint8m1_t v0 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v1 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v2 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v3 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v4 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v5 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v6 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v7 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v8 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v9 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v10 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v11 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v12 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v13 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v14 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  vuint8m1_t v15 = __riscv_vle8_v_u8m1 ((void *) it, vl);
+  it += vl;
+  
+  asm volatile("nop" ::: "memory");
+  vint16m2_t vw0 = __riscv_vluxei8_v_i16m2 ((void *) it, v0, vl);
+  vint16m2_t vw1 = __riscv_vluxei8_v_i16m2 ((void *) it, v1, vl);
+  vint16m2_t vw2 = __riscv_vluxei8_v_i16m2 ((void *) it, v2, vl);
+  vint16m2_t vw3 = __riscv_vluxei8_v_i16m2 ((void *) it, v3, vl);
+  vint16m2_t vw4 = __riscv_vluxei8_v_i16m2 ((void *) it, v4, vl);
+  vint16m2_t vw5 = __riscv_vluxei8_v_i16m2 ((void *) it, v5, vl);
+  vint16m2_t vw6 = __riscv_vluxei8_v_i16m2 ((void *) it, v6, vl);
+  vint16m2_t vw7 = __riscv_vluxei8_v_i16m2 ((void *) it, v7, vl);
+  vint16m2_t vw8 = __riscv_vluxei8_v_i16m2 ((void *) it, v8, vl);
+  vint16m2_t vw9 = __riscv_vluxei8_v_i16m2 ((void *) it, v9, vl);
+  vint16m2_t vw10 = __riscv_vluxei8_v_i16m2 ((void *) it, v10, vl);
+  vint16m2_t vw11 = __riscv_vluxei8_v_i16m2 ((void *) it, v11, vl);
+  vint16m2_t vw12 = __ri

Re: [PATCH V4 1/3] aarch64: Place target independent and dependent changed code in one file

[Ajit Agarwal]

Hello Alex:

On 14/04/24 10:29 pm, Ajit Agarwal wrote:
> Hello Alex:
> 
> On 12/04/24 11:02 pm, Ajit Agarwal wrote:
>> Hello Alex:
>>
>> On 12/04/24 8:15 pm, Alex Coplan wrote:
>>> On 12/04/2024 20:02, Ajit Agarwal wrote:
 Hello Alex:

 On 11/04/24 7:55 pm, Alex Coplan wrote:
> On 10/04/2024 23:48, Ajit Agarwal wrote:
>> Hello Alex:
>>
>> On 10/04/24 7:52 pm, Alex Coplan wrote:
>>> Hi Ajit,
>>>
>>> On 10/04/2024 15:31, Ajit Agarwal wrote:
 Hello Alex:

 On 10/04/24 1:42 pm, Alex Coplan wrote:
> Hi Ajit,
>
> On 09/04/2024 20:59, Ajit Agarwal wrote:
>> Hello Alex:
>>
>> On 09/04/24 8:39 pm, Alex Coplan wrote:
>>> On 09/04/2024 20:01, Ajit Agarwal wrote:
 Hello Alex:

 On 09/04/24 7:29 pm, Alex Coplan wrote:
> On 09/04/2024 17:30, Ajit Agarwal wrote:
>>
>>
>> On 05/04/24 10:03 pm, Alex Coplan wrote:
>>> On 05/04/2024 13:53, Ajit Agarwal wrote:
 Hello Alex/Richard:

 All review comments are incorporated.
>>> 
 @@ -2890,8 +3018,8 @@ ldp_bb_info::merge_pairs (insn_list_t 
 &left_list,
  // of accesses.  If we find two sets of adjacent accesses, 
 call
  // merge_pairs.
  void
 -ldp_bb_info::transform_for_base (int encoded_lfs,
 -   access_group &group)
 +pair_fusion_bb_info::transform_for_base (int encoded_lfs,
 +   access_group &group)
  {
const auto lfs = decode_lfs (encoded_lfs);
const unsigned access_size = lfs.size;
 @@ -2909,7 +3037,7 @@ ldp_bb_info::transform_for_base (int 
 encoded_lfs,
   access.cand_insns,
   lfs.load_p,
   access_size);
 -skip_next = access.cand_insns.empty ();
 +skip_next = bb_state->cand_insns_empty_p 
 (access.cand_insns);
>>>
>>> As above, why is this needed?
>>
>> For rs6000 we want to return always true. as load store pair
>> that are to be merged with 8/16 16/32 32/64 is occuring for 
>> rs6000.
>> And we want load store pair to 8/16 32/64. Thats why we want
>> to generate always true for rs6000 to skip pairs as above.
>
> Hmm, sorry, I'm not sure I follow.  Are you saying that for 
> rs6000 you have
> load/store pair instructions where the two arms of the access are 
> storing
> operands of different sizes?  Or something else?
>
> As it stands the logic is to skip the next iteration only if we
> exhausted all the candidate insns for the current access.  In the 
> case
> that we didn't exhaust all such candidates, then the idea is that 
> when
> access becomes prev_access, we can attempt to use those 
> candidates as
> the "left-hand side" of a pair in the next iteration since we 
> failed to
> use them as the "right-hand side" of a pair in the current 
> iteration.
> I don't see why you wouldn't want that behaviour.  Please can you
> explain?
>

 In merge_pair we get the 2 load candiates one load from 0 offset 
 and
 other load is from 16th offset. Then in next iteration we get load
 from 16th offset and other load from 32 offset. In next iteration
 we get load from 32 offset and other load from 48 offset.

 For example:

 Currently we get the load candiates as follows.

 pairs:

 load from 0th offset.
 load from 16th offset.

 next pairs:

 load from 16th offset.
 load from 32th offset.

 next pairs:

 load from 32th offset
 load from 48th offset.

 Instead in rs6000 we should get:

 pairs:

 load from 0th offset
 load from 16th offset.

 next pairs:

 load from 32th offset
 load from 48th offset.
>>>
>>> Hmm, so then I guess my question is: why wouldn't you consider 
>>> merging
>>> the pair with offsets (16,32) for rs6000?  Is i