[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

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

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

--- Comment #32 from Eric Gallager  ---
(In reply to matoro from comment #31)
> (In reply to Eric Gallager from comment #30)
> > (In reply to matoro from comment #26)
> > > We also had somebody report on IRC that they observed this on powerpc (not
> > > sure what tuple), again with -j1.  It does not seem to show up with -j2, 
> > > so
> > > likely -j1 is necessary to trigger.
> > 
> > I can also confirm that switching to -j2 makes this particular error go away
> 
> It may make it "go away", but how can it be worked around on real
> single-core systems?  All that does is get lucky by throwing more
> parallelism at it.  I've been completely unable to even try out gccgo
> because of this bug.

Right, yes, this is still definitely a bug, I was just confirming that I was
able to get the workaround to work for me personally

Re: [PATCH v3 4/9] LoongArch:Added support for SX vector floating-point instructions.

[Xi Ruoyao via Gcc-patches]

The subject should be "Add tests for SX vector floating-point
instructions".  The "support" has already been added.

Likewise for patches 5-9.


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

[Bug driver/86030] specs file processing does not create response files for input directories

[john.soo+gcc-bugzilla at arista dot com via Gcc-bugs]

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

--- Comment #10 from John Soo  ---
I'm also not sure
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=180ebb8a24d24fc5b105f2257d6216f6dfde62df
fixes the collect bug because collect uses collect_execute instead of the pex_*
exec functions.

[PATCH v3 7/9] LoongArch:Add vector arithmetic addition vsadd instruction.

[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 v3 3/9] 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| 5038 +
 1 file changed, 5038 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..dcc8f9211bd
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-builtin.c
@@ -0,0 +1,5038 @@
+/* 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
+ * 

[PATCH v3 1/9] 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

[PATCH v3 2/9] 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..f33bad82cb2
--- /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 " -mlasx"
+}
+
+#Initialize `dg'.
+dg-init
+
+#Main loop.
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/lsx/*.\[cS\]]] \
+   "" $DEFAULT_CFLAGS
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/lasx/*.\[cS\]]] \
+   "" $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 v3 0/9] Added support for SX/LSX vector instructions.

[Xiaolong Chen]

v2 -> v3:
  Standardize the code using the GNU format.

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

Xiaolong Chen (9):
  LoongArch: Add tests of -mstrict-align option.
  LoongArch: Add testsuite framework for Loongson SX/ASX.
  LoongArch: Add tests for Loongson SX builtin functions.
  LoongArch:Added support for SX vector floating-point instructions.
  LoongArch:Add SX instructions for vector arithmetic addition
operations.
  LoongArch:Add vector subtraction arithmetic operation SX instruction.
  LoongArch:Add vector arithmetic addition vsadd instruction.
  LoongArch:Added SX vector arithmetic multiplication instruction.
  LoongArch:Add SX instructions for vector arithmetic operations other
than multiplication, addition, and subtraction.

 .../gcc.target/loongarch/strict-align.c   |   12 +
 .../loongarch/vector/loongarch-vector.exp |   42 +
 .../loongarch/vector/lsx/lsx-builtin.c| 5038 +
 .../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-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-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-vfcvt-1.c|  398 ++
 .../loongarch/vector/lsx/lsx-vfcvt-2.c|  278 +
 .../loongarch/vector/lsx/lsx-vffint-1.c   |  161 +
 .../loongarch/vector/lsx/lsx-vffint-2.c   |  264 +
 .../loongarch/vector/lsx/lsx-vffint-3.c   |  102 +
 .../loongarch/vector/lsx/lsx-vfrint_d.c   |  230 +
 .../loongarch/vector/lsx/lsx-vfrint_s.c   |  350 ++
 .../loongarch/vector/lsx/lsx-vftint-1.c   |  349 ++
 .../loongarch/vector/lsx/lsx-vftint-2.c   |  695 +++
 .../loongarch/vector/lsx/lsx-vftint-3.c   | 1028 
 .../loongarch/vector/lsx/lsx-vftint-4.c   |  345 ++
 .../loongarch/vector/lsx/lsx-vhaddw-1.c   |  488 ++
 .../loongarch/vector/lsx/lsx-vhaddw-2.c   |  452 ++
 .../loongarch/vector/lsx/lsx-vhsubw-1.c   |  327 ++
 .../loongarch/vector/lsx/lsx-vhsubw-2.c   |  353 ++
 .../loongarch/vector/lsx/lsx-vldi.c   |   61 +
 .../loongarch/vector/lsx/lsx-vmadd.c  |  450 ++
 .../loongarch/vector/lsx/lsx-vmaddwev-1.c |  472 ++
 .../loongarch/vector/lsx/lsx-vmaddwev-2.c |  383 ++
 .../loongarch/vector/lsx/lsx-vmaddwev-3.c |  383 ++
 .../loongarch/vector/lsx/lsx-vmaddwod-1.c |  372 ++
 .../loongarch/vector/lsx/lsx-vmaddwod-2.c |  438 ++
 .../loongarch/vector/lsx/lsx-vmaddwod-3.c |  460 ++
 .../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 +
 .../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-vmsub.c  |  461 ++
 .../loongarch/vector/lsx/lsx-vmuh-1.c |  353 ++
 .../loongarch/vector/lsx/lsx-vmuh-2.c |  372 ++
 .../loongarch/vector/lsx/lsx-vmul.c   |  282 +
 .../loongarch/vector/lsx/lsx-vmulwev-1.c  |  434 ++
 .../loongarch/vector/lsx/lsx-vmulwev-2.c  |  344 ++
 .../loongarch/vector/lsx/lsx-vmulwev-3.c  |  245 +
 .../loongarch/vector/lsx/lsx-vmulwod-1.c  |  272 +
 .../loongarch/vector/lsx/lsx-vmulwod-2.c  |  282 +
 .../loongarch/vector/lsx/lsx-vmulwod-3.c  |  308 +
 .../loongarch/vector/lsx/lsx-vneg.c   |  321 ++
 .../loongarch/vector/lsx/lsx-vsadd-1.c|  335 ++
 .../loongarch/vector/lsx/lsx-vsadd-2.c|  345 ++
 .../loongarch/vector/lsx/lsx-vsat-1.c |  231 +
 .../loongarch/vector/lsx/lsx-vsat-2.c |  272 +
 .../loongarch/vector/lsx/lsx-vsigncov.c   |  425 ++
 .../loongarch/vector/lsx/lsx-vssub-1.c|  398 ++
 .../loongarch/vector/lsx/lsx-vssub-2.c|  408 ++
 

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

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

Ping this patch.

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

Update current FAILs status:

Real FAILS (ICE and execution FAIL):

FAIL: gcc.dg/pr70252.c (internal compiler error: in 
gimple_expand_vec_cond_expr, at gimple-isel.cc:284)
FAIL: gcc.dg/pr70252.c (test for excess errors)
FAIL: gcc.dg/pr92301.c execution test

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

FAIL: g++.dg/torture/vshuf-v4df.C   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (internal compiler error: in as_a, at machmode.h:381)
FAIL: g++.dg/torture/vshuf-v4df.C   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (test for excess errors)
FAIL: g++.dg/torture/vshuf-v4df.C   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  (internal compiler error: in as_a, at machmode.h:381)
FAIL: g++.dg/torture/vshuf-v4df.C   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  (test for excess errors)
This is a long time known issue I have mentioned many times, we need help for 
LTO since it's caused by mode bits extension.

The rest bogus FAILs:
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "Not unrolling loop, doesn't 
roll"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "likely upper bound: 6"
FAIL: gcc.dg/unroll-8.c scan-rtl-dump loop2_unroll "realistic bound: -1"
FAIL: gcc.dg/var-expand1.c scan-rtl-dump loop2_unroll "Expanding Accumulator"
FAIL: gcc.dg/tree-ssa/cunroll-16.c scan-tree-dump cunroll "optimized: loop with 
[0-9]+ iterations completely unrolled"
FAIL: gcc.dg/tree-ssa/cunroll-16.c scan-tree-dump-not optimized "foo"
FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized 
"BIT_FIELD_REF" 0
FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized 
"BIT_INSERT_EXPR" 0
FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized 
"BIT_FIELD_REF" 0
FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized 
"BIT_INSERT_EXPR" 1
FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vect "vectorized 0 
loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vect "vectorized 0 
loops" 1
FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect "Alignment of 
access forced using peeling" 1
FAIL: gcc.dg/tree-ssa/gen-vect-28.c scan-tree-dump-times vect "Alignment of 
access forced using peeling" 1
FAIL: gcc.dg/tree-ssa/loop-bound-1.c scan-tree-dump ivopts "bounded by 254"
FAIL: gcc.dg/tree-ssa/loop-bound-2.c scan-tree-dump ivopts "bounded by 254"
FAIL: gcc.dg/tree-ssa/predcom-2.c scan-tree-dump-times pcom "Unrolling 2 
times." 2
FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom "Combination" 1
FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom "Unrolling 3 
times." 1
FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom "Combination" 2
FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom "Unrolling 3 
times." 1
FAIL: gcc.dg/tree-ssa/predcom-9.c scan-tree-dump pcom "Executing predictive 
commoning without unrolling"
FAIL: gcc.dg/tree-ssa/reassoc-46.c scan-tree-dump-times optimized 
"(?:vect_)?sum_[\\d._]+ = (?:(?:vect_)?_[\\d._]+ \\+ 
(?:vect_)?sum_[\\d._]+|(?:v   ect_)?sum_[\\d._]+ \\+ (?:vect_)?_[\\d._]+)" 1
FAIL: gcc.dg/tree-ssa/scev-10.c scan-tree-dump-times ivopts "  
Type:\\tREFERENCE ADDRESS\n" 1
FAIL: gcc.dg/tree-ssa/scev-11.c scan-tree-dump-times ivopts "  
Type:\\tREFERENCE ADDRESS\n" 2
FAIL: gcc.dg/tree-ssa/scev-14.c scan-tree-dump ivopts "Overflowness wrto loop 
niter:\tNo-overflow"
FAIL: gcc.dg/tree-ssa/scev-9.c scan-tree-dump-times ivopts "  Type:\\tREFERENCE 
ADDRESS\n" 1
FAIL: gcc.dg/tree-ssa/split-path-11.c scan-tree-dump-times split-paths "join 
point for if-convertable half-diamond" 1

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

So is this patch ok for trunk ?



juzhe.zh...@rivai.ai
 
From: Juzhe-Zhong
Date: 2023-09-07 15:28
To: gcc-patches
CC: kito.cheng; kito.cheng; jeffreyalaw; rdapp.gcc; Juzhe-Zhong
Subject: [PATCH] RISC-V: Enable RVV scalable vectorization by default[PR111311]
This patch is not ready but they all will be fixed very soon.
 
gcc/ChangeLog:
 
* config/riscv/riscv.opt: Set default as scalable vectorization.
 
---
gcc/config/riscv/riscv.opt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
 
diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
index 98f342348b7..bf2eca08221 100644
--- a/gcc/config/riscv/riscv.opt
+++ b/gcc/config/riscv/riscv.opt
@@ -292,7 +292,7 @@ EnumValue
Enum(riscv_autovec_preference) String(fixed-vlmax) Value(RVV_FIXED_VLMAX)
-param=riscv-autovec-preference=
-Target RejectNegative Joined Enum(riscv_autovec_preference) 
Var(riscv_autovec_preference) Init(NO_AUTOVEC)
+Target RejectNegative Joined Enum(riscv_autovec_preference) 
Var(riscv_autovec_preference) Init(RVV_SCALABLE)
-param=riscv-autovec-preference= Set the preference of 
auto-vectorization in the RISC-V port.
Enum
-- 
2.36.3
 

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

[Juzhe-Zhong]

I found that it's more reasonable to use existing dominance analysis.

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc 
(pass_vsetvl::global_eliminate_vsetvl_insn): Use dominance analysis.
(pass_vsetvl::init): Ditto.
(pass_vsetvl::done): Ditto.

---
 gcc/config/riscv/riscv-vsetvl.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc
index 134b97737ae..f81361c4ccd 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -4054,7 +4054,7 @@ pass_vsetvl::global_eliminate_vsetvl_insn (const bb_info 
*bb) const
 }
 
   /* Step1: Reshape the VL/VTYPE status to make sure everything compatible.  */
-  hash_set pred_cfg_bbs = get_all_predecessors (cfg_bb);
+  auto_vec pred_cfg_bbs = get_dominated_by (CDI_POST_DOMINATORS, 
cfg_bb);
   FOR_EACH_EDGE (e, ei, cfg_bb->preds)
 {
   sbitmap avout = m_vector_manager->vector_avout[e->src->index];
@@ -4243,6 +4243,7 @@ pass_vsetvl::init (void)
 {
   /* Initialization of RTL_SSA.  */
   calculate_dominance_info (CDI_DOMINATORS);
+  calculate_dominance_info (CDI_POST_DOMINATORS);
   df_analyze ();
   crtl->ssa = new function_info (cfun);
 }
@@ -4264,6 +4265,7 @@ pass_vsetvl::done (void)
 {
   /* Finalization of RTL_SSA.  */
   free_dominance_info (CDI_DOMINATORS);
+  free_dominance_info (CDI_POST_DOMINATORS);
   if (crtl->ssa->perform_pending_updates ())
cleanup_cfg (0);
   delete crtl->ssa;
-- 
2.36.3

[Bug target/111311] RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable

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

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

--- Comment #6 from CVS Commits  ---
The trunk branch has been updated by Lehua Ding :

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

commit r14-3834-gd05aac047e0643d5c32b706c4c3b12e13f35e19a
Author: Juzhe-Zhong 
Date:   Mon Sep 11 11:25:02 2023 +0800

RISC-V: Add VLS modes VEC_PERM support[PR111311]

This patch add VLS modes VEC_PERM support which fix these following
FAILs in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311:

FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized
"BIT_FIELD_REF" 0
FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized
"BIT_INSERT_EXPR" 0
FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized
"BIT_FIELD_REF" 0
FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized
"BIT_INSERT_EXPR" 1

These FAILs are fixed after this patch.

PR target/111311

gcc/ChangeLog:

* config/riscv/autovec.md: Add VLS modes.
* config/riscv/riscv-protos.h (cmp_lmul_le_one): New function.
(cmp_lmul_gt_one): Ditto.
* config/riscv/riscv-v.cc (cmp_lmul_le_one): Ditto.
(cmp_lmul_gt_one): Ditto.
* config/riscv/riscv.cc (riscv_print_operand): Add VLS modes.
(riscv_vectorize_vec_perm_const): Ditto.
* config/riscv/vector-iterators.md: Ditto.
* config/riscv/vector.md: Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/partial/slp-1.c: Adapt test.
* gcc.target/riscv/rvv/autovec/partial/slp-16.c: Ditto.
* gcc.target/riscv/rvv/autovec/partial/slp-17.c: Ditto.
* gcc.target/riscv/rvv/autovec/partial/slp-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/partial/slp-5.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/compress-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/compress-2.c: New test.
* gcc.target/riscv/rvv/autovec/vls/compress-3.c: New test.
* gcc.target/riscv/rvv/autovec/vls/compress-4.c: New test.
* gcc.target/riscv/rvv/autovec/vls/compress-5.c: New test.
* gcc.target/riscv/rvv/autovec/vls/compress-6.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-2.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-3.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-4.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-5.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-6.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-7.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-2.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-3.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-4.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-5.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-6.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-7.c: New test.

[Committed V2] RISC-V: Add VLS modes VEC_PERM support[PR111311]

[Juzhe-Zhong]

This patch add VLS modes VEC_PERM support which fix these following
FAILs in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311:

FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized 
"BIT_FIELD_REF" 0
FAIL: gcc.dg/tree-ssa/forwprop-40.c scan-tree-dump-times optimized 
"BIT_INSERT_EXPR" 0
FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized 
"BIT_FIELD_REF" 0
FAIL: gcc.dg/tree-ssa/forwprop-41.c scan-tree-dump-times optimized 
"BIT_INSERT_EXPR" 1

These FAILs are fixed after this patch.

gcc/ChangeLog:

* config/riscv/autovec.md: Add VLS modes.
* config/riscv/riscv-protos.h (cmp_lmul_le_one): New function.
(cmp_lmul_gt_one): Ditto.
* config/riscv/riscv-v.cc (cmp_lmul_le_one): Ditto.
(cmp_lmul_gt_one): Ditto.
* config/riscv/riscv.cc (riscv_print_operand): Add VLS modes.
(riscv_vectorize_vec_perm_const): Ditto.
* config/riscv/vector-iterators.md: Ditto.
* config/riscv/vector.md: Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/partial/slp-1.c: Adapt test.
* gcc.target/riscv/rvv/autovec/partial/slp-16.c: Ditto.
* gcc.target/riscv/rvv/autovec/partial/slp-17.c: Ditto.
* gcc.target/riscv/rvv/autovec/partial/slp-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/partial/slp-5.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/compress-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/compress-2.c: New test.
* gcc.target/riscv/rvv/autovec/vls/compress-3.c: New test.
* gcc.target/riscv/rvv/autovec/vls/compress-4.c: New test.
* gcc.target/riscv/rvv/autovec/vls/compress-5.c: New test.
* gcc.target/riscv/rvv/autovec/vls/compress-6.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-2.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-3.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-4.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-5.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-6.c: New test.
* gcc.target/riscv/rvv/autovec/vls/merge-7.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-2.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-3.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-4.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-5.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-6.c: New test.
* gcc.target/riscv/rvv/autovec/vls/perm-7.c: New test.

---
 gcc/config/riscv/autovec.md   |   6 +-
 gcc/config/riscv/riscv-protos.h   |   2 +
 gcc/config/riscv/riscv-v.cc   |  22 ++
 gcc/config/riscv/riscv.cc |   4 +-
 gcc/config/riscv/vector-iterators.md  | 289 -
 gcc/config/riscv/vector.md| 302 +-
 .../riscv/rvv/autovec/partial/slp-1.c |   2 +-
 .../riscv/rvv/autovec/partial/slp-16.c|   2 +-
 .../riscv/rvv/autovec/partial/slp-17.c|   2 +-
 .../riscv/rvv/autovec/partial/slp-3.c |   2 +-
 .../riscv/rvv/autovec/partial/slp-5.c |   2 +-
 .../riscv/rvv/autovec/vls/compress-1.c|   6 +
 .../riscv/rvv/autovec/vls/compress-2.c|   7 +
 .../riscv/rvv/autovec/vls/compress-3.c|   7 +
 .../riscv/rvv/autovec/vls/compress-4.c|   7 +
 .../riscv/rvv/autovec/vls/compress-5.c|   6 +
 .../riscv/rvv/autovec/vls/compress-6.c|   6 +
 .../riscv/rvv/autovec/vls/merge-1.c   |   6 +
 .../riscv/rvv/autovec/vls/merge-2.c   |   6 +
 .../riscv/rvv/autovec/vls/merge-3.c   |   6 +
 .../riscv/rvv/autovec/vls/merge-4.c   |   6 +
 .../riscv/rvv/autovec/vls/merge-5.c   |   6 +
 .../riscv/rvv/autovec/vls/merge-6.c   |   6 +
 .../riscv/rvv/autovec/vls/merge-7.c   |   6 +
 .../gcc.target/riscv/rvv/autovec/vls/perm-1.c |   6 +
 .../gcc.target/riscv/rvv/autovec/vls/perm-2.c |   6 +
 .../gcc.target/riscv/rvv/autovec/vls/perm-3.c |   6 +
 .../gcc.target/riscv/rvv/autovec/vls/perm-4.c |   8 +
 .../gcc.target/riscv/rvv/autovec/vls/perm-5.c |   6 +
 .../gcc.target/riscv/rvv/autovec/vls/perm-6.c |   6 +
 .../gcc.target/riscv/rvv/autovec/vls/perm-7.c |   6 +
 31 files changed, 584 insertions(+), 176 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/compress-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/compress-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/compress-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/compress-4.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/compress-5.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vls/compress-6.c
 create mode 100644 

[Bug middle-end/111324] More optimization about "(X * Y) / Y"

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

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

--- Comment #3 from Jiu Fu Guo  ---
A patch is posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629534.html

Re: Re: [PATCH] RISC-V: Add VLS modes VEC_PERM support[PR111311]

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

Sure. Thanks kito.



juzhe.zh...@rivai.ai
 
From: Kito Cheng
Date: 2023-09-11 10:57
To: juzhe.zh...@rivai.ai
CC: gcc-patches; Kito.cheng
Subject: Re: Re: [PATCH] RISC-V: Add VLS modes VEC_PERM support[PR111311]
OK, but could you split this patch into two patches? pre-approved for both.
 
On Mon, Sep 11, 2023 at 10:36 AM juzhe.zh...@rivai.ai
 wrote:
>
> >> Should we also add loads and stores as well?
> >> and just make sure this is also necessary for the fix and not sneaky, 
> >> right?
>
> No, we don't need loads/stores. Since this following handling codes:
> (define_insn_and_split "*mov_lra"
>   [(set (match_operand:VLS_AVL_REG 0 "reg_or_mem_operand" "=vr, m,vr")
>   (match_operand:VLS_AVL_REG 1 "reg_or_mem_operand" "  m,vr,vr"))
>(clobber (match_scratch:P 2 "=,,X"))]
>   "TARGET_VECTOR && (lra_in_progress || reload_completed)
>&& (register_operand (operands[0], mode)
>|| register_operand (operands[1], mode))"
>   "#"
>   "&& reload_completed"
>   [(const_int 0)]
> {
>   if (REG_P (operands[0]) && REG_P (operands[1]))
>   emit_insn (gen_rtx_SET (operands[0], operands[1]));
>   else
> {
>   emit_move_insn (operands[2], gen_int_mode (GET_MODE_NUNITS 
> (mode),
>  Pmode));
>   unsigned insn_flags
> = GET_MODE_CLASS (mode) == MODE_VECTOR_BOOL
>  ? riscv_vector::UNARY_MASK_OP
>  : riscv_vector::UNARY_OP;
>   riscv_vector::emit_nonvlmax_insn (code_for_pred_mov 
> (mode),
>   insn_flags, operands, operands[2]);
> }
>   DONE;
> }
>   [(set_attr "type" "vmov")]
> )
>
> We split special case use emit_insn (gen_rtx_SET (operands[0], operands[1]));
>
> Missing this pattern will cause ICE but current testcases didn't produce such 
> issues.
> This issue is recognized after I support this pattern.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: Kito Cheng
> Date: 2023-09-11 10:18
> To: Juzhe-Zhong
> CC: gcc-patches; kito.cheng
> Subject: Re: [PATCH] RISC-V: Add VLS modes VEC_PERM support[PR111311]
> > diff --git a/gcc/config/riscv/autovec-vls.md 
> > b/gcc/config/riscv/autovec-vls.md
> > index d208b418e5f..6f48f7d6232 100644
> > --- a/gcc/config/riscv/autovec-vls.md
> > +++ b/gcc/config/riscv/autovec-vls.md
> > @@ -148,6 +148,14 @@
> >[(set_attr "type" "vmov")
> > (set_attr "mode" "")])
> >
> > +(define_insn "*mov_vls"
> > +  [(set (match_operand:VLSB 0 "register_operand" "=vr")
> > +   (match_operand:VLSB 1 "register_operand" " vr"))]
> > +  "TARGET_VECTOR"
> > +  "vmv1r.v\t%0,%1"
> > +  [(set_attr "type" "vmov")
> > +   (set_attr "mode" "")])
>
> Should we also add loads and stores as well?
> and just make sure this is also necessary for the fix and not sneaky, right?
>
> > +
> >  (define_expand "movmisalign"
> >[(set (match_operand:VLS 0 "nonimmediate_operand")
> > (match_operand:VLS 1 "general_operand"))]
>
 

[Committed] RISC-V: Add missing VLS mask bool mode reg -> reg patterns

[Juzhe-Zhong]

Committed.

gcc/ChangeLog:

* config/riscv/autovec-vls.md (*mov_vls): New pattern.
* config/riscv/vector-iterators.md: New iterator

---
 gcc/config/riscv/autovec-vls.md  |  8 
 gcc/config/riscv/vector-iterators.md | 15 +++
 2 files changed, 23 insertions(+)

diff --git a/gcc/config/riscv/autovec-vls.md b/gcc/config/riscv/autovec-vls.md
index d208b418e5f..6f48f7d6232 100644
--- a/gcc/config/riscv/autovec-vls.md
+++ b/gcc/config/riscv/autovec-vls.md
@@ -148,6 +148,14 @@
   [(set_attr "type" "vmov")
(set_attr "mode" "")])
 
+(define_insn "*mov_vls"
+  [(set (match_operand:VLSB 0 "register_operand" "=vr")
+   (match_operand:VLSB 1 "register_operand" " vr"))]
+  "TARGET_VECTOR"
+  "vmv1r.v\t%0,%1"
+  [(set_attr "type" "vmov")
+   (set_attr "mode" "")])
+
 (define_expand "movmisalign"
   [(set (match_operand:VLS 0 "nonimmediate_operand")
(match_operand:VLS 1 "general_operand"))]
diff --git a/gcc/config/riscv/vector-iterators.md 
b/gcc/config/riscv/vector-iterators.md
index a98ed9fcbb6..5694c0c8f37 100644
--- a/gcc/config/riscv/vector-iterators.md
+++ b/gcc/config/riscv/vector-iterators.md
@@ -2425,6 +2425,21 @@
   (V256DF "TARGET_VECTOR_VLS && TARGET_VECTOR_ELEN_FP_64 && TARGET_MIN_VLEN >= 
2048")
   (V512DF "TARGET_VECTOR_VLS && TARGET_VECTOR_ELEN_FP_64 && TARGET_MIN_VLEN >= 
4096")])
 
+(define_mode_iterator VLSB [
+  (V1BI "TARGET_VECTOR_VLS")
+  (V2BI "TARGET_VECTOR_VLS")
+  (V4BI "TARGET_VECTOR_VLS")
+  (V8BI "TARGET_VECTOR_VLS")
+  (V16BI "TARGET_VECTOR_VLS")
+  (V32BI "TARGET_VECTOR_VLS")
+  (V64BI "TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 64")
+  (V128BI "TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 128")
+  (V256BI "TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 256")
+  (V512BI "TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 512")
+  (V1024BI "TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 1024")
+  (V2048BI "TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 2048")
+  (V4096BI "TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 4096")])
+
 ;; VLS modes that has NUNITS < 32.
 (define_mode_iterator VLS_AVL_IMM [
   (V1QI "TARGET_VECTOR_VLS")
-- 
2.36.3

Re: Re: [PATCH] RISC-V: Add VLS modes VEC_PERM support[PR111311]

[Kito Cheng via Gcc-patches]

OK, but could you split this patch into two patches? pre-approved for both.

On Mon, Sep 11, 2023 at 10:36 AM juzhe.zh...@rivai.ai
 wrote:
>
> >> Should we also add loads and stores as well?
> >> and just make sure this is also necessary for the fix and not sneaky, 
> >> right?
>
> No, we don't need loads/stores. Since this following handling codes:
> (define_insn_and_split "*mov_lra"
>   [(set (match_operand:VLS_AVL_REG 0 "reg_or_mem_operand" "=vr, m,vr")
>   (match_operand:VLS_AVL_REG 1 "reg_or_mem_operand" "  m,vr,vr"))
>(clobber (match_scratch:P 2 "=,,X"))]
>   "TARGET_VECTOR && (lra_in_progress || reload_completed)
>&& (register_operand (operands[0], mode)
>|| register_operand (operands[1], mode))"
>   "#"
>   "&& reload_completed"
>   [(const_int 0)]
> {
>   if (REG_P (operands[0]) && REG_P (operands[1]))
>   emit_insn (gen_rtx_SET (operands[0], operands[1]));
>   else
> {
>   emit_move_insn (operands[2], gen_int_mode (GET_MODE_NUNITS 
> (mode),
>  Pmode));
>   unsigned insn_flags
> = GET_MODE_CLASS (mode) == MODE_VECTOR_BOOL
>  ? riscv_vector::UNARY_MASK_OP
>  : riscv_vector::UNARY_OP;
>   riscv_vector::emit_nonvlmax_insn (code_for_pred_mov 
> (mode),
>   insn_flags, operands, operands[2]);
> }
>   DONE;
> }
>   [(set_attr "type" "vmov")]
> )
>
> We split special case use emit_insn (gen_rtx_SET (operands[0], operands[1]));
>
> Missing this pattern will cause ICE but current testcases didn't produce such 
> issues.
> This issue is recognized after I support this pattern.
>
>
>
> juzhe.zh...@rivai.ai
>
> From: Kito Cheng
> Date: 2023-09-11 10:18
> To: Juzhe-Zhong
> CC: gcc-patches; kito.cheng
> Subject: Re: [PATCH] RISC-V: Add VLS modes VEC_PERM support[PR111311]
> > diff --git a/gcc/config/riscv/autovec-vls.md 
> > b/gcc/config/riscv/autovec-vls.md
> > index d208b418e5f..6f48f7d6232 100644
> > --- a/gcc/config/riscv/autovec-vls.md
> > +++ b/gcc/config/riscv/autovec-vls.md
> > @@ -148,6 +148,14 @@
> >[(set_attr "type" "vmov")
> > (set_attr "mode" "")])
> >
> > +(define_insn "*mov_vls"
> > +  [(set (match_operand:VLSB 0 "register_operand" "=vr")
> > +   (match_operand:VLSB 1 "register_operand" " vr"))]
> > +  "TARGET_VECTOR"
> > +  "vmv1r.v\t%0,%1"
> > +  [(set_attr "type" "vmov")
> > +   (set_attr "mode" "")])
>
> Should we also add loads and stores as well?
> and just make sure this is also necessary for the fix and not sneaky, right?
>
> > +
> >  (define_expand "movmisalign"
> >[(set (match_operand:VLS 0 "nonimmediate_operand")
> > (match_operand:VLS 1 "general_operand"))]
>

Re: Re: [PATCH] RISC-V: Add VLS modes VEC_PERM support[PR111311]

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

>> Should we also add loads and stores as well?
>> and just make sure this is also necessary for the fix and not sneaky, right?

No, we don't need loads/stores. Since this following handling codes:
(define_insn_and_split "*mov_lra"
  [(set (match_operand:VLS_AVL_REG 0 "reg_or_mem_operand" "=vr, m,vr")
  (match_operand:VLS_AVL_REG 1 "reg_or_mem_operand" "  m,vr,vr"))
   (clobber (match_scratch:P 2 "=,,X"))]
  "TARGET_VECTOR && (lra_in_progress || reload_completed)
   && (register_operand (operands[0], mode)
   || register_operand (operands[1], mode))"
  "#"
  "&& reload_completed"
  [(const_int 0)]
{
  if (REG_P (operands[0]) && REG_P (operands[1]))
  emit_insn (gen_rtx_SET (operands[0], operands[1]));
  else
{
  emit_move_insn (operands[2], gen_int_mode (GET_MODE_NUNITS 
(mode),
 Pmode));
  unsigned insn_flags
= GET_MODE_CLASS (mode) == MODE_VECTOR_BOOL
 ? riscv_vector::UNARY_MASK_OP
 : riscv_vector::UNARY_OP;
  riscv_vector::emit_nonvlmax_insn (code_for_pred_mov 
(mode),
  insn_flags, operands, operands[2]);
}
  DONE;
}
  [(set_attr "type" "vmov")]
)

We split special case use emit_insn (gen_rtx_SET (operands[0], operands[1]));

Missing this pattern will cause ICE but current testcases didn't produce such 
issues.
This issue is recognized after I support this pattern.



juzhe.zh...@rivai.ai
 
From: Kito Cheng
Date: 2023-09-11 10:18
To: Juzhe-Zhong
CC: gcc-patches; kito.cheng
Subject: Re: [PATCH] RISC-V: Add VLS modes VEC_PERM support[PR111311]
> diff --git a/gcc/config/riscv/autovec-vls.md b/gcc/config/riscv/autovec-vls.md
> index d208b418e5f..6f48f7d6232 100644
> --- a/gcc/config/riscv/autovec-vls.md
> +++ b/gcc/config/riscv/autovec-vls.md
> @@ -148,6 +148,14 @@
>[(set_attr "type" "vmov")
> (set_attr "mode" "")])
>
> +(define_insn "*mov_vls"
> +  [(set (match_operand:VLSB 0 "register_operand" "=vr")
> +   (match_operand:VLSB 1 "register_operand" " vr"))]
> +  "TARGET_VECTOR"
> +  "vmv1r.v\t%0,%1"
> +  [(set_attr "type" "vmov")
> +   (set_attr "mode" "")])
 
Should we also add loads and stores as well?
and just make sure this is also necessary for the fix and not sneaky, right?
 
> +
>  (define_expand "movmisalign"
>[(set (match_operand:VLS 0 "nonimmediate_operand")
> (match_operand:VLS 1 "general_operand"))]
 

Re: [PATCH] MATCH: [PR111346] `X CMP MINMAX` pattern missing :c on CMP

[Jeff Law via Gcc-patches]

On 9/10/23 20:18, Andrew Pinski via Gcc-patches wrote:

I noticed this while working on other MINMAX optimizations. It was
hard to find a simplified testcase though because it was dependent on
the ssa name versions. Adding the `:c` to cmp allows the pattern to
be match for the case where minmax as the first operand of the comparison
rather than the second.

Committed as obvious after a bootstrap/test on x86_64-linux-gnu.

PR tree-optimization/111346

gcc/ChangeLog:

* match.pd (`X CMP MINMAX`): Add `:c` on the cmp part
of the pattern

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/minmaxcmp-1.c: New test.

OK
jeff

[Bug tree-optimization/96708] Failure to optimize max pattern with comparison when using a temporary variable

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

--- Comment #5 from Andrew Pinski  ---
Note this was mostly fixed for GCC 11 but had missed the :c on the cmp and that
was fully fixed in GCC 14, see PR 111346 for that. What that means is sometimes
we would not optimize always to 0/1 and keep around the comparison.

[Bug tree-optimization/111346] `X <= MINMAX` pattern is missing :c on the cmp

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Fixed.

[Bug tree-optimization/111346] `X <= MINMAX` pattern is missing :c on the cmp

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

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

--- Comment #5 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:190cf0ce8f4c141ac5b42d53b9ddeba367495333

commit r14-3832-g190cf0ce8f4c141ac5b42d53b9ddeba367495333
Author: Andrew Pinski 
Date:   Sun Sep 10 15:59:41 2023 -0700

MATCH: [PR111346] `X CMP MINMAX` pattern missing :c on CMP

I noticed this while working on other MINMAX optimizations. It was
hard to find a simplified testcase though because it was dependent on
the ssa name versions. Adding the `:c` to cmp allows the pattern to
be match for the case where minmax as the first operand of the comparison
rather than the second.

Committed as obvious after a bootstrap/test on x86_64-linux-gnu.

PR tree-optimization/111346

gcc/ChangeLog:

* match.pd (`X CMP MINMAX`): Add `:c` on the cmp part
of the pattern

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/minmaxcmp-1.c: New test.

Re: [PATCH] RISC-V: Add VLS modes VEC_PERM support[PR111311]

[Kito Cheng via Gcc-patches]

> diff --git a/gcc/config/riscv/autovec-vls.md b/gcc/config/riscv/autovec-vls.md
> index d208b418e5f..6f48f7d6232 100644
> --- a/gcc/config/riscv/autovec-vls.md
> +++ b/gcc/config/riscv/autovec-vls.md
> @@ -148,6 +148,14 @@
>[(set_attr "type" "vmov")
> (set_attr "mode" "")])
>
> +(define_insn "*mov_vls"
> +  [(set (match_operand:VLSB 0 "register_operand" "=vr")
> +   (match_operand:VLSB 1 "register_operand" " vr"))]
> +  "TARGET_VECTOR"
> +  "vmv1r.v\t%0,%1"
> +  [(set_attr "type" "vmov")
> +   (set_attr "mode" "")])

Should we also add loads and stores as well?
and just make sure this is also necessary for the fix and not sneaky, right?

> +
>  (define_expand "movmisalign"
>[(set (match_operand:VLS 0 "nonimmediate_operand")
> (match_operand:VLS 1 "general_operand"))]

[PATCH] MATCH: [PR111346] `X CMP MINMAX` pattern missing :c on CMP

[Andrew Pinski via Gcc-patches]

I noticed this while working on other MINMAX optimizations. It was
hard to find a simplified testcase though because it was dependent on
the ssa name versions. Adding the `:c` to cmp allows the pattern to
be match for the case where minmax as the first operand of the comparison
rather than the second.

Committed as obvious after a bootstrap/test on x86_64-linux-gnu.

PR tree-optimization/111346

gcc/ChangeLog:

* match.pd (`X CMP MINMAX`): Add `:c` on the cmp part
of the pattern

gcc/testsuite/ChangeLog:

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

diff --git a/gcc/match.pd b/gcc/match.pd
index c7b6db4b543..a60fe04885e 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -3942,7 +3942,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (for minmax (min min max max )
  cmp(ge  lt  le  gt  )
  (simplify
-  (cmp @0 (minmax:c @0 @1))
+  (cmp:c @0 (minmax:c @0 @1))
   { constant_boolean_node (cmp == GE_EXPR || cmp == LE_EXPR, type); } ))
 
 /* Undo fancy ways of writing max/min or other ?: expressions, like
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/minmaxcmp-1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/minmaxcmp-1.c
new file mode 100644
index 000..0706c026076
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/minmaxcmp-1.c
@@ -0,0 +1,39 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized -fdump-tree-original" } */
+/* PR tree-optimization/111346 */
+
+int f();
+int g();
+
+_Bool test1(int a, int b)
+{
+return ((a > b) ? a : b) >= a; // return 1;
+}
+_Bool test1_(int a, int b)
+{
+return a <= ((a > b) ? a : b); // return 1;
+}
+/* test1 and test1_ should be able to optimize to `return 1;` during fold.  */
+/* { dg-final { scan-tree-dump-times "return 1;" 2 "original" } } */
+/* { dg-final { scan-tree-dump-not " MAX_EXPR " "original" } } */
+
+_Bool test2(int a, int b)
+{
+a = f();
+a = g();
+int t = a;
+if (t < b) t = b;
+return t >= a; // return 1;
+}
+
+_Bool test2_(int a, int b)
+{
+a = g();
+int t = a;
+if (t < b) t = b;
+return t >= a; // return 1;
+}
+
+/* All of these should be optimized to just be the function calls and `return 
1;` */
+/* { dg-final { scan-tree-dump-times "return 1;" 4 "optimized" } } */
+/* { dg-final { scan-tree-dump-not " MAX_EXPR " "optimized" } } */
-- 
2.31.1

Re: [PATCH] analyzer: implement symbolic value support for CPython plugin's refcnt checker [PR107646]

[Eric Feng via Gcc]

On Thu, Sep 7, 2023 at 1:28 PM David Malcolm  wrote:

> On Mon, 2023-09-04 at 22:13 -0400, Eric Feng wrote:
>
> > Hi Dave,
>
> Hi Eric, thanks for the patch.
>
> >
> > Recently I've been working on symbolic value support for the reference
> > count checker. I've attached a patch for it below; let me know it looks
> > OK for trunk. Thanks!
> >
> > Best,
> > Eric
> >
> > ---
> >
> > This patch enhances the reference count checker in the CPython plugin by
> > adding support for symbolic values. Whereas previously we were only able
> > to check the reference count of PyObject* objects created in the scope
> > of the function; we are now able to emit diagnostics on reference count
> > mismatch of objects that were, for example, passed in as a function
> > parameter.
> >
> > rc6.c:6:10: warning: expected ‘obj’ to have reference count: N + ‘1’ but
> ob_refcnt field is N + ‘2’
> > 6 |   return obj;
> >   |  ^~~
>
> [...snip...]
>
> >  create mode 100644
> gcc/testsuite/gcc.dg/plugin/cpython-plugin-test-refcnt.c
> >
> > diff --git a/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.c
> b/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.c
> > index bf1982e79c3..d7ecd7fce09 100644
> > --- a/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.c
> > +++ b/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.c
> > @@ -314,17 +314,20 @@ public:
> >{
> >  diagnostic_metadata m;
> >  bool warned;
> > -// just assuming constants for now
> > -auto actual_refcnt
> > - = m_actual_refcnt->dyn_cast_constant_svalue ()->get_constant ();
> > -auto ob_refcnt = m_ob_refcnt->dyn_cast_constant_svalue
> ()->get_constant ();
> > -warned = warning_meta (rich_loc, m, get_controlling_option (),
> > -"expected %qE to have "
> > -"reference count: %qE but ob_refcnt field is:
> %qE",
> > -m_reg_tree, actual_refcnt, ob_refcnt);
> > -
> > -// location_t loc = rich_loc->get_loc ();
> > -// foo (loc);
> > +
> > +const auto *actual_refcnt_constant
> > + = m_actual_refcnt->dyn_cast_constant_svalue ();
> > +const auto *ob_refcnt_constant =
> m_ob_refcnt->dyn_cast_constant_svalue ();
> > +if (!actual_refcnt_constant || !ob_refcnt_constant)
> > +  return false;
> > +
> > +auto actual_refcnt = actual_refcnt_constant->get_constant ();
> > +auto ob_refcnt = ob_refcnt_constant->get_constant ();
> > +warned = warning_meta (
> > + rich_loc, m, get_controlling_option (),
> > + "expected %qE to have "
> > + "reference count: N + %qE but ob_refcnt field is N + %qE",
> > + m_reg_tree, actual_refcnt, ob_refcnt);
> >  return warned;
>
> I know you're emulating the old behavior I implemented way back in
> cpychecker, but I don't like that behavior :(
>
> Specifically, although the patch improves the behavior for symbolic
> values, it regresses the precision of wording for the concrete values
> case.  If we have e.g. a concrete ob_refcnt of 2, whereas we only have
> 1 pointer, then it's more readable to say:
>
>   warning: expected ‘obj’ to have reference count: ‘1’ but ob_refcnt
> field is ‘2’
>
> than:
>
>   warning: expected ‘obj’ to have reference count: N + ‘1’ but ob_refcnt
> field is N + ‘2’
>
> ...and we shouldn't quote concrete numbers, the message should be:
>
>   warning: expected ‘obj’ to have reference count of 1 but ob_refcnt field
> is 2


> or better:
>
>   warning: ‘*obj’ is pointed to by 1 pointer but 'ob_refcnt' field is 2
>
>
> Can you move the unwrapping of the svalue from the tests below into the
> emit vfunc?  That way the m_actual_refcnt doesn't have to be a
> constant_svalue; you could have logic in the emit vfunc to print
> readable messages based on what kind of svalue it is.
>
> Rather than 'N', it might be better to say 'initial'; how about:
>
>   warning: ‘*obj’ is pointed to by 0 additional pointers but 'ob_refcnt'
> field has increased by 1
>   warning: ‘*obj’ is pointed to by 1 additional pointer but 'ob_refcnt'
> field has increased by 2
>   warning: ‘*obj’ is pointed to by 1 additional pointer but 'ob_refcnt'
> field is unchanged
>   warning: ‘*obj’ is pointed to by 2 additional pointers but 'ob_refcnt'
> field has decreased by 1
>   warning: ‘*obj’ is pointed to by 1 fewer pointers but 'ob_refcnt' field
> is unchanged
>
> and similar?
>

That makes sense to me as well (indeed I was just emulating the old
behavior)! Will experiment and keep you posted on a revised patch with this
in mind.  This is somewhat of a minor detail but can we emit ‘*obj’ as
bolded text in the diagnostic message? Currently, I can emit this
(including the asterisk) like so: '*%E'. But unlike using %qE, it doesn't
bold the body of the single quotations. Is this possible?

>
> Maybe have a flag that tracks whether we're talking about a concrete
> value that's absolute versus a concrete value that's relative to the
> initial value?
>
>
> [...snip...]
>
>
> > @@ -369,6 +368,19 @@ 

Re: [PATCH] analyzer: implement symbolic value support for CPython plugin's refcnt checker [PR107646]

[Eric Feng via Gcc-patches]

On Thu, Sep 7, 2023 at 1:28 PM David Malcolm  wrote:

> On Mon, 2023-09-04 at 22:13 -0400, Eric Feng wrote:
>
> > Hi Dave,
>
> Hi Eric, thanks for the patch.
>
> >
> > Recently I've been working on symbolic value support for the reference
> > count checker. I've attached a patch for it below; let me know it looks
> > OK for trunk. Thanks!
> >
> > Best,
> > Eric
> >
> > ---
> >
> > This patch enhances the reference count checker in the CPython plugin by
> > adding support for symbolic values. Whereas previously we were only able
> > to check the reference count of PyObject* objects created in the scope
> > of the function; we are now able to emit diagnostics on reference count
> > mismatch of objects that were, for example, passed in as a function
> > parameter.
> >
> > rc6.c:6:10: warning: expected ‘obj’ to have reference count: N + ‘1’ but
> ob_refcnt field is N + ‘2’
> > 6 |   return obj;
> >   |  ^~~
>
> [...snip...]
>
> >  create mode 100644
> gcc/testsuite/gcc.dg/plugin/cpython-plugin-test-refcnt.c
> >
> > diff --git a/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.c
> b/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.c
> > index bf1982e79c3..d7ecd7fce09 100644
> > --- a/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.c
> > +++ b/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.c
> > @@ -314,17 +314,20 @@ public:
> >{
> >  diagnostic_metadata m;
> >  bool warned;
> > -// just assuming constants for now
> > -auto actual_refcnt
> > - = m_actual_refcnt->dyn_cast_constant_svalue ()->get_constant ();
> > -auto ob_refcnt = m_ob_refcnt->dyn_cast_constant_svalue
> ()->get_constant ();
> > -warned = warning_meta (rich_loc, m, get_controlling_option (),
> > -"expected %qE to have "
> > -"reference count: %qE but ob_refcnt field is:
> %qE",
> > -m_reg_tree, actual_refcnt, ob_refcnt);
> > -
> > -// location_t loc = rich_loc->get_loc ();
> > -// foo (loc);
> > +
> > +const auto *actual_refcnt_constant
> > + = m_actual_refcnt->dyn_cast_constant_svalue ();
> > +const auto *ob_refcnt_constant =
> m_ob_refcnt->dyn_cast_constant_svalue ();
> > +if (!actual_refcnt_constant || !ob_refcnt_constant)
> > +  return false;
> > +
> > +auto actual_refcnt = actual_refcnt_constant->get_constant ();
> > +auto ob_refcnt = ob_refcnt_constant->get_constant ();
> > +warned = warning_meta (
> > + rich_loc, m, get_controlling_option (),
> > + "expected %qE to have "
> > + "reference count: N + %qE but ob_refcnt field is N + %qE",
> > + m_reg_tree, actual_refcnt, ob_refcnt);
> >  return warned;
>
> I know you're emulating the old behavior I implemented way back in
> cpychecker, but I don't like that behavior :(
>
> Specifically, although the patch improves the behavior for symbolic
> values, it regresses the precision of wording for the concrete values
> case.  If we have e.g. a concrete ob_refcnt of 2, whereas we only have
> 1 pointer, then it's more readable to say:
>
>   warning: expected ‘obj’ to have reference count: ‘1’ but ob_refcnt
> field is ‘2’
>
> than:
>
>   warning: expected ‘obj’ to have reference count: N + ‘1’ but ob_refcnt
> field is N + ‘2’
>
> ...and we shouldn't quote concrete numbers, the message should be:
>
>   warning: expected ‘obj’ to have reference count of 1 but ob_refcnt field
> is 2


> or better:
>
>   warning: ‘*obj’ is pointed to by 1 pointer but 'ob_refcnt' field is 2
>
>
> Can you move the unwrapping of the svalue from the tests below into the
> emit vfunc?  That way the m_actual_refcnt doesn't have to be a
> constant_svalue; you could have logic in the emit vfunc to print
> readable messages based on what kind of svalue it is.
>
> Rather than 'N', it might be better to say 'initial'; how about:
>
>   warning: ‘*obj’ is pointed to by 0 additional pointers but 'ob_refcnt'
> field has increased by 1
>   warning: ‘*obj’ is pointed to by 1 additional pointer but 'ob_refcnt'
> field has increased by 2
>   warning: ‘*obj’ is pointed to by 1 additional pointer but 'ob_refcnt'
> field is unchanged
>   warning: ‘*obj’ is pointed to by 2 additional pointers but 'ob_refcnt'
> field has decreased by 1
>   warning: ‘*obj’ is pointed to by 1 fewer pointers but 'ob_refcnt' field
> is unchanged
>
> and similar?
>

That makes sense to me as well (indeed I was just emulating the old
behavior)! Will experiment and keep you posted on a revised patch with this
in mind.  This is somewhat of a minor detail but can we emit ‘*obj’ as
bolded text in the diagnostic message? Currently, I can emit this
(including the asterisk) like so: '*%E'. But unlike using %qE, it doesn't
bold the body of the single quotations. Is this possible?

>
> Maybe have a flag that tracks whether we're talking about a concrete
> value that's absolute versus a concrete value that's relative to the
> initial value?
>
>
> [...snip...]
>
>
> > @@ -369,6 +368,19 @@ 

[Bug target/111306] [12,13] macro-fusion makes error on conjugate complex multiplication fp16

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Hongtao.liu  ---
Fixed in GCC14.1 GCC13.3 GCC12.4

[Bug target/111335] fmaddpch seems not commutative for operands[1] and operands[2] due to precision loss

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

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

--- Comment #4 from Hongtao.liu  ---
Fixed in GCC14.1 GCC13.3 GCC12.4

[Bug target/111306] [12,13] macro-fusion makes error on conjugate complex multiplication fp16

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-12 branch has been updated by hongtao Liu
:

https://gcc.gnu.org/g:82c1ff396e49b706d5baa11f4c884810f6350e95

commit r12-9852-g82c1ff396e49b706d5baa11f4c884810f6350e95
Author: liuhongt 
Date:   Fri Sep 8 09:22:43 2023 +0800

Remove constraint modifier % for fcmaddcph/fmaddcph/fcmulcph since there're
not commutative.

gcc/ChangeLog:

PR target/111306
PR target/111335
* config/i386/sse.md (int_comm): New int_attr.
(fma__):
Remove % for Complex conjugate operations since they're not
commutative.
(fma___pair): Ditto.
(___mask): Ditto.
(cmul3): Ditto.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit f197392a16ffb1327f1d12ff8ff05f9295e015cb)

[Bug target/111335] fmaddpch seems not commutative for operands[1] and operands[2] due to precision loss

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-12 branch has been updated by hongtao Liu
:

https://gcc.gnu.org/g:82c1ff396e49b706d5baa11f4c884810f6350e95

commit r12-9852-g82c1ff396e49b706d5baa11f4c884810f6350e95
Author: liuhongt 
Date:   Fri Sep 8 09:22:43 2023 +0800

Remove constraint modifier % for fcmaddcph/fmaddcph/fcmulcph since there're
not commutative.

gcc/ChangeLog:

PR target/111306
PR target/111335
* config/i386/sse.md (int_comm): New int_attr.
(fma__):
Remove % for Complex conjugate operations since they're not
commutative.
(fma___pair): Ditto.
(___mask): Ditto.
(cmul3): Ditto.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit f197392a16ffb1327f1d12ff8ff05f9295e015cb)

[Bug target/111306] [12,13] macro-fusion makes error on conjugate complex multiplication fp16

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-13 branch has been updated by hongtao Liu
:

https://gcc.gnu.org/g:162731529e4dd10970880c369471229735dc3e9b

commit r13-7789-g162731529e4dd10970880c369471229735dc3e9b
Author: liuhongt 
Date:   Fri Sep 8 09:22:43 2023 +0800

Remove constraint modifier % for fcmaddcph/fmaddcph/fcmulcph since there're
not commutative.

gcc/ChangeLog:

PR target/111306
PR target/111335
* config/i386/sse.md (int_comm): New int_attr.
(fma__):
Remove % for Complex conjugate operations since they're not
commutative.
(fma___pair): Ditto.
(___mask): Ditto.
(cmul3): Ditto.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit f197392a16ffb1327f1d12ff8ff05f9295e015cb)

[Bug target/111335] fmaddpch seems not commutative for operands[1] and operands[2] due to precision loss

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

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-13 branch has been updated by hongtao Liu
:

https://gcc.gnu.org/g:162731529e4dd10970880c369471229735dc3e9b

commit r13-7789-g162731529e4dd10970880c369471229735dc3e9b
Author: liuhongt 
Date:   Fri Sep 8 09:22:43 2023 +0800

Remove constraint modifier % for fcmaddcph/fmaddcph/fcmulcph since there're
not commutative.

gcc/ChangeLog:

PR target/111306
PR target/111335
* config/i386/sse.md (int_comm): New int_attr.
(fma__):
Remove % for Complex conjugate operations since they're not
commutative.
(fma___pair): Ditto.
(___mask): Ditto.
(cmul3): Ditto.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit f197392a16ffb1327f1d12ff8ff05f9295e015cb)

[Bug target/111335] fmaddpch seems not commutative for operands[1] and operands[2] due to precision loss

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r14-3831-gf197392a16ffb1327f1d12ff8ff05f9295e015cb
Author: liuhongt 
Date:   Fri Sep 8 09:22:43 2023 +0800

Remove constraint modifier % for fcmaddcph/fmaddcph/fcmulcph since there're
not commutative.

gcc/ChangeLog:

PR target/111306
PR target/111335
* config/i386/sse.md (int_comm): New int_attr.
(fma__):
Remove % for Complex conjugate operations since they're not
commutative.
(fma___pair): Ditto.
(___mask): Ditto.
(cmul3): Ditto.

gcc/testsuite/ChangeLog:

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

[Bug target/111306] [12,13] macro-fusion makes error on conjugate complex multiplication fp16

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r14-3831-gf197392a16ffb1327f1d12ff8ff05f9295e015cb
Author: liuhongt 
Date:   Fri Sep 8 09:22:43 2023 +0800

Remove constraint modifier % for fcmaddcph/fmaddcph/fcmulcph since there're
not commutative.

gcc/ChangeLog:

PR target/111306
PR target/111335
* config/i386/sse.md (int_comm): New int_attr.
(fma__):
Remove % for Complex conjugate operations since they're not
commutative.
(fma___pair): Ditto.
(___mask): Ditto.
(cmul3): Ditto.

gcc/testsuite/ChangeLog:

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

[PATCH] Remove constraint modifier % for fcmaddcph/fmaddcph/fcmulcph since there're not commutative.

[liuhongt via Gcc-patches]

Here's the patch I've commited.
The patch also remove % for vfmaddcph.

gcc/ChangeLog:

PR target/111306
PR target/111335
* config/i386/sse.md (int_comm): New int_attr.
(fma__):
Remove % for Complex conjugate operations since they're not
commutative.
(fma___pair): Ditto.
(___mask): Ditto.
(cmul3): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr111306.c: New test.
---
 gcc/config/i386/sse.md   | 16 ---
 gcc/testsuite/gcc.target/i386/pr111306.c | 36 
 2 files changed, 48 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr111306.c

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 6d3ae8dea0c..14615999394 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -6480,6 +6480,14 @@ (define_int_attr complexpairopname
[(UNSPEC_COMPLEX_FMA_PAIR "fmaddc")
 (UNSPEC_COMPLEX_FCMA_PAIR "fcmaddc")])
 
+(define_int_attr int_comm
+   [(UNSPEC_COMPLEX_FMA "")
+(UNSPEC_COMPLEX_FMA_PAIR "")
+(UNSPEC_COMPLEX_FCMA "")
+(UNSPEC_COMPLEX_FCMA_PAIR "")
+(UNSPEC_COMPLEX_FMUL "%")
+(UNSPEC_COMPLEX_FCMUL "")])
+
 (define_int_attr conj_op
[(UNSPEC_COMPLEX_FMA "")
 (UNSPEC_COMPLEX_FCMA "_conj")
@@ -6593,7 +6601,7 @@ (define_expand "cmla4"
 (define_insn "fma__"
   [(set (match_operand:VHF_AVX512VL 0 "register_operand" "=")
(unspec:VHF_AVX512VL
- [(match_operand:VHF_AVX512VL 1 "" "%v")
+ [(match_operand:VHF_AVX512VL 1 "" "v")
   (match_operand:VHF_AVX512VL 2 "" 
"")
   (match_operand:VHF_AVX512VL 3 "" "0")]
   UNSPEC_COMPLEX_F_C_MA))]
@@ -6658,7 +,7 @@ (define_insn_and_split 
"fma___fma_zero"
 (define_insn "fma___pair"
  [(set (match_operand:VF1_AVX512VL 0 "register_operand" "=")
(unspec:VF1_AVX512VL
-[(match_operand:VF1_AVX512VL 1 "vector_operand" "%v")
+[(match_operand:VF1_AVX512VL 1 "vector_operand" "v")
  (match_operand:VF1_AVX512VL 2 "bcst_vector_operand" "vmBr")
  (match_operand:VF1_AVX512VL 3 "vector_operand" "0")]
  UNSPEC_COMPLEX_F_C_MA_PAIR))]
@@ -6727,7 +6735,7 @@ (define_insn 
"___mask"
   [(set (match_operand:VHF_AVX512VL 0 "register_operand" "=")
(vec_merge:VHF_AVX512VL
  (unspec:VHF_AVX512VL
-   [(match_operand:VHF_AVX512VL 1 "nonimmediate_operand" "%v")
+   [(match_operand:VHF_AVX512VL 1 "nonimmediate_operand" "v")
 (match_operand:VHF_AVX512VL 2 "nonimmediate_operand" 
"")
 (match_operand:VHF_AVX512VL 3 "register_operand" "0")]
 UNSPEC_COMPLEX_F_C_MA)
@@ -6752,7 +6760,7 @@ (define_expand "cmul3"
 (define_insn "__"
   [(set (match_operand:VHF_AVX512VL 0 "register_operand" "=")
  (unspec:VHF_AVX512VL
-   [(match_operand:VHF_AVX512VL 1 "nonimmediate_operand" "%v")
+   [(match_operand:VHF_AVX512VL 1 "nonimmediate_operand" "v")
 (match_operand:VHF_AVX512VL 2 "nonimmediate_operand" 
"")]
 UNSPEC_COMPLEX_F_C_MUL))]
   "TARGET_AVX512FP16 && "
diff --git a/gcc/testsuite/gcc.target/i386/pr111306.c 
b/gcc/testsuite/gcc.target/i386/pr111306.c
new file mode 100644
index 000..541725ebdad
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr111306.c
@@ -0,0 +1,36 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -mavx512fp16 -mavx512vl" } */
+/* { dg-require-effective-target avx512fp16 } */
+
+#define AVX512FP16
+#include "avx512f-helper.h"
+
+__attribute__((optimize("O2"),noipa))
+void func1(_Float16 *a, _Float16 *b, int n, _Float16 *c) {
+  __m512h rA = _mm512_loadu_ph(a);
+  for (int i = 0; i < n; i += 32) {
+__m512h rB = _mm512_loadu_ph(b + i);
+_mm512_storeu_ph(c + i, _mm512_fcmul_pch(rB, rA));
+  }
+}
+
+void
+test_512 (void)
+{
+  int n = 32;
+  _Float16 a[n], b[n], c[n];
+  _Float16 exp[n];
+  for (int i = 1; i <= n; i++) {
+a[i - 1] = i & 1 ? -i : i;
+b[i - 1] = i;
+  }
+
+  func1(a, b, n, c);
+  for (int i = 0; i < n / 32; i += 2) {
+if (c[i] != a[i] * b[i] + a[i+1] * b[i+1]
+   || c[i+1] != a[i] * b[i+1] - a[i+1]*b[i])
+  __builtin_abort ();
+}
+}
+
+
-- 
2.31.1

[Bug tree-optimization/111348] `(a CMP b) ? minmax : minmax` pattern missing :c on CMP

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 55875
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55875=edit
testcase

Currentlyt test1 is able to optimize to MAX_EXPR , c> but not
test1_

[Bug tree-optimization/111349] `Optimize (a CMP CST1) ? max : a` pattern's cmp is missing :c

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 55874
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55874=edit
testcase

Currently test1_  is only able to optimize to `return a;` during fold.
test1 is caught via phiopt (minmax replacement still) and then during ccp1 is
simplified down to a.

[Bug tree-optimization/111346] `X <= MINMAX` pattern is missing :c on the cmp

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 55873
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55873=edit
Patch which I will commit after testing is finished

[Bug tree-optimization/111346] `X <= MINMAX` pattern is missing :c on the cmp

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

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

--- Comment #3 from Andrew Pinski  ---
Actually here is a simplier testcase:
```
_Bool test1(int a, int b)
{
return ((a > b) ? a : b) >= a; // return 1;
}
_Bool test1_(int a, int b)
{
return a <= ((a > b) ? a : b); // return 1;
}

```
Right now test1_ is able to optimize to 1 while test1 is not. but they are both
the same.

RE: [PATCH] RISC-V: Expand fixed-vlmax/vls vector permutation in targethook

[Li, Pan2 via Gcc-patches]

Committed, thanks Jeff.

Pan

-Original Message-
From: Gcc-patches  On Behalf 
Of Jeff Law via Gcc-patches
Sent: Sunday, September 10, 2023 9:38 PM
To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org
Cc: kito.ch...@sifive.com; kito.ch...@gmail.com
Subject: Re: [PATCH] RISC-V: Expand fixed-vlmax/vls vector permutation in 
targethook



On 9/9/23 20:33, Juzhe-Zhong wrote:
> When debugging FAIL: gcc.dg/pr92301.c execution test.
> Realize a vls vector permutation situation failed to vectorize since early 
> return false:
> 
> -  /* For constant size indices, we dont't need to handle it here.
> - Just leave it to vec_perm.  */
> -  if (d->perm.length ().is_constant ())
> -return false;
> 
> To avoid more potential failed vectorization case. Now expand it in 
> targethook.
> 
> gcc/ChangeLog:
> 
>   * config/riscv/riscv-v.cc (shuffle_generic_patterns): Expand 
> fixed-vlmax/vls vector permutation.
OK.
jeff

RE: [PATCH V2] RISC-V: Avoid unnecessary slideup in compress pattern of vec_perm

[Li, Pan2 via Gcc-patches]

Committed, thanks Jeff.

Pan

-Original Message-
From: Gcc-patches  On Behalf 
Of Jeff Law via Gcc-patches
Sent: Sunday, September 10, 2023 11:25 PM
To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org
Cc: kito.ch...@sifive.com; kito.ch...@gmail.com
Subject: Re: [PATCH V2] RISC-V: Avoid unnecessary slideup in compress pattern 
of vec_perm



On 9/10/23 08:07, Juzhe-Zhong wrote:
> gcc/ChangeLog:
> 
>   * config/riscv/riscv-v.cc (shuffle_compress_patterns): Avoid 
> unnecessary slideup.
OK
jeff

gcc-14-20230910 is now available

[GCC Administrator via Gcc]

Snapshot gcc-14-20230910 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/14-20230910/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 14 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision 30e6ee074588bacefd2dfe745b188bb20c81fe5e

You'll find:

 gcc-14-20230910.tar.xz   Complete GCC

  SHA256=a4a2ad020b53a501ac64c89bc04d873cc76b0a0695c6403ee5a29b6d3dfbba3c
  SHA1=5af07ec6457294422c57b4d5f6591161f93fc179

Diffs from 14-20230903 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-14
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Incremental LTO Project

[Jan Hubicka via Gcc]

> Hi!
> 
> On 2023-09-07T19:00:49-0400, James Hu via Gcc  wrote:
> > I noticed that adding incremental LTO was a GSoC project that was not
> > claimed this cycle (
> > https://summerofcode.withgoogle.com/programs/2023/organizations/gnu-compiler-collection-gcc).
> > I was curious about working on this project, but wanted to check on the
> > state of the project.
> 
> Thanks for your interest!  (... as a potential contributor, I presume?)
> 
> > Has it already been completed? Is someone actively
> > working on it?
> 
> Yesterday, when browsing the schedule of the GNU Tools Cauldron 2023,
> , I noticed there's going to be a
> presentation on "Incremental LTO in GCC" (Michal Jireš),
> .

Indeed Michal Jires (who is my student at Charles University) did a lot
of work on incremental LTO.  He is finishing his second bachelor in
physics and then we plan to start working towards contributing it to the
mainline.
His imlementation is described in thesis
https://dspace.cuni.cz/bitstream/handle/20.500.11956/183051/130360194.pdf?sequence=1

This is just a start of the project, further improvemnts will be welcome

Honza
> 
> > If not, what would be the appropriate method to contact the
> > mentor (Jan Hubička)?
> 
> He's reading this list, but I've now also put Honza in CC.
> 
> 
> Grüße
>  Thomas
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
> München, HRB 106955

[Bug tree-optimization/111364] `MAX_EXPR <= a` is not optimized to `a >= b`

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-09-10
 Status|UNCONFIRMED |ASSIGNED

[Bug tree-optimization/111364] New: `MAX_EXPR <= a` is not optimized to `a >= b`

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

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

Bug ID: 111364
   Summary: `MAX_EXPR <= a` is not optimized to `a >= b`
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

I Noticed this while looking into PR 111346:
```
_Bool test2(int a, int b)
{
int t = a;
if (t < b) t = b;
return t <= a;
}
```
Should be optimized to just:
```
return a >= b;
```

There is a pattern for constants:
/* MIN (X, C1) < C2 -> X < C2 || C1 < C2  */
But we could do the same when we know C1 == C2 and not constant (for
!HONOR_NANS & !HONOR_SIGNED_ZEROS).

[Bug tree-optimization/111346] `X <= MINMAX` pattern is missing :c on the cmp

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=96708

--- Comment #2 from Andrew Pinski  ---
Reduced testcase:
```
static inline _Bool
test1 (int a, int b, int c)
{
return c >= a;
}

int f();
int g();

_Bool test2(int a, int b)
{
a = f();
a = g();
int t = a;
if (t < b) t = b;
return test1(a,b,t);
}
```

This should just reduced to:
```
  f ();
  g ();
  return 1;
```

But currently we get:
```
  f ();
  a_5 = g ();
  _3 = MAX_EXPR ;
  _7 = _3 >= a_5;
  return _7;
```
Which does not match the referenced pattern due to the missing :c on cmp.

[Bug driver/86030] specs file processing does not create response files for input directories

[john.soo+gcc-bugzilla at arista dot com via Gcc-bugs]

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

--- Comment #9 from John Soo  ---
Would a patch for unix doing something similar to
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=180ebb8a24d24fc5b105f2257d6216f6dfde62df
be accepted? I am happy to start working on something like it but I have no gcc
contributions yet and would like to know ahead of time if it is desired.

[Bug c++/111363] New: internal compiler error when mistype type of operator<=>

[sergei at tsaplin dot ru via Gcc-bugs]

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

Bug ID: 111363
   Summary: internal compiler error when mistype type of
operator<=>
   Product: gcc
   Version: 9.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sergei at tsaplin dot ru
  Target Milestone: ---

Created attachment 55872
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55872=edit
archive with 4 file described in the end of comment

mistyped: 
"B operator<=>(const B &) const = default;" 
instead of:
"auto operator<=>(const B &) const = default;"

Got following error on compilation:

kk.cpp:20:20:   required from here
kk.cpp:15:5: internal compiler error: in finish_expr_stmt, at
cp/semantics.c:682
   15 |   B operator<=>(const B &) const = default;
  | ^~~~
0x7f1c30f45082 __libc_start_main
../csu/libc-start.c:308

Error is reproduced when struct B has other struct A as a member and A has
std::array as a member.

gcc version: 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.2)
exec command:  g++ -std=c++20 kk.cpp -save-temps -v &> compiler_output.txt

In attachements:
gcc_v_output.txt: full output of "gcc -v"
compiler_output.txt: output of exec command "g++ ..."
kk.ii: file produced by -save-temps
kk.cpp: single file with source code

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

[Christophe Lyon via Gcc-patches]

Some targets like arm-eabi with newlib and default settings rely on
__sync_synchronize() to ensure synchronization.  Newlib does not
implement it by default, to make users aware they have to take special
care.

This makes a few tests fail to link.

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

2023-09-10  Christophe Lyon  

libstdc++-v3/
* testsuite/20_util/to_address/debug.cc: Require thread-fence effective 
target.
* testsuite/21_strings/basic_string/cons/char/self_move.cc: Likewise.
* testsuite/21_strings/basic_string/debug/1_neg.cc: Likewise.
* testsuite/21_strings/basic_string/debug/2_neg.cc: Likewise.
* testsuite/21_strings/basic_string/debug/find1_neg.cc: Likewise.
* testsuite/21_strings/basic_string/debug/find2_neg.cc: Likewise.
* testsuite/21_strings/basic_string/hash/debug.cc: Likewise.
* testsuite/21_strings/basic_string/requirements/citerators.cc: 
Likewise.
* testsuite/21_strings/basic_string/requirements/exception/basic.cc: 
Likewise.
* 
testsuite/21_strings/basic_string/requirements/exception/generation_prohibited.cc:
Likewise.
* 
testsuite/21_strings/basic_string/requirements/exception/propagation_consistent.cc:
Likewise.
* testsuite/21_strings/debug/shrink_to_fit.cc: Likewise.
* testsuite/23_containers/array/debug/back1_neg.cc: Likewise.
* testsuite/23_containers/array/debug/back2_neg.cc: Likewise.
* testsuite/23_containers/array/debug/front1_neg.cc: Likewise.
* testsuite/23_containers/array/debug/front2_neg.cc: Likewise.
* testsuite/23_containers/array/debug/square_brackets_operator1_neg.cc: 
Likewise.
* testsuite/23_containers/array/debug/square_brackets_operator2_neg.cc: 
Likewise.
* testsuite/23_containers/deque/cons/self_move.cc: Likewise.
* testsuite/23_containers/deque/debug/98466.cc: Likewise.
* testsuite/23_containers/deque/debug/assign4_neg.cc: Likewise.
* testsuite/23_containers/deque/debug/construct4_neg.cc: Likewise.
* testsuite/23_containers/deque/debug/insert4_neg.cc: Likewise.
* testsuite/23_containers/deque/debug/invalidation/1.cc: Likewise.
* testsuite/23_containers/deque/debug/invalidation/2.cc: Likewise.
* testsuite/23_containers/deque/debug/invalidation/3.cc: Likewise.
* testsuite/23_containers/deque/debug/invalidation/4.cc: Likewise.
* testsuite/23_containers/forward_list/cons/self_move.cc: Likewise.
* testsuite/23_containers/forward_list/debug/construct4_neg.cc: 
Likewise.
* testsuite/23_containers/forward_list/debug/move_assign_neg.cc: 
Likewise.
* testsuite/23_containers/forward_list/debug/move_neg.cc: Likewise.
* testsuite/23_containers/list/cons/self_move.cc: Likewise.
* testsuite/23_containers/list/debug/assign4_neg.cc: Likewise.
* testsuite/23_containers/list/debug/construct4_neg.cc: Likewise.
* testsuite/23_containers/list/debug/insert4_neg.cc: Likewise.
* testsuite/23_containers/list/debug/invalidation/1.cc: Likewise.
* testsuite/23_containers/list/debug/invalidation/2.cc: Likewise.
* testsuite/23_containers/list/debug/invalidation/3.cc: Likewise.
* testsuite/23_containers/list/debug/invalidation/4.cc: Likewise.
* testsuite/23_containers/map/debug/construct4_neg.cc: Likewise.
* testsuite/23_containers/map/debug/construct5_neg.cc: Likewise.
* testsuite/23_containers/map/debug/insert4_neg.cc: Likewise.
* testsuite/23_containers/map/debug/invalidation/1.cc: Likewise.
* testsuite/23_containers/map/debug/invalidation/2.cc: Likewise.
* testsuite/23_containers/map/debug/move_assign_neg.cc: Likewise.
* testsuite/23_containers/map/debug/move_neg.cc: Likewise.
* testsuite/23_containers/map/modifiers/erase/end_neg.cc: Likewise.
* testsuite/23_containers/map/modifiers/insert/16813.cc: Likewise.
* testsuite/23_containers/multimap/debug/construct4_neg.cc: Likewise.
* testsuite/23_containers/multimap/debug/construct5_neg.cc: Likewise.
* testsuite/23_containers/multimap/debug/insert4_neg.cc: Likewise.
* testsuite/23_containers/multimap/debug/invalidation/1.cc: Likewise.
* testsuite/23_containers/multimap/debug/invalidation/2.cc: Likewise.
* testsuite/23_containers/multimap/debug/move_assign_neg.cc: Likewise.
* testsuite/23_containers/multimap/debug/move_neg.cc: Likewise.
* testsuite/23_containers/multiset/debug/construct4_neg.cc: Likewise.
* testsuite/23_containers/multiset/debug/construct5_neg.cc: Likewise.
* testsuite/23_containers/multiset/debug/insert4_neg.cc: Likewise.
* testsuite/23_containers/multiset/debug/invalidation/1.cc: Likewise.
* 

[PATCH 1/2] testsuite: Add and use thread_fence effective-target

[Christophe Lyon via Gcc-patches]

Some targets like arm-eabi with newlib and default settings rely on
__sync_synchronize() to ensure synchronization.  Newlib does not
implement it by default, to make users aware they have to take special
care.

This makes a few tests fail to link.

This patch adds a new thread_fence effective target (similar to the
corresponding one in libstdc++ testsuite), and uses it in the tests
that need it, making them UNSUPPORTED instead of FAIL and UNRESOLVED.

2023-09-10  Christophe Lyon  

gcc/
* doc/sourcebuild.texi (Other attributes): Document thread_fence
effective-target.

gcc/testsuite/
* g++.dg/init/array54.C: Require thread_fence.
* gcc.dg/c2x-nullptr-1.c: Likewise.
* gcc.dg/pr103721-2.c: Likewise.
* lib/target-supports.exp (check_effective_target_thread_fence):
New.
---
 gcc/doc/sourcebuild.texi  |  4 
 gcc/testsuite/g++.dg/init/array54.C   |  1 +
 gcc/testsuite/gcc.dg/c2x-nullptr-1.c  |  1 +
 gcc/testsuite/gcc.dg/pr103721-2.c |  1 +
 gcc/testsuite/lib/target-supports.exp | 12 
 5 files changed, 19 insertions(+)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 1a78b3c1abb..a5f61c29f3b 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2860,6 +2860,10 @@ Compiler has been configured to support link-time 
optimization (LTO).
 Compiler and linker support link-time optimization relocatable linking
 with @option{-r} and @option{-flto} options.
 
+@item thread_fence
+Target implements @code{__atomic_thread_fence} without relying on
+non-implemented @code{__sync_synchronize()}.
+
 @item naked_functions
 Target supports the @code{naked} function attribute.
 
diff --git a/gcc/testsuite/g++.dg/init/array54.C 
b/gcc/testsuite/g++.dg/init/array54.C
index f6be350ba72..5241e451d6d 100644
--- a/gcc/testsuite/g++.dg/init/array54.C
+++ b/gcc/testsuite/g++.dg/init/array54.C
@@ -1,5 +1,6 @@
 // PR c++/90947
 // { dg-do run { target c++11 } }
+// { dg-require-effective-target thread_fence }
 
 #include 
 
diff --git a/gcc/testsuite/gcc.dg/c2x-nullptr-1.c 
b/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
index 4e440234d52..97a31c27409 100644
--- a/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
+++ b/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
@@ -1,5 +1,6 @@
 /* Test valid usage of C23 nullptr.  */
 /* { dg-do run } */
+// { dg-require-effective-target thread_fence }
 /* { dg-options "-std=c2x -pedantic-errors -Wall -Wextra -Wno-unused-variable" 
} */
 
 #include 
diff --git a/gcc/testsuite/gcc.dg/pr103721-2.c 
b/gcc/testsuite/gcc.dg/pr103721-2.c
index aefa1f0f147..e059b1cfc2d 100644
--- a/gcc/testsuite/gcc.dg/pr103721-2.c
+++ b/gcc/testsuite/gcc.dg/pr103721-2.c
@@ -1,4 +1,5 @@
 // { dg-do run }
+// { dg-require-effective-target thread_fence }
 // { dg-options "-O2" }
 
 extern void abort ();
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index d353cc0aaf0..7ac9e7530cc 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -9107,6 +9107,18 @@ proc check_effective_target_sync_char_short { } {
 || [check_effective_target_mips_llsc] }}]
 }
 
+# Return 1 if thread_fence does not rely on __sync_synchronize
+# library function
+
+proc check_effective_target_thread_fence {} {
+return [check_no_compiler_messages thread_fence executable {
+   int main () {
+   __atomic_thread_fence (__ATOMIC_SEQ_CST);
+   return 0;
+   }
+} ""]
+}
+
 # Return 1 if the target uses a ColdFire FPU.
 
 proc check_effective_target_coldfire_fpu { } {
-- 
2.34.1

[PATCH v2] swap: Fix incorrect lane extraction by vec_extract() [PR106770]

[Surya Kumari Jangala via Gcc-patches]

swap: Fix incorrect lane extraction by vec_extract() [PR106770]

In the routine rs6000_analyze_swaps(), special handling of swappable
instructions is done even if the webs that contain the swappable
instructions are not optimized, i.e., the webs do not contain any
permuting load/store instructions along with the associated register
swap instructions. Doing special handling in such webs will result in
the extracted lane being adjusted unnecessarily for vec_extract.

Another issue is that existing code treats non-permuting loads/stores
as special swappables. Non-permuting loads/stores (that have not yet
been split into a permuting load/store and a swap) are handled by
converting them into a permuting load/store (which effectively removes
the swap). As a result, if special swappables are handled only in webs
containing permuting loads/stores, then non-optimal code is generated
for non-permuting loads/stores.

Hence, in this patch, all webs containing either permuting loads/
stores or non-permuting loads/stores are marked as requiring special
handling of swappables. Swaps associated with permuting loads/stores
are marked for removal, and non-permuting loads/stores are converted to
permuting loads/stores. Then the special swappables in the webs are
fixed up.

Another issue with always handling swappable instructions is that it is
incorrect to do so in webs where loads/stores on quad word aligned
addresses are changed to lvx/stvx. Similarly, in webs where
swap(load(vector constant)) instructions are replaced with
load(swapped vector constant), the swappable instructions should not be
modified.

2023-09-10  Surya Kumari Jangala  

gcc/
PR rtl-optimization/PR106770
* config/rs6000/rs6000-p8swap.cc (non_permuting_mem_insn): New
function.
(handle_non_permuting_mem_insn): New function.
(rs6000_analyze_swaps): Handle swappable instructions only in
certain webs.
(web_requires_special_handling): New instance variable.
(handle_special_swappables): Remove handling of non-permuting
load/store instructions.

gcc/testsuite/
PR rtl-optimization/PR106770
* gcc.target/powerpc/pr106770.c: New test.
---

diff --git a/gcc/config/rs6000/rs6000-p8swap.cc 
b/gcc/config/rs6000/rs6000-p8swap.cc
index 0388b9bd736..3a695aa1318 100644
--- a/gcc/config/rs6000/rs6000-p8swap.cc
+++ b/gcc/config/rs6000/rs6000-p8swap.cc
@@ -179,6 +179,13 @@ class swap_web_entry : public web_entry_base
   unsigned int special_handling : 4;
   /* Set if the web represented by this entry cannot be optimized.  */
   unsigned int web_not_optimizable : 1;
+  /* Set if the swappable insns in the web represented by this entry
+ have to be fixed. Swappable insns have to be fixed in :
+   - webs containing permuting loads/stores and the swap insns
+in such webs have been marked for removal
+   - webs where non-permuting loads/stores have been converted
+to permuting loads/stores  */
+  unsigned int web_requires_special_handling : 1;
   /* Set if this insn should be deleted.  */
   unsigned int will_delete : 1;
 };
@@ -1468,14 +1475,6 @@ handle_special_swappables (swap_web_entry *insn_entry, 
unsigned i)
   if (dump_file)
fprintf (dump_file, "Adjusting subreg in insn %d\n", i);
   break;
-case SH_NOSWAP_LD:
-  /* Convert a non-permuting load to a permuting one.  */
-  permute_load (insn);
-  break;
-case SH_NOSWAP_ST:
-  /* Convert a non-permuting store to a permuting one.  */
-  permute_store (insn);
-  break;
 case SH_EXTRACT:
   /* Change the lane on an extract operation.  */
   adjust_extract (insn);
@@ -2401,6 +2400,25 @@ recombine_lvx_stvx_patterns (function *fun)
   free (to_delete);
 }
 
+/* Return true if insn is a non-permuting load/store.  */
+static bool
+non_permuting_mem_insn (swap_web_entry *insn_entry, unsigned int i)
+{
+  return (insn_entry[i].special_handling == SH_NOSWAP_LD ||
+ insn_entry[i].special_handling == SH_NOSWAP_ST);
+}
+
+/* Convert a non-permuting load/store insn to a permuting one.  */
+static void
+handle_non_permuting_mem_insn (swap_web_entry *insn_entry, unsigned int i)
+{
+  rtx_insn *insn = insn_entry[i].insn;
+  if (insn_entry[i].special_handling == SH_NOSWAP_LD)
+permute_load (insn);
+  else if (insn_entry[i].special_handling == SH_NOSWAP_ST)
+permute_store (insn);
+}
+
 /* Main entry point for this pass.  */
 unsigned int
 rs6000_analyze_swaps (function *fun)
@@ -2624,25 +2642,56 @@ rs6000_analyze_swaps (function *fun)
   dump_swap_insn_table (insn_entry);
 }
 
-  /* For each load and store in an optimizable web (which implies
- the loads and stores are permuting), find the associated
- register swaps and mark them for removal.  Due to various
- optimizations we may mark the same swap more than once.  Also
- perform special handling for swappable insns that require it.  */
+  /* There are two kinds of optimizations 

PING^4: [PATCH] rtl-optimization/110939 Really fix narrow comparison of memory and constant

[Xi Ruoyao via Gcc-patches]

Ping.

> > > On Thu, Aug 10, 2023 at 03:04:03PM +0200, Stefan Schulze Frielinghaus 
> > > wrote:
> > > > In the former fix in commit 41ef5a34161356817807be3a2e51fbdbe575ae85 I
> > > > completely missed the fact that the normal form of a generated constant 
> > > > for a
> > > > mode with fewer bits than in HOST_WIDE_INT is a sign extended version 
> > > > of the
> > > > actual constant.  This even holds true for unsigned constants.
> > > > 
> > > > Fixed by masking out the upper bits for the incoming constant and sign
> > > > extending the resulting unsigned constant.
> > > > 
> > > > Bootstrapped and regtested on x64 and s390x.  Ok for mainline?
> > > > 
> > > > While reading existing optimizations in combine I stumbled across two
> > > > optimizations where either my intuition about the representation of
> > > > unsigned integers via a const_int rtx is wrong, which then in turn would
> > > > probably also mean that this patch is wrong, or that the optimizations
> > > > are missed sometimes.  In other words in the following I would assume
> > > > that the upper bits are masked out:
> > > > 
> > > > diff --git a/gcc/combine.cc b/gcc/combine.cc
> > > > index 468b7fde911..80c4ff0fbaf 100644
> > > > --- a/gcc/combine.cc
> > > > +++ b/gcc/combine.cc
> > > > @@ -11923,7 +11923,7 @@ simplify_compare_const (enum rtx_code code, 
> > > > machine_mode mode,
> > > >    /* (unsigned) < 0x8000 is equivalent to >= 0.  */
> > > >    else if (is_a  (mode, _mode)
> > > >    && GET_MODE_PRECISION (int_mode) - 1 < 
> > > > HOST_BITS_PER_WIDE_INT
> > > > -  && ((unsigned HOST_WIDE_INT) const_op
> > > > +  && (((unsigned HOST_WIDE_INT) const_op & GET_MODE_MASK 
> > > > (int_mode))
> > > >    == HOST_WIDE_INT_1U << (GET_MODE_PRECISION 
> > > > (int_mode) - 1)))
> > > >     {
> > > >   const_op = 0;
> > > > @@ -11962,7 +11962,7 @@ simplify_compare_const (enum rtx_code code, 
> > > > machine_mode mode,
> > > >    /* (unsigned) >= 0x8000 is equivalent to < 0.  */
> > > >    else if (is_a  (mode, _mode)
> > > >    && GET_MODE_PRECISION (int_mode) - 1 < 
> > > > HOST_BITS_PER_WIDE_INT
> > > > -  && ((unsigned HOST_WIDE_INT) const_op
> > > > +  && (((unsigned HOST_WIDE_INT) const_op & GET_MODE_MASK 
> > > > (int_mode))
> > > >    == HOST_WIDE_INT_1U << (GET_MODE_PRECISION 
> > > > (int_mode) - 1)))
> > > >     {
> > > >   const_op = 0;
> > > > 
> > > > For example, while bootstrapping on x64 the optimization is missed since
> > > > a LTU comparison in QImode is done and the constant equals
> > > > 0xff80.
> > > > 
> > > > Sorry for inlining another patch, but I would really like to make sure
> > > > that my understanding is correct, now, before I come up with another
> > > > patch.  Thus it would be great if someone could shed some light on this.
> > > > 
> > > > gcc/ChangeLog:
> > > > 
> > > > * combine.cc (simplify_compare_const): Properly handle unsigned
> > > > constants while narrowing comparison of memory and constants.
> > > > ---
> > > >  gcc/combine.cc | 19 ++-
> > > >  1 file changed, 10 insertions(+), 9 deletions(-)
> > > > 
> > > > diff --git a/gcc/combine.cc b/gcc/combine.cc
> > > > index e46d202d0a7..468b7fde911 100644
> > > > --- a/gcc/combine.cc
> > > > +++ b/gcc/combine.cc
> > > > @@ -12003,14 +12003,15 @@ simplify_compare_const (enum rtx_code code, 
> > > > machine_mode mode,
> > > >    && !MEM_VOLATILE_P (op0)
> > > >    /* The optimization makes only sense for constants which are big 
> > > > enough
> > > >  so that we have a chance to chop off something at all.  */
> > > > -  && (unsigned HOST_WIDE_INT) const_op > 0xff
> > > > -  /* Bail out, if the constant does not fit into INT_MODE.  */
> > > > -  && (unsigned HOST_WIDE_INT) const_op
> > > > -    < ((HOST_WIDE_INT_1U << (GET_MODE_PRECISION (int_mode) - 1) << 
> > > > 1) - 1)
> > > > +  && ((unsigned HOST_WIDE_INT) const_op & GET_MODE_MASK 
> > > > (int_mode)) > 0xff
> > > >    /* Ensure that we do not overflow during normalization.  */
> > > > -  && (code != GTU || (unsigned HOST_WIDE_INT) const_op < 
> > > > HOST_WIDE_INT_M1U))
> > > > +  && (code != GTU
> > > > + || ((unsigned HOST_WIDE_INT) const_op & GET_MODE_MASK 
> > > > (int_mode))
> > > > +    < HOST_WIDE_INT_M1U)
> > > > +  && trunc_int_for_mode (const_op, int_mode) == const_op)
> > > >  {
> > > > -  unsigned HOST_WIDE_INT n = (unsigned HOST_WIDE_INT) const_op;
> > > > +  unsigned HOST_WIDE_INT n
> > > > +   = (unsigned HOST_WIDE_INT) const_op & GET_MODE_MASK (int_mode);
> > > >    enum rtx_code adjusted_code;
> > > >  
> > > >    /* Normalize code to either LEU or GEU.  */
> > > > @@ -12051,15 +12052,15 @@ simplify_compare_const (enum rtx_code code, 
> > > > machine_mode mode,
> > > > 

[Bug bootstrap/102665] ELF-specific configure flags should be rejected on non-ELF platforms

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

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

--- Comment #7 from Eric Gallager  ---
Making some more progress on this:
https://github.com/gcc-mirror/gcc/compare/master...cooljeanius:gcc:me/PR102665
Some notes:
- There are a lot of these; I'm not quite sure how many to include in a single
patch, or where I should stop...
- I'm currently testing platform based on target, but I'm not quite sure if
that's correct? Are these target flags or host flags?
- All I've done so far has been to test to make sure that the flags are
properly rejected on platforms where they're unsupported; I'd appreciate it if
people could help with testing that they're still accepted on platforms where
they're supposed to be accepted, though...

[Bug tree-optimization/111331] [11/12/13 Regression] Wrong code at -O1 on x86_64-linux-gnu since

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression] Wrong
   |Wrong code at -O1 on|code at -O1 on
   |x86_64-linux-gnu since  |x86_64-linux-gnu since

--- Comment #14 from Andrew Pinski  ---
Fixed on the trunk, will backport in a few days.

[Bug tree-optimization/111331] [11/12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu since

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

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

--- Comment #13 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:30e6ee074588bacefd2dfe745b188bb20c81fe5e

commit r14-3827-g30e6ee074588bacefd2dfe745b188bb20c81fe5e
Author: Andrew Pinski 
Date:   Thu Sep 7 22:13:31 2023 -0700

Fix PR 111331: wrong code for `a > 28 ? MIN : 29`

The problem here is after r6-7425-ga9fee7cdc3c62d0e51730,
the comparison to see if the transformation could be done was using the
wrong value. Instead of see if the inner was LE (for MIN and GE for MAX)
the outer value, it was comparing the inner to the value used in the
comparison
which was wrong.
The match pattern copied the same logic mistake when they were added in
r14-1411-g17cca3c43e2f49 .

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

gcc/ChangeLog:

PR tree-optimization/111331
* match.pd (`(a CMP CST1) ? max : a`):
Fix the LE/GE comparison to the correct value.
* tree-ssa-phiopt.cc (minmax_replacement):
Fix the LE/GE comparison for the
`(a CMP CST1) ? max : a` optimization.

gcc/testsuite/ChangeLog:

PR tree-optimization/111331
* gcc.c-torture/execute/pr111331-1.c: New test.
* gcc.c-torture/execute/pr111331-2.c: New test.
* gcc.c-torture/execute/pr111331-3.c: New test.

Re: [PATCH] Fix PR 111331: wrong code for `a > 28 ? MIN : 29`

[Jeff Law via Gcc-patches]

On 9/8/23 06:39, Andrew Pinski via Gcc-patches wrote:

The problem here is after r6-7425-ga9fee7cdc3c62d0e51730,
the comparison to see if the transformation could be done was using the
wrong value. Instead of see if the inner was LE (for MIN and GE for MAX)
the outer value, it was comparing the inner to the value used in the comparison
which was wrong.
The match pattern copied the same logic mistake when they were added in
r14-1411-g17cca3c43e2f49 .

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

gcc/ChangeLog:

PR tree-optimization/111331
* match.pd (`(a CMP CST1) ? max : a`):
Fix the LE/GE comparison to the correct value.
* tree-ssa-phiopt.cc (minmax_replacement):
Fix the LE/GE comparison for the
`(a CMP CST1) ? max : a` optimization.

gcc/testsuite/ChangeLog:

PR tree-optimization/111331
* gcc.c-torture/execute/pr111331-1.c: New test.
* gcc.c-torture/execute/pr111331-2.c: New test.
* gcc.c-torture/execute/pr111331-3.c: New test.

OK
jeff

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

[Jeff Law via Gcc-patches]

On 8/31/23 11:36, Edwin Lu wrote:

Related Discussion:
https://inbox.sourceware.org/gcc-patches/12fb5088-3f28-0a69-de1e-f387371a5...@gmail.com/

This patch updates the THEAD instructions to ensure that no insn is left
without a type attribute.

Tested for regressions using rv32/64 multilib for linux/newlib.

gcc/Changelog:

* config/riscv/thead.md: Update types
OK.  THe first could arguably be "multi", but both instructions it 
generates appear to be move/conversions, so "fmove" is reasonable as well.


Ok for the trunk.  And I think that's should allow us to turn on the 
assertion, right?


jeff

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

[Sam James via Gcc-patches]

François Dumont via Gcc-patches  writes:

> Following confirmation of the fix by TC here is the patch where I'm
> simply adding a 'constexpr' on _M_next().
>
> Please let me know this ChangeLog entry is correct. I would prefer
> this patch to be assigned to 'TC' with me as co-author but I don't
> know how to do such a thing. Unless I need to change my user git
> identity to do so ?

git commit --author="TC " --amend

>
>     libstdc++: Add constexpr qualification to _Hash_node::_M_next()
>
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1b6f0476837205932613ddb2b3429a55c26c409d
>     changed _Hash_node_value_base to no longer derive from
> _Hash_node_base, which means
>     that its member functions expect _M_storage to be at a different
> offset. So explosions
>     result if an out-of-line definition is emitted for any of the
> member functions (say,
>     in a non-optimized build) and the resulting object file is then
> linked with code built
>     using older version of GCC/libstdc++.
>
>     libstdc++-v3/ChangeLog:
>
>     * include/bits/hashtable_policy.h
>     (_Hash_node_value_base<>::_M_valptr(),
> _Hash_node_value_base<>::_M_v())
>     Add [[__gnu__::__always_inline__]].
>     (_Hash_node<>::_M_next()): Add constexpr.
>
>     Co-authored-by: TC 
>
> Ok to commit and backport to GCC 11, 12, 13 branches ?
>
> François
>
> [2. text/x-patch; pr111050.patch]...

[Bug bootstrap/91972] Bootstrap should use -Wmissing-declarations

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

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords|easyhack|

--- Comment #9 from Eric Gallager  ---
so, I've tried enabling this flag while building, and one problem with it is
that GCC's genfoo machinery for its garbage collection system creates a bunch
of gt-*.h headers with a bunch of autogenerated gt_ggc_mx and gt_pch_nx
functions in them that all get warned about... this will require messing with
the generator utilities to get them to stop generating code that warns, so this
will be more difficult than I thought; removing the "easyhack" keyword...

Re: [PATCH V2] RISC-V: Avoid unnecessary slideup in compress pattern of vec_perm

[Jeff Law via Gcc-patches]

On 9/10/23 08:07, Juzhe-Zhong wrote:

gcc/ChangeLog:

* config/riscv/riscv-v.cc (shuffle_compress_patterns): Avoid 
unnecessary slideup.

OK
jeff

Re: Re: [PATCH] RISC-V: Avoid unnecessary slideup in compress pattern of vec_perm

[钟居哲]

Address comment: [PATCH V2] RISC-V: Avoid unnecessary slideup in compress 
pattern of vec_perm (gnu.org)



juzhe.zh...@rivai.ai
 
From: Jeff Law
Date: 2023-09-10 21:34
To: Juzhe-Zhong; gcc-patches
CC: kito.cheng; kito.cheng; rdapp.gcc
Subject: Re: [PATCH] RISC-V: Avoid unnecessary slideup in compress pattern of 
vec_perm
 
 
On 9/9/23 21:55, Juzhe-Zhong wrote:
> If a const vector all elements are same, the slide up is unnecessary.
> 
> gcc/ChangeLog:
> 
> * config/riscv/riscv-v.cc (shuffle_compress_patterns): Avoid unnecessary 
> slideup.
> 
> ---
>   gcc/config/riscv/riscv-v.cc | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
> index bee60de1d26..7ef884907b8 100644
> --- a/gcc/config/riscv/riscv-v.cc
> +++ b/gcc/config/riscv/riscv-v.cc
> @@ -2697,7 +2697,7 @@ shuffle_compress_patterns (struct expand_vec_perm_d *d)
> rtx mask = force_reg (mask_mode, builder.build ());
>   
> rtx merge = d->op1;
> -  if (need_slideup_p)
> +  if (need_slideup_p && !const_vec_duplicate_p (d->op1))
>   {
> int slideup_cnt = vlen - (d->perm[vlen - 1].to_constant () % vlen) - 
> 1;
> rtx ops[] = {d->target, d->op1, gen_int_mode (slideup_cnt, Pmode)};
Would it be better to adjust how we compute need_slidup_p to check 
!const_vec_duplicate_p (d->op1) instead of doing it here?
 
That way the name "need_slideup_p" stays consistent with the intent of 
the code.  It would also mean we wouldn't need to duplicate the 
additional check if we wanted to model the use of slideup in the cost 
calculations.
 
Jeff
 

[pushed] Darwin: Partial reversion of r14-3648 (Inits Section).

[Iain Sandoe via Gcc-patches]

Tested on x86_64-darwin21 and i686-darwin9 with both dwarfutils and
llvm-based dsymutil implementations.  Pushed to trunk, thanks
Iain

--- 8< ---

Although the Darwin ABI places both hot and cold partitions in the same
section (the linker can partition by name), this does not work with the
current dwarf2out implementation.

Since we do see global initialization code getting hot/cold splits, this
patch places the cold parts into text_cold, and keeps the hot part in
the correct Init section per ABI.

TODO: figure out a way to allow us to match the ABI fully.

gcc/ChangeLog:

* config/darwin.cc (darwin_function_section): Place unlikely
executed global init code into the standard cold section.

Signed-off-by: Iain Sandoe 
---
 gcc/config/darwin.cc | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/gcc/config/darwin.cc b/gcc/config/darwin.cc
index 95d6194cf22..154a2b2755a 100644
--- a/gcc/config/darwin.cc
+++ b/gcc/config/darwin.cc
@@ -3893,19 +3893,22 @@ darwin_function_section (tree decl, enum node_frequency 
freq,
   if (decl && DECL_SECTION_NAME (decl) != NULL)
 return get_named_section (decl, NULL, 0);
 
+  /* We always put unlikely executed stuff in the cold section; we have to put
+ this ahead of the global init section, since partitioning within a section
+ breaks some assumptions made in the DWARF handling.  */
+  if (freq == NODE_FREQUENCY_UNLIKELY_EXECUTED)
+return (use_coal) ? darwin_sections[text_cold_coal_section]
+ : darwin_sections[text_cold_section];
+
   /* Intercept functions in global init; these are placed in separate sections.
- FIXME: there should be some neater way to do this.  */
+ FIXME: there should be some neater way to do this, FIXME we should be able
+ to partition within a section.  */
   if (DECL_NAME (decl)
   && (startswith (IDENTIFIER_POINTER (DECL_NAME (decl)), "_GLOBAL__sub_I")
  || startswith (IDENTIFIER_POINTER (DECL_NAME (decl)),
 "__static_initialization_and_destruction")))
 return  darwin_sections[static_init_section];
 
-  /* We always put unlikely executed stuff in the cold section.  */
-  if (freq == NODE_FREQUENCY_UNLIKELY_EXECUTED)
-return (use_coal) ? darwin_sections[text_cold_coal_section]
- : darwin_sections[text_cold_section];
-
   /* If we have LTO *and* feedback information, then let LTO handle
  the function ordering, it makes a better job (for normal, hot,
  startup and exit - hence the bailout for cold above).  */
-- 
2.39.2 (Apple Git-143)

Re: [PATCH V2] RISC-V: Avoid unnecessary slideup in compress pattern of vec_perm

[钟居哲]

Address comment: [PATCH V2] RISC-V: Avoid unnecessary slideup in compress 
pattern of vec_perm (gnu.org)



juzhe.zh...@rivai.ai
 
From: Juzhe-Zhong
Date: 2023-09-10 22:07
To: gcc-patches
CC: kito.cheng; kito.cheng; jeffreyalaw; rdapp.gcc; Juzhe-Zhong
Subject: [PATCH V2] RISC-V: Avoid unnecessary slideup in compress pattern of 
vec_perm
gcc/ChangeLog:
 
* config/riscv/riscv-v.cc (shuffle_compress_patterns): Avoid unnecessary 
slideup.
 
---
gcc/config/riscv/riscv-v.cc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
 
diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index bee60de1d26..3cd1f61de0e 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -2647,7 +2647,8 @@ shuffle_compress_patterns (struct expand_vec_perm_d *d)
For index = { 0, 2, 5, 6}, we need to slide op1 up before
we apply compress approach.  */
-  bool need_slideup_p = maybe_ne (d->perm[vlen - 1], 2 * vec_len - 1);
+  bool need_slideup_p = maybe_ne (d->perm[vlen - 1], 2 * vec_len - 1)
+ && !const_vec_duplicate_p (d->op1);
   /* If we leave it directly be handled by general gather,
  the code sequence will be:
-- 
2.36.3
 

[PATCH V2] RISC-V: Avoid unnecessary slideup in compress pattern of vec_perm

[Juzhe-Zhong]

gcc/ChangeLog:

* config/riscv/riscv-v.cc (shuffle_compress_patterns): Avoid 
unnecessary slideup.

---
 gcc/config/riscv/riscv-v.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index bee60de1d26..3cd1f61de0e 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -2647,7 +2647,8 @@ shuffle_compress_patterns (struct expand_vec_perm_d *d)
 
For index = { 0, 2, 5, 6}, we need to slide op1 up before
we apply compress approach.  */
-  bool need_slideup_p = maybe_ne (d->perm[vlen - 1], 2 * vec_len - 1);
+  bool need_slideup_p = maybe_ne (d->perm[vlen - 1], 2 * vec_len - 1)
+   && !const_vec_duplicate_p (d->op1);
 
   /* If we leave it directly be handled by general gather,
  the code sequence will be:
-- 
2.36.3

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

[François Dumont via Gcc-patches]

Following confirmation of the fix by TC here is the patch where I'm 
simply adding a 'constexpr' on _M_next().


Please let me know this ChangeLog entry is correct. I would prefer this 
patch to be assigned to 'TC' with me as co-author but I don't know how 
to do such a thing. Unless I need to change my user git identity to do so ?


    libstdc++: Add constexpr qualification to _Hash_node::_M_next()

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1b6f0476837205932613ddb2b3429a55c26c409d
    changed _Hash_node_value_base to no longer derive from 
_Hash_node_base, which means
    that its member functions expect _M_storage to be at a different 
offset. So explosions
    result if an out-of-line definition is emitted for any of the 
member functions (say,
    in a non-optimized build) and the resulting object file is then 
linked with code built

    using older version of GCC/libstdc++.

    libstdc++-v3/ChangeLog:

    * include/bits/hashtable_policy.h
    (_Hash_node_value_base<>::_M_valptr(), 
_Hash_node_value_base<>::_M_v())

    Add [[__gnu__::__always_inline__]].
    (_Hash_node<>::_M_next()): Add constexpr.

    Co-authored-by: TC 

Ok to commit and backport to GCC 11, 12, 13 branches ?

François

diff --git a/libstdc++-v3/include/bits/hashtable_policy.h b/libstdc++-v3/include/bits/hashtable_policy.h
index 347d468ea86..101c5eb639c 100644
--- a/libstdc++-v3/include/bits/hashtable_policy.h
+++ b/libstdc++-v3/include/bits/hashtable_policy.h
@@ -327,18 +327,22 @@ namespace __detail
 
   __gnu_cxx::__aligned_buffer<_Value> _M_storage;
 
+  [[__gnu__::__always_inline__]]
   _Value*
   _M_valptr() noexcept
   { return _M_storage._M_ptr(); }
 
+  [[__gnu__::__always_inline__]]
   const _Value*
   _M_valptr() const noexcept
   { return _M_storage._M_ptr(); }
 
+  [[__gnu__::__always_inline__]]
   _Value&
   _M_v() noexcept
   { return *_M_valptr(); }
 
+  [[__gnu__::__always_inline__]]
   const _Value&
   _M_v() const noexcept
   { return *_M_valptr(); }
@@ -372,7 +376,7 @@ namespace __detail
 : _Hash_node_base
 , _Hash_node_value<_Value, _Cache_hash_code>
 {
-  _Hash_node*
+  constexpr _Hash_node*
   _M_next() const noexcept
   { return static_cast<_Hash_node*>(this->_M_nxt); }
 };

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[matoro_gcc_bugzilla at matoro dot tk via Gcc-bugs]

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

--- Comment #31 from matoro  ---
(In reply to Eric Gallager from comment #30)
> (In reply to matoro from comment #26)
> > We also had somebody report on IRC that they observed this on powerpc (not
> > sure what tuple), again with -j1.  It does not seem to show up with -j2, so
> > likely -j1 is necessary to trigger.
> 
> I can also confirm that switching to -j2 makes this particular error go away

It may make it "go away", but how can it be worked around on real single-core
systems?  All that does is get lucky by throwing more parallelism at it.  I've
been completely unable to even try out gccgo because of this bug.

Re: [PATCH] RISC-V: Expand fixed-vlmax/vls vector permutation in targethook

[Jeff Law via Gcc-patches]

On 9/9/23 20:33, Juzhe-Zhong wrote:

When debugging FAIL: gcc.dg/pr92301.c execution test.
Realize a vls vector permutation situation failed to vectorize since early 
return false:

-  /* For constant size indices, we dont't need to handle it here.
- Just leave it to vec_perm.  */
-  if (d->perm.length ().is_constant ())
-return false;

To avoid more potential failed vectorization case. Now expand it in targethook.

gcc/ChangeLog:

* config/riscv/riscv-v.cc (shuffle_generic_patterns): Expand 
fixed-vlmax/vls vector permutation.

OK.
jeff

Re: [PATCH] RISC-V: Avoid unnecessary slideup in compress pattern of vec_perm

[Jeff Law via Gcc-patches]

On 9/9/23 21:55, Juzhe-Zhong wrote:

If a const vector all elements are same, the slide up is unnecessary.

gcc/ChangeLog:

* config/riscv/riscv-v.cc (shuffle_compress_patterns): Avoid 
unnecessary slideup.

---
  gcc/config/riscv/riscv-v.cc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index bee60de1d26..7ef884907b8 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -2697,7 +2697,7 @@ shuffle_compress_patterns (struct expand_vec_perm_d *d)
rtx mask = force_reg (mask_mode, builder.build ());
  
rtx merge = d->op1;

-  if (need_slideup_p)
+  if (need_slideup_p && !const_vec_duplicate_p (d->op1))
  {
int slideup_cnt = vlen - (d->perm[vlen - 1].to_constant () % vlen) - 1;
rtx ops[] = {d->target, d->op1, gen_int_mode (slideup_cnt, Pmode)};
Would it be better to adjust how we compute need_slidup_p to check 
!const_vec_duplicate_p (d->op1) instead of doing it here?


That way the name "need_slideup_p" stays consistent with the intent of 
the code.  It would also mean we wouldn't need to duplicate the 
additional check if we wanted to model the use of slideup in the cost 
calculations.


Jeff

[Bug target/111362] New: [14 Regression] '-fcompare-debug' failure (length) with -O -fno-tree-ch --param=max-completely-peel-times=0 -march=rv64iv

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 111362
   Summary: [14 Regression] '-fcompare-debug' failure (length)
with -O -fno-tree-ch
--param=max-completely-peel-times=0 -march=rv64iv
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: compare-debug-failure
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu

Created attachment 55871
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55871=edit
reduced testcase

Compiler output:
$ riscv64-unknown-linux-gnu-gcc -O -fno-tree-ch
--param=max-completely-peel-times=0 -march=rv64iv -fcompare-debug testcase.c
-save-temps
riscv64-unknown-linux-gnu-gcc: error: testcase.c: '-fcompare-debug' failure
(length)

$ diff -u *gkd
--- a-testcase.c.gkd2023-09-10 13:14:46.728418677 +0200
+++ a-testcase.gk.c.gkd 2023-09-10 13:14:46.781751718 +0200
@@ -34,17 +34,7 @@
 (const_int 8 [0x8])) [  S8 A64])
 (reg:DI 9 s1))
 (nil
-(insn/f # 0 0 (set (mem/c:DI (reg/f:DI 2 sp) [  S8 A64])
-(reg:DI 18 s2)) "testcase.c":2:11# {*movdi_64bit}
- (expr_list:REG_DEAD (reg:DI 18 s2)
-(expr_list:REG_FRAME_RELATED_EXPR (set/f (mem/c:DI (reg/f:DI 2 sp) [ 
S8 A64])
-(reg:DI 18 s2))
-(nil
 (note # 0 0 NOTE_INSN_PROLOGUE_END)
-(insn # 0 0 (set (reg:SI 18 s2 [139])
-(reg:SI 69 frm))# {frrmsi}
- (expr_list:REG_DEAD (reg:SI 69 frm)
-(nil)))
 (note # 0 0 NOTE_INSN_FUNCTION_BEG)
 (insn # 0 0 (set (reg:DI 8 s0 [orig:134 ivtmp_6 ] [134])
 (const_int 2 [0x2])) "testcase.c":3:3# {*movdi_64bit}
@@ -85,10 +75,6 @@
 (const_int 8 [0x8])) [  S8 A64])) "testcase.c":5:1#
{*movdi_64bit}
  (expr_list:REG_CFA_RESTORE (reg:DI 9 s1)
 (nil)))
-(insn/f # 0 0 (set (reg:DI 18 s2)
-(mem/c:DI (reg/f:DI 2 sp) [  S8 A64])) "testcase.c":5:1#
{*movdi_64bit}
- (expr_list:REG_CFA_RESTORE (reg:DI 18 s2)
-(nil)))
 (insn # 0 0 (set (mem:BLK (scratch) [  A8])
 (unspec:BLK [
 (reg/f:DI 2 sp)
@@ -118,12 +104,6 @@
 (symbol_ref/f:DI ("*.LC0") [flags 0x82]  )))
"testcase.c":4:5# {*lowdi}
  (expr_list:REG_EQUAL (symbol_ref/f:DI ("*.LC0") [flags 0x82]  )
 (nil)))
-(insn # 0 0 (set (reg:SI 69 frm)
-(unspec_volatile:SI [
-(reg:SI 18 s2 [139])
-] UNSPECV_FRM_RESTORE_EXIT)) "testcase.c":4:5#
{fsrmsi_restore_volatile}
- (expr_list:REG_UNUSED (reg:SI 69 frm)
-(nil)))
 (call_insn # 0 0 (parallel [
 (set (reg:DI 10 a0)
 (call (mem:SI (symbol_ref:DI ("printf") [flags 0x41] 
) [ __builtin_printf S4 A32])

$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-3825-20230910101237-g0d50facd937-checking-yes-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,df,extra
--with-cloog --with-ppl --with-isl --with-isa-spec=2.2
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-3825-20230910101237-g0d50facd937-checking-yes-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230910 (experimental) (GCC)

[Bug analyzer/111361] New: [14 Regression] ICE: in has_null_terminator, at analyzer/region-model.cc:3410 with -fanalyzer

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 111361
   Summary: [14 Regression] ICE: in has_null_terminator, at
analyzer/region-model.cc:3410 with -fanalyzer
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 55870
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55870=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fanalyzer testcase.c
during IPA pass: analyzer
testcase.c: In function 'foo':
testcase.c:7:3: internal compiler error: in has_null_terminator, at
analyzer/region-model.cc:3410
7 |   __builtin_strncpy (out, (void *), 5);
  |   ^~
0x18a4beb
ana::fragment::has_null_terminator(generic_wide_int
>, generic_wide_int >*) const
/repo/gcc-trunk/gcc/analyzer/region-model.cc:3410
0x1893cf5 ana::region_model::scan_for_null_terminator(ana::region const*,
tree_node*, ana::svalue const**, ana::region_model_context*) const
/repo/gcc-trunk/gcc/analyzer/region-model.cc:3676
0x18740c3 ana::kf_strncpy::impl_call_post(ana::call_details const&) const
/repo/gcc-trunk/gcc/analyzer/kf.cc:1544
0x18740c3 ana::kf_strncpy::impl_call_post(ana::call_details const&) const
/repo/gcc-trunk/gcc/analyzer/kf.cc:1409
0x189f197 ana::region_model::on_call_post(gcall const*, bool,
ana::region_model_context*)
/repo/gcc-trunk/gcc/analyzer/region-model.cc:1679
0x186137b ana::exploded_node::on_stmt_post(gimple const*, ana::program_state*,
bool, ana::region_model_context*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:1569
0x186137b ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::uncertainty_t*,
ana::path_context*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:1507
0x1863e25 ana::exploded_graph::process_node(ana::exploded_node*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:4082
0x1864d6a ana::exploded_graph::process_worklist()
/repo/gcc-trunk/gcc/analyzer/engine.cc:3476
0x186745f ana::impl_run_checkers(ana::logger*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:6144
0x18682e6 ana::run_checkers()
/repo/gcc-trunk/gcc/analyzer/engine.cc:6232
0x1857608 execute
/repo/gcc-trunk/gcc/analyzer/analyzer-pass.cc:87
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.


$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-3825-20230910101237-g0d50facd937-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-3825-20230910101237-g0d50facd937-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230910 (experimental) (GCC)

[Bug ada/81114] GNAT mishandles filenames with UTF8 chars on case-insensitive filesystems

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
 Status|SUSPENDED   |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #5 from Eric Gallager  ---
(In reply to simon from comment #4)
> (In reply to Eric Botcazou from comment #2)
> 
> When I said in comment 1 
> 
> >I have to say that, great as it would be to have this fixed, the changes 
> >required would be extensive, and I can’t see that anyone would think it 
> >worth the trouble.
> 
> I meant that coping with macOS’s HFS+ behaviour w.r.t. NFC vs NFD was 
> something it’d be unreasonable to spend effort on fixing.
> 
> The main point of this PR is that you can’t use extended characters in 
> unit names on case-insensitive filesystems, *which includes Windows*. 
> Fixing that problem (I can see it might mean introducing a new adaint.c 
> interface "is filesystem UTF8?") would be a good thing. Can the compiler 
> use iconv? or Ada.Wide_Characters.Handling,
> Ada.Strings.UTF_Encoding.[Wide_]Strings?
> 
> The awkwardness discussed in comment 1 isn’t really a problem except 
> when compiling the offending unit from the command line; when compiled 
> as part of the closure by gnatmake there’s no problem, I guess gnatmake 
> reads the unit name in NFC and gets the file name in NFD from the file 
> system.
> 
> I think there _is_ a problem in gprbuild but of course that’s nothing 
> to do with GCC.
> 
> Please can this PR be reopened?

Well, it was never closed in the first place, just marked as SUSPENDED, but I
can put it back to UNCONFIRMED, I guess...

[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

Eric Gallager  changed:

   What|Removed |Added

 CC||belyshev at depni dot 
sinp.msu.ru

--- Comment #1 from Eric Gallager  ---
git blame says that Serge Belyshev was the last to touch this line in
r12-3370-g78b34cd8a803aa; adding to cc

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

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

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

Bug ID: 111360
   Summary: contrib/gcc_update: bad test
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
  Target Milestone: ---

Running contrib/gcc_update on the gcc111 machine on the compile farm includes
the following message in its output:

./contrib/gcc_update[346]: test: argument expected

The line in question has:

if test -n $r; then

Shouldn't the "${r}" be quoted or something? Or maybe the issue is actually
that the command to set it on the previous lines is failing; it's set like
this:

# Open-coded version of "git gcc-descr" from
contrib/gcc-git-customization.sh
revision=`$GCC_GIT log -n1 --pretty=tformat:%h`
r=`$GCC_GIT describe --all --match 'basepoints/gcc-[0-9]*' HEAD \
   | sed -n
's,^\(tags/\)\?basepoints/gcc-\([0-9]\+\)-\([0-9]\+\)-g[0-9a-f]*$,r\2-\3,p;s,^\(tags/\)\?basepoints/gcc-\([0-9]\+\)$,r\2-0,p'`;

[Bug other/17239] gcc_update not being writable while it is running

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
patch in question references CVS; is it still relevant now that gcc has
migrated to git?

[Bug other/111359] contrib/gcc-git-customization.sh uses getent, which is non-portable

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||rearnsha at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
git blame says Richard Earnshaw added the line in r10-6003-g545f5fad17ff0d;
adding to cc

[Bug other/111359] New: contrib/gcc-git-customization.sh uses getent, which is non-portable

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

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

Bug ID: 111359
   Summary: contrib/gcc-git-customization.sh uses getent, which is
non-portable
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
  Target Milestone: ---

On both darwin and AIX, running contrib/gcc-git-customization.sh will print
messages like this:

contrib/gcc-git-customization.sh[49]: getent:  not found.

Running `which getent` confirms:

which: 0652-141 There is no getent in /usr/bin /etc /usr/sbin /usr/ucb
/home/egallager/bin /usr/bin/X11 /sbin ..

Suggest switching to a different sort of test when getent isn't available.

[Bug c++/111300] Modules error: mangling of [lambda] conflicts with previous mangle

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

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

--- Comment #7 from Jonathan Wakely  ---
Given the note, maybe this is an intentional error to avoid creating a compiled
module interface that might not be usable:

note: a later '-fabi-version=' (or =0) avoids this error with a change in
mangling

But since a compiled module can't be used with different versions of the
compiler or even with different flags, I'm not sure how any conflict can
happen.

[Bug c++/111300] Modules error: mangling of [lambda] conflicts with previous mangle

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[14 Regression] |Modules error: mangling of
   |g++.dg/modules/xtreme-heade |[lambda] conflicts with
   |r_b.C   |previous mangle

--- Comment #6 from Jonathan Wakely  ---
(In reply to Hans-Peter Nilsson from comment #4)
> So, keeping this PR open is TRT?

Yes, I think so.

> Should the title then change to reflect a description of the latent error?

I've changed it to something that I think is more descriptive.

I didn't mention the library header name, because the version of the header on
trunk doesn't reveal it now. I haven't succeeded in reducing the error yet.

[Bug libstdc++/111358] libstdc++'s optional::and_then and optional::transform are not ADL-proof

[de34 at live dot cn via Gcc-bugs]

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

--- Comment #1 from Jiang An  ---
Related issues:

Monadic operations of expected are not ADL-proof per the uses of **this in
[expected.object.monadic]. However, currently implementations make them
ADL-proof by directly naming the union member, which is right IMO.

P2407R5 (https://wg21.link/p2407r5) is changing value() to **this in
[optional.monadic], which makes the monadic operations of optional not
ADL-proof. I believe this is a mistake.

I've mailed to LWG Chair to submit an LWG issue for these issues.

[Bug libstdc++/111358] New: libstdc++'s optional::and_then and optional::transform are not ADL-proof

[de34 at live dot cn via Gcc-bugs]

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

Bug ID: 111358
   Summary: libstdc++'s optional::and_then and optional::transform
are not ADL-proof
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: de34 at live dot cn
  Target Milestone: ---

The following program is incorrectly rejected when using libstdc++
(https://godbolt.org/z/eavTYjEdx):
```
#include 

namespace fvs {
struct Foo {};

void operator*(std::optional) = delete;
}

int main()
{
std::optional{}.and_then(
[](auto&&){ return std::optional{}; });
std::optional{}.transform(
[](auto&&){ return 0; });
}
```

The reason of compilation error is that libstdc++ uses **this in and_then and
transform functions, which triggers ADL and finds unwanted operator*().

These monadic operations are currently specified in [optional.monadic] with
value(), so they should be ADL-proof.

[C PATCH 1/6 v2] c: reorganize recursive type checking

[Martin Uecker via Gcc-patches]

Thanks Joseph, below is a a revised version of this patch
with slight additional changes to the comment of
tagged_types_tu_compatible_p.

ok for trunk? 

Martin

Am Mittwoch, dem 06.09.2023 um 20:59 + schrieb Joseph Myers:
> On Sat, 26 Aug 2023, Martin Uecker via Gcc-patches wrote:
> 
> > -static int
> > +static bool
> >  comp_target_types (location_t location, tree ttl, tree ttr)
> 
> The comment above this function should be updated to refer to returning 
> true, not to returning 1.  And other comments on common_pointer_type and 
> inside that function should be updated to refer to comp_target_types 
> returning true, not nonzero.
> 
> > @@ -1395,17 +1382,13 @@ free_all_tagged_tu_seen_up_to (const struct 
> > tagged_tu_seen_cache *tu_til)
> >  
> >  /* Return 1 if two 'struct', 'union', or 'enum' types T1 and T2 are
> > compatible.  If the two types are not the same (which has been
> > -   checked earlier), this can only happen when multiple translation
> > -   units are being compiled.  See C99 6.2.7 paragraph 1 for the exact
> > -   rules.  ENUM_AND_INT_P and DIFFERENT_TYPES_P are as in
> > -   comptypes_internal.  */
> > +   checked earlier).  */
> >  
> > -static int
> > +static bool
> >  tagged_types_tu_compatible_p (const_tree t1, const_tree t2,
> > - bool *enum_and_int_p, bool *different_types_p)
> > + struct comptypes_data* data)
> 
> Similarly, this comment should be updated for the new return type.  Also 
> the GNU style is "struct comptypes_data *data" with space before not after 
> '*'.
> 
> > @@ -1631,9 +1603,9 @@ tagged_types_tu_compatible_p (const_tree t1, 
> > const_tree t2,
> > Otherwise, the argument types must match.
> > ENUM_AND_INT_P and DIFFERENT_TYPES_P are as in comptypes_internal.  */
> >  
> > -static int
> > +static bool
> >  function_types_compatible_p (const_tree f1, const_tree f2,
> > -bool *enum_and_int_p, bool *different_types_p)
> > +struct comptypes_data *data)
> 
> Another comment to update for a changed return type.
> 
> >  /* Check two lists of types for compatibility, returning 0 for
> > -   incompatible, 1 for compatible, or 2 for compatible with
> > -   warning.  ENUM_AND_INT_P and DIFFERENT_TYPES_P are as in
> > -   comptypes_internal.  */
> > +   incompatible, 1 for compatible.  ENUM_AND_INT_P and
> > +   DIFFERENT_TYPES_P are as in comptypes_internal.  */
> >  
> > -static int
> > +static bool
> >  type_lists_compatible_p (const_tree args1, const_tree args2,
> > -bool *enum_and_int_p, bool *different_types_p)
> > +struct comptypes_data *data)
> 
> This one also needs updating to remove references to parameters that no 
> longer exist.
> 

c: reorganize recursive type checking

Reorganize recursive type checking to use a structure to
store information collected during the recursion and
returned to the caller (warning_needed, enum_and_init_p,
different_types_p).

gcc/c:
* c-typeck.cc (struct comptypes_data): Add structure.
(tagged_types_tu_compatible_p,
function_types_compatible_p, type_lists_compatible_p,
comptypes_internal): Add structure to interface, change
return type to bool, and adapt calls.
(comptarget_types): Change return type too bool.
(comptypes, comptypes_check_enum_int,
comptypes_check_different_types): Adapt calls.
---
 gcc/c/c-typeck.cc | 282 --
 1 file changed, 121 insertions(+), 161 deletions(-)

diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index e2bfd2caf85..e55e887da14 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -90,12 +90,14 @@ static bool require_constant_elements;
 static bool require_constexpr_value;
 
 static tree qualify_type (tree, tree);
-static int tagged_types_tu_compatible_p (const_tree, const_tree, bool *,
-bool *);
-static int comp_target_types (location_t, tree, tree);
-static int function_types_compatible_p (const_tree, const_tree, bool *,
-   bool *);
-static int type_lists_compatible_p (const_tree, const_tree, bool *, bool *);
+struct comptypes_data;
+static bool tagged_types_tu_compatible_p (const_tree, const_tree,
+ struct comptypes_data *);
+static bool comp_target_types (location_t, tree, tree);
+static bool function_types_compatible_p (const_tree, const_tree,
+struct comptypes_data *);
+static bool type_lists_compatible_p (const_tree, const_tree,
+struct comptypes_data *);
 static tree lookup_field (tree, tree);
 static int convert_arguments (location_t, vec, tree,
  vec *, vec *, tree,
@@ -125,7 +127,8 @@ static tree find_init_member (tree, struct obstack *);
 static void readonly_warning (tree, enum lvalue_use);
 static int 

[Bug c++/111356] Segmentation fault when compiling large static data structure

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

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

--- Comment #4 from Xi Ruoyao  ---
BTW it works with 13.2.0 with "ulimit -s 131072" too, so it's a stack usage
issue.

[Bug c++/111356] Segmentation fault when compiling large static data structure

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org
  Known to work||14.0
   Keywords||needs-bisection
  Known to fail||13.2.0

--- Comment #3 from Xi Ruoyao  ---
Fails for me with 13.2.  Maybe a duplicate of a PR fixed in trunk.

[Bug tree-optimization/110068] missing min detection

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
   Last reconfirmed||2023-09-10
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Mine.

I think I know how to fix this ...

minmax_from_comparison needs to pass the sign of what the exp0/exp1 are being
compared in.

Note I think we have other issues too ...

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

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

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

--- Comment #30 from Eric Gallager  ---
(In reply to matoro from comment #26)
> We also had somebody report on IRC that they observed this on powerpc (not
> sure what tuple), again with -j1.  It does not seem to show up with -j2, so
> likely -j1 is necessary to trigger.

I can also confirm that switching to -j2 makes this particular error go away

[Bug go/90685] failure of go in gcc-9.1.0 to build in i686-pc-linux-gnu

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

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

--- Comment #4 from Eric Gallager  ---
(In reply to Eric Gallager from comment #3)
> (In reply to Eric Gallager from comment #2)
> > I just got a similar error on gcc13 on the compile farm; config.guess there
> > reports:
> > 
> > $ ../config.guess
> > x86_64-pc-linux-gnu
> > 
> > So, confirmed.
> 
> Oops wait make that gcc14, not gcc13 (since there isn't even any machine
> called gcc13 on the compile farm in the first place)

Also happens on the machine called "gcc45" on the compile farm, where
../config.guess reports i686-pc-linux-gnu

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

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

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||egallager at gcc dot gnu.org

--- Comment #29 from Eric Gallager  ---
just ran into this on the machine called "gcc45" on the compile farm with a
single-job build; confirming
(it's an i686-pc-linux-gnu machine)