[PATCH] lower-bitint: Fix up maximum addition/subtraction/multiplication result computations

[Jakub Jelinek]

Hi!

When debugging PR112750, I've noticed some issues in the computation
of precisions and the following patch attempts to fix those.

The pass uses range_to_prec function, which possibly using ranger returns
minimum precision of some operand in the style that libgcc _BitInt
entrypoints expect, i.e. for operands with unsigned types either the
precision of that type or with help of ranger
wi::min_precision (upper_bound, UNSIGNED) (done both if the types
are really unsigned or even when lower_bound is non-negative), while
for operands with signed types either negated precision of that type or
with help of ranger negated value of maximum of SIGNED min_precisions
of lower and upper bound.
Because _BitInt in C only supports unsigned precisions >= 1 and signed
precisions >= 2, the function also ensures that 0 is never returned (returns
1 instead) and should ensure that -1 is never returned (should return -2).
That is the first bug I found though, for the ranger case it ensured that,
but if an operand would be signed 1-bit precision (that means
non-BITINT_TYPE) operand, it could return -1.

Another thing is that both lower_addsub_overflow and lower_mul_overflow
compute from the prec0 and prec1 of the operands (returned by range_to_prec
with the above value meanings) prec2, which is how many bits of the result
we actually need to compute to know the infinite precision result.
This is then used by arith_overflow function together with prec
(TYPE_PRECISION (type)), type (type of the result), prec0 and prec1 to
compute which range of bits should be tested (if any, or that there is never
an overflow) and with which kind (require those bits to be zero vs.
check if all those bits together all all zeros/ones).
The arith_overflow function has one special case, when
prec0 >= 0 && prec1 >= 0 and operation is not .SUB_OVERFLOW; in that case
we treat prec2 as minimum precision to express any infinite precision
unsigned result (the result is never negative in that case), while
in all other cases prec2 is treated as minimum precision to express
any infinite precision signed result (because the result can be also
negative).
The computations of those values were apparently incorrect for all of
.{ADD,SUB}_OVERFLOW (in that case only if one operand was signed and
the other unsigned) and for .MUL_OVERFLOW it was sometimes too large.

It took me a while to get to the right expression how to compute that,
I've started with writing into the comment the possible results for
different prec0 and prec1 values (used just 8/-8/10/-10 as placeholders
for equal or different absolute values of the 2 precisions and cases
with positive and/or negative signs) and then turned into the attached
test program that actually printed what I was writing to make sure
I didn't make mistakes in it and in the end also verified the computation,
this time for all combinations of 1..14 and -2..-14 precisions.
The UNSIGNED vs. SIGNED in the table is what arith_overflow expects
the prec2 to be (see above mentioned exception).

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

2023-12-01  Jakub Jelinek  

* gimple-lower-bitint.cc (range_to_prec): Don't return -1 for
signed types.
(bitint_large_huge::lower_addsub_overflow): Fix up computation of
prec2.
(bitint_large_huge::lower_mul_overflow): Likewise.

--- gcc/gimple-lower-bitint.cc.jj   2023-11-30 12:46:34.715093396 +0100
+++ gcc/gimple-lower-bitint.cc  2023-11-30 17:24:59.828026693 +0100
@@ -1963,7 +1963,7 @@ range_to_prec (tree op, gimple *stmt)
   if (TYPE_UNSIGNED (type))
return prec;
   else
-   return -prec;
+   return MIN ((int) -prec, -2);
 }
 
   if (!TYPE_UNSIGNED (TREE_TYPE (op)))
@@ -3792,11 +3792,45 @@ bitint_large_huge::lower_addsub_overflow
   int prec = TYPE_PRECISION (type);
   int prec0 = range_to_prec (arg0, stmt);
   int prec1 = range_to_prec (arg1, stmt);
-  int prec2 = ((prec0 < 0) == (prec1 < 0)
-  ? MAX (prec0 < 0 ? -prec0 : prec0,
- prec1 < 0 ? -prec1 : prec1) + 1
-  : MAX (prec0 < 0 ? -prec0 : prec0 + 1,
- prec1 < 0 ? -prec1 : prec1 + 1) + 1);
+  /* If PREC0 >= 0 && PREC1 >= 0 and CODE is not MINUS_EXPR, PREC2 is
+ the be minimum unsigned precision of any possible operation's
+ result, otherwise it is minimum signed precision.
+ Some examples:
+ If PREC0 or PREC1 is 8, it means that argument is [0, 0xff],
+ if PREC0 or PREC1 is 10, it means that argument is [0, 0x3ff],
+ if PREC0 or PREC1 is -8, it means that argument is [-0x80, 0x7f],
+ if PREC0 or PREC1 is -10, it means that argument is [-0x200, 0x1ff].
+ PREC0  CODE  PREC1  RESULT  PREC2  SIGNED vs. UNSIGNED
+   8  + 8[0, 0x1fe]9UNSIGNED
+   8  +10[0, 0x4fe]   11UNSIGNED
+  -8  +-8[-0x100, 0xfe]9SIGNED
+  -8  +   -10[-0x280, 0x27e]  11SIGNED
+   8 

Re: [PATCH] lower-bitint: Fix ICE on bitint-39.c

[Richard Biener]

On Fri, 1 Dec 2023, Jakub Jelinek wrote:

> Hi!
> 
> torture/bitint-39.c ICEs with -O1; the problem is that the
> finish_arith_overflow code in one spot replaces use_stmt with an
> assignment or cast, but if unlucky and m_gsi iterator is the same statement,
> when the code later
>   tree clobber = build_clobber (TREE_TYPE (var), CLOBBER_EOL);
>   g = gimple_build_assign (var, clobber);
>   gsi_insert_after (_gsi, g, GSI_SAME_STMT);
> it will insert after iterator which contains already replaced statement and
> that causes the gimple chain corruption.
> 
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
> for trunk?

OK.

> 2023-12-01  Jakub Jelinek  
> 
>   * gimple-lower-bitint.cc (bitint_large_huge::finish_arith_overflow):
>   When replacing use_stmt which is gsi_stmt (m_gsi), update m_gsi to
>   the new statement.
> 
> --- gcc/gimple-lower-bitint.cc.jj 2023-11-30 10:57:40.09940 +0100
> +++ gcc/gimple-lower-bitint.cc2023-11-30 12:46:34.715093396 +0100
> @@ -3682,6 +3682,8 @@ bitint_large_huge::finish_arith_overflow
> else
>   g = gimple_build_assign (lhs2, NOP_EXPR, ovf);
> gsi_replace (, g, true);
> +   if (gsi_stmt (m_gsi) == use_stmt)
> + m_gsi = gsi_for_stmt (g);
> break;
>   }
>   }
> 
>   Jakub
> 
> 

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

Re: [PATCH] lower-bitint: Fix _BitInt .{ADD,SUB}_OVERFLOW lowering [PR112750]

[Richard Biener]

On Fri, 1 Dec 2023, Jakub Jelinek wrote:

> Hi!
> 
> The .{ADD,SUB}_OVERFLOW lowering is implemented by performing normal
> addition/subtraction (perhaps extended to even more bits than normally by
> continuing with extended values of operands after running of normal bits)
> and in addition to that trying to compute if certain sets of bits are either
> all zero or all sign extensions of the least significant bit.
> 
> That code is in a lot of cases guarded just by a single condition (which
> can be idx > startlimb, idx >= startlimb or idx == startlimb) or by
> 2 conditions - if (idx >= startlimb) { if (idx == startlimb) ... else ... }
> Now, if_then_if_then_else when the second argument is NULL works just as
> if_then and sets m_gsi to be within the initially empty then block and that is
> where we emit code for constant tidx startlimb + (cmp_code == GT_EXPR).
> But in the 2 conditions case, m_gsi is set to the initially empty else
> block, so using EQ_EXPR for the condition was incorrect (and strangely
> nothing in the testsuite caught that), because the code for extracting the
> lowest set of bits (i.e. when tidx is startlimb) is then done when idx
> is not startlimb rather than when it is.
> The following patch fixes that.
> 
> Note, when developing the lowering, I was using gcov to make sure all code
> is covered by the testsuite with minimum exceptions, so no idea how this
> slipped out.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Richard.

> 2023-12-01  Jakub Jelinek  
> 
>   PR middle-end/112750
>   * gimple-lower-bitint.cc (bitint_large_huge::lower_addsub_overflow):
>   Use NE_EXPR rather than EQ_EXPR for g2 if !single_comparison and
>   adjust probabilities.
> 
>   * gcc.dg/bitint-41.c: Use -std=c23 rather than -std=c2x.
>   * gcc.dg/torture/bitint-43.c: Likewise.
>   * gcc.dg/torture/bitint-44.c: Likewise.
>   * gcc.dg/torture/bitint-45.c: New test.
> 
> --- gcc/gimple-lower-bitint.cc.jj 2023-11-24 11:30:24.416427246 +0100
> +++ gcc/gimple-lower-bitint.cc2023-11-30 10:57:40.09940 +0100
> @@ -4028,11 +4028,11 @@ bitint_large_huge::lower_addsub_overflow
> edge edge_true_true, edge_true_false, edge_false;
> gimple *g2 = NULL;
> if (!single_comparison)
> - g2 = gimple_build_cond (EQ_EXPR, idx,
> + g2 = gimple_build_cond (NE_EXPR, idx,
>   size_int (startlimb), NULL_TREE,
>   NULL_TREE);
> if_then_if_then_else (g, g2, profile_probability::likely (),
> - profile_probability::unlikely (),
> + profile_probability::likely (),
>   edge_true_true, edge_true_false,
>   edge_false);
> unsigned tidx = startlimb + (cmp_code == GT_EXPR);
> --- gcc/testsuite/gcc.dg/bitint-41.c.jj   2023-11-23 12:59:48.027443972 
> +0100
> +++ gcc/testsuite/gcc.dg/bitint-41.c  2023-11-30 11:05:54.956550967 +0100
> @@ -1,6 +1,6 @@
>  /* PR middle-end/112336 */
>  /* { dg-do compile { target bitint } } */
> -/* { dg-options "-std=c2x" } */
> +/* { dg-options "-std=c23" } */
>  
>  unsigned _BitInt(1) v1;
>  unsigned _BitInt(1) *p1 = 
> --- gcc/testsuite/gcc.dg/torture/bitint-43.c.jj   2023-11-20 
> 09:49:35.236668167 +0100
> +++ gcc/testsuite/gcc.dg/torture/bitint-43.c  2023-11-30 11:06:31.840028866 
> +0100
> @@ -1,6 +1,6 @@
>  /* PR c/111309 */
>  /* { dg-do run { target bitint } } */
> -/* { dg-options "-std=c2x -pedantic-errors" } */
> +/* { dg-options "-std=c23 -pedantic-errors" } */
>  /* { dg-skip-if "" { ! run_expensive_tests }  { "*" } { "-O0" "-O2" } } */
>  /* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */
>  
> --- gcc/testsuite/gcc.dg/torture/bitint-44.c.jj   2023-11-14 
> 10:52:16.192276014 +0100
> +++ gcc/testsuite/gcc.dg/torture/bitint-44.c  2023-11-30 11:06:37.494948817 
> +0100
> @@ -1,6 +1,6 @@
>  /* PR c/111309 */
>  /* { dg-do run { target bitint } } */
> -/* { dg-options "-std=c2x -pedantic-errors" } */
> +/* { dg-options "-std=c23 -pedantic-errors" } */
>  /* { dg-skip-if "" { ! run_expensive_tests }  { "*" } { "-O0" "-O2" } } */
>  /* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */
>  
> --- gcc/testsuite/gcc.dg/torture/bitint-45.c.jj   2023-11-30 
> 11:07:40.778053018 +0100
> +++ gcc/testsuite/gcc.dg/torture/bitint-45.c  2023-11-30 11:07:19.294357123 
> +0100
> @@ -0,0 +1,32 @@
> +/* PR middle-end/112750 */
> +/* { dg-do run { target bitint } } */
> +/* { dg-options "-std=c23 -pedantic-errors" } */
> +/* { dg-skip-if "" { ! run_expensive_tests }  { "*" } { "-O0" "-O2" } } */
> +/* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */
> +
> +#if __BITINT_MAXWIDTH__ >= 256
> +_BitInt(256) a = __INT_MAX__ + (_BitInt(256)) 1;
> 

[PATCH v2] RISC-V: Bugfix for legitimize move when get vec mode in zve32f

[pan2 . li]

From: Pan Li 

If we want to extract 64bit value but ELEN < 64, we use RVV
vector mode with EEW = 32 to extract the highpart and lowpart.
However, this approach doesn't honor DFmode when movdf pattern
when ZVE32f and of course results in ICE when zve32f.

This patch would like to reuse the approach with some additional
handing, consider lowpart bits is meaningless for FP mode, we need
one int reg as bridge here. For example:

rtx tmp = gen_rtx_reg (DImode)
reg:DI = reg:DF (fmv.d.x) // Move DF reg to DI
...
perform the extract for high and low parts
...
reg:DF = reg:DI (fmv.x.d) // Move DI reg back to DF after all done

PR target/112743

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_legitimize_move): Take the
exist (U *mode) and handle DFmode like DImode when EEW is
32bits like ZVE32F.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr112743-2.c: New test.

Signed-off-by: Pan Li 
---
 gcc/config/riscv/riscv.cc | 67 +--
 .../gcc.target/riscv/rvv/base/pr112743-2.c| 52 ++
 2 files changed, 99 insertions(+), 20 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112743-2.c

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index a4fc858fb50..996347ee3fd 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -2605,41 +2605,68 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx 
src)
   unsigned int nunits = vmode_size > mode_size ? vmode_size / mode_size : 
1;
   scalar_mode smode = as_a (mode);
   unsigned int index = SUBREG_BYTE (src).to_constant () / mode_size;
-  unsigned int num = smode == DImode && !TARGET_VECTOR_ELEN_64 ? 2 : 1;
+  unsigned int num = (smode == DImode || smode == DFmode)
+   && !TARGET_VECTOR_ELEN_64 ? 2 : 1;
+  bool need_int_reg_p = false;
 
   if (num == 2)
{
  /* If we want to extract 64bit value but ELEN < 64,
 we use RVV vector mode with EEW = 32 to extract
 the highpart and lowpart.  */
+ need_int_reg_p = smode == DFmode;
  smode = SImode;
  nunits = nunits * 2;
}
-  vmode = riscv_vector::get_vector_mode (smode, nunits).require ();
-  rtx v = gen_lowpart (vmode, SUBREG_REG (src));
 
-  for (unsigned int i = 0; i < num; i++)
+  opt_machine_mode opt_mode = riscv_vector::get_vector_mode (smode, 
nunits);
+
+  if (opt_mode.exists ())
{
- rtx result;
- if (num == 1)
-   result = dest;
- else if (i == 0)
-   result = gen_lowpart (smode, dest);
- else
-   result = gen_reg_rtx (smode);
- riscv_vector::emit_vec_extract (result, v, index + i);
+ rtx v = gen_lowpart (vmode, SUBREG_REG (src));
+ rtx int_reg = dest;
 
- if (i == 1)
+ if (need_int_reg_p)
{
- rtx tmp
-   = expand_binop (Pmode, ashl_optab, gen_lowpart (Pmode, result),
-   gen_int_mode (32, Pmode), NULL_RTX, 0,
-   OPTAB_DIRECT);
- rtx tmp2 = expand_binop (Pmode, ior_optab, tmp, dest, NULL_RTX, 0,
-  OPTAB_DIRECT);
- emit_move_insn (dest, tmp2);
+ int_reg = gen_reg_rtx (DImode);
+ emit_insn (
+   gen_movdi (int_reg, gen_lowpart (GET_MODE (int_reg), dest)));
+   }
+
+ for (unsigned int i = 0; i < num; i++)
+   {
+ rtx result;
+ if (num == 1)
+   result = int_reg;
+ else if (i == 0)
+   result = gen_lowpart (smode, int_reg);
+ else
+   result = gen_reg_rtx (smode);
+
+ riscv_vector::emit_vec_extract (result, v, index + i);
+
+ if (i == 1)
+   {
+ rtx tmp = expand_binop (Pmode, ashl_optab,
+ gen_lowpart (Pmode, result),
+ gen_int_mode (32, Pmode), NULL_RTX, 0,
+ OPTAB_DIRECT);
+ rtx tmp2 = expand_binop (Pmode, ior_optab, tmp, int_reg,
+  NULL_RTX, 0,
+  OPTAB_DIRECT);
+ emit_move_insn (int_reg, tmp2);
+   }
}
+
+ if (need_int_reg_p)
+   emit_insn (
+ gen_movdf (dest, gen_lowpart (GET_MODE (dest), int_reg)));
+ else
+   emit_move_insn (dest, int_reg);
}
+  else
+   gcc_unreachable ();
+
   return true;
 }
   /* Expand
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/base/pr112743-2.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112743-2.c
new file mode 100644
index 000..fdb35fd70f2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/base/pr112743-2.c
@@ -0,0 +1,52 @@
+/* Test that 

[PATCH v2 2/3] libphobos: Update build scripts for LoongArch64.

[Yang Yujie]

libphobos/ChangeLog:

* m4/druntime/cpu.m4: Support loongarch* targets.
* libdruntime/Makefile.am: Same.
* libdruntime/Makefile.in: Regenerate.
* configure: Regenerate.
---
 libphobos/configure   | 21 ++-
 libphobos/libdruntime/Makefile.am |  3 +
 libphobos/libdruntime/Makefile.in | 98 +++
 libphobos/m4/druntime/cpu.m4  |  5 ++
 4 files changed, 87 insertions(+), 40 deletions(-)

diff --git a/libphobos/configure b/libphobos/configure
index 25b13bdd93e..9a59bad34ac 100755
--- a/libphobos/configure
+++ b/libphobos/configure
@@ -696,6 +696,8 @@ DRUNTIME_CPU_POWERPC_FALSE
 DRUNTIME_CPU_POWERPC_TRUE
 DRUNTIME_CPU_MIPS_FALSE
 DRUNTIME_CPU_MIPS_TRUE
+DRUNTIME_CPU_LOONGARCH_FALSE
+DRUNTIME_CPU_LOONGARCH_TRUE
 DRUNTIME_CPU_ARM_FALSE
 DRUNTIME_CPU_ARM_TRUE
 DRUNTIME_CPU_AARCH64_FALSE
@@ -11865,7 +11867,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11868 "configure"
+#line 11870 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11971,7 +11973,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11974 "configure"
+#line 11976 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -14305,6 +14307,9 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
;;
   arm*)druntime_target_cpu_parsed="arm"
;;
+  loongarch*)
+   druntime_target_cpu_parsed="loongarch"
+   ;;
   mips*)   druntime_target_cpu_parsed="mips"
;;
   powerpc*)
@@ -14336,6 +14341,14 @@ else
   DRUNTIME_CPU_ARM_FALSE=
 fi
 
+   if test "$druntime_target_cpu_parsed" = "loongarch"; then
+  DRUNTIME_CPU_LOONGARCH_TRUE=
+  DRUNTIME_CPU_LOONGARCH_FALSE='#'
+else
+  DRUNTIME_CPU_LOONGARCH_TRUE='#'
+  DRUNTIME_CPU_LOONGARCH_FALSE=
+fi
+
if test "$druntime_target_cpu_parsed" = "mips"; then
   DRUNTIME_CPU_MIPS_TRUE=
   DRUNTIME_CPU_MIPS_FALSE='#'
@@ -15997,6 +16010,10 @@ if test -z "${DRUNTIME_CPU_ARM_TRUE}" && test -z 
"${DRUNTIME_CPU_ARM_FALSE}"; th
   as_fn_error $? "conditional \"DRUNTIME_CPU_ARM\" was never defined.
 Usually this means the macro was only invoked conditionally." "$LINENO" 5
 fi
+if test -z "${DRUNTIME_CPU_LOONGARCH_TRUE}" && test -z 
"${DRUNTIME_CPU_LOONGARCH_FALSE}"; then
+  as_fn_error $? "conditional \"DRUNTIME_CPU_LOONGARCH\" was never defined.
+Usually this means the macro was only invoked conditionally." "$LINENO" 5
+fi
 if test -z "${DRUNTIME_CPU_MIPS_TRUE}" && test -z 
"${DRUNTIME_CPU_MIPS_FALSE}"; then
   as_fn_error $? "conditional \"DRUNTIME_CPU_MIPS\" was never defined.
 Usually this means the macro was only invoked conditionally." "$LINENO" 5
diff --git a/libphobos/libdruntime/Makefile.am 
b/libphobos/libdruntime/Makefile.am
index 23205fd3301..ca43a0753c4 100644
--- a/libphobos/libdruntime/Makefile.am
+++ b/libphobos/libdruntime/Makefile.am
@@ -83,6 +83,9 @@ endif
 if DRUNTIME_CPU_ARM
 DRUNTIME_SOURCES_CONFIGURED += config/arm/switchcontext.S
 endif
+if DRUNTIME_CPU_LOONGARCH
+DRUNTIME_SOURCES_CONFIGURED += config/loongarch/switchcontext.S
+endif
 if DRUNTIME_CPU_MIPS
 DRUNTIME_SOURCES_CONFIGURED += config/mips/switchcontext.S
 endif
diff --git a/libphobos/libdruntime/Makefile.in 
b/libphobos/libdruntime/Makefile.in
index 410245d71ca..f52bf36c282 100644
--- a/libphobos/libdruntime/Makefile.in
+++ b/libphobos/libdruntime/Makefile.in
@@ -124,12 +124,13 @@ target_triplet = @target@
 # CPU specific sources
 @DRUNTIME_CPU_AARCH64_TRUE@am__append_11 = config/aarch64/switchcontext.S
 @DRUNTIME_CPU_ARM_TRUE@am__append_12 = config/arm/switchcontext.S
-@DRUNTIME_CPU_MIPS_TRUE@am__append_13 = config/mips/switchcontext.S
-@DRUNTIME_CPU_POWERPC_TRUE@am__append_14 = config/powerpc/switchcontext.S
-@DRUNTIME_CPU_X86_TRUE@@DRUNTIME_OS_MINGW_TRUE@am__append_15 = 
config/mingw/switchcontext.S
-@DRUNTIME_CPU_X86_TRUE@@DRUNTIME_OS_MINGW_FALSE@am__append_16 = 
config/x86/switchcontext.S
-@DRUNTIME_CPU_SYSTEMZ_TRUE@am__append_17 = config/systemz/get_tls_offset.S
-@DRUNTIME_CPU_S390_TRUE@am__append_18 = config/s390/get_tls_offset.S
+@DRUNTIME_CPU_LOONGARCH_TRUE@am__append_13 = config/loongarch/switchcontext.S
+@DRUNTIME_CPU_MIPS_TRUE@am__append_14 = config/mips/switchcontext.S
+@DRUNTIME_CPU_POWERPC_TRUE@am__append_15 = config/powerpc/switchcontext.S
+@DRUNTIME_CPU_X86_TRUE@@DRUNTIME_OS_MINGW_TRUE@am__append_16 = 
config/mingw/switchcontext.S
+@DRUNTIME_CPU_X86_TRUE@@DRUNTIME_OS_MINGW_FALSE@am__append_17 = 
config/x86/switchcontext.S
+@DRUNTIME_CPU_SYSTEMZ_TRUE@am__append_18 = config/systemz/get_tls_offset.S
+@DRUNTIME_CPU_S390_TRUE@am__append_19 = config/s390/get_tls_offset.S
 subdir = libdruntime
 ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
 am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \
@@ -485,46 +486,50 @@ am__objects_23 = core/sys/solaris/dlfcn.lo 
core/sys/solaris/elf.lo \
 

[PATCH v2 0/3] LoongArch D support

[Yang Yujie]

This patchset is based on Zixing Liu's initial support patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631260.html

Update v1 -> v2:
Rebased onto the dmd/druntime upstream state.

Regtested on loongarch64-linux-gnu with the following result:

=== libphobos Summary ===

FAIL: libphobos.config/test22523.d -- --DRT-testmode=run-main execution test
FAIL: libphobos.gc/precisegc.d execution test
FAIL: libphobos.phobos/std/datetime/systime.d (test for excess errors)
UNRESOLVED: libphobos.phobos/std/datetime/systime.d compilation failed to 
produce executable
UNSUPPORTED: libphobos.phobos/std/net/curl.d: skipped test
UNSUPPORTED: libphobos.phobos_shared/std/net/curl.d: skipped test
FAIL: libphobos.shared/loadDR.c -ldl -pthread -g execution test (out-of-tree 
testing)

# of expected passes1024
# of unexpected failures4
# of unresolved testcases   1
# of unsupported tests  2

=== gdc Summary ===

FAIL: gdc.test/runnable/testaa.d   execution test
FAIL: gdc.test/runnable/testaa.d -fPIC   execution test

# of expected passes10353
# of unexpected failures2
# of unsupported tests  631


Yang Yujie (3):
  LoongArch: Adjust D version strings.
  libphobos: Update build scripts for LoongArch64.
  libphobos: LoongArch hardware support.

 gcc/config/loongarch/loongarch-d.cc   |  27 ++--
 gcc/d/dmd/cond.d  |   6 +-
 gcc/d/implement-d.texi|   6 +
 libphobos/configure   |  21 ++-
 libphobos/libdruntime/Makefile.am |   3 +
 libphobos/libdruntime/Makefile.in |  98 -
 .../config/loongarch/switchcontext.S  | 133 ++
 libphobos/m4/druntime/cpu.m4  |   5 +
 libphobos/src/std/math/hardware.d |  53 +++
 9 files changed, 296 insertions(+), 56 deletions(-)
 create mode 100644 libphobos/libdruntime/config/loongarch/switchcontext.S

-- 
2.20.1

[PATCH v2 3/3] libphobos: LoongArch hardware support.

[Yang Yujie]

libphobos/ChangeLog:

* src/std/math/hardware.d: Implement FP control.
* libdruntime/config/loongarch/switchcontext.S: New file.
---
 .../config/loongarch/switchcontext.S  | 133 ++
 libphobos/src/std/math/hardware.d |  53 +++
 2 files changed, 186 insertions(+)
 create mode 100644 libphobos/libdruntime/config/loongarch/switchcontext.S

diff --git a/libphobos/libdruntime/config/loongarch/switchcontext.S 
b/libphobos/libdruntime/config/loongarch/switchcontext.S
new file mode 100644
index 000..edfb9b67e8f
--- /dev/null
+++ b/libphobos/libdruntime/config/loongarch/switchcontext.S
@@ -0,0 +1,133 @@
+/* LoongArch support code for fibers and multithreading.
+   Copyright (C) 2023 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+.  */
+
+#include "../common/threadasm.S"
+
+/**
+ * Performs a context switch.
+ *
+ * $a0 - void** - ptr to old stack pointer
+ * $a1 - void*  - new stack pointer
+ *
+ */
+
+#if defined(__loongarch_lp64)
+#  define GPR_L ld.d
+#  define GPR_S st.d
+#  define SZ_GPR 8
+#  define ADDSP(si)   addi.d  $sp, $sp, si
+#elif defined(__loongarch64_ilp32)
+#  define GPR_L ld.w
+#  define GPR_S st.w
+#  define SZ_GPR 4
+#  define ADDSP(si)   addi.w  $sp, $sp, si
+#else
+#  error Unsupported GPR size (must be 64-bit or 32-bit).
+#endif
+
+#if defined(__loongarch_double_float)
+#  define FPR_L fld.d
+#  define FPR_S fst.d
+#  define SZ_FPR 8
+#elif defined(__loongarch_single_float)
+#  define FPR_L fld.s
+#  define FPR_S fst.s
+#  define SZ_FPR 4
+#else
+#  define SZ_FPR 0
+#endif
+
+.text
+.align 2
+.global fiber_switchContext
+.type   fiber_switchContext, @function
+fiber_switchContext:
+.cfi_startproc
+ADDSP(-11 * SZ_GPR)
+
+// fp regs and return address are stored below the stack
+// because we don't want the GC to scan them.
+
+// return address (r1)
+GPR_S  $r1, $sp, -SZ_GPR
+
+#if SZ_FPR != 0
+// callee-saved scratch FPRs (f24-f31)
+FPR_S  $f24, $sp, -SZ_GPR-1*SZ_FPR
+FPR_S  $f25, $sp, -SZ_GPR-2*SZ_FPR
+FPR_S  $f26, $sp, -SZ_GPR-3*SZ_FPR
+FPR_S  $f27, $sp, -SZ_GPR-4*SZ_FPR
+FPR_S  $f28, $sp, -SZ_GPR-5*SZ_FPR
+FPR_S  $f29, $sp, -SZ_GPR-6*SZ_FPR
+FPR_S  $f30, $sp, -SZ_GPR-7*SZ_FPR
+FPR_S  $f31, $sp, -SZ_GPR-8*SZ_FPR
+#endif
+
+// callee-saved GPRs (r21, fp (r22), r23-r31)
+GPR_S $r21, $sp, 0*SZ_GPR
+GPR_S  $fp, $sp, 1*SZ_GPR
+GPR_S  $s0, $sp, 2*SZ_GPR
+GPR_S  $s1, $sp, 3*SZ_GPR
+GPR_S  $s2, $sp, 4*SZ_GPR
+GPR_S  $s3, $sp, 5*SZ_GPR
+GPR_S  $s4, $sp, 6*SZ_GPR
+GPR_S  $s5, $sp, 7*SZ_GPR
+GPR_S  $s6, $sp, 8*SZ_GPR
+GPR_S  $s7, $sp, 9*SZ_GPR
+GPR_S  $s8, $sp, 10*SZ_GPR
+
+// swap stack pointer
+GPR_S $sp, $a0, 0
+move $sp, $a1
+
+GPR_L  $r1, $sp, -SZ_GPR
+
+#if SZ_FPR != 0
+FPR_L  $f24, $sp, -SZ_GPR-1*SZ_FPR
+FPR_L  $f25, $sp, -SZ_GPR-2*SZ_FPR
+FPR_L  $f26, $sp, -SZ_GPR-3*SZ_FPR
+FPR_L  $f27, $sp, -SZ_GPR-4*SZ_FPR
+FPR_L  $f28, $sp, -SZ_GPR-5*SZ_FPR
+FPR_L  $f29, $sp, -SZ_GPR-6*SZ_FPR
+FPR_L  $f30, $sp, -SZ_GPR-7*SZ_FPR
+FPR_L  $f31, $sp, -SZ_GPR-8*SZ_FPR
+#endif
+
+GPR_L $r21, $sp, 0*SZ_GPR
+GPR_L  $fp, $sp, 1*SZ_GPR
+GPR_L  $s0, $sp, 2*SZ_GPR
+GPR_L  $s1, $sp, 3*SZ_GPR
+GPR_L  $s2, $sp, 4*SZ_GPR
+GPR_L  $s3, $sp, 5*SZ_GPR
+GPR_L  $s4, $sp, 6*SZ_GPR
+GPR_L  $s5, $sp, 7*SZ_GPR
+GPR_L  $s6, $sp, 8*SZ_GPR
+GPR_L  $s7, $sp, 9*SZ_GPR
+GPR_L  $s8, $sp, 10*SZ_GPR
+
+ADDSP(11 * SZ_GPR)
+
+jr $r1 // return
+.cfi_endproc
+.size fiber_switchContext,.-fiber_switchContext
diff --git a/libphobos/src/std/math/hardware.d 
b/libphobos/src/std/math/hardware.d
index cb6cb87845c..8d11459a8ac 100644
--- a/libphobos/src/std/math/hardware.d
+++ b/libphobos/src/std/math/hardware.d
@@ -177,6 +177,20 @@ private:
 return result;
 }
 }
+else version (LoongArch_Any)
+{
+version (D_SoftFloat)
+return 0;
+else
+{
+  

[PATCH v2 1/3] LoongArch: Adjust D version strings.

[Yang Yujie]

gcc/ChangeLog:

* config/loongarch/loongarch-d.cc: Undefine LoongArch32.
Define LoongArch_SF, LoongArch_F32, LoongArch_F64

gcc/d/ChangeLog:

* dmd/cond.d: Same.
* implement-d.texi: Same.
---
 gcc/config/loongarch/loongarch-d.cc | 27 ++-
 gcc/d/dmd/cond.d|  6 +++---
 gcc/d/implement-d.texi  |  6 ++
 3 files changed, 23 insertions(+), 16 deletions(-)

diff --git a/gcc/config/loongarch/loongarch-d.cc 
b/gcc/config/loongarch/loongarch-d.cc
index 9ac483c39a7..4692b78708a 100644
--- a/gcc/config/loongarch/loongarch-d.cc
+++ b/gcc/config/loongarch/loongarch-d.cc
@@ -29,24 +29,27 @@ along with GCC; see the file COPYING3.  If not see
 void
 loongarch_d_target_versions (void)
 {
-  if (TARGET_64BIT)
+  if (TARGET_ABI_LP64)
 d_add_builtin_version ("LoongArch64");
-  else
-d_add_builtin_version ("LoongArch32");
 
-  if (TARGET_HARD_FLOAT_ABI)
+  if (TARGET_DOUBLE_FLOAT_ABI)
+{
+  d_add_builtin_version ("LoongArch_F64");
+  d_add_builtin_version ("D_HardFloat");
+}
+  else if (TARGET_SINGLE_FLOAT_ABI)
 {
-  d_add_builtin_version ("LoongArch_HardFloat");
+  d_add_builtin_version ("LoongArch_F32");
   d_add_builtin_version ("D_HardFloat");
 }
-  else if (TARGET_SOFT_FLOAT_ABI)
+  else
 {
-  d_add_builtin_version ("LoongArch_SoftFloat");
+  d_add_builtin_version ("LoongArch_SF");
   d_add_builtin_version ("D_SoftFloat");
 }
 }
 
-/* Handle a call to `__traits(getTargetInfo, "floatAbi")'.  */
+/* Handle trait getTargetInfo with key "floatAbi"  */
 
 static tree
 loongarch_d_handle_target_float_abi (void)
@@ -55,10 +58,8 @@ loongarch_d_handle_target_float_abi (void)
 
   if (TARGET_HARD_FLOAT_ABI)
 abi = "hard";
-  else if (TARGET_SOFT_FLOAT_ABI)
-abi = "soft";
   else
-abi = "";
+abi = "soft";
 
   return build_string_literal (strlen (abi) + 1, abi);
 }
@@ -69,8 +70,8 @@ void
 loongarch_d_register_target_info (void)
 {
   const struct d_target_info_spec handlers[] = {
-{"floatAbi", loongarch_d_handle_target_float_abi},
-{NULL, NULL},
+{ "floatAbi", loongarch_d_handle_target_float_abi },
+{ NULL, NULL },
   };
 
   d_add_target_info_handlers (handlers);
diff --git a/gcc/d/dmd/cond.d b/gcc/d/dmd/cond.d
index 568b639e0b6..02af0cc9e29 100644
--- a/gcc/d/dmd/cond.d
+++ b/gcc/d/dmd/cond.d
@@ -693,10 +693,10 @@ extern (C++) final class VersionCondition : DVCondition
 case "LDC":
 case "linux":
 case "LittleEndian":
-case "LoongArch32":
 case "LoongArch64":
-case "LoongArch_HardFloat":
-case "LoongArch_SoftFloat":
+case "LoongArch_F64":
+case "LoongArch_F32":
+case "LoongArch_SF":
 case "MinGW":
 case "MIPS32":
 case "MIPS64":
diff --git a/gcc/d/implement-d.texi b/gcc/d/implement-d.texi
index 6f33bc192fe..cc0d1ecf593 100644
--- a/gcc/d/implement-d.texi
+++ b/gcc/d/implement-d.texi
@@ -1966,6 +1966,12 @@ Version relating to GNU Hurd systems.
 @item linux
 Version relating to Linux systems.
 
+@item LoongArch64
+@item LoongArch_SF
+@item LoongArch_F32
+@item LoongArch_F64
+Versions relating to the LoongArch family of processors.
+
 @item MinGW
 Version relating to the MinGW environment.
 
-- 
2.20.1

[PATCH] lower-bitint: Fix ICE on bitint-39.c

[Jakub Jelinek]

Hi!

torture/bitint-39.c ICEs with -O1; the problem is that the
finish_arith_overflow code in one spot replaces use_stmt with an
assignment or cast, but if unlucky and m_gsi iterator is the same statement,
when the code later
  tree clobber = build_clobber (TREE_TYPE (var), CLOBBER_EOL);
  g = gimple_build_assign (var, clobber);
  gsi_insert_after (_gsi, g, GSI_SAME_STMT);
it will insert after iterator which contains already replaced statement and
that causes the gimple chain corruption.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
for trunk?

2023-12-01  Jakub Jelinek  

* gimple-lower-bitint.cc (bitint_large_huge::finish_arith_overflow):
When replacing use_stmt which is gsi_stmt (m_gsi), update m_gsi to
the new statement.

--- gcc/gimple-lower-bitint.cc.jj   2023-11-30 10:57:40.09940 +0100
+++ gcc/gimple-lower-bitint.cc  2023-11-30 12:46:34.715093396 +0100
@@ -3682,6 +3682,8 @@ bitint_large_huge::finish_arith_overflow
  else
g = gimple_build_assign (lhs2, NOP_EXPR, ovf);
  gsi_replace (, g, true);
+ if (gsi_stmt (m_gsi) == use_stmt)
+   m_gsi = gsi_for_stmt (g);
  break;
}
}

Jakub

RE: [PATCH] i386: Mark Xeon Phi ISAs as deprecated

[Jiang, Haochen]

> -Original Message-
> From: Richard Biener 
> Sent: Friday, December 1, 2023 3:04 PM
> To: Jiang, Haochen 
> Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao ;
> ubiz...@gmail.com
> Subject: Re: [PATCH] i386: Mark Xeon Phi ISAs as deprecated
> 
> On Fri, Dec 1, 2023 at 3:22 AM Haochen Jiang 
> wrote:
> >
> > Since Knight Landing and Knight Mill microarchitectures are EOL, we
> > would like to remove its support in GCC 15. In GCC 14, we will first
> > emit a warning for the usage.
> 
> I think it's better to keep supporting -mtune/arch=knl without diagnostics

I see, it could be a choice and might be better. But if we take this, how should
we define -mtune=knl remains a question.

> but simply not enable the ISAs we don't support.  The better question is
> what to do about KNL specific intrinsics headers / intrinsics?  Will we
> simply remove those?

If there is no objection, The intrinsics are planned to be removed in GCC 15.
As far as concerned, almost nobody are using them with the latest GCC. And
there is no complaint when removing them in ICC/ICX.

Thx,
Haochen

> 
> Richard.
> 
> > gcc/ChangeLog:
> >
> > * config/i386/driver-i386.cc (host_detect_local_cpu):
> > Do not append "-mno-" for Xeon Phi ISAs.
> > * config/i386/i386-options.cc (ix86_option_override_internal):
> > Emit a warning for KNL/KNM targets.
> > * config/i386/i386.opt: Emit a warning for Xeon Phi ISAs.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/other/i386-2.C: Adjust testcases.
> > * g++.dg/other/i386-3.C: Ditto.
> > * g++.dg/pr80481.C: Ditto.
> > * gcc.dg/pr71279.c: Ditto.
> > * gcc.target/i386/avx5124fmadd-v4fmaddps-1.c: Ditto.
> > * gcc.target/i386/avx5124fmadd-v4fmaddps-2.c: Ditto.
> > * gcc.target/i386/avx5124fmadd-v4fmaddss-1.c: Ditto.
> > * gcc.target/i386/avx5124fmadd-v4fnmaddps-1.c: Ditto.
> > * gcc.target/i386/avx5124fmadd-v4fnmaddps-2.c: Ditto.
> > * gcc.target/i386/avx5124fmadd-v4fnmaddss-1.c: Ditto.
> > * gcc.target/i386/avx5124vnniw-vp4dpwssd-1.c: Ditto.
> > * gcc.target/i386/avx5124vnniw-vp4dpwssd-2.c: Ditto.
> > * gcc.target/i386/avx5124vnniw-vp4dpwssds-1.c: Ditto.
> > * gcc.target/i386/avx5124vnniw-vp4dpwssds-2.c: Ditto.
> > * gcc.target/i386/avx512er-vexp2pd-1.c: Ditto.
> > * gcc.target/i386/avx512er-vexp2pd-2.c: Ditto.
> > * gcc.target/i386/avx512er-vexp2ps-1.c: Ditto.
> > * gcc.target/i386/avx512er-vexp2ps-2.c: Ditto.
> > * gcc.target/i386/avx512er-vrcp28pd-1.c: Ditto.
> > * gcc.target/i386/avx512er-vrcp28pd-2.c: Ditto.
> > * gcc.target/i386/avx512er-vrcp28ps-1.c: Ditto.
> > * gcc.target/i386/avx512er-vrcp28ps-2.c: Ditto.
> > * gcc.target/i386/avx512er-vrcp28ps-3.c: Ditto.
> > * gcc.target/i386/avx512er-vrcp28ps-4.c: Ditto.
> > * gcc.target/i386/avx512er-vrcp28sd-1.c: Ditto.
> > * gcc.target/i386/avx512er-vrcp28sd-2.c: Ditto.
> > * gcc.target/i386/avx512er-vrcp28ss-1.c: Ditto.
> > * gcc.target/i386/avx512er-vrcp28ss-2.c: Ditto.
> > * gcc.target/i386/avx512er-vrsqrt28pd-1.c: Ditto.
> > * gcc.target/i386/avx512er-vrsqrt28pd-2.c: Ditto.
> > * gcc.target/i386/avx512er-vrsqrt28ps-1.c: Ditto.
> > * gcc.target/i386/avx512er-vrsqrt28ps-2.c: Ditto.
> > * gcc.target/i386/avx512er-vrsqrt28ps-3.c: Ditto.
> > * gcc.target/i386/avx512er-vrsqrt28ps-4.c: Ditto.
> > * gcc.target/i386/avx512er-vrsqrt28ps-5.c: Ditto.
> > * gcc.target/i386/avx512er-vrsqrt28ps-6.c: Ditto.
> > * gcc.target/i386/avx512er-vrsqrt28sd-1.c: Ditto.
> > * gcc.target/i386/avx512er-vrsqrt28sd-2.c: Ditto.
> > * gcc.target/i386/avx512er-vrsqrt28ss-1.c: Ditto.
> > * gcc.target/i386/avx512er-vrsqrt28ss-2.c: Ditto.
> > * gcc.target/i386/avx512f-gather-1.c: Ditto.
> > * gcc.target/i386/avx512f-gather-2.c: Ditto.
> > * gcc.target/i386/avx512f-gather-3.c: Ditto.
> > * gcc.target/i386/avx512f-gather-4.c: Ditto.
> > * gcc.target/i386/avx512f-gather-5.c: Ditto.
> > * gcc.target/i386/avx512f-i32gatherd512-1.c: Ditto.
> > * gcc.target/i386/avx512f-i32gatherd512-2.c: Ditto.
> > * gcc.target/i386/avx512f-i32gatherpd512-1.c: Ditto.
> > * gcc.target/i386/avx512f-i32gatherpd512-2.c: Ditto.
> > * gcc.target/i386/avx512f-i32gatherps512-1.c: Ditto.
> > * gcc.target/i386/avx512f-vect-perm-1.c: Ditto.
> > * gcc.target/i386/avx512f-vect-perm-2.c: Ditto.
> > * gcc.target/i386/avx512pf-vgatherpf0dpd-1.c: Ditto.
> > * gcc.target/i386/avx512pf-vgatherpf0dps-1.c: Ditto.
> > * gcc.target/i386/avx512pf-vgatherpf0qpd-1.c: Ditto.
> > * gcc.target/i386/avx512pf-vgatherpf0qps-1.c: Ditto.
> > * gcc.target/i386/avx512pf-vgatherpf1dpd-1.c: Ditto.
> > * gcc.target/i386/avx512pf-vgatherpf1dps-1.c: 

[PATCH] lower-bitint: Fix _BitInt .{ADD,SUB}_OVERFLOW lowering [PR112750]

[Jakub Jelinek]

Hi!

The .{ADD,SUB}_OVERFLOW lowering is implemented by performing normal
addition/subtraction (perhaps extended to even more bits than normally by
continuing with extended values of operands after running of normal bits)
and in addition to that trying to compute if certain sets of bits are either
all zero or all sign extensions of the least significant bit.

That code is in a lot of cases guarded just by a single condition (which
can be idx > startlimb, idx >= startlimb or idx == startlimb) or by
2 conditions - if (idx >= startlimb) { if (idx == startlimb) ... else ... }
Now, if_then_if_then_else when the second argument is NULL works just as
if_then and sets m_gsi to be within the initially empty then block and that is
where we emit code for constant tidx startlimb + (cmp_code == GT_EXPR).
But in the 2 conditions case, m_gsi is set to the initially empty else
block, so using EQ_EXPR for the condition was incorrect (and strangely
nothing in the testsuite caught that), because the code for extracting the
lowest set of bits (i.e. when tidx is startlimb) is then done when idx
is not startlimb rather than when it is.
The following patch fixes that.

Note, when developing the lowering, I was using gcov to make sure all code
is covered by the testsuite with minimum exceptions, so no idea how this
slipped out.

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

2023-12-01  Jakub Jelinek  

PR middle-end/112750
* gimple-lower-bitint.cc (bitint_large_huge::lower_addsub_overflow):
Use NE_EXPR rather than EQ_EXPR for g2 if !single_comparison and
adjust probabilities.

* gcc.dg/bitint-41.c: Use -std=c23 rather than -std=c2x.
* gcc.dg/torture/bitint-43.c: Likewise.
* gcc.dg/torture/bitint-44.c: Likewise.
* gcc.dg/torture/bitint-45.c: New test.

--- gcc/gimple-lower-bitint.cc.jj   2023-11-24 11:30:24.416427246 +0100
+++ gcc/gimple-lower-bitint.cc  2023-11-30 10:57:40.09940 +0100
@@ -4028,11 +4028,11 @@ bitint_large_huge::lower_addsub_overflow
  edge edge_true_true, edge_true_false, edge_false;
  gimple *g2 = NULL;
  if (!single_comparison)
-   g2 = gimple_build_cond (EQ_EXPR, idx,
+   g2 = gimple_build_cond (NE_EXPR, idx,
size_int (startlimb), NULL_TREE,
NULL_TREE);
  if_then_if_then_else (g, g2, profile_probability::likely (),
-   profile_probability::unlikely (),
+   profile_probability::likely (),
edge_true_true, edge_true_false,
edge_false);
  unsigned tidx = startlimb + (cmp_code == GT_EXPR);
--- gcc/testsuite/gcc.dg/bitint-41.c.jj 2023-11-23 12:59:48.027443972 +0100
+++ gcc/testsuite/gcc.dg/bitint-41.c2023-11-30 11:05:54.956550967 +0100
@@ -1,6 +1,6 @@
 /* PR middle-end/112336 */
 /* { dg-do compile { target bitint } } */
-/* { dg-options "-std=c2x" } */
+/* { dg-options "-std=c23" } */
 
 unsigned _BitInt(1) v1;
 unsigned _BitInt(1) *p1 = 
--- gcc/testsuite/gcc.dg/torture/bitint-43.c.jj 2023-11-20 09:49:35.236668167 
+0100
+++ gcc/testsuite/gcc.dg/torture/bitint-43.c2023-11-30 11:06:31.840028866 
+0100
@@ -1,6 +1,6 @@
 /* PR c/111309 */
 /* { dg-do run { target bitint } } */
-/* { dg-options "-std=c2x -pedantic-errors" } */
+/* { dg-options "-std=c23 -pedantic-errors" } */
 /* { dg-skip-if "" { ! run_expensive_tests }  { "*" } { "-O0" "-O2" } } */
 /* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */
 
--- gcc/testsuite/gcc.dg/torture/bitint-44.c.jj 2023-11-14 10:52:16.192276014 
+0100
+++ gcc/testsuite/gcc.dg/torture/bitint-44.c2023-11-30 11:06:37.494948817 
+0100
@@ -1,6 +1,6 @@
 /* PR c/111309 */
 /* { dg-do run { target bitint } } */
-/* { dg-options "-std=c2x -pedantic-errors" } */
+/* { dg-options "-std=c23 -pedantic-errors" } */
 /* { dg-skip-if "" { ! run_expensive_tests }  { "*" } { "-O0" "-O2" } } */
 /* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */
 
--- gcc/testsuite/gcc.dg/torture/bitint-45.c.jj 2023-11-30 11:07:40.778053018 
+0100
+++ gcc/testsuite/gcc.dg/torture/bitint-45.c2023-11-30 11:07:19.294357123 
+0100
@@ -0,0 +1,32 @@
+/* PR middle-end/112750 */
+/* { dg-do run { target bitint } } */
+/* { dg-options "-std=c23 -pedantic-errors" } */
+/* { dg-skip-if "" { ! run_expensive_tests }  { "*" } { "-O0" "-O2" } } */
+/* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */
+
+#if __BITINT_MAXWIDTH__ >= 256
+_BitInt(256) a = __INT_MAX__ + (_BitInt(256)) 1;
+_BitInt(256) b = __INT_MAX__;
+#endif
+#if __BITINT_MAXWIDTH__ >= 512
+_BitInt(512) c = 0x7fffwb + (_BitInt(512)) 
1;
+_BitInt(512) d = 0x7fffwb;
+#endif
+
+int
+main ()
+{

Re: [PATCH] s390x: Fix PR112753

[Andreas Krebbel]

On 11/30/23 16:45, Juergen Christ wrote:
> Commit 466b100e5fee808d77598e0f294654deec281150 introduced a bug in
> s390_md_asm_adjust if vector extensions are not available.  Fix the control
> flow of this function to not adjust long double values.
> 
> gcc/ChangeLog:
> 
>   * config/s390/s390.cc (s390_md_asm_adjust): Fix.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/s390/pr112753.c: New test.
> 
> Bootstrapped and tested on s390x.

Committed to mainline with a slightly more verbose changelog which also refers 
to the BZ. Thanks!

Andreas

> 
> Signed-off-by: Juergen Christ 
> ---
>  gcc/config/s390/s390.cc  | 4 
>  gcc/testsuite/gcc.target/s390/pr112753.c | 8 
>  2 files changed, 12 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/s390/pr112753.c
> 
> diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
> index 29b5dc979207..3a4d2d346f0c 100644
> --- a/gcc/config/s390/s390.cc
> +++ b/gcc/config/s390/s390.cc
> @@ -17604,6 +17604,10 @@ s390_md_asm_adjust (vec , vec 
> ,
>outputs[i] = fprx2;
>  }
>  
> +  if (!TARGET_VXE)
> +/* Long doubles are stored in FPR pairs - nothing left to do.  */
> +return after_md_seq;
> +
>for (unsigned i = 0; i < ninputs; i++)
>  {
>if (GET_MODE (inputs[i]) != TFmode)
> diff --git a/gcc/testsuite/gcc.target/s390/pr112753.c 
> b/gcc/testsuite/gcc.target/s390/pr112753.c
> new file mode 100644
> index ..7183b3f12bed
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/s390/pr112753.c
> @@ -0,0 +1,8 @@
> +/* This caused an ICE on s390x due to a bug in s390_md_asm_adjust when no
> +   vector extension is available.  */
> +
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -march=zEC12" } */
> +
> +long double strtold_l_internal___x;
> +void strtold_l_internal() { __asm__("" : : 
> "fm"(strtold_l_internal___x)); }

Re: [PATCH v2] doc: Update the status of build directory not fully separated

[Richard Biener]

On Thu, Nov 30, 2023 at 2:42 PM Xi Ruoyao  wrote:
>
> Recently there are some people building GCC with srcdir == objdir and
> the attempts just failed [1].  So stop to say "it should work".  OTOH
> objdir as a subdirectory of srcdir works: we've built GCC in LFS [2]
> and BLFS [3] this way for decades and this is confirmed during the
> review of a previous version of this patch [4].
>
> [1]: https://gcc.gnu.org/pipermail/gcc-help/2023-November/143068.html
> [2]: https://www.linuxfromscratch.org/lfs/view/12.0/chapter08/gcc.html
> [3]: https://www.linuxfromscratch.org/blfs/view/12.0/general/gcc.html
> [4]: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638760.html>

> gcc/ChangeLog:
>
> * doc/install.texi: Deem srcdir == objdir broken, but objdir
> as a subdirectory of srcdir fine.
> ---
>
> Superseds
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638728.html.
>
> Ok for trunk?

OK.

Thanks,
Richard.

>  gcc/doc/install.texi | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> index c1ccb8ba02d..c1128d9274c 100644
> --- a/gcc/doc/install.texi
> +++ b/gcc/doc/install.texi
> @@ -697,9 +697,8 @@ phases.
>  First, we @strong{highly} recommend that GCC be built into a
>  separate directory from the sources which does @strong{not} reside
>  within the source tree.  This is how we generally build GCC; building
> -where @var{srcdir} == @var{objdir} should still work, but doesn't
> -get extensive testing; building where @var{objdir} is a subdirectory
> -of @var{srcdir} is unsupported.
> +where @var{objdir} is a subdirectory of @var{srcdir} should work as well;
> +building where @var{objdir} == @var{srcdir} is unsupported.
>
>  If you have previously built GCC in the same directory for a
>  different target machine, do @samp{make distclean} to delete all files
> --
> 2.43.0
>

Re: Ping: [PATCH] Allow target attributes in non-gnu namespaces

[Richard Biener]

On Thu, Nov 30, 2023 at 3:12 PM Richard Sandiford
 wrote:
>
> Ping

OK.

Thanks,
Richard.

> Richard Sandiford  writes:
> > This is a ping+rebase of the patch below.  I've also optimised the
> > handling of ignored attributes so that we don't register empty tables.
> > There was also a typo in the jit changes (which I had tested, but the
> > typo didn't seem to cause a failure).
> >
> > Retested on aarch64-linux-gnu & x86_64-linux-gnu.  The original was
> > also tested on the full target list in config-list.mk.
> >
> > Iain has already approved the D parts (thanks!).  OK for the rest?
> >
> > And sorry to be pinging something when I'm behind on reviews myself...
> >
> > ---
> >
> > Currently there are four static sources of attributes:
> >
> > - LANG_HOOKS_ATTRIBUTE_TABLE
> > - LANG_HOOKS_COMMON_ATTRIBUTE_TABLE
> > - LANG_HOOKS_FORMAT_ATTRIBUTE_TABLE
> > - TARGET_ATTRIBUTE_TABLE
> >
> > All of the attributes in these tables go in the "gnu" namespace.
> > This means that they can use the traditional GNU __attribute__((...))
> > syntax and the standard [[gnu::...]] syntax.
> >
> > Standard attributes are registered dynamically with a null namespace.
> > There are no supported attributes in other namespaces (clang, vendor
> > namespaces, etc.).
> >
> > This patch tries to generalise things by making the namespace
> > part of the attribute specification.
> >
> > It's usual for multiple attributes to be defined in the same namespace,
> > so rather than adding the namespace to each individual definition,
> > it seemed better to group attributes in the same namespace together.
> > This would also allow us to reuse the same table for clang attributes
> > that are written with the GNU syntax, or other similar situations
> > where the attribute can be accessed via multiple "spellings".
> >
> > The patch therefore adds a scoped_attribute_specs that contains
> > a namespace and a list of attributes in that namespace.
> >
> > It's still possible to have multiple scoped_attribute_specs
> > for the same namespace.  E.g. it makes sense to keep the
> > C++-specific, C/C++-common, and format-related attributes in
> > separate tables, even though they're all GNU attributes.
> >
> > Current lists of attributes are terminated by a null name.
> > Rather than keep that for the new structure, it seemed neater
> > to use an array_slice.  This also makes the tables slighly more
> > compact.
> >
> > In general, a target might want to support attributes in multiple
> > namespaces.  Rather than have a separate hook for each possibility
> > (like the three langhooks above), it seemed better to make
> > TARGET_ATTRIBUTE_TABLE a table of tables.  Specifically, it's
> > an array_slice of scoped_attribute_specs.
> >
> > We can do the same thing for langhooks, which allows the three hooks
> > above to be merged into a single LANG_HOOKS_ATTRIBUTE_TABLE.
> > It also allows the standard attributes to be registered statically
> > and checked by the usual attribs.cc checks.
> >
> > The patch adds a TARGET_GNU_ATTRIBUTES helper for the common case
> > in which a target wants a single table of gnu attributes.  It can
> > only be used if the table is free of preprocessor directives.
> >
> > There are probably other things we need to do to make vendor namespaces
> > work smoothly.  E.g. in principle it would be good to make exclusion
> > sets namespace-aware.  But to some extent we have that with standard
> > vs. gnu attributes too.  This patch is just supposed to be a first step.
>
> gcc/
> * attribs.h (scoped_attribute_specs): New structure.
> (register_scoped_attributes): Take a reference to a
> scoped_attribute_specs instead of separate namespace and array
> parameters.
> * plugin.h (register_scoped_attributes): Likewise.
> * attribs.cc (register_scoped_attributes): Likewise.
> (attribute_tables): Change into an array of scoped_attribute_specs
> pointers.  Reduce to 1 element for frontends and 1 element for 
> targets.
> (empty_attribute_table): Delete.
> (check_attribute_tables): Update for changes to attribute_tables.
> Use a hash_set to identify duplicates.
> (handle_ignored_attributes_option): Update for above changes.
> (init_attributes): Likewise.
> (excl_pair): Delete.
> (test_attribute_exclusions): Update for above changes.  Don't
> enforce symmetry for standard attributes in the top-level namespace.
> * langhooks-def.h (LANG_HOOKS_COMMON_ATTRIBUTE_TABLE): Delete.
> (LANG_HOOKS_FORMAT_ATTRIBUTE_TABLE): Likewise.
> (LANG_HOOKS_INITIALIZER): Update accordingly.
> (LANG_HOOKS_ATTRIBUTE_TABLE): Define to an empty constructor.
> * langhooks.h (lang_hooks::common_attribute_table): Delete.
> (lang_hooks::format_attribute_table): Likewise.
> (lang_hooks::attribute_table): Redefine to an array of
> scoped_attribute_specs pointers.
> * target-def.h 

Re: [PATCH] testsuite: scev: expect fail on ilp32

[Richard Biener]

On Fri, 1 Dec 2023, Hans-Peter Nilsson wrote:

> > From: Hans-Peter Nilsson 
> > Date: Thu, 30 Nov 2023 18:09:10 +0100
> 
> Richard B.:
> > > > In the end we might need to move/duplicate the test to some
> > > > gcc.target/* dir and restrict it to a specific tuning.
> > 
> > I intend to post two alternative patches to get this
> > resolved:
> > 1: Move the tests to gcc.target/i386/scev-[3-5].c
> 
> Subject: [PATCH 1/2] testsuite: Fix XPASS for gcc.dg/tree-ssa/scev-3.c, -4.c 
> and -5.c [PR112786]
> 
> This is the first alternative, perhaps the more appropriate one.
> 
> Tested cris-elf, arm-eabi (default), x86_64-linux, ditto -m32,
> h8300-elf and shle-linux; xpassing, skipped and passing as
> applicable and intended.
> 
> Ok to commit?

Digging in history reveals the testcases were added by
Jiangning Liu , not for any
particular bugreport but "The problem is originally from a real benchmark,
and the test case only tries to detect the GIMPLE level changes."

I'm not sure we can infer the testcase should be moved to
gcc.target/arm/ because of that, but it does seem plausible.

I read from your messages that the testcases pass on arm*-*-*?

Richard.

> -- >8 --
>   PR testsuite/112786
>   * gcc.dg/tree-ssa/scev-3.c, gcc.dg/tree-ssa/scev-4.c,
>   gcc.dg/tree-ssa/scev-5.c: Revert last change and move...
>   * gcc.target/i386/scev-3.c, gcc.target/i386/scev-4.c:
>   gcc.target/i386/scev-5.c: ...here.
> ---
>  gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-3.c | 3 +--
>  gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-4.c | 3 +--
>  gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-5.c | 3 +--
>  3 files changed, 3 insertions(+), 6 deletions(-)
>  rename gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-3.c (80%)
>  rename gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-4.c (81%)
>  rename gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-5.c (81%)
> 
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c 
> b/gcc/testsuite/gcc.target/i386/scev-3.c
> similarity index 80%
> rename from gcc/testsuite/gcc.dg/tree-ssa/scev-3.c
> rename to gcc/testsuite/gcc.target/i386/scev-3.c
> index beea9aed9fe9..ac8c8d4519e3 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c
> +++ b/gcc/testsuite/gcc.target/i386/scev-3.c
> @@ -40,5 +40,4 @@ __BB(6):
>  
>  }
>  
> -/* Not all 32-bit systems fail this, but several do.  */
> -/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { xfail ilp32 } } } */
> +/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { xfail ia32 } } } */
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c 
> b/gcc/testsuite/gcc.target/i386/scev-4.c
> similarity index 81%
> rename from gcc/testsuite/gcc.dg/tree-ssa/scev-4.c
> rename to gcc/testsuite/gcc.target/i386/scev-4.c
> index a97f75f81f65..b0d594053019 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c
> +++ b/gcc/testsuite/gcc.target/i386/scev-4.c
> @@ -45,5 +45,4 @@ __BB(6):
>  
>  }
>  
> -/* Not all 32-bit systems fail this, but several do.  */
> -/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { xfail ilp32 } } } */
> +/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { xfail ia32 } } } */
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c 
> b/gcc/testsuite/gcc.target/i386/scev-5.c
> similarity index 81%
> rename from gcc/testsuite/gcc.dg/tree-ssa/scev-5.c
> rename to gcc/testsuite/gcc.target/i386/scev-5.c
> index 08f4260403c4..c911a9298866 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c
> +++ b/gcc/testsuite/gcc.target/i386/scev-5.c
> @@ -40,5 +40,4 @@ __BB(6):
>  
>  }
>  
> -/* Not all 32-bit systems fail this, but several do.  */
> -/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { xfail ilp32 } } } */
> +/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { xfail ia32 } } } */
> 

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

Re: [PATCH] i386: Mark Xeon Phi ISAs as deprecated

[Richard Biener]

On Fri, Dec 1, 2023 at 3:22 AM Haochen Jiang  wrote:
>
> Since Knight Landing and Knight Mill microarchitectures are EOL, we
> would like to remove its support in GCC 15. In GCC 14, we will first
> emit a warning for the usage.

I think it's better to keep supporting -mtune/arch=knl without diagnostics
but simply not enable the ISAs we don't support.  The better question is
what to do about KNL specific intrinsics headers / intrinsics?  Will we
simply remove those?

Richard.

> gcc/ChangeLog:
>
> * config/i386/driver-i386.cc (host_detect_local_cpu):
> Do not append "-mno-" for Xeon Phi ISAs.
> * config/i386/i386-options.cc (ix86_option_override_internal):
> Emit a warning for KNL/KNM targets.
> * config/i386/i386.opt: Emit a warning for Xeon Phi ISAs.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/other/i386-2.C: Adjust testcases.
> * g++.dg/other/i386-3.C: Ditto.
> * g++.dg/pr80481.C: Ditto.
> * gcc.dg/pr71279.c: Ditto.
> * gcc.target/i386/avx5124fmadd-v4fmaddps-1.c: Ditto.
> * gcc.target/i386/avx5124fmadd-v4fmaddps-2.c: Ditto.
> * gcc.target/i386/avx5124fmadd-v4fmaddss-1.c: Ditto.
> * gcc.target/i386/avx5124fmadd-v4fnmaddps-1.c: Ditto.
> * gcc.target/i386/avx5124fmadd-v4fnmaddps-2.c: Ditto.
> * gcc.target/i386/avx5124fmadd-v4fnmaddss-1.c: Ditto.
> * gcc.target/i386/avx5124vnniw-vp4dpwssd-1.c: Ditto.
> * gcc.target/i386/avx5124vnniw-vp4dpwssd-2.c: Ditto.
> * gcc.target/i386/avx5124vnniw-vp4dpwssds-1.c: Ditto.
> * gcc.target/i386/avx5124vnniw-vp4dpwssds-2.c: Ditto.
> * gcc.target/i386/avx512er-vexp2pd-1.c: Ditto.
> * gcc.target/i386/avx512er-vexp2pd-2.c: Ditto.
> * gcc.target/i386/avx512er-vexp2ps-1.c: Ditto.
> * gcc.target/i386/avx512er-vexp2ps-2.c: Ditto.
> * gcc.target/i386/avx512er-vrcp28pd-1.c: Ditto.
> * gcc.target/i386/avx512er-vrcp28pd-2.c: Ditto.
> * gcc.target/i386/avx512er-vrcp28ps-1.c: Ditto.
> * gcc.target/i386/avx512er-vrcp28ps-2.c: Ditto.
> * gcc.target/i386/avx512er-vrcp28ps-3.c: Ditto.
> * gcc.target/i386/avx512er-vrcp28ps-4.c: Ditto.
> * gcc.target/i386/avx512er-vrcp28sd-1.c: Ditto.
> * gcc.target/i386/avx512er-vrcp28sd-2.c: Ditto.
> * gcc.target/i386/avx512er-vrcp28ss-1.c: Ditto.
> * gcc.target/i386/avx512er-vrcp28ss-2.c: Ditto.
> * gcc.target/i386/avx512er-vrsqrt28pd-1.c: Ditto.
> * gcc.target/i386/avx512er-vrsqrt28pd-2.c: Ditto.
> * gcc.target/i386/avx512er-vrsqrt28ps-1.c: Ditto.
> * gcc.target/i386/avx512er-vrsqrt28ps-2.c: Ditto.
> * gcc.target/i386/avx512er-vrsqrt28ps-3.c: Ditto.
> * gcc.target/i386/avx512er-vrsqrt28ps-4.c: Ditto.
> * gcc.target/i386/avx512er-vrsqrt28ps-5.c: Ditto.
> * gcc.target/i386/avx512er-vrsqrt28ps-6.c: Ditto.
> * gcc.target/i386/avx512er-vrsqrt28sd-1.c: Ditto.
> * gcc.target/i386/avx512er-vrsqrt28sd-2.c: Ditto.
> * gcc.target/i386/avx512er-vrsqrt28ss-1.c: Ditto.
> * gcc.target/i386/avx512er-vrsqrt28ss-2.c: Ditto.
> * gcc.target/i386/avx512f-gather-1.c: Ditto.
> * gcc.target/i386/avx512f-gather-2.c: Ditto.
> * gcc.target/i386/avx512f-gather-3.c: Ditto.
> * gcc.target/i386/avx512f-gather-4.c: Ditto.
> * gcc.target/i386/avx512f-gather-5.c: Ditto.
> * gcc.target/i386/avx512f-i32gatherd512-1.c: Ditto.
> * gcc.target/i386/avx512f-i32gatherd512-2.c: Ditto.
> * gcc.target/i386/avx512f-i32gatherpd512-1.c: Ditto.
> * gcc.target/i386/avx512f-i32gatherpd512-2.c: Ditto.
> * gcc.target/i386/avx512f-i32gatherps512-1.c: Ditto.
> * gcc.target/i386/avx512f-vect-perm-1.c: Ditto.
> * gcc.target/i386/avx512f-vect-perm-2.c: Ditto.
> * gcc.target/i386/avx512pf-vgatherpf0dpd-1.c: Ditto.
> * gcc.target/i386/avx512pf-vgatherpf0dps-1.c: Ditto.
> * gcc.target/i386/avx512pf-vgatherpf0qpd-1.c: Ditto.
> * gcc.target/i386/avx512pf-vgatherpf0qps-1.c: Ditto.
> * gcc.target/i386/avx512pf-vgatherpf1dpd-1.c: Ditto.
> * gcc.target/i386/avx512pf-vgatherpf1dps-1.c: Ditto.
> * gcc.target/i386/avx512pf-vgatherpf1qpd-1.c: Ditto.
> * gcc.target/i386/avx512pf-vgatherpf1qps-1.c: Ditto.
> * gcc.target/i386/avx512pf-vscatterpf0dpd-1.c: Ditto.
> * gcc.target/i386/avx512pf-vscatterpf0dps-1.c: Ditto.
> * gcc.target/i386/avx512pf-vscatterpf0qpd-1.c: Ditto.
> * gcc.target/i386/avx512pf-vscatterpf0qps-1.c: Ditto.
> * gcc.target/i386/avx512pf-vscatterpf1dpd-1.c: Ditto.
> * gcc.target/i386/avx512pf-vscatterpf1dps-1.c: Ditto.
> * gcc.target/i386/avx512pf-vscatterpf1qpd-1.c: Ditto.
> * gcc.target/i386/avx512pf-vscatterpf1qps-1.c: Ditto.
> * gcc.target/i386/funcspec-56.inc: Ditto.
> * gcc.target/i386/pr101395-2.c: Ditto.
> * 

[PATCH] RISC-V: Support highpart register overlap for widen vx/vf instructions

[Juzhe-Zhong]

This patch leverages the same approach as vwcvt.

Before this patch:

.L5:
add a3,s0,s1
add a4,s6,s1
add a5,s7,s1
vsetvli zero,s0,e32,m4,ta,ma
vle32.v v16,0(s1)
vle32.v v12,0(a3)
mv  s1,s2
vle32.v v8,0(a4)
vle32.v v4,0(a5)
nop
vfwadd.vf   v24,v16,fs0
vfwadd.vf   v16,v12,fs0
vs8r.v  v16,0(sp)-> spill
vfwadd.vf   v16,v8,fs0
vfwadd.vf   v8,v4,fs0
nop
vsetvli zero,zero,e64,m8,ta,ma
vfmv.f.sfa4,v24
vl8re64.v   v24,0(sp)   -> reload
vfmv.f.sfa5,v24
fcvt.lu.d a0,fa4,rtz
fcvt.lu.d a1,fa5,rtz
vfmv.f.sfa4,v16
vfmv.f.sfa5,v8
fcvt.lu.d a2,fa4,rtz
fcvt.lu.d a3,fa5,rtz
add s2,s2,s5
callsumation
add s3,s3,a0
bgeus4,s2,.L5

After this patch:

.L5:
add a3,s0,s1
add a4,s6,s1
add a5,s7,s1
vsetvli zero,s0,e32,m4,ta,ma
vle32.v v4,0(s1)
vle32.v v28,0(a3)
mv  s1,s2
vle32.v v20,0(a4)
vle32.v v12,0(a5)
vfwadd.vf   v0,v4,fs0
vfwadd.vf   v24,v28,fs0
vfwadd.vf   v16,v20,fs0
vfwadd.vf   v8,v12,fs0
vsetvli zero,zero,e64,m8,ta,ma
vfmv.f.sfa4,v0
vfmv.f.sfa5,v24
fcvt.lu.d a0,fa4,rtz
fcvt.lu.d a1,fa5,rtz
vfmv.f.sfa4,v16
vfmv.f.sfa5,v8
fcvt.lu.d a2,fa4,rtz
fcvt.lu.d a3,fa5,rtz
add s2,s2,s5
callsumation
add s3,s3,a0
bgeus4,s2,.L5

PR target/112431

gcc/ChangeLog:

* config/riscv/vector.md: Support highpart overlap for vx/vf.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr112431-22.c: New test.
* gcc.target/riscv/rvv/base/pr112431-23.c: New test.
* gcc.target/riscv/rvv/base/pr112431-24.c: New test.
* gcc.target/riscv/rvv/base/pr112431-25.c: New test.
* gcc.target/riscv/rvv/base/pr112431-26.c: New test.
* gcc.target/riscv/rvv/base/pr112431-27.c: New test.

---
 gcc/config/riscv/vector.md|  65 +++---
 .../gcc.target/riscv/rvv/base/pr112431-22.c   | 188 ++
 .../gcc.target/riscv/rvv/base/pr112431-23.c   | 119 +++
 .../gcc.target/riscv/rvv/base/pr112431-24.c   |  86 
 .../gcc.target/riscv/rvv/base/pr112431-25.c   | 104 ++
 .../gcc.target/riscv/rvv/base/pr112431-26.c   |  68 +++
 .../gcc.target/riscv/rvv/base/pr112431-27.c   |  51 +
 7 files changed, 650 insertions(+), 31 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-22.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-23.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-24.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-25.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-26.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr112431-27.c

diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
index b47b9742b62..7a1b22fb58d 100644
--- a/gcc/config/riscv/vector.md
+++ b/gcc/config/riscv/vector.md
@@ -3768,27 +3768,28 @@
(set_attr "mode" "")])
 
 (define_insn 
"@pred_dual_widen__scalar"
-  [(set (match_operand:VWEXTI 0 "register_operand"  "=,")
+  [(set (match_operand:VWEXTI 0 "register_operand"   "=vr,   
vr,   vr,   vr,  vr,vr, ?, ?")
(if_then_else:VWEXTI
  (unspec:
-   [(match_operand: 1 "vector_mask_operand"   
"vmWc1,vmWc1")
-(match_operand 5 "vector_length_operand"  "   rK,   
rK")
-(match_operand 6 "const_int_operand"  "i,
i")
-(match_operand 7 "const_int_operand"  "i,
i")
-(match_operand 8 "const_int_operand"  "i,
i")
+   [(match_operand: 1 "vector_mask_operand"   
"vmWc1,vmWc1,vmWc1,vmWc1,vmWc1,vmWc1,vmWc1,vmWc1")
+(match_operand 5 "vector_length_operand"  "   rK,   
rK,   rK,   rK,   rK,   rK,   rK,   rK")
+(match_operand 6 "const_int_operand"  "i,
i,i,i,i,i,i,i")
+(match_operand 7 "const_int_operand"  "i,
i,i,i,i,i,i,i")
+(match_operand 8 "const_int_operand"  "i,
i,i,i,i,i,i,i")
 (reg:SI VL_REGNUM)
 (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
  (any_widen_binop:VWEXTI
(any_extend:VWEXTI
- (match_operand: 3 "register_operand" "   vr,   
vr"))
+ (match_operand: 3 "register_operand" "  W21,  
W21,  

Re: [PATCH] gcov: Fix __LIBGCC_HAVE_LIBATOMIC definition

[Richard Biener]

On Thu, Nov 30, 2023 at 5:21 PM Sebastian Huber
 wrote:
>
> In libgcov we use defined (__LIBGCC_HAVE_LIBATOMIC), so we must define it only
> if needed (vs. #if __LIBGCC_HAVE_LIBATOMIC).

For consistency wouldn't it be better to change the user side in libgcc?

> gcc/c-family/ChangeLog:
>
> PR target/112777
>
> * c-cppbuiltin.cc (c_cpp_builtins):  Define __LIBGCC_HAVE_LIBATOMIC
> only if targetm.have_libatomic is true.
> ---
>  gcc/c-family/c-cppbuiltin.cc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/c-family/c-cppbuiltin.cc b/gcc/c-family/c-cppbuiltin.cc
> index e536429fa4c..f8ec6f1747c 100644
> --- a/gcc/c-family/c-cppbuiltin.cc
> +++ b/gcc/c-family/c-cppbuiltin.cc
> @@ -1570,8 +1570,8 @@ c_cpp_builtins (cpp_reader *pfile)
>/* For libgcov.  */
>builtin_define_with_int_value ("__LIBGCC_VTABLE_USES_DESCRIPTORS__",
>  TARGET_VTABLE_USES_DESCRIPTORS);
> -  builtin_define_with_int_value ("__LIBGCC_HAVE_LIBATOMIC",
> -targetm.have_libatomic);
> +  if (targetm.have_libatomic)
> +   cpp_define (pfile, "__LIBGCC_HAVE_LIBATOMIC");
>  }
>
>/* For use in assembly language.  */
> --
> 2.35.3
>

Re: [PATCH] s390: Fix builtin-classify-type-1.c on s390 too [PR112725]

[Andreas Krebbel]

On 11/30/23 17:34, Jakub Jelinek wrote:
> On Wed, Nov 29, 2023 at 07:27:20PM +0100, Jakub Jelinek wrote:
>> Given that the s390 backend defines pretty much the same target hook
>> as rs6000, I believe it suffers (at least when using -mvx?) the same
>> problem as rs6000, though admittedly this is so far completely
>> untested.
>>
>> Ok for trunk if it passes bootstrap/regtest there?
> 
> Now successfully bootstrapped/regtested on s390x-linux and indeed it
> fixes
> -FAIL: c-c++-common/builtin-classify-type-1.c  -Wc++-compat  (test for excess 
> errors)
> -UNRESOLVED: c-c++-common/builtin-classify-type-1.c  -Wc++-compat  
> compilation failed to produce executable
> there as well.
> 
>> 2023-11-29  Jakub Jelinek  
>>
>>  PR target/112725
>>  * config/s390/s390.cc (s390_invalid_arg_for_unprototyped_fn): Return
>>  NULL for __builtin_classify_type calls with vector arguments.

Ok. Thank you, Jakub!

Andreas

Re: [PATCH v6 1/1] c++: Initial support for P0847R7 (Deducing This) [PR102609]

[waffl3x]

I ran into another issue while devising tests for redeclarations of
xobj member functions as static member functions and vice versa. I am
pretty sure by the literal wording of the standard, this is well formed.

template
concept Constrain = true;

struct S {
  void f(this auto, Constrain auto) {};
  static void f(Constrain auto) {};

  void g(this auto const&, Constrain auto) {};
  static void g(Constrain auto) {};

  void h(this auto&&, Constrain auto) {};
  static void h(Constrain auto) {};
};

And also,

struct S{
  void f(this auto) {};
  static void f() {};

  void g(this auto const&) {};
  static void g() {};

  void h(this auto&&) {};
  static void h() {};
};

I wrote these tests expecting them to be ill-formed, and found what I
thought was a bug when they were not diagnosed as redecelarations.
However, given how the code for resolving overloads and determining
redeclarations looks, I believe this is actually well formed on a
technicality. I can't find the passages in the standard that specify
this so I can't be sure.

Anyway, the template parameter list differs because of the deduced
object parameter. Now here is the question, you are required to ignore
the object parameter when determining if these are redeclarations or
not, but what about the template parameters associated with the object
parameter? Am I just missing the passage that specifies this or is this
an actual defect in the standard?

The annoying thing is, even if this was brought up, I think the only
solution is to ratify these examples as well formed.

struct S {
  template
  void f(this T, T) {}
  template
  static void f(T) {}
};

Like what about this? If we ignore the template parameters associated
with the explicit object parameter, then the template parameter lists
don't match.

struct S {
  template typename Templ, typename T>
  void f(this Templ, T) {}
  template
  void f(T) {}
};

However, after writing them out and thinking about it a little, maybe
it really is just that simple. If after eliminating the template
parameters the explicit object parameter depends on the template
parameter lists are the same, then it's a redeclaration. Maybe this
works?

Am I overthinking this? Is there actually something specifying this
properly already? Hopefully that's the case but at the very least I
managed to write out this e-mail fairly quick for once so I didn't
waste too much time on this even if it does turn out to be nothing. The
majority of my time here was spent on the test case, which needed to be
written anyway.

Alex

Ping: [PATCH v2] Only allow (int)trunc(x) to (int)x simplification with -ffp-int-builtin-inexact [PR107723]

[Xi Ruoyao]

Ping.

On Fri, 2023-11-24 at 17:09 +0800, Xi Ruoyao wrote:
> With -fno-fp-int-builtin-inexact, trunc is not allowed to raise
> FE_INEXACT and it should produce an integral result (if the input is not
> NaN or Inf).  Thus FE_INEXACT should not be raised.
> 
> But (int)x may raise FE_INEXACT when x is a non-integer, non-NaN, and
> non-Inf value.  C23 recommends to do so in a footnote.
> 
> Thus we should not simplify (int)trunc(x) to (int)x if
> -fno-fp-int-builtin-inexact is in-effect.
> 
> gcc/ChangeLog:
> 
>   PR middle-end/107723
>   * convert.cc (convert_to_integer_1) [case BUILT_IN_TRUNC]: Break
>   early if !flag_fp_int_builtin_inexact and flag_trapping_math.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR middle-end/107723
>   * gcc.dg/torture/builtin-fp-int-inexact-trunc.c: New test.
> ---
> 
> Change from v1: add flag_trapping_math into the condition.
> 
> Bootstrapped and regtested on x86_64-linux-gnu.  Ok for trunk?
> 
>  gcc/convert.cc   |  3 ++-
>  .../gcc.dg/torture/builtin-fp-int-inexact-trunc.c    | 12 
>  2 files changed, 14 insertions(+), 1 deletion(-)
>  create mode 100644 
> gcc/testsuite/gcc.dg/torture/builtin-fp-int-inexact-trunc.c
> 
> diff --git a/gcc/convert.cc b/gcc/convert.cc
> index 46c8bcb31f8..f214b750188 100644
> --- a/gcc/convert.cc
> +++ b/gcc/convert.cc
> @@ -591,7 +591,8 @@ convert_to_integer_1 (tree type, tree expr, bool dofold)
>   CASE_FLT_FN (BUILT_IN_TRUNC):
>   CASE_FLT_FN_FLOATN_NX (BUILT_IN_TRUNC):
>     if (call_expr_nargs (s_expr) != 1
> -   || !SCALAR_FLOAT_TYPE_P (TREE_TYPE (CALL_EXPR_ARG (s_expr, 0
> +   || !SCALAR_FLOAT_TYPE_P (TREE_TYPE (CALL_EXPR_ARG (s_expr, 0)))
> +   || (!flag_fp_int_builtin_inexact && flag_trapping_math))
>       break;
>     return convert_to_integer_1 (type, CALL_EXPR_ARG (s_expr, 0),
>      dofold);
> diff --git a/gcc/testsuite/gcc.dg/torture/builtin-fp-int-inexact-trunc.c 
> b/gcc/testsuite/gcc.dg/torture/builtin-fp-int-inexact-trunc.c
> new file mode 100644
> index 000..09731183621
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/builtin-fp-int-inexact-trunc.c
> @@ -0,0 +1,12 @@
> +/* Test -fno-fp-int-builtin-inexact.  */
> +/* { dg-do compile } */
> +/* { dg-options "-fno-fp-int-builtin-inexact -fdump-tree-original" } */
> +
> +long
> +x (double y)
> +{
> +  return __builtin_trunc (y);
> +}
> +
> +/* Optimization should not discard the __builtin_trunc call.  */
> +/* { dg-final { scan-tree-dump "__builtin_trunc" "original" } } */

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

[PATCH] c++: lambda capture and explicit object parm

[Jason Merrill]

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

-- 8< --

More adjustments to allow for explicit object parameters in lambdas.  This
has no practical effect until that patch goes in, but applying this
separately seems reasonable.

gcc/cp/ChangeLog:

* semantics.cc (finish_non_static_data_member)
(finish_decltype_type, capture_decltype):
Handle deduced closure parameter.
---
 gcc/cp/semantics.cc | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 36b57ac9524..fbbc18336a0 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -2262,6 +2262,16 @@ finish_non_static_data_member (tree decl, tree object, 
tree qualifying_scope,
   else if (PACK_EXPANSION_P (type))
/* Don't bother trying to represent this.  */
type = NULL_TREE;
+  else if (WILDCARD_TYPE_P (TREE_TYPE (object)))
+   /* We don't know what the eventual quals will be, so punt until
+  instantiation time.
+
+  This can happen when called from build_capture_proxy for an explicit
+  object lambda.  It's a bit marginal to call this function in that
+  case, since this function is for references to members of 'this',
+  but the deduced type is required to be derived from the closure
+  type, so it works.  */
+   type = NULL_TREE;
   else
{
  /* Set the cv qualifiers.  */
@@ -11682,6 +11692,7 @@ finish_decltype_type (tree expr, bool 
id_expression_or_member_access_p,
  A::U doesn't require 'typename'.  */
   if (instantiation_dependent_uneval_expression_p (expr))
 {
+dependent:
   type = cxx_make_type (DECLTYPE_TYPE);
   DECLTYPE_TYPE_EXPR (type) = expr;
   DECLTYPE_TYPE_ID_EXPR_OR_MEMBER_ACCESS_P (type)
@@ -11856,7 +11867,11 @@ finish_decltype_type (tree expr, bool 
id_expression_or_member_access_p,
   if (outer_automatic_var_p (STRIP_REFERENCE_REF (expr))
  && current_function_decl
  && LAMBDA_FUNCTION_P (current_function_decl))
-   type = capture_decltype (STRIP_REFERENCE_REF (expr));
+   {
+ type = capture_decltype (STRIP_REFERENCE_REF (expr));
+ if (!type)
+   goto dependent;
+   }
   else if (error_operand_p (expr))
type = error_mark_node;
   else if (expr == current_class_ptr)
@@ -12754,7 +12769,8 @@ apply_deduced_return_type (tree fco, tree return_type)
 
 /* DECL is a local variable or parameter from the surrounding scope of a
lambda-expression.  Returns the decltype for a use of the capture field
-   for DECL even if it hasn't been captured yet.  */
+   for DECL even if it hasn't been captured yet.  Or NULL_TREE if we can't give
+   a correct answer at this point and we should build a DECLTYPE_TYPE.  */
 
 static tree
 capture_decltype (tree decl)
@@ -12792,9 +12808,11 @@ capture_decltype (tree decl)
 
   if (!TYPE_REF_P (type))
 {
-  int quals = cp_type_quals (type);
   tree obtype = TREE_TYPE (DECL_ARGUMENTS (current_function_decl));
-  gcc_checking_assert (!WILDCARD_TYPE_P (non_reference (obtype)));
+  if (WILDCARD_TYPE_P (non_reference (obtype)))
+   /* We don't know what the eventual obtype quals will be.  */
+   return NULL_TREE;
+  int quals = cp_type_quals (type);
   if (INDIRECT_TYPE_P (obtype))
quals |= cp_type_quals (TREE_TYPE (obtype));
   type = cp_build_qualified_type (type, quals);

base-commit: f2c52c0dfde581461959b0e2b423ad106aadf179
-- 
2.39.3

Re: [PATCH] testsuite: scev: expect fail on ilp32

[Hans-Peter Nilsson]

> From: Hans-Peter Nilsson 
> Date: Thu, 30 Nov 2023 18:09:10 +0100

> I intend to post two alternative patches to get this
> resolved:

> 2: gcc.dg/tree-ssa/scev-[3-5].c skipped for arm*, xfailed
>only on h8300-*-* and ia32.

(Except as mentioned, the XPASS issue does not apply to
h8300; it's "i16lp32".  It remains in the set of targets
that were tested though.)

Subject: [PATCH 2/2] testsuite: Fix XPASS for gcc.dg/tree-ssa/scev-3.c, -4.c 
and -5.c [PR112786]

This is the second alternative, slightly more trivial than the first.

Tested cris-elf, arm-eabi (default), x86_64-linux, ditto -m32,
h8300-elf and shle-linux; xpassing, skipped and passing as
applicable and intended.

Ok to commit?
-- >8 --
Results differ between ARM sub-targets, thus better to skip these
tests.  They are known to fail only for ia32-elf.

PR testsuite/112786
* gcc.dg/tree-ssa/scev-3.c, gcc.dg/tree-ssa/scev-4.c,
gcc.dg/tree-ssa/scev-5.c: Revert last change.  Instead, skip dump
match for arm*.
---
 gcc/testsuite/gcc.dg/tree-ssa/scev-3.c | 3 +--
 gcc/testsuite/gcc.dg/tree-ssa/scev-4.c | 3 +--
 gcc/testsuite/gcc.dg/tree-ssa/scev-5.c | 3 +--
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c 
b/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c
index beea9aed9fe9..6e9733504014 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c
@@ -40,5 +40,4 @@ __BB(6):
 
 }
 
-/* Not all 32-bit systems fail this, but several do.  */
-/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { xfail ilp32 } } } */
+/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { target { ! arm*-*-* } 
xfail ia32 } } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c 
b/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c
index a97f75f81f65..a0cf171f01be 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c
@@ -45,5 +45,4 @@ __BB(6):
 
 }
 
-/* Not all 32-bit systems fail this, but several do.  */
-/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { xfail ilp32 } } } */
+/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { target { ! arm*-*-* } 
xfail ia32 } } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c 
b/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c
index 08f4260403c4..0bd743cc6be6 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c
@@ -40,5 +40,4 @@ __BB(6):
 
 }
 
-/* Not all 32-bit systems fail this, but several do.  */
-/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { xfail ilp32 } } } */
+/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { target { ! arm*-*-* } 
xfail ia32 } } } */
-- 
2.30.2

Re: [PATCH] testsuite: scev: expect fail on ilp32

[Hans-Peter Nilsson]

> From: Hans-Peter Nilsson 
> Date: Thu, 30 Nov 2023 18:09:10 +0100

Richard B.:
> > > In the end we might need to move/duplicate the test to some
> > > gcc.target/* dir and restrict it to a specific tuning.
> 
> I intend to post two alternative patches to get this
> resolved:
> 1: Move the tests to gcc.target/i386/scev-[3-5].c

Subject: [PATCH 1/2] testsuite: Fix XPASS for gcc.dg/tree-ssa/scev-3.c, -4.c 
and -5.c [PR112786]

This is the first alternative, perhaps the more appropriate one.

Tested cris-elf, arm-eabi (default), x86_64-linux, ditto -m32,
h8300-elf and shle-linux; xpassing, skipped and passing as
applicable and intended.

Ok to commit?
-- >8 --
PR testsuite/112786
* gcc.dg/tree-ssa/scev-3.c, gcc.dg/tree-ssa/scev-4.c,
gcc.dg/tree-ssa/scev-5.c: Revert last change and move...
* gcc.target/i386/scev-3.c, gcc.target/i386/scev-4.c:
gcc.target/i386/scev-5.c: ...here.
---
 gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-3.c | 3 +--
 gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-4.c | 3 +--
 gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-5.c | 3 +--
 3 files changed, 3 insertions(+), 6 deletions(-)
 rename gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-3.c (80%)
 rename gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-4.c (81%)
 rename gcc/testsuite/{gcc.dg/tree-ssa => gcc.target/i386}/scev-5.c (81%)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c 
b/gcc/testsuite/gcc.target/i386/scev-3.c
similarity index 80%
rename from gcc/testsuite/gcc.dg/tree-ssa/scev-3.c
rename to gcc/testsuite/gcc.target/i386/scev-3.c
index beea9aed9fe9..ac8c8d4519e3 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c
+++ b/gcc/testsuite/gcc.target/i386/scev-3.c
@@ -40,5 +40,4 @@ __BB(6):
 
 }
 
-/* Not all 32-bit systems fail this, but several do.  */
-/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { xfail ilp32 } } } */
+/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { xfail ia32 } } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c 
b/gcc/testsuite/gcc.target/i386/scev-4.c
similarity index 81%
rename from gcc/testsuite/gcc.dg/tree-ssa/scev-4.c
rename to gcc/testsuite/gcc.target/i386/scev-4.c
index a97f75f81f65..b0d594053019 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c
+++ b/gcc/testsuite/gcc.target/i386/scev-4.c
@@ -45,5 +45,4 @@ __BB(6):
 
 }
 
-/* Not all 32-bit systems fail this, but several do.  */
-/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { xfail ilp32 } } } */
+/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { xfail ia32 } } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c 
b/gcc/testsuite/gcc.target/i386/scev-5.c
similarity index 81%
rename from gcc/testsuite/gcc.dg/tree-ssa/scev-5.c
rename to gcc/testsuite/gcc.target/i386/scev-5.c
index 08f4260403c4..c911a9298866 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/scev-5.c
+++ b/gcc/testsuite/gcc.target/i386/scev-5.c
@@ -40,5 +40,4 @@ __BB(6):
 
 }
 
-/* Not all 32-bit systems fail this, but several do.  */
-/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { xfail ilp32 } } } */
+/* { dg-final { scan-tree-dump-times "" 1 "ivopts" { xfail ia32 } } } */
-- 
2.30.2

Re: [PATCH] RISC-V: Fix VSETVL PASS regression

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

All regressions (zve64d/zvl128b/zvl256b/zvl512b/zvl1024b) passed.


juzhe.zh...@rivai.ai
 
From: Juzhe-Zhong
Date: 2023-12-01 08:51
To: gcc-patches
CC: kito.cheng; kito.cheng; jeffreyalaw; rdapp.gcc; Juzhe-Zhong
Subject: [PATCH] RISC-V: Fix VSETVL PASS regression
This patch fix 2 regression (one is bug regression, the other is performance 
regression).
Those 2 regressions are both we are comparing ratio for same AVL in wrong place.
 
1. BUG regression:
avl_single-84.c:
 
f0:
li  a5,999424
add a1,a1,a5
li  a4,299008
add a5,a0,a5
addia3,a4,992
addia5,a5,576
addia1,a1,576
vsetvli a4,zero,e8,m2,ta,ma
add a0,a0,a3
vlm.v   v1,0(a5)
vsm.v   v1,0(a1)
vl1re64.v   v1,0(a0)
beq a2,zero,.L10
li  a5,0
vsetvli zero,zero,e64,m1,tu,ma   --->  This is totally incorrect since 
the ratio above is 4, wheras it is demanding ratio = 64 here.
.L3:
fcvt.d.lu   fa5,a5
addia5,a5,1
fadd.d  fa5,fa5,fa0
vfmv.s.fv1,fa5
bne a5,a2,.L3
vfmv.f.sfa0,v1
ret
.L10:
vsetvli zero,zero,e64,m1,ta,ma
vfmv.f.sfa0,v1
ret
 
2. Performance regression:
 
before this patch:
 
vsetvli a5,a4,e8,m1,ta,ma
vsetvli zero,a5,e32,m1,tu,ma
vmv.s.x v2,zero
vmv.s.x v1,zero
vsetvli zero,a5,e32,m4,tu,ma
vle32.v v4,0(a1)
vfmul.vvv4,v4,v4
vfredosum.vsv1,v4,v2
vfmv.f.sfa5,v1
fsw fa5,0(a0)
sub a4,a4,a5
bne a4,zero,.L2
ret
 
After this patch:
 
vsetvli a5,a4,e32,m4,tu,ma
vle32.v v4,0(a1)
vmv.s.x v2,zero
vmv.s.x v1,zero
vfmul.vv v4,v4,v4
vfredosum.vs v1,v4,v2
vfmv.f.s fa5,v1
fsw fa5,0(a0)
sub a4,a4,a5
bne a4,zero,.L2
ret
 
Tested rv64gcv_zvfh_zfh passed no regression.
 
zvl256b/zvl512b/zvl1024b/zve64d is runing.
 
PR target/112776
 
gcc/ChangeLog:
 
* config/riscv/riscv-vsetvl.cc (pre_vsetvl::pre_global_vsetvl_info): Fix ratio.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/vsetvl/avl_single-84.c: Adapt test.
* gcc.target/riscv/rvv/vsetvl/pr111037-3.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/pr112776.c: New test.
 
---
gcc/config/riscv/riscv-vsetvl.cc  | 13 ---
.../riscv/rvv/vsetvl/avl_single-84.c  |  6 ++--
.../gcc.target/riscv/rvv/vsetvl/pr111037-3.c  |  2 +-
.../gcc.target/riscv/rvv/vsetvl/pr112776.c| 36 +++
4 files changed, 46 insertions(+), 11 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/pr112776.c
 
diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc
index b3e07d4c3aa..1da95daeeb0 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -1497,9 +1497,6 @@ private:
   {
 gcc_assert (prev.valid_p () && next.valid_p ());
-if (prev.get_ratio () != next.get_ratio ())
-  return false;
-
 if (next.has_vl () && next.vl_used_by_non_rvv_insn_p ())
   return false;
@@ -2188,7 +2185,7 @@ private:
 return true;
   }
-  bool preds_has_same_avl_p (const vsetvl_info _info)
+  bool preds_all_same_avl_and_ratio_p (const vsetvl_info _info)
   {
 gcc_assert (
   !bitmap_empty_p (m_vsetvl_def_in[curr_info.get_bb ()->index ()]));
@@ -2200,7 +2197,8 @@ private:
   {
const vsetvl_info _info = *m_vsetvl_def_exprs[expr_index];
if (!prev_info.valid_p ()
- || !m_dem.avl_available_p (prev_info, curr_info))
+ || !m_dem.avl_available_p (prev_info, curr_info)
+ || prev_info.get_ratio () != curr_info.get_ratio ())
  return false;
   }
@@ -3171,7 +3169,7 @@ pre_vsetvl::pre_global_vsetvl_info ()
  curr_info = block_info.local_infos[0];
}
   if (curr_info.valid_p () && !curr_info.vl_used_by_non_rvv_insn_p ()
-   && preds_has_same_avl_p (curr_info))
+   && preds_all_same_avl_and_ratio_p (curr_info))
curr_info.set_change_vtype_only ();
   vsetvl_info prev_info = vsetvl_info ();
@@ -3179,7 +3177,8 @@ pre_vsetvl::pre_global_vsetvl_info ()
   for (auto _info : block_info.local_infos)
{
  if (prev_info.valid_p () && curr_info.valid_p ()
-   && m_dem.avl_available_p (prev_info, curr_info))
+   && m_dem.avl_available_p (prev_info, curr_info)
+   && prev_info.get_ratio () == curr_info.get_ratio ())
curr_info.set_change_vtype_only ();
  prev_info = curr_info;
}
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-84.c 
b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-84.c
index a584dd97dc0..5cd0f285029 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-84.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-84.c
@@ -17,6 +17,6 @@ double f0 (int8_t * restrict in, int8_t * restrict out, int 
n, int m, unsigned c
}
/* { dg-final { scan-assembler-times 
{vsetvli\s+[a-x0-9]+,\s*zero,\s*e8,\s*m2,\s*t[au],\s*m[au]} 1 { target { 
no-opts "-O0" no-opts "-Os" 

[patch-1, rs6000] enable fctiw on old archs [PR112707]

[HAO CHEN GUI]

Hi,
  SImode in float register is supported on P7 above. It causes "fctiw"
can be generated on old 32-bit processors as the output operand of
fctiw insn is a SImode in float/double register. This patch fixes the
problem by adding an expand and an insn pattern for fctiw. The output
of new pattern is SFmode. When the target doesn't support SImode in
float register, it calls the new pattern and convert the SFmode to
SImode via stack.

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

Thanks
Gui Haochen

ChangeLog
rs6000: enable fctiw on old archs

The powerpc 32-bit processors (e.g. 5470) supports "fctiw" instruction,
but the instruction can't be generated on such platforms as the insn is
guard by TARGET_POPCNTD.  The root cause is SImode in float register is
supported from Power7.  Actually implementation of "fctiw" only needs
stfiwx which is supported by the old 320-bit processors.  This patch
enables "fctiw" expand for these processors.

gcc/
PR target/112707
* config/rs6000/rs6000.md (UNSPEC_STFIWX_SF, UNSPEC_FCTIW_SF): New.
(expand lrintsi2): New.
(insn lrintsi2): Rename to...
(lrintsi_internal): ...this, and remove guard TARGET_POPCNTD.
(lrintsi_internal2): New.
(stfiwx_sf): New.

gcc/testsuite/
PR target/112707
* gcc.target/powerpc/pr112707-1.c: New.

patch.diff
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index d4337ce42a9..1b207522ad5 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -90,6 +90,7 @@ (define_c_enum "unspec"
UNSPEC_TLSTLS_PCREL
UNSPEC_FIX_TRUNC_TF ; fadd, rounding towards zero
UNSPEC_STFIWX
+   UNSPEC_STFIWX_SF
UNSPEC_POPCNTB
UNSPEC_FRES
UNSPEC_SP_SET
@@ -111,6 +112,7 @@ (define_c_enum "unspec"
UNSPEC_PARITY
UNSPEC_CMPB
UNSPEC_FCTIW
+   UNSPEC_FCTIW_SF
UNSPEC_FCTID
UNSPEC_LFIWAX
UNSPEC_LFIWZX
@@ -6722,11 +6724,39 @@ (define_insn "lrintdi2"
   "fctid %0,%1"
   [(set_attr "type" "fp")])

-(define_insn "lrintsi2"
+(define_expand "lrintsi2"
   [(set (match_operand:SI 0 "gpc_reg_operand" "=d")
(unspec:SI [(match_operand:SFDF 1 "gpc_reg_operand" "")]
   UNSPEC_FCTIW))]
-  "TARGET_HARD_FLOAT && TARGET_POPCNTD"
+  "TARGET_HARD_FLOAT && TARGET_STFIWX"
+{
+  /* For those old archs in which SImode can't be hold in float registers,
+ call lrintsi_internal2 to put the result in SFmode then
+ convert it via stack.  */
+  if (!TARGET_POPCNTD)
+{
+  rtx tmp = gen_reg_rtx (SFmode);
+  emit_insn (gen_lrintsi_internal2 (tmp, operands[1]));
+  rtx stack = rs6000_allocate_stack_temp (SImode, false, true);
+  emit_insn (gen_stfiwx_sf (stack, tmp));
+  emit_move_insn (operands[0], stack);
+  DONE;
+}
+})
+
+(define_insn "lrintsi_internal"
+  [(set (match_operand:SI 0 "gpc_reg_operand" "=d")
+   (unspec:SI [(match_operand:SFDF 1 "gpc_reg_operand" "")]
+  UNSPEC_FCTIW))]
+  "TARGET_HARD_FLOAT"
+  "fctiw %0,%1"
+  [(set_attr "type" "fp")])
+
+(define_insn "lrintsi_internal2"
+  [(set (match_operand:SF 0 "gpc_reg_operand" "=d")
+   (unspec:SF [(match_operand:SFDF 1 "gpc_reg_operand" "")]
+  UNSPEC_FCTIW_SF))]
+  "TARGET_HARD_FLOAT"
   "fctiw %0,%1"
   [(set_attr "type" "fp")])

@@ -6801,6 +6831,14 @@ (define_insn "stfiwx"
   [(set_attr "type" "fpstore")
(set_attr "isa" "*,p8v")])

+(define_insn "stfiwx_sf"
+  [(set (match_operand:SI 0 "memory_operand" "=Z")
+   (unspec:SI [(match_operand:SF 1 "gpc_reg_operand" "d")]
+  UNSPEC_STFIWX_SF))]
+  "TARGET_STFIWX"
+  "stfiwx %1,%y0"
+  [(set_attr "type" "fpstore")])
+
 ;; If we don't have a direct conversion to single precision, don't enable this
 ;; conversion for 32-bit without fast math, because we don't have the insn to
 ;; generate the fixup swizzle to avoid double rounding problems.
diff --git a/gcc/testsuite/gcc.target/powerpc/pr112707-1.c 
b/gcc/testsuite/gcc.target/powerpc/pr112707-1.c
new file mode 100644
index 000..32f708c5402
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr112707-1.c
@@ -0,0 +1,15 @@
+/* { dg-do compile { target { powerpc*-*-* && be } } } */
+/* { dg-options "-O2 -mdejagnu-cpu=7450 -m32 -fno-math-errno" } */
+/* { dg-require-effective-target ilp32 } */
+/* { dg-final { scan-assembler-times {\mfctiw\M} 2 } }  */
+/* { dg-final { scan-assembler-times {\mstfiwx\M} 2 } }  */
+
+int test1 (double a)
+{
+  return __builtin_irint (a);
+}
+
+int test2 (float a)
+{
+  return __builtin_irint (a);
+}

[patch-2, rs6000] guard fctid on PPC64 and powerpc 476 [PR112707]

[HAO CHEN GUI]

Hi,
  The "fctid" is supported on 64-bit Power processors and powerpc 476. It
need a guard to check it. The patch fixes the issue.

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

Thanks
Gui Haochen

ChangeLog
rs6000: guard fctid on PPC64 and powerpc 476

fctid is supported on 64-bit Power processors and powerpc 476. It should
be guarded by this condition. The patch fixes the issue.

gcc/
PR target/112707
* config/rs6000/rs6000.h (TARGET_FCTID): Define.
* config/rs6000/rs6000.md (lrintdi2): Add guard TARGET_FCTID.

gcc/testsuite/
PR target/112707
* gcc.target/powerpc/pr112707.h: New.
* gcc.target/powerpc/pr112707-2.c: New.
* gcc.target/powerpc/pr112707-3.c: New.


patch.diff
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 22595f6..497ae3d 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -467,6 +467,8 @@ extern int rs6000_vector_align[];
 #define TARGET_FCFIDUS TARGET_POPCNTD
 #define TARGET_FCTIDUZ TARGET_POPCNTD
 #define TARGET_FCTIWUZ TARGET_POPCNTD
+/* Enable fctid on ppc64 and powerpc476.  */
+#define TARGET_FCTID   (TARGET_POWERPC64 | TARGET_FPRND)
 #define TARGET_CTZ TARGET_MODULO
 #define TARGET_EXTSWSLI(TARGET_MODULO && TARGET_POWERPC64)
 #define TARGET_MADDLD  TARGET_MODULO
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index d4337ce..4a5e63c 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -6718,7 +6718,7 @@ (define_insn "lrintdi2"
   [(set (match_operand:DI 0 "gpc_reg_operand" "=d")
(unspec:DI [(match_operand:SFDF 1 "gpc_reg_operand" "")]
   UNSPEC_FCTID))]
-  "TARGET_HARD_FLOAT"
+  "TARGET_HARD_FLOAT && TARGET_FCTID"
   "fctid %0,%1"
   [(set_attr "type" "fp")])

diff --git a/gcc/testsuite/gcc.target/powerpc/pr112707-2.c 
b/gcc/testsuite/gcc.target/powerpc/pr112707-2.c
new file mode 100644
index 000..ae91913
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr112707-2.c
@@ -0,0 +1,6 @@
+/* { dg-do compile { target { powerpc*-*-* && be } } } */
+/* { dg-options "-O2 -mdejagnu-cpu=7450 -m32 -fno-math-errno" } */
+/* { dg-require-effective-target ilp32 } */
+/* { dg-final { scan-assembler-not {\mfctid\M} } }  */
+
+#include "pr112707.h"
diff --git a/gcc/testsuite/gcc.target/powerpc/pr112707-3.c 
b/gcc/testsuite/gcc.target/powerpc/pr112707-3.c
new file mode 100644
index 000..e47ce20
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr112707-3.c
@@ -0,0 +1,9 @@
+/* { dg-do compile { target { powerpc*-*-* && be } } } */
+/* { dg-options "-O2 -m32 -fno-math-errno -mdejagnu-cpu=476fp" } */
+/* { dg-require-effective-target ilp32 } */
+
+/* powerpc 476fp has hard float enabled which is required by fctid */
+
+#include "pr112707.h"
+
+/* { dg-final { scan-assembler-times {\mfctid\M} 2 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr112707.h 
b/gcc/testsuite/gcc.target/powerpc/pr112707.h
new file mode 100644
index 000..e427dc6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr112707.h
@@ -0,0 +1,10 @@
+long long test1 (double a)
+{
+  return __builtin_llrint (a);
+}
+
+long long test2 (float a)
+{
+  return __builtin_llrint (a);
+}
+

[PATCH] Take register pressure into account for vec_construct/scalar_to_vec when the components are not loaded from memory.

[liuhongt]

> Hmm, I would suggest you put reg_needed into the class and accumulate
> over all vec_construct, with your patch you pessimize a single v32qi
> over two separate v16qi for example.  Also currently the whole block is
> gated with INTEGRAL_TYPE_P but register pressure would be also
> a concern for floating point vectors.  finish_cost would then apply an
> adjustment.

Changed.

> 'target_avail_regs' is for GENERAL_REGS, does that include APX regs?
> I don't see anything similar for FP regs, but I guess the target should know
> or maybe there's a #regs in regclass query already.
Haven't see any, use below setting.

unsigned target_avail_sse = TARGET_64BIT ? (TARGET_AVX512F ? 32 : 16) : 8;

Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
No big impact on SPEC2017.
Observe 1 big improvement from other benchmark by avoiding vectorization with
vec_construct v32qi which caused lots of spills.

Ok for trunk?

For vec_contruct, the components must be live at the same time if
they're not loaded from memory, when the number of those components
exceeds available registers, spill happens. Try to account that with a
rough estimation.
??? Ideally, we should have an overall estimation of register pressure
if we know the live range of all variables.

gcc/ChangeLog:

* config/i386/i386.cc (ix86_vector_costs::add_stmt_cost):
Count sse_reg/gpr_regs for components not loaded from memory.
(ix86_vector_costs:ix86_vector_costs): New constructor.
(ix86_vector_costs::m_num_gpr_needed[3]): New private memeber.
(ix86_vector_costs::m_num_sse_needed[3]): Ditto.
(ix86_vector_costs::finish_cost): Estimate overall register
pressure cost.
(ix86_vector_costs::ix86_vect_estimate_reg_pressure): New
function.
---
 gcc/config/i386/i386.cc | 54 ++---
 1 file changed, 50 insertions(+), 4 deletions(-)

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 9390f525b99..dcaea6c2096 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -24562,15 +24562,34 @@ ix86_noce_conversion_profitable_p (rtx_insn *seq, 
struct noce_if_info *if_info)
 /* x86-specific vector costs.  */
 class ix86_vector_costs : public vector_costs
 {
-  using vector_costs::vector_costs;
+public:
+  ix86_vector_costs (vec_info *, bool);
 
   unsigned int add_stmt_cost (int count, vect_cost_for_stmt kind,
  stmt_vec_info stmt_info, slp_tree node,
  tree vectype, int misalign,
  vect_cost_model_location where) override;
   void finish_cost (const vector_costs *) override;
+
+private:
+
+  /* Estimate register pressure of the vectorized code.  */
+  void ix86_vect_estimate_reg_pressure ();
+  /* Number of GENERAL_REGS/SSE_REGS used in the vectorizer, it's used for
+ estimation of register pressure.
+ ??? Currently it's only used by vec_construct/scalar_to_vec
+ where we know it's not loaded from memory.  */
+  unsigned m_num_gpr_needed[3];
+  unsigned m_num_sse_needed[3];
 };
 
+ix86_vector_costs::ix86_vector_costs (vec_info* vinfo, bool costing_for_scalar)
+  : vector_costs (vinfo, costing_for_scalar),
+m_num_gpr_needed (),
+m_num_sse_needed ()
+{
+}
+
 /* Implement targetm.vectorize.create_costs.  */
 
 static vector_costs *
@@ -24748,8 +24767,7 @@ ix86_vector_costs::add_stmt_cost (int count, 
vect_cost_for_stmt kind,
 }
   else if ((kind == vec_construct || kind == scalar_to_vec)
   && node
-  && SLP_TREE_DEF_TYPE (node) == vect_external_def
-  && INTEGRAL_TYPE_P (TREE_TYPE (vectype)))
+  && SLP_TREE_DEF_TYPE (node) == vect_external_def)
 {
   stmt_cost = ix86_builtin_vectorization_cost (kind, vectype, misalign);
   unsigned i;
@@ -24785,7 +24803,15 @@ ix86_vector_costs::add_stmt_cost (int count, 
vect_cost_for_stmt kind,
  && (gimple_assign_rhs_code (def) != BIT_FIELD_REF
  || !VECTOR_TYPE_P (TREE_TYPE
(TREE_OPERAND (gimple_assign_rhs1 (def), 0))
-   stmt_cost += ix86_cost->sse_to_integer;
+   {
+ if (fp)
+   m_num_sse_needed[where]++;
+ else
+   {
+ m_num_gpr_needed[where]++;
+ stmt_cost += ix86_cost->sse_to_integer;
+   }
+   }
}
   FOR_EACH_VEC_ELT (SLP_TREE_SCALAR_OPS (node), i, op)
if (TREE_CODE (op) == SSA_NAME)
@@ -24821,6 +24847,24 @@ ix86_vector_costs::add_stmt_cost (int count, 
vect_cost_for_stmt kind,
   return retval;
 }
 
+void
+ix86_vector_costs::ix86_vect_estimate_reg_pressure ()
+{
+  unsigned gpr_spill_cost = COSTS_N_INSNS (ix86_cost->int_store [2]) / 2;
+  unsigned sse_spill_cost = COSTS_N_INSNS (ix86_cost->sse_store[0]) / 2;
+
+  /* Any better way to have target available fp registers, currently use 
SSE_REGS.  */
+  unsigned target_avail_sse = TARGET_64BIT ? 

Re: [PATCH] testsuite: scev: expect fail on ilp32

[Hans-Peter Nilsson]

> From: Hans-Peter Nilsson 
> Date: Thu, 30 Nov 2023 18:09:10 +0100

> I intend to post two alternative patches to get this
> resolved:
> 1: Move the tests to gcc.target/i386/scev-[3-5].c
> 2: gcc.dg/tree-ssa/scev-[3-5].c skipped for arm*, xfailed
>only on h8300-*-* and ia32.

Correction: h8300-elf does not XPASS not because it's a
ilp32 that fails, but because it's not an ilp32 and does not
match the XFAIL selector, therefore it passes.

IOW, minimizing the negations: h8300-elf is apparently an
"i16lp32" and passes.  No need for special-casing.
TIL, TMRIF.

brgds, H-P

[PATCH] i386: Mark Xeon Phi ISAs as deprecated

[Haochen Jiang]

Since Knight Landing and Knight Mill microarchitectures are EOL, we
would like to remove its support in GCC 15. In GCC 14, we will first
emit a warning for the usage.

gcc/ChangeLog:

* config/i386/driver-i386.cc (host_detect_local_cpu):
Do not append "-mno-" for Xeon Phi ISAs.
* config/i386/i386-options.cc (ix86_option_override_internal):
Emit a warning for KNL/KNM targets.
* config/i386/i386.opt: Emit a warning for Xeon Phi ISAs.

gcc/testsuite/ChangeLog:

* g++.dg/other/i386-2.C: Adjust testcases.
* g++.dg/other/i386-3.C: Ditto.
* g++.dg/pr80481.C: Ditto.
* gcc.dg/pr71279.c: Ditto.
* gcc.target/i386/avx5124fmadd-v4fmaddps-1.c: Ditto.
* gcc.target/i386/avx5124fmadd-v4fmaddps-2.c: Ditto.
* gcc.target/i386/avx5124fmadd-v4fmaddss-1.c: Ditto.
* gcc.target/i386/avx5124fmadd-v4fnmaddps-1.c: Ditto.
* gcc.target/i386/avx5124fmadd-v4fnmaddps-2.c: Ditto.
* gcc.target/i386/avx5124fmadd-v4fnmaddss-1.c: Ditto.
* gcc.target/i386/avx5124vnniw-vp4dpwssd-1.c: Ditto.
* gcc.target/i386/avx5124vnniw-vp4dpwssd-2.c: Ditto.
* gcc.target/i386/avx5124vnniw-vp4dpwssds-1.c: Ditto.
* gcc.target/i386/avx5124vnniw-vp4dpwssds-2.c: Ditto.
* gcc.target/i386/avx512er-vexp2pd-1.c: Ditto.
* gcc.target/i386/avx512er-vexp2pd-2.c: Ditto.
* gcc.target/i386/avx512er-vexp2ps-1.c: Ditto.
* gcc.target/i386/avx512er-vexp2ps-2.c: Ditto.
* gcc.target/i386/avx512er-vrcp28pd-1.c: Ditto.
* gcc.target/i386/avx512er-vrcp28pd-2.c: Ditto.
* gcc.target/i386/avx512er-vrcp28ps-1.c: Ditto.
* gcc.target/i386/avx512er-vrcp28ps-2.c: Ditto.
* gcc.target/i386/avx512er-vrcp28ps-3.c: Ditto.
* gcc.target/i386/avx512er-vrcp28ps-4.c: Ditto.
* gcc.target/i386/avx512er-vrcp28sd-1.c: Ditto.
* gcc.target/i386/avx512er-vrcp28sd-2.c: Ditto.
* gcc.target/i386/avx512er-vrcp28ss-1.c: Ditto.
* gcc.target/i386/avx512er-vrcp28ss-2.c: Ditto.
* gcc.target/i386/avx512er-vrsqrt28pd-1.c: Ditto.
* gcc.target/i386/avx512er-vrsqrt28pd-2.c: Ditto.
* gcc.target/i386/avx512er-vrsqrt28ps-1.c: Ditto.
* gcc.target/i386/avx512er-vrsqrt28ps-2.c: Ditto.
* gcc.target/i386/avx512er-vrsqrt28ps-3.c: Ditto.
* gcc.target/i386/avx512er-vrsqrt28ps-4.c: Ditto.
* gcc.target/i386/avx512er-vrsqrt28ps-5.c: Ditto.
* gcc.target/i386/avx512er-vrsqrt28ps-6.c: Ditto.
* gcc.target/i386/avx512er-vrsqrt28sd-1.c: Ditto.
* gcc.target/i386/avx512er-vrsqrt28sd-2.c: Ditto.
* gcc.target/i386/avx512er-vrsqrt28ss-1.c: Ditto.
* gcc.target/i386/avx512er-vrsqrt28ss-2.c: Ditto.
* gcc.target/i386/avx512f-gather-1.c: Ditto.
* gcc.target/i386/avx512f-gather-2.c: Ditto.
* gcc.target/i386/avx512f-gather-3.c: Ditto.
* gcc.target/i386/avx512f-gather-4.c: Ditto.
* gcc.target/i386/avx512f-gather-5.c: Ditto.
* gcc.target/i386/avx512f-i32gatherd512-1.c: Ditto.
* gcc.target/i386/avx512f-i32gatherd512-2.c: Ditto.
* gcc.target/i386/avx512f-i32gatherpd512-1.c: Ditto.
* gcc.target/i386/avx512f-i32gatherpd512-2.c: Ditto.
* gcc.target/i386/avx512f-i32gatherps512-1.c: Ditto.
* gcc.target/i386/avx512f-vect-perm-1.c: Ditto.
* gcc.target/i386/avx512f-vect-perm-2.c: Ditto.
* gcc.target/i386/avx512pf-vgatherpf0dpd-1.c: Ditto.
* gcc.target/i386/avx512pf-vgatherpf0dps-1.c: Ditto.
* gcc.target/i386/avx512pf-vgatherpf0qpd-1.c: Ditto.
* gcc.target/i386/avx512pf-vgatherpf0qps-1.c: Ditto.
* gcc.target/i386/avx512pf-vgatherpf1dpd-1.c: Ditto.
* gcc.target/i386/avx512pf-vgatherpf1dps-1.c: Ditto.
* gcc.target/i386/avx512pf-vgatherpf1qpd-1.c: Ditto.
* gcc.target/i386/avx512pf-vgatherpf1qps-1.c: Ditto.
* gcc.target/i386/avx512pf-vscatterpf0dpd-1.c: Ditto.
* gcc.target/i386/avx512pf-vscatterpf0dps-1.c: Ditto.
* gcc.target/i386/avx512pf-vscatterpf0qpd-1.c: Ditto.
* gcc.target/i386/avx512pf-vscatterpf0qps-1.c: Ditto.
* gcc.target/i386/avx512pf-vscatterpf1dpd-1.c: Ditto.
* gcc.target/i386/avx512pf-vscatterpf1dps-1.c: Ditto.
* gcc.target/i386/avx512pf-vscatterpf1qpd-1.c: Ditto.
* gcc.target/i386/avx512pf-vscatterpf1qps-1.c: Ditto.
* gcc.target/i386/funcspec-56.inc: Ditto.
* gcc.target/i386/pr101395-2.c: Ditto.
* gcc.target/i386/pr101395-3.c: Ditto.
* gcc.target/i386/pr103404.c: Ditto.
* gcc.target/i386/pr104448.c: Ditto.
* gcc.target/i386/pr107934.c: Ditto.
* gcc.target/i386/pr57275.c: Ditto.
* gcc.target/i386/pr64387.c: Ditto.
* gcc.target/i386/pr70728.c: Ditto.
* gcc.target/i386/pr71346.c: Ditto.
* gcc.target/i386/pr82941-2.c: Ditto.
* gcc.target/i386/pr82942-1.c: Ditto.
* 

[RFC] i386: Remove Xeon Phi ISA support

[Haochen Jiang]

Hi all,

Since Knight Landing and Knight Mill microarchitectures were EOL in 2019
and previously ICC and ICX has removed the support and emitted errors, we
would also like to remove the support in GCC to reduce maintainence effort.
The deprecated Xeon Phi ISAs are AVX512PF, AVX512ER, AVX5124VNNIW,
AVX5124FMAPS, PREFETCHWT1.

Our plan is to first emit a warning in GCC 14 to indicate that we will remove
them in GCC 15. And in GCC 15, we will remove the support if there is no
objection.

The patch following is the GCC 14 patch which mark them as deprecated.

Regtested on x86_64-pc-linux-gnu. Ok for trunk?

Thx,
Haochen

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

[Xi Ruoyao]

On Thu, 2023-11-30 at 08:44 -0700, Jeff Law wrote:
> 
> 
> On 11/29/23 02:33, Xi Ruoyao wrote:
> > On Mon, 2023-11-27 at 23:06 -0700, Jeff Law wrote:
> > > This has (of course) been tested on rv64.  It's also been bootstrapped
> > > and regression tested on x86.  Bootstrap and regression tested (C only)
> > > for m68k, sh4, sh4eb, alpha.  Earlier versions were also bootstrapped
> > > and regression tested on ppc, hppa and s390x (C only for those as well).
> > >    It's also been tested on the various crosses in my tester.  So we've
> > > got reasonable coverage of 16, 32 and 64 bit targets, big and little
> > > endian, with and without SHIFT_COUNT_TRUNCATED and all kinds of other
> > > oddities.
> > > 
> > > The included tests are for RISC-V only because not all targets are going
> > > to have extraneous extensions.   There's tests from coremark, x264 and
> > > GCC's bz database.  It probably wouldn't be hard to add aarch64
> > > testscases.  The BZs listed are improved by this patch for aarch64.
> > 
> > I've successfully bootstrapped this on loongarch64-linux-gnu and tried
> > the added test cases.  For loongarch64 the redundant extensions are
> > removed for core_bench_list.c, core_init_matrix.c, core_list_init.c,
> > matrix_add_const.c, and pr111384.c, but not mem-extend.c.
> > 
> > Should I change something in LoongArch backend in order to make ext_dce
> > work for mem-extend.c too?  If yes then any pointers?
> I'd bet it was my goof removing MINUS from the list of supported opcodes 
> where we can use narrowing life information from the destination to 
> narrow the lifetime of the sources.
> 
> Try adding MINUS back into safe_for_live_propagation.

I can confirm it works for this this case, and bootstrap & regtest still
fine on LoongArch.

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

Re: [RFA] New pass for sign/zero extension elimination

[Hans-Peter Nilsson]

> Date: Sun, 19 Nov 2023 17:47:56 -0700
> From: Jeff Law 

> Locally we have had this enabled at -O1 and above to encourage testing, 
> but I'm thinking that for the trunk enabling at -O2 and above is the 
> right thing to do.

Yes.

> Thoughts, comments, recommendations?

Sounds great!

It'd be nice if its framework can be re-used for
target-specific passes, doing quirky sign- or zero-extend-
related optimizations (those that are not just sign- or
zero-extend removal).  Perhaps most of those opportunities
can be implemented as target hooks in this pass.  Definitely
not asking for a change, just imagining future improvements.

Also, I haven't followed the thread and its branches, just
offering a word encouragement.

brgds, H-P

Re: [PATCH] RISC-V: Vectorized str(n)cmp and strlen.

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

Ah.  I see:

--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -2336,9 +2336,7 @@ (define_expand "cpymem"
  (use (match_operand:SI 3 "const_int_operand"))])]
   ""
 {
-  if (riscv_vector::expand_block_move (operands[0], operands[1], operands[2]))
-DONE;
-  else if (riscv_expand_block_move (operands[0], operands[1], operands[2]))
+  if (riscv_expand_block_move (operands[0], operands[1], operands[2]))
 DONE;

I think it should be an NFC patch in another separate patch.



juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2023-12-01 06:22
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Vectorized str(n)cmp and strlen.
Hi,
 
this adds vectorized implementations of strcmp and strncmp as well as
strlen.  strlen falls back to the previously implemented rawmemchr.
Also, it fixes a rawmemchr bug causing a SPEC2017 execution failure:
We would only ever increment the source address by 1 regardless of
the input type.
 
The patch also changes the stringop-strategy handling slightly:
auto is now an aggregate (including vector and scalar,
possibly more in the future) and expansion functions try all
matching strategies in their preferred order.
 
As before, str* expansion is guarded by -minline-str* and not active
by default.  This might change in the future as I would rather have
those on by default.  As of now, though, there is still a latent bug:
 
With -minline-strlen and -minline-strcmp we have several execution
failures in gcc.c-torture/execute/builtins/.  From my initial analysis
it looks like we don't insert a vsetvl at the right spot (which would
be right after a setjmp in those cases).  This leaves the initial
vle8ff without a proper vtype or vl causing a SIGILL.
Still, I figured I'd rather post the patch as-is so the bug can be
reproduced upstream.
 
Regards
Robin
 
gcc/ChangeLog:
 
PR target/112109
 
* config/riscv/riscv-opts.h (enum riscv_stringop_strategy_enum):
Rename.
(enum stringop_strategy_enum): To this.
* config/riscv/riscv-protos.h (expand_rawmemchr): Add strlen
param.
(expand_strcmp): Define.
* config/riscv/riscv-string.cc (riscv_expand_strcmp):  Add
vector version.
(riscv_expand_strlen): Ditto.
(riscv_expand_block_move_scalar): Handle existing scalar expansion.
(riscv_expand_block_move): Expand to either vector or scalar
version.
(expand_block_move): Add stringop strategy.
(expand_rawmemchr): Handle strlen and fix increment bug.
(expand_strcmp): New expander.
* config/riscv/riscv.md: Add vector.
* config/riscv/riscv.opt: Ditto.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/autovec/builtin/strcmp-run.c: New test.
* gcc.target/riscv/rvv/autovec/builtin/strcmp.c: New test.
* gcc.target/riscv/rvv/autovec/builtin/strlen-run.c: New test.
* gcc.target/riscv/rvv/autovec/builtin/strlen.c: New test.
---
gcc/config/riscv/riscv-opts.h |  20 +-
gcc/config/riscv/riscv-protos.h   |   4 +-
gcc/config/riscv/riscv-string.cc  | 287 +++---
gcc/config/riscv/riscv.md |  18 +-
gcc/config/riscv/riscv.opt|  18 +-
.../riscv/rvv/autovec/builtin/strcmp-run.c|  32 ++
.../riscv/rvv/autovec/builtin/strcmp.c|  13 +
.../riscv/rvv/autovec/builtin/strlen-run.c|  37 +++
.../riscv/rvv/autovec/builtin/strlen.c|  12 +
9 files changed, 363 insertions(+), 78 deletions(-)
create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/builtin/strcmp-run.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/builtin/strcmp.c
create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/builtin/strlen-run.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/builtin/strlen.c
 
diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index e6e55ad7071..315f6ddb239 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -103,16 +103,16 @@ enum riscv_entity
   MAX_RISCV_ENTITIES
};
-/* RISC-V stringop strategy. */
-enum riscv_stringop_strategy_enum {
-  /* Use scalar or vector instructions. */
-  USE_AUTO,
-  /* Always use a library call. */
-  USE_LIBCALL,
-  /* Only use scalar instructions. */
-  USE_SCALAR,
-  /* Only use vector instructions. */
-  USE_VECTOR
+/* RISC-V builtin strategy. */
+enum stringop_strategy_enum {
+  /* No expansion. */
+  STRINGOP_STRATEGY_LIBCALL = 1,
+  /* Use scalar expansion if possible. */
+  STRINGOP_STRATEGY_SCALAR = 2,
+  /* Only vector expansion if possible. */
+  STRINGOP_STRATEGY_VECTOR = 4,
+  /* Use any. */
+  STRINGOP_STRATEGY_AUTO = STRINGOP_STRATEGY_SCALAR | STRINGOP_STRATEGY_VECTOR
};
#define TARGET_ZICOND_LIKE (TARGET_ZICOND || (TARGET_XVENTANACONDOPS && 
TARGET_64BIT))
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 695ee24ad6f..51359154846 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -557,7 +557,9 @@ void expand_cond_unop (unsigned, rtx *);
void 

Re: [PATCH] RISC-V: Vectorized str(n)cmp and strlen.

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

Hi, Robin.

Thanks for working on this. I know this is a tedious work.

A couple comments here:


-  if (TARGET_ZBB || TARGET_XTHEADBB)
+  if (TARGET_VECTOR && stringop_strategy & STRINGOP_STRATEGY_VECTOR)
+{
+  bool ok = riscv_vector::expand_strcmp (result, src1, src2, bytes_rtx,
+alignment, ncompare);
+  if (ok)
+   return true;
+}
+  if (TARGET_VECTOR && (stringop_strategy & STRINGOP_STRATEGY_VECTOR))
+{
+  riscv_vector::expand_rawmemchr (E_QImode, result, src, search_char,
+ /* strlen */ true);
+  return true;
+}

To make code consistent, I think you should change it cpymem:
(define_expand "cpymem"
  [(parallel [(set (match_operand:BLK 0 "general_operand")
   (match_operand:BLK 1 "general_operand"))
(use (match_operand:P 2 ""))
(use (match_operand:SI 3 "const_int_operand"))])]
  ""
{
  if (riscv_vector::expand_block_move (operands[0], operands[1], operands[2]))
DONE;
  else if (riscv_expand_block_move (operands[0], operands[1], operands[2]))
DONE;
  else
FAIL;
})

Or you should change cpymem code first (in another patch) like strcmp/strlen 
you did in this patch.

I don't have strong opinion here, depend on you.

 -bool
-riscv_expand_block_move (rtx dest, rtx src, rtx length)
+static bool
+riscv_expand_block_move_scalar (rtx dest, rtx src, rtx length)
 {
-  if (riscv_memcpy_strategy == USE_LIBCALL
-  || riscv_memcpy_strategy == USE_VECTOR)
+  if (!CONST_INT_P (length))
 return false;
 
-  if (CONST_INT_P (length))
-{
-  unsigned HOST_WIDE_INT hwi_length = UINTVAL (length);
-  unsigned HOST_WIDE_INT factor, align;
+  unsigned HOST_WIDE_INT hwi_length = UINTVAL (length);
+  unsigned HOST_WIDE_INT factor, align;
 
-  align = MIN (MIN (MEM_ALIGN (src), MEM_ALIGN (dest)), BITS_PER_WORD);
-  factor = BITS_PER_WORD / align;
+  align = MIN (MIN (MEM_ALIGN (src), MEM_ALIGN (dest)), BITS_PER_WORD);
+  factor = BITS_PER_WORD / align;
 
-  if (optimize_function_for_size_p (cfun)
- && hwi_length * factor * UNITS_PER_WORD > MOVE_RATIO (false))
-   return false;
+  if (optimize_function_for_size_p (cfun)
+  && hwi_length * factor * UNITS_PER_WORD > MOVE_RATIO (false))
+return false;
 
-  if (hwi_length <= (RISCV_MAX_MOVE_BYTES_STRAIGHT / factor))
+  if (hwi_length <= (RISCV_MAX_MOVE_BYTES_STRAIGHT / factor))
+{
+  riscv_block_move_straight (dest, src, INTVAL (length));
+  return true;
+}
+  else if (optimize && align >= BITS_PER_WORD)
+{
+  unsigned min_iter_words
+   = RISCV_MAX_MOVE_BYTES_PER_LOOP_ITER / UNITS_PER_WORD;
+  unsigned iter_words = min_iter_words;
+  unsigned HOST_WIDE_INT bytes = hwi_length;
+  unsigned HOST_WIDE_INT words = bytes / UNITS_PER_WORD;
+
+  /* Lengthen the loop body if it shortens the tail.  */
+  for (unsigned i = min_iter_words; i < min_iter_words * 2 - 1; i++)
{
- riscv_block_move_straight (dest, src, INTVAL (length));
- return true;
+ unsigned cur_cost = iter_words + words % iter_words;
+ unsigned new_cost = i + words % i;
+ if (new_cost <= cur_cost)
+   iter_words = i;
}
-  else if (optimize && align >= BITS_PER_WORD)
-   {
- unsigned min_iter_words
-   = RISCV_MAX_MOVE_BYTES_PER_LOOP_ITER / UNITS_PER_WORD;
- unsigned iter_words = min_iter_words;
- unsigned HOST_WIDE_INT bytes = hwi_length;
- unsigned HOST_WIDE_INT words = bytes / UNITS_PER_WORD;
-
- /* Lengthen the loop body if it shortens the tail.  */
- for (unsigned i = min_iter_words; i < min_iter_words * 2 - 1; i++)
-   {
- unsigned cur_cost = iter_words + words % iter_words;
- unsigned new_cost = i + words % i;
- if (new_cost <= cur_cost)
-   iter_words = i;
-   }
 
- riscv_block_move_loop (dest, src, bytes, iter_words * UNITS_PER_WORD);
- return true;
-   }
+  riscv_block_move_loop (dest, src, bytes, iter_words * UNITS_PER_WORD);
+  return true;
+}
+
+  return false;
+}
I don't understand why you touch scalar part here ? It looks like formating ?
If yes, it should be another separate patch.

Otherwise, Ok from my side.



juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2023-12-01 06:22
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Vectorized str(n)cmp and strlen.
Hi,
 
this adds vectorized implementations of strcmp and strncmp as well as
strlen.  strlen falls back to the previously implemented rawmemchr.
Also, it fixes a rawmemchr bug causing a SPEC2017 execution failure:
We would only ever increment the source address by 1 regardless of
the input type.
 
The patch also changes the stringop-strategy handling slightly:
auto is now an aggregate (including vector and scalar,
possibly more in the 

[PATCH] RISC-V: Fix VSETVL PASS regression

[Juzhe-Zhong]

This patch fix 2 regression (one is bug regression, the other is performance 
regression).
Those 2 regressions are both we are comparing ratio for same AVL in wrong place.

1. BUG regression:
avl_single-84.c:

f0:
li  a5,999424
add a1,a1,a5
li  a4,299008
add a5,a0,a5
addia3,a4,992
addia5,a5,576
addia1,a1,576
vsetvli a4,zero,e8,m2,ta,ma
add a0,a0,a3
vlm.v   v1,0(a5)
vsm.v   v1,0(a1)
vl1re64.v   v1,0(a0)
beq a2,zero,.L10
li  a5,0
vsetvli zero,zero,e64,m1,tu,ma   --->  This is totally incorrect since 
the ratio above is 4, wheras it is demanding ratio = 64 here.
.L3:
fcvt.d.lu   fa5,a5
addia5,a5,1
fadd.d  fa5,fa5,fa0
vfmv.s.fv1,fa5
bne a5,a2,.L3
vfmv.f.sfa0,v1
ret
.L10:
vsetvli zero,zero,e64,m1,ta,ma
vfmv.f.sfa0,v1
ret

2. Performance regression:

before this patch:

vsetvli a5,a4,e8,m1,ta,ma
vsetvli zero,a5,e32,m1,tu,ma
vmv.s.x v2,zero
vmv.s.x v1,zero
vsetvli zero,a5,e32,m4,tu,ma
vle32.v v4,0(a1)
vfmul.vvv4,v4,v4
vfredosum.vsv1,v4,v2
vfmv.f.sfa5,v1
fsw fa5,0(a0)
sub a4,a4,a5
bne a4,zero,.L2
ret

After this patch:

vsetvli a5,a4,e32,m4,tu,ma
vle32.v v4,0(a1)
vmv.s.x v2,zero
vmv.s.x v1,zero
vfmul.vvv4,v4,v4
vfredosum.vsv1,v4,v2
vfmv.f.sfa5,v1
fsw fa5,0(a0)
sub a4,a4,a5
bne a4,zero,.L2
ret

Tested rv64gcv_zvfh_zfh passed no regression.

zvl256b/zvl512b/zvl1024b/zve64d is runing.

PR target/112776

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc (pre_vsetvl::pre_global_vsetvl_info): 
Fix ratio.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/vsetvl/avl_single-84.c: Adapt test.
* gcc.target/riscv/rvv/vsetvl/pr111037-3.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/pr112776.c: New test.

---
 gcc/config/riscv/riscv-vsetvl.cc  | 13 ---
 .../riscv/rvv/vsetvl/avl_single-84.c  |  6 ++--
 .../gcc.target/riscv/rvv/vsetvl/pr111037-3.c  |  2 +-
 .../gcc.target/riscv/rvv/vsetvl/pr112776.c| 36 +++
 4 files changed, 46 insertions(+), 11 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/pr112776.c

diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc
index b3e07d4c3aa..1da95daeeb0 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -1497,9 +1497,6 @@ private:
   {
 gcc_assert (prev.valid_p () && next.valid_p ());
 
-if (prev.get_ratio () != next.get_ratio ())
-  return false;
-
 if (next.has_vl () && next.vl_used_by_non_rvv_insn_p ())
   return false;
 
@@ -2188,7 +2185,7 @@ private:
 return true;
   }
 
-  bool preds_has_same_avl_p (const vsetvl_info _info)
+  bool preds_all_same_avl_and_ratio_p (const vsetvl_info _info)
   {
 gcc_assert (
   !bitmap_empty_p (m_vsetvl_def_in[curr_info.get_bb ()->index ()]));
@@ -2200,7 +2197,8 @@ private:
   {
const vsetvl_info _info = *m_vsetvl_def_exprs[expr_index];
if (!prev_info.valid_p ()
-   || !m_dem.avl_available_p (prev_info, curr_info))
+   || !m_dem.avl_available_p (prev_info, curr_info)
+   || prev_info.get_ratio () != curr_info.get_ratio ())
  return false;
   }
 
@@ -3171,7 +3169,7 @@ pre_vsetvl::pre_global_vsetvl_info ()
  curr_info = block_info.local_infos[0];
}
   if (curr_info.valid_p () && !curr_info.vl_used_by_non_rvv_insn_p ()
- && preds_has_same_avl_p (curr_info))
+ && preds_all_same_avl_and_ratio_p (curr_info))
curr_info.set_change_vtype_only ();
 
   vsetvl_info prev_info = vsetvl_info ();
@@ -3179,7 +3177,8 @@ pre_vsetvl::pre_global_vsetvl_info ()
   for (auto _info : block_info.local_infos)
{
  if (prev_info.valid_p () && curr_info.valid_p ()
- && m_dem.avl_available_p (prev_info, curr_info))
+ && m_dem.avl_available_p (prev_info, curr_info)
+ && prev_info.get_ratio () == curr_info.get_ratio ())
curr_info.set_change_vtype_only ();
  prev_info = curr_info;
}
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-84.c 
b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-84.c
index a584dd97dc0..5cd0f285029 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-84.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-84.c
@@ -17,6 +17,6 @@ double f0 (int8_t * restrict in, int8_t * restrict out, int 
n, int m, unsigned c
 }
 
 /* { dg-final { scan-assembler-times 
{vsetvli\s+[a-x0-9]+,\s*zero,\s*e8,\s*m2,\s*t[au],\s*m[au]} 1 { target 

Re: [PATCH] RISC-V: Vectorized str(n)cmp and strlen.

[Jeff Law]

On 11/30/23 15:22, Robin Dapp wrote:

Hi,

this adds vectorized implementations of strcmp and strncmp as well as
strlen.  strlen falls back to the previously implemented rawmemchr.
Also, it fixes a rawmemchr bug causing a SPEC2017 execution failure:
We would only ever increment the source address by 1 regardless of
the input type.

The patch also changes the stringop-strategy handling slightly:
auto is now an aggregate (including vector and scalar,
possibly more in the future) and expansion functions try all
matching strategies in their preferred order.

As before, str* expansion is guarded by -minline-str* and not active
by default.  This might change in the future as I would rather have
those on by default.  As of now, though, there is still a latent bug:

With -minline-strlen and -minline-strcmp we have several execution
failures in gcc.c-torture/execute/builtins/.  From my initial analysis
it looks like we don't insert a vsetvl at the right spot (which would
be right after a setjmp in those cases).  This leaves the initial
vle8ff without a proper vtype or vl causing a SIGILL.
Still, I figured I'd rather post the patch as-is so the bug can be
reproduced upstream.

Regards
  Robin

gcc/ChangeLog:

PR target/112109

* config/riscv/riscv-opts.h (enum riscv_stringop_strategy_enum):
Rename.
(enum stringop_strategy_enum): To this.
* config/riscv/riscv-protos.h (expand_rawmemchr): Add strlen
param.
(expand_strcmp): Define.
* config/riscv/riscv-string.cc (riscv_expand_strcmp):  Add
vector version.
(riscv_expand_strlen): Ditto.
(riscv_expand_block_move_scalar): Handle existing scalar expansion.
(riscv_expand_block_move): Expand to either vector or scalar
version.
(expand_block_move): Add stringop strategy.
(expand_rawmemchr): Handle strlen and fix increment bug.
(expand_strcmp): New expander.
* config/riscv/riscv.md: Add vector.
* config/riscv/riscv.opt: Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/builtin/strcmp-run.c: New test.
* gcc.target/riscv/rvv/autovec/builtin/strcmp.c: New test.
* gcc.target/riscv/rvv/autovec/builtin/strlen-run.c: New test.
* gcc.target/riscv/rvv/autovec/builtin/strlen.c: New test.
Do you want to extract the rawmemchr fix and push it forward 
independently?  Or do we think the vsetvl issue will be resolved quickly 
enough that extraction of that fix would just be "make work"?


Jeff

Re: [PATCH] htdocs/git.html: correct spelling and use git in example

[Joseph Myers]

On Thu, 30 Nov 2023, Jonny Grant wrote:

> ChangeLog:
> 
>   htdocs/git.html: change example to use git:// and correct
>   spelling repostiory -> repository .

git:// (unencrypted / unauthenticated) is pretty widely considered 
obsolescent, I'm not sure adding a use of it (as opposed to changing any 
existing examples to use a secure connection mechanism) is a good idea.

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

Re: [PATCH v5] c++: implement P2564, consteval needs to propagate up [PR107687]

[Jason Merrill]

On 11/23/23 11:46, Marek Polacek wrote:

v5 greatly simplifies the code.


Indeed, it's much cleaner now.


I still need a new ff_ flag to signal that we can return immediately
after seeing an i-e expr.


That's still not clear to me:


+  /* In turn, maybe promote the function we find ourselves in...  */
+  if ((data->flags & ff_find_escalating_expr)
+ && DECL_IMMEDIATE_FUNCTION_P (decl)
+ /* ...but not if the call to DECL was constant; that is the
+"an immediate invocation that is not a constant expression"
+case.  */
+ && (e = cxx_constant_value (stmt, tf_none), e == error_mark_node))
+   {
+ /* Since we had to set DECL_ESCALATION_CHECKED_P before the walk,
+we call promote_function_to_consteval directly which doesn't
+check unchecked_immediate_escalating_function_p.  */
+ if (current_function_decl)
+   promote_function_to_consteval (current_function_decl);
+ *walk_subtrees = 0;
+ return stmt;
+   }


This is the one use of ff_find_escalating_expr, and it seems redundant 
with the code immediately below, where we use complain (derived from 
ff_mce_false) to decide whether to return immediately.  Can we remove 
this hunk and the flag, and merge find_escalating_expr with 
cp_fold_immediate?


I think you want to walk the function body for three-ish reasons:
1) at EOF, to check for escalation
2) at EOF, to check for errors
3) at error time, to explain escalation

It's not clear to me that we need a flag to distinguish between them. 
When we encounter an immediate-escalating expression E:


A) if we're in an immediate-escalating function, escalate and return E 
(#1, #3).

B) otherwise, if we're diagnosing, error and continue (#2).
C) otherwise, return E (individual expression mce_unknown walk from 
constexpr.cc).



@@ -1178,11 +1388,19 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void *data_
)
  *walk_subtrees = 0;
  /* Don't return yet, still need the cp_fold below.  */
}
-  cp_fold_immediate_r (stmt_p, walk_subtrees, data);
+  else
+   cp_fold_immediate_r (stmt_p, walk_subtrees, data);
 }
 
   *stmt_p = stmt = cp_fold (*stmt_p, data->flags);
 
+  /* For certain trees, like +foo(), the cp_fold below will remove the +,


s/below/above/?


+/* We've stashed immediate-escalating functions.  Now see if they indeed
+   ought to be promoted to consteval.  */
+
+void
+process_pending_immediate_escalating_fns ()
+{
+  /* This will be null for -fno-immediate-escalation.  */
+  if (!deferred_escalating_exprs)
+return;
+
+  for (auto e : *deferred_escalating_exprs)
+if (TREE_CODE (e) == FUNCTION_DECL && !DECL_ESCALATION_CHECKED_P (e))
+  cp_fold_immediate (_SAVED_TREE (e), mce_false, e);
+}
+
+/* We've escalated every function that could have been promoted to
+   consteval.  Check that we are not taking the address of a consteval
+   function.  */
+
+void
+check_immediate_escalating_refs ()
+{
+  /* This will be null for -fno-immediate-escalation.  */
+  if (!deferred_escalating_exprs)
+return;
+
+  for (auto ref : *deferred_escalating_exprs)
+{
+  if (TREE_CODE (ref) == FUNCTION_DECL)
+   continue;
+  tree decl = (TREE_CODE (ref) == PTRMEM_CST
+  ? PTRMEM_CST_MEMBER (ref)
+  : TREE_OPERAND (ref, 0));
+  if (DECL_IMMEDIATE_FUNCTION_P (decl))
+   taking_address_of_imm_fn_error (ref, decl);
+}
+
+  deferred_escalating_exprs = nullptr;
 }


Could these be merged, so you do a single loop of cp_fold_immediate over 
function bodies or non-function expressions?  I'd expect that to work.


Jason

[PATCH] btf: fix PR debug/112656

[Indu Bhagat]

PR debug/112656 - btf: function prototypes generated with name

With this patch, all BTF_KIND_FUNC_PROTO will appear anonymous in the
generated BTF section.

As noted in the discussion in the bugzilla, the number of
BTF_KIND_FUNC_PROTO types output varies across targets (BPF with -mco-re
vs non-BPF targets).  Hence the check in the test case merely checks
that all BTF_KIND_FUNC_PROTO appear anonymous.

gcc/ChangeLog:

PR debug/112656
* btfout.cc (btf_asm_type): Fixup ctti_name for all
BTF types of kind BTF_KIND_FUNC_PROTO.

gcc/testsuite/ChangeLog:

PR debug/112656
* gcc.dg/debug/btf/btf-function-7.c: New test.


Testing notes:
  - bootstrapped and reg tested on x86_64
  - No regressions in btf.exp on BPF target

---
 gcc/btfout.cc |  4 
 .../gcc.dg/debug/btf/btf-function-7.c | 19 +++
 2 files changed, 23 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-function-7.c

diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 1c25404b2c0..a5e0d640e19 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -820,6 +820,10 @@ btf_asm_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd)
btf_kind = BTF_KIND_ENUM64;
}
 
+  /* PR debug/112656.  BTF_KIND_FUNC_PROTO is always anonymous.  */
+  if (btf_kind == BTF_KIND_FUNC_PROTO)
+dtd->dtd_data.ctti_name = 0;
+
   dw2_asm_output_data (4, dtd->dtd_data.ctti_name,
   "TYPE %" PRIu64 " BTF_KIND_%s '%s'",
   get_btf_id (dtd->dtd_type), btf_kind_name (btf_kind),
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-function-7.c 
b/gcc/testsuite/gcc.dg/debug/btf/btf-function-7.c
new file mode 100644
index 000..b560dc75650
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-function-7.c
@@ -0,0 +1,19 @@
+/* Test BTF for inlined functions.
+
+   See PR/112656 - btf: function prototypes generated with name
+   BTF_KIND_FUNC_PROTO must be anonymous.  */
+
+/* { dg-do compile } */
+/* { dg-options "-O2 -gbtf -dA" } */
+
+/* { dg-final { scan-assembler-times "BTF_KIND_FUNC_PROTO 
''\\(\[0-9a-z\]*\\)'" 0 } } */
+
+static int log_event(const char *event_name, void *dev_ptr)
+{
+  return 666;
+}
+
+int foo ()
+{
+  return log_event ("foobar", ((void *)0));
+}
-- 
2.41.0

[PATCH] RISC-V: Vectorized str(n)cmp and strlen.

[Robin Dapp]

Hi,

this adds vectorized implementations of strcmp and strncmp as well as
strlen.  strlen falls back to the previously implemented rawmemchr.
Also, it fixes a rawmemchr bug causing a SPEC2017 execution failure:
We would only ever increment the source address by 1 regardless of
the input type.

The patch also changes the stringop-strategy handling slightly:
auto is now an aggregate (including vector and scalar,
possibly more in the future) and expansion functions try all
matching strategies in their preferred order.

As before, str* expansion is guarded by -minline-str* and not active
by default.  This might change in the future as I would rather have
those on by default.  As of now, though, there is still a latent bug:

With -minline-strlen and -minline-strcmp we have several execution
failures in gcc.c-torture/execute/builtins/.  From my initial analysis
it looks like we don't insert a vsetvl at the right spot (which would
be right after a setjmp in those cases).  This leaves the initial
vle8ff without a proper vtype or vl causing a SIGILL.
Still, I figured I'd rather post the patch as-is so the bug can be
reproduced upstream.

Regards
 Robin

gcc/ChangeLog:

PR target/112109

* config/riscv/riscv-opts.h (enum riscv_stringop_strategy_enum):
Rename.
(enum stringop_strategy_enum): To this.
* config/riscv/riscv-protos.h (expand_rawmemchr): Add strlen
param.
(expand_strcmp): Define.
* config/riscv/riscv-string.cc (riscv_expand_strcmp):  Add
vector version.
(riscv_expand_strlen): Ditto.
(riscv_expand_block_move_scalar): Handle existing scalar expansion.
(riscv_expand_block_move): Expand to either vector or scalar
version.
(expand_block_move): Add stringop strategy.
(expand_rawmemchr): Handle strlen and fix increment bug.
(expand_strcmp): New expander.
* config/riscv/riscv.md: Add vector.
* config/riscv/riscv.opt: Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/builtin/strcmp-run.c: New test.
* gcc.target/riscv/rvv/autovec/builtin/strcmp.c: New test.
* gcc.target/riscv/rvv/autovec/builtin/strlen-run.c: New test.
* gcc.target/riscv/rvv/autovec/builtin/strlen.c: New test.
---
 gcc/config/riscv/riscv-opts.h |  20 +-
 gcc/config/riscv/riscv-protos.h   |   4 +-
 gcc/config/riscv/riscv-string.cc  | 287 +++---
 gcc/config/riscv/riscv.md |  18 +-
 gcc/config/riscv/riscv.opt|  18 +-
 .../riscv/rvv/autovec/builtin/strcmp-run.c|  32 ++
 .../riscv/rvv/autovec/builtin/strcmp.c|  13 +
 .../riscv/rvv/autovec/builtin/strlen-run.c|  37 +++
 .../riscv/rvv/autovec/builtin/strlen.c|  12 +
 9 files changed, 363 insertions(+), 78 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/builtin/strcmp-run.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/builtin/strcmp.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/builtin/strlen-run.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/builtin/strlen.c

diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index e6e55ad7071..315f6ddb239 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -103,16 +103,16 @@ enum riscv_entity
   MAX_RISCV_ENTITIES
 };
 
-/* RISC-V stringop strategy. */
-enum riscv_stringop_strategy_enum {
-  /* Use scalar or vector instructions. */
-  USE_AUTO,
-  /* Always use a library call. */
-  USE_LIBCALL,
-  /* Only use scalar instructions. */
-  USE_SCALAR,
-  /* Only use vector instructions. */
-  USE_VECTOR
+/* RISC-V builtin strategy. */
+enum stringop_strategy_enum {
+  /* No expansion. */
+  STRINGOP_STRATEGY_LIBCALL = 1,
+  /* Use scalar expansion if possible. */
+  STRINGOP_STRATEGY_SCALAR = 2,
+  /* Only vector expansion if possible. */
+  STRINGOP_STRATEGY_VECTOR = 4,
+  /* Use any. */
+  STRINGOP_STRATEGY_AUTO = STRINGOP_STRATEGY_SCALAR | STRINGOP_STRATEGY_VECTOR
 };
 
 #define TARGET_ZICOND_LIKE (TARGET_ZICOND || (TARGET_XVENTANACONDOPS && 
TARGET_64BIT))
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 695ee24ad6f..51359154846 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -557,7 +557,9 @@ void expand_cond_unop (unsigned, rtx *);
 void expand_cond_binop (unsigned, rtx *);
 void expand_cond_ternop (unsigned, rtx *);
 void expand_popcount (rtx *);
-void expand_rawmemchr (machine_mode, rtx, rtx, rtx);
+void expand_rawmemchr (machine_mode, rtx, rtx, rtx, bool = false);
+bool expand_strcmp (rtx, rtx, rtx, rtx,
+   unsigned HOST_WIDE_INT, bool);
 void emit_vec_extract (rtx, rtx, poly_int64);
 
 /* Rounding mode bitfield for fixed point VXRM.  */
diff --git a/gcc/config/riscv/riscv-string.cc b/gcc/config/riscv/riscv-string.cc
index 

Re: [PATCH] preprocessor: Reinitialize frontend parser after loading a PCH [PR112319]

[Lewis Hyatt]

On Thu, Nov 30, 2023 at 4:19 PM Marek Polacek  wrote:
>
> On Wed, Nov 01, 2023 at 05:54:57PM -0400, Lewis Hyatt wrote:
> > Hello-
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112319
> >
> > This is a one-line patch to fix the GCC 14 regression noted in the
> > PR. Bootstrap + regtest all languages on x86-64 looks good. Is it OK please?
> > Thanks!
> >
> > -Lewis
> >
> > -- >8 --
> >
> > Since r14-2893, the frontend parser object needs to exist when running in
> > preprocess-only mode, because pragma_lex() is now called in that mode and
> > needs to make use of it. This is handled by calling c_init_preprocess() at
> > startup. If -fpch-preprocess is in effect (commonly, because of
> > -save-temps), a PCH file may be loaded during preprocessing, in which
> > case the parser will be destroyed, causing the issue noted in the
> > PR. Resolve it by reinitializing the frontend parser after loading the PCH.
> >
> > gcc/c-family/ChangeLog:
> >
> >   PR pch/112319
> >   * c-ppoutput.cc (cb_read_pch): Reinitialize the frontend parser
>
> "front-end"
>
> >   after loading a PCH.
> >
> > gcc/testsuite/ChangeLog:
> >
> >   PR pch/112319
> >   * g++.dg/pch/pr112319.C: New test.
> >   * g++.dg/pch/pr112319.Hs: New test.
> >   * gcc.dg/pch/pr112319.c: New test.
> >   * gcc.dg/pch/pr112319.hs: New test.
> > ---
> >  gcc/c-family/c-ppoutput.cc   | 5 +
> >  gcc/testsuite/g++.dg/pch/pr112319.C  | 5 +
> >  gcc/testsuite/g++.dg/pch/pr112319.Hs | 1 +
> >  gcc/testsuite/gcc.dg/pch/pr112319.c  | 5 +
> >  gcc/testsuite/gcc.dg/pch/pr112319.hs | 1 +
> >  5 files changed, 17 insertions(+)
> >  create mode 100644 gcc/testsuite/g++.dg/pch/pr112319.C
> >  create mode 100644 gcc/testsuite/g++.dg/pch/pr112319.Hs
> >  create mode 100644 gcc/testsuite/gcc.dg/pch/pr112319.c
> >  create mode 100644 gcc/testsuite/gcc.dg/pch/pr112319.hs
> >
> > diff --git a/gcc/c-family/c-ppoutput.cc b/gcc/c-family/c-ppoutput.cc
> > index 4aa2bef2c0f..4f973767976 100644
> > --- a/gcc/c-family/c-ppoutput.cc
> > +++ b/gcc/c-family/c-ppoutput.cc
> > @@ -862,4 +862,9 @@ cb_read_pch (cpp_reader *pfile, const char *name,
> >
> >fprintf (print.outf, "#pragma GCC pch_preprocess \"%s\"\n", name);
> >print.src_line++;
> > +
> > +  /* The process of reading the PCH has destroyed the frontend parser,
>
> "front-end"
>
> > + so ask the frontend to reinitialize it, in case we need it to
>
> "front end"
>
> (sorry to be overly pedantic...)
>
> Patch looks fine to me; please go ahead if you haven't pushed it already.
>

Thanks for the review! I did push it a few days ago as Jakub approved
it... I will spell front end correctly next time :).

-Lewis

[PATCH] btf: fix PR debug/112768

[Indu Bhagat]

PR debug/112768 - btf: fix asm comment output for BTF_KIND_FUNC* kinds

The patch adds a small function to abstract out the detail and return
the name of the type.  The patch also fixes the issue of BTF_KIND_FUNC
appearing in the comments with a 'null' string.

For btf-function-6.c testcase, after the patch:

.long   0   # TYPE 2 BTF_KIND_FUNC_PROTO ''
.long   0xd02   # btt_info: kind=13, kflag=0, vlen=2
.long   0x1 # btt_type: (BTF_KIND_INT 'int')
.long   0   # farg_name
.long   0x1 # farg_type: (BTF_KIND_INT 'int')
.long   0   # farg_name
.long   0x1 # farg_type: (BTF_KIND_INT 'int')
.long   0   # TYPE 3 BTF_KIND_FUNC_PROTO ''
.long   0xd01   # btt_info: kind=13, kflag=0, vlen=1
.long   0x1 # btt_type: (BTF_KIND_INT 'int')
.long   0x68# farg_name
.long   0x1 # farg_type: (BTF_KIND_INT 'int')
.long   0x5 # TYPE 4 BTF_KIND_FUNC 'extfunc'
.long   0xc02   # btt_info: kind=12, kflag=0, linkage=2
.long   0x2 # btt_type: (BTF_KIND_FUNC_PROTO '')
.long   0xd # TYPE 5 BTF_KIND_FUNC 'foo'
.long   0xc01   # btt_info: kind=12, kflag=0, linkage=1
.long   0x3 # btt_type: (BTF_KIND_FUNC_PROTO '')

gcc/ChangeLog:

PR debug/112768
* btfout.cc (get_btf_type_name): New definition.
(btf_collect_datasec): Update dtd_name to the original type name
string.
(btf_asm_type_ref): Use the new get_btf_type_name function
instead.
(btf_asm_type): Likewise.
(btf_asm_func_type): Likewise.

gcc/testsuite/ChangeLog:

PR debug/112768
* gcc.dg/debug/btf/btf-function-6.c: Empty string expected with
BTF_KIND_FUNC_PROTO.

Testing notes:
  - bootstrapped and reg tested on x86_64
  - No regressions in btf.exp on BPF target

---
 gcc/btfout.cc | 22 +++
 .../gcc.dg/debug/btf/btf-function-6.c |  4 ++--
 2 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 5f2e99ce472..1c25404b2c0 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -158,6 +158,19 @@ get_btf_kind (uint32_t ctf_kind)
   return BTF_KIND_UNKN;
 }
 
+/* Some BTF types, like BTF_KIND_FUNC_PROTO, are anonymous.  The machinery
+   in btfout to emit BTF, may reset dtd_data->ctti_name, but does not update
+   the name in the ctf_dtdef_ref type object (deliberate choice).  This
+   interface helps abstract out that state of affairs, while giving access to
+   the name of the type as intended.  */
+
+static const char *
+get_btf_type_name (ctf_dtdef_ref dtd)
+{
+  const char *anon = "";
+  return (dtd->dtd_data.ctti_name) ? dtd->dtd_name : anon;
+}
+
 /* Helper routines to map between 'relative' and 'absolute' IDs.
 
In BTF all records (including variables) are output in one long list, and 
all
@@ -425,6 +438,7 @@ btf_collect_datasec (ctf_container_ref ctfc)
   func_dtd->dtd_data = dtd->dtd_data;
   func_dtd->dtd_data.ctti_type = dtd->dtd_type;
   func_dtd->linkage = dtd->linkage;
+  func_dtd->dtd_name = dtd->dtd_name;
   func_dtd->dtd_type = num_types_added + num_types_created;
 
   /* Only the BTF_KIND_FUNC type actually references the name. The
@@ -722,7 +736,7 @@ btf_asm_type_ref (const char *prefix, ctf_container_ref 
ctfc, ctf_id_t ref_id)
   size_t func_id = btf_relative_func_id (ref_id);
   ctf_dtdef_ref ref_type = (*funcs)[func_id];
   dw2_asm_output_data (4, ref_id, "%s: (BTF_KIND_FUNC '%s')",
-  prefix, ref_type->dtd_name);
+  prefix, get_btf_type_name (ref_type));
 }
   else
 {
@@ -733,7 +747,7 @@ btf_asm_type_ref (const char *prefix, ctf_container_ref 
ctfc, ctf_id_t ref_id)
 
   dw2_asm_output_data (4, ref_id, "%s: (BTF_KIND_%s '%s')",
   prefix, btf_kind_name (ref_kind),
-  ref_type->dtd_name);
+  get_btf_type_name (ref_type));
 }
 }
 
@@ -809,7 +823,7 @@ btf_asm_type (ctf_container_ref ctfc, ctf_dtdef_ref dtd)
   dw2_asm_output_data (4, dtd->dtd_data.ctti_name,
   "TYPE %" PRIu64 " BTF_KIND_%s '%s'",
   get_btf_id (dtd->dtd_type), btf_kind_name (btf_kind),
-  dtd->dtd_name);
+  get_btf_type_name (dtd));
   dw2_asm_output_data (4, BTF_TYPE_INFO (btf_kind, btf_kflag, btf_vlen),
   "btt_info: kind=%u, kflag=%u, vlen=%u",
   btf_kind, btf_kflag, btf_vlen);
@@ -950,7 +964,7 @@ btf_asm_func_type (ctf_container_ref ctfc, ctf_dtdef_ref 
dtd, ctf_id_t id)
   ctf_id_t ref_id = dtd->dtd_data.ctti_type;
   dw2_asm_output_data (4, dtd->dtd_data.ctti_name,
   "TYPE %" PRIu64 " BTF_KIND_FUNC '%s'",
-  btf_absolute_func_id (id), dtd->dtd_name);
+  

Re: [PATCH] libgccjit: Add vector permutation and vector access operations

[Antoni Boucher]

All of these are fixed in this new patch.
Thanks for the review.

On Mon, 2023-11-20 at 18:05 -0500, David Malcolm wrote:
> On Fri, 2023-11-17 at 17:36 -0500, Antoni Boucher wrote:
> > Hi.
> > This patch adds a vector permutation and vector access operations
> > (bug
> > 112602).
> > 
> > This was split from this patch:
> > https://gcc.gnu.org/pipermail/jit/2023q1/001606.html
> > 
> 
> Thanks for the patch.
> 
> Overall, looks good, but 3 minor nitpicks:
> 
> [...snip...]
> 
> > diff --git a/gcc/jit/docs/topics/compatibility.rst
> > b/gcc/jit/docs/topics/compatibility.rst
> > index ebede440ee4..a764e3968d1 100644
> > --- a/gcc/jit/docs/topics/compatibility.rst
> > +++ b/gcc/jit/docs/topics/compatibility.rst
> > @@ -378,3 +378,13 @@ alignment of a variable:
> >  
> >  ``LIBGCCJIT_ABI_25`` covers the addition of
> >  :func:`gcc_jit_type_get_restrict`
> > +
> > +
> > +.. _LIBGCCJIT_ABI_26:
> > +
> > +``LIBGCCJIT_ABI_26``
> > +
> > +``LIBGCCJIT_ABI_26`` covers the addition of functions to
> > manipulate vectors:
> > +
> > +  * :func:`gcc_jit_context_new_rvalue_vector_perm`
> > +  * :func:`gcc_jit_context_new_vector_access`
> > diff --git a/gcc/jit/docs/topics/expressions.rst
> > b/gcc/jit/docs/topics/expressions.rst
> > index 42cfee36302..4a45aa13f5c 100644
> > --- a/gcc/jit/docs/topics/expressions.rst
> > +++ b/gcc/jit/docs/topics/expressions.rst
> > @@ -295,6 +295,35 @@ Vector expressions
> >  
> >    #ifdef LIBGCCJIT_HAVE_gcc_jit_context_new_rvalue_from_vector
> >  
> > +.. function:: gcc_jit_rvalue * \
> > +  gcc_jit_context_new_rvalue_vector_perm
> > (gcc_jit_context *ctxt, \
> > + 
> > gcc_jit_location *loc, \
> > + 
> > gcc_jit_rvalue *elements1, \
> > + 
> > gcc_jit_rvalue *elements2, \
> > + 
> > gcc_jit_rvalue *mask);
> > +
> > +   Build a permutation of two vectors.
> > +
> > +   "elements1" and "elements2" should have the same type.
> > +   The length of "mask" and "elements1" should be the same.
> > +   The element type of "mask" should be integral.
> > +   The size of the element type of "mask" and "elements1" should
> > be the same.
> > +
> > +   This entrypoint was added in :ref:`LIBGCCJIT_ABI_25`; you can
> > test for
>    ^^
> Should be 26
> 
> [...snip...]
> 
> >  Unary Operations
> >  
> >  
> > @@ -1020,3 +1049,27 @@ Field access is provided separately for both
> > lvalues and rvalues.
> >    PTR[INDEX]
> >  
> >     in C (or, indeed, to ``PTR + INDEX``).
> > +
> > +.. function:: gcc_jit_lvalue *\
> > +  gcc_jit_context_new_vector_access (gcc_jit_context
> > *ctxt,\
> > + gcc_jit_location
> > *loc,\
> > + gcc_jit_rvalue
> > *vector,\
> > + gcc_jit_rvalue
> > *index)
> > +
> > +   Given an rvalue of vector type ``T __attribute__
> > ((__vector_size__ (SIZE)))``, get the element `T` at
> > +   the given index.
> > +
> > +   This entrypoint was added in :ref:`LIBGCCJIT_ABI_25`; you can
> > test for
>    ^^
> 
> Likewise here.
> 
> [...snip...]
> 
> > @@ -4071,6 +4107,79 @@ gcc_jit_context_new_rvalue_from_vector
> > (gcc_jit_context *ctxt,
> >   (gcc::jit::recording::rvalue **)elements);
> >  }
> >  
> > +/* Public entrypoint.  See description in libgccjit.h.
> > +
> > +   After error-checking, the real work is done by the
> > +   gcc::jit::recording::context::new_rvalue_vector_perm method, in
> > +   jit-recording.cc.  */
> > +
> > +gcc_jit_rvalue *
> > +gcc_jit_context_new_rvalue_vector_perm (gcc_jit_context *ctxt,
> > +   gcc_jit_location *loc,
> > +   gcc_jit_rvalue *elements1,
> > +   gcc_jit_rvalue *elements2,
> > +   gcc_jit_rvalue *mask)
> > +{
> > +  RETURN_NULL_IF_FAIL (ctxt, NULL, loc, "NULL ctxt");
> > +  JIT_LOG_FUNC (ctxt->get_logger ());
> > +
> > +  /* LOC can be NULL.  */
> 
> ...but "elements1", "elements2", and "mask" must not be NULL, as
> they're dereferenced below.  So this is going to need something like
> the following (untested):
> 
>   RETURN_NULL_IF_FAIL (elements1, ctxt, loc, "NULL elements1");
>   RETURN_NULL_IF_FAIL (elements2, ctxt, loc, "NULL elements2");
>   RETURN_NULL_IF_FAIL (mask, ctxt, loc, "NULL mask");
> 
> [...snip...]
> 
> OK with those fixed.
> 
> Thanks
> Dave
> 

From 2fccdeac68464ee42a46a17607cd85cac0384902 Mon Sep 17 00:00:00 2001
From: Antoni Boucher 
Date: Fri, 17 Nov 2023 17:23:28 -0500
Subject: [PATCH] libgccjit: Add vector permutation and vector access
 operations

Re: [PATCH] libgccjit: Fix GGC segfault when using -flto

[Antoni Boucher]

Here's the updated patch.
The failure was due to the test being in the test array while it should
not have been there since it changes the context.

Thanks for the review.

On Sun, 2023-11-12 at 18:03 -0500, David Malcolm wrote:
> On Fri, 2023-11-10 at 18:14 -0500, David Malcolm wrote:
> > On Fri, 2023-11-10 at 11:02 -0500, Antoni Boucher wrote:
> > > Hi.
> > > This patch fixes the segfault when using -flto with libgccjit
> > > (bug
> > > 111396).
> > > 
> > > You mentioned in bugzilla that this didn't fix the reproducer for
> > > you,
> > 
> > Rereading https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111396 it
> > looks
> > like all I tested back in August was your reproducer; I didn't yet
> > test
> > your patch.
> > 
> > > but it does for me.
> > > At first, the test case would not pass, but running "make
> > > install"
> > > made
> > > it pass.
> > > Not sure if this is normal.
> > > 
> > > Could you please check if this fixes the issue on your side as
> > > well?
> > > Since this patch changes files outside of gcc/jit, what tests
> > > should
> > > I
> > > run to make sure it didn't break anything?
> > 
> > I'm trying your patch in my tester now.
> 
> Bootstrapped with x86_64-pc-linux-gnu/build.  No changes to non-jit
> tests, but had this effect on jit.sum:
> 
> Changes to jit.sum
> --
> 
>   FAIL: 9->11 (+2)
>   PASS: 14827->11434 (-3393)
> 
> apparently due to:
>  FAIL: test-combination.c.exe iteration 1 of 5:
> verify_code_accessing_bitfield: result is NULL
>  FAIL: test-combination.c.exe killed: 997638 exp16 0 0 CHILDKILLED
> SIGABRT SIGABRT
> 
> > 
> > BTW, we shouldn't add test-ggc-bugfix to since it adds options to
> > the
> > context: this would affect all the other tests.
> 
> 

From 4024224e57a465e414fa26d21a57e188aadb349c Mon Sep 17 00:00:00 2001
From: Antoni Boucher 
Date: Fri, 10 Nov 2023 09:52:32 -0500
Subject: [PATCH] libgccjit: Fix GGC segfault when using -flto

gcc/ChangeLog:
	PR jit/111396
	* ipa-fnsummary.cc (ipa_fnsummary_cc_finalize): Call
	ipa_free_size_summary.
	* ipa-icf.cc (ipa_icf_cc_finalize): New function.
	* ipa-profile.cc (ipa_profile_cc_finalize): New function.
	* ipa-prop.cc (ipa_prop_cc_finalize): New function.
	* ipa-prop.h (ipa_prop_cc_finalize): New function.
	* ipa-sra.cc (ipa_sra_cc_finalize): New function.
	* ipa-utils.h (ipa_profile_cc_finalize, ipa_icf_cc_finalize,
	ipa_sra_cc_finalize): New functions.
	* toplev.cc (toplev::finalize): Call ipa_icf_cc_finalize,
	ipa_prop_cc_finalize, ipa_profile_cc_finalize and
	ipa_sra_cc_finalize
	Include ipa-utils.h.

gcc/testsuite/ChangeLog:
	PR jit/111396
	* jit.dg/all-non-failing-tests.h: Add note about test-ggc-bugfix.
	* jit.dg/test-ggc-bugfix.c: New test.
---
 gcc/ipa-fnsummary.cc |  1 +
 gcc/ipa-icf.cc   |  9 ++
 gcc/ipa-profile.cc   | 10 ++
 gcc/ipa-prop.cc  | 18 +++
 gcc/ipa-prop.h   |  2 ++
 gcc/ipa-sra.cc   | 12 +++
 gcc/ipa-utils.h  |  7 
 gcc/testsuite/jit.dg/all-non-failing-tests.h |  4 +++
 gcc/testsuite/jit.dg/test-ggc-bugfix.c   | 34 
 gcc/toplev.cc|  5 +++
 10 files changed, 102 insertions(+)
 create mode 100644 gcc/testsuite/jit.dg/test-ggc-bugfix.c

diff --git a/gcc/ipa-fnsummary.cc b/gcc/ipa-fnsummary.cc
index a2495ffe63e..34e011c4b50 100644
--- a/gcc/ipa-fnsummary.cc
+++ b/gcc/ipa-fnsummary.cc
@@ -5090,4 +5090,5 @@ void
 ipa_fnsummary_cc_finalize (void)
 {
   ipa_free_fn_summary ();
+  ipa_free_size_summary ();
 }
diff --git a/gcc/ipa-icf.cc b/gcc/ipa-icf.cc
index bbdfd445397..ba6c6899ce6 100644
--- a/gcc/ipa-icf.cc
+++ b/gcc/ipa-icf.cc
@@ -3657,3 +3657,12 @@ make_pass_ipa_icf (gcc::context *ctxt)
 {
   return new ipa_icf::pass_ipa_icf (ctxt);
 }
+
+/* Reset all state within ipa-icf.cc so that we can rerun the compiler
+   within the same process.  For use by toplev::finalize.  */
+
+void
+ipa_icf_cc_finalize (void)
+{
+  ipa_icf::optimizer = NULL;
+}
diff --git a/gcc/ipa-profile.cc b/gcc/ipa-profile.cc
index 78a40a118bc..8083b8195a8 100644
--- a/gcc/ipa-profile.cc
+++ b/gcc/ipa-profile.cc
@@ -1065,3 +1065,13 @@ make_pass_ipa_profile (gcc::context *ctxt)
 {
   return new pass_ipa_profile (ctxt);
 }
+
+/* Reset all state within ipa-profile.cc so that we can rerun the compiler
+   within the same process.  For use by toplev::finalize.  */
+
+void
+ipa_profile_cc_finalize (void)
+{
+  delete call_sums;
+  call_sums = NULL;
+}
diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index 7de2b788185..31ca5af061e 100644
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -5915,5 +5915,23 @@ ipcp_transform_function (struct cgraph_node *node)
   return modified_mem_access ? TODO_update_ssa_only_virtuals : 0;
 }
 
+/* Reset all state within ipa-prop.cc so that we can rerun the compiler
+   within the same process.  For use by toplev::finalize.  */

Re: [PATCH] libgccjit: Add ability to get CPU features

[Antoni Boucher]

See more answers below.

On Thu, 2023-11-09 at 19:33 -0500, Antoni Boucher wrote:
> > Hi.
> > See answers below.
> > 
> > On Thu, 2023-11-09 at 18:04 -0500, David Malcolm wrote:
> > > > On Thu, 2023-11-09 at 17:27 -0500, Antoni Boucher wrote:
> > > > > > Hi.
> > > > > > This patch adds support for getting the CPU features in
> > > > > > libgccjit
> > > > > > (bug
> > > > > > 112466)
> > > > > > 
> > > > > > There's a TODO in the test:
> > > > > > I'm not sure how to test that gcc_jit_target_info_arch
> > > > > > returns
> > > > > > the
> > > > > > correct value since it is dependant on the CPU.
> > > > > > Any idea on how to improve this?
> > > > > > 
> > > > > > Also, I created a CStringHash to be able to have a
> > > > > > std::unordered_set. Is there any built-in way
> > > > > > of
> > > > > > doing
> > > > > > this?
> > > > 
> > > > Thanks for the patch.
> > > > 
> > > > Some high-level questions:
> > > > 
> > > > Is this specifically about detecting capabilities of the host
> > > > that
> > > > libgccjit is currently running on? or how the target was
> > > > configured
> > > > when libgccjit was built?
> > 
> > I'm less sure about this part. I'll need to do more tests.

This detects the capabilities of the host that libgccjit is currently
running on.

> > 
> > > > 
> > > > One of the benefits of libgccjit is that, in theory, we support
> > > > all
> > > > of
> > > > the targets that GCC already supports.  Does this patch change
> > > > that,
> > > > or
> > > > is this more about giving client code the ability to determine
> > > > capabilities of the specific host being compiled for?
> > 
> > This should not change that. If it does, this is a bug.

To add to this, libgccjit will just report that the feature is not
detected when cross-compiling.

> > 
> > > > 
> > > > I'm nervous about having per-target jit code.  Presumably
> > > > there's a
> > > > reason that we can't reuse existing target logic here - can you
> > > > please
> > > > describe what the problem is.  I see that the ChangeLog has:
> > > > 
> > > > > >  * config/i386/i386-jit.cc: New file.
> > > > 
> > > > where i386-jit.cc has almost 200 lines of nontrivial code. 
> > > > Where
> > > > did
> > > > this come from?  Did you base it on existing code in our source
> > > > tree,
> > > > making modifications to fit the new internal API, or did you
> > > > write
> > > > it
> > > > from scratch?  In either case, how onerous would this be for
> > > > other
> > > > targets?
> > 
> > This was mostly copied from the same code done for the Rust and D
> > frontends.
> > See this commit and the following:
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b1c06fd9723453dd2b2ec306684cb806dc2b4fbb
> > The equivalent to i386-jit.cc is there:
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=22e3557e2d52f129f2bbfdc98688b945dba28dc9
> > 
> > > > 
> > > > I'm not at expert at target hooks (or at the i386 backend), so
> > > > if
> > > > we
> > > > do
> > > > go with this approach I'd want someone else to review those
> > > > parts
> > > > of
> > > > the patch.
> > > > 
> > > > Have you verified that GCC builds with this patch with jit
> > > > *not*
> > > > enabled in the enabled languages?
> > 
> > I will do.

It does build.

> > 
> > > > 
> > > > [...snip...]
> > > > 
> > > > A nitpick:
> > > > 
> > > > > > +.. function:: const char * \
> > > > > > +  gcc_jit_target_info_arch
> > > > > > (gcc_jit_target_info
> > > > > > *info)
> > > > > > +
> > > > > > +   Get the architecture of the currently running CPU.
> > > > 
> > > > What does this string look like?
> > > > How long does the pointer remain valid?
> > 
> > It's the march string, like "znver2", for instance.
> > It remains valid until we free the gcc_jit_target_info object.
> > 
> > > > 
> > > > Thanks again; hope the above makes sense
> > > > Dave
> > > > 
> > 

Re: [PATCH v2] c++: wrong ambiguity in accessing static field [PR112744]

[Marek Polacek]

On Thu, Nov 30, 2023 at 11:42:36AM -0500, Jason Merrill wrote:
> On 11/29/23 17:01, Marek Polacek wrote:
> > On Wed, Nov 29, 2023 at 03:28:44PM -0500, Jason Merrill wrote:
> > > On 11/29/23 12:43, Marek Polacek wrote:
> > > > On Wed, Nov 29, 2023 at 12:23:46PM -0500, Patrick Palka wrote:
> > > > > On Wed, 29 Nov 2023, Marek Polacek wrote:
> > > > > 
> > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > > > > 
> > > > > > Now that I'm posting this patch, I think you'll probably want me to 
> > > > > > use
> > > > > > ba_any unconditionally.  That works too; g++.dg/tc1/dr52.C just 
> > > > > > needs
> > > > > > a trivial testsuite tweak:
> > > > > > 'C' is not an accessible base of 'X'
> > > > > > v.
> > > > > > 'C' is an inaccessible base of 'X'
> > > > > > We should probably unify those messages...
> > > > > > 
> > > > > > -- >8 --
> > > > > > Given
> > > > > > 
> > > > > > struct A { constexpr static int a = 0; };
> > > > > > struct B : A {};
> > > > > > struct C : A {};
> > > > > > struct D : B, C {};
> > > > > > 
> > > > > > we give the "'A' is an ambiguous base of 'D'" error for
> > > > > > 
> > > > > > D{}.A::a;
> > > > > > 
> > > > > > which seems wrong: 'a' is a static data member so there is only one 
> > > > > > copy
> > > > > > so it can be unambiguously referred to even if there are multiple A
> > > > > > objects.  clang++/MSVC/icx agree.
> > > > > > 
> > > > > > PR c++/112744
> > > > > > 
> > > > > > gcc/cp/ChangeLog:
> > > > > > 
> > > > > > * typeck.cc (finish_class_member_access_expr): When accessing
> > > > > > a static data member, use ba_any for lookup_base.
> > > > > > 
> > > > > > gcc/testsuite/ChangeLog:
> > > > > > 
> > > > > > * g++.dg/lookup/scoped11.C: New test.
> > > > > > * g++.dg/lookup/scoped12.C: New test.
> > > > > > * g++.dg/lookup/scoped13.C: New test.
> > > > > > ---
> > > > > >gcc/cp/typeck.cc   | 21 ++---
> > > > > >gcc/testsuite/g++.dg/lookup/scoped11.C | 14 ++
> > > > > >gcc/testsuite/g++.dg/lookup/scoped12.C | 14 ++
> > > > > >gcc/testsuite/g++.dg/lookup/scoped13.C | 14 ++
> > > > > >4 files changed, 60 insertions(+), 3 deletions(-)
> > > > > >create mode 100644 gcc/testsuite/g++.dg/lookup/scoped11.C
> > > > > >create mode 100644 gcc/testsuite/g++.dg/lookup/scoped12.C
> > > > > >create mode 100644 gcc/testsuite/g++.dg/lookup/scoped13.C
> > > > > > 
> > > > > > diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
> > > > > > index e995fb6ddd7..c4de8bb2616 100644
> > > > > > --- a/gcc/cp/typeck.cc
> > > > > > +++ b/gcc/cp/typeck.cc
> > > > > > @@ -3476,7 +3476,7 @@ finish_class_member_access_expr (cp_expr 
> > > > > > object, tree name, bool template_p,
> > > > > >name, scope);
> > > > > >   return error_mark_node;
> > > > > > }
> > > > > > -   
> > > > > > +
> > > > > >   if (TREE_SIDE_EFFECTS (object))
> > > > > > val = build2 (COMPOUND_EXPR, TREE_TYPE (val), object, 
> > > > > > val);
> > > > > >   return val;
> > > > > > @@ -3493,9 +3493,24 @@ finish_class_member_access_expr (cp_expr 
> > > > > > object, tree name, bool template_p,
> > > > > >   return error_mark_node;
> > > > > > }
> > > > > > + /* NAME may refer to a static data member, in which case 
> > > > > > there is
> > > > > > +one copy of the data member that is shared by all the 
> > > > > > objects of
> > > > > > +the class.  So NAME can be unambiguously referred to even 
> > > > > > if
> > > > > > +there are multiple indirect base classes containing NAME.  
> > > > > > */
> > > > > > + const base_access ba = [scope, name] ()
> > > > > > +   {
> > > > > > + if (identifier_p (name))
> > > > > > +   {
> > > > > > + tree m = lookup_member (scope, name, /*protect=*/0,
> > > > > > + /*want_type=*/false, tf_none);
> > > > > > + if (!m || VAR_P (m))
> > > > > > +   return ba_any;
> > > > > 
> > > > > I wonder if we want to return ba_check_bit instead of ba_any so that 
> > > > > we
> > > > > still check access of the selected base?
> > > > 
> > > > That would certainly make sense to me.  I didn't do that because
> > > > I'd not seen ba_check_bit being used except as part of ba_check,
> > > > but that may not mean much.
> > > > 
> > > > So either I can tweak the lambda to return ba_check_bit rather
> > > > than ba_any or use ba_check_bit unconditionally.  Any opinions on that?
> > > 
> > > The relevant passage seems to be
> > > https://eel.is/c++draft/class.access.base#6
> > > after DR 52, which seems to have clarified that the pointer conversion 
> > > only
> > > applies to non-static members.
> > > 
> > > > > struct A { constexpr static int a = 0; };
> > > > > struct D : private A {};
> > > > > 
> > > > > void 

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

[Marek Polacek]

On Thu, Nov 30, 2023 at 10:30:44PM +0100, Jakub Jelinek wrote:
> On Thu, Nov 30, 2023 at 10:27:33PM +0100, Florian Weimer wrote:
> > * Jakub Jelinek:
> > 
> > > On Thu, Nov 30, 2023 at 04:15:26PM -0500, Marek Polacek wrote:
> > >> On Thu, Nov 30, 2023 at 10:11:31PM +0100, Florian Weimer wrote:
> > >> > * Marek Polacek:
> > >> > 
> > >> > > On Mon, Nov 20, 2023 at 10:56:36AM +0100, Florian Weimer wrote:
> > >> > >> --- a/gcc/doc/invoke.texi
> > >> > >> +++ b/gcc/doc/invoke.texi
> > >> > >> @@ -6183,6 +6183,7 @@ that have their own flag:
> > >> > >>  @gccoptlist{
> > >> > >>  -Wimplicit-function-declaration @r{(C)}
> > >> > >>  -Wimplicit-int @r{(C)}
> > >> > >> +-Wincompatible-pointer-types @r{(C)}
> > >> > >>  -Wint-conversion @r{(C)}
> > >> > >>  -Wnarrowing @r{(C++)}
> > >> > >>  -Wreturn-mismatch @r{(C)}
> > >> > >
> > >> > > BTW, should the C ones mention Objective-C as well?
> > >> > 
> > >> > Isn't there Objective-C++ as well?  I assumed it applied to both
> > >> > dialects.
> > >> 
> > >> I think we usually spell both, if they apply.  But you can leave it as 
> > >> it is.
> > >
> > > Seems we use (C and Objective-C only) (40 times) in preference to (C only)
> > > (4 times), (C++ and Objective-C++ only) (61 times) in preference to (6
> > > times), but (C and C++ only) (5 times) and never all 4 languages, even
> > > when I think it is very likely some switch would be C only, C++ only or
> > > C and C++ only.  And (C) is used just for Copyright ;)
> > 
> > So it should say “C and Objective-C only” for the C stuff,
> 
> Yes please.
> > and “C++ and
> > Objective-C++ only” for -Wnarrowing?
> 
> I'd say so, but let's wait for Jason.

FWIW, I just checked the code and I agree.

> AFAIK one can use any -std={gnu,c}++{98,11,14,17,20,23,26} and their
> aliases with Objective-C++, similarly how Objective-C can use any
> -std={gnu,c}{89,99,11,17,23} etc. flags.
> 
> > Jason, does the -Wnarrowing aspect of -fpermissive apply to
> > Objective-C++ as well, or is it stuck at C++98?

Marek

Re: [PATCH v3 00/11] : More warnings as errors by default

[Florian Weimer]

* Sam James:

>>> But give Marek additional time to chime in, particularly given the
>>> holidays this week in the US.  Say through this time next week?
>>
>> [...]
>>
>> I'm also gathering some numbers regarding autoconf impact and potential
>> silent miscompilation.
>
> I'd actually forgot about another element here: FreeBSD 14 which was
> just released now ships with Clang 16 so we seem to be getting some
> activity from them which is a help.
>
> I've resumed our testing for configure diffs and am going to
> focus on that for now. It's just laborious because of how many errors
> are actually fine.

Marek has kindly posted his reviews, and I'm incorporating his
suggestions.

Meanwhile, I've posted some numbers to the gcc list:

  Update on GCC 14 C type safety changes/warnings as errors
  

Thanks,
Florian

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

[Jeff Law]

On 11/30/23 14:22, Jeff Law wrote:

So if you're going to add opcodes in here, don't they also need to be in 
safe_for_propagation_p as well?  Otherwise they won't get used, right? 
I'm thinking about the HIGHPART cases for example.  As well as the 
saturating shifts which we indicated we were going to take out of 
safe_for_propagation_p IIRC.

Ignore my comment about HIGHPART :-)

Jeff

[PATCH v3] aarch64: New RTL optimization pass avoid-store-forwarding.

[Manos Anagnostakis]

This is an RTL pass that detects store forwarding from stores to larger loads 
(load pairs).

This optimization is SPEC2017-driven and was found to be beneficial for some 
benchmarks,
through testing on ampere1/ampere1a machines.

For example, it can transform cases like

str  d5, [sp, #320]
fmul d5, d31, d29
ldp  d31, d17, [sp, #312] # Large load from small store

to

str  d5, [sp, #320]
fmul d5, d31, d29
ldr  d31, [sp, #312]
ldr  d17, [sp, #320]

Currently, the pass is disabled by default on all architectures and enabled by 
a target-specific option.

If deemed beneficial enough for a default, it will be enabled on 
ampere1/ampere1a,
or other architectures as well, without needing to be turned on by this option.

Bootstrapped and regtested on aarch64-linux.

gcc/ChangeLog:

* config.gcc: Add aarch64-store-forwarding.o to extra_objs.
* config/aarch64/aarch64-passes.def (INSERT_PASS_AFTER): New pass.
* config/aarch64/aarch64-protos.h (make_pass_avoid_store_forwarding): 
Declare.
* config/aarch64/aarch64.opt (mavoid-store-forwarding): New option.
(aarch64-store-forwarding-threshold): New param.
* config/aarch64/t-aarch64: Add aarch64-store-forwarding.o
* doc/invoke.texi: Document new option and new param.
* config/aarch64/aarch64-store-forwarding.cc: New file.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/ldp_ssll_no_overlap_address.c: New test.
* gcc.target/aarch64/ldp_ssll_no_overlap_offset.c: New test.
* gcc.target/aarch64/ldp_ssll_overlap.c: New test.

Signed-off-by: Manos Anagnostakis 
Co-Authored-By: Manolis Tsamis 
Co-Authored-By: Philipp Tomsich 
---
Changes in v3:
- Removed obvious zext/sext check in SET_DEST.
- Replaced map/vector with list/struct.
- Replaced current threshold check algorithm with the
suggested, more efficient one (actually an inline check).
- Added usage of cselib_subst_to_values, which works well
with cselib_process_insn.
- Removed canon_rtx, but cannot remove init/end_alias_analysis,
as this is required for cselib to work properly (see cselib_init
in gcc/cselib.cc).
- Adjusted comments according to the new changes.

 gcc/config.gcc|   1 +
 gcc/config/aarch64/aarch64-passes.def |   1 +
 gcc/config/aarch64/aarch64-protos.h   |   1 +
 .../aarch64/aarch64-store-forwarding.cc   | 319 ++
 gcc/config/aarch64/aarch64.opt|   9 +
 gcc/config/aarch64/t-aarch64  |  10 +
 gcc/doc/invoke.texi   |  12 +-
 .../aarch64/ldp_ssll_no_overlap_address.c |  33 ++
 .../aarch64/ldp_ssll_no_overlap_offset.c  |  33 ++
 .../gcc.target/aarch64/ldp_ssll_overlap.c |  33 ++
 10 files changed, 451 insertions(+), 1 deletion(-)
 create mode 100644 gcc/config/aarch64/aarch64-store-forwarding.cc
 create mode 100644 
gcc/testsuite/gcc.target/aarch64/ldp_ssll_no_overlap_address.c
 create mode 100644 
gcc/testsuite/gcc.target/aarch64/ldp_ssll_no_overlap_offset.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/ldp_ssll_overlap.c

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 748430194f3..2ee3b61c4fa 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -350,6 +350,7 @@ aarch64*-*-*)
cxx_target_objs="aarch64-c.o"
d_target_objs="aarch64-d.o"
extra_objs="aarch64-builtins.o aarch-common.o aarch64-sve-builtins.o 
aarch64-sve-builtins-shapes.o aarch64-sve-builtins-base.o 
aarch64-sve-builtins-sve2.o cortex-a57-fma-steering.o aarch64-speculation.o 
falkor-tag-collision-avoidance.o aarch-bti-insert.o aarch64-cc-fusion.o"
+   extra_objs="${extra_objs} aarch64-store-forwarding.o"
target_gtfiles="\$(srcdir)/config/aarch64/aarch64-builtins.cc 
\$(srcdir)/config/aarch64/aarch64-sve-builtins.h 
\$(srcdir)/config/aarch64/aarch64-sve-builtins.cc"
target_has_targetm_common=yes
;;
diff --git a/gcc/config/aarch64/aarch64-passes.def 
b/gcc/config/aarch64/aarch64-passes.def
index 6ace797b738..fa79e8adca8 100644
--- a/gcc/config/aarch64/aarch64-passes.def
+++ b/gcc/config/aarch64/aarch64-passes.def
@@ -23,3 +23,4 @@ INSERT_PASS_BEFORE (pass_reorder_blocks, 1, 
pass_track_speculation);
 INSERT_PASS_AFTER (pass_machine_reorg, 1, pass_tag_collision_avoidance);
 INSERT_PASS_BEFORE (pass_shorten_branches, 1, pass_insert_bti);
 INSERT_PASS_AFTER (pass_if_after_combine, 1, pass_cc_fusion);
+INSERT_PASS_AFTER (pass_peephole2, 1, pass_avoid_store_forwarding);
diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index d2718cc87b3..7d9dfa06af9 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -1050,6 +1050,7 @@ rtl_opt_pass *make_pass_track_speculation (gcc::context 
*);
 rtl_opt_pass *make_pass_tag_collision_avoidance (gcc::context *);
 rtl_opt_pass *make_pass_insert_bti (gcc::context *ctxt);
 rtl_opt_pass 

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

[Jakub Jelinek]

On Thu, Nov 30, 2023 at 10:27:33PM +0100, Florian Weimer wrote:
> * Jakub Jelinek:
> 
> > On Thu, Nov 30, 2023 at 04:15:26PM -0500, Marek Polacek wrote:
> >> On Thu, Nov 30, 2023 at 10:11:31PM +0100, Florian Weimer wrote:
> >> > * Marek Polacek:
> >> > 
> >> > > On Mon, Nov 20, 2023 at 10:56:36AM +0100, Florian Weimer wrote:
> >> > >> --- a/gcc/doc/invoke.texi
> >> > >> +++ b/gcc/doc/invoke.texi
> >> > >> @@ -6183,6 +6183,7 @@ that have their own flag:
> >> > >>  @gccoptlist{
> >> > >>  -Wimplicit-function-declaration @r{(C)}
> >> > >>  -Wimplicit-int @r{(C)}
> >> > >> +-Wincompatible-pointer-types @r{(C)}
> >> > >>  -Wint-conversion @r{(C)}
> >> > >>  -Wnarrowing @r{(C++)}
> >> > >>  -Wreturn-mismatch @r{(C)}
> >> > >
> >> > > BTW, should the C ones mention Objective-C as well?
> >> > 
> >> > Isn't there Objective-C++ as well?  I assumed it applied to both
> >> > dialects.
> >> 
> >> I think we usually spell both, if they apply.  But you can leave it as it 
> >> is.
> >
> > Seems we use (C and Objective-C only) (40 times) in preference to (C only)
> > (4 times), (C++ and Objective-C++ only) (61 times) in preference to (6
> > times), but (C and C++ only) (5 times) and never all 4 languages, even
> > when I think it is very likely some switch would be C only, C++ only or
> > C and C++ only.  And (C) is used just for Copyright ;)
> 
> So it should say “C and Objective-C only” for the C stuff,

Yes please.

> and “C++ and
> Objective-C++ only” for -Wnarrowing?

I'd say so, but let's wait for Jason.
AFAIK one can use any -std={gnu,c}++{98,11,14,17,20,23,26} and their
aliases with Objective-C++, similarly how Objective-C can use any
-std={gnu,c}{89,99,11,17,23} etc. flags.

> Jason, does the -Wnarrowing aspect of -fpermissive apply to
> Objective-C++ as well, or is it stuck at C++98?

Jakub

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

[Florian Weimer]

* Jakub Jelinek:

> On Thu, Nov 30, 2023 at 04:15:26PM -0500, Marek Polacek wrote:
>> On Thu, Nov 30, 2023 at 10:11:31PM +0100, Florian Weimer wrote:
>> > * Marek Polacek:
>> > 
>> > > On Mon, Nov 20, 2023 at 10:56:36AM +0100, Florian Weimer wrote:
>> > >> --- a/gcc/doc/invoke.texi
>> > >> +++ b/gcc/doc/invoke.texi
>> > >> @@ -6183,6 +6183,7 @@ that have their own flag:
>> > >>  @gccoptlist{
>> > >>  -Wimplicit-function-declaration @r{(C)}
>> > >>  -Wimplicit-int @r{(C)}
>> > >> +-Wincompatible-pointer-types @r{(C)}
>> > >>  -Wint-conversion @r{(C)}
>> > >>  -Wnarrowing @r{(C++)}
>> > >>  -Wreturn-mismatch @r{(C)}
>> > >
>> > > BTW, should the C ones mention Objective-C as well?
>> > 
>> > Isn't there Objective-C++ as well?  I assumed it applied to both
>> > dialects.
>> 
>> I think we usually spell both, if they apply.  But you can leave it as it is.
>
> Seems we use (C and Objective-C only) (40 times) in preference to (C only)
> (4 times), (C++ and Objective-C++ only) (61 times) in preference to (6
> times), but (C and C++ only) (5 times) and never all 4 languages, even
> when I think it is very likely some switch would be C only, C++ only or
> C and C++ only.  And (C) is used just for Copyright ;)

So it should say “C and Objective-C only” for the C stuff, and “C++ and
Objective-C++ only” for -Wnarrowing?

Jason, does the -Wnarrowing aspect of -fpermissive apply to
Objective-C++ as well, or is it stuck at C++98?

Thanks,
Florian

Re: Darwin: Replace environment runpath with embedded [PR88590]

[Ian Lance Taylor]

On Thu, Nov 30, 2023 at 11:58 AM Ian Lance Taylor  wrote:
>
> On Thu, Nov 30, 2023 at 11:56 AM Iain Sandoe  wrote:
> >
> > > On 30 Nov 2023, at 19:43, Ian Lance Taylor  wrote:
> > >
> > > On Sun, Oct 22, 2023 at 2:18 PM FX Coudert  wrote:
> > >>
> > >> Thanks a lot Alexandre for the review!
> > >
> > > This patch changed the files lingo/configure.ac and libgo/configure.
> > > Those files live in an upstream repository and should be changed there
> > > and then merged into the GCC repo, as described in libgo/README.gcc.
> > > This is not a big deal, and I can take care of changing the upstream
> > > repository.  But I don't understand the changes in libgo.  As far as I
> > > can tell, all they do is add an automake conditional that is never
> > > used.  Is there any reason for that?
> >
> > It’s not used (yet) because we do not build libgo on Darwin, if/when we
> > do it would be used in the same way as for the other runtimes.
> >
> > >  Should I just revert the changes to libgo?
> >
> > That is also fine (because we do not yet build it on Darwin), it seems 
> > unlikely
> > we’d forget to re-add it.
>
> Thanks, I'll make the change upstream.

Now done.

Ian

Re: [PATCH] libgo, libstdc++: Regenerate GCC_CHECK_ASSEMBLER_HWCAP users

[Ian Lance Taylor]

On Thu, Nov 30, 2023 at 11:46 AM Ian Lance Taylor  wrote:
>
> On Thu, Nov 30, 2023 at 1:30 AM Rainer Orth  
> wrote:
> >
> > the gcc-autoregen bot correctly complained that the libgo and libstdc++
> > configure scripts hadn't been regenerated.  I'd have commited the
> > following as obvious (just whitespace change), but since libgo is
> > imported from upstream, I'm uncertain how best to handle that part.
>
> I can update libgo/configure upstream, but first I'd like to
> understand the change in git revision
> 6a6d3817afa02bbcd2388c8e005da6faf88932f1, which seems unnecessary.
> Asked in https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638814.html.

OK, fixed now in the GCC repo.

Ian

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

[Jakub Jelinek]

On Thu, Nov 30, 2023 at 04:15:26PM -0500, Marek Polacek wrote:
> On Thu, Nov 30, 2023 at 10:11:31PM +0100, Florian Weimer wrote:
> > * Marek Polacek:
> > 
> > > On Mon, Nov 20, 2023 at 10:56:36AM +0100, Florian Weimer wrote:
> > >> --- a/gcc/doc/invoke.texi
> > >> +++ b/gcc/doc/invoke.texi
> > >> @@ -6183,6 +6183,7 @@ that have their own flag:
> > >>  @gccoptlist{
> > >>  -Wimplicit-function-declaration @r{(C)}
> > >>  -Wimplicit-int @r{(C)}
> > >> +-Wincompatible-pointer-types @r{(C)}
> > >>  -Wint-conversion @r{(C)}
> > >>  -Wnarrowing @r{(C++)}
> > >>  -Wreturn-mismatch @r{(C)}
> > >
> > > BTW, should the C ones mention Objective-C as well?
> > 
> > Isn't there Objective-C++ as well?  I assumed it applied to both
> > dialects.
> 
> I think we usually spell both, if they apply.  But you can leave it as it is.

Seems we use (C and Objective-C only) (40 times) in preference to (C only)
(4 times), (C++ and Objective-C++ only) (61 times) in preference to (6
times), but (C and C++ only) (5 times) and never all 4 languages, even
when I think it is very likely some switch would be C only, C++ only or
C and C++ only.  And (C) is used just for Copyright ;)

Jakub

Re: [PATCH] preprocessor: Reinitialize frontend parser after loading a PCH [PR112319]

[Marek Polacek]

On Wed, Nov 01, 2023 at 05:54:57PM -0400, Lewis Hyatt wrote:
> Hello-
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112319
> 
> This is a one-line patch to fix the GCC 14 regression noted in the
> PR. Bootstrap + regtest all languages on x86-64 looks good. Is it OK please?
> Thanks!
> 
> -Lewis
> 
> -- >8 --
> 
> Since r14-2893, the frontend parser object needs to exist when running in
> preprocess-only mode, because pragma_lex() is now called in that mode and
> needs to make use of it. This is handled by calling c_init_preprocess() at
> startup. If -fpch-preprocess is in effect (commonly, because of
> -save-temps), a PCH file may be loaded during preprocessing, in which
> case the parser will be destroyed, causing the issue noted in the
> PR. Resolve it by reinitializing the frontend parser after loading the PCH.
> 
> gcc/c-family/ChangeLog:
> 
>   PR pch/112319
>   * c-ppoutput.cc (cb_read_pch): Reinitialize the frontend parser

"front-end"

>   after loading a PCH.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR pch/112319
>   * g++.dg/pch/pr112319.C: New test.
>   * g++.dg/pch/pr112319.Hs: New test.
>   * gcc.dg/pch/pr112319.c: New test.
>   * gcc.dg/pch/pr112319.hs: New test.
> ---
>  gcc/c-family/c-ppoutput.cc   | 5 +
>  gcc/testsuite/g++.dg/pch/pr112319.C  | 5 +
>  gcc/testsuite/g++.dg/pch/pr112319.Hs | 1 +
>  gcc/testsuite/gcc.dg/pch/pr112319.c  | 5 +
>  gcc/testsuite/gcc.dg/pch/pr112319.hs | 1 +
>  5 files changed, 17 insertions(+)
>  create mode 100644 gcc/testsuite/g++.dg/pch/pr112319.C
>  create mode 100644 gcc/testsuite/g++.dg/pch/pr112319.Hs
>  create mode 100644 gcc/testsuite/gcc.dg/pch/pr112319.c
>  create mode 100644 gcc/testsuite/gcc.dg/pch/pr112319.hs
> 
> diff --git a/gcc/c-family/c-ppoutput.cc b/gcc/c-family/c-ppoutput.cc
> index 4aa2bef2c0f..4f973767976 100644
> --- a/gcc/c-family/c-ppoutput.cc
> +++ b/gcc/c-family/c-ppoutput.cc
> @@ -862,4 +862,9 @@ cb_read_pch (cpp_reader *pfile, const char *name,
>  
>fprintf (print.outf, "#pragma GCC pch_preprocess \"%s\"\n", name);
>print.src_line++;
> +
> +  /* The process of reading the PCH has destroyed the frontend parser,

"front-end"

> + so ask the frontend to reinitialize it, in case we need it to

"front end"

(sorry to be overly pedantic...)

Patch looks fine to me; please go ahead if you haven't pushed it already.

> + process any #pragma directives encountered while preprocessing.  */
> +  c_init_preprocess ();
>  }
> diff --git a/gcc/testsuite/g++.dg/pch/pr112319.C 
> b/gcc/testsuite/g++.dg/pch/pr112319.C
> new file mode 100644
> index 000..9e0457e8aec
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/pch/pr112319.C
> @@ -0,0 +1,5 @@
> +/* { dg-additional-options "-Wpragmas -save-temps" } */
> +#include "pr112319.H"
> +#pragma GCC diagnostic error "-Wpragmas"
> +#pragma GCC diagnostic ignored "oops" /* { dg-error "oops" } */
> +/* { dg-regexp {[^[:space:]]*: some warnings being treated as errors} } */
> diff --git a/gcc/testsuite/g++.dg/pch/pr112319.Hs 
> b/gcc/testsuite/g++.dg/pch/pr112319.Hs
> new file mode 100644
> index 000..3b6178bfae0
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/pch/pr112319.Hs
> @@ -0,0 +1 @@
> +/* This space intentionally left blank.  */
> diff --git a/gcc/testsuite/gcc.dg/pch/pr112319.c 
> b/gcc/testsuite/gcc.dg/pch/pr112319.c
> new file mode 100644
> index 000..043881463c5
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pch/pr112319.c
> @@ -0,0 +1,5 @@
> +/* { dg-additional-options "-Wpragmas -save-temps" } */
> +#include "pr112319.h"
> +#pragma GCC diagnostic error "-Wpragmas"
> +#pragma GCC diagnostic ignored "oops" /* { dg-error "oops" } */
> +/* { dg-regexp {[^[:space:]]*: some warnings being treated as errors} } */
> diff --git a/gcc/testsuite/gcc.dg/pch/pr112319.hs 
> b/gcc/testsuite/gcc.dg/pch/pr112319.hs
> new file mode 100644
> index 000..3b6178bfae0
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pch/pr112319.hs
> @@ -0,0 +1 @@
> +/* This space intentionally left blank.  */
> 

Marek

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

[Marek Polacek]

On Thu, Nov 30, 2023 at 10:11:31PM +0100, Florian Weimer wrote:
> * Marek Polacek:
> 
> > On Mon, Nov 20, 2023 at 10:56:36AM +0100, Florian Weimer wrote:
> >> --- a/gcc/doc/invoke.texi
> >> +++ b/gcc/doc/invoke.texi
> >> @@ -6183,6 +6183,7 @@ that have their own flag:
> >>  @gccoptlist{
> >>  -Wimplicit-function-declaration @r{(C)}
> >>  -Wimplicit-int @r{(C)}
> >> +-Wincompatible-pointer-types @r{(C)}
> >>  -Wint-conversion @r{(C)}
> >>  -Wnarrowing @r{(C++)}
> >>  -Wreturn-mismatch @r{(C)}
> >
> > BTW, should the C ones mention Objective-C as well?
> 
> Isn't there Objective-C++ as well?  I assumed it applied to both
> dialects.

I think we usually spell both, if they apply.  But you can leave it as it is.

Marek

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

[Florian Weimer]

* Marek Polacek:

> On Mon, Nov 20, 2023 at 10:56:36AM +0100, Florian Weimer wrote:
>> --- a/gcc/doc/invoke.texi
>> +++ b/gcc/doc/invoke.texi
>> @@ -6183,6 +6183,7 @@ that have their own flag:
>>  @gccoptlist{
>>  -Wimplicit-function-declaration @r{(C)}
>>  -Wimplicit-int @r{(C)}
>> +-Wincompatible-pointer-types @r{(C)}
>>  -Wint-conversion @r{(C)}
>>  -Wnarrowing @r{(C++)}
>>  -Wreturn-mismatch @r{(C)}
>
> BTW, should the C ones mention Objective-C as well?

Isn't there Objective-C++ as well?  I assumed it applied to both
dialects.

Thanks,
Florian

Re: [PATCH v3 11/11] c: Add new -Wdeclaration-missing-parameter-type permerror

[Marek Polacek]

On Mon, Nov 20, 2023 at 10:56:42AM +0100, Florian Weimer wrote:
> This used to be a warning, enabled by default, without its own option.

I think this patch is OK now.
 
> A subsequent change could improve diagnostics and provide spelling
> hints for declarations like “void function (int32t);”.

Feel free to open a PR.
 
> gcc/c-family/
> 
>   * c.opt (Wdeclaration-missing-parameter-type): New.
> 
> gcc/c/ChangeLog:
> 
>   PR other/44209

FWIW, these usually go before the whole ChangeLog entry.

Thanks, and sorry about the wait.

>   * c-decl.cc (grokparms): Issue permerror for
>   OPT_Wdeclaration_missing_parameter_type instead of a pedwarn.
> 
> gcc/ChangeLog:
> 
>   * doc/invoke.texi (Warning Options): Document
>   -Wdeclaration-missing-parameter-type.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.dg/permerror-default.c (missing_parameter_type):
>   Expect error.
>   * gcc.dg/permerror-fpermissive.c (missing_parameter_type):
>   Expect -Wdeclaration-missing-parameter-type warning.
>   * gcc.dg/permerror-gnu89-nopermissive.c (missing_parameter_type):
>   Expect -Wdeclaration-missing-parameter-type error.
>   * gcc.dg/permerror-gnu89-pedantic.c (missing_parameter_type):
>   Likewise.
>   * gcc.dg/permerror-gnu89.c (missing_parameter_type):
>   Expect -Wdeclaration-missing-parameter-type warning.
>   * gcc.dg/permerror-noerror.c: Add
>   -Wno-error=declaration-missing-parameter-type to build flags.
>   (missing_parameter_type): Expect
>   -Wdeclaration-missing-parameter-type warning.
>   * gcc.dg/permerror-nowarning.c: Build with
>   -Wno-declaration-missing-parameter-type.  Remove previously
>   expected warning.
>   * gcc.dg/permerror-fpermissive-nowarning.c: Likewise.
>   * gcc.dg/permerror-pedantic.c (missing_parameter_type):
>   Expect -Wdeclaration-missing-parameter-type error.
>   * gcc.dg/permerror-system.c (missing_parameter_type):
>   Likewise.
> ---
>  gcc/c-family/c.opt  |  4 
>  gcc/c/c-decl.cc |  6 --
>  gcc/doc/invoke.texi | 17 -
>  gcc/testsuite/gcc.dg/permerror-default.c|  2 +-
>  .../gcc.dg/permerror-fpermissive-nowarning.c|  7 +--
>  gcc/testsuite/gcc.dg/permerror-fpermissive.c|  2 +-
>  .../gcc.dg/permerror-gnu89-nopermissive.c   |  2 +-
>  gcc/testsuite/gcc.dg/permerror-gnu89-pedantic.c |  2 +-
>  gcc/testsuite/gcc.dg/permerror-gnu89.c  |  2 +-
>  gcc/testsuite/gcc.dg/permerror-noerror.c|  4 ++--
>  gcc/testsuite/gcc.dg/permerror-nowarning.c  |  7 +--
>  gcc/testsuite/gcc.dg/permerror-pedantic.c   |  2 +-
>  gcc/testsuite/gcc.dg/permerror-system.c |  2 ++
>  13 files changed, 36 insertions(+), 23 deletions(-)
> 
> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
> index b10c6057cd1..723e8c3e27b 100644
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -591,6 +591,10 @@ Wdeclaration-after-statement
>  C ObjC Var(warn_declaration_after_statement) Init(-1) Warning
>  Warn when a declaration is found after a statement.
>  
> +Wdeclaration-missing-parameter-type
> +C ObjC Var(warn_declaration_missing_parameter) Warning Init(1)
> +Warn for missing parameter types in function declarations.
> +
>  Wdelete-incomplete
>  C++ ObjC++ Var(warn_delete_incomplete) Init(1) Warning
>  Warn when deleting a pointer to incomplete type.
> diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
> index d16958113a8..3d9bee54259 100644
> --- a/gcc/c/c-decl.cc
> +++ b/gcc/c/c-decl.cc
> @@ -8337,8 +8337,10 @@ grokparms (struct c_arg_info *arg_info, bool 
> funcdef_flag)
>  {
>if (!funcdef_flag)
>   {
> -   pedwarn (input_location, 0, "parameter names (without types) in "
> -"function declaration");
> +   permerror_opt (input_location,
> +  OPT_Wdeclaration_missing_parameter_type,
> +  "parameter names (without types) in "
> +  "function declaration");
> arg_info->parms = NULL_TREE;
>   }
>else
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index be33da71c44..7f5da45dcea 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -504,7 +504,8 @@ Objective-C and Objective-C++ Dialects}.
>  
>  @item C and Objective-C-only Warning Options
>  @gccoptlist{-Wbad-function-cast  -Wmissing-declarations
> --Wmissing-parameter-type -Wmissing-prototypes -Wmissing-variable-declarations
> +-Wmissing-parameter-type -Wdeclaration-missing-parameter-type
> +-Wmissing-prototypes -Wmissing-variable-declarations
>  -Wnested-externs -Wold-style-declaration  -Wold-style-definition
>  -Wstrict-prototypes  -Wtraditional  -Wtraditional-conversion
>  -Wdeclaration-after-statement  -Wpointer-sign}
> @@ -9734,6 +9735,20 @@ void foo(bar) @{ @}
>  
>  This warning is also enabled by @option{-Wextra}.
>  
> +@opindex 

[PATCH] Fortran: copy-out for possibly missing OPTIONAL CLASS arguments [PR112772]

[Harald Anlauf]

Dear all,

the attached rather obvious patch fixes the first testcase of pr112772:
we unconditionally generated copy-out code for optional class arguments,
while the copy-in properly checked the presence of arguments.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

(The second testcase is a different issue.)

Thanks,
Harald

From 38433016def0337a72cb0ef0029cd2c05d702282 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Thu, 30 Nov 2023 21:53:21 +0100
Subject: [PATCH] Fortran: copy-out for possibly missing OPTIONAL CLASS
 arguments [PR112772]

gcc/fortran/ChangeLog:

	PR fortran/112772
	* trans-expr.cc (gfc_conv_class_to_class): Make copy-out conditional
	on the presence of an OPTIONAL CLASS argument passed to an OPTIONAL
	CLASS dummy.

gcc/testsuite/ChangeLog:

	PR fortran/112772
	* gfortran.dg/missing_optional_dummy_7.f90: New test.
---
 gcc/fortran/trans-expr.cc |  9 +++
 .../gfortran.dg/missing_optional_dummy_7.f90  | 64 +++
 2 files changed, 73 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/missing_optional_dummy_7.f90

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index bfe9996ced6..6a47af39c57 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -1365,6 +1365,15 @@ gfc_conv_class_to_class (gfc_se *parmse, gfc_expr *e, gfc_typespec class_ts,
   tmp = build3_loc (input_location, COND_EXPR, void_type_node,
 			cond, tmp, tmp2);
   gfc_add_expr_to_block (>pre, tmp);
+
+  if (!elemental && full_array && copyback)
+	{
+	  tmp2 = build_empty_stmt (input_location);
+	  tmp = gfc_finish_block (>post);
+	  tmp = build3_loc (input_location, COND_EXPR, void_type_node,
+			cond, tmp, tmp2);
+	  gfc_add_expr_to_block (>post, tmp);
+	}
 }
   else
 gfc_add_block_to_block (>pre, );
diff --git a/gcc/testsuite/gfortran.dg/missing_optional_dummy_7.f90 b/gcc/testsuite/gfortran.dg/missing_optional_dummy_7.f90
new file mode 100644
index 000..ad9ecd8f2b6
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/missing_optional_dummy_7.f90
@@ -0,0 +1,64 @@
+! { dg-do run }
+! PR fortran/112772 - test absent OPTIONAL, ALLOCATABLE/POINTER class dummies
+
+program main
+  implicit none
+  type t
+  end type t
+  call test_c_a ()
+  call test_u_a ()
+  call test_c_p ()
+  call test_u_p ()
+contains
+  ! class, allocatable
+  subroutine test_c_a (msg1)
+class(t), optional, allocatable :: msg1(:)
+if (present (msg1)) stop 1
+call assert_c_a ()
+call assert_c_a (msg1)
+  end
+
+  subroutine assert_c_a (msg2)
+class(t), optional, allocatable :: msg2(:)
+if (present (msg2)) stop 2
+  end
+
+  ! unlimited polymorphic, allocatable
+  subroutine test_u_a (msg1)
+class(*), optional, allocatable :: msg1(:)
+if (present (msg1)) stop 3
+call assert_u_a ()
+call assert_u_a (msg1)
+  end
+
+  subroutine assert_u_a (msg2)
+class(*), optional, allocatable :: msg2(:)
+if (present (msg2)) stop 4
+  end
+
+  ! class, pointer
+  subroutine test_c_p (msg1)
+class(t), optional, pointer :: msg1(:)
+if (present (msg1)) stop 5
+call assert_c_p ()
+call assert_c_p (msg1)
+  end
+
+  subroutine assert_c_p (msg2)
+class(t), optional, pointer :: msg2(:)
+if (present (msg2)) stop 6
+  end
+
+  ! unlimited polymorphic, pointer
+  subroutine test_u_p (msg1)
+class(*), optional, pointer :: msg1(:)
+if (present (msg1)) stop 7
+call assert_u_p ()
+call assert_u_p (msg1)
+  end
+
+  subroutine assert_u_p (msg2)
+class(*), optional, pointer :: msg2(:)
+if (present (msg2)) stop 8
+  end
+end
--
2.35.3

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

[Marek Polacek]

On Mon, Nov 20, 2023 at 10:56:36AM +0100, Florian Weimer wrote:
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -6183,6 +6183,7 @@ that have their own flag:
>  @gccoptlist{
>  -Wimplicit-function-declaration @r{(C)}
>  -Wimplicit-int @r{(C)}
> +-Wincompatible-pointer-types @r{(C)}
>  -Wint-conversion @r{(C)}
>  -Wnarrowing @r{(C++)}
>  -Wreturn-mismatch @r{(C)}

BTW, should the C ones mention Objective-C as well?

Marek

Re: [PATCH v3 10/11] c: Turn -Wincompatible-pointer-types into a permerror

[Marek Polacek]

On Mon, Nov 20, 2023 at 10:56:36AM +0100, Florian Weimer wrote:
> The change to build_conditional_expr drops the downgrade
> from a pedwarn to warning for builtins for C99 and later
> language dialects.  It remains a warning in C89 mode (not
> a permerror), as the -std=gnu89 -fno-permissive test shows.
> 
> gcc/
> 
>   * doc/invoke.texi (Warning Options): Document changes.
> 
> gcc/c/
> 
>   PR c/96284
>   * c-typeck.cc (build_conditional_expr): Upgrade most pointer
>   type mismatches to a permerror.
>   (convert_for_assignment): Use permerror_opt and
>   permerror_init for OPT_Wincompatible_pointer_types warnings.
> 
> gcc/testsuite/
> 
>   * gcc.dg/permerror-default.c (incompatible_pointer_types):
>   Expect new permerror.
>   * gcc.dg/permerror-gnu89-nopermissive.c
>   (incompatible_pointer_types):   Likewise.

Some extra spaces after :.

>   * gcc.dg/permerror-pedantic.c (incompatible_pointer_types):
>   Likewise.
>   * gcc.dg/permerror-system.c: Likewise.
>   * gcc.dg/Wincompatible-pointer-types-2.c: Compile with
>   -fpermissivedue to expected errors.

Some extra spaces after -fpermissive.

>   * gcc.dg/Wincompatible-pointer-types-5.c: New test.  Copied
>   from gcc.dg/Wincompatible-pointer-types-2.c.  Expect errors.
>   * gcc.dg/anon-struct-11.c: Compile with -fpermissive
>   due to expected errors.
>   * gcc.dg/anon-struct-11a.c: New test.  Copied from
>   gcc.dg/anon-struct-11.c.  Expect errors.
>   * gcc.dg/anon-struct-13.c: Compile with -fpermissive
>   due to expected errors.
>   * gcc.dg/anon-struct-13a.c: New test.  Copied from
>   gcc.dg/anon-struct-13.c.  Expect errors.
>   * gcc.dg/builtin-arith-overflow-4.c: Compile with -fpermissive
>   due to expected errors.
>   * gcc.dg/builtin-arith-overflow-4a.c: New test.  Copied from
>   gcc.dg/builtin-arith-overflow-4.c.  Expect errors.
>   * gcc.dg/c23-qual-4.c: Expect -Wincompatible-pointer-types errors.
>   * gcc.dg/dfp/composite-type.c: Compile with -fpermissive
>   due to expected errors.
>   * gcc.dg/dfp/composite-type-2.c: New test.  Copied from
>   gcc.dg/dfp/composite-type.c.  Expect errors.
>   * gcc.dg/diag-aka-1.c: Compile with -fpermissive
>   due to expected errors.

This may fit on one line.

>   * gcc.dg/diag-aka-1a.c: New test.  Copied from gcc.dg/diag-aka-1a.c.
>   Expect errors.
>   * gcc.dg/enum-compat-1.c: Compile with -fpermissive
>   due to expected errors.

This too.

>   * gcc.dg/enum-compat-2.c: New test.  Copied from
>   gcc.dg/enum-compat-1.c.  Expect errors.
>   * gcc.dg/func-ptr-conv-1.c: Compile with -fpermissive
>   due to expected errors.
>   * gcc.dg/func-ptr-conv-2.c: New test.  Copied from
>   gcc.dg/func-ptr-conv-1.c.  Expect errors.
>   * gcc.dg/init-bad-7.c: Compile with -fpermissive
>   due to expected errors.
>   * gcc.dg/init-bad-7a.c: New test.  Copied from gcc.dg/init-bad-7.c.
>   Expect errors.
>   * gcc.dg/noncompile/incomplete-3.c (foo): Expect
>   -Wincompatible-pointer-types error.
>   * gcc.dg/param-type-mismatch-2.c (test8): Likewise.
>   * gcc.dg/pointer-array-atomic.c: Compile with -fpermissive
>   due to expected errors.
>   * gcc.dg/pointer-array-atomic-2.c: New test.  Copied from
>   gcc.dg/pointer-array-atomic.c.  Expect errors.
>   * gcc.dg/pointer-array-quals-1.c (test): Expect
>   -Wincompatible-pointer-types errors.
>   * gcc.dg/transparent-union-1.c: Compile with -fpermissive
>   due to expected errors.
>   * gcc.dg/transparent-union-1a.c: New test.  Copied from
>   gcc.dg/transparent-union-1.c.  Expect errors.
>   * gcc.target/aarch64/acle/memtag_2a.c
>   (test_memtag_warning_return_qualifier): Expect additional
>   errors.
>   * gcc.target/aarch64/sve/acle/general-c/load_2.c (f1): Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_1.c
>   (f1): Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_2.c
>   (f1): Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_3.c
>   (f1): Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_4.c
>   (f1): Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_5.c
>   (f1): Likewise.
>   * 
> gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_1.c
>   (f1): Likewise.
>   * 
> gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_2.c
>   (f1): Likewise.
>   * 
> gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_3.c
>   (f1): Likewise.
>   * 
> gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_4.c
>   (f1): Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/sizeless-1.c (f1): Likewise.
>   * 

Re: [PATCH 4/4] libbacktrace: get debug information for loaded dlls

[Eli Zaretskii]

> Date: Thu, 30 Nov 2023 11:53:54 -0800
> Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> From: Ian Lance Taylor via Gcc 
> 
> Also starting with a module count of 1000 seems like a lot.  Do
> typical Windows programs load that many modules?

Unlikely.  I'd start with 100.

Re: Darwin: Replace environment runpath with embedded [PR88590]

[Ian Lance Taylor]

On Thu, Nov 30, 2023 at 11:56 AM Iain Sandoe  wrote:
>
> > On 30 Nov 2023, at 19:43, Ian Lance Taylor  wrote:
> >
> > On Sun, Oct 22, 2023 at 2:18 PM FX Coudert  wrote:
> >>
> >> Thanks a lot Alexandre for the review!
> >
> > This patch changed the files lingo/configure.ac and libgo/configure.
> > Those files live in an upstream repository and should be changed there
> > and then merged into the GCC repo, as described in libgo/README.gcc.
> > This is not a big deal, and I can take care of changing the upstream
> > repository.  But I don't understand the changes in libgo.  As far as I
> > can tell, all they do is add an automake conditional that is never
> > used.  Is there any reason for that?
>
> It’s not used (yet) because we do not build libgo on Darwin, if/when we
> do it would be used in the same way as for the other runtimes.
>
> >  Should I just revert the changes to libgo?
>
> That is also fine (because we do not yet build it on Darwin), it seems 
> unlikely
> we’d forget to re-add it.

Thanks, I'll make the change upstream.

Ian

Re: Darwin: Replace environment runpath with embedded [PR88590]

[Iain Sandoe]

Hi Ian

> On 30 Nov 2023, at 19:43, Ian Lance Taylor  wrote:
> 
> On Sun, Oct 22, 2023 at 2:18 PM FX Coudert  wrote:
>> 
>> Thanks a lot Alexandre for the review!
> 
> This patch changed the files lingo/configure.ac and libgo/configure.
> Those files live in an upstream repository and should be changed there
> and then merged into the GCC repo, as described in libgo/README.gcc.
> This is not a big deal, and I can take care of changing the upstream
> repository.  But I don't understand the changes in libgo.  As far as I
> can tell, all they do is add an automake conditional that is never
> used.  Is there any reason for that?

It’s not used (yet) because we do not build libgo on Darwin, if/when we
do it would be used in the same way as for the other runtimes.

>  Should I just revert the changes to libgo?

That is also fine (because we do not yet build it on Darwin), it seems unlikely
we’d forget to re-add it.

Iain


> 
> To be clear, I am asking about this change in git revision
> 6a6d3817afa02bbcd2388c8e005da6faf88932f1 and the corresponding change
> in the generated file libgo/configure.ac.  Thanks.
> 
> diff --git a/libgo/configure.ac b/libgo/configure.ac
> index 54c35c0903c..e8d66f8415d 100644
> --- a/libgo/configure.ac
> +++ b/libgo/configure.ac
> @@ -53,6 +53,7 @@ AC_LIBTOOL_DLOPEN
> AM_PROG_LIBTOOL
> AC_SUBST(enable_shared)
> AC_SUBST(enable_static)
> +AM_CONDITIONAL([ENABLE_DARWIN_AT_RPATH], [test
> x$enable_darwin_at_rpath = xyes])
> 
> CC_FOR_BUILD=${CC_FOR_BUILD:-gcc}
> AC_SUBST(CC_FOR_BUILD)

Re: [PATCH 4/4] libbacktrace: get debug information for loaded dlls

[Ian Lance Taylor]

On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers  wrote:
>
> From: Björn Schäpers 
>
> Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except
> that libraries loaded after the backtrace_initialize are not handled.
> But as far as I can see that's the same for elf.

Thanks, but I don't want a patch that loops using goto statements.
Please rewrite to avoid that.  It may be simpler to call a function.

Also starting with a module count of 1000 seems like a lot.  Do
typical Windows programs load that many modules?

Ian




> Tested on x86_64-linux and i686-w64-mingw32.
>
> -- >8 --
>
> * pecoff.c (coff_add): New argument for the module handle of the
> file, to get the base address.
> * pecoff.c (backtrace_initialize): Iterate over loaded libraries
> and call coff_add.
>
> Signed-off-by: Björn Schäpers 
> ---
>  libbacktrace/pecoff.c | 76 ---
>  1 file changed, 72 insertions(+), 4 deletions(-)
>
> diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c
> index 296f1357b5f..40395109e51 100644
> --- a/libbacktrace/pecoff.c
> +++ b/libbacktrace/pecoff.c
> @@ -49,6 +49,7 @@ POSSIBILITY OF SUCH DAMAGE.  */
>  #endif
>
>  #include 
> +#include 
>  #endif
>
>  /* Coff file header.  */
> @@ -592,7 +593,8 @@ coff_syminfo (struct backtrace_state *state, uintptr_t 
> addr,
>  static int
>  coff_add (struct backtrace_state *state, int descriptor,
>   backtrace_error_callback error_callback, void *data,
> - fileline *fileline_fn, int *found_sym, int *found_dwarf)
> + fileline *fileline_fn, int *found_sym, int *found_dwarf,
> + uintptr_t module_handle ATTRIBUTE_UNUSED)
>  {
>struct backtrace_view fhdr_view;
>off_t fhdr_off;
> @@ -623,7 +625,6 @@ coff_add (struct backtrace_state *state, int descriptor,
>int is_64;
>uintptr_t image_base;
>uintptr_t base_address = 0;
> -  uintptr_t module_handle;
>struct dwarf_sections dwarf_sections;
>
>*found_sym = 0;
> @@ -871,7 +872,6 @@ coff_add (struct backtrace_state *state, int descriptor,
>  }
>
>  #ifdef HAVE_WINDOWS_H
> -module_handle = (uintptr_t) GetModuleHandleW (NULL);
>  base_address = module_handle - image_base;
>  #endif
>
> @@ -914,12 +914,80 @@ backtrace_initialize (struct backtrace_state *state,
>int found_sym;
>int found_dwarf;
>fileline coff_fileline_fn;
> +  uintptr_t module_handle = 0;
> +
> +#ifdef HAVE_WINDOWS_H
> +  DWORD i;
> +  DWORD module_count;
> +  DWORD bytes_needed_for_modules;
> +  HMODULE *modules;
> +  char module_name[MAX_PATH];
> +  int module_found_sym;
> +  fileline module_fileline_fn;
> +
> +  module_handle = (uintptr_t) GetModuleHandleW (NULL);
> +#endif
>
>ret = coff_add (state, descriptor, error_callback, data,
> - _fileline_fn, _sym, _dwarf);
> + _fileline_fn, _sym, _dwarf, module_handle);
>if (!ret)
>  return 0;
>
> +#ifdef HAVE_WINDOWS_H
> +  module_count = 1000;
> + alloc_modules:
> +  modules = backtrace_alloc (state, module_count * sizeof(HMODULE),
> +error_callback, data);
> +  if (modules == NULL)
> +goto skip_modules;
> +  if (!EnumProcessModules (GetCurrentProcess (), modules, module_count,
> +  _needed_for_modules))
> +{
> +  error_callback(data, "Could not enumerate process modules",
> +(int) GetLastError ());
> +  goto free_modules;
> +}
> +  if (bytes_needed_for_modules > module_count * sizeof(HMODULE))
> +{
> +  backtrace_free (state, modules, module_count * sizeof(HMODULE),
> + error_callback, data);
> +  // Add an extra of 2, if some module is loaded in another thread.
> +  module_count = bytes_needed_for_modules / sizeof(HMODULE) + 2;
> +  modules = NULL;
> +  goto alloc_modules;
> +}
> +
> +  for (i = 0; i < bytes_needed_for_modules / sizeof(HMODULE); ++i)
> +{
> +  if (GetModuleFileNameA (modules[i], module_name, MAX_PATH - 1))
> +   {
> + if (strcmp (filename, module_name) == 0)
> +   continue;
> +
> + module_handle = (uintptr_t) GetModuleHandleA (module_name);
> + if (module_handle == 0)
> +   continue;
> +
> + descriptor = backtrace_open (module_name, error_callback, data, 
> NULL);
> + if (descriptor < 0)
> +   continue;
> +
> + coff_add (state, descriptor, error_callback, data,
> +   _fileline_fn, _found_sym, _dwarf,
> +   module_handle);
> + if (module_found_sym)
> +   found_sym = 1;
> +   }
> +}
> +
> + free_modules:
> +  if (modules)
> +backtrace_free(state, modules, module_count * sizeof(HMODULE),
> +  error_callback, data);
> +  modules = NULL;
> + skip_modules:
> +#endif
> +
>if (!state->threaded)
>  {
>if (found_sym)
> --
> 2.38.1
>

Re: [PATCH v3 08/11] c: Do not ignore some forms of -Wimplicit-int in system headers

[Marek Polacek]

On Mon, Nov 20, 2023 at 10:56:26AM +0100, Florian Weimer wrote:
> Most -Wimplicit-int warnings were unconditionally disabled for system
> headers.  Only missing types for parameters in old-style function
> definitions resulted in warnings.  This is inconsistent with the
> treatment of other permerrors, which are active in system headers.

LGTM.
 
> gcc/c/
> 
>   * c-decl.cc (grokdeclarator): Do not skip -Wimplicit-int
>   warnings or errors in system headers.
> 
> gcc/testsuite/
> 
>   * gcc.dg/permerror-system.c: Expect all -Wimplicit-int
>   permerrors.
> ---
>  gcc/c/c-decl.cc | 2 +-
>  gcc/testsuite/gcc.dg/permerror-system.c | 5 +
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
> index 893e24f7dc6..d16958113a8 100644
> --- a/gcc/c/c-decl.cc
> +++ b/gcc/c/c-decl.cc
> @@ -6845,7 +6845,7 @@ grokdeclarator (const struct c_declarator *declarator,
>  
>/* Diagnose defaulting to "int".  */
>  
> -  if (declspecs->default_int_p && !in_system_header_at (input_location))
> +  if (declspecs->default_int_p)
>  {
>/* Issue a warning if this is an ISO C 99 program or if
>-Wreturn-type and this is a function, or if -Wimplicit;
> diff --git a/gcc/testsuite/gcc.dg/permerror-system.c 
> b/gcc/testsuite/gcc.dg/permerror-system.c
> index 60c65ffc1d4..cad48c93f90 100644
> --- a/gcc/testsuite/gcc.dg/permerror-system.c
> +++ b/gcc/testsuite/gcc.dg/permerror-system.c
> @@ -10,7 +10,12 @@
>  
>  /* { dg-error "'f1' \\\[-Wimplicit-function-declaration\\\]" "" { target 
> *-*-* } 10 } */
>  
> +/* { dg-error "'implicit_int_1' \\\[-Wimplicit-int\\\]" "" { target *-*-* } 
> 13 } */
> +/* { dg-error "'implicit_int_2' \\\[-Wimplicit-int\\\]" "" { target *-*-* } 
> 14 } */
> +/* { dg-error "'implicit_int_3' \\\[-Wimplicit-int\\]" "" { target *-*-* } 
> 15 } */
> +/* { dg-error "return type defaults to 'int' \\\[-Wimplicit-int\\\]" "" { 
> target *-*-* } 16 } */
>  /* { dg-error "type of 'i' defaults to 'int' \\\[-Wimplicit-int\\\]" "" { 
> target *-*-*} 16 } */
> +/* { dg-error "type defaults to 'int' in type name \\\[-Wimplicit-int\\\]" 
> "" { target *-*-* } 19 } */
>  
>  /* { dg-error "pointer/integer type mismatch in conditional expression 
> \\\[-Wint-conversion\\\]" "" { target *-*-* } 29 } */
>  /* { dg-error "pointer/integer type mismatch in conditional expression 
> \\\[-Wint-conversion\\\]" "" { target *-*-* } 30 } */
> -- 
> 2.42.0
> 
> 

Marek

Re: [PATCH v3 07/11] c: Turn -Wimplicit-int into a permerror

[Marek Polacek]

On Mon, Nov 20, 2023 at 10:56:20AM +0100, Florian Weimer wrote:
> Most of these new permerrors are currently not diagnosed in system
> headers.
> 
> gcc/
> 
>   PR c/91093
>   PR c/96284
>   * doc/invoke.texi (Warning Options): Document changes.
> 
> gcc/c/
> 
>   * c-decl.cc (warn_defaults_to): Remove.
>   (grok_declarator, start_function): Call permerror_opt
>   instead of warn_defaults_to.
>   (store_parm_decls_oldstyle): Call permerror_opt for
>   OPT_Wimplicit_int.
> 
> gcc/testsuite/
> 
>   * gcc.dg/permerror-default.c (implicit_int_1, implicit_int_2)
>   (implicit_int_3, implicit_int_4): Expect new permerror.
>   * gcc.dg/permerror-system.c: Expect a single new permerror.
>   * gcc.dg/Wimplicit-int-1.c: Compile with -fpermissive due to
>   expected warning.
>   * gcc.dg/Wimplicit-int-4.c: Likewise.
>   * gcc.dg/Wimplicit-int-1a.c: New test.  Copied from
>   gcc.dg/Wimplicit-int-1.c, but expect errors.
>   * gcc.dg/Wimplicit-int-4a.c: New test.  Copied from
>   gcc.dg/Wimplicit-int-4.c, but expect errors.
>   * gcc.dg/gnu23-attr-syntax-2.c: Compile with -fpermissive
>   due to expected implicit-int error.
>   * gcc.dg/gnu23-attr-syntax-3.c: New test.  Copied from
>   gcc.dg/gnu23-attr-syntax-2.c, but expect an error.
>   * gcc.dg/pr105635.c: Build with -fpermissive due to implicit
>   int.
>   * gcc.dg/pr105635-2.c: New test.  Copied from
>   gcc.dg/pr105635.c.  Expect implicit int error.
>   * gcc.dg/noncompile/pr79758.c: Build with -fpermissive due to
>   implicitint.

Some extra whitespaces here.

The patch looks good.

>   * gcc.dg/noncompile/pr79758-2.c: New test.  Copied from
>   gcc.dg/noncompile/pr79758.c.  Expect implicit int error.
> ---
>  gcc/c/c-decl.cc | 43 ++---
>  gcc/doc/invoke.texi |  7 +++-
>  gcc/testsuite/gcc.dg/Wimplicit-int-1.c  |  2 +-
>  gcc/testsuite/gcc.dg/Wimplicit-int-1a.c | 11 ++
>  gcc/testsuite/gcc.dg/Wimplicit-int-4.c  |  2 +-
>  gcc/testsuite/gcc.dg/Wimplicit-int-4a.c | 11 ++
>  gcc/testsuite/gcc.dg/gnu23-attr-syntax-2.c  |  2 +-
>  gcc/testsuite/gcc.dg/gnu23-attr-syntax-3.c  | 17 
>  gcc/testsuite/gcc.dg/noncompile/pr79758-2.c |  6 +++
>  gcc/testsuite/gcc.dg/noncompile/pr79758.c   |  1 +
>  gcc/testsuite/gcc.dg/permerror-default.c| 12 +++---
>  gcc/testsuite/gcc.dg/permerror-system.c |  2 +
>  gcc/testsuite/gcc.dg/pr105635-2.c   | 11 ++
>  gcc/testsuite/gcc.dg/pr105635.c |  2 +-
>  14 files changed, 86 insertions(+), 43 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/Wimplicit-int-1a.c
>  create mode 100644 gcc/testsuite/gcc.dg/Wimplicit-int-4a.c
>  create mode 100644 gcc/testsuite/gcc.dg/gnu23-attr-syntax-3.c
>  create mode 100644 gcc/testsuite/gcc.dg/noncompile/pr79758-2.c
>  create mode 100644 gcc/testsuite/gcc.dg/pr105635-2.c
> 
> diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
> index 011f0bf0a69..893e24f7dc6 100644
> --- a/gcc/c/c-decl.cc
> +++ b/gcc/c/c-decl.cc
> @@ -647,8 +647,6 @@ static tree grokdeclarator (const struct c_declarator *,
>   bool *, enum deprecated_states);
>  static tree grokparms (struct c_arg_info *, bool);
>  static void layout_array_type (tree);
> -static void warn_defaults_to (location_t, int, const char *, ...)
> -ATTRIBUTE_GCC_DIAG(3,4);
>  static const char *header_for_builtin_fn (tree);
>  
>  /* T is a statement.  Add it to the statement-tree.  This is the
> @@ -6570,23 +6568,6 @@ warn_variable_length_array (tree name, tree size)
>  }
>  }
>  
> -/* Print warning about defaulting to int if necessary.  */
> -
> -static void
> -warn_defaults_to (location_t location, int opt, const char *gmsgid, ...)
> -{
> -  diagnostic_info diagnostic;
> -  va_list ap;
> -  rich_location richloc (line_table, location);
> -
> -  va_start (ap, gmsgid);
> -  diagnostic_set_info (, gmsgid, , ,
> -   flag_isoc99 ? DK_PEDWARN : DK_WARNING);
> -  diagnostic.option_index = opt;
> -  diagnostic_report_diagnostic (global_dc, );
> -  va_end (ap);
> -}
> -
>  /* Returns the smallest location != UNKNOWN_LOCATION in LOCATIONS,
> considering only those c_declspec_words found in LIST, which
> must be terminated by cdw_number_of_elements.  */
> @@ -6875,12 +6856,12 @@ grokdeclarator (const struct c_declarator *declarator,
>else
>   {
> if (name)
> - warn_defaults_to (loc, OPT_Wimplicit_int,
> -   "type defaults to % in declaration "
> -   "of %qE", name);
> + permerror_opt (loc, OPT_Wimplicit_int,
> +"type defaults to % in declaration "
> +"of %qE", name);
> else
> - warn_defaults_to (loc, OPT_Wimplicit_int,
> -   "type defaults to % in type name");
> + 

Re: [PATCH] libgo, libstdc++: Regenerate GCC_CHECK_ASSEMBLER_HWCAP users

[Ian Lance Taylor]

On Thu, Nov 30, 2023 at 1:30 AM Rainer Orth  
wrote:
>
> the gcc-autoregen bot correctly complained that the libgo and libstdc++
> configure scripts hadn't been regenerated.  I'd have commited the
> following as obvious (just whitespace change), but since libgo is
> imported from upstream, I'm uncertain how best to handle that part.

I can update libgo/configure upstream, but first I'd like to
understand the change in git revision
6a6d3817afa02bbcd2388c8e005da6faf88932f1, which seems unnecessary.
Asked in https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638814.html.

Ian

Re: [PATCH v3 05/11] c: Turn int-conversion warnings into permerrors

[Florian Weimer]

* Marek Polacek:

>>  permerror_init for -Wint-conversion warnings.
>
> A few extra whitespaces.

>>  * gcc.dg/assign-warn-4.c: New file.  Extracted from
>>  assign-warn1.c.  Expect int-cnversion errors.
>
> "int-conversion" (sorry about pointing out typos...)
>
>>  * gcc.dg/diagnostic-types-1.c: compile with -fpermissive.
>
> s/compile/Compile/

All fixed, thanks.

Florian

Re: Darwin: Replace environment runpath with embedded [PR88590]

[Ian Lance Taylor]

On Sun, Oct 22, 2023 at 2:18 PM FX Coudert  wrote:
>
> Thanks a lot Alexandre for the review!

This patch changed the files lingo/configure.ac and libgo/configure.
Those files live in an upstream repository and should be changed there
and then merged into the GCC repo, as described in libgo/README.gcc.
This is not a big deal, and I can take care of changing the upstream
repository.  But I don't understand the changes in libgo.  As far as I
can tell, all they do is add an automake conditional that is never
used.  Is there any reason for that?  Should I just revert the changes
to libgo?

To be clear, I am asking about this change in git revision
6a6d3817afa02bbcd2388c8e005da6faf88932f1 and the corresponding change
in the generated file libgo/configure.ac.  Thanks.

diff --git a/libgo/configure.ac b/libgo/configure.ac
index 54c35c0903c..e8d66f8415d 100644
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -53,6 +53,7 @@ AC_LIBTOOL_DLOPEN
 AM_PROG_LIBTOOL
 AC_SUBST(enable_shared)
 AC_SUBST(enable_static)
+AM_CONDITIONAL([ENABLE_DARWIN_AT_RPATH], [test
x$enable_darwin_at_rpath = xyes])

 CC_FOR_BUILD=${CC_FOR_BUILD:-gcc}
 AC_SUBST(CC_FOR_BUILD)

[PATCH] htdocs/git.html: correct spelling and use git in example

[Jonny Grant]

ChangeLog:

htdocs/git.html: change example to use git:// and correct
spelling repostiory -> repository .



>From fad03a107f5f8734e9eeafb618cdb30fa100cbbb Mon Sep 17 00:00:00 2001
From: Jonathan Grant 
Date: Thu, 30 Nov 2023 17:55:49 +
Subject: [PATCH] htdocs/git.html: change example to use git:// and correct
 spelling repostiory -> repository

---
 htdocs/git.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/htdocs/git.html b/htdocs/git.html
index 22c0eec1..45d5cf9d 100644
--- a/htdocs/git.html
+++ b/htdocs/git.html
@@ -44,7 +44,7 @@ through, you can replace git:// with 
https://.
 If there is another local repository accessible you can avoid
 re-downloading everything by using --reference, e.g.
 
-git clone --reference original-gcc --dissociate 
ssh://gcc.gnu.org/git/gcc.git new-gcc
+git clone --reference original-gcc --dissociate 
git://gcc.gnu.org/git/gcc.git new-gcc
 
 But if you own this other copy, you probably want to use
 separate worktrees instead of multiple clones.
@@ -236,7 +236,7 @@ additional branches can also be fetched if necessary.
 
 
 You can download any of the additional branches by adding a suitable
-fetch specification to your local copy of the git repostiory.  For
+fetch specification to your local copy of the git repository.  For
 example, if your remote is called 'origin' (the default with git
 clone) you can add the 'dead' development branches by running:
 
-- 
2.40.1

Re: [PATCH 3/4] libbacktrace: work with aslr on windows

[Ian Lance Taylor]

On Mon, Nov 20, 2023 at 11:58 AM Björn Schäpers  wrote:
>
> An updated version, using neither A or W, but just the macro.

Thanks.  Committed as follows.

Ian
1017495bc91d40570f58c37e88ca013164782129
diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c
index 56af4828e27..f976a963bf3 100644
--- a/libbacktrace/pecoff.c
+++ b/libbacktrace/pecoff.c
@@ -39,6 +39,18 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #include "backtrace.h"
 #include "internal.h"
 
+#ifdef HAVE_WINDOWS_H
+#ifndef WIN32_MEAN_AND_LEAN
+#define WIN32_MEAN_AND_LEAN
+#endif
+
+#ifndef NOMINMAX
+#define NOMINMAX
+#endif
+
+#include 
+#endif
+
 /* Coff file header.  */
 
 typedef struct {
@@ -610,6 +622,7 @@ coff_add (struct backtrace_state *state, int descriptor,
   int debug_view_valid;
   int is_64;
   uintptr_t image_base;
+  uintptr_t base_address = 0;
   struct dwarf_sections dwarf_sections;
 
   *found_sym = 0;
@@ -856,7 +869,16 @@ coff_add (struct backtrace_state *state, int descriptor,
  + (sections[i].offset - min_offset));
 }
 
-  if (!backtrace_dwarf_add (state, /* base_address */ 0, _sections,
+#ifdef HAVE_WINDOWS_H
+  {
+uintptr_t module_handle;
+
+module_handle = (uintptr_t) GetModuleHandle (NULL);
+base_address = module_handle - image_base;
+  }
+#endif
+
+  if (!backtrace_dwarf_add (state, base_address, _sections,
0, /* FIXME: is_bigendian */
NULL, /* altlink */
error_callback, data, fileline_fn,

[PATCH] libstdc++: Simplify ranges::to closure objects

[Patrick Palka]

Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

-- >8 --

Use the existing _Partial range adaptor closure object in the
definition of ranges::to instead of essentially open coding it.

libstdc++-v3/ChangeLog:

* include/std/ranges (__detail::_ToClosure): Replace with ...
(__detail::_To): ... this.
(__detail::_ToClosure2): Replace with ...
(__detail::To2): ... this.
(to): Simplify using the existing _Partial range adaptor
closure object.
---
 libstdc++-v3/include/std/ranges | 140 
 1 file changed, 32 insertions(+), 108 deletions(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 9d4c2e01c4d..33e576e563a 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -1007,6 +1007,7 @@ namespace views::__adaptor
 
   // Invoke _Adaptor with arguments __r, _M_args... according to the
   // value category of this _Partial object.
+  // TODO: use explicit object functions ("deducing this").
   template
requires __adaptor_invocable<_Adaptor, _Range, const _Args&...>
constexpr auto
@@ -1137,6 +1138,7 @@ namespace views::__adaptor
 
   // Invoke _M_rhs(_M_lhs(__r)) according to the value category of this
   // range adaptor closure object.
+  // TODO: use explicit object functions ("deducing this").
   template
requires __pipe_invocable
constexpr auto
@@ -9391,59 +9393,16 @@ namespace __detail
 /// @cond undocumented
 namespace __detail
 {
-  template
-class _ToClosure
-: public views::__adaptor::_RangeAdaptorClosure<_ToClosure<_Cont, 
_Args...>>
+  template
+struct _To
 {
-  tuple...> _M_bound_args;
-
-public:
-  constexpr
-  _ToClosure(_Args&&... __args)
-  : _M_bound_args(std::forward<_Args>(__args)...)
-  { }
-
-  // TODO: use explicit object functions ("deducing this").
-
-  template
-   constexpr auto
-   operator()(_Rg&& __r) &
-   {
- return std::apply([&__r](_Tp&&... __args) {
-   return ranges::to<_Cont>(std::forward<_Rg>(__r),
-std::forward<_Tp>(__args)...);
- }, _M_bound_args);
-   }
-
-  template
-   constexpr auto
-   operator()(_Rg&& __r) const &
-   {
- return std::apply([&__r](_Tp&&... __args) {
-   return ranges::to<_Cont>(std::forward<_Rg>(__r),
-std::forward<_Tp>(__args)...);
- }, _M_bound_args);
-   }
-
-  template
-   constexpr auto
-   operator()(_Rg&& __r) &&
-   {
- return std::apply([&__r](_Tp&&... __args) {
-   return ranges::to<_Cont>(std::forward<_Rg>(__r),
-std::forward<_Tp>(__args)...);
- }, std::move(_M_bound_args));
-   }
-
-  template
-   constexpr auto
-   operator()(_Rg&& __r) const &&
-   {
- return std::apply([&__r](_Tp&&... __args) {
-   return ranges::to<_Cont>(std::forward<_Rg>(__r),
-std::forward<_Tp>(__args)...);
- }, std::move(_M_bound_args));
-   }
+  template
+  constexpr auto
+  operator()(_Range&& __r, _Args&&... __args) const
+  {
+   return ranges::to<_Cont>(std::forward<_Range>(__r),
+std::forward<_Args>(__args)...);
+  }
 };
 } // namespace __detail
 /// @endcond
@@ -9465,66 +9424,27 @@ namespace __detail
*/
   template
 requires (!view<_Cont>)
-constexpr __detail::_ToClosure<_Cont, _Args...>
+constexpr auto
 to [[nodiscard]] (_Args&&... __args)
-{ return {std::forward<_Args>(__args)...}; }
+{
+  using __detail::_To;
+  using views::__adaptor::_Partial;
+  return _Partial<_To<_Cont>, 
decay_t<_Args>...>{std::forward<_Args>(__args)...};
+}
 
 /// @cond undocumented
 namespace __detail
 {
-  template typename _Cont, typename... _Args>
-class _ToClosure2
-: public views::__adaptor::_RangeAdaptorClosure<_ToClosure2<_Cont, 
_Args...>>
+  template typename _Cont>
+struct _To2
 {
-  tuple...> _M_bound_args;
-
-public:
-  constexpr
-  _ToClosure2(_Args&&... __args)
-  : _M_bound_args(std::forward<_Args>(__args)...)
-  { }
-
-  // TODO: use explicit object functions ("deducing this").
-
-  template
-   constexpr auto
-   operator()(_Rg&& __r) &
-   {
- return std::apply([&__r](_Tp&&... __args) {
-   return ranges::to<_Cont>(std::forward<_Rg>(__r),
-std::forward<_Tp>(__args)...);
- }, _M_bound_args);
-   }
-
-  template
-   constexpr auto
-   operator()(_Rg&& __r) const &
-   {
- return std::apply([&__r](_Tp&&... __args) {
-   return ranges::to<_Cont>(std::forward<_Rg>(__r),
-std::forward<_Tp>(__args)...);
- 

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

[Jeff Law]

On 11/30/23 11:31, Joern Rennecke wrote:



Pretending the vector modes don't happen is not making the code safe.
We have to handle them somehow, so we might as well do that in a way
that is consistent and gives more potential for optimization.
We're not pretending they don't happen.  Quite the opposite.  When we 
see them we need to take appropriate action.


For a set you can ignore since that means we'll keep objects live longer 
than they normally would have been -- which is the safe thing for this pass.


For a use, you can't ignore, ever.  You must always make live anything 
that is potentially used or you run the risk of incorrect code generation.


If that's not what we're doing now, then let's fix that without 
introducing a whole new set of optimizations that need to be analyzed 
and debugged.


I would have been all for this work a month ago, but we're past stage1 
close so the focus needs to be on cleaning up what we've got for gcc-14.


Jeff

Re: [PATCH v3 06/11] c: Turn -Wimplicit-function-declaration into a permerror

[Marek Polacek]

On Mon, Nov 20, 2023 at 10:56:16AM +0100, Florian Weimer wrote:
> In the future, it may make sense to avoid cascading errors from
> the implicit declaration, especially its assumed int return type.
> This change here only changes the kind of the diagnostic, not
> its wording or consequences.

Looks fine.
 
> gcc/
> 
>   * doc/invoke.texi (Warning Options): Document changes.
> 
> gcc/c/
> 
>   PR c/91092
>   PR c/96284
>   * c-decl.cc (implicit_decl_permerror): Rename from
>   implicit_decl_warning.  Call permerror_opt instead of
>   pedwarn and warning_at.
>   (implicitly_declare): Adjust callers.
> 
> gcc/testsuite/
> 
>   * gcc.dg/permerror-default.c (implicit_function_declaration):
>   Expect the new permerror.
>   * gcc.dg/permerror-system.c: Likewise.
>   * c-c++-common/spellcheck-reserved.c (test, test_2): Expect
>   error instead of warning.
>   (f): Expect error instead of warning.
>   * gcc.dg/Wimplicit-function-declaration-c99.c: Compile with
>   -fpermissive due to expected warning.
>   * gcc.dg/Wimplicit-function-declaration-c99-2.c: New test.
>   Copied from gcc.dg/Wimplicit-function-declaration-c99.c.
>   Expect error.
>   * gcc.dg/missing-header-fixit-1.c: Compile with -fpermissive
>   due to expect error.
>   * gcc.dg/missing-header-fixit-1a.c: New test.  Copied from
>   gcc.dg/missing-header-fixit-1.c, but expect error.
>   * gcc.dg/missing-header-fixit-2.c: Compile with -fpermissive
>   due to expect error.
>   * gcc.dg/missing-header-fixit-2a.c: New test.  Copied from
>   gcc.dg/missing-header-fixit-2.c, but expect error.
>   * gcc.dg/missing-header-fixit-4.c: Compile with -fpermissive
>   due to expect error.
>   * gcc.dg/missing-header-fixit-4a.c: New test.  Copied from
>   gcc.dg/missing-header-fixit-4.c, but expect error.
>   * gcc.dg/missing-header-fixit-5.c: Compile with -fpermissive
>   due to expect error.
>   * gcc.dg/missing-header-fixit-5a.c: New test.  Copied from
>   gcc.dg/missing-header-fixit-5.c, but expect error.
>   * gcc.dg/pr61852.c: Expect implicit-function-declaration
>   error instead of warning.
>   * gcc.dg/spellcheck-identifiers-2.c: Compile with
>   -fpermissive due to expected warnings.
>   * gcc.dg/spellcheck-identifiers-2a.c: New test.  Copied
>   from gcc.dg/spellcheck-identifiers-2a.c.  Expect errors.
>   * gcc.dg/spellcheck-identifiers-3.c: Compile with
>   -fpermissive due to expected warnings.
>   * gcc.dg/spellcheck-identifiers-3a.c: New test.  Copied
>   from gcc.dg/spellcheck-identifiers-2a.c.  Expect errors.
>   * gcc.dg/spellcheck-identifiers-4.c: Compile with
>   -fpermissive due to expected warnings.
>   * gcc.dg/spellcheck-identifiers-4a.c: New test.  Copied
>   from gcc.dg/spellcheck-identifiers-2a.c.  Expect error.
>   * gcc.dg/spellcheck-identifiers.c: Compile with
>   -fpermissive due to expected warnings.
>   * gcc.dg/spellcheck-identifiers-1a.c: New test.  Copied
>   from gcc.dg/spellcheck-identifiers.c.  Expect errors.
>   * gcc.target/aarch64/sve/acle/general-c/ld1sh_gather_1.c (f1):
>   Expect error.
>   * gcc.target/aarch64/sve/acle/general-c/load_ext_gather_index_1.c:
>   (f1): Likewise.
>   * 
> gcc.target/aarch64/sve/acle/general-c/load_ext_gather_index_restricted_1.c:
>   (f1): Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_1.c:
>   (f1): Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_2.c:
>   (f1): Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_3.c:
>   (f1): Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_4.c:
>   (f1): Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_5.c:
>   (f1): Likewise.
>   * 
> gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_1.c:
>   (f1): Likewise.
>   * 
> gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_2.c:
>   (f1): Likewise.
>   * 
> gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_3.c:
>   (f1): Likewise.
>   * 
> gcc.target/aarch64/sve/acle/general-c/load_ext_gather_offset_restricted_4.c:
>   (f1): Likewise.
> ---
>  gcc/c/c-decl.cc   |  20 +--
>  gcc/doc/invoke.texi   |   8 +-
>  .../c-c++-common/spellcheck-reserved.c|   4 +-
>  .../Wimplicit-function-declaration-c99-2.c|   7 +
>  .../Wimplicit-function-declaration-c99.c  |   2 +-
>  gcc/testsuite/gcc.dg/missing-header-fixit-1.c |   2 +-
>  .../gcc.dg/missing-header-fixit-1a.c  |  37 +
>  gcc/testsuite/gcc.dg/missing-header-fixit-2.c |   2 +-
>  .../gcc.dg/missing-header-fixit-2a.c  |  31 
>  gcc/testsuite/gcc.dg/missing-header-fixit-4.c |   2 

Re: [PATCH v3 05/11] c: Turn int-conversion warnings into permerrors

[Marek Polacek]

On Mon, Nov 20, 2023 at 10:56:09AM +0100, Florian Weimer wrote:
> gcc/
> 
>   * doc/invoke.texi (Warning Options): Document changes.

Let's be more specific here.
 
> gcc/c/
> 
>   PR c/96284
>   PR c/106416
>   * c-typeck.cc (build_conditional_expr): Use permerror_opt for
>   pointer/integer type mismatches, based on -Wint-conversion.
>   (pedwarn_permerror_init, permerror_init): New function.
>   (pedwarn_init): Call pedwarn_permerror_init.
>   (convert_for_assignment): Use permerror_opt and
>   permerror_init for -Wint-conversion warnings.

A few extra whitespaces.
 
> gcc/testsuite/
> 
>   * gcc.dg/permerror-default.c (int_conversion_1)
>   (int_conversion_2): Expect the new permerrors.
>   * gcc.dg/permerror-gnu89-nopermissive.c (int_conversion_1)
>   (int_conversion_2): Likewise.
>   * gcc.dg/permerror-system.c: Likewise.
>   * c-c++-common/pr77624-1.c (foo, bar): Expect
>   error instead of warning.
>   * gcc.dg/Wint-conversion-2.c: Compile with -fpermissive due
>   to expected int-conversion warning.
>   * gcc.dg/Wint-conversion-3.c: Likewise.
>   * gcc.dg/Wint-conversion-4.c: New test.  Based on
>   gcc.dg/Wint-conversion-3.c.  Expect int-conversion errors.
>   * gcc.dg/assign-warn-1.c: Compile with -fpermissive.
>   * gcc.dg/assign-warn-4.c: New file.  Extracted from
>   assign-warn1.c.  Expect int-cnversion errors.

"int-conversion" (sorry about pointing out typos...)

>   * gcc.dg/diagnostic-types-1.c: compile with -fpermissive.

s/compile/Compile/

>   * gcc.dg/diagnostic-types-2.c: New file.  Extracted from
>   gcc.dg/diagnostic-types-1.c.  Expect some errors instead of
>   warnings.
>   * gcc.dg/gomp/pr35738.c: Compile with -fpermissive due to
>   expected int-conversion error.
>   * gcc.dg/gomp/pr35738-2.c: New test.  Based on
>   gcc.dg/gomp/pr35738.c.  Expect int-converison errors.
>   * gcc.dg/init-excess-3.c: Expect int-converison errors.
>   * gcc.dg/overflow-warn-1.c: Likewise.
>   * gcc.dg/overflow-warn-3.c: Likewise.
>   * gcc.dg/param-type-mismatch.c: Compile with -fpermissive.
>   * gcc.dg/param-type-mismatch-2.c: New test.  Copied from
>   gcc.dg/param-type-mismatch.c.  Expect errors.
>   * gcc.dg/pr61162-2.c: Compile with -fpermissive.
>   * gcc.dg/pr61162-3.c: New test. Extracted from
>   gcc.dg/pr61162-2.c.  Expect int-conversion errors.
>   * gcc.dg/spec-barrier-3.c: Use -fpermissive due to expected
>   int-conversion error.
>   * gcc.dg/spec-barrier-3a.c: New test.  Based on
>   gcc.dg/spec-barrier-3.c.  Expect int-conversion errors.
>   * gcc.target/aarch64/acle/memtag_2.c: Use -fpermissive due to expected
>   int-conversion error.
>   * gcc.target/aarch64/acle/memtag_2a.c: New test.  Copied from
>   gcc.target/aarch64/acle/memtag_2.c.  Expect error.
>   * gcc.target/aarch64/sve/acle/general-c/load_3.c (f1): Expect
>   error.
>   * gcc.target/aarch64/sve/acle/general-c/store_2.c (f1): Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/store_scatter_index_1.c
>   (f1): Likewise.
>   * 
> gcc.target/aarch64/sve/acle/general-c/store_scatter_index_restricted_1.c
>   (f1): Likewise.
>   * gcc.target/aarch64/sve/acle/general-c/store_scatter_offset_2.c
>   (f1): Likewise.
>   * 
> gcc.target/aarch64/sve/acle/general-c/store_scatter_offset_restricted_1.c
>   (f1): Likewise.
> ---
>  gcc/c/c-typeck.cc |  97 +
>  gcc/doc/invoke.texi   |   6 +
>  gcc/testsuite/c-c++-common/pr77624-1.c|   4 +-
>  gcc/testsuite/gcc.dg/Wint-conversion-2.c  |   2 +-
>  gcc/testsuite/gcc.dg/Wint-conversion-3.c  |   2 +-
>  gcc/testsuite/gcc.dg/Wint-conversion-4.c  |  14 ++
>  gcc/testsuite/gcc.dg/assign-warn-1.c  |   2 +-
>  gcc/testsuite/gcc.dg/assign-warn-4.c  |  21 ++
>  gcc/testsuite/gcc.dg/diagnostic-types-1.c |   2 +-
>  gcc/testsuite/gcc.dg/diagnostic-types-2.c |  24 +++
>  gcc/testsuite/gcc.dg/gomp/pr35738-2.c |  18 ++
>  gcc/testsuite/gcc.dg/gomp/pr35738.c   |   2 +-
>  gcc/testsuite/gcc.dg/init-excess-3.c  |   4 +-
>  gcc/testsuite/gcc.dg/overflow-warn-1.c|   4 +-
>  gcc/testsuite/gcc.dg/overflow-warn-3.c|   4 +-
>  gcc/testsuite/gcc.dg/param-type-mismatch-2.c  | 187 ++
>  gcc/testsuite/gcc.dg/param-type-mismatch.c|   2 +-
>  gcc/testsuite/gcc.dg/permerror-default.c  |  20 +-
>  .../gcc.dg/permerror-gnu89-nopermissive.c |  20 +-
>  gcc/testsuite/gcc.dg/permerror-system.c   |  13 +-
>  gcc/testsuite/gcc.dg/pr61162-2.c  |   2 +-
>  gcc/testsuite/gcc.dg/pr61162-3.c  |  13 ++
>  gcc/testsuite/gcc.dg/spec-barrier-3.c |   2 +-
>  gcc/testsuite/gcc.dg/spec-barrier-3a.c|  13 ++
>  .../gcc.target/aarch64/acle/memtag_2.c|   4 +-
>  

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

[Joern Rennecke]

On Thu, 30 Nov 2023 at 17:53, Jeff Law  wrote:
 > >  * ext-dce.c: Fixes for carry handling.
> >
> >  * ext-dce.c (safe_for_live_propagation): Handle MINUS.
> >(ext_dce_process_uses): Break out carry handling into ..
> >(carry_backpropagate): This new function.
> >Better handling of ASHIFT.
> >Add handling of SMUL_HIGHPART, UMUL_HIGHPART, SIGN_EXTEND, SS_ASHIFT 
> > and
> >US_ASHIFT.
> >
> >  * ext-dce.c: fix SUBREG_BYTE test
> >
> >  As mentioned in
> >  https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637486.html
> >  and
> >  https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638473.html
> >
> >
> > diff --git a/gcc/ext-dce.cc b/gcc/ext-dce.cc
> > index 4e4c57de117..228c50e8b73 100644
> > --- a/gcc/ext-dce.cc
> > +++ b/gcc/ext-dce.cc
> > @@ -38,7 +38,10 @@ along with GCC; see the file COPYING3.  If not see
> >  bit 0..7   (least significant byte)
> >  bit 8..15  (second least significant byte)
> >  bit 16..31
> > -   bit 32..BITS_PER_WORD-1  */
> > +   bit 32..BITS_PER_WORD-1
> > +
> > +   For vector modes, we apply these bit groups to every lane; if any of the
> > +   bits in the group are live in any lane, we consider this group live.  */
> Why add vector modes now?  I realize it might help a vectorized sub*_dct
> from x264, but I was thinking that would be more of a gcc-15 improvement.

Actually, we already did, but because it was unintentional, it wasn't
done properly.

I've been using BEG_MODE_BITSIZE(GET_MODE (x)).to_constant, thinking a mode
should just have a constant size that can easily fit into an int.  I was wrong.
Debugging found that was a scalable vector mode.  SUBREGs, shifts and
other stuff
has vector modes and goes through the code.  Instead of adding code to bail our,
I though it would be a good idea to think about how vector modes can
be supported
without balooning the computation time or memory.  And keeping in mind
the original
intention of the patch - eliminating redundant sign/zero extension -
that actually can
applied to vectors as well, and that means we should consider how
these operations
work on each lane.

By looking at the inner mode of a vector, we also conventiently also
get a sane size.
For complex numbers, it's also saner to treat them as two-element vectors, tham
trying to apply the bit parts while ignoring the structure, so it
makes sense to use
GET_MODE_INNER in general.

Something that could be done for further improvement but seems too complex
for gcc 14 would be to handle vector constants as shift counts.

Come to think of it, I actually applied the wrong test for the integer
shift counts -
it should be CONST_INT_P, not CONSTANT_P.

> >
> >   /* Note this pass could be used to narrow memory loads too.  It's
> >  not clear if that's profitable or not in general.  */
>
> > @@ -96,6 +100,8 @@ safe_for_live_propagation (rtx_code code)
> >   case SS_ASHIFT:
> >   case US_ASHIFT:
> >   case ASHIFT:
> > +case LSHIFTRT:
> > +case ASHIFTRT:
> > return true;
> So this starts to touch on a cleanup Richard mentioned.  The codes in
> there until now were supposed to be safe across the board.

Saturating operations are not safe at all without explicitly computing
the liveness propagation.

>  As we add
> things like LSHIFTRT, we need to describe how to handle liveness
> transfer from the destination into the source(s).  I think what Richard
> is asking for is to just have one place which handles both.

LSHIFTRT is much simpler than the saturating operations.

> Anyway, my current plan would be to pull in the formatting fixes, the
> back propagation without the vector enhancement.

Pretending the vector modes don't happen is not making the code safe.
We have to handle them somehow, so we might as well do that in a way
that is consistent and gives more potential for optimization.

Re: [PATCH v3 04/11] Add tests for validating future C permerrors

[Jakub Jelinek]

On Thu, Nov 30, 2023 at 12:39:22PM -0500, Marek Polacek wrote:
> On Thu, Nov 30, 2023 at 06:37:21PM +0100, Florian Weimer wrote:
> > * Marek Polacek:
> > 
> > >> +void
> > >> +implicit_function_declaration (void)
> > >> +{
> > >> +  f1 (); /* { dg-warning "'f1' \\\[-Wimplicit-function-declaration\\\]" 
> > >> } */
> > >> +}
> > >> +
> > >> +extern implicit_int_1; /* { dg-warning "'implicit_int_1' 
> > >> \\\[-Wimplicit-int\\\]" } */
> > >
> > > Oy, these \ tend to get unwieldy.  You could probably just say
> > > { dg-warning {-Wimplicit-int} }
> > 
> > I wanted to have some more context for the other files that might get
> > the explict line number wrong.
> > 
> > >> +return incompatible_pointer_types; /* { dg-error "returning 'int 
> > >> \\\* \\\(\\\*\\\)\\\(int\\\)' from a function with incompatible return 
> > >> type 'int \\\*' \\\[-Wincompatible-pointer-types\\\]" } */
> > >
> > > And here maybe
> > > { dg-error {returning 'int \* \(\*\)\(int\)' from a function with 
> > > incompatible return type 'int \*' \[-Wincompatible-pointer-types\]} }
> > > could work the same.  But you don't have to go and change it; I don't
> > > want to make more work for you.
> > 
> > Oh, I'm not too familiar with Tcl.  I haven't seen single quotes being
> > used elsewhere.  I prefer not to change it unless there is another
> > reason to rework all this.  So … let's wait?
> 
> Sure.

Note, I think \\\s are used in thousands of dg-error/dg-warning etc.
in other tests already, I think it isn't a big deal.
find testsuite -type f | xargs grep 'dg-\(warning\|error\|message\).*".*\\' 
| wc -l
4782
Sure, with using {} instead of "" one can get rid of some of the \s.

Jakub

Re: [PATCH] AArch64: Fix __sync_val_compare_and_swap [PR111404]

[Wilco Dijkstra]

Hi Richard,

Thanks for the review, now committed.

> The new aarch64_split_compare_and_swap code looks a bit twisty.
> The approach in lse.S seems more obvious.  But I'm guessing you
> didn't want to spend any time restructuring the pre-LSE
> -mno-outline-atomics code, and I agree the patch in its current
> form is more backportable.

Indeed this code needs cleaning up - all the complex speculation stuff
should be behind a simple interface. I was thinking of emitting CSEL
here but it would require adding new TI mode patterns or manually
splitting into low/high parts and emitting CSEL.

> I suppose we might want to backport this after it has been in trunk
> for a bit.

Yes that was my plan.

Cheers,
Wilco

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

[Jeff Law]

On 11/29/23 19:39, Joern Rennecke wrote:

On Wed, 29 Nov 2023 at 20:05, Joern Rennecke
  wrote:


I suspect it'd be more useful to add handling of LSHIFTRT and ASHIFTRT
.  Some ports do
a lot of static shifting.
+case SS_ASHIFT:
+case US_ASHIFT:
+  if (!mask || XEXP (x, 1) == const0_rtx)
+   return 0;

P.S.: I just realize that this is a pasto: in the case of a const0_rtx
shift count,
we returning 0 will usually be wrong.

I've attached my current patch version.


tmp.txt

 ext-dce.cc: handle vector modes.
 
 * ext-dce.cc: Amend comment to explain how liveness of vectors is tracked.

   (carry_backpropagate): Use GET_MODE_INNER.
   (ext_dce_process_sets): Likewise.  Only apply big endian correction for
   subregs if they don't have a vector mode.
   (ext_cde_process_uses): Likewise.

 * ext-dce.cc: carry_backpropagate: [US]S_ASHIFT fix, handle [LA]SHIFTRT
 
 * ext-dce.cc (safe_for_live_propagation): Add LSHIFTRT and ASHIFTRT.

   (carry_backpropagate): Reformat top comment.
   Add handling of LSHIFTRT and ASHIFTRT.
   Fix bit count for [SU]MUL_HIGHPART.
   Fix pasto for [SU]S_ASHIFT.

 * ext-dce.c: Fixes for carry handling.
 
 * ext-dce.c (safe_for_live_propagation): Handle MINUS.

   (ext_dce_process_uses): Break out carry handling into ..
   (carry_backpropagate): This new function.
   Better handling of ASHIFT.
   Add handling of SMUL_HIGHPART, UMUL_HIGHPART, SIGN_EXTEND, SS_ASHIFT and
   US_ASHIFT.

 * ext-dce.c: fix SUBREG_BYTE test
 
 As mentioned in

 https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637486.html
 and
 https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638473.html


diff --git a/gcc/ext-dce.cc b/gcc/ext-dce.cc
index 4e4c57de117..228c50e8b73 100644
--- a/gcc/ext-dce.cc
+++ b/gcc/ext-dce.cc
@@ -38,7 +38,10 @@ along with GCC; see the file COPYING3.  If not see
 bit 0..7   (least significant byte)
 bit 8..15  (second least significant byte)
 bit 16..31
-   bit 32..BITS_PER_WORD-1  */
+   bit 32..BITS_PER_WORD-1
+
+   For vector modes, we apply these bit groups to every lane; if any of the
+   bits in the group are live in any lane, we consider this group live.  */
Why add vector modes now?  I realize it might help a vectorized sub*_dct 
from x264, but I was thinking that would be more of a gcc-15 improvement.


Was this in fact to help sub*_dct or something else concrete?  Unless 
it's concrete and significant, I'd lean towards deferring the 
enhancement until gcc-15.


  
  /* Note this pass could be used to narrow memory loads too.  It's

 not clear if that's profitable or not in general.  */



@@ -96,6 +100,8 @@ safe_for_live_propagation (rtx_code code)
  case SS_ASHIFT:
  case US_ASHIFT:
  case ASHIFT:
+case LSHIFTRT:
+case ASHIFTRT:
return true;
So this starts to touch on a cleanup Richard mentioned.  The codes in 
there until now were supposed to be safe across the board.  As we add 
things like LSHIFTRT, we need to describe how to handle liveness 
transfer from the destination into the source(s).  I think what Richard 
is asking for is to just have one place which handles both.


Anyway, my current plan would be to pull in the formatting fixes, the 
back propagation without the vector enhancement.  We've already fixed 
the subreg thingie locally.



jeff

Re: [PATCH v3 04/11] Add tests for validating future C permerrors

[Marek Polacek]

On Thu, Nov 30, 2023 at 06:37:21PM +0100, Florian Weimer wrote:
> * Marek Polacek:
> 
> >> +void
> >> +implicit_function_declaration (void)
> >> +{
> >> +  f1 (); /* { dg-warning "'f1' \\\[-Wimplicit-function-declaration\\\]" } 
> >> */
> >> +}
> >> +
> >> +extern implicit_int_1; /* { dg-warning "'implicit_int_1' 
> >> \\\[-Wimplicit-int\\\]" } */
> >
> > Oy, these \ tend to get unwieldy.  You could probably just say
> > { dg-warning {-Wimplicit-int} }
> 
> I wanted to have some more context for the other files that might get
> the explict line number wrong.
> 
> >> +return incompatible_pointer_types; /* { dg-error "returning 'int \\\* 
> >> \\\(\\\*\\\)\\\(int\\\)' from a function with incompatible return type 
> >> 'int \\\*' \\\[-Wincompatible-pointer-types\\\]" } */
> >
> > And here maybe
> > { dg-error {returning 'int \* \(\*\)\(int\)' from a function with 
> > incompatible return type 'int \*' \[-Wincompatible-pointer-types\]} }
> > could work the same.  But you don't have to go and change it; I don't
> > want to make more work for you.
> 
> Oh, I'm not too familiar with Tcl.  I haven't seen single quotes being
> used elsewhere.  I prefer not to change it unless there is another
> reason to rework all this.  So … let's wait?

Sure.
 
> >> --- /dev/null
> >> +++ b/gcc/testsuite/gcc.dg/permerror-system.c
> >> @@ -0,0 +1,9 @@
> >> +/* { dg-options "-isystem ${srcdir}" } */
> >> +
> >> +/* Test that permerrors appear in system headers.  */
> >> +
> >> +/* The dg-* directives in the header file are ignored.  No warnings are
> >> +   expected.  */
> >> +#include 
> >
> > Why not just #include "permerror-default.c"?
> 
> I wanted to make sure that the file is found through the -isystem path.

Aha, okay then.

Marek

Re: [PATCH v3 04/11] Add tests for validating future C permerrors

[Florian Weimer]

* Marek Polacek:

>> +void
>> +implicit_function_declaration (void)
>> +{
>> +  f1 (); /* { dg-warning "'f1' \\\[-Wimplicit-function-declaration\\\]" } */
>> +}
>> +
>> +extern implicit_int_1; /* { dg-warning "'implicit_int_1' 
>> \\\[-Wimplicit-int\\\]" } */
>
> Oy, these \ tend to get unwieldy.  You could probably just say
> { dg-warning {-Wimplicit-int} }

I wanted to have some more context for the other files that might get
the explict line number wrong.

>> +return incompatible_pointer_types; /* { dg-error "returning 'int \\\* 
>> \\\(\\\*\\\)\\\(int\\\)' from a function with incompatible return type 'int 
>> \\\*' \\\[-Wincompatible-pointer-types\\\]" } */
>
> And here maybe
> { dg-error {returning 'int \* \(\*\)\(int\)' from a function with 
> incompatible return type 'int \*' \[-Wincompatible-pointer-types\]} }
> could work the same.  But you don't have to go and change it; I don't
> want to make more work for you.

Oh, I'm not too familiar with Tcl.  I haven't seen single quotes being
used elsewhere.  I prefer not to change it unless there is another
reason to rework all this.  So … let's wait?

>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/permerror-system.c
>> @@ -0,0 +1,9 @@
>> +/* { dg-options "-isystem ${srcdir}" } */
>> +
>> +/* Test that permerrors appear in system headers.  */
>> +
>> +/* The dg-* directives in the header file are ignored.  No warnings are
>> +   expected.  */
>> +#include 
>
> Why not just #include "permerror-default.c"?

I wanted to make sure that the file is found through the -isystem path.

Thanks,
Florian

Re: [RFA] New pass for sign/zero extension elimination

[Jeff Law]

On 11/28/23 06:36, Joern Rennecke wrote:

On Mon, 27 Nov 2023 at 20:18, Jeff Law  wrote:




On 11/27/23 13:03, Richard Sandiford wrote:

Joern Rennecke  writes:

   On 11/20/23 11:26, Richard Sandiford wrote:

+  /* ?!? What is the point of this adjustment to DST_MASK?  */
+  if (code == PLUS || code == MINUS
+  || code == MULT || code == ASHIFT)
+ dst_mask
+  = dst_mask ? ((2ULL << floor_log2 (dst_mask)) - 1) : 0;


Yeah, sympathise with the ?!? here :)

Jeff Law:

Inherited.  Like the other bit of magic I think I'll do a test with them
pulled out to see if I can make something undesirable trigger.


This represents the carry effect.  Even if the destination only cares about
some high order bits, you have to consider all lower order bits of the inputs.

For ASHIFT, you could refine this in the case of a constant shift count.


Ah, right.  Think it would be worth a comment.

Definitely.  Wouldn't SIGN_EXTEND have a similar problem?  While we
don't care about all the low bits, we do care about that MSB.


Yes, if bits outside of the MODE_MASK of the input (i.e. higher bits) are
life in the output, than we want the high bit of the SIGN_EXTEND input live.
So I had a hack in my tree to do this for a while, but it was early in 
the effort to test this across more targets.  It wasn't clear at that 
point in the effort if it was correct or just working around bugs 
elsewhere.  After we had everything working across the various targets I 
pulled it out without ill effects.  It looks like you're handling it in 
your carry_backpropagate changes.


Jeff

Re: [PATCH v3 04/11] Add tests for validating future C permerrors

[Marek Polacek]

On Mon, Nov 20, 2023 at 10:56:03AM +0100, Florian Weimer wrote:
> The dg-error directives for gcc.dg/permerror-system.c can be generated
> using (for the most part at least):
> 
> perl -ne 'print if s,.*(/\* \{ dg-error .*) } \*/$,$1 "" { target *-*-* } $. 
> } */,' \
>   < gcc/testsuite/gcc.dg/permerror-default.c
> 
> gcc/testsuite/
> 
>   * gcc.dg/permerror-default.c: New test.
>   * gcc.dg/permerror-fpermissive.c: Likewise.
>   * gcc.dg/permerror-fpermissive-nowarning.c: Likewise.
>   * gcc.dg/permerror-gnu89-nopermissive.c: Likewise.
>   No permerrors yet, so this matches gcc.dg/permerror-gnu89.c
>   for now.
>   * gcc.dg/permerror-gnu89-pedantic.c: New test.
>   * gcc.dg/permerror-gnu89.c: Likewise.
>   * gcc.dg/permerror-noerror.c: Likewise.
>   * gcc.dg/permerror-nowarning.c: Likewise.
>   * gcc.dg/permerror-pedantic.c: Likewise.
>   * gcc.dg/permerror-system.c: Likewise.
> ---
>  gcc/testsuite/gcc.dg/permerror-default.c  | 85 +++
>  .../gcc.dg/permerror-fpermissive-nowarning.c  | 11 +++
>  gcc/testsuite/gcc.dg/permerror-fpermissive.c  | 85 +++
>  .../gcc.dg/permerror-gnu89-nopermissive.c | 85 +++
>  .../gcc.dg/permerror-gnu89-pedantic.c | 85 +++
>  gcc/testsuite/gcc.dg/permerror-gnu89.c| 85 +++
>  gcc/testsuite/gcc.dg/permerror-noerror.c  | 85 +++
>  gcc/testsuite/gcc.dg/permerror-nowarning.c| 10 +++
>  gcc/testsuite/gcc.dg/permerror-pedantic.c | 85 +++
>  gcc/testsuite/gcc.dg/permerror-system.c   |  9 ++
>  10 files changed, 625 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.dg/permerror-default.c
>  create mode 100644 gcc/testsuite/gcc.dg/permerror-fpermissive-nowarning.c
>  create mode 100644 gcc/testsuite/gcc.dg/permerror-fpermissive.c
>  create mode 100644 gcc/testsuite/gcc.dg/permerror-gnu89-nopermissive.c
>  create mode 100644 gcc/testsuite/gcc.dg/permerror-gnu89-pedantic.c
>  create mode 100644 gcc/testsuite/gcc.dg/permerror-gnu89.c
>  create mode 100644 gcc/testsuite/gcc.dg/permerror-noerror.c
>  create mode 100644 gcc/testsuite/gcc.dg/permerror-nowarning.c
>  create mode 100644 gcc/testsuite/gcc.dg/permerror-pedantic.c
>  create mode 100644 gcc/testsuite/gcc.dg/permerror-system.c
> 
> diff --git a/gcc/testsuite/gcc.dg/permerror-default.c 
> b/gcc/testsuite/gcc.dg/permerror-default.c
> new file mode 100644
> index 000..ea0be1dc89f
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/permerror-default.c
> @@ -0,0 +1,85 @@
> +/* { dg-options "" } */
> +
> +/* Overview test for C permerrors.  This test should be kept in sync with the
> +   other permerror-* tests.  If new permerrors are added, test cases should 
> be
> +   added to this and the other files.  */
> +
> +void
> +implicit_function_declaration (void)
> +{
> +  f1 (); /* { dg-warning "'f1' \\\[-Wimplicit-function-declaration\\\]" } */
> +}
> +
> +extern implicit_int_1; /* { dg-warning "'implicit_int_1' 
> \\\[-Wimplicit-int\\\]" } */

Oy, these \ tend to get unwieldy.  You could probably just say
{ dg-warning {-Wimplicit-int} }

> +return incompatible_pointer_types; /* { dg-error "returning 'int \\\* 
> \\\(\\\*\\\)\\\(int\\\)' from a function with incompatible return type 'int 
> \\\*' \\\[-Wincompatible-pointer-types\\\]" } */

And here maybe
{ dg-error {returning 'int \* \(\*\)\(int\)' from a function with incompatible 
return type 'int \*' \[-Wincompatible-pointer-types\]} }
could work the same.  But you don't have to go and change it; I don't
want to make more work for you.

> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/permerror-system.c
> @@ -0,0 +1,9 @@
> +/* { dg-options "-isystem ${srcdir}" } */
> +
> +/* Test that permerrors appear in system headers.  */
> +
> +/* The dg-* directives in the header file are ignored.  No warnings are
> +   expected.  */
> +#include 

Why not just #include "permerror-default.c"?

I think this patch is OK.

Marek

Re: Ping: [PATCH] Fix PR112419

[Hans-Peter Nilsson]

> From: Martin Uecker 
> Cc: richard.guent...@gmail.com

> Am Montag, dem 27.11.2023 um 08:36 -0700 schrieb Jeff Law:
> > 
> > On 11/23/23 10:05, Hans-Peter Nilsson wrote:
> > > > From: Hans-Peter Nilsson 
> > > > Date: Thu, 16 Nov 2023 05:24:06 +0100
> > > > 
> > > > > From: Martin Uecker 
> > > > > Date: Tue, 07 Nov 2023 06:56:25 +0100
> > > > 
> > > > > Am Montag, dem 06.11.2023 um 21:01 -0700 schrieb Jeff Law:
> > > > > > 
> > > > > > On 11/6/23 20:58, Hans-Peter Nilsson wrote:
> > > > > > > This patch caused a testsuite regression: there's now an
> > > > > > > "excess error" failure for gcc.dg/Wnonnull-4.c for 32-bit
> > > > > > > targets (and 64-bit targets testing with a "-m32" option)
> > > > > > > after your r14-5115-g6e9ee44d96e5.  It's logged as PR112419.
> > > > > > It caused failures for just about every target ;(  Presumably it 
> > > > > > worked
> > > > > > on x86_64...
> > > > > 
> > > > > I do not think this is a true regression
> > > > > just a problem with the test on 32-bit which somehow surfaced
> > > > > due to the change.
> > > > > 
> > > > > The excess error is:
> > > > > 
> > > > > FAIL: gcc.dg/Wnonnull-4.c (test for excess errors)
> > > > > Excess errors:
> > > > > /home/tcwg-buildslave/workspace/tcwg_gnu_6/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.dg/Wnonnull-4.c:144:3:
> > > > >  warning: 'fda_n_5' specified size 4294967256 exceeds maximum object 
> > > > > size
> > > > > 2147483647 [-Wstringop-overflow=]
> > > > > 
> > > > > I think the warning was suppressed before due to the other (nonnull)
> > > > > warning which I removed in this case.
> > > > > 
> > > > > I think the simple fix might be to to turn off -Wstringop-overflow.
> > > > 
> > > > No, that trigs many of the dg-warnings that are tested.
> > > > 
> > > > (I didn't pay attention to the actual warning messages and
> > > > tried to pursue that at first.)
> > > > 
> > > > Maybe think it's best to actually expect the warning, like
> > > > so.
> > > > 
> > > > Maintainers of 16-bit targets will have to address their
> > > > concerns separately.  For example, they may choose to not
> > > > run the test at all.
> > > > 
> > > > Ok to commit?
> > > > 
> > > > Subject: [PATCH] gcc.dg/Wnonnull-4.c: Handle new overflow warning for 
> > > > 32-bit targets [PR112419]
> > > > 
> > > > PR testsuite/112419
> > > > * gcc.dg/Wnonnull-4.c (test_fda_n_5): Expect warning for 
> > > > exceeding
> > > > maximum object size for 32-bit targets.
> > > > ---
> > > >   gcc/testsuite/gcc.dg/Wnonnull-4.c | 1 +
> > > >   1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/gcc/testsuite/gcc.dg/Wnonnull-4.c 
> > > > b/gcc/testsuite/gcc.dg/Wnonnull-4.c
> > > > index 1f14fbba45df..d63e76da70a2 100644
> > > > --- a/gcc/testsuite/gcc.dg/Wnonnull-4.c
> > > > +++ b/gcc/testsuite/gcc.dg/Wnonnull-4.c
> > > > @@ -142,6 +142,7 @@ void test_fda_n_5 (int r_m1)
> > > > T (  1);  // { dg-bogus "argument 2 of variable length 
> > > > array 'double\\\[n]\\\[5]' is null but the corresponding bound argument 
> > > > 1 value is 1" }
> > > > T (  9);  // { dg-bogus "argument 2 of variable length 
> > > > array 'double\\\[n]\\\[5]' is null but the corresponding bound argument 
> > > > 1 value is 9" }
> > > > T (max);  // { dg-bogus "argument 2 of variable length 
> > > > array 'double\\\[n]\\\[5]' is null but the corresponding bound argument 
> > > > 1 value is \\d+" }
> > > > +// { dg-warning "size 4294967256 exceeds maximum object size" "" { 
> > > > target ilp32 } .-1 }
> > > >   }
> > Unfortunately I think we need to go back to the original issue that 
> > Martin (I think) dismissed.
> > 
> > Specifically, this is a regression.  It's very clear that prior to the 
> > patch in question there was no diagnostic about the size of the 
> > requested memory allocation and after the patch in question we get the 
> > "exceeds maximum object size" diagnostic.
> > 
> > Now one explanation could be that the diagnostic is warranted and it was 
> > a bug that the diagnostic hadn't been emitted prior to Martin's patch. 
> > In this case some kind of dg-blah is warranted, but I don't think anyone 
> > has made this argument.
> > 
> I believe the warning is correct but was suppressed before.
> 
> 
> My plan was to split up the test case in one which is for
> -Wstringop-overflow and one which is for -Wnonnull and then
> one could turn off the -Wstringop-overflow for the tests
> which are actually for -Wnonnull.  But adding the dg-blah
> would certainly be simpler.

Sort-of-mid-week ping (only because status quo isn't clear):
Jeff, are you content with Martin U:s reply (i.e. patch ok)
or are you waiting for a follow-up?

Perhaps it's already in your overflowing queue, then please
ignore this, I'll just ping in a week. ;-)

IMHO, after looking at the test-case I'd expect *more*
warnings for ilp32 targets; i.e. it was a bug that it didn't
show up before.

brgds, H-P

Re: [PATCH] testsuite: scev: expect fail on ilp32

[Hans-Peter Nilsson]

> From: Alexandre Oliva 
> Date: Thu, 30 Nov 2023 01:41:55 -0300

> On Nov 29, 2023, Hans-Peter Nilsson  wrote:
> 
> >> XPASS: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times ivopts "" 1
> >> XPASS: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "" 1
> >> XPASS: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts "" 1
> 
> > It XPASSes on the ilp32 targets I've tried - except "ia32"
> > (as in i686-elf) and h8300-elf.  Notably XPASSing targets
> > includes a *default* configuration of arm-eabi, which in
> > part contradicts your observation above.
> 
> My arm-eabi testing then targeted tms570 (big-endian cortex-r5).
> 
> I borrowed the ilp32 vs lp64 line from an internal patch by Eric that
> we've had in gcc-11 and gcc-12, when I hit this fail while transitioning
> the first and then the second of our 32-bit targets to gcc-13.

'k, I interpret that as that ilp32 being mostly a copy-paste
of unclear origin, and that there weren't actually any
observation of more than two ilp32 targets failing (counting
ia32 and one or more non-default armeb).

> > So, ilp32 is IMO a really bad approximation for the elusive
> > property.
> 
> Yeah.  Maybe we should just drop the ilp32, so that it's an unsurprising
> fail on any targets?
> 
> > Would you please consider changing those "ilp32" to a
> > specific set of targets where these tests failed?
> 
> I'd normally have aimed for that, but the challenge is that arm-eabi is
> not uniform in the results for this test, and there doesn't seem to be
> much support or knowledge to delineate on which target variants it's
> meant to pass or not.

That situation suggests to me to *skip* it for arm*-*-*.
For other targets, skip or xfail as needed after a quick
look.  Or as per below.

>  The test expects the transformation to take
> place, as if it ought to, but there's no strong reason to expect that it
> should.  There's nothing wrong if it doesn't.  Going about trying to
> match the expectations to the current results may be useful, but
> investigating the reasons why we get the current results for each target
> is beyond my available resources for a set of tests that used to *seem*
> to pass uniformly only because of a bug in the test pattern.
> 
> I don't see much value in these tests as they are, TBH.

Richard B. seems to have been the last person doing
significant work on those tests (rewriting scev-[3-5].c to
gimple tests for ivopts, commit r7-6026-ga23e48df4514c4), so
I value his suggestion per below particularly valuable:

> > In the end we might need to move/duplicate the test to some
> > gcc.target/* dir and restrict it to a specific tuning.

I intend to post two alternative patches to get this
resolved:
1: Move the tests to gcc.target/i386/scev-[3-5].c
2: gcc.dg/tree-ssa/scev-[3-5].c skipped for arm*, xfailed
   only on h8300-*-* and ia32.

If you can help with e.g. reviewing, thanks in advance.

I opened PR112786 to get an ID for the issue.

brgds, H-P

Re: [PATCH v2] c++: wrong ambiguity in accessing static field [PR112744]

[Jason Merrill]

On 11/29/23 17:01, Marek Polacek wrote:

On Wed, Nov 29, 2023 at 03:28:44PM -0500, Jason Merrill wrote:

On 11/29/23 12:43, Marek Polacek wrote:

On Wed, Nov 29, 2023 at 12:23:46PM -0500, Patrick Palka wrote:

On Wed, 29 Nov 2023, Marek Polacek wrote:


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

Now that I'm posting this patch, I think you'll probably want me to use
ba_any unconditionally.  That works too; g++.dg/tc1/dr52.C just needs
a trivial testsuite tweak:
'C' is not an accessible base of 'X'
v.
'C' is an inaccessible base of 'X'
We should probably unify those messages...

-- >8 --
Given

struct A { constexpr static int a = 0; };
struct B : A {};
struct C : A {};
struct D : B, C {};

we give the "'A' is an ambiguous base of 'D'" error for

D{}.A::a;

which seems wrong: 'a' is a static data member so there is only one copy
so it can be unambiguously referred to even if there are multiple A
objects.  clang++/MSVC/icx agree.

PR c++/112744

gcc/cp/ChangeLog:

* typeck.cc (finish_class_member_access_expr): When accessing
a static data member, use ba_any for lookup_base.

gcc/testsuite/ChangeLog:

* g++.dg/lookup/scoped11.C: New test.
* g++.dg/lookup/scoped12.C: New test.
* g++.dg/lookup/scoped13.C: New test.
---
   gcc/cp/typeck.cc   | 21 ++---
   gcc/testsuite/g++.dg/lookup/scoped11.C | 14 ++
   gcc/testsuite/g++.dg/lookup/scoped12.C | 14 ++
   gcc/testsuite/g++.dg/lookup/scoped13.C | 14 ++
   4 files changed, 60 insertions(+), 3 deletions(-)
   create mode 100644 gcc/testsuite/g++.dg/lookup/scoped11.C
   create mode 100644 gcc/testsuite/g++.dg/lookup/scoped12.C
   create mode 100644 gcc/testsuite/g++.dg/lookup/scoped13.C

diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index e995fb6ddd7..c4de8bb2616 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -3476,7 +3476,7 @@ finish_class_member_access_expr (cp_expr object, tree 
name, bool template_p,
   name, scope);
  return error_mark_node;
}
-   
+
  if (TREE_SIDE_EFFECTS (object))
val = build2 (COMPOUND_EXPR, TREE_TYPE (val), object, val);
  return val;
@@ -3493,9 +3493,24 @@ finish_class_member_access_expr (cp_expr object, tree 
name, bool template_p,
  return error_mark_node;
}
+ /* NAME may refer to a static data member, in which case there is
+one copy of the data member that is shared by all the objects of
+the class.  So NAME can be unambiguously referred to even if
+there are multiple indirect base classes containing NAME.  */
+ const base_access ba = [scope, name] ()
+   {
+ if (identifier_p (name))
+   {
+ tree m = lookup_member (scope, name, /*protect=*/0,
+ /*want_type=*/false, tf_none);
+ if (!m || VAR_P (m))
+   return ba_any;


I wonder if we want to return ba_check_bit instead of ba_any so that we
still check access of the selected base?


That would certainly make sense to me.  I didn't do that because
I'd not seen ba_check_bit being used except as part of ba_check,
but that may not mean much.

So either I can tweak the lambda to return ba_check_bit rather
than ba_any or use ba_check_bit unconditionally.  Any opinions on that?


The relevant passage seems to be
https://eel.is/c++draft/class.access.base#6
after DR 52, which seems to have clarified that the pointer conversion only
applies to non-static members.


struct A { constexpr static int a = 0; };
struct D : private A {};

void f() {
  D{}.A::a; // #1 GCC (and Clang) currently rejects
}


I see that MSVC also rejects it, while EDG accepts.

https://eel.is/c++draft/class.access.base#5.1 seems to say that a is
accessible when named in A.

https://eel.is/c++draft/expr.ref#7 also only constrains references to
non-static members.

But first we need to look up A in D, and A's injected-class-name looked up
as a member of D is not accessible; it's private, and f() is not a friend,
and we correctly complain about that.

If we avoid the lookup of A in D with

D{}.::A::a;

clang accepts it, which is consistent with accepting the template version,
and seems correct.

So, I think ba_any is what we want here.


Wow, that is not intuitive (to me at least).  So I had it right but
only by accident.

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

-- >8 --
Given

   struct A { constexpr static int a = 0; };
   struct B : A {};
   struct C : A {};
   struct D : B, C {};

we give the "'A' is an ambiguous base of 'D'" error for

   D{}.A::a;

which seems wrong: 'a' is a static data member so there is only one copy
so it can be unambiguously referred to even if there are multiple A
objects.  clang++/MSVC/icx 

Re: [PATCH] s390: Fix builtin-classify-type-1.c on s390 too [PR112725]

[Jakub Jelinek]

On Wed, Nov 29, 2023 at 07:27:20PM +0100, Jakub Jelinek wrote:
> Given that the s390 backend defines pretty much the same target hook
> as rs6000, I believe it suffers (at least when using -mvx?) the same
> problem as rs6000, though admittedly this is so far completely
> untested.
> 
> Ok for trunk if it passes bootstrap/regtest there?

Now successfully bootstrapped/regtested on s390x-linux and indeed it
fixes
-FAIL: c-c++-common/builtin-classify-type-1.c  -Wc++-compat  (test for excess 
errors)
-UNRESOLVED: c-c++-common/builtin-classify-type-1.c  -Wc++-compat  compilation 
failed to produce executable
there as well.

> 2023-11-29  Jakub Jelinek  
> 
>   PR target/112725
>   * config/s390/s390.cc (s390_invalid_arg_for_unprototyped_fn): Return
>   NULL for __builtin_classify_type calls with vector arguments.
> 
> --- gcc/config/s390/s390.cc.jj2023-11-27 17:34:25.684287136 +0100
> +++ gcc/config/s390/s390.cc   2023-11-29 09:41:08.569491077 +0100
> @@ -12650,7 +12650,8 @@ s390_invalid_arg_for_unprototyped_fn (co
>  && VECTOR_TYPE_P (TREE_TYPE (val))
>  && (funcdecl == NULL_TREE
>  || (TREE_CODE (funcdecl) == FUNCTION_DECL
> -&& DECL_BUILT_IN_CLASS (funcdecl) != BUILT_IN_MD)))
> +&& DECL_BUILT_IN_CLASS (funcdecl) != BUILT_IN_MD
> +&& !fndecl_built_in_p (funcdecl, BUILT_IN_CLASSIFY_TYPE
> ? N_("vector argument passed to unprototyped function")
> : NULL);
>  }

Jakub

[PATCH] gcov: Fix __LIBGCC_HAVE_LIBATOMIC definition

[Sebastian Huber]

In libgcov we use defined (__LIBGCC_HAVE_LIBATOMIC), so we must define it only
if needed (vs. #if __LIBGCC_HAVE_LIBATOMIC).

gcc/c-family/ChangeLog:

PR target/112777

* c-cppbuiltin.cc (c_cpp_builtins):  Define __LIBGCC_HAVE_LIBATOMIC
only if targetm.have_libatomic is true.
---
 gcc/c-family/c-cppbuiltin.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/c-family/c-cppbuiltin.cc b/gcc/c-family/c-cppbuiltin.cc
index e536429fa4c..f8ec6f1747c 100644
--- a/gcc/c-family/c-cppbuiltin.cc
+++ b/gcc/c-family/c-cppbuiltin.cc
@@ -1570,8 +1570,8 @@ c_cpp_builtins (cpp_reader *pfile)
   /* For libgcov.  */
   builtin_define_with_int_value ("__LIBGCC_VTABLE_USES_DESCRIPTORS__",
 TARGET_VTABLE_USES_DESCRIPTORS);
-  builtin_define_with_int_value ("__LIBGCC_HAVE_LIBATOMIC",
-targetm.have_libatomic);
+  if (targetm.have_libatomic)
+   cpp_define (pfile, "__LIBGCC_HAVE_LIBATOMIC");
 }
 
   /* For use in assembly language.  */
-- 
2.35.3

Re: [PATCH v3 09/11] c: Turn -Wreturn-mismatch into a permerror

[Marek Polacek]

On Thu, Nov 23, 2023 at 07:22:58PM +0100, Florian Weimer wrote:
> * Marek Polacek:
> 
> > On Mon, Nov 20, 2023 at 10:56:30AM +0100, Florian Weimer wrote:
> >> gcc/
> >> 
> >>* doc/invoke.texi (Warning Options): Document changes.
> >
> > That's pretty vague :).  How about "Document that -Wreturn-mismatch is a
> > permerror in C99."?
> 
> Applied (with “in C99 and later”).
> 
> >>* gcc.target/powerpc/conditional-return.c: Compile with
> >>-fpermissive due to expected-Wreturn-mismatch error.
> >
> > There seem to be some extra whitespaces after "expected".
> 
> Fixed.
> 
> >> @@ -7375,7 +7376,10 @@ Attempting to use the return value of a 
> >> non-@code{void} function other
> >>  than @code{main} that flows off the end by reaching the closing curly
> >>  brace that terminates the function is undefined.
> >>  
> >> -This warning is specific to C and enabled by default.
> >> +This warning is specific to C and enabled by default.  In C99 and later
> >> +language dialects, it is treated as an error.  It an be downgraded
> >
> > an -> can
> 
> Fixed.
> 
> >> diff --git a/gcc/testsuite/gcc.target/powerpc/conditional-return.c 
> >> b/gcc/testsuite/gcc.target/powerpc/conditional-return.c
> >> index 6b3ef5f52ca..c6491216752 100644
> >> --- a/gcc/testsuite/gcc.target/powerpc/conditional-return.c
> >> +++ b/gcc/testsuite/gcc.target/powerpc/conditional-return.c
> >> @@ -1,7 +1,7 @@
> >>  /* Check that a conditional return is used.  */
> >>  
> >>  /* { dg-do compile } */
> >> -/* { dg-options "-O2 -w" } */
> >> +/* { dg-options "-O2 -fpermissive -w" } */
> >>  
> >>  /* { dg-final { scan-assembler {\mbeqlr\M} } } */
> >>  
> >
> > These seem fine.
> >
> > Should we have a test for -Wno-error=return-mismatch and 
> > -Wno-return-mismatch?
> > I didn't see those.
> 
> See gcc/testsuite/gcc.dg/permerror-noerror.c and
> gcc/testsuite/gcc.dg/permerror-nowarning.c.  They don't show up in the
> patch because the diagnostics don't change.

Ah, I see that now.  This patch is OK then.  Thanks.

Marek

HELP: one issue during the implementation for counted_by attribute

[Qing Zhao]

Hi, 

1. For the following source code (portion):

struct annotated {
  size_t foo;
  char b;
  char array[] __attribute__((counted_by (foo)));
};

static void noinline bar ()
{
  struct annotated *p2 = alloc_buf (10);
  p2->array[8] = 0;
  return;
}

2. I modified C FE to generate the following code for the routine “bar”:

;; Function bar (null)
;; enabled by -tree-original
{
  struct annotated * p2 = alloc_buf (10);

struct annotated * p2 = alloc_buf (10);
  .ACCESS_WITH_SIZE ((char *) >array, >foo, 1, 8, -1)[8] = 0;
  return;
}

The gimpliflication asserted at:/home/opc/Install/latest-d/bin/gcc -O2 
-fdump-tree-all ttt_1.c
ttt_1.c: In function ‘bar’:
ttt_1.c:29:5: internal compiler error: in create_tmp_var, at gimple-expr.cc:488
   29 |   p2->array[8] = 0;
  |   ~~^~~

3. The reason for this assertion failure is:  (in gcc/gimplify.cc)

16686 case CALL_EXPR:
16687   ret = gimplify_call_expr (expr_p, pre_p, fallback != fb_none);
16688 
16689   /* C99 code may assign to an array in a structure returned
16690  from a function, and this has undefined behavior only on
16691  execution, so create a temporary if an lvalue is
16692  required.  */
16693   if (fallback == fb_lvalue)
16694 {
16695   *expr_p = get_initialized_tmp_var (*expr_p, pre_p, post_p, 
false);
16696   mark_addressable (*expr_p);
16697   ret = GS_OK;
16698 }
16699   break;

At Line 16695, when gimplifier tried to create a temporary value for the 
.ACCESS_WITH_SIZE function as:
   tmp = .ACCESS_WITH_SIZE ((char *) >array, >foo, 1, 8, -1);

It asserted since the TYPE of the function .ACCESS_WITH_SIZE is an 
INCOMPLETE_TYPE (it’s the TYPE of p2->array, which is an incomplete type).

4. I am stuck on how to resolve this issue properly:
The first question is:

Where should  we generate
  tmp = .ACCESS_WITH_SIZE ((char *) >array, >foo, 1, 8, -1)

In C FE or in middle-end gimplification? 

Thanks a lot for your help.

Qing

Re: [PATCH] libstdc++: Implement LGW 4016 for std::ranges::to

[Jonathan Wakely]

Before pushing I'll fix the summary to say "LWG" instead of "LGW" (the
airport code for London Gatwick!)

On Thu, 30 Nov 2023 at 15:51, Jonathan Wakely wrote:
>
> This hasn't been finally approved by LWG yet, but everybody seems to be
> in favour of it. I think I'll push this soon.
>
> Tested x86_64-linux.
>
> -- >8 --
>
> This implements the proposed resolution of LWG 4016, so that
> std::ranges::to does not use std::back_inserter and std::inserter.
> Instead it inserts at the back of the container directly, using
> the first supported one of emplace_back, push_back, emplace, and insert.
>
> Using emplace avoids creating a temporary that has to be moved into the
> container, for cases where the source range and the destination
> container do not have the same value type.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (__detail::__container_insertable): Remove.
> (__detail::__container_inserter): Remove.
> (ranges::to): Use emplace_back or emplace, as per LWG 4016.
> * testsuite/std/ranges/conv/1.cc (Cont4, test_2_1_4): Check for
> use of emplace_back and emplace.
> ---
>  libstdc++-v3/include/std/ranges |  50 +++
>  libstdc++-v3/testsuite/std/ranges/conv/1.cc | 149 
>  2 files changed, 144 insertions(+), 55 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index 9d4c2e01c4d..afd0a38e0cf 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -9229,26 +9229,6 @@ namespace __detail
> { __c.max_size() } -> same_as;
>};
>
> -  template
> -constexpr bool __container_insertable
> -  = requires(_Container& __c, _Ref&& __ref) {
> -   typename _Container::value_type;
> -   requires (
> - requires { __c.push_back(std::forward<_Ref>(__ref)); }
> - || requires { __c.insert(__c.end(), std::forward<_Ref>(__ref)); }
> -   );
> -  };
> -
> -  template
> -constexpr auto
> -__container_inserter(_Container& __c)
> -{
> -  if constexpr (requires { __c.push_back(std::declval<_Ref>()); })
> -   return std::back_inserter(__c);
> -  else
> -   return std::inserter(__c, __c.end());
> -}
> -
>template
>  constexpr bool __toable = requires {
>requires (!input_range<_Cont>
> @@ -9301,17 +9281,33 @@ namespace __detail
>  std::forward<_Args>(__args)...);
>   else
> {
> - using __detail::__container_insertable;
> - using __detail::__reservable_container;
>   using _RefT = range_reference_t<_Rg>;
>   static_assert(constructible_from<_Cont, _Args...>);
> - static_assert(__container_insertable<_Cont, _RefT>);
>   _Cont __c(std::forward<_Args>(__args)...);
> - if constexpr (sized_range<_Rg> && __reservable_container<_Cont>)
> + if constexpr (sized_range<_Rg>
> + && __detail::__reservable_container<_Cont>)
> 
> __c.reserve(static_cast>(ranges::size(__r)));
> - auto __ins = __detail::__container_inserter<_RefT>(__c);
> - for (auto&& __e : __r)
> -   *__ins++ = std::forward(__e);
> + // _GLIBCXX_RESOLVE_LIB_DEFECTS
> + // 4016. container-insertable checks do not match what
> + // container-inserter does
> + auto __it = ranges::begin(__r);
> + const auto __sent = ranges::end(__r);
> + while (__it != __sent)
> +   {
> + if constexpr (requires { __c.emplace_back(*__it); })
> +   __c.emplace_back(*__it);
> + else if constexpr (requires { __c.push_back(*__it); })
> +   __c.push_back(*__it);
> + else
> +   {
> + auto __end = __c.end();
> + if constexpr (requires { __c.emplace(__end, *__it); })
> +   __end = __c.emplace(__end, *__it);
> + else
> +   __end = __c.insert(__end, *__it);
> +   }
> + ++__it;
> +   }
>   return __c;
> }
> }
> diff --git a/libstdc++-v3/testsuite/std/ranges/conv/1.cc 
> b/libstdc++-v3/testsuite/std/ranges/conv/1.cc
> index 4b6814b1add..b5f861dedb3 100644
> --- a/libstdc++-v3/testsuite/std/ranges/conv/1.cc
> +++ b/libstdc++-v3/testsuite/std/ranges/conv/1.cc
> @@ -203,33 +203,51 @@ test_2_1_3()
>VERIFY( c2.c.get_allocator() == Alloc(78) );
>  }
>
> -template
> +enum AppendKind { None, EmplaceBack, PushBack, Emplace, Insert };
> +
> +template
>  struct Cont4
>  {
> -  using value_type = typename C::value_type;
> -
>// Only support construction with no args or an allocator.
> -  // This forces the use of either push_back or insert to fill the container.
> +  // This forces the use of either 

[PATCH] libstdc++: Add workaround to std::ranges::subrange [PR111948]

[Jonathan Wakely]

I think I'll push this to work around the compiler bug. We can revert it
later if the front end gets fixed.

Tested x86_64-linux. Needed on trunk and gcc-13.

-- >8 --

libstdc++-v3/ChangeLog:

PR libstdc++/111948
* include/bits/ranges_util.h (subrange): Add constructor to
_Size to aoid setting member in constructor.
* testsuite/std/ranges/subrange/111948.cc: New test.
---
 libstdc++-v3/include/bits/ranges_util.h   | 21 ---
 .../testsuite/std/ranges/subrange/111948.cc   |  8 +++
 2 files changed, 21 insertions(+), 8 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/std/ranges/subrange/111948.cc

diff --git a/libstdc++-v3/include/bits/ranges_util.h 
b/libstdc++-v3/include/bits/ranges_util.h
index ab6c69c57d0..185e46ec7a9 100644
--- a/libstdc++-v3/include/bits/ranges_util.h
+++ b/libstdc++-v3/include/bits/ranges_util.h
@@ -267,13 +267,21 @@ namespace ranges
   using __size_type
= __detail::__make_unsigned_like_t>;
 
-  template
+  template
struct _Size
-   { };
+   {
+ [[__gnu__::__always_inline__]]
+ constexpr _Size(_Tp = {}) { }
+   };
 
   template
struct _Size<_Tp, true>
-   { _Tp _M_size; };
+   {
+ [[__gnu__::__always_inline__]]
+ constexpr _Size(_Tp __s = {}) : _M_size(__s) { }
+
+ _Tp _M_size;
+   };
 
   [[no_unique_address]] _Size<__size_type> _M_size = {};
 
@@ -294,11 +302,8 @@ namespace ranges
   noexcept(is_nothrow_constructible_v<_It, decltype(__i)>
   && is_nothrow_constructible_v<_Sent, _Sent&>)
requires (_Kind == subrange_kind::sized)
-  : _M_begin(std::move(__i)), _M_end(__s)
-  {
-   if constexpr (_S_store_size)
- _M_size._M_size = __n;
-  }
+  : _M_begin(std::move(__i)), _M_end(__s), _M_size(__n)
+  { }
 
   template<__detail::__different_from _Rng>
requires borrowed_range<_Rng>
diff --git a/libstdc++-v3/testsuite/std/ranges/subrange/111948.cc 
b/libstdc++-v3/testsuite/std/ranges/subrange/111948.cc
new file mode 100644
index 000..dcc64b56def
--- /dev/null
+++ b/libstdc++-v3/testsuite/std/ranges/subrange/111948.cc
@@ -0,0 +1,8 @@
+// { dg-do compile { target c++20 } }
+
+#include 
+
+// Bug libstdc++/111948 - subrange modifies a const size object
+
+constexpr auto r = std::ranges::subrange(std::views::iota(0), 5);
+static_assert(std::ranges::distance(r));
-- 
2.43.0

[PATCH] libstdc++: Implement LGW 4016 for std::ranges::to

[Jonathan Wakely]

This hasn't been finally approved by LWG yet, but everybody seems to be
in favour of it. I think I'll push this soon.

Tested x86_64-linux.

-- >8 --

This implements the proposed resolution of LWG 4016, so that
std::ranges::to does not use std::back_inserter and std::inserter.
Instead it inserts at the back of the container directly, using
the first supported one of emplace_back, push_back, emplace, and insert.

Using emplace avoids creating a temporary that has to be moved into the
container, for cases where the source range and the destination
container do not have the same value type.

libstdc++-v3/ChangeLog:

* include/std/ranges (__detail::__container_insertable): Remove.
(__detail::__container_inserter): Remove.
(ranges::to): Use emplace_back or emplace, as per LWG 4016.
* testsuite/std/ranges/conv/1.cc (Cont4, test_2_1_4): Check for
use of emplace_back and emplace.
---
 libstdc++-v3/include/std/ranges |  50 +++
 libstdc++-v3/testsuite/std/ranges/conv/1.cc | 149 
 2 files changed, 144 insertions(+), 55 deletions(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 9d4c2e01c4d..afd0a38e0cf 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -9229,26 +9229,6 @@ namespace __detail
{ __c.max_size() } -> same_as;
   };
 
-  template
-constexpr bool __container_insertable
-  = requires(_Container& __c, _Ref&& __ref) {
-   typename _Container::value_type;
-   requires (
- requires { __c.push_back(std::forward<_Ref>(__ref)); }
- || requires { __c.insert(__c.end(), std::forward<_Ref>(__ref)); }
-   );
-  };
-
-  template
-constexpr auto
-__container_inserter(_Container& __c)
-{
-  if constexpr (requires { __c.push_back(std::declval<_Ref>()); })
-   return std::back_inserter(__c);
-  else
-   return std::inserter(__c, __c.end());
-}
-
   template
 constexpr bool __toable = requires {
   requires (!input_range<_Cont>
@@ -9301,17 +9281,33 @@ namespace __detail
 std::forward<_Args>(__args)...);
  else
{
- using __detail::__container_insertable;
- using __detail::__reservable_container;
  using _RefT = range_reference_t<_Rg>;
  static_assert(constructible_from<_Cont, _Args...>);
- static_assert(__container_insertable<_Cont, _RefT>);
  _Cont __c(std::forward<_Args>(__args)...);
- if constexpr (sized_range<_Rg> && __reservable_container<_Cont>)
+ if constexpr (sized_range<_Rg>
+ && __detail::__reservable_container<_Cont>)

__c.reserve(static_cast>(ranges::size(__r)));
- auto __ins = __detail::__container_inserter<_RefT>(__c);
- for (auto&& __e : __r)
-   *__ins++ = std::forward(__e);
+ // _GLIBCXX_RESOLVE_LIB_DEFECTS
+ // 4016. container-insertable checks do not match what
+ // container-inserter does
+ auto __it = ranges::begin(__r);
+ const auto __sent = ranges::end(__r);
+ while (__it != __sent)
+   {
+ if constexpr (requires { __c.emplace_back(*__it); })
+   __c.emplace_back(*__it);
+ else if constexpr (requires { __c.push_back(*__it); })
+   __c.push_back(*__it);
+ else
+   {
+ auto __end = __c.end();
+ if constexpr (requires { __c.emplace(__end, *__it); })
+   __end = __c.emplace(__end, *__it);
+ else
+   __end = __c.insert(__end, *__it);
+   }
+ ++__it;
+   }
  return __c;
}
}
diff --git a/libstdc++-v3/testsuite/std/ranges/conv/1.cc 
b/libstdc++-v3/testsuite/std/ranges/conv/1.cc
index 4b6814b1add..b5f861dedb3 100644
--- a/libstdc++-v3/testsuite/std/ranges/conv/1.cc
+++ b/libstdc++-v3/testsuite/std/ranges/conv/1.cc
@@ -203,33 +203,51 @@ test_2_1_3()
   VERIFY( c2.c.get_allocator() == Alloc(78) );
 }
 
-template
+enum AppendKind { None, EmplaceBack, PushBack, Emplace, Insert };
+
+template
 struct Cont4
 {
-  using value_type = typename C::value_type;
-
   // Only support construction with no args or an allocator.
-  // This forces the use of either push_back or insert to fill the container.
+  // This forces the use of either emplace_back, push_back, emplace or insert.
   Cont4() { }
   Cont4(typename C::allocator_type a) : c(a) { }
 
-  // Satisfying container-insertable requires either this ...
   template
-requires UsePushBack
+requires (Kind <= EmplaceBack)
+&& requires(C& c, T&& t) { c.emplace_back(std::forward(t)); }
+void
+emplace_back(T&& t)
+{
+  kind = EmplaceBack;
+  

Re: [committed v2] libstdc++: Define std::ranges::to for C++23 (P1206R7) [PR111055]

[Jonathan Wakely]

On Wed, 29 Nov 2023 at 16:28, Patrick Palka wrote:
>
> On Thu, 23 Nov 2023, Jonathan Wakely wrote:
>
> > Here's the finished version of the std::ranges::to patch, which I've
> > pushed to trunk.
> >
> > Tested x86_64-linux.
> >
> > -- >8 --
> >
> > This adds the std::ranges::to functions for C++23. The rest of P1206R7
> > is not yet implemented, i.e. the new constructors taking the
> > std::from_range tag, and the new insert_range, assign_range, etc. member
> > functions. std::ranges::to works with the standard containers even
> > without the new constructors, so this is useful immediately.
> >
> > The __cpp_lib_ranges_to_container feature test macro can be defined now,
> > because that only indicates support for the changes in , which
> > are implemented by this patch. The __cpp_lib_containers_ranges macro
> > will be defined once all containers support the new member functions.
> >
> > libstdc++-v3/ChangeLog:
> >
> >   PR libstdc++/111055
> >   * include/bits/ranges_base.h (from_range_t): Define new tag
> >   type.
> >   (from_range): Define new tag object.
> >   * include/bits/version.def (ranges_to_container): Define.
> >   * include/bits/version.h: Regenerate.
> >   * include/std/ranges (ranges::to): Define.
> >   * testsuite/std/ranges/conv/1.cc: New test.
> >   * testsuite/std/ranges/conv/2_neg.cc: New test.
> >   * testsuite/std/ranges/conv/version.cc: New test.
> > ---
> >  libstdc++-v3/include/bits/ranges_base.h   |   8 +-
> >  libstdc++-v3/include/bits/version.def |  34 +-
> >  libstdc++-v3/include/bits/version.h   | 111 +++---
> >  libstdc++-v3/include/std/ranges   | 361 -
> >  libstdc++-v3/testsuite/std/ranges/conv/1.cc   | 369 ++
> >  .../testsuite/std/ranges/conv/2_neg.cc|  24 ++
> >  .../testsuite/std/ranges/conv/version.cc  |  19 +
> >  7 files changed, 866 insertions(+), 60 deletions(-)
> >  create mode 100644 libstdc++-v3/testsuite/std/ranges/conv/1.cc
> >  create mode 100644 libstdc++-v3/testsuite/std/ranges/conv/2_neg.cc
> >  create mode 100644 libstdc++-v3/testsuite/std/ranges/conv/version.cc
> >
> > diff --git a/libstdc++-v3/include/bits/ranges_base.h 
> > b/libstdc++-v3/include/bits/ranges_base.h
> > index 7fa43d1965a..1ca2c5ce2bb 100644
> > --- a/libstdc++-v3/include/bits/ranges_base.h
> > +++ b/libstdc++-v3/include/bits/ranges_base.h
> > @@ -37,6 +37,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #ifdef __cpp_lib_concepts
> >  namespace std _GLIBCXX_VISIBILITY(default)
> > @@ -1056,8 +1057,13 @@ namespace ranges
> >  using borrowed_iterator_t = __conditional_t,
> >   iterator_t<_Range>,
> >   dangling>;
> > -
> >  } // namespace ranges
> > +
> > +#if __glibcxx_ranges_to_container // C++ >= 23
> > +  struct from_range_t { explicit from_range_t() = default; };
> > +  inline constexpr from_range_t from_range{};
> > +#endif
> > +
> >  _GLIBCXX_END_NAMESPACE_VERSION
> >  } // namespace std
> >  #endif // library concepts
> > diff --git a/libstdc++-v3/include/bits/version.def 
> > b/libstdc++-v3/include/bits/version.def
> > index 605708dfee7..140777832ed 100644
> > --- a/libstdc++-v3/include/bits/version.def
> > +++ b/libstdc++-v3/include/bits/version.def
> > @@ -1439,19 +1439,21 @@ ftms = {
> >};
> >  };
> >
> > -ftms = {
> > -  name = to_underlying;
> > -  values = {
> > -v = 202102;
> > -cxxmin = 23;
> > -  };
> > -};
> > +//ftms = {
> > +//  name = container_ranges;
> > +//  values = {
> > +//v = 202202;
> > +//cxxmin = 23;
> > +//hosted = yes;
> > +//  };
> > +//};
> >
> >  ftms = {
> > -  name = unreachable;
> > +  name = ranges_to_container;
> >values = {
> >  v = 202202;
> >  cxxmin = 23;
> > +hosted = yes;
> >};
> >  };
> >
> > @@ -1683,6 +1685,22 @@ ftms = {
> >};
> >  };
> >
> > +ftms = {
> > +  name = to_underlying;
> > +  values = {
> > +v = 202102;
> > +cxxmin = 23;
> > +  };
> > +};
> > +
> > +ftms = {
> > +  name = unreachable;
> > +  values = {
> > +v = 202202;
> > +cxxmin = 23;
> > +  };
> > +};
> > +
> >  ftms = {
> >name = fstream_native_handle;
> >values = {
> > diff --git a/libstdc++-v3/include/bits/version.h 
> > b/libstdc++-v3/include/bits/version.h
> > index cacd9375cab..1fb1d148459 100644
> > --- a/libstdc++-v3/include/bits/version.h
> > +++ b/libstdc++-v3/include/bits/version.h
> > @@ -1740,29 +1740,18 @@
> >  #endif /* !defined(__cpp_lib_reference_from_temporary) && 
> > defined(__glibcxx_want_reference_from_temporary) */
> >  #undef __glibcxx_want_reference_from_temporary
> >
> > -// from version.def line 1443
> > -#if !defined(__cpp_lib_to_underlying)
> > -# if (__cplusplus >= 202100L)
> > -#  define __glibcxx_to_underlying 202102L
> > -#  if defined(__glibcxx_want_all) || defined(__glibcxx_want_to_underlying)
> > -#   define __cpp_lib_to_underlying 

[committed] libstdc++: Fix std::ranges::to errors

[Jonathan Wakely]

Tested x86_64-linux. Pushed to trunk.

-- >8 --

Fix some errors that Patrick noticed, and remove a #if 0 group that I
didn't mean to leave in the file.

libstdc++-v3/ChangeLog:

* include/std/ranges (__detail::__toable): Fix incorrect use of
_Range instead of _Cont.
(__detail::_ToClosure, __detail::_ToClosure2): Add missing
constexpr specifier on constructors.
* testsuite/std/ranges/conv/1.cc (_Cont, _Cont2, _Cont3): Remove
unnecessary begin() and end() members.
(test_constexpr): New function to check range adaptors are
usable in constant expressions.
---
 libstdc++-v3/include/std/ranges | 26 +++---
 libstdc++-v3/testsuite/std/ranges/conv/1.cc | 29 +++--
 2 files changed, 19 insertions(+), 36 deletions(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 63bea862c05..9d4c2e01c4d 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -9251,7 +9251,7 @@ namespace __detail
 
   template
 constexpr bool __toable = requires {
-  requires (!input_range<_Range>
+  requires (!input_range<_Cont>
  || convertible_to,
range_value_t<_Cont>>);
 };
@@ -9290,7 +9290,7 @@ namespace __detail
  else if constexpr (constructible_from<_Cont, from_range_t, _Rg, 
_Args...>)
return _Cont(from_range, std::forward<_Rg>(__r),
 std::forward<_Args>(__args)...);
- else if constexpr (requires { common_range<_Rg>;
+ else if constexpr (requires { requires common_range<_Rg>;
typename __iter_category_t>;
requires derived_from<__iter_category_t>,
  input_iterator_tag>;
@@ -9346,26 +9346,6 @@ namespace __detail
   bool operator==(const _InputIter&) const;
 };
 
-#if 0
-  template typename _Cont, typename _Rg,
-  typename... _Args>
-concept __deduce_expr_1 = requires {
-  _Cont(std::declval<_Rg>(), std::declval<_Args>()...);
-};
-
-  template typename _Cont, typename _Rg,
-  typename... _Args>
-concept __deduce_expr_2 = requires {
-  _Cont(from_range, std::declval<_Rg>(), std::declval<_Args>()...);
-};
-
-  template typename _Cont, typename _Rg,
-  typename... _Args>
-concept __deduce_expr_3 = requires(_InputIter<_Rg> __i) {
-  _Cont(std::move(__i), std::move(__i), std::declval<_Args>()...);
-};
-#endif
-
   template typename _Cont, input_range _Rg,
   typename... _Args>
 using _DeduceExpr1
@@ -9418,6 +9398,7 @@ namespace __detail
   tuple...> _M_bound_args;
 
 public:
+  constexpr
   _ToClosure(_Args&&... __args)
   : _M_bound_args(std::forward<_Args>(__args)...)
   { }
@@ -9498,6 +9479,7 @@ namespace __detail
   tuple...> _M_bound_args;
 
 public:
+  constexpr
   _ToClosure2(_Args&&... __args)
   : _M_bound_args(std::forward<_Args>(__args)...)
   { }
diff --git a/libstdc++-v3/testsuite/std/ranges/conv/1.cc 
b/libstdc++-v3/testsuite/std/ranges/conv/1.cc
index 0032cf32688..4b6814b1add 100644
--- a/libstdc++-v3/testsuite/std/ranges/conv/1.cc
+++ b/libstdc++-v3/testsuite/std/ranges/conv/1.cc
@@ -89,9 +89,6 @@ struct Cont1
 : c(r, args...)
 { }
 
-  typename C::iterator begin();
-  typename C::iterator end();
-
   C c;
 };
 
@@ -153,9 +150,6 @@ struct Cont2
 : c(r, args...)
 { }
 
-  typename C::iterator begin();
-  typename C::iterator end();
-
   C c;
 };
 
@@ -186,9 +180,6 @@ struct Cont3
 : c(first, last, args...)
 { }
 
-  typename C::iterator begin();
-  typename C::iterator end();
-
   C c;
 };
 
@@ -222,10 +213,6 @@ struct Cont4
   Cont4() { }
   Cont4(typename C::allocator_type a) : c(a) { }
 
-  // Required to satisfy range
-  typename C::iterator begin() { return c.begin(); }
-  typename C::iterator end() { return c.end(); }
-
   // Satisfying container-insertable requires either this ...
   template
 requires UsePushBack
@@ -254,7 +241,9 @@ struct Cont4
 used_reserve = true;
   }
 
-  // Required to satisfy reservable-container
+  // Satisfying sized_range is required to satisfy reservable-container
+  typename C::iterator begin() { return c.begin(); }
+  typename C::iterator end() { return c.end(); }
   auto size() const { return c.size(); }
 
   // Required to satisfy reservable-container
@@ -355,6 +344,17 @@ test_nodiscard()
   std::ranges::to();// { dg-warning "ignoring return" }
 }
 
+void
+test_constexpr()
+{
+  constexpr int x = [](int i) {
+auto c1 = std::views::iota(1, i) | std::ranges::to>();
+auto c2 = std::views::iota(i, 10) | std::ranges::to();
+return c1[0] + c2[0];
+  }(5);
+  static_assert(x == 6);
+}
+
 int main()
 {
   test_p1206r7_examples();
@@ -366,4 +366,5 @@ int main()
   test_2_2();
   test_lwg3984();
   test_nodiscard();
+  test_constexpr();
 }
-- 
2.43.0

Re: [V2] New pass for sign/zero extension elimination -- not ready for "final" review

[Jeff Law]

On 11/29/23 19:39, Joern Rennecke wrote:

On Wed, 29 Nov 2023 at 20:05, Joern Rennecke
 wrote:


I suspect it'd be more useful to add handling of LSHIFTRT and ASHIFTRT
.  Some ports do
a lot of static shifting.



+case SS_ASHIFT:
+case US_ASHIFT:
+  if (!mask || XEXP (x, 1) == const0_rtx)
+   return 0;


P.S.: I just realize that this is a pasto: in the case of a const0_rtx
shift count,
we returning 0 will usually be wrong.


I've attached my current patch version.
I would strongly suggest we not start adding a lot of new capabilities 
here, deferring such work until gcc-15.  Our focus should be getting the 
existing code working well and cleanly implemented.


Jeff

Re: [PATCH v3 3/3] c++: note other candidates when diagnosing deletedness

[Patrick Palka]

On Fri, 27 Oct 2023, Patrick Palka wrote:

> On Fri, 27 Oct 2023, Jason Merrill wrote:
> 
> > On 10/27/23 15:55, Patrick Palka wrote:
> > > With the previous two patches in place, we can now extend our
> > > deletedness diagnostic to note the other considered candidates, e.g.:
> > > 
> > >deleted16.C: In function 'int main()':
> > >deleted16.C:10:4: error: use of deleted function 'void f(int)'
> > >   10 |   f(0);
> > >  |   ~^~~
> > >deleted16.C:5:6: note: declared here
> > >5 | void f(int) = delete;
> > >  |  ^
> > >deleted16.C:5:6: note: candidate: 'void f(int)' (deleted)
> > >deleted16.C:6:6: note: candidate: 'void f(...)'
> > >6 | void f(...);
> > >  |  ^
> > >deleted16.C:7:6: note: candidate: 'void f(int, int)'
> > >7 | void f(int, int);
> > >  |  ^
> > >deleted16.C:7:6: note:   candidate expects 2 arguments, 1 provided
> > > 
> > > These notes are controlled by a new command line flag -fnote-all-cands,
> > > which also controls whether we note ignored candidates more generally.
> > > 
> > > gcc/ChangeLog:
> > > 
> > >   * doc/invoke.texi (C++ Dialect Options): Document -fnote-all-cands.
> > > 
> > > gcc/c-family/ChangeLog:
> > > 
> > >   * c.opt: Add -fnote-all-cands.
> > > 
> > > gcc/cp/ChangeLog:
> > > 
> > >   * call.cc (print_z_candidates): Only print ignored candidates
> > >   when -fnote-all-cands is set.
> > >   (build_over_call): When diagnosing deletedness, call
> > >   print_z_candidates if -fnote-all-cands is set.
> > 
> > My suggestion was also to suggest using the flag in cases where it would 
> > make
> > a difference, e.g.
> > 
> > note: some candidates omitted, use '-fnote-all-cands' to display them
> 
> Ah thanks, fixed.  That'll help a lot with discoverability of the flag.
> 
> > 
> > Maybe "-fdiagnostics-all-candidates"?
> 
> Nice, that's a better name indeed :)
> 
> How does the following look?  Full bootstrap/regtest in progress.
> 
> Here's the output of e.g. deleted16a.C.  I think I'd prefer to not print
> the source line when emitting the suggestion, but I don't know how to do
> that properly (aside from e.g. emitting the note at UNKNOWN_LOCATION).
> 
> In file included from gcc/testsuite/g++.dg/cpp0x/deleted16a.C:4:
> gcc/testsuite/g++.dg/cpp0x/deleted16.C: In function ‘int main()’:
> gcc/testsuite/g++.dg/cpp0x/deleted16.C:21:4: error: use of deleted function 
> ‘void f(int)’
>21 |   f(0); // { dg-error "deleted" }
>   |   ~^~~
> gcc/testsuite/g++.dg/cpp0x/deleted16.C:6:6: note: declared here
> 6 | void f(int) = delete; // { dg-message "declared here" }
>   |  ^
> gcc/testsuite/g++.dg/cpp0x/deleted16.C:21:4: note: use 
> ‘-fdiagnostics-all-candidates’ to display considered candidates
>21 |   f(0); // { dg-error "deleted" }
>   |   ~^~~
> gcc/testsuite/g++.dg/cpp0x/deleted16.C:22:4: error: use of deleted function 
> ‘void g(int)’
>22 |   g(0); // { dg-error "deleted" }
>   |   ~^~~
> gcc/testsuite/g++.dg/cpp0x/deleted16.C:12:6: note: declared here
>12 | void g(int) = delete; // { dg-message "declared here" }
>   |  ^
> gcc/testsuite/g++.dg/cpp0x/deleted16.C:22:4: note: use 
> ‘-fdiagnostics-all-candidates’ to display considered candidates
>22 |   g(0); // { dg-error "deleted" }
>   |   ~^~~
> gcc/testsuite/g++.dg/cpp0x/deleted16.C:23:4: error: use of deleted function 
> ‘void h(T, T) [with T = int]’
>23 |   h(1, 1); // { dg-error "deleted" }
>   |   ~^~
> gcc/testsuite/g++.dg/cpp0x/deleted16.C:17:24: note: declared here
>17 | template void h(T, T) = delete; // { dg-message "declared 
> here|candidate" }
>   |^
> gcc/testsuite/g++.dg/cpp0x/deleted16.C:23:4: note: use 
> ‘-fdiagnostics-all-candidates’ to display considered candidates
>23 |   h(1, 1); // { dg-error "deleted" }
>   |   ~^~
> 
> -- >8 --
> 
> 
> Subject: [PATCH 3/3] c++: note other candidates when diagnosing deletedness
> 
> With the previous two patches in place, we can now extend our
> deletedness diagnostic to note the other considered candidates, e.g.:
> 
>   deleted16.C: In function 'int main()':
>   deleted16.C:10:4: error: use of deleted function 'void f(int)'
>  10 |   f(0);
> |   ~^~~
>   deleted16.C:5:6: note: declared here
>   5 | void f(int) = delete;
> |  ^
>   deleted16.C:5:6: note: candidate: 'void f(int)' (deleted)
>   deleted16.C:6:6: note: candidate: 'void f(...)'
>   6 | void f(...);
> |  ^
>   deleted16.C:7:6: note: candidate: 'void f(int, int)'
>   7 | void f(int, int);
> |  ^
>   deleted16.C:7:6: note:   candidate expects 2 arguments, 1 provided
> 
> These notes are controlled by a new command line flag
> -fdiagnostics-all-candidates which also controls whether we note
> ignored candidates more generally.
> 
> gcc/ChangeLog:
> 
>   * doc/invoke.texi (C++ Dialect Options): Document
>   -fdiagnostics-all-candidates.
>