Re: gcc-12+: D / phobos runtime

[ASSI]

Rainer Orth writes:
> Just try to configure gcc with --enable-libphobos, which overrides the
> default of LIBPHOBOS_SUPPORTED.  In quite a number of cases, this just
> works, but hasn't yet been verified.  You won't know until you try,
> though.

I did that and it indeed doesn't build.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

[Bug c/111398] New: GCC should warn if a struct with flexible array member is declared static or onstack

[tg at mirbsd dot org via Gcc-bugs]

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

Bug ID: 111398
   Summary: GCC should warn if a struct with flexible array member
is declared static or onstack
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tg at mirbsd dot org
  Target Milestone: ---

If I have (-std=c99 and up) a…

struct foo {
size_t len;
char buf[];
};

… then I would like to be warned (at least with -Wextra or something) if I do
either of…

static struct foo a;  // this
struct foo b; // this
extern struct foo x;  // and probably even this!
void bla(void) {
static struct foo c;  // this
struct foo d; // and this
}

(Probably the same for GCC’s char buf[0]; extension.)

Re: [committed] RISC-V: Remove redundant ABI test

[Kito Cheng via Gcc-patches]

lgtm

On Wed, Sep 13, 2023 at 11:23 AM Juzhe-Zhong  wrote:
>
> We only support and report warning for RVV types.
>
> We don't report warning for GNU vectors.
> So this testcase checking is incorrect and the FAIL is bogus.
>
> Remove it and commit it.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/base/vector-abi-9.c: Removed.
>
> ---
>  .../gcc.target/riscv/rvv/base/vector-abi-9.c | 16 
>  1 file changed, 16 deletions(-)
>  delete mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vector-abi-9.c
>
> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/vector-abi-9.c 
> b/gcc/testsuite/gcc.target/riscv/rvv/base/vector-abi-9.c
> deleted file mode 100644
> index b5f130f0caf..000
> --- a/gcc/testsuite/gcc.target/riscv/rvv/base/vector-abi-9.c
> +++ /dev/null
> @@ -1,16 +0,0 @@
> -/* { dg-do compile } */
> -/* { dg-options "-march=rv64gcv -mabi=lp64d 
> --param=riscv-autovec-preference=fixed-vlmax" } */
> -
> -#include "riscv_vector.h"
> -
> -typedef int v4si __attribute__ ((vector_size (16)));
> -
> -v4si
> -fun (v4si a) {  return a; }  /* { dg-warning "the vector type" } */
> -
> -void
> -bar ()
> -{
> -  v4si a;
> -  fun (a);
> -}
> --
> 2.36.3
>

[PATCH v4 12/22] LoongArch: Add tests for ASX builtin functions.

[Xiaolong Chen]

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vector/lasx/lasx-builtin.c: New test.
---
 .../loongarch/vector/lasx/lasx-builtin.c  | 1509 +
 1 file changed, 1509 insertions(+)
 create mode 100644 
gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-builtin.c

diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-builtin.c 
b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-builtin.c
new file mode 100644
index 000..ecb8d639bdd
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-builtin.c
@@ -0,0 +1,1509 @@
+/* Test builtins for LOONGARCH LASX ASE instructions */
+/* { dg-do compile } */
+/* { dg-options "-mlasx" } */
+/* { dg-final { scan-assembler-times "lasx_xvsll_b:.*xvsll\\.b.*lasx_xvsll_b" 
1 } } */
+/* { dg-final { scan-assembler-times "lasx_xvsll_h:.*xvsll\\.h.*lasx_xvsll_h" 
1 } } */
+/* { dg-final { scan-assembler-times "lasx_xvsll_w:.*xvsll\\.w.*lasx_xvsll_w" 
1 } } */
+/* { dg-final { scan-assembler-times "lasx_xvsll_d:.*xvsll\\.d.*lasx_xvsll_d" 
1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvslli_b:.*xvslli\\.b.*lasx_xvslli_b" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvslli_h:.*xvslli\\.h.*lasx_xvslli_h" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvslli_w:.*xvslli\\.w.*lasx_xvslli_w" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvslli_d:.*xvslli\\.d.*lasx_xvslli_d" 1 } } */
+/* { dg-final { scan-assembler-times "lasx_xvsra_b:.*xvsra\\.b.*lasx_xvsra_b" 
1 } } */
+/* { dg-final { scan-assembler-times "lasx_xvsra_h:.*xvsra\\.h.*lasx_xvsra_h" 
1 } } */
+/* { dg-final { scan-assembler-times "lasx_xvsra_w:.*xvsra\\.w.*lasx_xvsra_w" 
1 } } */
+/* { dg-final { scan-assembler-times "lasx_xvsra_d:.*xvsra\\.d.*lasx_xvsra_d" 
1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrai_b:.*xvsrai\\.b.*lasx_xvsrai_b" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrai_h:.*xvsrai\\.h.*lasx_xvsrai_h" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrai_w:.*xvsrai\\.w.*lasx_xvsrai_w" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrai_d:.*xvsrai\\.d.*lasx_xvsrai_d" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrar_b:.*xvsrar\\.b.*lasx_xvsrar_b" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrar_h:.*xvsrar\\.h.*lasx_xvsrar_h" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrar_w:.*xvsrar\\.w.*lasx_xvsrar_w" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrar_d:.*xvsrar\\.d.*lasx_xvsrar_d" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrari_b:.*xvsrari\\.b.*lasx_xvsrari_b" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrari_h:.*xvsrari\\.h.*lasx_xvsrari_h" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrari_w:.*xvsrari\\.w.*lasx_xvsrari_w" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrari_d:.*xvsrari\\.d.*lasx_xvsrari_d" 1 } } */
+/* { dg-final { scan-assembler-times "lasx_xvsrl_b:.*xvsrl\\.b.*lasx_xvsrl_b" 
1 } } */
+/* { dg-final { scan-assembler-times "lasx_xvsrl_h:.*xvsrl\\.h.*lasx_xvsrl_h" 
1 } } */
+/* { dg-final { scan-assembler-times "lasx_xvsrl_w:.*xvsrl\\.w.*lasx_xvsrl_w" 
1 } } */
+/* { dg-final { scan-assembler-times "lasx_xvsrl_d:.*xvsrl\\.d.*lasx_xvsrl_d" 
1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrli_b:.*xvsrli\\.b.*lasx_xvsrli_b" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrli_h:.*xvsrli\\.h.*lasx_xvsrli_h" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrli_w:.*xvsrli\\.w.*lasx_xvsrli_w" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrli_d:.*xvsrli\\.d.*lasx_xvsrli_d" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrlr_b:.*xvsrlr\\.b.*lasx_xvsrlr_b" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrlr_h:.*xvsrlr\\.h.*lasx_xvsrlr_h" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrlr_w:.*xvsrlr\\.w.*lasx_xvsrlr_w" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrlr_d:.*xvsrlr\\.d.*lasx_xvsrlr_d" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrlri_b:.*xvsrlri\\.b.*lasx_xvsrlri_b" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrlri_h:.*xvsrlri\\.h.*lasx_xvsrlri_h" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrlri_w:.*xvsrlri\\.w.*lasx_xvsrlri_w" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvsrlri_d:.*xvsrlri\\.d.*lasx_xvsrlri_d" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvbitclr_b:.*xvbitclr\\.b.*lasx_xvbitclr_b" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvbitclr_h:.*xvbitclr\\.h.*lasx_xvbitclr_h" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvbitclr_w:.*xvbitclr\\.w.*lasx_xvbitclr_w" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvbitclr_d:.*xvbitclr\\.d.*lasx_xvbitclr_d" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvbitclri_b:.*xvbitclri\\.b.*lasx_xvbitclri_b" 1 } } */
+/* { dg-final { scan-assembler-times 
"lasx_xvbitclri_h:.*xvbitclri\\.h.*lasx_xvbitclri_h" 1 } } */
+/* { dg-final { scan-assembler-times 

[PATCH v4 13/22] LoongArch: Add tests for ASX xvldrepl/xvstelm instruction generation.

[Xiaolong Chen]

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vector/lasx/lasx-xvldrepl.c: New test.
* gcc.target/loongarch/vector/lasx/lasx-xvstelm.c: New test.
---
 .../loongarch/vector/lasx/lasx-xvldrepl.c| 16 
 .../loongarch/vector/lasx/lasx-xvstelm.c | 14 ++
 2 files changed, 30 insertions(+)
 create mode 100644 
gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvldrepl.c
 create mode 100644 
gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvstelm.c

diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvldrepl.c 
b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvldrepl.c
new file mode 100644
index 000..10556795119
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvldrepl.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -mlasx" } */
+/* { dg-final { scan-assembler-times "xvldrepl.w" 2} } */
+
+#define N 258
+
+float a[N], b[N], c[N];
+
+void
+test ()
+{
+  for (int i = 0; i < 256; i++)
+{
+  a[i] = c[0] * b[i] + c[1];
+}
+}
diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvstelm.c 
b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvstelm.c
new file mode 100644
index 000..1a7b0e86f8b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvstelm.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -mlasx" } */
+/* { dg-final { scan-assembler-times "xvstelm.w" 8} } */
+
+#define LEN 256
+
+float a[LEN], b[LEN], c[LEN];
+
+void
+test ()
+{
+  for (int i = 0; i < LEN; i += 2)
+a[i] = b[i] + c[i];
+}
-- 
2.20.1

[PATCH v4 07/22] LoongArch: Add tests for ASX vector xvand/xvandi/xvandn/xvor/xvori/ xvnor/xvnori/xvxor/xvxori instructions.

[Xiaolong Chen]

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vector/lasx/lasx-xvand.c: New test.
* gcc.target/loongarch/vector/lasx/lasx-xvandi.c: New test.
* gcc.target/loongarch/vector/lasx/lasx-xvandn.c: New test.
* gcc.target/loongarch/vector/lasx/lasx-xvnor.c: New test.
* gcc.target/loongarch/vector/lasx/lasx-xvnori.c: New test.
* gcc.target/loongarch/vector/lasx/lasx-xvor.c: New test.
* gcc.target/loongarch/vector/lasx/lasx-xvori.c: New test.
* gcc.target/loongarch/vector/lasx/lasx-xvorn.c: New test.
* gcc.target/loongarch/vector/lasx/lasx-xvxor.c: New test.
* gcc.target/loongarch/vector/lasx/lasx-xvxori.c: New test.
---
 .../loongarch/vector/lasx/lasx-xvand.c| 155 +++
 .../loongarch/vector/lasx/lasx-xvandi.c   | 196 ++
 .../loongarch/vector/lasx/lasx-xvandn.c   | 125 +
 .../loongarch/vector/lasx/lasx-xvnor.c| 170 
 .../loongarch/vector/lasx/lasx-xvnori.c   | 152 +++
 .../loongarch/vector/lasx/lasx-xvor.c | 215 +++
 .../loongarch/vector/lasx/lasx-xvori.c| 141 ++
 .../loongarch/vector/lasx/lasx-xvorn.c| 245 ++
 .../loongarch/vector/lasx/lasx-xvxor.c| 185 +
 .../loongarch/vector/lasx/lasx-xvxori.c   | 163 
 10 files changed, 1747 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvand.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvandi.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvandn.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvnor.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvnori.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvor.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvori.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvorn.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvxor.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvxori.c

diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvand.c 
b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvand.c
new file mode 100644
index 000..e485786dd3b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvand.c
@@ -0,0 +1,155 @@
+/* { dg-do run } */
+/* { dg-options "-mlasx -w -fno-strict-aliasing" } */
+#include "../simd_correctness_check.h"
+#include 
+
+int
+main ()
+{
+  __m256i __m256i_op0, __m256i_op1, __m256i_op2, __m256i_out, __m256i_result;
+  __m256 __m256_op0, __m256_op1, __m256_op2, __m256_out, __m256_result;
+  __m256d __m256d_op0, __m256d_op1, __m256d_op2, __m256d_out, __m256d_result;
+
+  int int_op0, int_op1, int_op2, int_out, int_result, i = 1, fail;
+  long int long_op0, long_op1, long_op2, lont_out, lont_result;
+  long int long_int_out, long_int_result;
+  unsigned int unsigned_int_out, unsigned_int_result;
+  unsigned long int unsigned_long_int_out, unsigned_long_int_result;
+
+  *((unsigned long *)&__m256i_op0[3]) = 0x;
+  *((unsigned long *)&__m256i_op0[2]) = 0x;
+  *((unsigned long *)&__m256i_op0[1]) = 0x;
+  *((unsigned long *)&__m256i_op0[0]) = 0x;
+  *((unsigned long *)&__m256i_op1[3]) = 0x0010001000100010;
+  *((unsigned long *)&__m256i_op1[2]) = 0x0010001000100010;
+  *((unsigned long *)&__m256i_op1[1]) = 0x0010001000100010;
+  *((unsigned long *)&__m256i_op1[0]) = 0x0010001000100010;
+  *((unsigned long *)&__m256i_result[3]) = 0x;
+  *((unsigned long *)&__m256i_result[2]) = 0x;
+  *((unsigned long *)&__m256i_result[1]) = 0x;
+  *((unsigned long *)&__m256i_result[0]) = 0x;
+  __m256i_out = __lasx_xvand_v (__m256i_op0, __m256i_op1);
+  ASSERTEQ_64 (__LINE__, __m256i_result, __m256i_out);
+
+  *((unsigned long *)&__m256i_op0[3]) = 0x;
+  *((unsigned long *)&__m256i_op0[2]) = 0x;
+  *((unsigned long *)&__m256i_op0[1]) = 0x;
+  *((unsigned long *)&__m256i_op0[0]) = 0x;
+  *((unsigned long *)&__m256i_op1[3]) = 0x;
+  *((unsigned long *)&__m256i_op1[2]) = 0x;
+  *((unsigned long *)&__m256i_op1[1]) = 0x;
+  *((unsigned long *)&__m256i_op1[0]) = 0x;
+  *((unsigned long *)&__m256i_result[3]) = 0x;
+  *((unsigned long *)&__m256i_result[2]) = 0x;
+  *((unsigned long *)&__m256i_result[1]) = 0x;
+  *((unsigned long *)&__m256i_result[0]) = 0x;
+  __m256i_out = __lasx_xvand_v (__m256i_op0, __m256i_op1);
+  ASSERTEQ_64 (__LINE__, __m256i_result, __m256i_out);
+
+  *((unsigned long *)&__m256i_op0[3]) = 0x;
+  *((unsigned long 

[PATCH v4 00/22] Added support for ASX vector instructions.

[Xiaolong Chen]

  In order to better test the function of the vector instruction, the 256
bit test cases are further split according to the function of the instruction.


Xiaolong Chen (22):
  LoongArch: Add tests for ASX vector xvadd/xvadda/xvaddi/xvaddwev/
xvaddwodxvsadd instructions.
  LoongArch: Add tests for ASX vector xvhadd/xvhaddw/xvmaddwev/xvmaddwod
instructions.
  LoongArch: Add tests for ASX vector subtraction instructions.
  LoongArch: Add tests for ASX vector xvmul/xvmod/xvdiv instructions.
  LoongArch: Add tests for ASX vector xvmax/xvmaxi/xvmin/xvmini
instructions.
  LoongArch: Add tests for ASX vector
xvldi/xvmskgez/xvmskltz/xvmsknz/xvmuh /xvsigncov instructions.
  LoongArch: Add tests for ASX vector xvand/xvandi/xvandn/xvor/xvori/
xvnor/xvnori/xvxor/xvxori instructions.
  LoongArch: Add tests for ASX vector xvsll/xvsrl instructions.
  LoongArch: Add tests for ASX vector xvextl/xvsra/xvsran/xvsrarn
instructions.
  LoongArch: Add tests for ASX vector
xvssran/xvssrani/xvssrarn/xvssrarni/xvssrln/
xvssrlni/xvssrlrn/xvssrlrni instructions.
  LoongArch: Add tests for ASX vector
xvbitclr/xvbitclri/xvbitrev/xvbitrevi/
xvbitsel/xvbitseli/xvbitset/xvbitseti/xvclo/xvclz/xvpcnt
instructions.
  LoongArch: Add tests for ASX builtin functions.
  LoongArch: Add tests for ASX xvldrepl/xvstelm instruction generation.
  LoongArch: Add tests for ASX vector floating-point operation
instruction.
  LoongArch: Add tests for ASX vector floating-point conversion
instruction.
  LoongArch: Add tests for ASX vector comparison and selection
instruction.
  LoongArch: Add tests for ASX vector xvfnmadd/xvfrstp/xvfstpi/xvhsubw/
xvmsub/xvrotr/xvrotri/xvld/xvst instructions.
  LoongArch: Add tests for ASX vector
xvabsd/xvavg/xvavgr/xvbsll/xvbsrl/xvneg/ xvsat instructions.
  LoongArch: Add tests for ASX vector
xvfcmp{caf/ceq/cle/clt/cne/cor/cun} instructions.
  LoongArch: Add tests for ASX vector
xvfcmp{saf/seq/sle/slt/sne/sor/sun} instructions.
  LoongArch: Add tests for ASX vector
xvext2xv/xvexth/xvextins/xvilvh/xvilvl/xvinsgr2vr/
xvinsve0/xvprem/xvpremi instructions.
  LoongArch: Add tests for ASX vector
xvpackev/xvpackod/xvpickev/xvpickod/
xvpickve2gr/xvreplgr2vr/xvreplve/xvreplve0/xvreplvei/xvshuf4i/xvshuf
instructions.

 .../loongarch/vector/lasx/lasx-builtin.c  | 1509 
 .../loongarch/vector/lasx/lasx-xvabsd-1.c |  485 +
 .../loongarch/vector/lasx/lasx-xvabsd-2.c |  650 +++
 .../loongarch/vector/lasx/lasx-xvadd.c|  725 
 .../loongarch/vector/lasx/lasx-xvadda.c   |  785 
 .../loongarch/vector/lasx/lasx-xvaddi.c   |  427 +
 .../loongarch/vector/lasx/lasx-xvaddwev-1.c   |  740 
 .../loongarch/vector/lasx/lasx-xvaddwev-2.c   |  485 +
 .../loongarch/vector/lasx/lasx-xvaddwev-3.c   |  515 ++
 .../loongarch/vector/lasx/lasx-xvaddwod-1.c   |  530 ++
 .../loongarch/vector/lasx/lasx-xvaddwod-2.c   |  560 ++
 .../loongarch/vector/lasx/lasx-xvaddwod-3.c   |  485 +
 .../loongarch/vector/lasx/lasx-xvand.c|  155 ++
 .../loongarch/vector/lasx/lasx-xvandi.c   |  196 ++
 .../loongarch/vector/lasx/lasx-xvandn.c   |  125 ++
 .../loongarch/vector/lasx/lasx-xvavg-1.c  |  680 +++
 .../loongarch/vector/lasx/lasx-xvavg-2.c  |  560 ++
 .../loongarch/vector/lasx/lasx-xvavgr-1.c |  770 
 .../loongarch/vector/lasx/lasx-xvavgr-2.c |  650 +++
 .../loongarch/vector/lasx/lasx-xvbitclr.c |  635 +++
 .../loongarch/vector/lasx/lasx-xvbitclri.c|  515 ++
 .../loongarch/vector/lasx/lasx-xvbitrev.c |  650 +++
 .../loongarch/vector/lasx/lasx-xvbitrevi.c|  317 
 .../loongarch/vector/lasx/lasx-xvbitsel.c |  134 ++
 .../loongarch/vector/lasx/lasx-xvbitseli.c|  185 ++
 .../loongarch/vector/lasx/lasx-xvbitset.c |  620 +++
 .../loongarch/vector/lasx/lasx-xvbitseti.c|  405 +
 .../loongarch/vector/lasx/lasx-xvbsll_v.c |  130 ++
 .../loongarch/vector/lasx/lasx-xvbsrl_v.c |   64 +
 .../loongarch/vector/lasx/lasx-xvclo.c|  449 +
 .../loongarch/vector/lasx/lasx-xvclz.c|  504 ++
 .../loongarch/vector/lasx/lasx-xvdiv-1.c  |  485 +
 .../loongarch/vector/lasx/lasx-xvdiv-2.c  |  500 ++
 .../loongarch/vector/lasx/lasx-xvext2xv-1.c   |  515 ++
 .../loongarch/vector/lasx/lasx-xvext2xv-2.c   |  669 +++
 .../loongarch/vector/lasx/lasx-xvexth-1.c |  350 
 .../loongarch/vector/lasx/lasx-xvexth-2.c |  592 ++
 .../loongarch/vector/lasx/lasx-xvextl-1.c |   86 +
 .../loongarch/vector/lasx/lasx-xvextl-2.c |  163 ++
 .../loongarch/vector/lasx/lasx-xvextrins.c|  515 ++
 .../loongarch/vector/lasx/lasx-xvfadd_d.c |  545 ++
 .../loongarch/vector/lasx/lasx-xvfadd_s.c |  911 ++
 .../loongarch/vector/lasx/lasx-xvfclass_d.c   |  152 ++
 .../loongarch/vector/lasx/lasx-xvfclass_s.c   |   95 +
 

[PATCH v4 23/23] LoongArch: Add tests for SX vector vfmadd/vfnmadd/vld/vst instructions.

[Xiaolong Chen]

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vector/lsx/lsx-vfmadd_d.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vfmadd_s.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vfnmadd_d.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vfnmadd_s.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vld.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vst.c: New test.
---
 .../loongarch/vector/lsx/lsx-vfmadd_d.c   | 251 
 .../loongarch/vector/lsx/lsx-vfmadd_s.c   | 381 ++
 .../loongarch/vector/lsx/lsx-vfnmadd_d.c  | 196 +
 .../loongarch/vector/lsx/lsx-vfnmadd_s.c  | 381 ++
 .../gcc.target/loongarch/vector/lsx/lsx-vld.c |  62 +++
 .../gcc.target/loongarch/vector/lsx/lsx-vst.c |  70 
 6 files changed, 1341 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfmadd_d.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfmadd_s.c
 create mode 100644 
gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfnmadd_d.c
 create mode 100644 
gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfnmadd_s.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vld.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vst.c

diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfmadd_d.c 
b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfmadd_d.c
new file mode 100644
index 000..c5de1ac7ae9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfmadd_d.c
@@ -0,0 +1,251 @@
+/* { dg-do run } */
+/* { dg-options "-mlsx -w -fno-strict-aliasing" } */
+#include "../simd_correctness_check.h"
+#include 
+
+int
+main ()
+{
+  __m128i __m128i_op0, __m128i_op1, __m128i_op2, __m128i_out, __m128i_result;
+  __m128 __m128_op0, __m128_op1, __m128_op2, __m128_out, __m128_result;
+  __m128d __m128d_op0, __m128d_op1, __m128d_op2, __m128d_out, __m128d_result;
+
+  int int_op0, int_op1, int_op2, int_out, int_result, i = 1, fail;
+  long int long_op0, long_op1, long_op2, lont_out, lont_result;
+  long int long_int_out, long_int_result;
+  unsigned int unsigned_int_out, unsigned_int_result;
+  unsigned long int unsigned_long_int_out, unsigned_long_int_result;
+
+  *((unsigned long *)&__m128d_op0[1]) = 0x;
+  *((unsigned long *)&__m128d_op0[0]) = 0x;
+  *((unsigned long *)&__m128d_op1[1]) = 0x8a228acac14e440a;
+  *((unsigned long *)&__m128d_op1[0]) = 0xc77c47cdc0f16549;
+  *((unsigned long *)&__m128d_op2[1]) = 0xd24271c4;
+  *((unsigned long *)&__m128d_op2[0]) = 0x2711bad1e8e309ed;
+  *((unsigned long *)&__m128d_result[1]) = 0xd24271c4;
+  *((unsigned long *)&__m128d_result[0]) = 0x2711bad1e8e309ed;
+  __m128d_out = __lsx_vfmadd_d (__m128d_op0, __m128d_op1, __m128d_op2);
+  ASSERTEQ_64 (__LINE__, __m128d_result, __m128d_out);
+
+  *((unsigned long *)&__m128d_op0[1]) = 0x;
+  *((unsigned long *)&__m128d_op0[0]) = 0x;
+  *((unsigned long *)&__m128d_op1[1]) = 0x;
+  *((unsigned long *)&__m128d_op1[0]) = 0x;
+  *((unsigned long *)&__m128d_op2[1]) = 0x;
+  *((unsigned long *)&__m128d_op2[0]) = 0x;
+  *((unsigned long *)&__m128d_result[1]) = 0x;
+  *((unsigned long *)&__m128d_result[0]) = 0x;
+  __m128d_out = __lsx_vfmadd_d (__m128d_op0, __m128d_op1, __m128d_op2);
+  ASSERTEQ_64 (__LINE__, __m128d_result, __m128d_out);
+
+  *((unsigned long *)&__m128d_op0[1]) = 0x04040383;
+  *((unsigned long *)&__m128d_op0[0]) = 0xe0001fff;
+  *((unsigned long *)&__m128d_op1[1]) = 0x04040383;
+  *((unsigned long *)&__m128d_op1[0]) = 0xe0001fff;
+  *((unsigned long *)&__m128d_op2[1]) = 0x0101;
+  *((unsigned long *)&__m128d_op2[0]) = 0x00010001;
+  *((unsigned long *)&__m128d_result[1]) = 0x0101;
+  *((unsigned long *)&__m128d_result[0]) = 0xe0001fff;
+  __m128d_out = __lsx_vfmadd_d (__m128d_op0, __m128d_op1, __m128d_op2);
+  ASSERTEQ_64 (__LINE__, __m128d_result, __m128d_out);
+
+  *((unsigned long *)&__m128d_op0[1]) = 0x;
+  *((unsigned long *)&__m128d_op0[0]) = 0x;
+  *((unsigned long *)&__m128d_op1[1]) = 0x003f80b0;
+  *((unsigned long *)&__m128d_op1[0]) = 0xff80;
+  *((unsigned long *)&__m128d_op2[1]) = 0x;
+  *((unsigned long *)&__m128d_op2[0]) = 0x;
+  *((unsigned long *)&__m128d_result[1]) = 0x;
+  *((unsigned long *)&__m128d_result[0]) = 0x;
+  __m128d_out = __lsx_vfmadd_d (__m128d_op0, __m128d_op1, __m128d_op2);
+  ASSERTEQ_64 (__LINE__, __m128d_result, __m128d_out);
+
+  *((unsigned long *)&__m128d_op0[1]) = 0x;
+  *((unsigned long *)&__m128d_op0[0]) = 0x00802000;
+  *((unsigned long *)&__m128d_op1[1]) = 0x00401000;
+  

[PATCH v4 22/23] LoongArch: Add tests for SX vector vand/vandi/vandn/vor/vori/vnor/ vnori/vxor/vxori instructions.

[Xiaolong Chen]

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vector/lsx/lsx-vand.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vandi.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vandn.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vnor.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vnori.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vor.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vori.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vorn.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vxor.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vxori.c: New test.
---
 .../loongarch/vector/lsx/lsx-vand.c   | 159 
 .../loongarch/vector/lsx/lsx-vandi.c  |  67 +++
 .../loongarch/vector/lsx/lsx-vandn.c  | 129 +
 .../loongarch/vector/lsx/lsx-vnor.c   | 109 +++
 .../loongarch/vector/lsx/lsx-vnori.c  |  91 ++
 .../gcc.target/loongarch/vector/lsx/lsx-vor.c | 169 ++
 .../loongarch/vector/lsx/lsx-vori.c   | 123 +
 .../loongarch/vector/lsx/lsx-vorn.c   | 109 +++
 .../loongarch/vector/lsx/lsx-vxor.c   |  79 
 .../loongarch/vector/lsx/lsx-vxori.c  |  67 +++
 10 files changed, 1102 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vand.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vandi.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vandn.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vnor.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vnori.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vor.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vori.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vorn.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vxor.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vxori.c

diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vand.c 
b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vand.c
new file mode 100644
index 000..1597749b546
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vand.c
@@ -0,0 +1,159 @@
+/* { dg-do run } */
+/* { dg-options "-mlsx -w -fno-strict-aliasing" } */
+#include "../simd_correctness_check.h"
+#include 
+
+int main ()
+{
+  __m128i __m128i_op0, __m128i_op1, __m128i_op2, __m128i_out, __m128i_result;
+  __m128 __m128_op0, __m128_op1, __m128_op2, __m128_out, __m128_result;
+  __m128d __m128d_op0, __m128d_op1, __m128d_op2, __m128d_out, __m128d_result;
+
+  int int_op0, int_op1, int_op2, int_out, int_result, i=1, fail;
+  long int long_op0, long_op1, long_op2, lont_out, lont_result;
+  long int long_int_out, long_int_result;
+  unsigned int unsigned_int_out, unsigned_int_result;
+  unsigned long int unsigned_long_int_out, unsigned_long_int_result;
+
+  *((unsigned long*)& __m128i_op0[1]) = 0x;
+  *((unsigned long*)& __m128i_op0[0]) = 0x;
+  *((unsigned long*)& __m128i_op1[1]) = 0x;
+  *((unsigned long*)& __m128i_op1[0]) = 0x;
+  *((unsigned long*)& __m128i_result[1]) = 0x;
+  *((unsigned long*)& __m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vand_v(__m128i_op0,__m128i_op1);
+  ASSERTEQ_64(__LINE__, __m128i_result, __m128i_out);
+
+
+  *((unsigned long*)& __m128i_op0[1]) = 0x;
+  *((unsigned long*)& __m128i_op0[0]) = 0x;
+  *((unsigned long*)& __m128i_op1[1]) = 0x03574e3a62407e03;
+  *((unsigned long*)& __m128i_op1[0]) = 0x0101;
+  *((unsigned long*)& __m128i_result[1]) = 0x03574e3a62407e03;
+  *((unsigned long*)& __m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vand_v(__m128i_op0,__m128i_op1);
+  ASSERTEQ_64(__LINE__, __m128i_result, __m128i_out);
+
+
+  *((unsigned long*)& __m128i_op0[1]) = 0x;
+  *((unsigned long*)& __m128i_op0[0]) = 0x;
+  *((unsigned long*)& __m128i_op1[1]) = 0x001f001f;
+  *((unsigned long*)& __m128i_op1[0]) = 0x001f001f;
+  *((unsigned long*)& __m128i_result[1]) = 0x001f001f;
+  *((unsigned long*)& __m128i_result[0]) = 0x001f001f;
+  __m128i_out = __lsx_vand_v(__m128i_op0,__m128i_op1);
+  ASSERTEQ_64(__LINE__, __m128i_result, __m128i_out);
+
+
+  *((unsigned long*)& __m128i_op0[1]) = 0x003dffc2;
+  *((unsigned long*)& __m128i_op0[0]) = 0x003dffc2;
+  *((unsigned long*)& __m128i_op1[1]) = 0x0008;
+  *((unsigned long*)& __m128i_op1[0]) = 0x;
+  *((unsigned long*)& __m128i_result[1]) = 0x;
+  *((unsigned long*)& __m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vand_v(__m128i_op0,__m128i_op1);
+  

[PATCH v4 11/23] LoongArch: Add tests for SX vector vexth/vextl/vldi/vneg/vsat instructions.

[Xiaolong Chen]

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vector/lsx/lsx-vexth-1.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vexth-2.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vextl-1.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vextl-2.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vldi.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vneg.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vsat-1.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vsat-2.c: New test.
---
 .../loongarch/vector/lsx/lsx-vexth-1.c| 342 ++
 .../loongarch/vector/lsx/lsx-vexth-2.c| 182 ++
 .../loongarch/vector/lsx/lsx-vextl-1.c|  83 +
 .../loongarch/vector/lsx/lsx-vextl-2.c|  83 +
 .../loongarch/vector/lsx/lsx-vldi.c   |  61 
 .../loongarch/vector/lsx/lsx-vneg.c   | 321 
 .../loongarch/vector/lsx/lsx-vsat-1.c | 231 
 .../loongarch/vector/lsx/lsx-vsat-2.c | 272 ++
 8 files changed, 1575 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vexth-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vexth-2.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vextl-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vextl-2.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vldi.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vneg.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vsat-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vsat-2.c

diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vexth-1.c 
b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vexth-1.c
new file mode 100644
index 000..f6390800d82
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vexth-1.c
@@ -0,0 +1,342 @@
+/* { dg-do run } */
+/* { dg-options "-mlsx -w -fno-strict-aliasing" } */
+#include "../simd_correctness_check.h"
+#include 
+
+int
+main ()
+{
+  __m128i __m128i_op0, __m128i_op1, __m128i_op2, __m128i_out, __m128i_result;
+  __m128 __m128_op0, __m128_op1, __m128_op2, __m128_out, __m128_result;
+  __m128d __m128d_op0, __m128d_op1, __m128d_op2, __m128d_out, __m128d_result;
+
+  int int_op0, int_op1, int_op2, int_out, int_result, i = 1, fail;
+  long int long_op0, long_op1, long_op2, lont_out, lont_result;
+  long int long_int_out, long_int_result;
+  unsigned int unsigned_int_out, unsigned_int_result;
+  unsigned long int unsigned_long_int_out, unsigned_long_int_result;
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vexth_h_b (__m128i_op0);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x7fff;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x007f;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vexth_h_b (__m128i_op0);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vexth_h_b (__m128i_op0);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vexth_h_b (__m128i_op0);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0xf909;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vexth_h_b (__m128i_op0);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vexth_h_b (__m128i_op0);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0xff01ff01;
+  *((unsigned long 

[PATCH v4 18/23] LoongArch: Add tests for SX vector floating point arithmetic instructions.

[Xiaolong Chen]

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vector/lsx/lsx-vfadd_d.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vfadd_s.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vfclass_d.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vfclass_s.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vflogb_d.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vflogb_s.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vfmax_d.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vfmax_s.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vfmaxa_d.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vfmaxa_s.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vfsqrt_d.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vfsqrt_s.c: New test.
---
 .../loongarch/vector/lsx/lsx-vfadd_d.c| 407 +++
 .../loongarch/vector/lsx/lsx-vfadd_s.c| 470 ++
 .../loongarch/vector/lsx/lsx-vfclass_d.c  |  83 
 .../loongarch/vector/lsx/lsx-vfclass_s.c  |  74 +++
 .../loongarch/vector/lsx/lsx-vflogb_d.c   |  76 +++
 .../loongarch/vector/lsx/lsx-vflogb_s.c   | 185 +++
 .../loongarch/vector/lsx/lsx-vfmax_d.c| 200 
 .../loongarch/vector/lsx/lsx-vfmax_s.c| 335 +
 .../loongarch/vector/lsx/lsx-vfmaxa_d.c   | 155 ++
 .../loongarch/vector/lsx/lsx-vfmaxa_s.c   | 230 +
 .../loongarch/vector/lsx/lsx-vfsqrt_d.c   | 216 
 .../loongarch/vector/lsx/lsx-vfsqrt_s.c   | 372 ++
 12 files changed, 2803 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfadd_d.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfadd_s.c
 create mode 100644 
gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfclass_d.c
 create mode 100644 
gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfclass_s.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vflogb_d.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vflogb_s.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfmax_d.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfmax_s.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfmaxa_d.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfmaxa_s.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfsqrt_d.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfsqrt_s.c

diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfadd_d.c 
b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfadd_d.c
new file mode 100644
index 000..7ffbd385ee0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfadd_d.c
@@ -0,0 +1,407 @@
+/* { dg-do run } */
+/* { dg-options "-mlsx -w -fno-strict-aliasing" } */
+#include "../simd_correctness_check.h"
+#include 
+
+int
+main ()
+{
+  __m128i __m128i_op0, __m128i_op1, __m128i_op2, __m128i_out, __m128i_result;
+  __m128 __m128_op0, __m128_op1, __m128_op2, __m128_out, __m128_result;
+  __m128d __m128d_op0, __m128d_op1, __m128d_op2, __m128d_out, __m128d_result;
+
+  int int_op0, int_op1, int_op2, int_out, int_result, i = 1, fail;
+  long int long_op0, long_op1, long_op2, lont_out, lont_result;
+  long int long_int_out, long_int_result;
+  unsigned int unsigned_int_out, unsigned_int_result;
+  unsigned long int unsigned_long_int_out, unsigned_long_int_result;
+
+  *((unsigned long *)&__m128d_op0[1]) = 0x;
+  *((unsigned long *)&__m128d_op0[0]) = 0x;
+  *((unsigned long *)&__m128d_op1[1]) = 0x;
+  *((unsigned long *)&__m128d_op1[0]) = 0x;
+  *((unsigned long *)&__m128d_result[1]) = 0x;
+  *((unsigned long *)&__m128d_result[0]) = 0x;
+  __m128d_out = __lsx_vfadd_d (__m128d_op0, __m128d_op1);
+  ASSERTEQ_64 (__LINE__, __m128d_result, __m128d_out);
+
+  *((unsigned long *)&__m128d_op0[1]) = 0x;
+  *((unsigned long *)&__m128d_op0[0]) = 0xfea8ff44;
+  *((unsigned long *)&__m128d_op1[1]) = 0x2020202020202020;
+  *((unsigned long *)&__m128d_op1[0]) = 0x2020202020202020;
+  *((unsigned long *)&__m128d_result[1]) = 0x2020202020202020;
+  *((unsigned long *)&__m128d_result[0]) = 0x2020202020202020;
+  __m128d_out = __lsx_vfadd_d (__m128d_op0, __m128d_op1);
+  ASSERTEQ_64 (__LINE__, __m128d_result, __m128d_out);
+
+  *((unsigned long *)&__m128d_op0[1]) = 0x1000100010001000;
+  *((unsigned long *)&__m128d_op0[0]) = 0x1000100010001000;
+  *((unsigned long *)&__m128d_op1[1]) = 0x;
+  *((unsigned long *)&__m128d_op1[0]) = 0x;
+  *((unsigned long *)&__m128d_result[1]) = 0x1000100010001000;
+  *((unsigned long *)&__m128d_result[0]) = 0x1000100010001000;
+  __m128d_out = __lsx_vfadd_d (__m128d_op0, __m128d_op1);
+  

[PATCH v4 10/23] LoongArch: Add tests for SX vector vmax/vmaxi/vmin/vmini instructions.

[Xiaolong Chen]

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vector/lsx/lsx-vmax-1.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vmax-2.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vmaxi-1.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vmaxi-2.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vmin-1.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vmin-2.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vmini-1.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vmini-2.c: New test.
---
 .../loongarch/vector/lsx/lsx-vmax-1.c | 317 +
 .../loongarch/vector/lsx/lsx-vmax-2.c | 362 +++
 .../loongarch/vector/lsx/lsx-vmaxi-1.c| 279 +++
 .../loongarch/vector/lsx/lsx-vmaxi-2.c| 223 +
 .../loongarch/vector/lsx/lsx-vmin-1.c | 434 ++
 .../loongarch/vector/lsx/lsx-vmin-2.c | 344 ++
 .../loongarch/vector/lsx/lsx-vmini-1.c| 314 +
 .../loongarch/vector/lsx/lsx-vmini-2.c| 216 +
 8 files changed, 2489 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vmax-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vmax-2.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vmaxi-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vmaxi-2.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vmin-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vmin-2.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vmini-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vmini-2.c

diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vmax-1.c 
b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vmax-1.c
new file mode 100644
index 000..b0e22f955b0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vmax-1.c
@@ -0,0 +1,317 @@
+/* { dg-do run } */
+/* { dg-options "-mlsx -w -fno-strict-aliasing" } */
+#include "../simd_correctness_check.h"
+#include 
+
+int
+main ()
+{
+  __m128i __m128i_op0, __m128i_op1, __m128i_op2, __m128i_out, __m128i_result;
+  __m128 __m128_op0, __m128_op1, __m128_op2, __m128_out, __m128_result;
+  __m128d __m128d_op0, __m128d_op1, __m128d_op2, __m128d_out, __m128d_result;
+
+  int int_op0, int_op1, int_op2, int_out, int_result, i = 1, fail;
+  long int long_op0, long_op1, long_op2, lont_out, lont_result;
+  long int long_int_out, long_int_result;
+  unsigned int unsigned_int_out, unsigned_int_result;
+  unsigned long int unsigned_long_int_out, unsigned_long_int_result;
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vmax_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vmax_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vmax_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x7fff7fff7fff7fff;
+  *((unsigned long *)&__m128i_op0[0]) = 0x0001003f;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x7f007f007f007f00;
+  *((unsigned long *)&__m128i_result[0]) = 0x0001003f;
+  __m128i_out = __lsx_vmax_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x0001;
+  *((unsigned long *)&__m128i_op1[1]) = 0xf0001fff;
+  *((unsigned long *)&__m128i_op1[0]) = 0xf0001fff;
+  *((unsigned long *)&__m128i_result[1]) = 0x1f00;
+  

[PATCH v4 12/23] LoongArch: Add tests for SX vector vabsd/vmskgez/vmskltz/vmsknz/vsigncov instructions.

[Xiaolong Chen]

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vector/lsx/lsx-vabsd-1.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vabsd-2.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vmskgez.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vmskltz.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vmsknz.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vsigncov.c: New test.
---
 .../loongarch/vector/lsx/lsx-vabsd-1.c| 272 +++
 .../loongarch/vector/lsx/lsx-vabsd-2.c| 398 
 .../loongarch/vector/lsx/lsx-vmskgez.c| 119 +
 .../loongarch/vector/lsx/lsx-vmskltz.c| 321 +
 .../loongarch/vector/lsx/lsx-vmsknz.c | 104 +
 .../loongarch/vector/lsx/lsx-vsigncov.c   | 425 ++
 6 files changed, 1639 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vabsd-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vabsd-2.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vmskgez.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vmskltz.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vmsknz.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vsigncov.c

diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vabsd-1.c 
b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vabsd-1.c
new file mode 100644
index 000..e336581f3b4
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vabsd-1.c
@@ -0,0 +1,272 @@
+/* { dg-do run } */
+/* { dg-options "-mlsx -w -fno-strict-aliasing" } */
+#include "../simd_correctness_check.h"
+#include 
+
+int
+main ()
+{
+  __m128i __m128i_op0, __m128i_op1, __m128i_op2, __m128i_out, __m128i_result;
+  __m128 __m128_op0, __m128_op1, __m128_op2, __m128_out, __m128_result;
+  __m128d __m128d_op0, __m128d_op1, __m128d_op2, __m128d_out, __m128d_result;
+
+  int int_op0, int_op1, int_op2, int_out, int_result, i = 1, fail;
+  long int long_op0, long_op1, long_op2, lont_out, lont_result;
+  long int long_int_out, long_int_result;
+  unsigned int unsigned_int_out, unsigned_int_result;
+  unsigned long int unsigned_long_int_out, unsigned_long_int_result;
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vabsd_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0xfda9b23a624082fd;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x03574e3a62407e03;
+  *((unsigned long *)&__m128i_result[0]) = 0x0101;
+  __m128i_out = __lsx_vabsd_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x80008000;
+  *((unsigned long *)&__m128i_op0[0]) = 0x7fff7fff;
+  *((unsigned long *)&__m128i_op1[1]) = 0xfffd0007;
+  *((unsigned long *)&__m128i_op1[0]) = 0x0014fff5;
+  *((unsigned long *)&__m128i_result[1]) = 0x7f0300078000;
+  *((unsigned long *)&__m128i_result[0]) = 0x7f15000a7f010101;
+  __m128i_out = __lsx_vabsd_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vabsd_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x7fff;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x0006000e;
+  *((unsigned long *)&__m128i_op1[0]) = 0x00127fea;
+  *((unsigned long *)&__m128i_result[1]) = 0x7f0101070101010f;
+  *((unsigned long *)&__m128i_result[0]) = 0x00127f010116;
+  __m128i_out = __lsx_vabsd_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x000b;
+  *((unsigned long *)&__m128i_op0[0]) = 0x000b;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;

[PATCH v4 13/23] LoongArch: Add tests for SX vector vdiv/vmod instructions.

[Xiaolong Chen]

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vector/lsx/lsx-vdiv-1.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vdiv-2.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vmod-1.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vmod-2.c: New test.
---
 .../loongarch/vector/lsx/lsx-vdiv-1.c | 299 ++
 .../loongarch/vector/lsx/lsx-vdiv-2.c | 254 +++
 .../loongarch/vector/lsx/lsx-vmod-1.c | 254 +++
 .../loongarch/vector/lsx/lsx-vmod-2.c | 254 +++
 4 files changed, 1061 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vdiv-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vdiv-2.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vmod-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vmod-2.c

diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vdiv-1.c 
b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vdiv-1.c
new file mode 100644
index 000..cb4be04757c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vdiv-1.c
@@ -0,0 +1,299 @@
+/* { dg-do run } */
+/* { dg-options "-mlsx -w -fno-strict-aliasing" } */
+#include "../simd_correctness_check.h"
+#include 
+
+int
+main ()
+{
+  __m128i __m128i_op0, __m128i_op1, __m128i_op2, __m128i_out, __m128i_result;
+  __m128 __m128_op0, __m128_op1, __m128_op2, __m128_out, __m128_result;
+  __m128d __m128d_op0, __m128d_op1, __m128d_op2, __m128d_out, __m128d_result;
+
+  int int_op0, int_op1, int_op2, int_out, int_result, i = 1, fail;
+  long int long_op0, long_op1, long_op2, lont_out, lont_result;
+  long int long_int_out, long_int_result;
+  unsigned int unsigned_int_out, unsigned_int_result;
+  unsigned long int unsigned_long_int_out, unsigned_long_int_result;
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vdiv_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x3ff0;
+  *((unsigned long *)&__m128i_op0[0]) = 0x40f3fa00;
+  *((unsigned long *)&__m128i_op1[1]) = 0xb4ff;
+  *((unsigned long *)&__m128i_op1[0]) = 0xb4ff;
+  *((unsigned long *)&__m128i_result[1]) = 0xc110;
+  *((unsigned long *)&__m128i_result[0]) = 0xc00d0600;
+  __m128i_out = __lsx_vdiv_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x0101010101010101;
+  __m128i_out = __lsx_vdiv_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x0002;
+  *((unsigned long *)&__m128i_op0[0]) = 0x0101000101010001;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x00fe;
+  *((unsigned long *)&__m128i_result[0]) = 0x00ff00ff;
+  __m128i_out = __lsx_vdiv_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x01010101;
+  *((unsigned long *)&__m128i_result[0]) = 0x01010101;
+  __m128i_out = __lsx_vdiv_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0xd3259a2984048c23;
+  *((unsigned long *)&__m128i_op1[0]) = 0xf9796558e39953fd;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vdiv_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x97279727;
+  *((unsigned long *)&__m128i_op0[0]) = 0xfe79ba5f;
+  *((unsigned long *)&__m128i_op1[1]) = 

[PATCH v4 09/23] LoongArch: Add tests for SX vector vavg/vavgr instructions.

[Xiaolong Chen]

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vector/lsx/lsx-vavg-1.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vavg-2.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vavgr-1.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vavgr-2.c: New test.
---
 .../loongarch/vector/lsx/lsx-vavg-1.c | 398 ++
 .../loongarch/vector/lsx/lsx-vavg-2.c | 308 ++
 .../loongarch/vector/lsx/lsx-vavgr-1.c| 299 +
 .../loongarch/vector/lsx/lsx-vavgr-2.c| 317 ++
 4 files changed, 1322 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vavg-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vavg-2.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vavgr-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vavgr-2.c

diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vavg-1.c 
b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vavg-1.c
new file mode 100644
index 000..2177ca3f6f7
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vavg-1.c
@@ -0,0 +1,398 @@
+/* { dg-do run } */
+/* { dg-options "-mlsx -w -fno-strict-aliasing" } */
+#include "../simd_correctness_check.h"
+#include 
+
+int
+main ()
+{
+  __m128i __m128i_op0, __m128i_op1, __m128i_op2, __m128i_out, __m128i_result;
+  __m128 __m128_op0, __m128_op1, __m128_op2, __m128_out, __m128_result;
+  __m128d __m128d_op0, __m128d_op1, __m128d_op2, __m128d_out, __m128d_result;
+
+  int int_op0, int_op1, int_op2, int_out, int_result, i = 1, fail;
+  long int long_op0, long_op1, long_op2, lont_out, lont_result;
+  long int long_int_out, long_int_result;
+  unsigned int unsigned_int_out, unsigned_int_result;
+  unsigned long int unsigned_long_int_out, unsigned_long_int_result;
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vavg_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0xfff8fff8fff8fff8;
+  *((unsigned long *)&__m128i_op0[0]) = 0xfff8fff8fff8fff8;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0xfffcfffcfffcfffc;
+  *((unsigned long *)&__m128i_result[0]) = 0xfffcfffcfffcfffc;
+  __m128i_out = __lsx_vavg_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vavg_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vavg_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x4050;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x2028;
+  __m128i_out = __lsx_vavg_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vavg_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 

[PATCH v4 07/23] LoongArch: Add tests for SX vector addition vsadd instructions.

[Xiaolong Chen]

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vector/lsx/lsx-vsadd-1.c: New test.
* gcc.target/loongarch/vector/lsx/lsx-vsadd-2.c: New test.
---
 .../loongarch/vector/lsx/lsx-vsadd-1.c| 335 +
 .../loongarch/vector/lsx/lsx-vsadd-2.c| 345 ++
 2 files changed, 680 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vsadd-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vsadd-2.c

diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vsadd-1.c 
b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vsadd-1.c
new file mode 100644
index 000..1bc27c983bb
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vsadd-1.c
@@ -0,0 +1,335 @@
+/* { dg-do run } */
+/* { dg-options "-mlsx -w -fno-strict-aliasing" } */
+#include "../simd_correctness_check.h"
+#include 
+
+int
+main ()
+{
+  __m128i __m128i_op0, __m128i_op1, __m128i_op2, __m128i_out, __m128i_result;
+  __m128 __m128_op0, __m128_op1, __m128_op2, __m128_out, __m128_result;
+  __m128d __m128d_op0, __m128d_op1, __m128d_op2, __m128d_out, __m128d_result;
+
+  int int_op0, int_op1, int_op2, int_out, int_result, i = 1, fail;
+  long int long_op0, long_op1, long_op2, lont_out, lont_result;
+  long int long_int_out, long_int_result;
+  unsigned int unsigned_int_out, unsigned_int_result;
+  unsigned long int unsigned_long_int_out, unsigned_long_int_result;
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vsadd_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0xfefefefefefefefe;
+  __m128i_out = __lsx_vsadd_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x3c992b2e;
+  *((unsigned long *)&__m128i_op1[0]) = 0x730f;
+  *((unsigned long *)&__m128i_result[1]) = 0x3c992b2e;
+  *((unsigned long *)&__m128i_result[0]) = 0x730f;
+  __m128i_out = __lsx_vsadd_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vsadd_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x;
+  *((unsigned long *)&__m128i_result[0]) = 0x;
+  __m128i_out = __lsx_vsadd_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x7fff7fff;
+  *((unsigned long *)&__m128i_op0[0]) = 0x;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x2bfd9461;
+  *((unsigned long *)&__m128i_result[1]) = 0x7fff7fff;
+  *((unsigned long *)&__m128i_result[0]) = 0x2bfd9461;
+  __m128i_out = __lsx_vsadd_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x00d3012acc56f9bb;
+  *((unsigned long *)&__m128i_op0[0]) = 0x1021;
+  *((unsigned long *)&__m128i_op1[1]) = 0x;
+  *((unsigned long *)&__m128i_op1[0]) = 0x;
+  *((unsigned long *)&__m128i_result[1]) = 0x00d3012acc56f9bb;
+  *((unsigned long *)&__m128i_result[0]) = 0x1021;
+  __m128i_out = __lsx_vsadd_b (__m128i_op0, __m128i_op1);
+  ASSERTEQ_64 (__LINE__, __m128i_result, __m128i_out);
+
+  *((unsigned long *)&__m128i_op0[1]) = 0x1000;
+  *((unsigned long *)&__m128i_op0[0]) = 

[PATCH v4 00/23] Add tests for SX vector instructions.

[Xiaolong Chen]

v3 -> v4:
  Modify the name of the patch file.

  In order to better test the function of the vector instruction, the 128 bit
test cases are further split according to the function of the instruction.


Xiaolong Chen (23):
  LoongArch: Add tests of -mstrict-align option.
  LoongArch: Add testsuite framework for Loongson SX/ASX.
  LoongArch: Add tests for Loongson SX builtin functions.
  LoongArch: Add tests for SX vector floating-point instructions.
  LoongArch: Add tests for SX vector addition instructions.
  LoongArch: Add tests for SX vector subtraction instructions.
  LoongArch: Add tests for SX vector addition vsadd instructions.
  LoongArch: Add tests for the SX vector multiplication instruction.
  LoongArch: Add tests for SX vector vavg/vavgr instructions.
  LoongArch: Add tests for SX vector vmax/vmaxi/vmin/vmini instructions.
  LoongArch: Add tests for SX vector vexth/vextl/vldi/vneg/vsat
instructions.
  LoongArch: Add tests for SX vector
vabsd/vmskgez/vmskltz/vmsknz/vsigncov instructions.
  LoongArch: Add tests for SX vector vdiv/vmod instructions.
  LoongArch: Add tests for SX vector
vsll/vslli/vsrl/vsrli/vsrln/vsrlni/vsrlr /vsrlri/vslrlrn/vsrlrni 
instructions.
  LoongArch: Add tests for SX vector
vrotr/vrotri/vsra/vsrai/vsran/vsrani /vsrarn/vsrarni instructions.
  LoongArch: Add tests for SX vector
vssran/vssrani/vssrarn/vssrarni/vssrln /vssrlni/vssrlrn/vssrlrni
instructions.
  LoongArch: Add tests for SX vector vbitclr/vbitclri/vbitrev/vbitrevi/
vbitsel/vbitseli/vbitset/vbitseti/vclo/vclz/vpcnt instructions.
  LoongArch: Add tests for SX vector floating point arithmetic
instructions.
  LoongArch: Add tests for SX vector vfrstp/vfrstpi/vseq/vseqi/vsle
/vslei/vslt/vslti instructions.
  LoongArch: Add tests for SX vector vfcmp instructions.
  LoongArch: Add tests for SX vector handling and shuffle instructions.
  LoongArch: Add tests for SX vector vand/vandi/vandn/vor/vori/vnor/
vnori/vxor/vxori instructions.
  LoongArch: Add tests for SX vector vfmadd/vfnmadd/vld/vst
instructions.

 .../gcc.target/loongarch/strict-align.c   |   12 +
 .../loongarch/vector/loongarch-vector.exp |   42 +
 .../loongarch/vector/lsx/lsx-builtin.c| 1461 +
 .../loongarch/vector/lsx/lsx-vabsd-1.c|  272 +++
 .../loongarch/vector/lsx/lsx-vabsd-2.c|  398 +
 .../loongarch/vector/lsx/lsx-vadd.c   |  416 +
 .../loongarch/vector/lsx/lsx-vadda.c  |  344 
 .../loongarch/vector/lsx/lsx-vaddi.c  |  251 +++
 .../loongarch/vector/lsx/lsx-vaddwev-1.c  |  335 
 .../loongarch/vector/lsx/lsx-vaddwev-2.c  |  344 
 .../loongarch/vector/lsx/lsx-vaddwev-3.c  |  425 +
 .../loongarch/vector/lsx/lsx-vaddwod-1.c  |  408 +
 .../loongarch/vector/lsx/lsx-vaddwod-2.c  |  344 
 .../loongarch/vector/lsx/lsx-vaddwod-3.c  |  237 +++
 .../loongarch/vector/lsx/lsx-vand.c   |  159 ++
 .../loongarch/vector/lsx/lsx-vandi.c  |   67 +
 .../loongarch/vector/lsx/lsx-vandn.c  |  129 ++
 .../loongarch/vector/lsx/lsx-vavg-1.c |  398 +
 .../loongarch/vector/lsx/lsx-vavg-2.c |  308 
 .../loongarch/vector/lsx/lsx-vavgr-1.c|  299 
 .../loongarch/vector/lsx/lsx-vavgr-2.c|  317 
 .../loongarch/vector/lsx/lsx-vbitclr.c|  461 ++
 .../loongarch/vector/lsx/lsx-vbitclri.c   |  279 
 .../loongarch/vector/lsx/lsx-vbitrev.c|  407 +
 .../loongarch/vector/lsx/lsx-vbitrevi.c   |  336 
 .../loongarch/vector/lsx/lsx-vbitsel.c|  109 ++
 .../loongarch/vector/lsx/lsx-vbitseli.c   |   84 +
 .../loongarch/vector/lsx/lsx-vbitset.c|  371 +
 .../loongarch/vector/lsx/lsx-vbitseti.c   |  279 
 .../loongarch/vector/lsx/lsx-vbsll.c  |   83 +
 .../loongarch/vector/lsx/lsx-vbsrl.c  |   55 +
 .../loongarch/vector/lsx/lsx-vclo.c   |  266 +++
 .../loongarch/vector/lsx/lsx-vclz.c   |  265 +++
 .../loongarch/vector/lsx/lsx-vdiv-1.c |  299 
 .../loongarch/vector/lsx/lsx-vdiv-2.c |  254 +++
 .../loongarch/vector/lsx/lsx-vexth-1.c|  342 
 .../loongarch/vector/lsx/lsx-vexth-2.c|  182 ++
 .../loongarch/vector/lsx/lsx-vextl-1.c|   83 +
 .../loongarch/vector/lsx/lsx-vextl-2.c|   83 +
 .../loongarch/vector/lsx/lsx-vextrins.c   |  479 ++
 .../loongarch/vector/lsx/lsx-vfadd_d.c|  407 +
 .../loongarch/vector/lsx/lsx-vfadd_s.c|  470 ++
 .../loongarch/vector/lsx/lsx-vfclass_d.c  |   83 +
 .../loongarch/vector/lsx/lsx-vfclass_s.c  |   74 +
 .../loongarch/vector/lsx/lsx-vfcmp_caf.c  |  244 +++
 .../loongarch/vector/lsx/lsx-vfcmp_ceq.c  |  516 ++
 .../loongarch/vector/lsx/lsx-vfcmp_cle.c  |  530 ++
 .../loongarch/vector/lsx/lsx-vfcmp_clt.c  |  476 ++
 .../loongarch/vector/lsx/lsx-vfcmp_cne.c  |  378 +
 .../loongarch/vector/lsx/lsx-vfcmp_cor.c 

[PATCH v4 03/23] LoongArch: Add tests for Loongson SX builtin functions.

[Xiaolong Chen]

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vector/lsx/lsx-builtin.c: New test.
---
 .../loongarch/vector/lsx/lsx-builtin.c| 1461 +
 1 file changed, 1461 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-builtin.c

diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-builtin.c 
b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-builtin.c
new file mode 100644
index 000..70f5000b29f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-builtin.c
@@ -0,0 +1,1461 @@
+/* Test builtins for LOONGARCH LSX ASE instructions */
+/* { dg-do compile } */
+/* { dg-options "-mlsx" } */
+/* { dg-final { scan-assembler-times "lsx_vsll_b:.*vsll\\.b.*lsx_vsll_b" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsll_h:.*vsll\\.h.*lsx_vsll_h" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsll_w:.*vsll\\.w.*lsx_vsll_w" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsll_d:.*vsll\\.d.*lsx_vsll_d" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vslli_b:.*vslli\\.b.*lsx_vslli_b" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vslli_h:.*vslli\\.h.*lsx_vslli_h" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vslli_w:.*vslli\\.w.*lsx_vslli_w" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vslli_d:.*vslli\\.d.*lsx_vslli_d" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsra_b:.*vsra\\.b.*lsx_vsra_b" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsra_h:.*vsra\\.h.*lsx_vsra_h" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsra_w:.*vsra\\.w.*lsx_vsra_w" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsra_d:.*vsra\\.d.*lsx_vsra_d" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsrai_b:.*vsrai\\.b.*lsx_vsrai_b" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrai_h:.*vsrai\\.h.*lsx_vsrai_h" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrai_w:.*vsrai\\.w.*lsx_vsrai_w" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrai_d:.*vsrai\\.d.*lsx_vsrai_d" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrar_b:.*vsrar\\.b.*lsx_vsrar_b" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrar_h:.*vsrar\\.h.*lsx_vsrar_h" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrar_w:.*vsrar\\.w.*lsx_vsrar_w" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrar_d:.*vsrar\\.d.*lsx_vsrar_d" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrari_b:.*vsrari\\.b.*lsx_vsrari_b" 
1 } } */
+/* { dg-final { scan-assembler-times "lsx_vsrari_h:.*vsrari\\.h.*lsx_vsrari_h" 
1 } } */
+/* { dg-final { scan-assembler-times "lsx_vsrari_w:.*vsrari\\.w.*lsx_vsrari_w" 
1 } } */
+/* { dg-final { scan-assembler-times "lsx_vsrari_d:.*vsrari\\.d.*lsx_vsrari_d" 
1 } } */
+/* { dg-final { scan-assembler-times "lsx_vsrl_b:.*vsrl\\.b.*lsx_vsrl_b" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsrl_h:.*vsrl\\.h.*lsx_vsrl_h" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsrl_w:.*vsrl\\.w.*lsx_vsrl_w" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsrl_d:.*vsrl\\.d.*lsx_vsrl_d" 1 } } 
*/
+/* { dg-final { scan-assembler-times "lsx_vsrli_b:.*vsrli\\.b.*lsx_vsrli_b" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrli_h:.*vsrli\\.h.*lsx_vsrli_h" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrli_w:.*vsrli\\.w.*lsx_vsrli_w" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrli_d:.*vsrli\\.d.*lsx_vsrli_d" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrlr_b:.*vsrlr\\.b.*lsx_vsrlr_b" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrlr_h:.*vsrlr\\.h.*lsx_vsrlr_h" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrlr_w:.*vsrlr\\.w.*lsx_vsrlr_w" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrlr_d:.*vsrlr\\.d.*lsx_vsrlr_d" 1 
} } */
+/* { dg-final { scan-assembler-times "lsx_vsrlri_b:.*vsrlri\\.b.*lsx_vsrlri_b" 
1 } } */
+/* { dg-final { scan-assembler-times "lsx_vsrlri_h:.*vsrlri\\.h.*lsx_vsrlri_h" 
1 } } */
+/* { dg-final { scan-assembler-times "lsx_vsrlri_w:.*vsrlri\\.w.*lsx_vsrlri_w" 
1 } } */
+/* { dg-final { scan-assembler-times "lsx_vsrlri_d:.*vsrlri\\.d.*lsx_vsrlri_d" 
1 } } */
+/* { dg-final { scan-assembler-times 
"lsx_vbitclr_b:.*vbitclr\\.b.*lsx_vbitclr_b" 1 } } */
+/* { dg-final { scan-assembler-times 
"lsx_vbitclr_h:.*vbitclr\\.h.*lsx_vbitclr_h" 1 } } */
+/* { dg-final { scan-assembler-times 
"lsx_vbitclr_w:.*vbitclr\\.w.*lsx_vbitclr_w" 1 } } */
+/* { dg-final { scan-assembler-times 
"lsx_vbitclr_d:.*vbitclr\\.d.*lsx_vbitclr_d" 1 } } */
+/* { dg-final { scan-assembler-times 
"lsx_vbitclri_b:.*vbitclri\\.b.*lsx_vbitclri_b" 1 } } */
+/* { dg-final { scan-assembler-times 
"lsx_vbitclri_h:.*vbitclri\\.h.*lsx_vbitclri_h" 1 } } */
+/* { dg-final { scan-assembler-times 
"lsx_vbitclri_w:.*vbitclri\\.w.*lsx_vbitclri_w" 1 } } */
+/* { dg-final { scan-assembler-times 
"lsx_vbitclri_d:.*vbitclri\\.d.*lsx_vbitclri_d" 1 } } */
+/* { dg-final { scan-assembler-times 
"lsx_vbitset_b:.*vbitset\\.b.*lsx_vbitset_b" 1 } } 

[PATCH v4 02/23] LoongArch: Add testsuite framework for Loongson SX/ASX.

[Xiaolong Chen]

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vector/loongarch-vector.exp: New test.
* gcc.target/loongarch/vector/simd_correctness_check.h: New test.
---
 .../loongarch/vector/loongarch-vector.exp | 42 +++
 .../loongarch/vector/simd_correctness_check.h | 54 +++
 2 files changed, 96 insertions(+)
 create mode 100644 
gcc/testsuite/gcc.target/loongarch/vector/loongarch-vector.exp
 create mode 100644 
gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h

diff --git a/gcc/testsuite/gcc.target/loongarch/vector/loongarch-vector.exp 
b/gcc/testsuite/gcc.target/loongarch/vector/loongarch-vector.exp
new file mode 100644
index 000..2cbf9ac6ac1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/loongarch-vector.exp
@@ -0,0 +1,42 @@
+#Copyright(C) 2021 - 2023 Free Software Foundation, Inc.
+
+#This program 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 of the License, or
+#(at your option) any later version.
+#
+#This program 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
+# .
+
+#GCC testsuite that uses the `dg.exp' driver.
+
+#Exit immediately if this isn't a LoongArch target.
+if ![istarget loongarch*-*-*] then {
+return
+}
+
+#Load support procs.
+load_lib gcc-dg.exp
+
+#If a testcase doesn't have special options, use these.
+global DEFAULT_CFLAGS
+if ![info exists DEFAULT_CFLAGS] then {
+set DEFAULT_CFLAGS ""
+}
+
+#Initialize `dg'.
+dg-init
+
+#Main loop.
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/lsx/*.\[cS\]]] \
+   "-mlsx" $DEFAULT_CFLAGS
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/lasx/*.\[cS\]]] \
+   "-mlasx" $DEFAULT_CFLAGS
+# All done.
+dg-finish
diff --git a/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h 
b/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h
new file mode 100644
index 000..eb7fbd59cc7
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h
@@ -0,0 +1,54 @@
+#include 
+#include 
+#include 
+
+#define ASSERTEQ_64(line, ref, res)   \
+  do  \
+{ \
+  int fail = 0;   \
+  for (size_t i = 0; i < sizeof (res) / sizeof (res[0]); ++i) \
+{ \
+  long *temp_ref = [i], *temp_res = [i];  \
+  if (abs (*temp_ref - *temp_res) > 0)\
+{ \
+  printf (" error: %s at line %ld , expected " #ref   \
+  "[%ld]:0x%lx, got: 0x%lx\n",\
+  __FILE__, line, i, *temp_ref, *temp_res);   \
+  fail = 1;   \
+} \
+} \
+  if (fail == 1)  \
+abort (); \
+} \
+  while (0)
+
+#define ASSERTEQ_32(line, ref, res)   \
+  do  \
+{ \
+  int fail = 0;   \
+  for (size_t i = 0; i < sizeof (res) / sizeof (res[0]); ++i) \
+{ \
+  int *temp_ref = [i], *temp_res = [i];   \
+  if (abs (*temp_ref - *temp_res) > 0)\
+{ \
+  printf (" error: %s at line %ld , expected " #ref   \
+  "[%ld]:0x%x, got: 0x%x\n",  \
+  __FILE__, line, i, *temp_ref, *temp_res);   \
+  fail = 1;   \
+}

[PATCH v4 01/23] LoongArch: Add tests of -mstrict-align option.

[Xiaolong Chen]

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/strict-align.c: New test.
---
 gcc/testsuite/gcc.target/loongarch/strict-align.c | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/strict-align.c

diff --git a/gcc/testsuite/gcc.target/loongarch/strict-align.c 
b/gcc/testsuite/gcc.target/loongarch/strict-align.c
new file mode 100644
index 000..040d849584b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/strict-align.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-Ofast -mstrict-align -mlasx" } */
+/* { dg-final { scan-assembler-not "vfadd.s" } } */
+
+void
+foo (float *restrict x, float *restrict y)
+{
+  x[0] = x[0] + y[0];
+  x[1] = x[1] + y[1];
+  x[2] = x[2] + y[2];
+  x[3] = x[3] + y[3];
+}
-- 
2.20.1

[committed] RISC-V: Remove redundant ABI test

[Juzhe-Zhong]

We only support and report warning for RVV types.

We don't report warning for GNU vectors.
So this testcase checking is incorrect and the FAIL is bogus.

Remove it and commit it.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/vector-abi-9.c: Removed.

---
 .../gcc.target/riscv/rvv/base/vector-abi-9.c | 16 
 1 file changed, 16 deletions(-)
 delete mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vector-abi-9.c

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/vector-abi-9.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/vector-abi-9.c
deleted file mode 100644
index b5f130f0caf..000
--- a/gcc/testsuite/gcc.target/riscv/rvv/base/vector-abi-9.c
+++ /dev/null
@@ -1,16 +0,0 @@
-/* { dg-do compile } */
-/* { dg-options "-march=rv64gcv -mabi=lp64d 
--param=riscv-autovec-preference=fixed-vlmax" } */
-
-#include "riscv_vector.h"
-
-typedef int v4si __attribute__ ((vector_size (16)));
-
-v4si
-fun (v4si a) {  return a; }  /* { dg-warning "the vector type" } */
-
-void
-bar ()
-{
-  v4si a;
-  fun (a);
-}
-- 
2.36.3

[PATCH] LoongArch: Change the value of branch_cost from 2 to 6.

[Lulu Cheng]

gcc/ChangeLog:

* config/loongarch/loongarch-def.c: Modify the default value of
branch_cost.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/cmov_ii.c: New test.
---
 gcc/config/loongarch/loongarch-def.c |  4 ++--
 gcc/testsuite/gcc.target/loongarch/cmov_ii.c | 16 
 2 files changed, 18 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/cmov_ii.c

diff --git a/gcc/config/loongarch/loongarch-def.c 
b/gcc/config/loongarch/loongarch-def.c
index e744ee01d6d..430ef8b2d95 100644
--- a/gcc/config/loongarch/loongarch-def.c
+++ b/gcc/config/loongarch/loongarch-def.c
@@ -85,7 +85,7 @@ loongarch_cpu_align[N_TUNE_TYPES] = {
 .int_mult_di   = COSTS_N_INSNS (1),\
 .int_div_si= COSTS_N_INSNS (4),\
 .int_div_di= COSTS_N_INSNS (6),\
-.branch_cost   = 2,\
+.branch_cost   = 6,\
 .memory_latency= 4
 
 /* The following properties cannot be looked up directly using "cpucfg".
@@ -118,7 +118,7 @@ loongarch_rtx_cost_optimize_size = {
 .int_mult_di  = 4,
 .int_div_si  = 4,
 .int_div_di  = 4,
-.branch_cost  = 2,
+.branch_cost  = 6,
 .memory_latency   = 4,
 };
 
diff --git a/gcc/testsuite/gcc.target/loongarch/cmov_ii.c 
b/gcc/testsuite/gcc.target/loongarch/cmov_ii.c
new file mode 100644
index 000..466a4c1c9af
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/cmov_ii.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-final { scan-assembler "main:.*xor.*masknez.*maskeqz.*or.*" } }
+ */
+void printf (char *, ...);
+extern void foo_ii (int *, int *, int *, int *);
+
+int
+test (void)
+{
+  int a, b;
+  int c, d, out;
+  foo_ii (, , , );
+  out = a == b ? c : d;
+  printf ("%d\n", out);
+}
-- 
2.31.1

[PING][PATCH v2] Add clang's invalid-noreturn warning flag

[Julian Waters via Gcc-patches]

Second desperate ping for patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627913.html

Re: [PATCH] Checking undefined_p before using the vr

[Jiufu Guo via Gcc-patches]

Hi,

Richard Biener  writes:

> On Thu, 7 Sep 2023, Jiufu Guo wrote:
>
>> Hi,
>> 
>> As discussed in PR111303:
>> 
>> For pattern "(X + C) / N": "div (plus@3 @0 INTEGER_CST@1) INTEGER_CST@2)",
>> Even if "X" has value-range and "X + C" does not overflow, "@3" may still
>> be undefined. Like below example:
>> 
>> _3 = _2 + -5;
>> if (0 != 0)
>>   goto ; [34.00%]
>> else
>>   goto ; [66.00%]
>> ;;  succ:   3
>> ;;  4
>> 
>> ;; basic block 3, loop depth 0
>> ;;  pred:   2
>> _5 = _3 / 5; 
>> ;;  succ:   4
>> 
>> The whole pattern "(_2 + -5 ) / 5" is in "bb 3", but "bb 3" would be
>> unreachable (because "if (0 != 0)" is always false).
>> And "get_range_query (cfun)->range_of_expr (vr3, @3)" is checked in
>> "bb 3", "range_of_expr" gets an "undefined vr3". Where "@3" is "_5".
>> 
>> So, before using "vr3", it would be safe to check "!vr3.undefined_p ()".
>> 
>> Bootstrap & regtest pass on ppc64{,le} and x86_64.
>> Is this ok for trunk?
>
> OK, but I wonder why ->range_of_expr () doesn't return false for
> undefined_p ()?  While "undefined" technically means we can treat
> it as nonnegative_p (or not, maybe but maybe not both), we seem to
> not want to do that.  So why expose it at all to ranger users
> (yes, internally we in some places want to handle undefined).

I guess, currently, it returns true and then lets the user check
undefined_p, maybe because it tries to only return false if the
type of EXPR is unsupported.

Let "range_of_expr" return false for undefined_p would save checking
undefined_p again when using the APIs.

Committed va r14-3913.

BR,
Jeff (Jiufu Guo)

>
> Richard.
>
>> BR,
>> Jeff (Jiufu Guo)
>> 
>>  PR middle-end/111303
>> 
>> gcc/ChangeLog:
>> 
>>  * match.pd ((X - N * M) / N): Add undefined_p checking.
>>  (X + N * M) / N): Likewise.
>>  ((X + C) div_rshift N): Likewise.
>> 
>> gcc/testsuite/ChangeLog:
>> 
>>  * gcc.dg/pr111303.c: New test.
>> 
>> ---
>>  gcc/match.pd|  3 +++
>>  gcc/testsuite/gcc.dg/pr111303.c | 11 +++
>>  2 files changed, 14 insertions(+)
>>  create mode 100644 gcc/testsuite/gcc.dg/pr111303.c
>> 
>> diff --git a/gcc/match.pd b/gcc/match.pd
>> index 801edb128f9..e2583ca7960 100644
>> --- a/gcc/match.pd
>> +++ b/gcc/match.pd
>> @@ -975,6 +975,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>> /* "X+(N*M)" doesn't overflow.  */
>> && range_op_handler (PLUS_EXPR).overflow_free_p (vr0, vr3)
>> && get_range_query (cfun)->range_of_expr (vr4, @4)
>> +   && !vr4.undefined_p ()
>> /* "X+N*M" is not with opposite sign as "X".  */
>> && (TYPE_UNSIGNED (type)
>> || (vr0.nonnegative_p () && vr4.nonnegative_p ())
>> @@ -995,6 +996,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>> /* "X - (N*M)" doesn't overflow.  */
>> && range_op_handler (MINUS_EXPR).overflow_free_p (vr0, vr3)
>> && get_range_query (cfun)->range_of_expr (vr4, @4)
>> +   && !vr4.undefined_p ()
>> /* "X-N*M" is not with opposite sign as "X".  */
>> && (TYPE_UNSIGNED (type)
>> || (vr0.nonnegative_p () && vr4.nonnegative_p ())
>> @@ -1025,6 +1027,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>>/* "X+C" doesn't overflow.  */
>>&& range_op_handler (PLUS_EXPR).overflow_free_p (vr0, vr1)
>>&& get_range_query (cfun)->range_of_expr (vr3, @3)
>> +  && !vr3.undefined_p ()
>>/* "X+C" and "X" are not of opposite sign.  */
>>&& (TYPE_UNSIGNED (type)
>>|| (vr0.nonnegative_p () && vr3.nonnegative_p ())
>> diff --git a/gcc/testsuite/gcc.dg/pr111303.c 
>> b/gcc/testsuite/gcc.dg/pr111303.c
>> new file mode 100644
>> index 000..eaabe55c105
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/pr111303.c
>> @@ -0,0 +1,11 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-O2" } */
>> +
>> +/* Make sure no ICE. */
>> +unsigned char a;
>> +int b(int c) {
>> +  if (c >= 5000)
>> +return c / 5;
>> +}
>> +void d() { b(a - 5); }
>> +int main() {}
>> 

[Bug tree-optimization/111303] [14 Regression] ICE: in type, at value-range.h:869

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jiu Fu Guo :

https://gcc.gnu.org/g:8d8bc560b6ab7f3153db23ffb37157528e5b2c9a

commit r14-3913-g8d8bc560b6ab7f3153db23ffb37157528e5b2c9a
Author: Jiufu Guo 
Date:   Wed Sep 6 21:38:11 2023 +0800

Checking undefined_p before using the vr

For pattern "(X + C) / N": "div (plus@3 @0 INTEGER_CST@1) INTEGER_CST@2)",
Even if "X" has value-range and "X + C" does not overflow, "@3" may still
be undefined. Like below example:

_3 = _2 + -5;
if (0 != 0)
  goto ; [34.00%]
else
  goto ; [66.00%]
;;  succ:   3
;;  4

;; basic block 3, loop depth 0
;;  pred:   2
_5 = _3 / 5;
;;  succ:   4

The whole pattern "(_2 + -5 ) / 5" is in "bb 3", but "bb 3" would be
unreachable (because "if (0 != 0)" is always false).
And "get_range_query (cfun)->range_of_expr (vr3, @3)" is checked in
"bb 3", "range_of_expr" gets an "undefined vr3". Where "@3" is "_5".

So, before using "vr3", it would be safe to check "!vr3.undefined_p ()".

PR tree-optimization/111303

gcc/ChangeLog:

* match.pd ((X - N * M) / N): Add undefined_p checking.
((X + N * M) / N): Likewise.
((X + C) div_rshift N): Likewise.

gcc/testsuite/ChangeLog:

* gcc.dg/pr111303.c: New test.

[PATCH v2] LoongArch: Fix bug of 'di3_fake'.

[Lulu Cheng]

PR 111334

gcc/ChangeLog:

* config/loongarch/loongarch.md: Fix bug of 'di3_fake'.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/pr111334.c: New test.
---
v1 -> v2:

Modify the template "*3", the SI type division operation
is not supported under the LA64 architecture.
---
 gcc/config/loongarch/loongarch.md | 20 ++
 gcc/testsuite/gcc.target/loongarch/pr111334.c | 39 +++
 2 files changed, 52 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/pr111334.c

diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index 1dc6b524416..4fcb6d781d5 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -72,6 +72,9 @@ (define_c_enum "unspec" [
   UNSPEC_LUI_H_HI12
   UNSPEC_TLS_LOW
 
+  ;; Fake div.w[u] mod.w[u]
+  UNSPEC_FAKE_ANY_DIV
+
   UNSPEC_SIBCALL_VALUE_MULTIPLE_INTERNAL_1
   UNSPEC_CALL_VALUE_MULTIPLE_INTERNAL_1
 ])
@@ -900,7 +903,7 @@ (define_expand "3"
 (match_operand:GPR 2 "register_operand")))]
   ""
 {
- if (GET_MODE (operands[0]) == SImode)
+ if (GET_MODE (operands[0]) == SImode && TARGET_64BIT)
   {
 rtx reg1 = gen_reg_rtx (DImode);
 rtx reg2 = gen_reg_rtx (DImode);
@@ -920,9 +923,9 @@ (define_expand "3"
 })
 
 (define_insn "*3"
-  [(set (match_operand:GPR 0 "register_operand" "=r,,")
-   (any_div:GPR (match_operand:GPR 1 "register_operand" "r,r,0")
-(match_operand:GPR 2 "register_operand" "r,r,r")))]
+  [(set (match_operand:X 0 "register_operand" "=r,,")
+   (any_div:X (match_operand:X 1 "register_operand" "r,r,0")
+  (match_operand:X 2 "register_operand" "r,r,r")))]
   ""
 {
   return loongarch_output_division (".\t%0,%1,%2", operands);
@@ -938,9 +941,12 @@ (define_insn "*3"
 (define_insn "di3_fake"
   [(set (match_operand:DI 0 "register_operand" "=r,,")
(sign_extend:DI
- (any_div:SI (match_operand:DI 1 "register_operand" "r,r,0")
- (match_operand:DI 2 "register_operand" "r,r,r"]
-  ""
+ (unspec:SI
+  [(subreg:SI
+(any_div:DI (match_operand:DI 1 "register_operand" "r,r,0")
+(match_operand:DI 2 "register_operand" "r,r,r")) 0)]
+ UNSPEC_FAKE_ANY_DIV)))]
+  "TARGET_64BIT"
 {
   return loongarch_output_division (".w\t%0,%1,%2", operands);
 }
diff --git a/gcc/testsuite/gcc.target/loongarch/pr111334.c 
b/gcc/testsuite/gcc.target/loongarch/pr111334.c
new file mode 100644
index 000..47366afcb74
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/pr111334.c
@@ -0,0 +1,39 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+unsigned
+util_next_power_of_two (unsigned x)
+{
+  return (1 << __builtin_clz (x - 1));
+}
+
+extern int create_vec_from_array (void);
+
+struct ac_shader_args {
+struct {
+   unsigned char offset;
+   unsigned char size;
+} args[384];
+};
+
+struct isel_context {
+const struct ac_shader_args* args;
+int arg_temps[384];
+};
+
+
+void
+add_startpgm (struct isel_context* ctx, unsigned short arg_count)
+{
+
+  for (unsigned i = 0, arg = 0; i < arg_count; i++)
+{
+  unsigned size = ctx->args->args[i].size;
+  unsigned reg = ctx->args->args[i].offset;
+
+  if (reg % ( 4 < util_next_power_of_two (size)
+? 4 : util_next_power_of_two (size)))
+ ctx->arg_temps[i] = create_vec_from_array ();
+}
+}
+
-- 
2.31.1

Re: [PATCH] aarch64: Add SVE instruction types

[Evandro Menezes via Gcc-patches]

Hi, Kyrill.

I wonder if the regression that you noticed was the same that I did.  Overall, 
thus far, there’s no significant regression that I can say is due to 
scheduling.  However, there is one benchmark, 507.cactuBSSN_r/607.cactuBSSN_s 
in SPEC2017, that regressed by more than 10%.  Upon closer examination, it 
seems that the change in the live ranges led to heavy spilling and to doubling 
of the stack size.  The spilling looks rather capricious though, as there seem 
to be enough free registers available.  

Is this similar to what you observed as well?  I tried to adjust the priority 
of memory ops through, TARGET_SCHED_ADJUST_PRIORITY, but it was innefective.  
I’m a bit at a loss what’s likely going on with the RA at this point.  Any 
pointers?

Thank you,

-- 
Evandro Menezes



> Em 16 de mai. de 2023, à(s) 03:36, Kyrylo Tkachov  
> escreveu:
> 
> Hi Evandro,
>  
> I created a new attribute so I didn’t have to extend the “type” attribute 
> that lives in config/arm/types.md. As that attribute and file lives in the 
> arm backend but SVE is AArch64-only I didn’t want to add logic to the arm 
> backend as it’s not truly shared.
> The granularity has been somewhat subjective. I had looked at the Software 
> Optimisation guides for various SVE and SVE2-capable cores from Arm on 
> developer.arm.com and tried to glean commonalities between different 
> instruction groups.
> I did try writing a model for Neoverse V1 using that classification but I 
> couldn’t spend much time on it and the resulting model didn’t give me much 
> improvements and gave some regressions instead.
> I think that was more down to my rushed model rather than anything else 
> though.
>  
> Thanks,
> Kyrill
>  
> From: Evandro Menezes  
> Sent: Monday, May 15, 2023 9:13 PM
> To: Kyrylo Tkachov 
> Cc: Richard Sandiford ; Evandro Menezes via 
> Gcc-patches ; evandro+...@gcc.gnu.org; Tamar 
> Christina 
> Subject: Re: [PATCH] aarch64: Add SVE instruction types
>  
> Hi, Kyrill.
>  
> I wasn’t aware of your previous patch.  Could you clarify why you considered 
> creating an SVE specific type attribute instead of reusing the common one?  I 
> really liked the iterators that you created; I’d like to use them.
>  
> Do you have specific examples which you might want to mention with regards to 
> granularity?
>  
> Yes, my intent for this patch is to enable modeling the SVE instructions on 
> N1.  The patch that implements it brings up some performance improvements, 
> but it’s mostly flat, as expected.
>  
> Thank you,
> 
> -- 
> Evandro Menezes
>  
>  
> 
> 
> Em 15 de mai. de 2023, à(s) 04:49, Kyrylo Tkachov  > escreveu:
>  
> 
> 
> 
> -Original Message-
> From: Richard Sandiford  >
> Sent: Monday, May 15, 2023 10:01 AM
> To: Evandro Menezes via Gcc-patches  >
> Cc: evandro+...@gcc.gnu.org ; Evandro Menezes 
> mailto:ebah...@icloud.com>>;
> Kyrylo Tkachov mailto:kyrylo.tkac...@arm.com>>; 
> Tamar Christina
> mailto:tamar.christ...@arm.com>>
> Subject: Re: [PATCH] aarch64: Add SVE instruction types
> 
> Evandro Menezes via Gcc-patches  > writes:
> 
> This patch adds the attribute `type` to most SVE1 instructions, as in the
> other
> 
> instructions.
> 
> Thanks for doing this.
> 
> Could you say what criteria you used for picking the granularity?  Other
> maintainers might disagree, but personally I'd prefer to distinguish two
> instructions only if:
> 
> (a) a scheduling description really needs to distinguish them or
> (b) grouping them together would be very artificial (because they're
>logically unrelated)
> 
> It's always possible to split types later if new scheduling descriptions
> require it.  Because of that, I don't think we should try to predict ahead
> of time what future scheduling descriptions will need.
> 
> Of course, this depends on having results that show that scheduling
> makes a significant difference on an SVE core.  I think one of the
> problems here is that, when a different scheduling model changes the
> performance of a particular test, it's difficult to tell whether
> the gain/loss is caused by the model being more/less accurate than
> the previous one, or if it's due to important "secondary" effects
> on register live ranges.  Instinctively, I'd have expected these
> secondary effects to dominate on OoO cores.
> 
> I agree with Richard on these points. The key here is getting the granularity 
> right without having too maintain too many types that aren't useful in the 
> models.
> FWIW I had posted 
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607101.html in 
> November. It adds annotations to SVE2 patterns as well as for base SVE.
> Feel free to reuse it if you'd like.
> I see you had posted a Neoverse V1 scheduling model. Does that give an 
> improvement on SVE code when combined with the scheduling attributes somehow?
> 

[PATCH] c++: always check arity before deduction

[Patrick Palka via Gcc-patches]

Bootstrpaped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?

-- >8 --

This simple patch extends the r12-3271-gf1e73199569287 optimization
to apply to deduction without explicit template arguments as well.
The motivation for this is to accept testcases such as conv20.C and
ttp40.C below, which don't use explicit template arguments but for which
unnecessary template instantiation during deduction could be avoided if
we pruned overloads according to arity early in this case as well.  This
incidentally causes us to accept one reduced testcase from PR c++/84075,
but the underlying issue there still remains unfixed.

As an added bonus, this change ends up causing the "candidate expects
N argument(s)" note during overload resolution failure to point to the
template candidate instead of the call site, which seems like an
improvement similar to r14-309-g14e881eb030509.

gcc/cp/ChangeLog:

* call.cc (add_template_candidate_real): Check arity even
when there are no explicit template arguments.  Combine the
two adjacent '!obj' tests into one.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/vt-57397-1.C: Expect "candidate expects ... N
argument(s)" at the declaration site instead of the call site.
* g++.dg/cpp0x/vt-57397-2.C: Likewise.
* g++.dg/overload/template5.C: Likewise.
* g++.dg/template/local6.C: Likewise.
* g++.dg/template/conv20.C: New test.
* g++.dg/template/ttp40.C: New test.
---
 gcc/cp/call.cc| 14 ++---
 gcc/testsuite/g++.dg/cpp0x/vt-57397-1.C   |  6 +++---
 gcc/testsuite/g++.dg/cpp0x/vt-57397-2.C   |  6 +++---
 gcc/testsuite/g++.dg/overload/template5.C |  4 ++--
 gcc/testsuite/g++.dg/template/conv20.C| 17 +++
 gcc/testsuite/g++.dg/template/local6.C|  4 ++--
 gcc/testsuite/g++.dg/template/ttp40.C | 25 +++
 7 files changed, 58 insertions(+), 18 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/template/conv20.C
 create mode 100644 gcc/testsuite/g++.dg/template/ttp40.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 399345307ea..2bbaeee039d 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -3535,13 +3535,13 @@ add_template_candidate_real (struct z_candidate 
**candidates, tree tmpl,
 }
   gcc_assert (ia == nargs_without_in_chrg);
 
-  if (!obj && explicit_targs)
+  if (!obj)
 {
   /* Check that there's no obvious arity mismatch before proceeding with
 deduction.  This avoids substituting explicit template arguments
-into the template (which could result in an error outside the
-immediate context) when the resulting candidate would be unviable
-anyway.  */
+into the template or e.g. derived-to-base parm/arg unification
+(which could result in an error outside the immediate context) when
+the resulting candidate would be unviable anyway.  */
   int min_arity = 0, max_arity = 0;
   tree parms = TYPE_ARG_TYPES (TREE_TYPE (tmpl));
   parms = skip_artificial_parms_for (tmpl, parms);
@@ -3571,11 +3571,7 @@ add_template_candidate_real (struct z_candidate 
**candidates, tree tmpl,
  reason = arity_rejection (NULL_TREE, max_arity, ia);
  goto fail;
}
-}
 
-  errs = errorcount+sorrycount;
-  if (!obj)
-{
   convs = alloc_conversions (nargs);
 
   if (shortcut_bad_convs
@@ -3602,6 +3598,8 @@ add_template_candidate_real (struct z_candidate 
**candidates, tree tmpl,
}
}
 }
+
+  errs = errorcount+sorrycount;
   fn = fn_type_unification (tmpl, explicit_targs, targs,
args_without_in_chrg,
nargs_without_in_chrg,
diff --git a/gcc/testsuite/g++.dg/cpp0x/vt-57397-1.C 
b/gcc/testsuite/g++.dg/cpp0x/vt-57397-1.C
index 440bea5b2f7..bac3b64ad7e 100644
--- a/gcc/testsuite/g++.dg/cpp0x/vt-57397-1.C
+++ b/gcc/testsuite/g++.dg/cpp0x/vt-57397-1.C
@@ -3,20 +3,20 @@
 
 template
 void foo(T1, Tn...);
+// { dg-message "candidate expects at least 1 argument, 0 provided" "" { 
target *-*-* } .-1 }
 
 template
 void bar(T1, T2, Tn...);
+// { dg-message "candidate expects at least 2 arguments, 0 provided" "" { 
target *-*-* } .-1 }
+// { dg-message "candidate expects at least 2 arguments, 1 provided" "" { 
target *-*-* } .-2 }
 
 int main()
 {
   foo();   // { dg-error "no matching" }
-  // { dg-message "candidate expects at least 1 argument, 0 provided" "" { 
target *-*-* } .-1 }
   foo(1);
   foo(1, 2);
   bar();   // { dg-error "no matching" }
-  // { dg-message "candidate expects at least 2 arguments, 0 provided" "" { 
target *-*-* } .-1 }
   bar(1);  // { dg-error "no matching" }
-  // { dg-message "candidate expects at least 2 arguments, 1 provided" "" { 
target *-*-* } .-1 }
   bar(1, 2);
   bar(1, 2, 3);
 }
diff --git a/gcc/testsuite/g++.dg/cpp0x/vt-57397-2.C 
b/gcc/testsuite/g++.dg/cpp0x/vt-57397-2.C
index 1a99e22c5cb..22b19ef6c1a 100644
--- 

[Bug libstdc++/111390] 'make check-compile' target is not useful

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jonathan Wakely  ---
I think what you're describing or looking for is something completely
different, which might be useful but is not what is present today.

The libstdc++-v3/scripts/check_compile script cannot be turned into what you're
describing. There's simply no way to get to what you want from a naive shell
script that isn't parallelized, and doesn't understand the dg-* directives in
the tests, and only supports a single -std option for all tests.

What we have today is not useful. A replacement would have to be written from
scratch anyway, so ripping it out entirely has no downside as far as I can see.

[Bug libstdc++/111390] 'make check-compile' target is not useful

[egallager at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #2)
> The fact nobody has tried to use it in 10+ years makes me think it's not all
> that useful.

Only reason I haven't tried to use it is because I didn't know it existed; if
it were also available from the top-level Makefile, it would be more
discoverable, and more likely to be used.

[Bug tree-optimization/110293] Some `A CMP (A NEEQ 0)` is not simplified in some cases

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Andrew Pinski  ---
Actually here is the rest for the non-zero comparisons.

Note for the below case, s can be swapped around with unsigned and the CST
comparisons become unsigned comparisons too.

s < (s == CST) ->  CST == 0 ? s <= 0 : CST < 0
s >= (s == CST) -> CST == 0 ? s > 0  : CST > 0
s > (s == CST) ->  CST == 0 ? s <= 0 : CST > 1
s <= (s == CST) -> CST == 0 ? s > 0  : CST <= 1

s <  (s != CST) -> CST == 0 ? s < 0  : (CST > 0 ? s < 1 : (s < 1 & s != CST))
s >= (s != CST) -> CST == 0 ? s >= 0 : (CST == 1 ? s > 1 : (CST > 1 ? s != CST
& s >= 1 : s >= 1))
s >  (s != CST) -> CST == 0 ? s <= 1 : 
s <= (s != CST) -> CST == 0 ? s >  1 :

[Bug libstdc++/111351] constexpr std::string objects permitted to escape constant evaluation when SSO

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Arthur O'Dwyer  ---
(In reply to James Y Knight from comment #5)
> > Does using __builtin_is_constant_p on the union member not work?
> 
> I've created a proof-of-concept patch for libc++ to support SSO strings
> during constant evaluation. It works.
> 
> If everyone disagrees with me and believes that this is a really awesome
> foot-gun to give to users, I will go ahead and propose that patch to libc++
> maintainers. (As mentioned, that'll cause more code to be compilable under
> libc++ than is possible to permit under libstdc++/MSVC implementations).

FWIW #1: Personally I would be weakly in favor of that patch, but I would also
be pessimistic about its chances of getting accepted in the current libc++
climate.

FWIW #2: A worst-of-both-worlds option ;) would be for your patch to `if
consteval` the SSO buffer size so that it would be 24 at runtime (matching
libc++'s current behavior) but 16 at compile time (matching libstdc++ and
Microsoft if I'm not mistaken, so you'd get your cross-vendor portability at
compile time). *I* would still consider that an unnecessary-and-thus-bad
crippling of libc++ string's cool 24-byte-SSO feature; but I could imagine
someone else finding it more palatable than any other alternative. 
["Worst-of-both-worlds" in the sense that you're paying to change the code at
all, but the end result still has two codepaths that both need to be
maintained, and divergence between compile-time and runtime SSO behavior.]

[Bug tree-optimization/111345] `X % Y is smaller than Y.` pattern could be simpified

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Septemb
   ||er/630109.html

--- Comment #1 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630109.html

[Bug target/110751] RISC-V: Suport undefined value that allows VSETVL PASS use TA/MA

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #30 from JuzheZhong  ---
Hi.Richard.

I understand your conern:

If we are possible have this following possible rule to fold to ELSE value in
the future:

1. (cond_len all-false a b c len bias)
2. (cond_len any mask a b c len bias) (len + bias == 0)


I think it also can be easily fixed in the backend by ELSE_VALUE targethook.

We can return scalar 0 for else value only if (ops[0] != all false mask &&
LEN+BIAS ！= 0).

Am I right?

Thanks.

[Bug middle-end/111337] ICE in gimple-isel.cc for RISC-V port

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

JuzheZhong  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from JuzheZhong  ---
fixed

[PATCH] MATCH: Simplify `(X % Y) < Y` pattern.

[Andrew Pinski via Gcc-patches]

This merges the two patterns to catch
`(X % Y) < Y` and `Y > (X % Y)` into one by
using :c on the comparison operator.
It does not change any code generation nor
anything else. It is more to allow for better
maintainability of this pattern.

OK? Bootstrapped and tested on x86_64-linux-gnu.

gcc/ChangeLog:

* match.pd (`Y > (X % Y)`): Merge
into ...
(`(X % Y) < Y`): Pattern by adding `:c`
on the comparison.
---
 gcc/match.pd | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/gcc/match.pd b/gcc/match.pd
index 39c7ea1088f..24fd29863fb 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1483,14 +1483,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 /* X % Y is smaller than Y.  */
 (for cmp (lt ge)
  (simplify
-  (cmp (trunc_mod @0 @1) @1)
+  (cmp:c (trunc_mod @0 @1) @1)
   (if (TYPE_UNSIGNED (TREE_TYPE (@0)))
{ constant_boolean_node (cmp == LT_EXPR, type); })))
-(for cmp (gt le)
- (simplify
-  (cmp @1 (trunc_mod @0 @1))
-  (if (TYPE_UNSIGNED (TREE_TYPE (@0)))
-   { constant_boolean_node (cmp == GT_EXPR, type); })))
 
 /* x | ~0 -> ~0  */
 (simplify
-- 
2.31.1

[Bug tree-optimization/111393] ICE: Segmentation fault src/gcc/toplev.cc:314

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to AK from comment #5)
> Created attachment 55890 [details]
> GlobalModuleIndex.cpp preprocessed files
> 
> Everytime the crash is in a different file. it could be just because of
> memory issues.

this does seem like a HW issue. Are you sure you have a decent RISCV machine
without any memory issues?

I suspect ninja is building with all of the cores which pushes the memory usage
high.

Maybe lower the clock speed of the CPU you are using.
Try with a cross compile also.

[Bug tree-optimization/111394] Warning about uninitialized memory that is actually initialized

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Andrew Pinski  ---
(In reply to Sayu from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > N could be -1 which then would access out of bounds ..
> > 
> > I suspect if you add a check for n being negative in memoized_cut_rod the
> > warning will go away and a security issue is solved too.
> 
> I see. I didn't realize that negative indexes are allowed in C, I always
> assumed it was undefined behavior or just invalid. However, what does "*r_30
> + _122" mean in the warning?

well for pointers it is not undefined. Just in this case it is being allocated
via malloc which does make it undefined. But that is the whole reason for the
warning.

The trunk gives:
In function 'memoized_cut_rod_aux',
inlined from 'memoized_cut_rod' at :34:14:
:5:10: warning: '*' may be used uninitialized
[-Wmaybe-uninitialized]
5 | if (r[n] >= 0)
  | ~^~~

Which was fixed by PR 111253 .

But yes this is warning about r being used as not being initialized in the case
n in memoized_cut_rod being negative and acessing r[n] here.

[Bug tree-optimization/111393] ICE: Segmentation fault src/gcc/toplev.cc:314

[hiraditya at msn dot com via Gcc-bugs]

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

--- Comment #5 from AK  ---
Created attachment 55890
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55890=edit
GlobalModuleIndex.cpp preprocessed files

Everytime the crash is in a different file. it could be just because of memory
issues.

[Bug tree-optimization/110293] Some `A CMP (A NEEQ 0)` is not simplified in some cases

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Andrew Pinski  ---
Created attachment 55889
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55889=edit
Runtime test

[Bug bootstrap/111141] Compiling gcc-13.2.0 on Ubuntu 22.04.3 LTS, problem asm-generic/errno.h

[hp at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Hans-Peter Nilsson  ---
Possibly also *gcc-multilib*

[Bug bootstrap/111141] Compiling gcc-13.2.0 on Ubuntu 22.04.3 LTS, problem asm-generic/errno.h

[hp at gcc dot gnu.org via Gcc-bugs]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #5 from Hans-Peter Nilsson  ---
ISTR this one is what you get when you miss *linux-libc-dev*; at least it was
for Debian, and last I looked Ubuntu was still a derivative.
(Noticed last month when building a Docker suitable for gcc.)

[Bug tree-optimization/111394] Warning about uninitialized memory that is actually initialized

[aiya64bits at gmail dot com via Gcc-bugs]

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

Sayu  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #3 from Sayu  ---
(In reply to Andrew Pinski from comment #1)
> N could be -1 which then would access out of bounds ..
> 
> I suspect if you add a check for n being negative in memoized_cut_rod the
> warning will go away and a security issue is solved too.

I see. I didn't realize that negative indexes are allowed in C, I always
assumed it was undefined behavior or just invalid. However, what does "*r_30 +
_122" mean in the warning?

[PING][PATCH 2/2 v2] Ada: Finalization of constrained subtypes of unconstrained synchronized private extensions

[Richard Wai]

> On Aug 23, 2023, at 10:24, Richard Wai  wrote:
> 
> Somehow an error worked its way into the original diff (the diff itself), 
> making the previous patch fail to apply.
>  
> Fixed version attached.
>  
> Richard Wai
> ANNEXI-STRAYLINE
>  
> From: Richard Wai  > 
> Sent: Thursday, August 10, 2023 1:27 AM
> To: 'gcc-patches@gcc.gnu.org ' 
> mailto:gcc-patches@gcc.gnu.org>>
> Cc: 'Eric Botcazou' mailto:ebotca...@adacore.com>>; 
> 'Arnaud Charlet' mailto:char...@adacore.com>>; 'Stephen 
> Baird' mailto:ba...@adacore.com>>
> Subject: [PATCH 2/2] Ada: Finalization of constrained subtypes of 
> unconstrained synchronized private extensions
>  
> When generating TSS address finalization bodies for a tagged class-wide 
> subtype, GNAT climbs the parent chain looking for the first “non-constrained” 
> type. That type’s underlying type’s class-wide type is used as a “designated” 
> type for a dispatching TSS deep finalize call to the designated class-wide 
> type. In the case of a constrained subtype of an unconstrained synchronized 
> private extension, this ends up designating the underlying type of that 
> private extension. This means it targets the class-wide type of the actual 
> underlying concurrent type rather than the corresponding record. Ultimately 
> it ends up generating a call to the corresponding record’s deep finalizer, 
> but with incompatible types (concurrent_type’Class -> 
> concurrent_typeV’Class). This causes compilation to fail.
>  
> This patch adds extra logic to exp_ch7(Make_Finalize_Address_Stmts) to 
> identify such cases and ensure that the designated type is the corresponding 
> record type’s class-wide type in that situation.
>  
> Patch file is attached.
>  
> --  Begin change log entry –
>  
> ada: TSS finalize address subprogram generation for constrained subtypes of 
> unconstrained synchronized private extensions should take care to designate 
> the corresponding record of the underlying concurrent type.
>  
> When generating TSS finalize address subprograms for class-wide types of 
> constrained root types, it follows the parent chain looking for the first 
> “non-constrained” type. It is possible that such a type is a private 
> extension with the “synchronized” keyword, in which case the underlying type 
> is a concurrent type. When that happens, the designated type of the finalize 
> address subprogram should be the corresponding record’s class-wide-type.
>  
> Gcc/ada/
> * exp_ch3(Expand_Freeze_Class_Wide_Type): Expanded comments 
> explaining why TSS Finalize_Address is not generated for concurrent 
> class-wide types.
> * exp_ch7(Make_Finalize_Address_Stmts): Handle cases where 
> the underlying non-constrained parent type is a concurrent type, and adjust 
> the designated type to be the corresponding record’s class-wide type.
>  
> --  End change log entry –
>  
> This patch was bootstrapped on x86_64-*-freebsd13.2. One new test cases was 
> added. Note that 4 gnat test cases fail currently on master and are unrelated 
> to this patch.
>  
> Check-ada output of this patch:
>  
> === acats tests ===
> Running chapter a ...
> Running chapter c2 ...
> Running chapter c3 ...
> Running chapter c4 ...
> Running chapter c5 ...
> Running chapter c6 ...
> Running chapter c7 ...
> Running chapter c8 ...
> Running chapter c9 ...
> Running chapter ca ...
> Running chapter cb ...
> Running chapter cc ...
> Running chapter cd ...
> Running chapter ce ...
> Running chapter cxa ...
> Running chapter cxb ...
> Running chapter cxf ...
> Running chapter cxg ...
> Running chapter cxh ...
> Running chapter cz ...
> Running chapter d ...
> Running chapter e ...
> Running chapter l ...
> === acats Summary ===
> # of expected passes   2328
> # of unexpected failures 0
>  
> Native configuration is x86_64-unknown-freebsd13.2
>  
> === gnat tests ===
>  
> Schedule of variations:
> unix
>  
> Running target unix
> FAIL: gnat.dg/specs/alignment2.ads  (test for warnings, line 14)
> FAIL: gnat.dg/specs/alignment2.ads  (test for warnings, line 20)
> FAIL: gnat.dg/specs/alignment2.ads  (test for warnings, line 38)
> FAIL: gnat.dg/specs/alignment2.ads  (test for warnings, line 42)
>  
> === gnat Summary ===
>  
> # of expected passes   3401
> # of unexpected failures 4
> # of expected failures  23
> # of unsupported tests   10
> gnatmake version 14.0.0 20230809 (experimental)
>  
>  
> Richard Wai
> ANNEXI-STRAYLINE


[PATCH 1/2 v2] Ada: Synchronized private extensions are always limited

[Richard Wai]

Hi Arno,

No worries, and sorry for the trouble. I’m going to try using a different 
client for the gcc mailing list, it doesn’t seem to like Outlook. Thanks for 
catching that mistake!

Please advise how I can get this patch actually applied, given my lack of 
commit privilege.

Revised patch attached!

Thanks!



ada-synchronized-private-types-are-limited-v2.patch
Description: Binary data



> On Sep 1, 2023, at 08:08, Arnaud Charlet  wrote:
> 
>> For some reason, your email is endeing up in a strange format, I almost
>> missed the .patch file attached, making the review harder.
> 
> Never mind, I was on vacation earlier this month and then busy with a seminar 
> last week, so I started looking at your ping email before the original email 
> which did contain the patch easily found, sorry for the noise!
> 
> Arno

[Bug libstdc++/111351] constexpr std::string objects permitted to escape constant evaluation when SSO

[foom at fuhm dot net via Gcc-bugs]

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

--- Comment #5 from James Y Knight  ---
> Does using __builtin_is_constant_p on the union member not work?

I've created a proof-of-concept patch for libc++ to support SSO strings during
constant evaluation. It works.

If everyone disagrees with me and believes that this is a really awesome
foot-gun to give to users, I will go ahead and propose that patch to libc++
maintainers. (As mentioned, that'll cause more code to be compilable under
libc++ than is possible to permit under libstdc++/MSVC implementations).

However, I continue to believe the opposite outcome, prohibiting this
everywhere, would be preferable.

[Bug tree-optimization/111393] ICE: Segmentation fault src/gcc/toplev.cc:314

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
Did you first report this to Debian also:
See  for instructions.

[Bug tree-optimization/111393] ICE: Segmentation fault src/gcc/toplev.cc:314

[hiraditya at msn dot com via Gcc-bugs]

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

--- Comment #3 from AK  ---
gcc -v

COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/riscv64-linux-gnu/13/lto-wrapper
Target: riscv64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 13.1.0-6'
--with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=riscv64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libitm --disable-libquadmath
--disable-libquadmath-support --enable-plugin --enable-default-pie
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --disable-multilib --with-arch=rv64gc --with-abi=lp64d
--enable-checking=release --build=riscv64-linux-gnu --host=riscv64-linux-gnu
--target=riscv64-linux-gnu --with-build-config=bootstrap-lto-lean
--enable-link-serialization=32
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (Debian 13.1.0-6) 
root@lpi4a:/media/root/d2fc9f48-c166-4a9

Re: [PATCH v3] c++: Move consteval folding to cp_fold_r

[Jason Merrill via Gcc-patches]

On 9/8/23 14:24, Marek Polacek wrote:

On Thu, Sep 07, 2023 at 02:32:51PM -0400, Jason Merrill wrote:

On 9/7/23 11:23, Marek Polacek wrote:

On Tue, Sep 05, 2023 at 04:36:34PM -0400, Jason Merrill wrote:

On 9/5/23 15:59, Marek Polacek wrote:

On Tue, Sep 05, 2023 at 10:52:04AM -0400, Jason Merrill wrote:

On 9/1/23 13:23, Marek Polacek wrote:

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --

In the review of P2564:

it turned out that in order to correctly handle an example in the paper,
we should stop doing immediate evaluation in build_over_call and
bot_replace, and instead do it in cp_fold_r.  This patch does that.

Another benefit is that this is a pretty significant simplification, at
least in my opinion.  Also, this fixes the c++/110997 ICE (but the test
doesn't compile yet).

The main drawback seems to be that cp_fold_r doesn't process as much
code as we did before: uninstantiated templates


That's acceptable, it's an optional diagnostic.


and things like "false ? foo () : 1".


This is a problem.  Maybe we want cp_fold_r to recurse into the arms of a
COND_EXPR before folding them away?  Maybe only if we know we've seen an
immediate function?


Unfortunately we had already thrown the dead branch away when we got to
cp_fold_r.  I wonder if we have to adjust cxx_eval_conditional_expression
to call cp_fold_r on the dead branch too,


Hmm, I guess so.


perhaps with a new ff_ flag to skip the whole second switch in cp_fold_r?


Or factor out the immediate function handling to a separate walk function
that cp_fold_r also calls?


I did that.

But then it's possible that the in_immediate_context checks have to stay.


We can just not do the walk in immediate (or mce_true) context, like we
currently avoid calling cp_fold_function.


Right.  Unfortunately I have to check even when mce_true, consider

consteval int bar (int i) { if (i != 1) throw 1; return 0; }
constexpr int a = 0 ? bar(3) : 3;


I disagree; the call is in a manifestly constant-evaluated expression, and
so is now considered an immediate function context, and we should accept
that example.


Ack.  I was still living in pre-P2564 world.
  

For mce_unknown I guess we'd want
to set *non_constant_p instead of giving an error.


I did not do this because I haven't found a case where it would make
a difference.


I think it will given the above comment.


Correct.  For instance, in:

   consteval int bar (int i) { if (i != 1) throw 1; return 0; }

   constexpr int
   foo (bool b)
   {
 return b ? bar (3) : 2;
   }

   static_assert (foo (false) == 2);

we should complain only once.  I've implemented your suggestion to set
*non_constant_p instead of giving an error for mce_unknown.


diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index 0ca4370deab..397d5c7ec3f 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -2311,6 +2311,29 @@ cxx_dynamic_cast_fn_p (tree fndecl)
  && CP_DECL_CONTEXT (fndecl) == abi_node);
   }
+/* Return true if we are in the body of a consteval function. > +   This is in 
addition to in_immediate_context because that
+   uses current_function_decl which may not be available.  CTX is
+   the current constexpr context.  */
+
+static bool
+in_immediate_context (const constexpr_ctx *ctx)
+{
+  if (in_immediate_context ())
+return true;


Can't we check for mce_true here instead of looking at the call chain?


Yes.
  

+/* A wrapper around cp_fold_immediate_r.  */
+
+void
+cp_fold_immediate (tree *tp)
+{


Maybe return early if consteval isn't supported in the active standard?


Absolutely.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --
In the review of P2564:

it turned out that in order to correctly handle an example in the paper,
we should stop doing immediate evaluation in build_over_call and
bot_replace, and instead do it in cp_fold_r.  This patch does that.

Another benefit is that this is a pretty significant simplification, at
least in my opinion.  Also, this fixes the c++/110997 ICE (but the test
doesn't compile yet).

The main drawback seems to be that cp_fold_r doesn't process
uninstantiated templates.  We still have to handle things like
"false ? foo () : 1".  To that end, I've added cp_fold_immediate, called
on dead branches in cxx_eval_conditional_expression.

You'll see that I've reintroduced ADDR_EXPR_DENOTES_CALL_P here.  This
is to detect

   *()) ()
   (s.*::foo) ()

which were deemed ill-formed.

gcc/cp/ChangeLog:

* call.cc (build_over_call): Set ADDR_EXPR_DENOTES_CALL_P.  Don't handle
immediate_invocation_p here.
* constexpr.cc (in_immediate_context): New overload.
(cxx_eval_call_expression): Use mce_true for DECL_IMMEDIATE_FUNCTION_P.
(cxx_eval_conditional_expression): Call cp_fold_immediate.
* cp-gimplify.cc (maybe_replace_decl): Make 

[Bug tree-optimization/111394] Warning about uninitialized memory that is actually initialized

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
Adding:
if (n < 0)
exit(1);

Or:
if (n < 0)
  __builtin_unreachable();

Fixes the warning.

Yes the warning could be slightly better but it is definitely a bug in your
code if you are not checking the input ...

[Bug tree-optimization/111397] Spurious warning "'({anonymous})' is used uninitialized" when calling a __returns_twice__ function (-Wuninitialized -O2)

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
Looks loop copy header change which allowed the warning not to happen.

The warning is about the argument of test_setjmpex. Because GCC does not
realize __builtin_frame_address cannot jump to the test_setjmpex ...

In the case of GCC 12-13, the copy of the loop header happens during
thread-full rather than earlier and inserts:
  _4(ab) = _11(D);

Which is what is warned about.
_11(D) does not get proped into the phi ...

Re: gcc-12+: D / phobos runtime

[Iain Sandoe]

> On 12 Sep 2023, at 20:42, Rainer Orth  wrote:
> 
> ASSI  writes:
> 
>> Richard Biener via Gcc writes:
>>> I think we should fix this build problems.  Is there a bugzilla with
>>> more details about the problem?
>> 
>> No, I don't have an account on that bugtracker.
>> 
>> It is possible that the build would perhaps work, but the configure
>> check for the presence of a D compiler requires not just the compiler,
>> but also a runtime and thus fails on Cygwin.
> 
> Just try to configure gcc with --enable-libphobos, which overrides the
> default of LIBPHOBOS_SUPPORTED.  In quite a number of cases, this just
> works, but hasn't yet been verified.  You won't know until you try,
> though.

also you can add —with-libphobos-druntime-only to the GCC-11 build, that
makes a compiler sufficient for bootstrapping 12+ and is much less demanding
on completeness of OS support.

Iain

[Bug target/111340] gcc.dg/bitint-12.c fails on x86_64-apple-darwin or fails on x86_64-linux-gnu with -fPIE

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |11.5
 Status|ASSIGNED|RESOLVED

--- Comment #11 from Uroš Bizjak  ---
Fixed.

[Bug target/111340] gcc.dg/bitint-12.c fails on x86_64-apple-darwin or fails on x86_64-linux-gnu with -fPIE

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:513bfd3271e7b425e91b0a55f72c134d917e9c12

commit r11-11005-g513bfd3271e7b425e91b0a55f72c134d917e9c12
Author: Uros Bizjak 
Date:   Mon Sep 11 20:56:42 2023 +0200

i386: Handle CONST_WIDE_INT in output_pic_addr_const [PR111340]

PR target/111340

gcc/ChangeLog:

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

gcc/testsuite/ChangeLog:

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

(cherry picked from commit 048927ed8561ca994ad853fe85ccf8c2ca07a8fe)

[Bug middle-end/111337] ICE in gimple-isel.cc for RISC-V port

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Robin Dapp :

https://gcc.gnu.org/g:701b9309b687ed46188b9caeb7d88ad60b0212e5

commit r14-3910-g701b9309b687ed46188b9caeb7d88ad60b0212e5
Author: Juzhe-Zhong 
Date:   Tue Sep 12 21:32:02 2023 +0800

RISC-V: Support VECTOR BOOL vcond_mask optab[PR111337]

As this PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337

We support VECTOR BOOL vcond_mask to fix this following ICE:
0x1a9e309 gimple_expand_vec_cond_expr
../../../../gcc/gcc/gimple-isel.cc:283
0x1a9ea56 execute
../../../../gcc/gcc/gimple-isel.cc:390

gcc/ChangeLog:

PR target/111337
* config/riscv/autovec.md (vcond_mask_): New pattern.

[Bug tree-optimization/111397] New: Spurious warning "'({anonymous})' is used uninitialized" when calling a __returns_twice__ function (-Wuninitialized -O2)

[skiminki at gmail dot com via Gcc-bugs]

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

Bug ID: 111397
   Summary: Spurious warning "'({anonymous})' is used
uninitialized" when calling a __returns_twice__
function (-Wuninitialized -O2)
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skiminki at gmail dot com
  Target Milestone: ---

The following piece of code triggers a spurious warning when calling
test_setjmpex() on GCC 12.3 and GCC 13.2 using -O2 or -O3.

test.c:  # compile with: gcc -c -O2 -Wuninitialized test.c

  int globalVar = 1;
  int __attribute__ ((__returns_twice__)) test_setjmpex(void *context);

  void testfn()
  {
  int localVar = globalVar;

  while (!localVar) {

  // The below triggers:
  // warning: '({anonymous})' is used uninitialized [-Wuninitialized]
  test_setjmpex(__builtin_frame_address (0));

  if (globalVar)
  break;
  }
  }

No includes needed, so I omitted the .i file. Initially setting
tree-optimization as the component based on a guess.

This was found when compiling Weiss (chess engine) for mingw, but the reduced
test case triggers the warning on regular Linux, too. (Link to the original
issue: https://github.com/TerjeKir/weiss/issues/680 )

Godbolt link: https://godbolt.org/z/ec1dKsx4q

Experimentation with godbolt:
- Affected GCC versions: 12.1 - 12.3; 13.1 - 13.2 ; multiple targets (at least:
x86-64, aarch64, risc-v)
- No warning on 11.x
- No warning on trunk
- No warning on -O1

Full repro:
---
# Ubuntu 23.04 / x86_64-linux-gnu
docker run --rm -v "$PWD":/usr/src/myapp -w /usr/src/myapp gcc:13.2 gcc -v -c
-O2 -Wuninitialized test.c

Repro output:
-
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-linux-gnu
Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu
--disable-multilib --enable-languages=c,c++,fortran,go
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-c' '-O2' '-Wuninitialized' '-mtune=generic'
'-march=x86-64'
 /usr/local/libexec/gcc/x86_64-linux-gnu/12.3.0/cc1 -quiet -v -imultiarch
x86_64-linux-gnu test.c -quiet -dumpbase test.c -dumpbase-ext .c -mtune=generic
-march=x86-64 -O2 -Wuninitialized -version -o /tmp/ccZm0Pke.s
GNU C17 (GCC) version 12.3.0 (x86_64-linux-gnu)
compiled by GNU C version 12.3.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-linux-gnu/12.3.0/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/x86_64-linux-gnu/12.3.0/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-linux-gnu/12.3.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C17 (GCC) version 12.3.0 (x86_64-linux-gnu)
compiled by GNU C version 12.3.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 1e1b4098557fa4aa478a5470075c20a5
test.c: In function 'testfn':
test.c:12:11: warning: '({anonymous})' is used uninitialized [-Wuninitialized]
   12 |   test_setjmpex(__builtin_frame_address (0));
  |   ^~
COLLECT_GCC_OPTIONS='-v' '-c' '-O2' '-Wuninitialized' '-mtune=generic'
'-march=x86-64'
 as -v --64 -o test.o /tmp/ccZm0Pke.s
GNU assembler version 2.40 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.40
COMPILER_PATH=/usr/local/libexec/gcc/x86_64-linux-gnu/12.3.0/:/usr/local/libexec/gcc/x86_64-linux-gnu/12.3.0/:/usr/local/libexec/gcc/x86_64-linux-gnu/:/usr/local/lib/gcc/x86_64-linux-gnu/12.3.0/:/usr/local/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/local/lib/gcc/x86_64-linux-gnu/12.3.0/:/usr/local/lib/gcc/x86_64-linux-gnu/12.3.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/usr/local/lib/gcc/x86_64-linux-gnu/12.3.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-c' '-O2' '-Wuninitialized' '-mtune=generic'
'-march=x86-64'

[Bug libstdc++/111172] Dead code in std::get for variant?

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-09-12
 Status|UNCONFIRMED |NEW

Re: libgo: Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing (instead of build-time 'CC' etc.) [PR109951] (was: [PATCH 3/4] libgo/test: Fix compilation for build sysroot)

[Ian Lance Taylor via Gcc-patches]

On Tue, Sep 12, 2023 at 4:16 AM Thomas Schwinge  wrote:
>
> As we've found, this is conceptually problematic, as discussed in
> 
> "Consider '--with-build-sysroot=[...]' for target libraries' build-tree 
> testing (instead of build-time 'CC' etc.)
> [PR109951]".
> I therefore suggest to apply to libgo the conceptually same changes
> as I've just pushed for libgomp:
> 
> "libgomp: Consider '--with-build-sysroot=[...]' for target libraries' 
> build-tree testing (instead of build-time 'CC'
> etc.) [PR91884, PR109951]".
> OK to push (via Ian/Go upstream) the attached
> "libgo: Consider '--with-build-sysroot=[...]' for target libraries' 
> build-tree testing (instead of build-time 'CC' etc.) [PR109951]"?
>
> By the way, I've tested this one via hard-coding
> 'libgo/configure.ac:USE_DEJAGNU' to 'yes', and observing that my
> "quick hack to replicate the original requirement"
> ('internal_error ("MISSING SYSROOT");') no longer triggers.

Thanks.  Committed.

Ian

[Bug testsuite/109951] [14 Regression] libgomp, testsuite: non-native multilib c++ tests fail on Darwin.

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

https://gcc.gnu.org/g:08dfde5a30ca818715e6d2bc2f2b592f8a98af77

commit r14-3909-g08dfde5a30ca818715e6d2bc2f2b592f8a98af77
Author: Ian Lance Taylor 
Date:   Tue Sep 12 09:11:48 2023 -0700

libgo: fix DejaGNU testsuite compiler when using build sysroot

Patch from Thomas Schwinge.

PR testsuite/109951
* configure.ac: 'AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)'.
* Makefile.in: Regenerate.
* configure: Likewise.
* testsuite/Makefile.in: Likewise.
* testsuite/lib/libgo.exp (libgo_init): If
'--with-build-sysroot=[...]' was specified, use it for build-tree
testing.
* testsuite/libgo-test-support.exp.in (GOC_UNDER_TEST): Don't set.
(SYSROOT_CFLAGS_FOR_TARGET): Set.

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/527755

[Bug c/111394] Warning about uninitialized memory that is actually initialized

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
N could be -1 which then would access out of bounds ..

I suspect if you add a check for n being negative in memoized_cut_rod the
warning will go away and a security issue is solved too.

[Bug libstdc++/111390] 'make check-compile' target is not useful

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jonathan Wakely  ---
The fact nobody has tried to use it in 10+ years makes me think it's not all
that useful.

Re: [PATCH] preprocessor: c++: Support `#pragma GCC target' macros [PR87299]

[Lewis Hyatt via Gcc-patches]

On Tue, Aug 8, 2023 at 5:53 PM Jason Merrill  wrote:
>
> On 7/31/23 22:22, Lewis Hyatt via Gcc-patches wrote:
> > `#pragma GCC target' is not currently handled in preprocess-only mode (e.g.,
> > when running gcc -E or gcc -save-temps). As noted in the PR, this means that
> > if the target pragma defines any macros, those macros are not effective in
> > preprocess-only mode. Similarly, such macros are not effective when
> > compiling with C++ (even when compiling without -save-temps), because C++
> > does not process the pragma until after all tokens have been obtained from
> > libcpp, at which point it is too late for macro expansion to take place.
> >
> > Since r13-1544 and r14-2893, there is a general mechanism to handle pragmas
> > under these conditions as well, so resolve the PR by using the new "early
> > pragma" support.
> >
> > toplev.cc required some changes because the target-specific handlers for
> > `#pragma GCC target' may call target_reinit(), and toplev.cc was not 
> > expecting
> > that function to be called in preprocess-only mode.
> >
> > I added some additional testcases from the PR for x86. The other targets
> > that support `#pragma GCC target' (aarch64, arm, nios2, powerpc, s390)
> > already had tests verifying that the pragma sets macros as expected; here I
> > have added -save-temps to some of them, to test that it now works in
> > preprocess-only mode as well.
> >
> > gcc/c-family/ChangeLog:
> >
> >   PR preprocessor/87299
> >   * c-pragma.cc (init_pragma): Register `#pragma GCC target' and
> >   related pragmas in preprocess-only mode, and enable early handling.
> >   (c_reset_target_pragmas): New function refactoring code from...
> >   (handle_pragma_reset_options): ...here.
> >   * c-pragma.h (c_reset_target_pragmas): Declare.
> >
> > gcc/cp/ChangeLog:
> >
> >   PR preprocessor/87299
> >   * parser.cc (cp_lexer_new_main): Call c_reset_target_pragmas ()
> >   after preprocessing is complete, before starting compilation.
> >
> > gcc/ChangeLog:
> >
> >   PR preprocessor/87299
> >   * toplev.cc (no_backend): New static global.
> >   (finalize): Remove argument no_backend, which is now a
> >   static global.
> >   (process_options): Likewise.
> >   (do_compile): Likewise.
> >   (target_reinit): Don't do anything in preprocess-only mode.
> >   (toplev::main): Adapt to no_backend change.
> >   (toplev::finalize): Likewise.
> >
> > gcc/testsuite/ChangeLog:
> >
> >   PR preprocessor/87299
> >   * c-c++-common/pragma-target-1.c: New test.
> >   * c-c++-common/pragma-target-2.c: New test.
> >   * g++.target/i386/pr87299-1.C: New test.
> >   * g++.target/i386/pr87299-2.C: New test.
> >   * gcc.target/i386/pr87299-1.c: New test.
> >   * gcc.target/i386/pr87299-2.c: New test.
> >   * gcc.target/s390/target-attribute/tattr-2.c: Add -save-temps to the
> >   options, to test preprocess-only mode as well.
> >   * gcc.target/aarch64/pragma_cpp_predefs_1.c: Likewise.
> >   * gcc.target/arm/pragma_arch_attribute.c: Likewise.
> >   * gcc.target/nios2/custom-fp-2.c: Likewise.
> >   * gcc.target/powerpc/float128-3.c: Likewise.
> > ---
> >
> > Notes:
> >  Hello-
> >
> >  This patch fixes the PR by enabling early pragma handling for `#pragma 
> > GCC
> >  target' and related pragmas such as `#pragma GCC push_options'. I did 
> > not
> >  need to touch any target-specific code, however I did need to make a 
> > change
> >  to toplev.cc, affecting all targets, to make it safe to call 
> > target_reinit()
> >  in preprocess-only mode. (Otherwise, it would be necessary to modify 
> > the
> >  implementation of target pragmas in every target, to avoid this code 
> > path.)
> >  That was the only complication I ran into.
> >
> >  Regarding testing, I did: (thanks to GCC compile farm for the non-x86
> >  targets)
> >
> >  bootstrap + regtest all languages - x86_64-pc-linux-gnu
> >  bootstrap + regtest c/c++ - powerpc64le-unknown-linux-gnu,
> >  aarch64-unknown-linux-gnu
> >
> >  The following backends also implement this pragma so ought to be 
> > tested:
> >  arm
> >  nios2
> >  s390
> >
> >  I am not able to test those directly. I did add coverage to their 
> > testsuites
> >  (basically, adding -save-temps to any existing test, causes it to test 
> > the
> >  pragma in preprocess-only mode.) Then, I verified on x86_64 with a 
> > cross
> >  compiler, that the modified testcases fail before the patch and pass
> >  afterwards. nios2 is an exception, it does not set any libcpp macros 
> > when
> >  handling the pragma, so there is nothing to test, but I did verify that
> >  processing the pragma in preprocess-only mode does not cause any 
> > problems.
> >  The cross compilers tested were targets arm-unknown-linux-gnueabi,
> >  

Re: gcc-12+: D / phobos runtime

[Richard Biener via Gcc]

> Am 12.09.2023 um 21:18 schrieb ASSI :
> 
> Richard Biener via Gcc writes:
>> I think we should fix this build problems.  Is there a bugzilla with
>> more details about the problem?
> 
> No, I don't have an account on that bugtracker.
> 
> It is possible that the build would perhaps work, but the configure
> check for the presence of a D compiler requires not just the compiler,
> but also a runtime and thus fails on Cygwin.

The alternative then ist to build D with a cross compiler.

> 
> Regards,
> Achim.
> -- 
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
> 
> Waldorf MIDI Implementation & additional documentation:
> http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
> 

Re: gcc-12+: D / phobos runtime

[Rainer Orth]

ASSI  writes:

> Richard Biener via Gcc writes:
>> I think we should fix this build problems.  Is there a bugzilla with
>> more details about the problem?
>
> No, I don't have an account on that bugtracker.
>
> It is possible that the build would perhaps work, but the configure
> check for the presence of a D compiler requires not just the compiler,
> but also a runtime and thus fails on Cygwin.

Just try to configure gcc with --enable-libphobos, which overrides the
default of LIBPHOBOS_SUPPORTED.  In quite a number of cases, this just
works, but hasn't yet been verified.  You won't know until you try,
though.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH V6] RISC-V: Enable vec_int testsuite for RVV VLA vectorization

[Robin Dapp via Gcc-patches]

> Most (all?) of those are due to:
> f951: Warning: command-line option '-Wno-psabi' is valid for 
> C/C++/D/LTO/ObjC/ObjC++ but not for Fortran
> so no real bug.

When pushing this, I'd take the liberty of enabling the recently merged vector
ABI so we don't require -Wno-psabi anymore.  All Fortran FAILs disappear and
nothing else changes.

--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -11166,12 +11166,12 @@ proc check_vect_support_and_set_flags { } {
 } elseif [istarget riscv64-*-*] {
if [check_effective_target_riscv_vector_hw] {
lappend DEFAULT_VECTCFLAGS "--param" 
"riscv-autovec-preference=scalable"
-   lappend DEFAULT_VECTCFLAGS "-Wno-psabi"
+   lappend DEFAULT_VECTCFLAGS "--param" "riscv-vector-abi"
set dg-do-what-default run
} else {
lappend DEFAULT_VECTCFLAGS "-march=rv64gcv_zvfh" "-mabi=lp64d"
lappend DEFAULT_VECTCFLAGS "--param" 
"riscv-autovec-preference=scalable"
-   lappend DEFAULT_VECTCFLAGS "-Wno-psabi"
+   lappend DEFAULT_VECTCFLAGS "--param" "riscv-vector-abi"
set dg-do-what-default compile
}
 } else {

Regards
 Robin

Re: [PATCH] ggc, jit: forcibly clear GTY roots in jit

[Antoni Boucher via Gcc-patches]

I added it to bugzilla here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111396

Since this only reproduces part of the issue, please let me test again
with rustc_codegen_gcc after adding the missing fix.

I confirmed that the fix is in
https://github.com/antoyo/gcc/commit/9d5b6b20efa20825926196759d50706a604c64a8
so you might as well include all of this (except the linetable
condition in toplev.cc).

On Tue, 2023-09-12 at 14:38 -0400, David Malcolm wrote:
> On Tue, 2023-09-12 at 13:36 -0400, Antoni Boucher wrote:
> > In the mean time, here's a (Rust) reproducer for the issue:
> > 
> > fn main() {
> >     for _ in 0..5 {
> >     let context = Context::default();
> >     context.add_command_line_option("-flto");
> >    
> > context.set_optimization_level(OptimizationLevel::Aggressive);
> >     context.add_driver_option("-nostdlib");
> > 
> >     let int_type = context.new_type::();
> > 
> >     let function = context.new_function(None,
> > FunctionType::Exported, int_type, &[], "main", false);
> >     let block = function.new_block("start");
> >     let value = context.new_rvalue_from_int(int_type, 42);
> >     block.end_with_return(None, value);
> > 
> >     context.compile_to_file(OutputKind::Executable, "my_exe");
> >     }
> > }
> 
> Can we get this in bugzilla please?  If you generate a .c version of
> the context (via gcc_jit_context_dump_reproducer_to_file) I can try
> to
> debug it.
> 
> Thanks
> Dave
> 

[Bug jit/111396] New: Segfault when using -flto with libgccjit

[bouanto at zoho dot com via Gcc-bugs]

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

Bug ID: 111396
   Summary: Segfault when using -flto with libgccjit
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

Created attachment 55888
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55888=edit
Reproducer for part of the bug

Hi.
There's a bug when compiling multiple times with -flto.
I attached a reproducer for a part of the bug.

(The other part of the bug should be fixed by
https://gcc.gnu.org/pipermail/jit/2023q3/001668.html.)

Re: gcc-12+: D / phobos runtime

[ASSI]

Richard Biener via Gcc writes:
> I think we should fix this build problems.  Is there a bugzilla with
> more details about the problem?

No, I don't have an account on that bugtracker.

It is possible that the build would perhaps work, but the configure
check for the presence of a D compiler requires not just the compiler,
but also a runtime and thus fails on Cygwin.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

[Bug middle-end/111395] New: RISC-V Vector Fortran: ICE in get_avl_or_vl_reg (vsetvl pass)

[jeremy.bennett at embecosm dot com via Gcc-bugs]

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

Bug ID: 111395
   Summary: RISC-V Vector Fortran: ICE in get_avl_or_vl_reg
(vsetvl pass)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeremy.bennett at embecosm dot com
  Target Milestone: ---

Created attachment 55887
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55887=edit
Reproducer

Found because of failure of SPEC CPU 2017 621_wrf_s to compile.

This appears to be related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11137, which is now resolved.

Reproducer (test.f90):

MODULE a
  REAL b
CONTAINS
  SUBROUTINE c(d,KTE)
REAL,DIMENSION(KTE) :: d,e,f,g
REAL,DIMENSION(KTE) :: h
i : DO j=1,b
   z=k
   DO l=m,n
  IF(o>=p)THEN
 IF(laf)THEN
   DO l=m,n
  d=h
   ENDDO
ENDIF
  END SUBROUTINE c
END MODULE a

Compile with:

riscv64-unknown-linux-gnu-gfortran -w -march=rv64gcv -mabi=lp64d -c -Ofast \
-ftree-vectorize --param=riscv-autovec-preference=scalable test.f90

Output:

during RTL pass: vsetvl
test.f90:37:18:

   37 |   END SUBROUTINE c
  |  ^
internal compiler error: in get_avl_or_vl_reg, at
config/riscv/riscv-vsetvl.cc:2297
0x9a24e5 riscv_vector::vector_insn_info::get_avl_or_vl_reg() const
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:2297
0x9a24e5 riscv_vector::vector_insn_info::get_avl_or_vl_reg() const
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:2271
0x16102f7 insert_vsetvl
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:724
0x1610edd pass_vsetvl::commit_vsetvls()
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:3615
0x1611191 pass_vsetvl::pre_vsetvl()
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:3728
0x1611ed8 pass_vsetvl::lazy_vsetvl()
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:4360
0x1612031 pass_vsetvl::execute(function*)
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:4395
0x1612031 pass_vsetvl::execute(function*)
/home/jeremy/gittrees/mustang/gcc/gcc/config/riscv/riscv-vsetvl.cc:4376
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

System information
--

Using built-in specs.
COLLECT_GCC=riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/jeremy/gittrees/mustang/install/libexec/gcc/riscv64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /home/jeremy/gittrees/mustang/gcc/configure
--target=riscv64-unknown-linux-gnu
--prefix=/home/jeremy/gittrees/mustang/install
--with-sysroot=/home/jeremy/gittrees/mustang/install/sysroot
--with-pkgversion=g35f498d8dfc --with-system-zlib --enable-shared --enable-tls
--enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap
--src=/home/jeremy/gittrees/mustang/gcc --enable-multilib --with-abi=lp64d
--with-arch=rv64gc --with-tune= --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2
   -mcmodel=medany' 'CXXFLAGS_FOR_TARGET=-O2-mcmodel=medany'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230912 (experimental) (g35f498d8dfc) 

Tool chain built with component commits:

Repository   SHA-1 hash (commit ID)  
--   --  
gcc  35f498d8dfc8e579eaba2ff2d2b96769c632fd58
binutils-gdb 318d3bda5cad124bd11eebb0349d0f183ba625b1
glibc073edbdfabaad4786e974a451efe4b6b3f7a5a61

[V2] RISC-V: Replace not + bitwise_imm with li + bitwise_not

[Jivan Hakobyan via Gcc-patches]

In the case when we have C code like this

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

GCC generates the following instruction sequence

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

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

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


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

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


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

[Bug libstdc++/111390] 'make check-compile' target is not useful

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=103324
 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
kinda related: bug 103324

(In reply to Jonathan Wakely from comment #0)
> If we want to do compilation-only testing, I think it would be better to
> modify the dejagnu procs so that "dg-do run" tests are treated as "dg-do
> compile".

Yes, I think this solution would be preferable to ripping it out entirely.
Also, it would be useful if such a target were available tree-wide, rather than
just for libstdc++.

[Bug other/111360] contrib/gcc_update: bad test

[egallager at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #4)
> Fixed on trunk

Cool, thanks. I'm wondering if it might be worthwhile to run shellcheck[1] on
GCC's various shell scripts to catch similar mistakes? I just tried running it
on all the ones in contrib/, but the output seemed rather noisy...

[1]: https://www.shellcheck.net/

[Bug tree-optimization/111393] ICE: Segmentation fault src/gcc/toplev.cc:314

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-09-12
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Can you provide the preprocessed source?

Also provide the output of `gcc -v`?

[PATCH] check_GNU_style.py: Skip .md square bracket linting

[Patrick O'Neill]

This testcase causes lots of false-positives for machine description files.

contrib/ChangeLog:

* check_GNU_style_lib.py: Skip machine description file bracket linting.

Signed-off-by: Patrick O'Neill 
---
 contrib/check_GNU_style_lib.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/contrib/check_GNU_style_lib.py b/contrib/check_GNU_style_lib.py
index 94a742941cf..5096b1333f3 100755
--- a/contrib/check_GNU_style_lib.py
+++ b/contrib/check_GNU_style_lib.py
@@ -182,6 +182,9 @@ class SquareBracketCheck:
 self.re = re.compile('\w\s+(\[)')

 def check(self, filename, lineno, line):
+if filename.endswith('.md'):
+return None
+
 m = self.re.search(line)
 if m != None:
 return CheckError(filename, lineno,
--
2.34.1

[Bug c/111394] New: Warning about uninitialized memory that is actually initialized

[aiya64bits at gmail dot com via Gcc-bugs]

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

Bug ID: 111394
   Summary: Warning about uninitialized memory that is actually
initialized
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aiya64bits at gmail dot com
  Target Milestone: ---

#include 
#include 

int memoized_cut_rod_aux(const int p[], int n, int c, int r[]) {
if (r[n] >= 0)
return r[n];

int q = p[n - 1];
if (!n) {
q = 0;
} else {
for (int i = 1; i <= n / 2; ++i) {
const int v = p[i - 1] + memoized_cut_rod_aux(p, n - i, c, r) - c;
if (v > q)
q = v;
}
}
r[n] = q;
return q;
}

int memoized_cut_rod(const int p[], int n, int c) {
int result;

int *const r = malloc((n + 1) * sizeof(int));
if (!r) {
fprintf(stderr, "Out of memory.\n");
exit(1);
}

for (int i = 0; i < n + 1; ++i)
r[i] = -1;

result = memoized_cut_rod_aux(p, n, c, r);
free(r);
return result;
}

The above code when compiled with "gcc -Wall -O3 -o rod_cutting rod_cutting.c"
gives the following warning:

In function ‘memoized_cut_rod_aux’,
inlined from ‘memoized_cut_rod’ at rod_cutting.c:95:17:
rod_cutting.c:59:14: warning: ‘*r_30 + _122’ may be used uninitialized
[-Wmaybe-uninitialized]
   59 | if (r[n] >= 0)
  | ~^~~

But all the elements of r are initialized to -1 in the loop in
memoized_cut_rod. I got this warning with GCC 13.2.1 and then got the same
warning with the trunk branch.

Re: [committed] libstdc++: Format Python code according to PEP8

[Eric Gallager via Gcc-patches]

On Tue, Sep 12, 2023 at 7:46 AM Jonathan Wakely via Gcc-patches
 wrote:
>
> Tested x86_64-linux. Pushed to trunk.
>
> -- >8 --
>
> These files were filtered through autopep8 to reformat them more
> conventionally.
>

Thanks for this; I'm wondering if it might be worthwhile to do
likewise for other python scripts elsewhere in the repository? e.g. in
contrib/

> libstdc++-v3/ChangeLog:
>
> * python/libstdcxx/v6/printers.py: Reformat.
> * python/libstdcxx/v6/xmethods.py: Likewise.
> ---
>  libstdc++-v3/python/libstdcxx/v6/printers.py | 651 +++
>  libstdc++-v3/python/libstdcxx/v6/xmethods.py |  58 +-
>  2 files changed, 446 insertions(+), 263 deletions(-)
>
> diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py 
> b/libstdc++-v3/python/libstdcxx/v6/printers.py
> index 37a447b514b..c0056de2565 100644
> --- a/libstdc++-v3/python/libstdcxx/v6/printers.py
> +++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
> @@ -18,10 +18,12 @@
>  import gdb
>  import itertools
>  import re
> -import sys, os, errno
> +import sys
> +import os
> +import errno
>  import datetime
>
> -### Python 2 + Python 3 compatibility code
> +# Python 2 + Python 3 compatibility code
>
>  # Resources about compatibility:
>  #
> @@ -38,7 +40,7 @@ import datetime
>  # 
>
>  if sys.version_info[0] > 2:
> -### Python 3 stuff
> +# Python 3 stuff
>  Iterator = object
>  # Python 3 folds these into the normal functions.
>  imap = map
> @@ -47,7 +49,7 @@ if sys.version_info[0] > 2:
>  long = int
>  _utc_timezone = datetime.timezone.utc
>  else:
> -### Python 2 stuff
> +# Python 2 stuff
>  class Iterator:
>  """Compatibility mixin for iterators
>
> @@ -98,6 +100,8 @@ except ImportError:
>  # Starting with the type ORIG, search for the member type NAME.  This
>  # handles searching upward through superclasses.  This is needed to
>  # work around http://sourceware.org/bugzilla/show_bug.cgi?id=13615.
> +
> +
>  def find_type(orig, name):
>  typ = orig.strip_typedefs()
>  while True:
> @@ -116,8 +120,10 @@ def find_type(orig, name):
>  else:
>  raise ValueError("Cannot find type %s::%s" % (str(orig), name))
>
> +
>  _versioned_namespace = '__8::'
>
> +
>  def lookup_templ_spec(templ, *args):
>  """
>  Lookup template specialization templ
> @@ -139,6 +145,8 @@ def lookup_templ_spec(templ, *args):
>
>  # Use this to find container node types instead of find_type,
>  # see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91997 for details.
> +
> +
>  def lookup_node_type(nodename, containertype):
>  """
>  Lookup specialization of template NODENAME corresponding to 
> CONTAINERTYPE.
> @@ -168,6 +176,7 @@ def lookup_node_type(nodename, containertype):
>  pass
>  return None
>
> +
>  def is_member_of_namespace(typ, *namespaces):
>  """
>  Test whether a type is a member of one of the specified namespaces.
> @@ -181,6 +190,7 @@ def is_member_of_namespace(typ, *namespaces):
>  return True
>  return False
>
> +
>  def is_specialization_of(x, template_name):
>  """
>  Test whether a type is a specialization of the named class template.
> @@ -195,12 +205,14 @@ def is_specialization_of(x, template_name):
>  return re.match('^std::(%s)?%s<.*>$' % (_versioned_namespace, 
> template_name), x) is not None
>  return re.match('^std::%s<.*>$' % template_name, x) is not None
>
> +
>  def strip_versioned_namespace(typename):
>  global _versioned_namespace
>  if _versioned_namespace:
>  return typename.replace(_versioned_namespace, '')
>  return typename
>
> +
>  def strip_inline_namespaces(type_str):
>  "Remove known inline namespaces from the canonical name of a type."
>  type_str = strip_versioned_namespace(type_str)
> @@ -212,6 +224,7 @@ def strip_inline_namespaces(type_str):
>  type_str = type_str.replace(fs_ns+'v1::', fs_ns)
>  return type_str
>
> +
>  def get_template_arg_list(type_obj):
>  "Return a type's template arguments as a list"
>  n = 0
> @@ -223,6 +236,7 @@ def get_template_arg_list(type_obj):
>  return template_args
>  n += 1
>
> +
>  class SmartPtrIterator(Iterator):
>  "An iterator for smart pointer types with a single 'child' value"
>
> @@ -238,28 +252,29 @@ class SmartPtrIterator(Iterator):
>  self.val, val = None, self.val
>  return ('get()', val)
>
> +
>  class SharedPointerPrinter:
>  "Print a shared_ptr, weak_ptr, atomic, or atomic"
>
> -def __init__ (self, typename, val):
> +def __init__(self, typename, val):
>  self.typename = strip_versioned_namespace(typename)
>  self.val = val
>  self.pointer = val['_M_ptr']
>
> -def children (self):
> +def children(self):
>  return SmartPtrIterator(self.pointer)
>
>  # Return the _Sp_counted_base<>* that holds the refcounts.
> -   

[Bug tree-optimization/111393] ICE: Segmentation fault src/gcc/toplev.cc:314

[hiraditya at msn dot com via Gcc-bugs]

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

--- Comment #1 from AK  ---
oot/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/build# ninja clang
check-clang
[100/845] Building CXX object
tools/clang/lib/Serialization/CMakeFiles/obj.clangSerialization.dir/GlobalModuleIndex.cpp.o
FAILED:
tools/clang/lib/Serialization/CMakeFiles/obj.clangSerialization.dir/GlobalModuleIndex.cpp.o
 
/usr/bin/c++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GLIBCXX_ASSERTIONS -D_GNU_SOURCE
-D_LIBCPP_ENABLE_HARDENED_MODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS
-I/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/build/tools/clang/lib/Serialization
-I/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/clang/lib/Serialization
-I/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/clang/include
-I/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/build/tools/clang/include
-I/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/build/include
-I/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/llvm/include
-fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time
-fno-lifetime-dse -Wall -Wextra -Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long
-Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-nonnull
-Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move
-Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment
-Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color
-ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual
-fno-strict-aliasing  -fno-exceptions -funwind-tables -fno-rtti -UNDEBUG
-std=c++17 -MD -MT
tools/clang/lib/Serialization/CMakeFiles/obj.clangSerialization.dir/GlobalModuleIndex.cpp.o
-MF
tools/clang/lib/Serialization/CMakeFiles/obj.clangSerialization.dir/GlobalModuleIndex.cpp.o.d
-o
tools/clang/lib/Serialization/CMakeFiles/obj.clangSerialization.dir/GlobalModuleIndex.cpp.o
-c
/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/clang/lib/Serialization/GlobalModuleIndex.cpp
In file included from
/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/llvm/include/llvm/ADT/DenseMapInfo.h:20,
 from
/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/llvm/include/llvm/ADT/DenseMap.h:17,
 from
/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/clang/include/clang/Serialization/GlobalModuleIndex.h:18,
 from
/media/root/d2fc9f48-c166-4a9e-9868-133a1db7af88/llvm-project/clang/lib/Serialization/GlobalModuleIndex.cpp:13:
/usr/include/c++/13/tuple: In instantiation of ‘struct std::_Tuple_impl<0,
clang::ModuleFileExtensionReader*,
std::default_delete >’:
/usr/include/c++/13/tuple:1232:11:   required from ‘class
std::tuple >’
/usr/include/c++/13/bits/unique_ptr.h:232:27:   required from ‘class
std::__uniq_ptr_impl >’
/usr/include/c++/13/bits/unique_ptr.h:239:12:   required from ‘struct
std::__uniq_ptr_data, true, true>’
/usr/include/c++/13/bits/unique_ptr.h:283:33:   required from ‘class
std::unique_ptr’
/usr/include/c++/13/bits/stl_vector.h:367:35:   required from
‘std::_Vector_base<_Tp, _Alloc>::~_Vector_base() [with _Tp =
std::unique_ptr; _Alloc =
std::allocator >]’
/usr/include/c++/13/bits/stl_vector.h:528:7:   required from here
/usr/include/c++/13/tuple:269:7: internal compiler error: Segmentation fault
  269 |   _M_head(_Tuple_impl& __t) noexcept { return _Base::_M_head(__t);
}
  |   ^~~
0x85d7c5 crash_signal
../../src/gcc/toplev.cc:314
0xa0d5e0 profile_count::operator==(profile_count const&) const
../../src/gcc/profile-count.h:865
0xa0d5e0 profile_count::apply_probability(profile_probability) const
../../src/gcc/profile-count.h:1104
0xa0d5e0 edge_def::count() const
../../src/gcc/basic-block.h:639
0xa0d5e0 eliminate_tail_call
../../src/gcc/tree-tailcall.cc:982
0xa0d5e0 optimize_tail_call
../../src/gcc/tree-tailcall.cc:1053
0xa0d5e0 tree_optimize_tail_calls_1
../../src/gcc/tree-tailcall.cc:1193
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/111393] New: ICE: Segmentation fault src/gcc/toplev.cc:314

[hiraditya at msn dot com via Gcc-bugs]

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

Bug ID: 111393
   Summary: ICE: Segmentation fault src/gcc/toplev.cc:314
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hiraditya at msn dot com
  Target Milestone: ---

riscv64-gnu-linux (version Debian 13.1) building llvm-project
(GlobalModuleIndex.cpp) crashed with ICE.

src/gcc/toplev.cc:314
profile_count::operator==(proile_count const&) const
 ../../src/gcc/profile-count.h:865
profile_count::apply_probability(proile_probability) const
 ../../src/gcc/profile-count.h:1104

Re: [PATCH] ggc, jit: forcibly clear GTY roots in jit

[David Malcolm via Gcc-patches]

On Tue, 2023-09-12 at 13:36 -0400, Antoni Boucher wrote:
> In the mean time, here's a (Rust) reproducer for the issue:
> 
> fn main() {
>     for _ in 0..5 {
>     let context = Context::default();
>     context.add_command_line_option("-flto");
>    
> context.set_optimization_level(OptimizationLevel::Aggressive);
>     context.add_driver_option("-nostdlib");
> 
>     let int_type = context.new_type::();
> 
>     let function = context.new_function(None,
> FunctionType::Exported, int_type, &[], "main", false);
>     let block = function.new_block("start");
>     let value = context.new_rvalue_from_int(int_type, 42);
>     block.end_with_return(None, value);
> 
>     context.compile_to_file(OutputKind::Executable, "my_exe");
>     }
> }

Can we get this in bugzilla please?  If you generate a .c version of
the context (via gcc_jit_context_dump_reproducer_to_file) I can try to
debug it.

Thanks
Dave

[Bug target/98596] registers not reused on RISC-V

[vineetg at gcc dot gnu.org via Gcc-bugs]

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

Vineet Gupta  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||vineetg at gcc dot gnu.org

--- Comment #3 from Vineet Gupta  ---
This is fixed with following commit (and will make it into gcc-14)

commit b41d7eb0e14785ff0ad6e6922cbd4c880e680bf9
Author: Vineet Gupta 
Date:   Mon Aug 7 13:45:29 2023 -0700

RISC-V: Enable Hoist to GCSE simple constants

Hoist want_to_gcse_p () calls rtx_cost () to compute max distance for
hoist candidates. For a simple const (say 6 which needs seperate insn "LI
6")
backend currently returns 0, causing Hoist to bail and elide GCSE.

Note that constants requiring more than 1 insns to setup were working
fine since riscv_rtx_costs () was returning non-zero (although that
itself might need refining: see bugzilla 39).

To keep testsuite parity, some V tests need updating which started failing
in the new costing regime.

Re: Complex numbers in compilers - upcoming GNU Tools Cauldron.

[Toon Moene]

On 9/12/23 11:25, Richard Biener wrote:


On Tue, Sep 5, 2023 at 10:44 PM Toon Moene  wrote:



This is even obvious in weather forecasting software I have to deal with
*today* (all written in Fortran). Some models use complex variables to
encode the "spectral" (wave-decomposed) computations in parts where that
is useful - others just "degrade" those algorithms to explicitly use reals.


Lack of applications / benchmarks using complex numbers is also a
problem for any work on this.


Yes, a certain amount of circular "reasoning" is at work here.

However, there is sufficient Fortran programming out there to study how 
to compile complex number arithmetic ... LAPACK and its test programs.


I realize that they are not "benchmarks" in the sense that they do not 
give you a measure how to speed up the code the compiler generates; but 
they are real-life complex number algorithms coded in a programming 
language that had complex number support from the beginning.


Hope this helps,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

[Bug c++/111272] [13/14 Regression] Truncated error messages with -std=c++23 and -std=c++26

[pkeir at outlook dot com via Gcc-bugs]

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

--- Comment #4 from Paul Keir  ---
I believe P2448R2 would only allow the code, without the static_assert.
Explicitly calling `test()`, `Jam::Jam()` and then `Jam::ft()` here would mean
evaluating a non-constexpr function (i.e. `ft`). ft is *constexpr-suitable*,
but still needs the `constexpr` specifier when it is constant evaluated.

Re: [pushed] c++: __integer_pack with class argument [PR111357]

[Jakub Jelinek via Gcc-patches]

On Tue, Sep 12, 2023 at 01:34:43PM -0400, Marek Polacek via Gcc-patches wrote:
> On Tue, Sep 12, 2023 at 01:27:44PM -0400, Jason Merrill via Gcc-patches wrote:
> > Tested x86_64-pc-linux-gnu, applying to trunk.
> > 
> > -- 8< --
> > 
> > The argument might not already be an integer.
> > 
> > PR c++/111357
> > 
> > gcc/cp/ChangeLog:
> > 
> > * pt.cc (expand_integer_pack): Convert argument to int.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/ext/integer-pack7.C: New test.
> > ---
> >  gcc/cp/pt.cc |  2 ++
> >  gcc/testsuite/g++.dg/ext/integer-pack7.C | 38 
> >  2 files changed, 40 insertions(+)
> >  create mode 100644 gcc/testsuite/g++.dg/ext/integer-pack7.C
> > 
> > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> > index 838179d5fe3..b583c11eb99 100644
> > --- a/gcc/cp/pt.cc
> > +++ b/gcc/cp/pt.cc
> > @@ -3793,6 +3793,8 @@ expand_integer_pack (tree call, tree args, 
> > tsubst_flags_t complain,
> >  }
> >else
> >  {
> > +  hi = perform_implicit_conversion_flags (integer_type_node, hi, 
> > complain,
> > + LOOKUP_IMPLICIT);
> 
> FWIW, we have perform_implicit_conversion for this.

Is it correct to convert exactly to integer_type_node though?
Consider
#include 

using std::integer_sequence;
using std::make_integer_sequence;

template
void g(integer_sequence)
{}

template
struct c1
{
  static constexpr int value = 1;
  constexpr operator int() { return value; } 
  constexpr operator long() { return value + 1; }
};
template
struct R
{
using S = make_integer_sequence{}>;

R() noexcept(noexcept(g(S(
{}
};
int main()
{
R();
}
Shouldn't that invoke c1{}.operator long() rather than operator int()?
I thought the conversion was supposed to be done a few lines earlier,
instead of doing
  CALL_EXPR_ARG (call, 0) = hi;
do
  CALL_EXPR_ARG (call, 0)
= perform_implicit_conversion_flags (TREE_TYPE (ohi), hi,
 complain, LOOKUP_IMPLICIT);
or tsubst that TREE_TYPE (ohi) as well?  I.e. convert to type of the
template parameter.

Jakub

[Bug c++/107198] [13/14 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:752 since r13-3175-g6ffbf87ca66f4ed9

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Jason Merrill  ---
Fixed for 14, not backporting error-recovery fix.

Re: [PATCH] ggc, jit: forcibly clear GTY roots in jit

[Antoni Boucher via Gcc-patches]

In the mean time, here's a (Rust) reproducer for the issue:

fn main() {
for _ in 0..5 {
let context = Context::default();
context.add_command_line_option("-flto");
context.set_optimization_level(OptimizationLevel::Aggressive);
context.add_driver_option("-nostdlib");

let int_type = context.new_type::();

let function = context.new_function(None,
FunctionType::Exported, int_type, &[], "main", false);
let block = function.new_block("start");
let value = context.new_rvalue_from_int(int_type, 42);
block.end_with_return(None, value);

context.compile_to_file(OutputKind::Executable, "my_exe");
}
}

On Tue, 2023-09-12 at 12:00 -0400, Antoni Boucher via Jit wrote:
> It seems to not be enough to fix the issue.
> Let me find out what's missing from my patch.
> 
> On Tue, 2023-09-12 at 11:35 +0200, Richard Biener via Jit wrote:
> > On Wed, Sep 6, 2023 at 3:41 PM David Malcolm via Gcc-patches
> >  wrote:
> > > 
> > > As part of Antoyo's work on supporting LTO in rustc_codegen_gcc,
> > > he
> > > noticed an ICE inside libgccjit when compiling certain rust
> > > files.
> > > 
> > > Debugging libgccjit showed that outdated information from a
> > > previous
> > > in-memory compile was referring to ad-hoc locations in the
> > > previous
> > > compile's line_table.
> > > 
> > > The issue turned out to be the function decls in
> > > internal_fn_fnspec_array
> > > from the previous compile keeping alive the symtab nodes for
> > > these
> > > functions, and from this finding other functions in the previous
> > > compile, walking their CFGs, and finding ad-hoc data pointers in
> > > an
> > > edge
> > > with a location_t using ad-hoc data from the previous line_table
> > > instance, and thus a use-after-free ICE attempting to use this
> > > ad-
> > > hoc
> > > data.
> > > 
> > > Previously in toplev::finalize we've fixed global state
> > > "piecemeal"
> > > by
> > > calling out to individual source_name_cc_finalize functions. 
> > > However,
> > > it occurred to me that we have run-time information on where the
> > > GTY-marked pointers are.
> > > 
> > > Hence this patch takes something of a "big hammer" approach by
> > > adding a
> > > new ggc_common_finalize that walks the GC roots, zeroing all of
> > > the
> > > pointers.  I stepped through this in the debugger and observed
> > > that, in
> > > particular, this correctly zeroes the internal_fn_fnspec_array at
> > > the end
> > > of a libgccjit compile.  Antoyo reports that this fixes the ICE
> > > for
> > > him.
> > > Doing so uncovered an ICE with libgccjit in dwarf2cfi.cc due to
> > > reuse of
> > > global variables from the previous compile, which this patch also
> > > fixes.
> > > 
> > > I noticed that in ggc_mark_roots when clearing deletable roots we
> > > only
> > > clear the initial element in each gcc_root_tab_t.  This looks
> > > like
> > > a
> > > latent bug to me, which the patch fixes.  That said, there don't
> > > seem to
> > > be any deletable roots where the number of elements != 1.
> > > 
> > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> > > 
> > > OK for trunk?
> > 
> > OK.
> > 
> > Thanks,
> > Richard.
> > 
> > > Thanks
> > > Dave
> > > 
> > > gcc/ChangeLog:
> > >     * dwarf2cfi.cc (dwarf2cfi_cc_finalize): New.
> > >     * dwarf2out.h (dwarf2cfi_cc_finalize): New decl.
> > >     * ggc-common.cc (ggc_mark_roots): Multiply by rti->nelt
> > > when
> > >     clearing the deletable gcc_root_tab_t.
> > >     (ggc_common_finalize): New.
> > >     * ggc.h (ggc_common_finalize): New decl.
> > >     * toplev.cc (toplev::finalize): Call
> > > dwarf2cfi_cc_finalize
> > > and
> > >     ggc_common_finalize.
> > > ---
> > >  gcc/dwarf2cfi.cc  |  9 +
> > >  gcc/dwarf2out.h   |  1 +
> > >  gcc/ggc-common.cc | 23 ++-
> > >  gcc/ggc.h |  2 ++
> > >  gcc/toplev.cc |  3 +++
> > >  5 files changed, 37 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/gcc/dwarf2cfi.cc b/gcc/dwarf2cfi.cc
> > > index ddc728f4ad00..f1777c0a4cf1 100644
> > > --- a/gcc/dwarf2cfi.cc
> > > +++ b/gcc/dwarf2cfi.cc
> > > @@ -3822,4 +3822,13 @@ make_pass_dwarf2_frame (gcc::context
> > > *ctxt)
> > >    return new pass_dwarf2_frame (ctxt);
> > >  }
> > > 
> > > +void dwarf2cfi_cc_finalize ()
> > > +{
> > > +  add_cfi_insn = NULL;
> > > +  add_cfi_vec = NULL;
> > > +  cur_trace = NULL;
> > > +  cur_row = NULL;
> > > +  cur_cfa = NULL;
> > > +}
> > > +
> > >  #include "gt-dwarf2cfi.h"
> > > diff --git a/gcc/dwarf2out.h b/gcc/dwarf2out.h
> > > index 870b56a6a372..61a996050ff9 100644
> > > --- a/gcc/dwarf2out.h
> > > +++ b/gcc/dwarf2out.h
> > > @@ -419,6 +419,7 @@ struct fixed_point_type_info
> > >  } scale_factor;
> > >  };
> > > 
> > > +void dwarf2cfi_cc_finalize (void);
> > >  void dwarf2out_cc_finalize (void);
> > > 
> > >  /* Some DWARF internals are exposed for the needs of DWARF-based
> > > debug
> > > diff --git 

Re: [pushed] c++: __integer_pack with class argument [PR111357]

[Marek Polacek via Gcc-patches]

On Tue, Sep 12, 2023 at 01:27:44PM -0400, Jason Merrill via Gcc-patches wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
> 
> -- 8< --
> 
> The argument might not already be an integer.
> 
>   PR c++/111357
> 
> gcc/cp/ChangeLog:
> 
>   * pt.cc (expand_integer_pack): Convert argument to int.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/ext/integer-pack7.C: New test.
> ---
>  gcc/cp/pt.cc |  2 ++
>  gcc/testsuite/g++.dg/ext/integer-pack7.C | 38 
>  2 files changed, 40 insertions(+)
>  create mode 100644 gcc/testsuite/g++.dg/ext/integer-pack7.C
> 
> diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> index 838179d5fe3..b583c11eb99 100644
> --- a/gcc/cp/pt.cc
> +++ b/gcc/cp/pt.cc
> @@ -3793,6 +3793,8 @@ expand_integer_pack (tree call, tree args, 
> tsubst_flags_t complain,
>  }
>else
>  {
> +  hi = perform_implicit_conversion_flags (integer_type_node, hi, 
> complain,
> +   LOOKUP_IMPLICIT);

FWIW, we have perform_implicit_conversion for this.

Marek

[PATCH RFC] diagnostic: add permerror variants with opt

[Jason Merrill via Gcc-patches]

Tested x86_64-pc-linux-gnu.  Does this approach make sense to you?  Or do you
have another idea?

Perhaps the warn_system_headers adjustment should also be part of this?

-- 8< --

In the discussion of promoting some pedwarns to be errors by default, rather
than move them all into -fpermissive it seems to me to make sense to follow
the -Wnarrowing pattern of turning pedantic_errors on by default for them
like I've previously done for -Wnarrowing.  This way will also work with
-fpermissive, but users can still use -Wno-error=narrowing to downgrade that
specific diagnostic rather than everything affected by -fpermissive.

gcc/ChangeLog:

* diagnostic.cc (permerror): Add new overloads.
* diagnostic-core.h (permerror): Declare them.

gcc/cp/ChangeLog:

* typeck2.cc (check_narrowing): Use permerror.
---
 gcc/diagnostic-core.h |  3 +++
 gcc/cp/typeck2.cc |  9 +++--
 gcc/diagnostic.cc | 39 +++
 3 files changed, 45 insertions(+), 6 deletions(-)

diff --git a/gcc/diagnostic-core.h b/gcc/diagnostic-core.h
index c9e27fd2e6e..2d9909f18bd 100644
--- a/gcc/diagnostic-core.h
+++ b/gcc/diagnostic-core.h
@@ -105,6 +105,9 @@ extern bool pedwarn (rich_location *, int, const char *, 
...)
 extern bool permerror (location_t, const char *, ...) ATTRIBUTE_GCC_DIAG(2,3);
 extern bool permerror (rich_location *, const char *,
   ...) ATTRIBUTE_GCC_DIAG(2,3);
+extern bool permerror (location_t, int, const char *, ...) 
ATTRIBUTE_GCC_DIAG(3,4);
+extern bool permerror (rich_location *, int, const char *,
+  ...) ATTRIBUTE_GCC_DIAG(3,4);
 extern void sorry (const char *, ...) ATTRIBUTE_GCC_DIAG(1,2);
 extern void sorry_at (location_t, const char *, ...) ATTRIBUTE_GCC_DIAG(2,3);
 extern void inform (location_t, const char *, ...) ATTRIBUTE_GCC_DIAG(2,3);
diff --git a/gcc/cp/typeck2.cc b/gcc/cp/typeck2.cc
index cd1ea045720..1cbab70f513 100644
--- a/gcc/cp/typeck2.cc
+++ b/gcc/cp/typeck2.cc
@@ -1109,15 +1109,12 @@ check_narrowing (tree type, tree init, tsubst_flags_t 
complain,
   else if (complain & tf_error)
{
  int savederrorcount = errorcount;
- if (!flag_permissive)
-   global_dc->pedantic_errors = 1;
  auto s = make_temp_override (global_dc->dc_warn_system_headers, true);
- pedwarn (loc, OPT_Wnarrowing,
-  "narrowing conversion of %qE from %qH to %qI",
-  init, ftype, type);
+ permerror (loc, OPT_Wnarrowing,
+"narrowing conversion of %qE from %qH to %qI",
+init, ftype, type);
  if (errorcount == savederrorcount)
ok = true;
- global_dc->pedantic_errors = flag_pedantic_errors;
}
 }
 
diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
index 65c0cfbf11a..4195a01aa09 100644
--- a/gcc/diagnostic.cc
+++ b/gcc/diagnostic.cc
@@ -2054,6 +2054,45 @@ permerror (rich_location *richloc, const char *gmsgid, 
...)
   return ret;
 }
 
+/* Similar to the above, but controlled by a flag other than -fpermissive.
+   As above, an error by default or a warning with -fpermissive, but this
+   diagnostic can also be downgraded by -Wno-error=opt.  */
+
+bool
+permerror (location_t location, int opt, const char *gmsgid, ...)
+{
+  auto_diagnostic_group d;
+  va_list ap;
+  va_start (ap, gmsgid);
+  rich_location richloc (line_table, location);
+  bool pe = global_dc->pedantic_errors;
+  if (!global_dc->permissive)
+global_dc->pedantic_errors = true;
+  bool ret = diagnostic_impl (, NULL, opt, gmsgid, , DK_PEDWARN);
+  global_dc->pedantic_errors = pe;
+  va_end (ap);
+  return ret;
+}
+
+/* Same as "permerror" above, but at RICHLOC.  */
+
+bool
+permerror (rich_location *richloc, int opt, const char *gmsgid, ...)
+{
+  gcc_assert (richloc);
+
+  auto_diagnostic_group d;
+  va_list ap;
+  va_start (ap, gmsgid);
+  bool pe = global_dc->pedantic_errors;
+  if (!global_dc->permissive)
+global_dc->pedantic_errors = true;
+  bool ret = diagnostic_impl (richloc, NULL, opt, gmsgid, , DK_PEDWARN);
+  global_dc->pedantic_errors = pe;
+  va_end (ap);
+  return ret;
+}
+
 /* A hard error: the code is definitely ill-formed, and an object file
will not be produced.  */
 void

base-commit: f73d2d61a5926f42e9e5d771d23868787ef9d800
-- 
2.39.3

[Bug c++/111357] [11/12/13/14 Regression] __integer_pack fails to work with values of dependent type convertible to integers in noexcept context

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:f73d2d61a5926f42e9e5d771d23868787ef9d800

commit r14-3908-gf73d2d61a5926f42e9e5d771d23868787ef9d800
Author: Jason Merrill 
Date:   Mon Sep 11 09:40:32 2023 -0400

c++: __integer_pack with class argument [PR111357]

The argument might not already be an integer.

PR c++/111357

gcc/cp/ChangeLog:

* pt.cc (expand_integer_pack): Convert argument to int.

gcc/testsuite/ChangeLog:

* g++.dg/ext/integer-pack7.C: New test.

[pushed] c++: __integer_pack with class argument [PR111357]

[Jason Merrill via Gcc-patches]

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

-- 8< --

The argument might not already be an integer.

PR c++/111357

gcc/cp/ChangeLog:

* pt.cc (expand_integer_pack): Convert argument to int.

gcc/testsuite/ChangeLog:

* g++.dg/ext/integer-pack7.C: New test.
---
 gcc/cp/pt.cc |  2 ++
 gcc/testsuite/g++.dg/ext/integer-pack7.C | 38 
 2 files changed, 40 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/ext/integer-pack7.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 838179d5fe3..b583c11eb99 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -3793,6 +3793,8 @@ expand_integer_pack (tree call, tree args, tsubst_flags_t 
complain,
 }
   else
 {
+  hi = perform_implicit_conversion_flags (integer_type_node, hi, complain,
+ LOOKUP_IMPLICIT);
   hi = instantiate_non_dependent_expr (hi, complain);
   hi = cxx_constant_value (hi, complain);
   int len = valid_constant_size_p (hi) ? tree_to_shwi (hi) : -1;
diff --git a/gcc/testsuite/g++.dg/ext/integer-pack7.C 
b/gcc/testsuite/g++.dg/ext/integer-pack7.C
new file mode 100644
index 000..95b1195bef4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/integer-pack7.C
@@ -0,0 +1,38 @@
+// PR c++/111357
+// { dg-do compile { target c++11 } }
+
+namespace std {
+  template
+struct integer_sequence
+{ };
+
+  template
+using make_integer_sequence
+  = integer_sequence<_Tp, __integer_pack(_Num)...>;
+}
+
+using std::integer_sequence;
+using std::make_integer_sequence;
+
+template
+void g(integer_sequence)
+{}
+
+template
+struct c1
+{
+  static constexpr int value = 1;
+  constexpr operator int() { return value; }
+};
+template
+struct R
+{
+   using S = make_integer_sequence{}>;
+
+   R() noexcept(noexcept(g(S(
+   {}
+};
+int main()
+{
+R();
+}

base-commit: ea5abbb263315e558c876b50c9371b90ddd5e028
-- 
2.39.3

Re: [PATCH] small _BitInt tweaks

[Joseph Myers]

On Tue, 12 Sep 2023, Jakub Jelinek via Gcc-patches wrote:

> And by ensuring we never create 1-bit signed BITINT_TYPE e.g. the backends
> don't need to worry about them.
> 
> But I admit I don't feel strongly about that.
> 
> Joseph, what do you think about this?

I think it's appropriate to avoid 1-bit signed BITINT_TYPE consistently.

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

[Bug c++/107198] [13/14 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:752 since r13-3175-g6ffbf87ca66f4ed9

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:ea5abbb263315e558c876b50c9371b90ddd5e028

commit r14-3907-gea5abbb263315e558c876b50c9371b90ddd5e028
Author: Jason Merrill 
Date:   Thu Sep 7 05:15:01 2023 -0400

c++: ICE with -fno-exceptions and array init [PR107198]

The removed line no longer has an effect on anew5.C error recovery, and
removing it improves error recovery for this testcase.

PR c++/107198

gcc/cp/ChangeLog:

* typeck2.cc (process_init_constructor_array): Use VEC_INIT_EXPR
regardless of seen_error.

gcc/testsuite/ChangeLog:

* g++.dg/eh/no-exceptions1.C: New test.

[pushed] c++: ICE with -fno-exceptions and array init [PR107198]

[Jason Merrill via Gcc-patches]

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

-- 8< --

The removed line no longer has an effect on anew5.C error recovery, and
removing it improves error recovery for this testcase.

PR c++/107198

gcc/cp/ChangeLog:

* typeck2.cc (process_init_constructor_array): Use VEC_INIT_EXPR
regardless of seen_error.

gcc/testsuite/ChangeLog:

* g++.dg/eh/no-exceptions1.C: New test.
---
 gcc/cp/typeck2.cc|  1 -
 gcc/testsuite/g++.dg/eh/no-exceptions1.C | 19 +++
 2 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/eh/no-exceptions1.C

diff --git a/gcc/cp/typeck2.cc b/gcc/cp/typeck2.cc
index 582a73bb053..cd1ea045720 100644
--- a/gcc/cp/typeck2.cc
+++ b/gcc/cp/typeck2.cc
@@ -1683,7 +1683,6 @@ process_init_constructor_array (tree type, tree init, int 
nested, int flags,
if (next)
  {
if (next != error_mark_node
-   && ! seen_error () // Improves error-recovery on anew5.C.
&& (initializer_constant_valid_p (next, TREE_TYPE (next))
!= null_pointer_node))
  {
diff --git a/gcc/testsuite/g++.dg/eh/no-exceptions1.C 
b/gcc/testsuite/g++.dg/eh/no-exceptions1.C
new file mode 100644
index 000..4b77064c646
--- /dev/null
+++ b/gcc/testsuite/g++.dg/eh/no-exceptions1.C
@@ -0,0 +1,19 @@
+// PR c++/107198
+// { dg-additional-options -fno-exceptions }
+
+struct A {
+  A() { throw 0; } // { dg-error disabled }
+  A(int i) { throw i; }
+  A(const A&) { throw 10; }
+};
+
+void try_idx (int i)
+{
+  int t = 10;
+  try {
+struct X {
+  A e1[2], e2;
+}
+x2[3] = { { 1, 2, 3 }, { 4, 5, 6 } };
+  } catch (int x) { t = x; }   // { dg-prune-output "not declared" }
+}

base-commit: 27e2e7c93e48bcbb63877cc5964fae8dba47d706
-- 
2.39.3

Re: [PATCH v2 08/11] Native complex ops: Add explicit vector of complex

[Joseph Myers]

On Tue, 12 Sep 2023, Sylvain Noiry via Gcc-patches wrote:

> Summary:
> Allow the creation and usage of builtins vectors of complex
> in C, using __attribute__ ((vector_size ()))

If you're adding a new language feature like this, you need to update 
extend.texi to explain the valid uses of the attribute for complex types, 
and (under "Vector Extensions") the valid uses of the resulting vectors.  
You also need to add testcases to the testsuite for such vectors - both 
execution tests covering valid uses of the vectors, and tests that invalid 
declarations or uses of such vectors (uses with any operator, or other 
operand to such operator, that aren't valid) are properly rejected - go 
through all cases of operators, with one or two complex vector operands, 
of the same or different types, and with different choices for what type 
the other operand might be when one has complex vector type, and make sure 
they are all properly tested and do have the desired and documented 
semantics.

If the intended semantics are the same for C and C++, the tests should be 
c-c++-common tests.  Any cases where the intended semantics are different 
will need separate tests for each language or appropriately conditional 
test assertions in c-c++-common.

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

Re: RFC: RISC-V sign extension dead code elimination

[Vineet Gupta]

On 8/29/23 08:40, Joern Rennecke wrote:

In the patch call we talked about sign extsnsion elimination, so I dug
up this patch set that I did a while ago.  It is still lacking some
documentation and testing in a more recent base version;
I only adjusted the common.opt part context for the patch to apply.


Attached is the updated patch - prev one fails to apply cleanly on trunk 
and also needs some adj for inverted_post_order_compute API change.


Thx,
-VineetFrom 246ca9a572f49c3e2f2076d5a82dbaa5bb9def52 Mon Sep 17 00:00:00 2001
From: Joern Rennecke 
Date: Mon, 11 Sep 2023 14:13:58 -0700
Subject: [PATCH] DCE extraneous extension pass

---
 gcc/Makefile.in  |   1 +
 gcc/common.opt   |   8 +
 gcc/config/riscv/bitmanip.md |  14 +
 gcc/df-scan.cc   |   3 +-
 gcc/df.h |   1 +
 gcc/ext-dce.cc   | 546 +++
 gcc/passes.def   |   1 +
 gcc/tree-pass.h  |   1 +
 8 files changed, 573 insertions(+), 2 deletions(-)
 create mode 100644 gcc/ext-dce.cc

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 6d608db4dd24..cc13d1904ed7 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1429,6 +1429,7 @@ OBJS = \
 	explow.o \
 	expmed.o \
 	expr.o \
+	ext-dce.o \
 	fibonacci_heap.o \
 	file-prefix-map.o \
 	final.o \
diff --git a/gcc/common.opt b/gcc/common.opt
index f137a1f81ac8..8a5d3fece581 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -3716,4 +3716,12 @@ fipa-ra
 Common Var(flag_ipa_ra) Optimization
 Use caller save register across calls if possible.
 
+fext-dce
+Common Var(flag_ext_dce, 1) Optimization Init(0)
+Perform dead code elimination on zero and sign extensions with special dataflow analysis.
+
+fext-dce-pre
+Common Var(flag_ext_dce, 2)
+Perform dead code elimination on zero and sign extensions with special dataflow analysis.  Insert extensions on edges for partial redundancy elimination.
+
 ; This comment is to ensure we retain the blank line above.
diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index 431b32922135..c03f20f59546 100644
--- a/gcc/config/riscv/bitmanip.md
+++ b/gcc/config/riscv/bitmanip.md
@@ -273,6 +273,20 @@
   [(set_attr "type" "")
(set_attr "mode" "DI")])
 
+;; Combine has a different idea about canonical rtl.
+;; Example: int f (int i) { return (short)i; }
+(define_insn_and_split "*extendhidi_combine"
+  [(set (match_operand:DI 0 "register_operand")
+	(sign_extend:DI
+	  (ashiftrt:SI
+	(subreg:SI (ashift:DI (match_operand:DI 1 "register_operand")
+  (const_int 16)) 0)
+	(const_int 16]
+  "TARGET_ZBB"
+  "#"
+  "&& 1"
+  [(set (match_dup 0) (sign_extend:DI (subreg:HI (match_dup 1) 0)))])
+
 (define_insn "*zero_extendhi2_bitmanip"
   [(set (match_operand:GPR 0 "register_operand" "=r,r")
 (zero_extend:GPR (match_operand:HI 1 "nonimmediate_operand" "r,m")))]
diff --git a/gcc/df-scan.cc b/gcc/df-scan.cc
index 9515740728c3..87729ab0f44d 100644
--- a/gcc/df-scan.cc
+++ b/gcc/df-scan.cc
@@ -78,7 +78,6 @@ static void df_get_eh_block_artificial_uses (bitmap);
 
 static void df_record_entry_block_defs (bitmap);
 static void df_record_exit_block_uses (bitmap);
-static void df_get_exit_block_use_set (bitmap);
 static void df_get_entry_block_def_set (bitmap);
 static void df_grow_ref_info (struct df_ref_info *, unsigned int);
 static void df_ref_chain_delete_du_chain (df_ref);
@@ -3642,7 +3641,7 @@ df_epilogue_uses_p (unsigned int regno)
 
 /* Set the bit for regs that are considered being used at the exit. */
 
-static void
+void
 df_get_exit_block_use_set (bitmap exit_block_uses)
 {
   unsigned int i;
diff --git a/gcc/df.h b/gcc/df.h
index 402657a7076f..abcbb0977349 100644
--- a/gcc/df.h
+++ b/gcc/df.h
@@ -1091,6 +1091,7 @@ extern bool df_epilogue_uses_p (unsigned int);
 extern void df_set_regs_ever_live (unsigned int, bool);
 extern void df_compute_regs_ever_live (bool);
 extern void df_scan_verify (void);
+extern void df_get_exit_block_use_set (bitmap);
 
 
 /*
diff --git a/gcc/ext-dce.cc b/gcc/ext-dce.cc
new file mode 100644
index ..c285e67c509d
--- /dev/null
+++ b/gcc/ext-dce.cc
@@ -0,0 +1,546 @@
+/* RTL dead zero/sign extension (code) elimination.
+   Copyright (C) 2000-2022 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
+.  

[Bug c++/59256] qualified name in friend function declaration doesn't match previous declaration in inline namespace

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from Jonathan Wakely  ---
The std::format case looks like this:

namespace x
{
  inline namespace v {

namespace detail {
  template struct bar;
}

template
  auto make(Arg);

template
class detail::bar {
  bar() { }

  template
friend auto x::make(Arg);
};

template
  auto make(Arg)
  {
detail::bar b;
return 1;
  }
  }
}
int main()
{
  return x::make(1);
}

Re: [PATCH][_GLIBCXX_INLINE_VERSION] Fix friend declarations

[Jonathan Wakely via Gcc-patches]

On Tue, 12 Sept 2023 at 17:47, Jonathan Wakely  wrote:
>
> On Wed, 23 Aug 2023 at 18:35, François Dumont via Libstdc++
>  wrote:
> >
> > Hi
> >
> > The few tests that are failing in versioned namespace mode are due to
> > those friend declarations.
> >
> > This is a fix proposal even if I considered 2 other options:
> >
> > 1. Make __format::_Arg_store a struct and so do not bother with friend
> > declarations.
> >
> > 2. Consider it as a compiler bug and do nothing. In this case I think we
> > might still need this patch to avoid a non-working format library in
> > versioned namespace mode in gcc 14 if compiler bug is not fixed.
>
> It definitely is a compiler bug, this is PR c++/59256.
>
> Please add a comment to the new macro definition, so we remember to
> remove it when it's not needed:
>
>
> #if _GLIBCXX_INLINE_VERSION
> // Needed because of PR c++/59526
> # define _GLIBCXX_STD_V std::__8
> #else
> # define _GLIBCXX_STD_V std
> #endif
>
>
> OK with that change, thanks.

Actually, are you sure the friend std::basic_format_args declaration
needs to change?

I only see errors for the friend function, not the friend class. So
this seems to fix it:

--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -3437,7 +3437,13 @@ namespace __format

  template
   friend auto
-   std::make_format_args(_Argz&&...) noexcept;
+#if _GLIBCXX_INLINE_VERSION
+   // Needed for PR c++/59526
+   std::__8::
+#else
+   std::
+#endif
+   make_format_args(_Argz&&...) noexcept;

  // For a sufficiently small number of arguments we only store values.
  // basic_format_args can get the types from the _Args pack.




>
>
> >
> > I can also define _GLIBCXX_STD_V at  level to limit impact.
> >
> >  libstdc++: [_GLIBCXX_INLINE_VERSION] Fix  friend declarations
> >
> >  GCC do not consider the inline namespace in friend declarations. We
> > need
> >  to explicit this namespace.
> >
> >  libstdc++-v3/ChangeLog:
> >
> >  * include/bits/c++config (_GLIBCXX_STD_V): New macro giving
> > current
> >  std namespace with optionally the version namespace.
> >  * include/std/format (std::__format::_Arg_store): Use
> > latter on friend
> >  declarations.
> >
> > Tested under versioned mode.
> >
> > Ok to commit ?
> >
> > François

[Bug fortran/111271] gcc/fortran/trans-expr.cc:1134:8: warning: duplicated ‘if’ condition [-Wduplicated-cond]

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

   Last reconfirmed||2023-09-12
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #2 from Paul Thomas  ---
(In reply to David Binderman from comment #1)
> git blame says
> 
> 6c95fe9bc0 (Paul Thomas  2023-05-16 06:35:40 +0100  1087)   if
> (unlimited_poly)
> 
> ...
> 
> 6c95fe9bc0 (Paul Thomas  2023-05-16 06:35:40 +0100  1134)   else
> if (unlimited_poly)
> 
> Adding Paul for their best advice.

Hah! You got me.

r14-870-g6c95fe9bc0553743098eeaa739f14b885050fa42

Thanks for pointing it out. The fix is easy enough.

Paul

[Bug c++/59256] qualified name in friend function declaration doesn't match previous declaration in inline namespace

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2021-12-13 00:00:00 |2023-9-12

--- Comment #15 from Jonathan Wakely  ---
This affects std::format now too.

Re: [PATCH][_GLIBCXX_INLINE_VERSION] Fix friend declarations

[Jonathan Wakely via Gcc-patches]

On Wed, 23 Aug 2023 at 18:35, François Dumont via Libstdc++
 wrote:
>
> Hi
>
> The few tests that are failing in versioned namespace mode are due to
> those friend declarations.
>
> This is a fix proposal even if I considered 2 other options:
>
> 1. Make __format::_Arg_store a struct and so do not bother with friend
> declarations.
>
> 2. Consider it as a compiler bug and do nothing. In this case I think we
> might still need this patch to avoid a non-working format library in
> versioned namespace mode in gcc 14 if compiler bug is not fixed.

It definitely is a compiler bug, this is PR c++/59256.

Please add a comment to the new macro definition, so we remember to
remove it when it's not needed:


#if _GLIBCXX_INLINE_VERSION
// Needed because of PR c++/59526
# define _GLIBCXX_STD_V std::__8
#else
# define _GLIBCXX_STD_V std
#endif


OK with that change, thanks.




>
> I can also define _GLIBCXX_STD_V at  level to limit impact.
>
>  libstdc++: [_GLIBCXX_INLINE_VERSION] Fix  friend declarations
>
>  GCC do not consider the inline namespace in friend declarations. We
> need
>  to explicit this namespace.
>
>  libstdc++-v3/ChangeLog:
>
>  * include/bits/c++config (_GLIBCXX_STD_V): New macro giving
> current
>  std namespace with optionally the version namespace.
>  * include/std/format (std::__format::_Arg_store): Use
> latter on friend
>  declarations.
>
> Tested under versioned mode.
>
> Ok to commit ?
>
> François

[Bug tree-optimization/111383] [12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu since r12-5138-ge82c382971

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
I think iv-opts is changing:
(d - 1625015511) + (d - 1625015341)

into (2*d - N) which introduces an overflow ...