Re: [PATCH] analyzer: deal with -fshort-enums

2023-11-21 Thread Alexandre Oliva
On Nov 20, 2023, David Malcolm  wrote:

> On Sun, 2023-11-19 at 04:39 -0300, Alexandre Oliva wrote:
>> 
>> On platforms that enable -fshort-enums by default, various switch-
>> enum
>> analyzer tests fail, because apply_constraints_for_gswitch doesn't
>> expect the integral promotion type cast.  I've arranged for the code
>> to cope with those casts.

> Thanks for the patch, and sorry for the failing tests.

No worries.

> Which tests failed?  I'm guessing one of the ones from r13-5159-
> gccd4df81aa6537.

Yeah, I'm afraid I didn't take notes about which tests failed (I'll try
to dig that up), but I'm sure switch-enum-1, switch-enum-2, and
switch-enum-pr105273-doom-p_maputl.c.  I *think* also switch-enum-5 and
switch-enum-pr105273-doom-p_floor.c.

> Can you add a copy of one of those tests that needs the patch, with an
> explicit -fshort-enums, to ensure that regression testing is hitting
> this case on all targets in the future?

Ah, nice, that's a great idea, I wish I'd thought of that!  Will do.

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


Re: [PATCH] binutils: v2: experimental use of libdiagnostics in gas

2023-11-21 Thread Jan Beulich
On 21.11.2023 23:20, David Malcolm wrote:
> @@ -101,6 +109,29 @@ had_warnings (void)
>return warning_count;
>  }
>  
> +#if USE_LIBDIAGNOSTICS
> +static diagnostic_manager *diag_mgr;
> +#endif
> +
> +void messages_init (void)
> +{
> +#if USE_LIBDIAGNOSTICS
> +  diag_mgr = diagnostic_manager_new ();
> +  diagnostic_manager_add_text_sink (diag_mgr, stderr,
> + DIAGNOSTIC_COLORIZE_IF_TTY);

Coloring will want to be possible to turn off (or maybe be off by default,
and be possible to turn on).

As to the #if-s: I think they all would better be #ifdef.

> @@ -182,6 +213,20 @@ as_warn_internal (const char *file, unsigned int line, 
> char *buffer)
>context = true;
>  }
>  
> +#if USE_LIBDIAGNOSTICS
> +  const diagnostic_file *file_obj
> += diagnostic_manager_new_file (diag_mgr, file, NULL);
> +
> +  const diagnostic_physical_location *loc
> += diagnostic_manager_new_location_from_file_and_line (diag_mgr,
> +   file_obj,
> +   line);
> +
> +  diagnostic *d = diagnostic_begin (diag_mgr,
> + DIAGNOSTIC_LEVEL_WARNING);
> +  diagnostic_set_location (d, loc);
> +  diagnostic_finish (d, "%s", buffer);
> +#else

This looks identical to ...

> @@ -256,6 +302,19 @@ as_bad_internal (const char *file, unsigned int line, 
> char *buffer)
>context = true;
>  }
>  
> +#if USE_LIBDIAGNOSTICS
> +  const diagnostic_file *file_obj
> += diagnostic_manager_new_file (diag_mgr, file, NULL);
> +  const diagnostic_physical_location *loc
> += diagnostic_manager_new_location_from_file_and_line (diag_mgr,
> +   file_obj,
> +   line);
> +
> +  diagnostic *d = diagnostic_begin (diag_mgr,
> + DIAGNOSTIC_LEVEL_ERROR);
> +  diagnostic_set_location (d, loc);
> +  diagnostic_finish (d, "%s", buffer);
> +#else

... this, except for the level used. Put into a helper function? Which
would the further want using from as_info_where()?

Jan


Re: [PATCH] [APX PUSH2POP2] Adjust operand order for PUSH2POP2

2023-11-21 Thread Hongtao Liu
On Wed, Nov 22, 2023 at 11:31 AM Hongyu Wang  wrote:
>
> Hi,
>
> The push2/pop2 operand order does not match the binutils implementation
> for AT syntax that it will first push operands[2] then operands[1].
> Correct it by reverse operand order for AT syntax.
>
> Bootstrapped/regtested on x86-64-linux-pc-gnu{-m32,}
>
> Ok for master?
Ok.
>
> gcc/ChangeLog:
>
> * config/i386/i386.md (push2_di): Adjust operand order for AT
> syntax.
> (pop2_di): Likewise.
> (push2p_di): Likewise.
> (pop2p_di): Likewise.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/apx-push2pop2-1.c: Adjust output scan.
> * gcc.target/i386/apx-push2pop2_force_drap-1.c: Likewise.
> ---
>  gcc/config/i386/i386.md   | 8 
>  gcc/testsuite/gcc.target/i386/apx-push2pop2-1.c   | 8 
>  .../gcc.target/i386/apx-push2pop2_force_drap-1.c  | 8 
>  3 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index 03e4ddd3037..99bb909b244 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -3772,7 +3772,7 @@ (define_insn "push2_di"
> (match_operand:DI 2 "register_operand" "r")]
> UNSPEC_APXPUSH2))]
>"TARGET_APX_PUSH2POP2"
> -  "push2\t%1, %2"
> +  "push2\t{%2, %1|%1, %2}"
>[(set_attr "mode" "TI")
> (set_attr "type" "multi")
> (set_attr "prefix" "evex")])
> @@ -3784,7 +3784,7 @@ (define_insn "pop2_di"
>   (set (match_operand:DI 2 "register_operand" "=r")
>(unspec:DI [(const_int 0)] UNSPEC_APXPOP2_HIGH))])]
>"TARGET_APX_PUSH2POP2"
> -  "pop2\t%0, %2"
> +  "pop2\t{%2, %0|%0, %2}"
>[(set_attr "mode" "TI")
> (set_attr "prefix" "evex")])
>
> @@ -3811,7 +3811,7 @@ (define_insn "push2p_di"
> UNSPEC_APXPUSH2))
> (unspec:DI [(const_int 0)] UNSPEC_APX_PPX)]
>"TARGET_APX_PUSH2POP2 && TARGET_APX_PPX"
> -  "push2p\t%1, %2"
> +  "push2p\t{%2, %1|%1, %2}"
>[(set_attr "mode" "TI")
> (set_attr "type" "multi")
> (set_attr "prefix" "evex")])
> @@ -3824,7 +3824,7 @@ (define_insn "pop2p_di"
>(unspec:DI [(const_int 0)] UNSPEC_APXPOP2_HIGH))
>   (unspec:DI [(const_int 0)] UNSPEC_APX_PPX)])]
>"TARGET_APX_PUSH2POP2 && TARGET_APX_PPX"
> -  "pop2p\t%0, %2"
> +  "pop2p\t{%2, %0|%0, %2}"
>[(set_attr "mode" "TI")
> (set_attr "prefix" "evex")])
>
> diff --git a/gcc/testsuite/gcc.target/i386/apx-push2pop2-1.c 
> b/gcc/testsuite/gcc.target/i386/apx-push2pop2-1.c
> index c53112758a5..d78c96d36a3 100644
> --- a/gcc/testsuite/gcc.target/i386/apx-push2pop2-1.c
> +++ b/gcc/testsuite/gcc.target/i386/apx-push2pop2-1.c
> @@ -24,11 +24,11 @@ void foo ()
>  /* { dg-final { scan-assembler-times ".cfi_def_cfa_offset 16" 2 } } */
>  /* { dg-final { scan-assembler-times "pushq\[^\n\r]*%r15(?:\n|\[ \\t\]+#)" 1 
> } } */
>  /* { dg-final { scan-assembler-times ".cfi_offset 15, -16(?:\n|\[ \\t\]+#)" 
> 1 } } */
> -/* { dg-final { scan-assembler-times "push2\[\\t 
> \]*\[^\n\r]*%r14\[^\n\r]*%r13\[^\n\r]*(?:\n|\[ \\t\]+#)" 1 } } */
> +/* { dg-final { scan-assembler-times "push2\[\\t 
> \]*\[^\n\r]*%r13\[^\n\r]*%r14\[^\n\r]*(?:\n|\[ \\t\]+#)" 1 } } */
>  /* { dg-final { scan-assembler-times ".cfi_def_cfa_offset 32" 2 } } */
>  /* { dg-final { scan-assembler-times ".cfi_offset 14, -24(?:\n|\[ \\t\]+#)" 
> 1 } } */
>  /* { dg-final { scan-assembler-times ".cfi_offset 13, -32(?:\n|\[ \\t\]+#)" 
> 1 } } */
> -/* { dg-final { scan-assembler-times "push2\[\\t 
> \]*\[^\n\r]*%r12\[^\n\r]*%rbp\[^\n\r]*(?:\n|\[ \\t\]+#)" 1 } } */
> +/* { dg-final { scan-assembler-times "push2\[\\t 
> \]*\[^\n\r]*%rbp\[^\n\r]*%r12\[^\n\r]*(?:\n|\[ \\t\]+#)" 1 } } */
>  /* { dg-final { scan-assembler-times ".cfi_def_cfa_offset 48" 2 } } */
>  /* { dg-final { scan-assembler-times ".cfi_offset 12, -40(?:\n|\[ \\t\]+#)" 
> 1 } } */
>  /* { dg-final { scan-assembler-times ".cfi_offset 6, -48(?:\n|\[ \\t\]+#)" 1 
> } } */
> @@ -36,10 +36,10 @@ void foo ()
>  /* { dg-final { scan-assembler-times ".cfi_def_cfa_offset 56" 2 } } */
>  /* { dg-final { scan-assembler-times ".cfi_offset 3, -56(?:\n|\[ \\t\]+#)" 1 
> } } */
>  /* { dg-final { scan-assembler-times "popq\[^\n\r]*rbx(?:\n|\[ \\t\]+#)" 1 } 
> } */
> -/* { dg-final { scan-assembler-times "pop2\[\\t 
> \]*\[^\n\r]*%rbp\[^\n\r]*%r12\[^\n\r]*(?:\n|\[ \\t\]+#)" 1 } } */
> +/* { dg-final { scan-assembler-times "pop2\[\\t 
> \]*\[^\n\r]*%r12\[^\n\r]*%rbp\[^\n\r]*(?:\n|\[ \\t\]+#)" 1 } } */
>  /* { dg-final { scan-assembler-times ".cfi_restore 12(?:\n|\[ \\t\]+#)" 1 } 
> } */
>  /* { dg-final { scan-assembler-times ".cfi_restore 6(?:\n|\[ \\t\]+#)" 1 } } 
> */
> -/* { dg-final { scan-assembler-times "pop2\[\\t 
> \]*\[^\n\r]*%r13\[^\n\r]*%r14\[^\n\r]*(?:\n|\[ \\t\]+#)" 1 } } */
> +/* { dg-final { scan-assembler-times "pop2\[\\t 
> \]*\[^\n\r]*%r14\[^\n\r]*%r13\[^\n\r]*(?:\n|\[ \\t\]+#)" 1 } } */
>  

Re: [PATCH] LoongArch: Optimize LSX vector shuffle on floating-point vector

2023-11-21 Thread chenglulu



在 2023/11/19 下午3:01, Xi Ruoyao 写道:

The vec_perm expander was wrongly defined.  GCC internal says:

Operand 3 is the “selector”.  It is an integral mode vector of the same
width and number of elements as mode M.

With this mistake, the generic code manages to work around and it ends
up creating some very nasty code for a simple __builtin_shuffle (a, b,
c) where a and b are V4SF, c is V4SI:

 la.local$r12,.LANCHOR0
 la.local$r13,.LANCHOR1
 vld $vr1,$r12,48
 vslli.w $vr1,$vr1,2
 vld $vr2,$r12,16
 vld $vr0,$r13,0
 vld $vr3,$r13,16
 vshuf.b $vr0,$vr1,$vr1,$vr0
 vld $vr1,$r12,32
 vadd.b  $vr0,$vr0,$vr3
 vandi.b $vr0,$vr0,31
 vshuf.b $vr0,$vr1,$vr2,$vr0
 vst $vr0,$r12,0
 jr  $r1

This is obviously stupid.  Fix the expander definition and adjust
loongarch_expand_vec_perm to handle it correctly.

gcc/ChangeLog:

* config/loongarch/lsx.md (vec_perm): Make the
selector VIMODE.
* config/loongarch/loongarch.cc (loongarch_expand_vec_perm):
Use the mode of the selector (instead of the shuffled vector)
for truncating it.  Operate on subregs in the selector mode if
the shuffled vector has a different mode (i. e. it's a
floating-point vector).

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/vect-shuf-fp.c: New test.
---

Bootstrapped & regtested on loongarch64-linux-gnu.  Ok for trunk?

LGTM. Thanks!


  gcc/config/loongarch/loongarch.cc  | 18 ++
  gcc/config/loongarch/lsx.md|  2 +-
  .../gcc.target/loongarch/vect-shuf-fp.c| 16 
  3 files changed, 27 insertions(+), 9 deletions(-)
  create mode 100644 gcc/testsuite/gcc.target/loongarch/vect-shuf-fp.c

diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index ce601a331f7..33357c670e1 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -8607,8 +8607,9 @@ void
  loongarch_expand_vec_perm (rtx target, rtx op0, rtx op1, rtx sel)
  {
machine_mode vmode = GET_MODE (target);
+  machine_mode vimode = GET_MODE (sel);
auto nelt = GET_MODE_NUNITS (vmode);
-  auto round_reg = gen_reg_rtx (vmode);
+  auto round_reg = gen_reg_rtx (vimode);
rtx round_data[MAX_VECT_LEN];
  
for (int i = 0; i < nelt; i += 1)

@@ -8616,9 +8617,16 @@ loongarch_expand_vec_perm (rtx target, rtx op0, rtx op1, 
rtx sel)
round_data[i] = GEN_INT (0x1f);
  }
  
-  rtx round_data_rtx = gen_rtx_CONST_VECTOR (vmode, gen_rtvec_v (nelt, round_data));

+  rtx round_data_rtx = gen_rtx_CONST_VECTOR (vimode, gen_rtvec_v (nelt, 
round_data));
emit_move_insn (round_reg, round_data_rtx);
  
+  if (vmode != vimode)

+{
+  target = lowpart_subreg (vimode, target, vmode);
+  op0 = lowpart_subreg (vimode, op0, vmode);
+  op1 = lowpart_subreg (vimode, op1, vmode);
+}
+
switch (vmode)
  {
  case E_V16QImode:
@@ -8626,17 +8634,11 @@ loongarch_expand_vec_perm (rtx target, rtx op0, rtx 
op1, rtx sel)
emit_insn (gen_lsx_vshuf_b (target, op1, op0, sel));
break;
  case E_V2DFmode:
-  emit_insn (gen_andv2di3 (sel, sel, round_reg));
-  emit_insn (gen_lsx_vshuf_d_f (target, sel, op1, op0));
-  break;
  case E_V2DImode:
emit_insn (gen_andv2di3 (sel, sel, round_reg));
emit_insn (gen_lsx_vshuf_d (target, sel, op1, op0));
break;
  case E_V4SFmode:
-  emit_insn (gen_andv4si3 (sel, sel, round_reg));
-  emit_insn (gen_lsx_vshuf_w_f (target, sel, op1, op0));
-  break;
  case E_V4SImode:
emit_insn (gen_andv4si3 (sel, sel, round_reg));
emit_insn (gen_lsx_vshuf_w (target, sel, op1, op0));
diff --git a/gcc/config/loongarch/lsx.md b/gcc/config/loongarch/lsx.md
index 8ea41c85b01..5e8d8d74b43 100644
--- a/gcc/config/loongarch/lsx.md
+++ b/gcc/config/loongarch/lsx.md
@@ -837,7 +837,7 @@ (define_expand "vec_perm"
   [(match_operand:LSX 0 "register_operand")
(match_operand:LSX 1 "register_operand")
(match_operand:LSX 2 "register_operand")
-  (match_operand:LSX 3 "register_operand")]
+  (match_operand: 3 "register_operand")]
"ISA_HAS_LSX"
  {
loongarch_expand_vec_perm (operands[0], operands[1],
diff --git a/gcc/testsuite/gcc.target/loongarch/vect-shuf-fp.c 
b/gcc/testsuite/gcc.target/loongarch/vect-shuf-fp.c
new file mode 100644
index 000..7acc2113afe
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vect-shuf-fp.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-mlasx -O3" } */
+/* { dg-final { scan-assembler "vshuf\.w" } } */
+
+#define V __attribute__ ((vector_size (16)))
+
+int a V;
+float b V;
+float c V;
+float d V;
+
+void
+test (void)
+{
+  d = __builtin_shuffle (b, c, a);
+}




Re: [PATCH] RISC-V: Fix permutation indice mode bug

2023-11-21 Thread Robin Dapp
LGTM.

Regards
 Robin



[PATCH] RISC-V: Fix permutation indice mode bug

2023-11-21 Thread Juzhe-Zhong
This patch fixes following FAILs on zvl512b:
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-1.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-1.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-16.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-16.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-17.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-17.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-3.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-3.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-5.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-5.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-6.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/slp_run-6.c execution test

The root cause is that we are using vrgather.vv on vector QI mode which 
is incorrect for zvl512b since it exceed 256.

Instead, we should use vrgatherei16.vv

PR target/112598

gcc/ChangeLog:

* config/riscv/riscv-v.cc (emit_vlmax_gather_insn): Adapt the priority.
(shuffle_generic_patterns): Fix permutation indice bug.
* config/riscv/vector-iterators.md: Fix VEI16 bug.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr112598-2.c: New test.

---
 gcc/config/riscv/riscv-v.cc   | 31 ++-
 gcc/config/riscv/vector-iterators.md  | 14 -
 .../gcc.target/riscv/rvv/autovec/pr112598-2.c | 24 ++
 3 files changed, 54 insertions(+), 15 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/pr112598-2.c

diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index 541dffba07b..7d6d0821d87 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -839,13 +839,13 @@ emit_vlmax_gather_insn (rtx target, rtx op, rtx sel)
   insn_code icode;
   machine_mode data_mode = GET_MODE (target);
   machine_mode sel_mode = GET_MODE (sel);
-  if (maybe_ne (GET_MODE_SIZE (data_mode), GET_MODE_SIZE (sel_mode)))
-icode = code_for_pred_gatherei16 (data_mode);
-  else if (const_vec_duplicate_p (sel, ))
+  if (const_vec_duplicate_p (sel, ))
 {
   icode = code_for_pred_gather_scalar (data_mode);
   sel = elt;
 }
+  else if (maybe_ne (GET_MODE_SIZE (data_mode), GET_MODE_SIZE (sel_mode)))
+icode = code_for_pred_gatherei16 (data_mode);
   else if (CONST_VECTOR_P (sel)
&& GET_MODE_BITSIZE (GET_MODE_INNER (sel_mode)) > 16
&& riscv_get_v_regno_alignment (data_mode) > 1)
@@ -3261,11 +3261,26 @@ shuffle_generic_patterns (struct expand_vec_perm_d *d)
   if (!pow2p_hwi (d->perm.encoding().npatterns ()))
 return false;
 
-  /* Permuting two SEW8 variable-length vectors need vrgatherei16.vv.
- Otherwise, it could overflow the index range.  */
-  if (!nunits.is_constant () && GET_MODE_INNER (d->vmode) == QImode
-  && !get_vector_mode (HImode, nunits).exists (_mode))
-return false;
+  if (GET_MODE_INNER (d->vmode) == QImode)
+{
+  if (nunits.is_constant ())
+   {
+ /* If indice is LMUL8 CONST_VECTOR and any element value
+exceed the range of 0 ~ 255, Forbid such permutation
+since we need vector HI mode to hold such indice and
+we don't have it.  */
+ if (!d->perm.all_in_range_p (0, 255)
+ && !get_vector_mode (HImode, nunits).exists (_mode))
+   return false;
+   }
+  else
+   {
+ /* Permuting two SEW8 variable-length vectors need vrgatherei16.vv.
+Otherwise, it could overflow the index range.  */
+ if (!get_vector_mode (HImode, nunits).exists (_mode))
+   return false;
+   }
+}
 
   /* Success! */
   if (d->testing_p)
diff --git a/gcc/config/riscv/vector-iterators.md 
b/gcc/config/riscv/vector-iterators.md
index 10187306de8..27dae102fff 100644
--- a/gcc/config/riscv/vector-iterators.md
+++ b/gcc/config/riscv/vector-iterators.md
@@ -376,13 +376,13 @@
   (V4QI "riscv_vector::vls_mode_valid_p (V4QImode)")
   (V8QI "riscv_vector::vls_mode_valid_p (V8QImode)")
   (V16QI "riscv_vector::vls_mode_valid_p (V16QImode)")
-  (V32QI "riscv_vector::vls_mode_valid_p (V32QImode)")
-  (V64QI "riscv_vector::vls_mode_valid_p (V64QImode) && TARGET_MIN_VLEN >= 64")
-  (V128QI "riscv_vector::vls_mode_valid_p (V128QImode) && TARGET_MIN_VLEN >= 
128")
-  (V256QI "riscv_vector::vls_mode_valid_p (V256QImode) && TARGET_MIN_VLEN >= 
256")
-  (V512QI "riscv_vector::vls_mode_valid_p (V512QImode) && TARGET_MIN_VLEN >= 
512")
-  (V1024QI "riscv_vector::vls_mode_valid_p (V1024QImode) && TARGET_MIN_VLEN >= 
1024")
-  (V2048QI "riscv_vector::vls_mode_valid_p (V2048QImode) && TARGET_MIN_VLEN >= 
2048")
+  (V32QI "riscv_vector::vls_mode_valid_p (V32QImode) && TARGET_MIN_VLEN >= 64")
+  (V64QI "riscv_vector::vls_mode_valid_p (V64QImode) && TARGET_MIN_VLEN 

Re: Re: [PATCH] RISC-V: testsuite: Remove redundant vector_hw and zvfh_hw.

2023-11-21 Thread juzhe.zh...@rivai.ai
LGTM。



juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2023-11-22 14:03
To: juzhe.zh...@rivai.ai; gcc-patches; palmer; kito.cheng; jeffreyalaw
CC: rdapp.gcc
Subject: Re: [PATCH] RISC-V: testsuite: Remove redundant vector_hw and zvfh_hw.
> I don't get it. Why do we need remove them ? 
 
It's just replaced by riscv_zvfh.  I should probably edit the
patch description and changelog entries to make it clearer.
 
Regards
Robin
 
 


Re: [PATCH] RISC-V: testsuite: Remove redundant vector_hw and zvfh_hw.

2023-11-21 Thread Robin Dapp
> I don't get it. Why do we need remove them ? 

It's just replaced by riscv_zvfh.  I should probably edit the
patch description and changelog entries to make it clearer.

Regards
 Robin



Re: [PING][PATCH] c++: Introduce the extended attribute for asm declarations

2023-11-21 Thread Julian Waters
Hi Ruoyao,

Thanks for the tips, I'll keep it in mind

I've seen the contribution style guide, but it can be pretty difficult
to format gcc's source in a patch, at least for me :(

Noted, I'll add more descriptions to prove it's use case, thanks

best regards,
Julian

On Wed, Nov 22, 2023 at 4:28 AM Xi Ruoyao  wrote:
>
> On Mon, 2023-11-20 at 16:35 +0800, Julian Waters wrote:
> > Hi all, I'd like to ping the following patch
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636924.html
>
> You posted the patch Friday and then pinged it in Monday.  There is
> literally zero working days for people to review the patch.
> https://gcc.gnu.org/contribute.html suggests to ping after at least two
> weeks.  Sometimes I ping a patch after one week if it's urgent but 0
> working days is definitely a no-go.
>
> Also see the contribute patch for some basic style rules of the GCC code
> and submitting a patch.  Bad-styled patches are often silently ignored.
>
> On pure technical basis, you need to prove the new feature added is
> really useful, for general use cases and not only your own use case.
> Once a feature is in GCC the developers need to pay efforts to maintain
> it, so it won't be added unless it will benefit some general use case.
>
> --
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University


[PATCH] Set AVOID_256FMA_CHAINS TO m_GENERIC as it's generally good to new platforms

2023-11-21 Thread liuhongt
From: "Zhang, Annita" 

Avoid_fma_chain was enabled in m_SAPPHIRERAPIDS, m_ALDERLAKE and
m_CORE_HYBRID. It can also be enabled in m_GENERIC to improve the
performance of -march=x86-64-v3/v4 with -mtune=generic set by
default. One SPEC2017 benchmark 510.parest_r can improve greatly due
to it. From the experiments, the single thread with -O2
-march=x86-64-v3 can improve 26% on SPR, and 15% on Zen3. Meanwhile,
it didn't cause notable regression in previous platforms including
Cascade Lake and Ice Lake Server.

On zenver4, it looks like fadd(3 cycles) is still fater than fma(4
cycles). So in theory, avoid_fma_chain should be also better for
znver4. And according to [1], enable fma_chain is not a generic win on
znver4?

cut from [1]---
I also added X86_TUNE_AVOID_256FMA_CHAINS. Since fma has improved in
zen4 this flag may not be a win except for very specific benchmarks. I
am still doing some more detailed testing here.
-cut end--

[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607962.html

Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?

gcc/ChangeLog

* config/i386/x86-tune.def (AVOID_256FMA_CHAINS): Add
m_GENERIC.
---
 gcc/config/i386/x86-tune.def | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/i386/x86-tune.def b/gcc/config/i386/x86-tune.def
index 43fa9e8fd6d..a2e57e01550 100644
--- a/gcc/config/i386/x86-tune.def
+++ b/gcc/config/i386/x86-tune.def
@@ -521,7 +521,7 @@ DEF_TUNE (X86_TUNE_AVOID_128FMA_CHAINS, "avoid_fma_chains", 
m_ZNVER1 | m_ZNVER2
 /* X86_TUNE_AVOID_256FMA_CHAINS: Avoid creating loops with tight 256bit or
smaller FMA chain.  */
 DEF_TUNE (X86_TUNE_AVOID_256FMA_CHAINS, "avoid_fma256_chains", m_ZNVER2 | 
m_ZNVER3
- | m_CORE_HYBRID | m_SAPPHIRERAPIDS | m_CORE_ATOM)
+ | m_CORE_HYBRID | m_SAPPHIRERAPIDS | m_CORE_ATOM | m_GENERIC)
 
 /* X86_TUNE_AVOID_512FMA_CHAINS: Avoid creating loops with tight 512bit or
smaller FMA chain.  */
-- 
2.31.1



Re: [PATCH] c++, v3: Implement C++26 P2741R3 - user-generated static_assert messages [PR110348]

2023-11-21 Thread Jason Merrill

On 11/21/23 17:51, Jakub Jelinek wrote:

On Tue, Nov 21, 2023 at 11:19:56PM +0100, Jakub Jelinek wrote:

+ error_at (location, "% message must be a string "
+ "literal or object with % and "
+ "% members");


Let's print the type of the message as well.


so add " while it has type %qT", TREE_TYPE (message) or something else?


Now in patch form (except for the removal of warning_at for now):

+  if (TREE_CODE (message) != STRING_CST
+  && !type_dependent_expression_p (message))
+{
+  message_sz
+   = finish_class_member_access_expr (message,
+  get_identifier ("size"),
+  false, tf_none);
+  message_data
+   = finish_class_member_access_expr (message,
+  get_identifier ("data"),
+  false, tf_none);
+  if (message_sz == error_mark_node || message_data == error_mark_node)
+   {
+ error_at (location, "% message must be a string "
+ "literal or object with % and "
+ "% members while it has type %qT",


Actually, let's go back to the previous message, but change the tf_nones 
above to 'complain' so that we see those errors and then this 
explanation.  Likewise with the conversion checks later in the function.



+ TREE_TYPE (message));
+ return;
+   }
+  releasing_vec size_args, data_args;
+  message_sz = finish_call_expr (message_sz, _args, false, false,
+tf_warning_or_error);
+  message_data = finish_call_expr (message_data, _args, false, false,
+  tf_warning_or_error);


Can use 'complain' instead of tf_warning_or_error here, too.


+  if (message_sz == error_mark_node || message_data == error_mark_node)
+   return;
+  if (tree s
+ = cp_get_callee_fndecl_nofold (extract_call_expr (message_sz)))
+   if (!DECL_DECLARED_CONSTEXPR_P (s))
+ warning_at (location, 0, "%qD used in % message "
+  "is not %", s);



I don't think we need this check, it should be covered by the later
constant-expression checks.


If the static_assert condition is true, we won't diagnose anything then.
clang++ there incorrectly errors, but I thought a warning could be useful
to users.  Perhaps it could warn only if the condition is true?


I don't think the extra warning is that useful, especially with no flag 
to suppress it; we specifically decided not to require the message to be 
constant if the condition is true, and involving a non-constexpr 
function is just one example of how it might not be constant.


Jason



[pushed] c++: start_preparsed_function tweak

2023-11-21 Thread Jason Merrill
Tested x86_64-pc-linux-gnu, applying to trunk.

-- 8< --

In review of the deducing 'this' patch, it came up that the logic in
start_preparsed_function around the ctype variable was convoluted, being
set for non-static member functions and friends, but not for static member
functions.  Let's set it for any member function, and not rely on it to
decide whether to set up 'this'.

gcc/cp/ChangeLog:

* decl.cc (start_preparsed_function): Clarify ctype logic.
---
 gcc/cp/decl.cc | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index e6f75d771e0..e7701afdefd 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -17392,8 +17392,8 @@ start_preparsed_function (tree decl1, tree attrs, int 
flags)
   gcc_assert (TREE_CHAIN (void_list_node) == NULL_TREE);
 
   tree fntype = TREE_TYPE (decl1);
-  if (TREE_CODE (fntype) == METHOD_TYPE)
-ctype = TYPE_METHOD_BASETYPE (fntype);
+  if (DECL_CLASS_SCOPE_P (decl1))
+ctype = DECL_CONTEXT (decl1);
   else
 {
   ctype = DECL_FRIEND_CONTEXT (decl1);
@@ -17424,15 +17424,13 @@ start_preparsed_function (tree decl1, tree attrs, int 
flags)
 
   /* Sometimes we don't notice that a function is a static member, and
  build a METHOD_TYPE for it.  Fix that up now.  */
-  gcc_assert (!(ctype != NULL_TREE && DECL_STATIC_FUNCTION_P (decl1)
+  gcc_assert (!(DECL_STATIC_FUNCTION_P (decl1)
&& TREE_CODE (TREE_TYPE (decl1)) == METHOD_TYPE));
 
   /* Set up current_class_type, and enter the scope of the class, if
  appropriate.  */
   if (ctype)
 push_nested_class (ctype);
-  else if (DECL_STATIC_FUNCTION_P (decl1))
-push_nested_class (DECL_CONTEXT (decl1));
 
   /* Now that we have entered the scope of the class, we must restore
  the bindings for any template parameters surrounding DECL1, if it
@@ -17469,7 +17467,7 @@ start_preparsed_function (tree decl1, tree attrs, int 
flags)
   tree newdecl1 = push_template_decl (decl1, doing_friend);
   if (newdecl1 == error_mark_node)
{
- if (ctype || DECL_STATIC_FUNCTION_P (decl1))
+ if (ctype)
pop_nested_class ();
  return false;
}
@@ -17621,7 +17619,7 @@ start_preparsed_function (tree decl1, tree attrs, int 
flags)
   /* Start the statement-tree, start the tree now.  */
   DECL_SAVED_TREE (decl1) = push_stmt_list ();
 
-  if (ctype && !doing_friend && !DECL_STATIC_FUNCTION_P (decl1))
+  if (DECL_NONSTATIC_MEMBER_FUNCTION_P (decl1))
 {
   /* We know that this was set up by `grokclassfn'.  We do not
 wait until `store_parm_decls', since evil parse errors may

base-commit: 4649c079409ec6cb67cd2cca0df81877e53c78b4
-- 
2.39.3



[PATCH] [APX PUSH2POP2] Adjust operand order for PUSH2POP2

2023-11-21 Thread Hongyu Wang
Hi,

The push2/pop2 operand order does not match the binutils implementation
for AT syntax that it will first push operands[2] then operands[1].
Correct it by reverse operand order for AT syntax.

Bootstrapped/regtested on x86-64-linux-pc-gnu{-m32,}

Ok for master?

gcc/ChangeLog:

* config/i386/i386.md (push2_di): Adjust operand order for AT
syntax.
(pop2_di): Likewise.
(push2p_di): Likewise.
(pop2p_di): Likewise.

gcc/testsuite/ChangeLog:

* gcc.target/i386/apx-push2pop2-1.c: Adjust output scan.
* gcc.target/i386/apx-push2pop2_force_drap-1.c: Likewise.
---
 gcc/config/i386/i386.md   | 8 
 gcc/testsuite/gcc.target/i386/apx-push2pop2-1.c   | 8 
 .../gcc.target/i386/apx-push2pop2_force_drap-1.c  | 8 
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 03e4ddd3037..99bb909b244 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -3772,7 +3772,7 @@ (define_insn "push2_di"
(match_operand:DI 2 "register_operand" "r")]
UNSPEC_APXPUSH2))]
   "TARGET_APX_PUSH2POP2"
-  "push2\t%1, %2"
+  "push2\t{%2, %1|%1, %2}"
   [(set_attr "mode" "TI")
(set_attr "type" "multi")
(set_attr "prefix" "evex")])
@@ -3784,7 +3784,7 @@ (define_insn "pop2_di"
  (set (match_operand:DI 2 "register_operand" "=r")
   (unspec:DI [(const_int 0)] UNSPEC_APXPOP2_HIGH))])]
   "TARGET_APX_PUSH2POP2"
-  "pop2\t%0, %2"
+  "pop2\t{%2, %0|%0, %2}"
   [(set_attr "mode" "TI")
(set_attr "prefix" "evex")])
 
@@ -3811,7 +3811,7 @@ (define_insn "push2p_di"
UNSPEC_APXPUSH2))
(unspec:DI [(const_int 0)] UNSPEC_APX_PPX)]
   "TARGET_APX_PUSH2POP2 && TARGET_APX_PPX"
-  "push2p\t%1, %2"
+  "push2p\t{%2, %1|%1, %2}"
   [(set_attr "mode" "TI")
(set_attr "type" "multi")
(set_attr "prefix" "evex")])
@@ -3824,7 +3824,7 @@ (define_insn "pop2p_di"
   (unspec:DI [(const_int 0)] UNSPEC_APXPOP2_HIGH))
  (unspec:DI [(const_int 0)] UNSPEC_APX_PPX)])]
   "TARGET_APX_PUSH2POP2 && TARGET_APX_PPX"
-  "pop2p\t%0, %2"
+  "pop2p\t{%2, %0|%0, %2}"
   [(set_attr "mode" "TI")
(set_attr "prefix" "evex")])
 
diff --git a/gcc/testsuite/gcc.target/i386/apx-push2pop2-1.c 
b/gcc/testsuite/gcc.target/i386/apx-push2pop2-1.c
index c53112758a5..d78c96d36a3 100644
--- a/gcc/testsuite/gcc.target/i386/apx-push2pop2-1.c
+++ b/gcc/testsuite/gcc.target/i386/apx-push2pop2-1.c
@@ -24,11 +24,11 @@ void foo ()
 /* { dg-final { scan-assembler-times ".cfi_def_cfa_offset 16" 2 } } */
 /* { dg-final { scan-assembler-times "pushq\[^\n\r]*%r15(?:\n|\[ \\t\]+#)" 1 } 
} */
 /* { dg-final { scan-assembler-times ".cfi_offset 15, -16(?:\n|\[ \\t\]+#)" 1 
} } */
-/* { dg-final { scan-assembler-times "push2\[\\t 
\]*\[^\n\r]*%r14\[^\n\r]*%r13\[^\n\r]*(?:\n|\[ \\t\]+#)" 1 } } */
+/* { dg-final { scan-assembler-times "push2\[\\t 
\]*\[^\n\r]*%r13\[^\n\r]*%r14\[^\n\r]*(?:\n|\[ \\t\]+#)" 1 } } */
 /* { dg-final { scan-assembler-times ".cfi_def_cfa_offset 32" 2 } } */
 /* { dg-final { scan-assembler-times ".cfi_offset 14, -24(?:\n|\[ \\t\]+#)" 1 
} } */
 /* { dg-final { scan-assembler-times ".cfi_offset 13, -32(?:\n|\[ \\t\]+#)" 1 
} } */
-/* { dg-final { scan-assembler-times "push2\[\\t 
\]*\[^\n\r]*%r12\[^\n\r]*%rbp\[^\n\r]*(?:\n|\[ \\t\]+#)" 1 } } */
+/* { dg-final { scan-assembler-times "push2\[\\t 
\]*\[^\n\r]*%rbp\[^\n\r]*%r12\[^\n\r]*(?:\n|\[ \\t\]+#)" 1 } } */
 /* { dg-final { scan-assembler-times ".cfi_def_cfa_offset 48" 2 } } */
 /* { dg-final { scan-assembler-times ".cfi_offset 12, -40(?:\n|\[ \\t\]+#)" 1 
} } */
 /* { dg-final { scan-assembler-times ".cfi_offset 6, -48(?:\n|\[ \\t\]+#)" 1 } 
} */
@@ -36,10 +36,10 @@ void foo ()
 /* { dg-final { scan-assembler-times ".cfi_def_cfa_offset 56" 2 } } */
 /* { dg-final { scan-assembler-times ".cfi_offset 3, -56(?:\n|\[ \\t\]+#)" 1 } 
} */
 /* { dg-final { scan-assembler-times "popq\[^\n\r]*rbx(?:\n|\[ \\t\]+#)" 1 } } 
*/
-/* { dg-final { scan-assembler-times "pop2\[\\t 
\]*\[^\n\r]*%rbp\[^\n\r]*%r12\[^\n\r]*(?:\n|\[ \\t\]+#)" 1 } } */
+/* { dg-final { scan-assembler-times "pop2\[\\t 
\]*\[^\n\r]*%r12\[^\n\r]*%rbp\[^\n\r]*(?:\n|\[ \\t\]+#)" 1 } } */
 /* { dg-final { scan-assembler-times ".cfi_restore 12(?:\n|\[ \\t\]+#)" 1 } } 
*/
 /* { dg-final { scan-assembler-times ".cfi_restore 6(?:\n|\[ \\t\]+#)" 1 } } */
-/* { dg-final { scan-assembler-times "pop2\[\\t 
\]*\[^\n\r]*%r13\[^\n\r]*%r14\[^\n\r]*(?:\n|\[ \\t\]+#)" 1 } } */
+/* { dg-final { scan-assembler-times "pop2\[\\t 
\]*\[^\n\r]*%r14\[^\n\r]*%r13\[^\n\r]*(?:\n|\[ \\t\]+#)" 1 } } */
 /* { dg-final { scan-assembler-times ".cfi_restore 14(?:\n|\[ \\t\]+#)" 1 } } 
*/
 /* { dg-final { scan-assembler-times ".cfi_restore 13(?:\n|\[ \\t\]+#)" 1 } } 
*/
 /* { dg-final { scan-assembler-times "popq\[^\n\r]*%r15(?:\n|\[ \\t\]+#)" 1 } 
} */
diff --git 

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

2023-11-21 Thread Jason Merrill

On 11/21/23 08:04, waffl3x wrote:

Bootstrapped and tested on x86_64-linux with no regressions.

Hopefully this patch is legible enough for reviewing purposes, I've not
been feeling the greatest so it was a task to get this finished.
Tomorrow I will look at putting the diagnostics in
start_preparsed_function and also fixing up anything else.

To reiterate in case it wasn't abundantly clear by the barren changelog
and commit message, this version is not intended as the final revision.

Handling re-declarations was kind of nightmarish, so the comments in
there are lengthy, but I am fairly certain I implemented them correctly.

I am going to get some sleep now, hopefully I will feel better tomorrow
and be ready to polish off the patch. Thanks for the patience.


Great!


I stared at start_preparsed_function for a long while and couldn't
figure out where to start off at. So for now the error handling is
split up between instantiate_body and cp_parser_lambda_declarator_opt.
The latter is super not correct but I've been stuck on this for a long
time now though so I wanted to actually get something that works and
then try to make it better.


I see what you mean, instantiate body isn't prepared for 
start_preparsed_function to fail.  It's ok to handle this in two places.
Though actually, instantiate_body is too late for it to fail; I think 
for the template case it should fail in tsubst_lambda_expr, before we 
even start to consider the body.


Incidentally, I notice this code in tsubst_function_decl seems to need 
adjusting for xobj:


  tree parms = DECL_ARGUMENTS (t);
  if (closure && !DECL_STATIC_FUNCTION_P (t))
parms = DECL_CHAIN (parms);
  parms = tsubst (parms, args, complain, t);
  for (tree parm = parms; parm; parm = DECL_CHAIN (parm))
DECL_CONTEXT (parm) = r;
  if (closure && !DECL_STATIC_FUNCTION_P (t))
...

and this in tsubst_lambda_expr that assumes iobj:

  /* Fix the type of 'this'.  */
  fntype = build_memfn_type (fntype, type,
 type_memfn_quals (fntype),
 type_memfn_rqual (fntype));

This also seems like the place to check for unrelated type.


 /* Nonzero for FUNCTION_DECL means that this decl is a non-static
-   member function.  */
+   member function, use DECL_IOBJ_MEMBER_FUNC_P instead.  */
 #define DECL_NONSTATIC_MEMBER_FUNCTION_P(NODE) \
   (TREE_CODE (TREE_TYPE (NODE)) == METHOD_TYPE)
 
+/* Nonzero for FUNCTION_DECL means that this decl is an implicit object

+   member function.  */
+#define DECL_IOBJ_MEMBER_FUNC_P(NODE) \
+  (TREE_CODE (TREE_TYPE (NODE)) == METHOD_TYPE)


I was thinking to rename DECL_NONSTATIC_MEMBER_FUNCTION_P rather than 
add a new, equivalent one.  And then go through all the current uses of 
the old macro to decide whether they mean IOBJ or OBJECT.



-   (static or non-static).  */
+   (static or object).  */


Let's leave this comment as it was.


+  auto handle_arg = [fn, flags, complain](tree type,
+ tree arg,
+ int const param_index,
+ conversion *conv,
+ bool const conversion_warning)


Let's move the conversion_warning logic into the handle_arg lambda 
rather than have it as a parameter.  Yes, we don't need it for the xobj 
parm, but I think it's cleaner to have less in the loop.


Also, let's move handle_arg after the iobj 'this' handling so it's 
closer to the uses.  For which the 'else xobj' needs to drop the 'else', 
or change to 'if (first_arg)'.



+  /* We currently handle for the case where first_arg is NULL_TREE
+in the future this should be changed and the assert reactivated.  */
+  #if 0
+  gcc_assert (first_arg);
+  #endif


Let's leave this out.


+  val = handle_arg(TREE_VALUE (parm),


Missing space before (.


-  if (null_node_p (arg)
-  && DECL_TEMPLATE_INFO (fn)
-  && cand->template_decl
- && !cand->explicit_targs)
-conversion_warning = false;
-
+  auto determine_conversion_warning = [&]()
+   {
+ return !(null_node_p (current_arg)
+   && DECL_TEMPLATE_INFO (fn)
+   && cand->template_decl
+   && !cand->explicit_targs);
+   };


I don't think this needs to be a lambda.


+declaration, then the type of it's object parameter is still

...

+but due to [basic.scope.scope.3] we need to ignore it's

...

+   /* Since a valid xobj parm has it's purpose cleared in 
find_xobj_parm


"its"


-  if (DECL_NONSTATIC_MEMBER_FUNCTION_P (fn)
-  && !(complain & tf_ptrmem_ok) && !flag_ms_extensions)
+  if (DECL_OBJECT_MEMBER_FUNC_P (fn)
+  && !(complain & tf_ptrmem_ok))


The following code (not quoted) could share more code between the cases 
if we check


!(flag_ms_extensions && DECL_IOBJ_MEMBER_FUNC_P (fn))

here?


+   else if (declarator->declarator->kind 

[PATCH] Fix gcc.target/aarch64/movk.c testcase after IPA-VRP improvement for return values

2023-11-21 Thread Andrew Pinski
This fixes the testcase.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/movk.c: Add noipa on dummy_number_generator
and remove -fno-inline option.

Signed-off-by: Andrew Pinski 
---
 gcc/testsuite/gcc.target/aarch64/movk.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/movk.c 
b/gcc/testsuite/gcc.target/aarch64/movk.c
index e6e4e3a8961..1fa11540c6c 100644
--- a/gcc/testsuite/gcc.target/aarch64/movk.c
+++ b/gcc/testsuite/gcc.target/aarch64/movk.c
@@ -1,8 +1,11 @@
 /* { dg-do run } */
-/* { dg-options "-O2 --save-temps -fno-inline" } */
+/* { dg-options "-O2 --save-temps" } */
 
 extern void abort (void);
 
+/* Note GCC can optimize this to -346565474575675 even without inlining so
+   mark it for noipa.  */
+[[gnu::noipa]]
 long long int
 dummy_number_generator ()
 {
-- 
2.34.1



[PATCH] Fix gcc.target/aarch64/movk.c testcase after IPA-VRP improvement for return values

2023-11-21 Thread Andrew Pinski
This fixes the testcase.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/movk.c: Add noipa on dummy_number_generator
and remove -fno-inline option.

Signed-off-by: Andrew Pinski 
---
 gcc/testsuite/gcc.target/aarch64/movk.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/movk.c 
b/gcc/testsuite/gcc.target/aarch64/movk.c
index e6e4e3a8961..1fa11540c6c 100644
--- a/gcc/testsuite/gcc.target/aarch64/movk.c
+++ b/gcc/testsuite/gcc.target/aarch64/movk.c
@@ -1,8 +1,11 @@
 /* { dg-do run } */
-/* { dg-options "-O2 --save-temps -fno-inline" } */
+/* { dg-options "-O2 --save-temps" } */
 
 extern void abort (void);
 
+/* Note GCC can optimize this to -346565474575675 even without inlining so
+   mark it for noipa.  */
+[[gnu::noipa]]
 long long int
 dummy_number_generator ()
 {
-- 
2.34.1



RE: [PATCH v4] DSE: Allow vector type for get_stored_val when read < store

2023-11-21 Thread Li, Pan2
Hi Richard S,

Thanks a lot for reviewing and comments. May I know is there any concern or 
further comments for landing this patch to GCC-14?

Pan

-Original Message-
From: Li, Pan2 
Sent: Wednesday, November 15, 2023 8:25 AM
To: gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Wang, Yanzhang ; 
kito.ch...@gmail.com; richard.guent...@gmail.com; richard.sandif...@arm.com; 
Jeff Law 
Subject: RE: [PATCH v4] DSE: Allow vector type for get_stored_val when read < 
store

Sorry for disturbing, looks I have a typo for Richard S's email address, cc the 
right email address for awareness.

Pan

-Original Message-
From: Li, Pan2 
Sent: Wednesday, November 15, 2023 8:18 AM
To: Jeff Law ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Wang, Yanzhang ; 
kito.ch...@gmail.com; richard.guent...@gmail.com; richard.sandiford@arm.com2
Subject: RE: [PATCH v4] DSE: Allow vector type for get_stored_val when read < 
store

> I wouldn't try to handle that case unless we had actual evidence it was 
> useful to do so.  Just wanted to point out that unlike pseudos we can 
> have multiple modes referencing the same memory location.

Got the point here, thanks Jeff for emphasizing this, .

Pan

-Original Message-
From: Jeff Law  
Sent: Tuesday, November 14, 2023 4:12 AM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Wang, Yanzhang ; 
kito.ch...@gmail.com; richard.guent...@gmail.com; richard.sandiford@arm.com2
Subject: Re: [PATCH v4] DSE: Allow vector type for get_stored_val when read < 
store



On 11/12/23 20:22, pan2...@intel.com wrote:
> From: Pan Li 
> 
> Update in v4:
> * Merge upstream and removed some independent changes.
> 
> Update in v3:
> * Take known_le instead of known_lt for vector size.
> * Return NULL_RTX when gap is not equal 0 and not constant.
> 
> Update in v2:
> * Move vector type support to get_stored_val.
> 
> Original log:
> 
> This patch would like to allow the vector mode in the
> get_stored_val in the DSE. It is valid for the read
> rtx if and only if the read bitsize is less than the
> stored bitsize.
> 
> Given below example code with
> --param=riscv-autovec-preference=fixed-vlmax.
> 
> vuint8m1_t test () {
>uint8_t arr[32] = {
>  1, 2, 7, 1, 3, 4, 5, 3, 1, 0, 1, 2, 4, 4, 9, 9,
>  1, 2, 7, 1, 3, 4, 5, 3, 1, 0, 1, 2, 4, 4, 9, 9,
>};
> 
>return __riscv_vle8_v_u8m1(arr, 32);
> }
> 
> Before this patch:
> test:
>lui a5,%hi(.LANCHOR0)
>addisp,sp,-32
>addia5,a5,%lo(.LANCHOR0)
>li  a3,32
>vl2re64.v   v2,0(a5)
>vsetvli zero,a3,e8,m1,ta,ma
>vs2r.v  v2,0(sp) <== Unnecessary store to stack
>vle8.v  v1,0(sp) <== Ditto
>vs1r.v  v1,0(a0)
>addisp,sp,32
>jr  ra
> 
> After this patch:
> test:
>lui a5,%hi(.LANCHOR0)
>addia5,a5,%lo(.LANCHOR0)
>li  a4,32
>addisp,sp,-32
>vsetvli zero,a4,e8,m1,ta,ma
>vle8.v  v1,0(a5)
>vs1r.v  v1,0(a0)
>addisp,sp,32
>jr  ra
> 
> Below tests are passed within this patch:
> * The risc-v regression test.
> * The x86 bootstrap and regression test.
> * The aarch64 regression test.
> 
>   PR target/111720
> 
> gcc/ChangeLog:
> 
>   * dse.cc (get_stored_val): Allow vector mode if read size is
>   less than or equal to stored size.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/riscv/rvv/base/pr111720-0.c: New test.
>   * gcc.target/riscv/rvv/base/pr111720-1.c: New test.
>   * gcc.target/riscv/rvv/base/pr111720-10.c: New test.
>   * gcc.target/riscv/rvv/base/pr111720-2.c: New test.
>   * gcc.target/riscv/rvv/base/pr111720-3.c: New test.
>   * gcc.target/riscv/rvv/base/pr111720-4.c: New test.
>   * gcc.target/riscv/rvv/base/pr111720-5.c: New test.
>   * gcc.target/riscv/rvv/base/pr111720-6.c: New test.
>   * gcc.target/riscv/rvv/base/pr111720-7.c: New test.
>   * gcc.target/riscv/rvv/base/pr111720-8.c: New test.
>   * gcc.target/riscv/rvv/base/pr111720-9.c: New test.
OK for the trunk.


> 

> +  else if (VECTOR_MODE_P (read_mode) && VECTOR_MODE_P (store_mode)
> +&& known_le (GET_MODE_BITSIZE (read_mode), GET_MODE_BITSIZE (store_mode))
> +&& targetm.modes_tieable_p (read_mode, store_mode))
> +read_reg = gen_lowpart (read_mode, copy_rtx (store_info->rhs));
> else
>   read_reg = extract_low_bits (read_mode, store_mode,
>copy_rtx (store_info->rhs));
It may not matter, especially for RV, but we could possibly have a 
mixture of scalar and vector modes in the RTL.  Say a vector store 
followed by a scalar read or vice-versa.

I wouldn't try to handle that case unless we had actual evidence it was 
useful to do so.  Just wanted to point out that unlike pseudos we can 
have multiple modes referencing the same memory location.

Jeff


Re: [PING^2][PATCH RFA] PR target/111815: VAX: Only accept the index scaler as the RHS operand to ASHIFT

2023-11-21 Thread Maciej W. Rozycki
On Mon, 13 Nov 2023, Jeff Law wrote:

> > >   The testcase is generic enough I thought it wouldn't hurt to place it in
> > > a generic part of the testsuite, where it has been verified to pass with
> > > the `powerpc64le-linux-gnu', `riscv64-linux-gnu', and `vax-netbsdelf'
> > > targets.  I'm fine to move it to the VAX part of the testsuite though if
> > > there's disagreement as to my choice.  Otherwise OK to apply for this
> > > part?
> > 
> >   Ping for:
> > .
> OK.  I'm fully supportive of generic tests :-)

 Thank you for the review.  I have now committed the fix and backported it 
to GCC 13/12/11.

  Maciej


Re: [PATCH] testsuite: Fix subexpressions with `scan-assembler-times'

2023-11-21 Thread Maciej W. Rozycki
On Sun, 19 Nov 2023, Jeff Law wrote:

> >   Verified with the `riscv64-linux-gnu' target and the C language
> > testsuite.  OK to apply?
> Not sure why it is the way it is -- I walked back to Zdenek's change which
> introduced the scan-assembler-times and nothing about the -inline argument.

 I went through our history beforehand too and found nothing interesting 
either.  My only suspicion has been it may have happened as a conseqence 
of somewhat confusing regexp(n) TCL documentation just saying:

"Determines whether the regular expression exp matches part or all of 
string and returns 1 if it does, 0 if it does not, unless -inline is 
specified (see below)."

and then you need to dive into the description of `-all' to find out it 
actually returns the number of matches rather than just 1 or 0:

"Causes the regular expression to be matched as many times as possible in 
the string, returning the total number of matches found."

I guess maybe Zdenek missed the part after the comma?

> OK, but be on the lookout for scan-asm problems on other targets over the next
> few days.

 Good point.  I have grepped our testsuite for instances and found only 
one (as opposed to numerous non-captured subexpressions), specifically 
gcc/testsuite/gcc.target/arm/pr53447-5.c, well-documented as working 
around the quirk.  I've posted a change to avoid the quirk with this case: 
 and 
I mean to apply it just before this `scan-assembler-times' fix.

  Maciej


[PATCH] testsuite: Tweak xfail bogus g++.dg/warn/Wstringop-overflow-4.C:144, PR106120

2023-11-21 Thread Hans-Peter Nilsson
I added that xfail in February for { ilp32 && c++98_only } and it
looks like it's moved on to lp64 now. :-/  Noted by Rainer
Orth, see the PR.

Tested cris-elf and x86_64-pc-linux-gnu w/wo. -m32.
Ok to commit?

-- >8 --
The conditions under which this this bogus warning is
emitted has changed to not happen for 32-bit targets
anymore.  Adjust accordingly.

PR testsuite/106120
* g++.dg/warn/Wstringop-overflow-4.C:144 XFAIL bogus warning for
lp64 targets with c++98.
---
 gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C 
b/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C
index 275ecac01b5f..2024f8d93ca3 100644
--- a/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C
+++ b/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C
@@ -141,7 +141,7 @@ void test_strcpy_new_int16_t (size_t n, const size_t vals[])
 
   int r_imin_imax = SR (INT_MIN, INT_MAX);
   T (S (1), new int16_t[r_imin_imax]);
-  T (S (2), new int16_t[r_imin_imax + 1]); // { dg-bogus "into a region of 
size" "pr106120" { xfail { c++98_only } } }
+  T (S (2), new int16_t[r_imin_imax + 1]); // { dg-bogus "into a region of 
size" "pr106120" { xfail { lp64 && c++98_only } } }
   T (S (9), new int16_t[r_imin_imax * 2 + 1]);
 
   int r_0_imax = SR (0, INT_MAX);
-- 
2.30.2



[PATCH] ARM/testsuite: Use non-capturing parentheses with pr53447-5.c

2023-11-21 Thread Maciej W. Rozycki
Use non-capturing parentheses for the subexpressions used with 
`scan-assembler-times', to avoid a quirk with double-counting.

gcc/testsuite/
* gcc.target/arm/pr53447-5.c: Use non-capturing parentheses with 
`scan-assembler-times'.
---
Hi,

 The `scan-assembler-times' quirk is being fixed with
, but 
we don't need capturing parentheses here, typically used for back 
references, so let's just avoid the quirk altogether and make our matching 
here work either way.  Cf. commit 88c888f11379 ("pr53447-5.c: Fix test 
expectations for neon-fpu.").

 Verified by proof-reading, with a reference to the commit quoted above.  
OK to apply?

  Maciej
---
 gcc/testsuite/gcc.target/arm/pr53447-5.c |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

gcc-arm-test-pr53447-5-non-capturing.diff
Index: gcc/gcc/testsuite/gcc.target/arm/pr53447-5.c
===
--- gcc.orig/gcc/testsuite/gcc.target/arm/pr53447-5.c
+++ gcc/gcc/testsuite/gcc.target/arm/pr53447-5.c
@@ -15,8 +15,6 @@ void foo(long long* p)
   p[9] -= p[10];
 }
 
-/* We accept neon instructions vldr.64 and vstr.64 as well.
-   Note: DejaGnu counts patterns with alternatives twice,
-   so actually there are only 10 loads and 9 stores.  */
-/* { dg-final { scan-assembler-times "(ldrd|vldr\\.64)" 20 } } */
-/* { dg-final { scan-assembler-times "(strd|vstr\\.64)" 18 } } */
+/* We accept neon instructions vldr.64 and vstr.64 as well.  */
+/* { dg-final { scan-assembler-times "(?:ldrd|vldr\\.64)" 10 } } */
+/* { dg-final { scan-assembler-times "(?:strd|vstr\\.64)" 9 } } */


Re: [PATCH 40/44] RISC-V: Handle FP NE operator via inversion in cond-operation expansion

2023-11-21 Thread Maciej W. Rozycki
On Sun, 19 Nov 2023, Jeff Law wrote:

> > gcc/
> > * config/riscv/riscv-protos.h (riscv_expand_float_scc): Add
> > `invert_ptr' parameter.
> > * config/riscv/riscv.cc (riscv_emit_float_compare): Add NE
> > inversion handling.
> > (riscv_expand_float_scc): Pass `invert_ptr' through to
> > `riscv_emit_float_compare'.
> > (riscv_expand_conditional_move): Pass `' to
> > `riscv_expand_float_scc'.
> > * config/riscv/riscv.md (addcc): Likewise.
> This and the rest of the patches (41, 42, 43, 44) in this series are OK.

 I have committed the whole patch set now, thank you for your review.  
I'll address the concerns raised in the course separately.

  Maciej


Re: [PATCH 01/44] testsuite: Add cases for conditional-move and conditional-add operations

2023-11-21 Thread Maciej W. Rozycki
On Mon, 20 Nov 2023, Richard Biener wrote:

> > > ok
> >
> >  Thank you for your review, but I think I need a general maintainer's ack
> > for this one.
> 
> OK.

 I have committed this change now, thank you for your review.

  Maciej


Re: [PATCH] RISC-V: Remove duplicate `order_operator' predicate

2023-11-21 Thread Maciej W. Rozycki
On Sun, 19 Nov 2023, Jeff Law wrote:

> >   Verified with the `riscv64-linux-gnu' target and the C language
> > testsuite.  OK to apply?
> OK

 Applied now, thank you for your review.

  Maciej


Re: [PATCH] mingw: Exclude utf8 manifest [PR111170, PR108865]

2023-11-21 Thread Jonathan Yong

On 11/21/23 18:07, Costas Argyris wrote:

This patch makes the inclusion of the utf8 manifest on the
mingw hosts optional by introducing the configure option
--disable-win32-utf8-manifest (has no effect on non-mingw
hosts).

Bootstrapped OK on i686-w64-mingw32 and x86_64-w64-mingw32
with and without --disable-win32-utf8-manifest.

Costas



I would prefer a AC_ARG_ENABLE to document the option in configure.ac, 
so it would show with configure --help. It should set new variables to 
i386/x-mingw32-utf8, utf8rc-mingw32.o and utf8-mingw32.o respectively 
unless disabled, like so:


host_xmake_mingw=i386/x-mingw32-utf8
host_extra_gcc_objs_mingw=utf8rc-mingw32.o
host_extra_objs=utf8-mingw32.o

And then entries in config.host would be:


  i[34567]86-*-mingw32* | x86_64-*-mingw*)
host_xm_file=i386/xm-mingw32.h
host_xmake_file="${host_xmake_file} ${host_xmake_mingw} i386/x-mingw32"
host_extra_gcc_objs="${host_extra_gcc_objs} ${host_extra_gcc_objs_mingw} driver-mingw32. 
> host_extra_objs="${host_extra_objs} ${host_extra_objs_mingw}"




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

2023-11-21 Thread LIU Hao

在 2023/11/22 03:35, Björn Schäpers 写道:
I'll guess it is not needed here, but otherwise  defines the macros max and min, they 
then conflict e.g. with C++'s std::max/std::min. So I consider it best practice to always define it, 
before including .


The mingw-w64 header does not define them for C++ [1] and GCC defines `NOMINMAX` in 'os_defines.h', 
so either way it is not necessary.



[1] 
https://github.com/mingw-w64/mingw-w64/blob/3ebb92804e3125d1be8f61bcd42f15a8db15ba1e/mingw-w64-headers/include/minmax.h#L9




--
Best regards,
LIU Hao



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: [PATCH] RISC-V: testsuite: Remove redundant vector_hw and zvfh_hw.

2023-11-21 Thread juzhe.zh...@rivai.ai
I don't get it. Why do we need remove them ? 



juzhe.zh...@rivai.ai
 
From: Robin Dapp
Date: 2023-11-22 03:43
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: testsuite: Remove redundant vector_hw and zvfh_hw.
Hi,
 
this removes the now-redundant vector_hw and zvfh_hw checks in the
testsuite.
 
Regards
Robin
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/autovec/binop/copysign-zvfh-run.c:
Remove zvfh_hw.
* gcc.target/riscv/rvv/autovec/binop/vadd-zvfh-run.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vdiv-zvfh-run.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vmax-zvfh-run.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vmin-zvfh-run.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vmul-zvfh-run.c: Ditto.
* gcc.target/riscv/rvv/autovec/cond/cond_copysign-zvfh-run.c:
Ditto.
* gcc.target/riscv/rvv/autovec/struct/struct_vect_run-10.c:
Ditto.
* gcc.target/riscv/rvv/autovec/struct/struct_vect_run-6.c: Allow
overriding N.
* gcc.target/riscv/rvv/autovec/unop/abs-zvfh-run.c: Remove
zvfh_hw.
* gcc.target/riscv/rvv/autovec/unop/vneg-zvfh-run.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-10.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-11.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-12.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-5.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-6.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-7.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-8.c: Ditto.
* lib/target-supports.exp: Ditto.
---
.../rvv/autovec/binop/copysign-zvfh-run.c |  2 +-
.../riscv/rvv/autovec/binop/vadd-zvfh-run.c   |  2 +-
.../riscv/rvv/autovec/binop/vdiv-zvfh-run.c   |  2 +-
.../riscv/rvv/autovec/binop/vmax-zvfh-run.c   |  2 +-
.../riscv/rvv/autovec/binop/vmin-zvfh-run.c   |  2 +-
.../riscv/rvv/autovec/binop/vmul-zvfh-run.c   |  2 +-
.../rvv/autovec/cond/cond_copysign-zvfh-run.c |  2 +-
.../rvv/autovec/struct/struct_vect_run-10.c   |  5 +-
.../rvv/autovec/struct/struct_vect_run-6.c|  2 +
.../riscv/rvv/autovec/unop/abs-zvfh-run.c |  2 +-
.../riscv/rvv/autovec/unop/vneg-zvfh-run.c|  2 +-
.../rvv/autovec/widen/widen_run_zvfh-1.c  |  2 +-
.../rvv/autovec/widen/widen_run_zvfh-10.c |  2 +-
.../rvv/autovec/widen/widen_run_zvfh-11.c |  2 +-
.../rvv/autovec/widen/widen_run_zvfh-12.c |  2 +-
.../rvv/autovec/widen/widen_run_zvfh-2.c  |  2 +-
.../rvv/autovec/widen/widen_run_zvfh-3.c  |  2 +-
.../rvv/autovec/widen/widen_run_zvfh-5.c  |  2 +-
.../rvv/autovec/widen/widen_run_zvfh-6.c  |  2 +-
.../rvv/autovec/widen/widen_run_zvfh-7.c  |  2 +-
.../rvv/autovec/widen/widen_run_zvfh-8.c  |  2 +-
gcc/testsuite/lib/target-supports.exp | 51 +--
22 files changed, 26 insertions(+), 70 deletions(-)
 
diff --git 
a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/copysign-zvfh-run.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/copysign-zvfh-run.c
index 3bf64ab72ef..e71b6589fc3 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/copysign-zvfh-run.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/copysign-zvfh-run.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { riscv_v && riscv_zvfh_hw } } } */
+/* { dg-do run { target { riscv_v && riscv_zvfh } } } */
/* { dg-additional-options "-std=c99 -fno-vect-cost-model 
--param=riscv-autovec-preference=fixed-vlmax -ffast-math" } */
#include "copysign-template.h"
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vadd-zvfh-run.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vadd-zvfh-run.c
index 2a8618ad09b..6c2d096e103 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vadd-zvfh-run.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vadd-zvfh-run.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { riscv_v && riscv_zvfh_hw } } } */
+/* { dg-do run { target { riscv_v && riscv_zvfh } } } */
/* { dg-additional-options "-std=c99 -fno-vect-cost-model 
--param=riscv-autovec-preference=fixed-vlmax -ffast-math" } */
#include "vadd-template.h"
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vdiv-zvfh-run.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vdiv-zvfh-run.c
index 1b8e69259ca..c9f9d83ccb8 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vdiv-zvfh-run.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vdiv-zvfh-run.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { riscv_v && riscv_zvfh_hw } } } */
+/* { dg-do run { target { riscv_v && riscv_zvfh } } } */
/* { dg-additional-options "-std=c99 -fno-vect-cost-model 
--param=riscv-autovec-preference=fixed-vlmax -ffast-math" } */
#include "vdiv-template.h"
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vmax-zvfh-run.c 

Re: [PATCH] gcc.misc-tests/linkage-y.c: Compatibility with C99+ system compilers

2023-11-21 Thread Joseph Myers
On Tue, 21 Nov 2023, Florian Weimer wrote:

> This program is compiled with an installed "cc" compiler, not the
> built GCC compiler, so it should be as compatible as possible across a
> wide range of compilers.
> 
> gcc/testsuite/
> 
>   * gcc.misc-tests/linkage-y.c (puts): Declare.
>   (main): Add int return type and return 0.

OK.

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


Re: [PATCH 0/4] v2 of Option handling: add documentation URLs

2023-11-21 Thread Joseph Myers
On Tue, 21 Nov 2023, Tobias Burnus wrote:

> On 21.11.23 14:57, David Malcolm wrote:
> > On Tue, 2023-11-21 at 02:09 +0100, Hans-Peter Nilsson wrote:
> > > Sorry for barging in though I did try finding the relevant
> > > discussion, but is committing this generated stuff necessary?
> > > Is it because we don't want to depend on Python being
> > > present at build time?
> > Partly, yes, [...]
> 
> I wonder how to ensure that this remains up to date. Should there be an
> item at
> 
> https://gcc.gnu.org/branching.html and/or
> https://gcc.gnu.org/releasing.html similar to the .pot generation?

My suggestion earlier in the discussion was that it should be added to the 
post-commit CI discussed starting at 
 (I think 
that CI is now in operation).  These are generated files that ought to be 
kept up to date with each commit that affects .opt files, unlike the .pot 
files where the expectation is that they should be up to date for releases 
and updated from time to time at other times for submission to the TP.

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


Re: [PATCH] c: Add __builtin_stdc_bit_{width,floor,ceil} builtins

2023-11-21 Thread Joseph Myers
On Mon, 20 Nov 2023, Jakub Jelinek wrote:

> > Note that stdc_bit_ceil now has defined behavior (return 0) on overflow: 
> > CD2 comment FR-135 was accepted for the DIS at the June WG14 meeting.  
> > This affects both the documentation and the implementation, as they need 
> > to avoid an undefined shift by the width of the type.  That's why my 
> > stdbit.h implementations have two shifts (not claiming that's necessarily 
> > the optimal way of ensuring the correct result in the overflow case).
> > 
> >   return __x <= 1 ? 1 : ((uint64_t) 1) << (__bw64_inline (__x - 1) - 1) << 
> > 1;
> 
> So
>   return __x <= 1 ? 1 : ((uint64_t) 2) << (__bw64_inline (__x - 1) - 1);
> then?

Yes, that looks better than my version, thanks.

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


[PATCH 2/2] testsuite/unroll-8: Disable vectorization for varibale-factor targets

2023-11-21 Thread Palmer Dabbelt
The vectorizer picks up these loops and disables unrolling on targets
with variable vector factors.  That result in better code here, but it
trips up the unrolling tests.  So just disable vectorization for these.

gcc/testsuite/ChangeLog:

PR target/112531
* gcc.dg/unroll-8.c: Disable vectorization on arm64 and riscv.
---
This also isn't tested.
---
 gcc/testsuite/gcc.dg/unroll-8.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/gcc/testsuite/gcc.dg/unroll-8.c b/gcc/testsuite/gcc.dg/unroll-8.c
index 06d32e56893..4465c620800 100644
--- a/gcc/testsuite/gcc.dg/unroll-8.c
+++ b/gcc/testsuite/gcc.dg/unroll-8.c
@@ -1,6 +1,15 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fdump-rtl-loop2_unroll-details-blocks -funroll-loops" } 
*/
+
+/*
+ * Targets that support variable-length vectorization don't unroll loops (see
+ * the "Disabling unrolling due to variable-length vectorization factor" out in
+ * tree-vect-loop.  So disable tree vectorization for these targets, as it will
+ * interfere with the unrolling we're looking for below.
+ */
+/* { dg-additional-options "-fno-tree-vectorize" { target aarch64-*-* } } */
 /* { dg-additional-options "-fno-tree-vectorize" { target amdgcn-*-* } } */
+/* { dg-additional-options "-fno-tree-vectorize" { target riscv*-*-* } } */
 
 struct a {int a[7];};
 void t(struct a *a, int n)
-- 
2.42.1



[PATCH 1/2] testsuite/unroll-8: Avoid triggering undefined behavior

2023-11-21 Thread Palmer Dabbelt
I was poking around with this test failure and noticed it was exercising
undefined behavior.  The return type doesn't matter for what's being
tested, so just mark it as void.

gcc/testsuite/ChangeLog:

* gcc.dg/unroll-8.c: Remove UB.
---
I didn't tes this, but it seems trivial enough that I'm just going to
throw it at the bots and hope I'm right.
---
 gcc/testsuite/gcc.dg/unroll-8.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/unroll-8.c b/gcc/testsuite/gcc.dg/unroll-8.c
index 4388f47d4c7..06d32e56893 100644
--- a/gcc/testsuite/gcc.dg/unroll-8.c
+++ b/gcc/testsuite/gcc.dg/unroll-8.c
@@ -3,7 +3,7 @@
 /* { dg-additional-options "-fno-tree-vectorize" { target amdgcn-*-* } } */
 
 struct a {int a[7];};
-int t(struct a *a, int n)
+void t(struct a *a, int n)
 {
   int i;
   for (i=0;i

Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime

2023-11-21 Thread Iain Sandoe
Hi Simon,

Thanks for persevering - I will keep the original patch, pending some chance to
fix the earlier OS issues.

I’ll check this on OS versions with older SDKs that do not have the TARGET_OS_XX
conditionals.

-

One small nit below,

Iain

> On 21 Nov 2023, at 20:25, Simon Wright  wrote:
> 
> On 21 Nov 2023, at 11:22, Iain Sandoe  wrote:
>> 
>> Hello Simon, Arno,
>> 
>>> On 17 Nov 2023, at 13:43, Simon Wright  wrote:
>>> 
 
> Apple’s naming is definitely confusing in this area!
> 
> In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS 
> X variant, 
> which covers OSX, IOS, Watch … ; to determine which kind of device, you 
> have to check the 
> specific define for that device - OSX corresponds to macOS, i.e. laptops, 
> desktops.
> 
> In older SDKs (specifically Xcode 3, for macOS Leopard (darwin 9) as 
> mentioned by Iain) 
> TARGET_OS_MAC means code is being generated for "Mac OS", i.e. laptops, 
> desktops as 
> above; TARGET_OS_OSX is undefined (as are TARGET_OS_IOS etc).
> 
> If we are compiling for macOS, using a current macOS SDK, then 
> TARGET_OS_MAC is
> set to 1 and TARGET_OS_OSX is set to 1. 
> 
> If we were compiling for iOS, using a current iOS SDK as supplied with 
> current Xcode, then 
> TARGET_OS_MAC would be set to 1, TARGET_OS_OSX would be set to 0, and 
> TARGET_OS_IOS would be set to 1.
 
 OK so then the following is sufficient for our needs:
 
 #elif defined (__APPLE__)
 /* By default, macOS volumes are case-insensitive, iOS
volumes are case-sensitive.  */
 #if TARGET_OS_IOS
  file_names_case_sensitive_cache = 1;
 #else
  file_names_case_sensitive_cache = 0;
 #endif
 #else /* Neither Windows nor Apple.  */
  file_names_case_sensitive_cache = 1;
 #endif
 
 We want the default to be 0, and we only care about setting it to 1 on iOS 
 for recent
 SDKs, the case of an old SDK and iOS isn't interesting at this stage, so 
 it's fine if we set
 the var to 0 in this scenario.
>>> 
>>> I can’t speak for Darwin maintainers, so I’ll leave it to Iain to comment 
>>> on this suggestion.
>> 
>> * We are far away from having support for watchOS (32b Arm64) so I think 
>> that is a bridge
>> that can be crossed later.
>> 
>> * It seems to me that the proposed solution is better matched to the 
>> defaults on macOS/iOS.
>> 
>> * It would be better to have an automatic solution for folks (like me) who 
>> do use case-
>> sensitive file systems on macOS, but we do not have the resources right now 
>> to figure
>> out what is not working on the earlier systems.  I looked briefly, and found 
>> that the libcalls
>> are thin wrappers on a syscall, so that the different behaviours we are 
>> seeing on earlier
>> OS versions reflects the kernel’s handling of the provided path, rather than 
>> some improvement
>> in newer library functions.  That suggests to me that we will need to wrap 
>> the call in some more
>> complex logic to obtain the correct response.
>> 
>> So, I think that (with a test across the range of supported OS versions) the 
>> proposed
>> solution is an incremental improvement and we should take it.
>> 
>> When there’s a final proposed patch, I can add it into my testing across the 
>> systems.
>> 
>> Iain
> 
> Herewith my proposed patch (still in thread, though the subject of the thread 
> isn’t still appropriate):
> 
> In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current
> assumption for __APPLE__ is that file names are case-insensitive
> unless __arm__ or __arm64__ are defined, in which case file names are
> declared case-sensitive.
> 
> The associated comment is
>   "By default, we suppose filesystems aren't case sensitive on
>   Windows and Darwin (but they are on arm-darwin)."
> 
> This means that on aarch64-apple-darwin, file names are treated as
> case-sensitive, which is not the default case.
> 
> The true default position is that macOS file systems are
> case-insensitive, iOS file systems are case-sensitive.
> 
> Apple provide a header file  which permits a
> compile-time check for the compiler target (e.g. OSX vs IOS); if
> TARGET_OS_IOS is defined as 1, this is a build for iOS.
> 
> gcc/ada/Changelog:
> 
> 2023-11-21 Simon Wright 
> 
>   * gcc/ada/adaint.c (__gnat_get_file_names_case_sensitive):
>   Split out the __APPLE__ check and remove the checks for __arm__,
>   __arm64__.
>   For Apple, file names are by default case-insensitive unless
>   TARGET_OS_IOS is set.
> 
> Signed-off-by: Simon Wright 
> ---
>  gcc/ada/adaint.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
> index bb4ed2607e5..0222791ed68 100644
> --- a/gcc/ada/adaint.c
> +++ b/gcc/ada/adaint.c
> @@ -84,7 +84,7 @@
>  #endif /* VxWorks */
>  
>  #if defined (__APPLE__)
> -#include 

If 

Re: [PATCH]AArch64 Add pattern for unsigned widenings (uxtl) to zip{1, 2}

2023-11-21 Thread Andrew Pinski
On Tue, Nov 21, 2023 at 2:43 PM Andrew Pinski  wrote:
>
> On Wed, Nov 15, 2023 at 6:42 AM Tamar Christina  
> wrote:
> >
> > Hi All,
> >
> > This changes unpack instructions to use zip{1,2} when doing a zero-extending
> > widening operation.  Permutes generally have a higher throughput than the
> > widening operations. Zeros are shuffled into the top half of the registers.
> >
> > The testcase
> >
> > void d2 (unsigned * restrict a, unsigned short *b, int n)
> > {
> > for (int i = 0; i < (n & -8); i++)
> >   a[i] = b[i];
> > }
> >
> > now generates:
> >
> > moviv1.4s, 0
> > .L3:
> > ldr q0, [x1], 16
> > zip1v2.8h, v0.8h, v1.8h
> > zip2v0.8h, v0.8h, v1.8h
> > stp q2, q0, [x0]
> > add x0, x0, 32
> > cmp x1, x2
> > bne .L3
> >
> >
> > instead of:
> >
> > .L3:
> > ldr q0, [x1], 16
> > uxtlv1.4s, v0.4h
> > uxtl2   v0.4s, v0.8h
> > stp q1, q0, [x0]
> > add x0, x0, 32
> > cmp x1, x2
> > bne .L3
> >
> > Since we need the extra 0 register we do this only for the vectorizer's 
> > lo/hi
> > pairs when we know the 0 will be floated outside of the loop.
> >
> > This gives an 8% speed-up in Imagick in SPECCPU 2017 on Neoverse V2.
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> >
> > Ok for master?
> >
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > * config/aarch64/aarch64-simd.md (vec_unpack_lo_ > vec_unpack_lo_ > (vec_unpacku_lo_ > vec_unpacku_lo_ > (aarch64_usubw__zip): New.
> > (aarch64_uaddw__zip): New.
> > * config/aarch64/iterators.md (PERM_EXTEND, perm_index): New.
> > (perm_hilo): Add UNSPEC_ZIP1, UNSPEC_ZIP2.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/aarch64/simd/vmovl_high_1.c: Update codegen.
> > * gcc.target/aarch64/uxtl-combine-1.c: New test.
> > * gcc.target/aarch64/uxtl-combine-2.c: New test.
> > * gcc.target/aarch64/uxtl-combine-3.c: New test.
> > * gcc.target/aarch64/uxtl-combine-4.c: New test.
> > * gcc.target/aarch64/uxtl-combine-5.c: New test.
> > * gcc.target/aarch64/uxtl-combine-6.c: New test.
>
> You have a few typos in the testcases which causes:
> ERROR: gcc.target/aarch64/uxtl-combine-4.c: error executing dg-final:
> invalid command name "scan-assembler-time"
> ERROR: gcc.target/aarch64/uxtl-combine-5.c: error executing dg-final:
> invalid command name "scan-assembler-time"
> ERROR: gcc.target/aarch64/uxtl-combine-6.c: error executing dg-final:
> invalid command name "scan-assembler-time"

You must not have done some good testing since it also caused the following:
FAIL: gcc.dg/vect/slp-widen-mult-half.c (test for excess errors)
FAIL: gcc.dg/vect/slp-widen-mult-half.c -flto -ffat-lto-objects (test
for excess errors)
UNRESOLVED: gcc.dg/vect/slp-widen-mult-half.c -flto -ffat-lto-objects
compilation failed to produce executable
UNRESOLVED: gcc.dg/vect/slp-widen-mult-half.c compilation failed to
produce executable
FAIL: gcc.dg/vect/vect-avg-9.c (test for excess errors)
FAIL: gcc.dg/vect/vect-avg-9.c -flto -ffat-lto-objects (test for excess errors)
UNRESOLVED: gcc.dg/vect/vect-avg-9.c -flto -ffat-lto-objects
compilation failed to produce executable
UNRESOLVED: gcc.dg/vect/vect-avg-9.c compilation failed to produce executable
FAIL: gcc.dg/vect/vect-outer-4f.c (test for excess errors)
FAIL: gcc.dg/vect/vect-outer-4f.c -flto -ffat-lto-objects (test for
excess errors)
UNRESOLVED: gcc.dg/vect/vect-outer-4f.c -flto -ffat-lto-objects
compilation failed to produce executable
UNRESOLVED: gcc.dg/vect/vect-outer-4f.c compilation failed to produce executable
FAIL: gcc.dg/vect/vect-outer-4g.c (test for excess errors)
FAIL: gcc.dg/vect/vect-outer-4g.c -flto -ffat-lto-objects (test for
excess errors)
UNRESOLVED: gcc.dg/vect/vect-outer-4g.c -flto -ffat-lto-objects
compilation failed to produce executable
UNRESOLVED: gcc.dg/vect/vect-outer-4g.c compilation failed to produce executable
FAIL: gcc.dg/vect/vect-outer-4i.c (test for excess errors)
FAIL: gcc.dg/vect/vect-outer-4i.c -flto -ffat-lto-objects (test for
excess errors)
UNRESOLVED: gcc.dg/vect/vect-outer-4i.c -flto -ffat-lto-objects
compilation failed to produce executable
UNRESOLVED: gcc.dg/vect/vect-outer-4i.c compilation failed to produce executable
FAIL: gcc.dg/vect/vect-outer-4k.c (test for excess errors)
FAIL: gcc.dg/vect/vect-outer-4k.c -flto -ffat-lto-objects (test for
excess errors)
UNRESOLVED: gcc.dg/vect/vect-outer-4k.c -flto -ffat-lto-objects
compilation failed to produce executable
UNRESOLVED: gcc.dg/vect/vect-outer-4k.c compilation failed to produce executable
FAIL: gcc.dg/vect/vect-outer-4l.c (test for excess errors)
FAIL: gcc.dg/vect/vect-outer-4l.c -flto -ffat-lto-objects (test for
excess errors)
UNRESOLVED: gcc.dg/vect/vect-outer-4l.c -flto -ffat-lto-objects
compilation failed to produce executable

Re: [PATCH] c++, v3: Implement C++26 P2741R3 - user-generated static_assert messages [PR110348]

2023-11-21 Thread Jakub Jelinek
On Tue, Nov 21, 2023 at 11:19:56PM +0100, Jakub Jelinek wrote:
> > > +   error_at (location, "% message must be a string "
> > > +   "literal or object with % and "
> > > +   "% members");
> > 
> > Let's print the type of the message as well.
> 
> so add " while it has type %qT", TREE_TYPE (message) or something else?

Now in patch form (except for the removal of warning_at for now):

2023-11-21  Jakub Jelinek  

PR c++/110348
gcc/
* doc/invoke.texi (-Wno-c++26-extensions): Document.
gcc/c-family/
* c.opt (Wc++26-extensions): New option.
* c-cppbuiltin.cc (c_cpp_builtins): For C++26 predefine
__cpp_static_assert to 202306L rather than 201411L.
gcc/cp/
* parser.cc: Implement C++26 P2741R3 - user-generated static_assert
messages.
(cp_parser_static_assert): Parse message argument as
conditional-expression if it is not a pure string literal or
several of them concatenated followed by closing paren.
* semantics.cc (finish_static_assert): Handle message which is not
STRING_CST.  For condition with bare parameter packs return early.
* pt.cc (tsubst_expr) : Also tsubst_expr
message and make sure that if it wasn't originally STRING_CST, it
isn't after tsubst_expr either.
gcc/testsuite/
* g++.dg/cpp26/static_assert1.C: New test.
* g++.dg/cpp26/feat-cxx26.C (__cpp_static_assert): Expect
202306L rather than 201411L.
* g++.dg/cpp0x/udlit-error1.C: Expect different diagnostics for
static_assert with user-defined literal.

--- gcc/doc/invoke.texi.jj  2023-11-21 21:00:41.980429829 +0100
+++ gcc/doc/invoke.texi 2023-11-21 23:25:16.849237207 +0100
@@ -9106,6 +9106,13 @@ Do not warn about C++23 constructs in co
 an older C++ standard.  Even without this option, some C++23 constructs
 will only be diagnosed if @option{-Wpedantic} is used.
 
+@opindex Wc++26-extensions
+@opindex Wno-c++26-extensions
+@item -Wno-c++26-extensions @r{(C++ and Objective-C++ only)}
+Do not warn about C++26 constructs in code being compiled using
+an older C++ standard.  Even without this option, some C++26 constructs
+will only be diagnosed if @option{-Wpedantic} is used.
+
 @opindex Wcast-qual
 @opindex Wno-cast-qual
 @item -Wcast-qual
--- gcc/c-family/c.opt.jj   2023-11-21 21:00:41.865431433 +0100
+++ gcc/c-family/c.opt  2023-11-21 23:25:16.850237193 +0100
@@ -498,6 +498,10 @@ Wc++23-extensions
 C++ ObjC++ Var(warn_cxx23_extensions) Warning Init(1)
 Warn about C++23 constructs in code compiled with an older standard.
 
+Wc++26-extensions
+C++ ObjC++ Var(warn_cxx26_extensions) Warning Init(1)
+Warn about C++26 constructs in code compiled with an older standard.
+
 Wcast-function-type
 C ObjC C++ ObjC++ Var(warn_cast_function_type) Warning EnabledBy(Wextra)
 Warn about casts between incompatible function types.
--- gcc/c-family/c-cppbuiltin.cc.jj 2023-11-21 21:00:41.865431433 +0100
+++ gcc/c-family/c-cppbuiltin.cc2023-11-21 23:25:16.850237193 +0100
@@ -1023,7 +1023,8 @@ c_cpp_builtins (cpp_reader *pfile)
{
  /* Set feature test macros for C++17.  */
  cpp_define (pfile, "__cpp_unicode_characters=201411L");
- cpp_define (pfile, "__cpp_static_assert=201411L");
+ if (cxx_dialect <= cxx23)
+   cpp_define (pfile, "__cpp_static_assert=201411L");
  cpp_define (pfile, "__cpp_namespace_attributes=201411L");
  cpp_define (pfile, "__cpp_enumerator_attributes=201411L");
  cpp_define (pfile, "__cpp_nested_namespace_definitions=201411L");
@@ -1086,6 +1087,7 @@ c_cpp_builtins (cpp_reader *pfile)
{
  /* Set feature test macros for C++26.  */
  cpp_define (pfile, "__cpp_constexpr=202306L");
+ cpp_define (pfile, "__cpp_static_assert=202306L");
}
   if (flag_concepts)
 {
--- gcc/cp/parser.cc.jj 2023-11-21 21:00:41.933430484 +0100
+++ gcc/cp/parser.cc2023-11-21 23:25:16.856237110 +0100
@@ -16616,6 +16616,7 @@ cp_parser_linkage_specification (cp_pars
static_assert-declaration:
  static_assert ( constant-expression , string-literal ) ;
  static_assert ( constant-expression ) ; (C++17)
+ static_assert ( constant-expression, conditional-expression ) ; (C++26)
 
If MEMBER_P, this static_assert is a class member.  */
 
@@ -16646,10 +16647,10 @@ cp_parser_static_assert (cp_parser *pars
 
   /* Parse the constant-expression.  Allow a non-constant expression
  here in order to give better diagnostics in finish_static_assert.  */
-  condition =
-cp_parser_constant_expression (parser,
-   /*allow_non_constant_p=*/true,
-  /*non_constant_p=*/nullptr);
+  condition
+= cp_parser_constant_expression (parser,
+/*allow_non_constant_p=*/true,
+/*non_constant_p=*/nullptr);
 
   

Re: [PATCH]AArch64 Add pattern for unsigned widenings (uxtl) to zip{1, 2}

2023-11-21 Thread Andrew Pinski
On Wed, Nov 15, 2023 at 6:42 AM Tamar Christina  wrote:
>
> Hi All,
>
> This changes unpack instructions to use zip{1,2} when doing a zero-extending
> widening operation.  Permutes generally have a higher throughput than the
> widening operations. Zeros are shuffled into the top half of the registers.
>
> The testcase
>
> void d2 (unsigned * restrict a, unsigned short *b, int n)
> {
> for (int i = 0; i < (n & -8); i++)
>   a[i] = b[i];
> }
>
> now generates:
>
> moviv1.4s, 0
> .L3:
> ldr q0, [x1], 16
> zip1v2.8h, v0.8h, v1.8h
> zip2v0.8h, v0.8h, v1.8h
> stp q2, q0, [x0]
> add x0, x0, 32
> cmp x1, x2
> bne .L3
>
>
> instead of:
>
> .L3:
> ldr q0, [x1], 16
> uxtlv1.4s, v0.4h
> uxtl2   v0.4s, v0.8h
> stp q1, q0, [x0]
> add x0, x0, 32
> cmp x1, x2
> bne .L3
>
> Since we need the extra 0 register we do this only for the vectorizer's lo/hi
> pairs when we know the 0 will be floated outside of the loop.
>
> This gives an 8% speed-up in Imagick in SPECCPU 2017 on Neoverse V2.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-simd.md (vec_unpack_lo_ vec_unpack_lo_ (vec_unpacku_lo_ vec_unpacku_lo_ (aarch64_usubw__zip): New.
> (aarch64_uaddw__zip): New.
> * config/aarch64/iterators.md (PERM_EXTEND, perm_index): New.
> (perm_hilo): Add UNSPEC_ZIP1, UNSPEC_ZIP2.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/aarch64/simd/vmovl_high_1.c: Update codegen.
> * gcc.target/aarch64/uxtl-combine-1.c: New test.
> * gcc.target/aarch64/uxtl-combine-2.c: New test.
> * gcc.target/aarch64/uxtl-combine-3.c: New test.
> * gcc.target/aarch64/uxtl-combine-4.c: New test.
> * gcc.target/aarch64/uxtl-combine-5.c: New test.
> * gcc.target/aarch64/uxtl-combine-6.c: New test.

You have a few typos in the testcases which causes:
ERROR: gcc.target/aarch64/uxtl-combine-4.c: error executing dg-final:
invalid command name "scan-assembler-time"
ERROR: gcc.target/aarch64/uxtl-combine-5.c: error executing dg-final:
invalid command name "scan-assembler-time"
ERROR: gcc.target/aarch64/uxtl-combine-6.c: error executing dg-final:
invalid command name "scan-assembler-time"


They all should be `scan-assembler-times`.

Thanks,
Andrew

>
> --- inline copy of patch --
> diff --git a/gcc/config/aarch64/aarch64-simd.md 
> b/gcc/config/aarch64/aarch64-simd.md
> index 
> 81ff5bad03d598fa0d48df93d172a28bc0d1d92e..3d811007dd94dcd9176d6021a41a196c12fe9c3f
>  100644
> --- a/gcc/config/aarch64/aarch64-simd.md
> +++ b/gcc/config/aarch64/aarch64-simd.md
> @@ -1988,26 +1988,60 @@ (define_insn "aarch64_simd_vec_unpack_hi_"
>[(set_attr "type" "neon_shift_imm_long")]
>  )
>
> -(define_expand "vec_unpack_hi_"
> +(define_expand "vec_unpacku_hi_"
>[(match_operand: 0 "register_operand")
> -   (ANY_EXTEND: (match_operand:VQW 1 "register_operand"))]
> +   (match_operand:VQW 1 "register_operand")]
> +  "TARGET_SIMD"
> +  {
> +rtx res = gen_reg_rtx (mode);
> +rtx tmp = aarch64_gen_shareable_zero (mode);
> +if (BYTES_BIG_ENDIAN)
> +  emit_insn (gen_aarch64_zip2 (res, tmp, operands[1]));
> +else
> + emit_insn (gen_aarch64_zip2 (res, operands[1], tmp));
> +emit_move_insn (operands[0],
> +  simplify_gen_subreg (mode, res, mode, 0));
> +DONE;
> +  }
> +)
> +
> +(define_expand "vec_unpacks_hi_"
> +  [(match_operand: 0 "register_operand")
> +   (match_operand:VQW 1 "register_operand")]
>"TARGET_SIMD"
>{
>  rtx p = aarch64_simd_vect_par_cnst_half (mode, , true);
> -emit_insn (gen_aarch64_simd_vec_unpack_hi_ (operands[0],
> - operands[1], p));
> +emit_insn (gen_aarch64_simd_vec_unpacks_hi_ (operands[0],
> +  operands[1], p));
> +DONE;
> +  }
> +)
> +
> +(define_expand "vec_unpacku_lo_"
> +  [(match_operand: 0 "register_operand")
> +   (match_operand:VQW 1 "register_operand")]
> +  "TARGET_SIMD"
> +  {
> +rtx res = gen_reg_rtx (mode);
> +rtx tmp = aarch64_gen_shareable_zero (mode);
> +if (BYTES_BIG_ENDIAN)
> +   emit_insn (gen_aarch64_zip1 (res, tmp, operands[1]));
> +else
> +   emit_insn (gen_aarch64_zip1 (res, operands[1], tmp));
> +emit_move_insn (operands[0],
> +  simplify_gen_subreg (mode, res, mode, 0));
>  DONE;
>}
>  )
>
> -(define_expand "vec_unpack_lo_"
> +(define_expand "vec_unpacks_lo_"
>[(match_operand: 0 "register_operand")
> -   (ANY_EXTEND: (match_operand:VQW 1 "register_operand"))]
> +   (match_operand:VQW 1 "register_operand")]
>"TARGET_SIMD"
>{
>  rtx p = aarch64_simd_vect_par_cnst_half (mode, , false);
> -emit_insn 

Re: [PATCH 0/6] v2 of libdiagnostics

2023-11-21 Thread Simon Sobisch

Thank you for your efforts.
Having the wiki page to track this definitely is useful!

I'll have a look at the "real patch" later, likely next week.

But for patch 4+5 which look quite clean: can we get an early 
improvement and inclusion into GCC for those?
They only adjust internals and should be well covered by the existing 
test suite, so we may be able to inspect the other changes from this 
patchset "alone".


Kind Regards,
Simon

Am 21.11.2023 um 23:20 schrieb David Malcolm:

Here's v2 of the "libdiagnostics" shared library idea; see:
   https://gcc.gnu.org/wiki/libdiagnostics

As in v1, patch 1 (for GCC) shows libdiagnostic.h (the public
header file), along with examples of simple self-contained programs that
show various uses of the API.

As in v1, patch 2 (for GCC) is the work-in-progress implementation.

Patch 3 (for GCC) adds a new libdiagnostics++.h, a wrapper API providing
some syntactic sugar when using the API from C++.  I've been using this
to "eat my own dogfood" and write a simple SARIF-dumping tool:
   https://github.com/davidmalcolm/libdiagnostics-sarif-dump

Patch 4 (for GCC) is an internal change needed by patch 1.

Patch 5 (for GCC) updates GCC's source printing code so that when
there's no column information, we don't print annotation lines.  This
fixes the extra lines seen using it from gas discussed in:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635575.html

Patch 6 (for binutils) is an updated version of the experiment at using
the API from gas.

Thoughts?

David Malcolm (5):
   libdiagnostics v2: header and examples
   libdiagnostics v2: work-in-progress implementation
   libdiagnostics v2: add C++ wrapper API
   diagnostics: add diagnostic_context::get_location_text
   diagnostics: don't print annotation lines when there's no column info

  gcc/Makefile.in   |  131 +-
  gcc/configure |2 +-
  gcc/configure.ac  |2 +-
  gcc/diagnostic-show-locus.cc  |   26 +-
  gcc/diagnostic.cc |   35 +-
  gcc/diagnostic.h  |2 +
  gcc/libdiagnostics++.h|  378 +
  gcc/libdiagnostics.cc | 1306 +
  gcc/libdiagnostics.h  |  602 
  gcc/libdiagnostics.map|   63 +
  .../libdiagnostics.dg/libdiagnostics.exp  |  544 +++
  gcc/testsuite/libdiagnostics.dg/test-dump.c   |   55 +
  .../libdiagnostics.dg/test-error-with-note.c  |   57 +
  .../libdiagnostics.dg/test-error-with-note.cc |   47 +
  gcc/testsuite/libdiagnostics.dg/test-error.c  |   49 +
  gcc/testsuite/libdiagnostics.dg/test-error.cc |   40 +
  .../libdiagnostics.dg/test-fix-it-hint.c  |   49 +
  .../libdiagnostics.dg/test-fix-it-hint.cc |   44 +
  .../libdiagnostics.dg/test-helpers++.h|   28 +
  .../libdiagnostics.dg/test-helpers.h  |   29 +
  .../libdiagnostics.dg/test-labelled-ranges.c  |   52 +
  .../libdiagnostics.dg/test-labelled-ranges.cc |   43 +
  .../libdiagnostics.dg/test-logical-location.c |   60 +
  .../libdiagnostics.dg/test-metadata.c |   54 +
  .../libdiagnostics.dg/test-multiple-lines.c   |   61 +
  .../libdiagnostics.dg/test-no-column.c|   41 +
  .../test-note-with-fix-it-hint.c  |   52 +
  .../test-text-sink-options.c  |   46 +
  .../libdiagnostics.dg/test-warning.c  |   52 +
  .../test-write-sarif-to-file.c|   46 +
  .../test-write-text-to-file.c |   47 +
  31 files changed, 4018 insertions(+), 25 deletions(-)
  create mode 100644 gcc/libdiagnostics++.h
  create mode 100644 gcc/libdiagnostics.cc
  create mode 100644 gcc/libdiagnostics.h
  create mode 100644 gcc/libdiagnostics.map
  create mode 100644 gcc/testsuite/libdiagnostics.dg/libdiagnostics.exp
  create mode 100644 gcc/testsuite/libdiagnostics.dg/test-dump.c
  create mode 100644 gcc/testsuite/libdiagnostics.dg/test-error-with-note.c
  create mode 100644 gcc/testsuite/libdiagnostics.dg/test-error-with-note.cc
  create mode 100644 gcc/testsuite/libdiagnostics.dg/test-error.c
  create mode 100644 gcc/testsuite/libdiagnostics.dg/test-error.cc
  create mode 100644 gcc/testsuite/libdiagnostics.dg/test-fix-it-hint.c
  create mode 100644 gcc/testsuite/libdiagnostics.dg/test-fix-it-hint.cc
  create mode 100644 gcc/testsuite/libdiagnostics.dg/test-helpers++.h
  create mode 100644 gcc/testsuite/libdiagnostics.dg/test-helpers.h
  create mode 100644 gcc/testsuite/libdiagnostics.dg/test-labelled-ranges.c
  create mode 100644 gcc/testsuite/libdiagnostics.dg/test-labelled-ranges.cc
  create mode 100644 gcc/testsuite/libdiagnostics.dg/test-logical-location.c
  create mode 100644 gcc/testsuite/libdiagnostics.dg/test-metadata.c
  create mode 100644 gcc/testsuite/libdiagnostics.dg/test-multiple-lines.c
  create mode 100644 gcc/testsuite/libdiagnostics.dg/test-no-column.c
  

[PATCH 2/5] libdiagnostics v2: work-in-progress implementation

2023-11-21 Thread David Malcolm
Changed in v2:
* Changed diagnostic_location_t -> const diagnostic_physical_location *
* new entrypoint: diagnostic_finish_va
* new debugging entrypoints for dumping to a FILE *
* Makefile.in: dropped FULL_DRIVER_NAME from libdiagnostics
* fix up for my recent changes to gcc/diagnostic.h

Blurb from v1:

Here's a work-in-progress patch for GCC that adds the implementation
of libdiagnostics.  Various aspects of this need work; posting now
for early feedback on overall direction.

gcc/ChangeLog:
* Makefile.in (lang_checks): Add check-libdiagnostics.
(start.encap): Add libdiagnostics.
(libdiagnostics_OBJS): New.
...plus a bunch of stuff hacked up from jit/Make-lang.in.
* configure: Regenerate.
* configure.ac (check_languages): Add check-libdiagnostics.
* libdiagnostics.cc: New file.
* libdiagnostics.map: New file.

gcc/testsuite/ChangeLog:
* libdiagnostics.dg/libdiagnostics.exp: New, based on jit.exp.
---
 gcc/Makefile.in   |  131 +-
 gcc/configure |2 +-
 gcc/configure.ac  |2 +-
 gcc/libdiagnostics.cc | 1306 +
 gcc/libdiagnostics.map|   63 +
 .../libdiagnostics.dg/libdiagnostics.exp  |  544 +++
 6 files changed, 2044 insertions(+), 4 deletions(-)
 create mode 100644 gcc/libdiagnostics.cc
 create mode 100644 gcc/libdiagnostics.map
 create mode 100644 gcc/testsuite/libdiagnostics.dg/libdiagnostics.exp

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 7b2f0c0f629c..7ad9eb442220 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -618,7 +618,7 @@ host_xm_defines=@host_xm_defines@
 xm_file_list=@xm_file_list@
 xm_include_list=@xm_include_list@
 xm_defines=@xm_defines@
-lang_checks=
+lang_checks=check-libdiagnostics
 lang_checks_parallelized=
 lang_opt_files=@lang_opt_files@ $(srcdir)/c-family/c.opt $(srcdir)/common.opt 
$(srcdir)/params.opt $(srcdir)/analyzer/analyzer.opt
 lang_specs_files=@lang_specs_files@
@@ -2169,7 +2169,7 @@ all.cross: native gcc-cross$(exeext) cpp$(exeext) specs \
libgcc-support lang.all.cross doc selftest @GENINSRC@ srcextra
 # This is what must be made before installing GCC and converting libraries.
 start.encap: native xgcc$(exeext) cpp$(exeext) specs \
-   libgcc-support lang.start.encap @GENINSRC@ srcextra
+   libgcc-support lang.start.encap libdiagnostics @GENINSRC@ srcextra
 # These can't be made until after GCC can run.
 rest.encap: lang.rest.encap
 # This is what is made with the host's compiler
@@ -2258,6 +2258,133 @@ cpp$(exeext): $(GCC_OBJS) c-family/cppspec.o 
libcommon-target.a $(LIBDEPS) \
  c-family/cppspec.o $(EXTRA_GCC_OBJS) libcommon-target.a \
  $(EXTRA_GCC_LIBS) $(LIBS)
 
+
+libdiagnostics_OBJS = libdiagnostics.o \
+   libcommon.a
+
+# FIXME:
+# Define the names for selecting jit in LANGUAGES.
+# Note that it would be nice to move the dependency on g++
+# into the jit rule, but that needs a little bit of work
+# to do the right thing within all.cross.
+
+LIBDIAGNOSTICS_VERSION_NUM = 0
+LIBDIAGNOSTICS_MINOR_NUM = 0
+LIBDIAGNOSTICS_RELEASE_NUM = 1
+
+ifneq (,$(findstring mingw,$(target)))
+LIBDIAGNOSTICS_FILENAME = libdiagnostics-$(LIBDIAGNOSTICS_VERSION_NUM).dll
+LIBDIAGNOSTICS_IMPORT_LIB = libdiagnostics.dll.a
+
+libdiagnostics: $(LIBDIAGNOSTICS_FILENAME)
+
+else
+
+ifneq (,$(findstring darwin,$(host)))
+
+LIBDIAGNOSTICS_AGE = 1
+LIBDIAGNOSTICS_BASENAME = libdiagnostics
+
+LIBDIAGNOSTICS_SONAME = \
+  ${libdir}/$(LIBDIAGNOSTICS_BASENAME).$(LIBDIAGNOSTICS_VERSION_NUM).dylib
+LIBDIAGNOSTICS_FILENAME = 
$(LIBDIAGNOSTICS_BASENAME).$(LIBDIAGNOSTICS_VERSION_NUM).dylib
+LIBDIAGNOSTICS_LINKER_NAME = $(LIBDIAGNOSTICS_BASENAME).dylib
+
+# Conditionalize the use of the LD_VERSION_SCRIPT_OPTION and
+# LD_SONAME_OPTION depending if configure found them, using $(if)
+# We have to define a LIBDIAGNOSTICS_COMMA here, otherwise the commas in the 
"true"
+# result are treated as separators by the $(if).
+LIBDIAGNOSTICS_COMMA := ,
+LIBDIAGNOSTICS_VERSION_SCRIPT_OPTION = \
+   $(if $(LD_VERSION_SCRIPT_OPTION),\
+ 
-Wl$(LIBDIAGNOSTICS_COMMA)$(LD_VERSION_SCRIPT_OPTION)$(LIBDIAGNOSTICS_COMMA)$(srcdir)/libdiagnostics.map)
+
+LIBDIAGNOSTICS_SONAME_OPTION = \
+   $(if $(LD_SONAME_OPTION), \
+
-Wl$(LIBDIAGNOSTICS_COMMA)$(LD_SONAME_OPTION)$(LIBDIAGNOSTICS_COMMA)$(LIBDIAGNOSTICS_SONAME))
+
+LIBDIAGNOSTICS_SONAME_SYMLINK = $(LIBDIAGNOSTICS_FILENAME)
+LIBDIAGNOSTICS_LINKER_NAME_SYMLINK = $(LIBDIAGNOSTICS_LINKER_NAME)
+
+libdiagnostics: $(LIBDIAGNOSTICS_FILENAME) \
+   $(LIBDIAGNOSTICS_SYMLINK) \
+   $(LIBDIAGNOSTICS_LINKER_NAME_SYMLINK)
+
+else
+
+LIBDIAGNOSTICS_LINKER_NAME = libdiagnostics.so
+LIBDIAGNOSTICS_SONAME = 
$(LIBDIAGNOSTICS_LINKER_NAME).$(LIBDIAGNOSTICS_VERSION_NUM)
+LIBDIAGNOSTICS_FILENAME = \
+  

[PATCH] binutils: v2: experimental use of libdiagnostics in gas

2023-11-21 Thread David Malcolm
Changed in v2:
* updated for change from diagnostic_location_t to
  const diagnostic_physical_location *
* fix #if USE_DIAGNOSTICS to retain context and listing code

Output from the example below with v2 is now:

testsuite/gas/all/warn-1.s:3: warning: a warning message
3 |  .warning "a warning message"   ;# { dg-warning "Warning: a warning 
message" }
testsuite/gas/all/warn-1.s:4: error: .warning argument must be a string
4 |  .warning a warning message ;# { dg-error "Error: .warning argument 
must be a string" }
testsuite/gas/all/warn-1.s:5: warning: .warning directive invoked in source file
5 |  .warning   ;# { dg-warning "Warning: .warning 
directive invoked in source file" }
testsuite/gas/all/warn-1.s:6: warning: .warning directive invoked in source file
6 |  .warning ".warning directive invoked in source file"   ;# { dg-warning 
"Warning: .warning directive invoked in source file" }
testsuite/gas/all/warn-1.s:7: warning: 
7 |  .warning "";# { dg-warning "Warning: " }

and there's also now a way to toggle quoting of the source code (perhaps
for use in the testsuite)


Blurb from v1:
Here's a patch for gas in binutils that makes it use libdiagnostics
(with some nasty hardcoded paths to specific places on my hard drive
to make it easier to develop the API).

For now this hardcodes adding two sinks: a text sink on stderr, and
also a SARIF output to stderr (which happens after all regular output).

For example, without this patch:

   gas testsuite/gas/all/warn-1.s

emits:

testsuite/gas/all/warn-1.s: Assembler messages:
testsuite/gas/all/warn-1.s:3: Warning: a warning message
testsuite/gas/all/warn-1.s:4: Error: .warning argument must be a string
testsuite/gas/all/warn-1.s:5: Warning: .warning directive invoked in source file
testsuite/gas/all/warn-1.s:6: Warning: .warning directive invoked in source file
testsuite/gas/all/warn-1.s:7: Warning:


whereas with this patch:
  LD_LIBRARY_PATH=/home/david/coding-3/gcc-newgit-canvas-2023/build/gcc 
./as-new testsuite/gas/all/warn-1.s
emits:


testsuite/gas/all/warn-1.s:3: warning: a warning message
3 |  .warning "a warning message"   ;# { dg-warning "Warning: a warning 
message" }
  |
testsuite/gas/all/warn-1.s:4: error: .warning argument must be a string
4 |  .warning a warning message ;# { dg-error "Error: .warning argument 
must be a string" }
  |
testsuite/gas/all/warn-1.s:5: warning: .warning directive invoked in source file
5 |  .warning   ;# { dg-warning "Warning: .warning 
directive invoked in source file" }
  |
testsuite/gas/all/warn-1.s:6: warning: .warning directive invoked in source file
6 |  .warning ".warning directive invoked in source file"   ;# { dg-warning 
"Warning: .warning directive invoked in source file" }
  |
testsuite/gas/all/warn-1.s:7: warning:
7 |  .warning "";# { dg-warning "Warning: " }
  |
{"$schema": 
"https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json;,
 "version": "2.1.0", "runs": [{"tool": {"driver": {"rules": []}}, 
"invocations": [{"executionSuccessful": true, "toolExecutionNotifications": 
[]}], "originalUriBaseIds": {"PWD": {"uri": 
"file:///home/david/coding-3/binutils-gdb/gas/"}}, "artifacts": [{"location": 
{"uri": "testsuite/gas/all/warn-1.s", "uriBaseId": "PWD"}, "contents": {"text": 
";# Test .warning directive.\n;# { dg-do assemble }\n .warning \"a warning 
message\"\t;# { dg-warning \"Warning: a warning message\" }\n .warning a 
warning message\t;# { dg-error \"Error: .warning argument must be a string\" 
}\n .warning\t\t\t;# { dg-warning \"Warning: .warning directive invoked in 
source file\" }\n .warning \".warning directive invoked in source file\"\t;# { 
dg-warning \"Warning: .warning directive invoked in source file\" }\n .warning 
\"\"\t\t\t;# { dg-warning \"Warning: \" }\n"}}], "results": [{"ruleId": 
"warning", "level": "warning", "message": {"text": "a warning message"}, 
"locations": [{"physicalLocation": {"artifactLocation": {"uri": 
"testsuite/gas/all/warn-1.s", "uriBaseId": "PWD"}, "region": {"startLine": 3, 
"startColumn": 0, "endColumn": 1}, "contextRegion": {"startLine": 3, "snippet": 
{"text": " .warning \"a warning message\"\t;# { dg-warning \"Warning: a warning 
message\" }\n"], "relatedLocations": [{"physicalLocation": 
{"artifactLocation": {"uri": "testsuite/gas/all/warn-1.s", "uriBaseId": "PWD"}, 
"region": {"startLine": 4, "startColumn": 0, "endColumn": 1}, "contextRegion": 
{"startLine": 4, "snippet": {"text": " .warning a warning message\t;# { 
dg-error \"Error: .warning argument must be a string\" }\n"}}}, "message": 
{"text": ".warning argument must be a 

[PATCH 4/5] diagnostics: add diagnostic_context::get_location_text

2023-11-21 Thread David Malcolm
No functional change intended.

gcc/ChangeLog:
* diagnostic.cc (diagnostic_get_location_text): Convert to...
(diagnostic_context::get_location_text): ...this, and convert
return type from char * to label_text.
(diagnostic_build_prefix): Update for above change.
(default_diagnostic_start_span_fn): Likewise.
(selftest::assert_location_text): Likewise.
* diagnostic.h (diagnostic_context::get_location_text): New decl.
---
 gcc/diagnostic.cc | 35 +++
 gcc/diagnostic.h  |  2 ++
 2 files changed, 17 insertions(+), 20 deletions(-)

diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
index b4ebcd29457c..4f66fa6acaa8 100644
--- a/gcc/diagnostic.cc
+++ b/gcc/diagnostic.cc
@@ -558,14 +558,12 @@ maybe_line_and_column (int line, int col)
   return result;
 }
 
-/* Return a malloc'd string describing a location e.g. "foo.c:42:10".
-   The caller is responsible for freeing the memory.  */
+/* Return a string describing a location e.g. "foo.c:42:10".  */
 
-static char *
-diagnostic_get_location_text (diagnostic_context *context,
- expanded_location s)
+label_text
+diagnostic_context::get_location_text (const expanded_location ) const
 {
-  pretty_printer *pp = context->printer;
+  pretty_printer *pp = this->printer;
   const char *locus_cs = colorize_start (pp_show_color (pp), "locus");
   const char *locus_ce = colorize_stop (pp_show_color (pp));
   const char *file = s.file ? s.file : progname;
@@ -574,13 +572,13 @@ diagnostic_get_location_text (diagnostic_context *context,
   if (strcmp (file, special_fname_builtin ()))
 {
   line = s.line;
-  if (context->m_show_column)
-   col = context->converted_column (s);
+  if (m_show_column)
+   col = this->converted_column (s);
 }
 
   const char *line_col = maybe_line_and_column (line, col);
-  return build_message_string ("%s%s%s:%s", locus_cs, file,
-  line_col, locus_ce);
+  return label_text::take (build_message_string ("%s%s%s:%s", locus_cs, file,
+line_col, locus_ce));
 }
 
 static const char *const diagnostic_kind_text[] = {
@@ -610,12 +608,11 @@ diagnostic_build_prefix (diagnostic_context *context,
   text_ce = colorize_stop (pp_show_color (pp));
 }
 
-  expanded_location s = diagnostic_expand_location (diagnostic);
-  char *location_text = diagnostic_get_location_text (context, s);
+  const expanded_location s = diagnostic_expand_location (diagnostic);
+  label_text location_text = context->get_location_text (s);
 
-  char *result = build_message_string ("%s %s%s%s", location_text,
+  char *result = build_message_string ("%s %s%s%s", location_text.get (),
   text_cs, text, text_ce);
-  free (location_text);
   return result;
 }
 
@@ -1091,9 +1088,8 @@ void
 default_diagnostic_start_span_fn (diagnostic_context *context,
  expanded_location exploc)
 {
-  char *text = diagnostic_get_location_text (context, exploc);
-  pp_string (context->printer, text);
-  free (text);
+  label_text text = context->get_location_text (exploc);
+  pp_string (context->printer, text.get ());
   pp_newline (context->printer);
 }
 
@@ -2852,9 +2848,8 @@ assert_location_text (const char *expected_loc_text,
   xloc.data = NULL;
   xloc.sysp = false;
 
-  char *actual_loc_text = diagnostic_get_location_text (, xloc);
-  ASSERT_STREQ (expected_loc_text, actual_loc_text);
-  free (actual_loc_text);
+  label_text actual_loc_text = dc.get_location_text (xloc);
+  ASSERT_STREQ (expected_loc_text, actual_loc_text.get ());
 }
 
 /* Verify that diagnostic_get_location_text works as expected.  */
diff --git a/gcc/diagnostic.h b/gcc/diagnostic.h
index 958068fea926..8b7f147c0d28 100644
--- a/gcc/diagnostic.h
+++ b/gcc/diagnostic.h
@@ -543,6 +543,8 @@ public:
 return m_option_callbacks.m_lang_mask;
   }
 
+  label_text get_location_text (const expanded_location ) const;
+
 private:
   bool includes_seen_p (const line_map_ordinary *map);
 
-- 
2.26.3



[PATCH 1/5] libdiagnostics v2: header and examples

2023-11-21 Thread David Malcolm
Changed in v2:
* Changed from diagnostic_location_t -> const diagnostic_physical_location *
* Add entrypoint: diagnostic_finish_va
* add new type diagnostic_text_sink, and new entrypoints for
  enabling/disabling options on it
* add new debugging entrypoints for dumping objects to a FILE *
* new test cases

Blurb from v1:

Here's a work-in-progress patch for GCC that adds a libdiagnostics.h
header describing the public interface, along with various testcases
that show usage examples for the API.  Various aspects of this need
work; posting now for early feedback on overall direction.

How does the interface look?

gcc/ChangeLog:
* libdiagnostics.h: New file.

gcc/testsuite/ChangeLog:
* libdiagnostics.dg/test-error-with-note.c: New test.
* libdiagnostics.dg/test-error.c: New test.
* libdiagnostics.dg/test-fix-it-hint.c: New test.
* libdiagnostics.dg/test-helpers.h: New.
* libdiagnostics.dg/test-labelled-ranges.c: New test.
* libdiagnostics.dg/test-logical-location.c: New test.
* libdiagnostics.dg/test-metadata.c: New test.
* libdiagnostics.dg/test-multiple-lines.c: New test.
* libdiagnostics.dg/test-note-with-fix-it-hint.c: New test.
* libdiagnostics.dg/test-warning.c: New test.
* libdiagnostics.dg/test-write-sarif-to-file.c: New test.
* libdiagnostics.dg/test-write-text-to-file.c: New test.
---
 gcc/libdiagnostics.h  | 602 ++
 gcc/testsuite/libdiagnostics.dg/test-dump.c   |  55 ++
 .../libdiagnostics.dg/test-error-with-note.c  |  57 ++
 gcc/testsuite/libdiagnostics.dg/test-error.c  |  49 ++
 .../libdiagnostics.dg/test-fix-it-hint.c  |  49 ++
 .../libdiagnostics.dg/test-helpers.h  |  29 +
 .../libdiagnostics.dg/test-labelled-ranges.c  |  52 ++
 .../libdiagnostics.dg/test-logical-location.c |  60 ++
 .../libdiagnostics.dg/test-metadata.c |  54 ++
 .../libdiagnostics.dg/test-multiple-lines.c   |  61 ++
 .../libdiagnostics.dg/test-no-column.c|  41 ++
 .../test-note-with-fix-it-hint.c  |  52 ++
 .../test-text-sink-options.c  |  46 ++
 .../libdiagnostics.dg/test-warning.c  |  52 ++
 .../test-write-sarif-to-file.c|  46 ++
 .../test-write-text-to-file.c |  47 ++
 16 files changed, 1352 insertions(+)
 create mode 100644 gcc/libdiagnostics.h
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-dump.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-error-with-note.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-error.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-fix-it-hint.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-helpers.h
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-labelled-ranges.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-logical-location.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-metadata.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-multiple-lines.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-no-column.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-note-with-fix-it-hint.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-text-sink-options.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-warning.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-write-sarif-to-file.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-write-text-to-file.c

diff --git a/gcc/libdiagnostics.h b/gcc/libdiagnostics.h
new file mode 100644
index ..5c4e203b6a0a
--- /dev/null
+++ b/gcc/libdiagnostics.h
@@ -0,0 +1,602 @@
+/* A pure C API for emitting diagnostics.
+   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.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#ifndef LIBDIAGNOSTICS_H
+#define LIBDIAGNOSTICS_H
+
+#include 
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+/**
+ Macros for attributes.
+ These are all currently empty, and thus for the human reader rather than
+ the compiler.
+ **/
+
+#define LIBDIAGNOSTICS_PARAM_MUST_BE_NON_NULL(ARG_NUM)
+
+#define LIBDIAGNOSTICS_PARAM_CAN_BE_NULL(ARG_NUM)
+
+#define LIBDIAGNOSTICS_PARAM_GCC_FORMAT_STRING(FMT_ARG_NUM, ARGS_ARG_NUM)
+

[PATCH 3/5] libdiagnostics v2: add C++ wrapper API

2023-11-21 Thread David Malcolm
This is new in v2: a C++ wrapper API that provides some syntactic sugar for
calling into libdiagnostics.{h,so}.

I've been "eating my own dogfood" with this by using it to write a simple
client that reads a SARIF file and dumps it using the text sink:
  https://github.com/davidmalcolm/libdiagnostics-sarif-dump

gcc/ChangeLog:
* libdiagnostics++.h: New file.

gcc/testsuite/ChangeLog:
* libdiagnostics.dg/libdiagnostics.exp: Add .cc tests.
* libdiagnostics.dg/test-error-with-note.cc: New test.
* libdiagnostics.dg/test-error.cc: New test.
* libdiagnostics.dg/test-fix-it-hint.cc: New test.
* libdiagnostics.dg/test-helpers++.h: New header.
* libdiagnostics.dg/test-labelled-ranges.cc: New test.
---
 gcc/libdiagnostics++.h| 378 ++
 .../libdiagnostics.dg/libdiagnostics.exp  |   8 +-
 .../libdiagnostics.dg/test-error-with-note.cc |  47 +++
 gcc/testsuite/libdiagnostics.dg/test-error.cc |  40 ++
 .../libdiagnostics.dg/test-fix-it-hint.cc |  44 ++
 .../libdiagnostics.dg/test-helpers++.h|  28 ++
 .../libdiagnostics.dg/test-labelled-ranges.cc |  43 ++
 7 files changed, 584 insertions(+), 4 deletions(-)
 create mode 100644 gcc/libdiagnostics++.h
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-error-with-note.cc
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-error.cc
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-fix-it-hint.cc
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-helpers++.h
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-labelled-ranges.cc

diff --git a/gcc/libdiagnostics++.h b/gcc/libdiagnostics++.h
new file mode 100644
index ..8f412b07aa78
--- /dev/null
+++ b/gcc/libdiagnostics++.h
@@ -0,0 +1,378 @@
+/* A C++ wrapper API around libdiagnostics.h for emitting diagnostics.
+   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.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#ifndef LIBDIAGNOSTICSPP_H
+#define LIBDIAGNOSTICSPP_H
+
+#include "libdiagnostics.h"
+
+namespace libdiagnostics {
+
+typedef diagnostic_line_num_t line_num_t;
+typedef diagnostic_column_num_t column_num_t;
+
+class file;
+class physical_location;
+class logical_location;
+class group;
+class manager;
+class diagnostic;
+
+/* Wrapper around a const diagnostic_file *.  */
+
+class file
+{
+public:
+  file (const diagnostic_file *file) : m_inner (file) {}
+
+  const diagnostic_file * const m_inner;
+};
+
+/* Wrapper around a const diagnostic_physical_location *.  */
+
+class physical_location
+{
+public:
+  physical_location (const diagnostic_physical_location *location)
+  : m_inner (location)
+  {}
+
+  const diagnostic_physical_location *m_inner;
+};
+
+/* Wrapper around a const diagnostic_logical_location *.  */
+
+class logical_location
+{
+public:
+  logical_location () : m_inner (nullptr) {}
+
+  logical_location (const diagnostic_logical_location *logical_loc)
+  : m_inner (logical_loc)
+  {}
+
+  const diagnostic_logical_location * const m_inner;
+};
+
+/* RAII class for starting/ending a group within a diagnostic_manager.  */
+
+class group
+{
+public:
+  group (manager );
+  ~group ();
+
+private:
+  manager _mgr;
+};
+
+/* Wrapper around a diagnostic *.  */
+
+class diagnostic
+{
+public:
+  diagnostic (::diagnostic *d) : m_inner (d) {}
+
+  void
+  set_cwe (unsigned cwe_id);
+
+  void
+  set_location (physical_location loc);
+
+  void
+  add_location_with_label (physical_location loc,
+  const char *text);
+
+  void
+  set_logical_location (logical_location loc);
+
+  void
+  add_fix_it_hint_insert_before (physical_location loc,
+const char *addition);
+  void
+  add_fix_it_hint_insert_after (physical_location loc,
+   const char *addition);
+  void
+  add_fix_it_hint_replace (physical_location loc,
+  const char *replacement);
+  void
+  add_fix_it_hint_delete (physical_location loc);
+
+  void
+  finish (const char *fmt, ...)
+LIBDIAGNOSTICS_PARAM_MUST_BE_NON_NULL (2)
+LIBDIAGNOSTICS_PARAM_GCC_FORMAT_STRING (2, 3);
+
+  ::diagnostic * const m_inner;
+};
+
+/* Wrapper around ownership of a diagnostic_manager *.  */
+
+class manager
+{
+public:
+  manager ()
+  : m_inner (diagnostic_manager_new ())
+  {
+  }
+  ~manager ()
+  {
+diagnostic_manager_release 

[PATCH 5/5] diagnostics: don't print annotation lines when there's no column info

2023-11-21 Thread David Malcolm
gcc/ChangeLog:
* diagnostic-show-locus.cc (layout::maybe_add_location_range):
Don't print annotation lines for ranges when there's no column
info.
(selftest::test_one_liner_no_column): New.
(selftest::test_diagnostic_show_locus_one_liner): Call it.
---
 gcc/diagnostic-show-locus.cc | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/gcc/diagnostic-show-locus.cc b/gcc/diagnostic-show-locus.cc
index 563d2826f249..55e7166b9448 100644
--- a/gcc/diagnostic-show-locus.cc
+++ b/gcc/diagnostic-show-locus.cc
@@ -1295,6 +1295,15 @@ layout::maybe_add_location_range (const location_range 
*loc_range,
   sanely relative to the primary location.  */
return false;
 
+  /* If there's no column information, then don't try to print
+ annotation lines for this range.  */
+  enum range_display_kind range_display_kind
+= loc_range->m_range_display_kind;
+  if (start.column == 0
+  || finish.column == 0
+  || caret.column == 0)
+range_display_kind = SHOW_LINES_WITHOUT_RANGE;
+
   /* Everything is now known to be in the correct source file,
  but it may require further sanitization.  */
   layout_range ri (exploc_with_display_col (m_file_cache,
@@ -1303,7 +1312,7 @@ layout::maybe_add_location_range (const location_range 
*loc_range,
   exploc_with_display_col (m_file_cache,
finish, m_policy,
LOCATION_ASPECT_FINISH),
-  loc_range->m_range_display_kind,
+  range_display_kind,
   exploc_with_display_col (m_file_cache,
caret, m_policy,
LOCATION_ASPECT_CARET),
@@ -3297,6 +3306,20 @@ test_one_liner_simple_caret ()
pp_formatted_text (dc.printer));
 }
 
+/* No column information (column == 0).
+   No annotation line should be printed.  */
+
+static void
+test_one_liner_no_column ()
+{
+  test_diagnostic_context dc;
+  location_t caret = linemap_position_for_column (line_table, 0);
+  rich_location richloc (line_table, caret);
+  diagnostic_show_locus (, , DK_ERROR);
+  ASSERT_STREQ (" foo = bar.field;\n",
+   pp_formatted_text (dc.printer));
+}
+
 /* Caret and range.  */
 
 static void
@@ -3848,6 +3871,7 @@ test_diagnostic_show_locus_one_liner (const 
line_table_case _)
   ASSERT_EQ (16, LOCATION_COLUMN (line_end));
 
   test_one_liner_simple_caret ();
+  test_one_liner_no_column ();
   test_one_liner_caret_and_range ();
   test_one_liner_multiple_carets_and_ranges ();
   test_one_liner_fixit_insert_before ();
-- 
2.26.3



[PATCH 0/6] v2 of libdiagnostics

2023-11-21 Thread David Malcolm
Here's v2 of the "libdiagnostics" shared library idea; see:
  https://gcc.gnu.org/wiki/libdiagnostics

As in v1, patch 1 (for GCC) shows libdiagnostic.h (the public
header file), along with examples of simple self-contained programs that
show various uses of the API.

As in v1, patch 2 (for GCC) is the work-in-progress implementation.

Patch 3 (for GCC) adds a new libdiagnostics++.h, a wrapper API providing
some syntactic sugar when using the API from C++.  I've been using this
to "eat my own dogfood" and write a simple SARIF-dumping tool:
  https://github.com/davidmalcolm/libdiagnostics-sarif-dump

Patch 4 (for GCC) is an internal change needed by patch 1.

Patch 5 (for GCC) updates GCC's source printing code so that when
there's no column information, we don't print annotation lines.  This
fixes the extra lines seen using it from gas discussed in:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635575.html

Patch 6 (for binutils) is an updated version of the experiment at using
the API from gas.

Thoughts?

David Malcolm (5):
  libdiagnostics v2: header and examples
  libdiagnostics v2: work-in-progress implementation
  libdiagnostics v2: add C++ wrapper API
  diagnostics: add diagnostic_context::get_location_text
  diagnostics: don't print annotation lines when there's no column info

 gcc/Makefile.in   |  131 +-
 gcc/configure |2 +-
 gcc/configure.ac  |2 +-
 gcc/diagnostic-show-locus.cc  |   26 +-
 gcc/diagnostic.cc |   35 +-
 gcc/diagnostic.h  |2 +
 gcc/libdiagnostics++.h|  378 +
 gcc/libdiagnostics.cc | 1306 +
 gcc/libdiagnostics.h  |  602 
 gcc/libdiagnostics.map|   63 +
 .../libdiagnostics.dg/libdiagnostics.exp  |  544 +++
 gcc/testsuite/libdiagnostics.dg/test-dump.c   |   55 +
 .../libdiagnostics.dg/test-error-with-note.c  |   57 +
 .../libdiagnostics.dg/test-error-with-note.cc |   47 +
 gcc/testsuite/libdiagnostics.dg/test-error.c  |   49 +
 gcc/testsuite/libdiagnostics.dg/test-error.cc |   40 +
 .../libdiagnostics.dg/test-fix-it-hint.c  |   49 +
 .../libdiagnostics.dg/test-fix-it-hint.cc |   44 +
 .../libdiagnostics.dg/test-helpers++.h|   28 +
 .../libdiagnostics.dg/test-helpers.h  |   29 +
 .../libdiagnostics.dg/test-labelled-ranges.c  |   52 +
 .../libdiagnostics.dg/test-labelled-ranges.cc |   43 +
 .../libdiagnostics.dg/test-logical-location.c |   60 +
 .../libdiagnostics.dg/test-metadata.c |   54 +
 .../libdiagnostics.dg/test-multiple-lines.c   |   61 +
 .../libdiagnostics.dg/test-no-column.c|   41 +
 .../test-note-with-fix-it-hint.c  |   52 +
 .../test-text-sink-options.c  |   46 +
 .../libdiagnostics.dg/test-warning.c  |   52 +
 .../test-write-sarif-to-file.c|   46 +
 .../test-write-text-to-file.c |   47 +
 31 files changed, 4018 insertions(+), 25 deletions(-)
 create mode 100644 gcc/libdiagnostics++.h
 create mode 100644 gcc/libdiagnostics.cc
 create mode 100644 gcc/libdiagnostics.h
 create mode 100644 gcc/libdiagnostics.map
 create mode 100644 gcc/testsuite/libdiagnostics.dg/libdiagnostics.exp
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-dump.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-error-with-note.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-error-with-note.cc
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-error.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-error.cc
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-fix-it-hint.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-fix-it-hint.cc
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-helpers++.h
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-helpers.h
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-labelled-ranges.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-labelled-ranges.cc
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-logical-location.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-metadata.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-multiple-lines.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-no-column.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-note-with-fix-it-hint.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-text-sink-options.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-warning.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-write-sarif-to-file.c
 create mode 100644 gcc/testsuite/libdiagnostics.dg/test-write-text-to-file.c

-- 
2.26.3



Re: [PATCH] c++, v3: Implement C++26 P2741R3 - user-generated static_assert messages [PR110348]

2023-11-21 Thread Jakub Jelinek
On Tue, Nov 21, 2023 at 04:44:01PM -0500, Jason Merrill wrote:
> > Or do you want to just use
> >   error_at (location, "% message must be a "
> >   "unevaluated string literal or object with "
> >   "% and % members");
> > wording (even when it is in C++26 term) regardless of the -std= level?
> 
> No, I think "unevaluated string literal" will be confusing to users.  I
> guess it's fine as it is, let's just print the type (as commented inline
> below).

Ok.

> > + error_at (location, "% message must be a string "
> > + "literal or object with % and "
> > + "% members");
> 
> Let's print the type of the message as well.

so add " while it has type %qT", TREE_TYPE (message) or something else?

> > +  releasing_vec size_args, data_args;
> > +  message_sz = finish_call_expr (message_sz, _args, false, false,
> > +tf_warning_or_error);
> > +  message_data = finish_call_expr (message_data, _args, false, 
> > false,
> > +  tf_warning_or_error);
> > +  if (message_sz == error_mark_node || message_data == error_mark_node)
> > +   return;
> > +  if (tree s
> > + = cp_get_callee_fndecl_nofold (extract_call_expr (message_sz)))
> > +   if (!DECL_DECLARED_CONSTEXPR_P (s))
> > + warning_at (location, 0, "%qD used in % message "
> > +  "is not %", s);
> 
> I don't think we need this check, it should be covered by the later
> constant-expression checks.

If the static_assert condition is true, we won't diagnose anything then.
clang++ there incorrectly errors, but I thought a warning could be useful
to users.  Perhaps it could warn only if the condition is true?

> > + error_at (location, "% message % "
> > + "must be implicitly convertible to "
> > + "%");
> 
> Let's also print the type of size().

" while it has type %qT" ?

> > @@ -11485,9 +11544,96 @@ finish_static_assert (tree condition, tr
> >   if (processing_template_decl)
> > goto defer;
> > - int sz = TREE_INT_CST_LOW (TYPE_SIZE_UNIT
> > -(TREE_TYPE (TREE_TYPE (message;
> > - int len = TREE_STRING_LENGTH (message) / sz - 1;
> > + int len;
> > + const char *msg = NULL;
> > + char *buf = NULL;
> > + if (message_sz && message_data)
> > +   {
> > + tree msz
> > +   = fold_non_dependent_expr (message_sz, complain,
> > +  /*manifestly_const_eval=*/true);
> 
> We can call cxx_constant_value here instead of fold_non_dependent_expr,
> since we don't get here in a template.

Ok.

> > + t = build1 (INDIRECT_REF, TREE_TYPE (TREE_TYPE (t)), t);
> > + tree t2
> > +   = fold_non_dependent_expr (t, complain,
> > +  /*manifestly_const_eval=*/
> > +  true);
> 
> This can also be cxx_constant_value.
> 
> > + if (!tree_fits_shwi_p (t2))
> > +   {
> > + cxx_constant_value (t);

But in that case I don't have to call it again, right?

> Let's add a comment here about how you're using (data(), 0) to test
> core-constant.

Ok.

Jakub



Re: [PATCH, v3] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]

2023-11-21 Thread Harald Anlauf

Uhh, it happened again.  Attached a wrong patch.
Only looked at the -v3 ...  My bad.

Sorry!

Harald


On 11/21/23 22:54, Harald Anlauf wrote:

Hi Mikael, Steve,

On 11/21/23 12:33, Mikael Morin wrote:

Harald, you mentioned the lack of GFC_STD_F2023_DEL feature group in
your first message, but I don't quite understand why you didn't add one.
  It seems to me the most natural way to do this.


thanks for insisting on this variant.

In my first attack at this problem, I overlooked one place in
libgfortran.h, which I now was able to find and adjust.
Now everything falls into place.


I suggest we emit a warning by default, error with -std=f2023 (I agree
with Steve that we should push towards strict f2023 conformance), and no
diagnostic with -std=gnu or -std=f2018 or lower.


As the majority agrees on this, I accept it.  The attached patch
now does this and fixes the testcases accordingly.


It seems that the solution is to fix the code in the testsuite.


Agreed, these seem to explicitly test mismatching kinds, so add an
option to prevent error.


Done.

I also fixed a few issues in the documentation in gfortran.texi .

As I currently cannot build a full compiler (see PR112643),
patch V3 is not properly regtested yet, but appears to give
results as discussed.

Comments?


Mikael


Thanks,
Harald


From 8fbffe1bd1faaff456abf6730ac2e2b3c370bc72 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Tue, 21 Nov 2023 22:29:19 +0100
Subject: [PATCH] Fortran: restrictions on integer arguments to SYSTEM_CLOCK
 [PR112609]

Fortran 2023 added restrictions on integer arguments to SYSTEM_CLOCK to
have a decimal exponent range at least as large as a default integer,
and that all integer arguments have the same kind type parameter.

gcc/fortran/ChangeLog:

	PR fortran/112609
	* check.cc (gfc_check_system_clock): Add checks on integer arguments
	to SYSTEM_CLOCK specific to F2023.
	* error.cc (notify_std_msg): Adjust to handle new features added
	in F2023.
	* gfortran.texi (_gfortran_set_options): Document GFC_STD_F2023_DEL,
	remove obsolete option GFC_STD_F2008_TS and fix enumeration values.
	* libgfortran.h (GFC_STD_F2023_DEL): Add and use in GFC_STD_OPT_F23.
	* options.cc (set_default_std_flags): Add GFC_STD_F2023_DEL.

gcc/testsuite/ChangeLog:

	PR fortran/112609
	* gfortran.dg/system_clock_1.f90: Add option -std=f2003.
	* gfortran.dg/system_clock_3.f08: Add option -std=f2008.
	* gfortran.dg/system_clock_4.f90: New test.
---
 gcc/fortran/check.cc | 50 
 gcc/fortran/error.cc |  6 ++-
 gcc/fortran/gfortran.texi| 10 ++--
 gcc/fortran/libgfortran.h|  8 ++--
 gcc/fortran/options.cc   |  6 ++-
 gcc/testsuite/gfortran.dg/system_clock_1.f90 |  1 +
 gcc/testsuite/gfortran.dg/system_clock_3.f08 |  1 +
 gcc/testsuite/gfortran.dg/system_clock_4.f90 | 24 ++
 8 files changed, 95 insertions(+), 11 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/system_clock_4.f90

diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 6c45e6542f0..3b1a0f9f4f4 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -6774,6 +6774,8 @@ bool
 gfc_check_system_clock (gfc_expr *count, gfc_expr *count_rate,
 			gfc_expr *count_max)
 {
+  int first_int_kind = -1;
+
   if (count != NULL)
 {
   if (!scalar_check (count, 0))
@@ -6788,8 +6790,17 @@ gfc_check_system_clock (gfc_expr *count, gfc_expr *count_rate,
 			  >where))
 	return false;
 
+  if (count->ts.kind < gfc_default_integer_kind
+	  && !gfc_notify_std (GFC_STD_F2023_DEL,
+			  "COUNT argument to SYSTEM_CLOCK at %L "
+			  "with kind smaller than default integer",
+			  >where))
+	return false;
+
   if (!variable_check (count, 0, false))
 	return false;
+
+  first_int_kind = count->ts.kind;
 }
 
   if (count_rate != NULL)
@@ -6816,6 +6827,16 @@ gfc_check_system_clock (gfc_expr *count, gfc_expr *count_rate,
   "SYSTEM_CLOCK at %L has non-default kind",
   _rate->where))
 	return false;
+
+	  if (count_rate->ts.kind < gfc_default_integer_kind
+	  && !gfc_notify_std (GFC_STD_F2023_DEL,
+  "COUNT_RATE argument to SYSTEM_CLOCK at %L "
+  "with kind smaller than default integer",
+  _rate->where))
+	return false;
+
+	  if (first_int_kind < 0)
+	first_int_kind = count_rate->ts.kind;
 	}
 
 }
@@ -6836,6 +6857,35 @@ gfc_check_system_clock (gfc_expr *count, gfc_expr *count_rate,
 
   if (!variable_check (count_max, 2, false))
 	return false;
+
+  if (count_max->ts.kind < gfc_default_integer_kind
+	  && !gfc_notify_std (GFC_STD_F2023_DEL,
+			  "COUNT_MAX argument to SYSTEM_CLOCK at %L "
+			  "with kind smaller than default integer",
+			  _max->where))
+	return false;
+
+  if (first_int_kind < 0)
+	first_int_kind = count_max->ts.kind;
+}
+
+  if (first_int_kind > 0)
+{
+  if (count_rate
+	  && count_rate->ts.type == BT_INTEGER
+	  && 

[PATCH, v3] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]

2023-11-21 Thread Harald Anlauf

Hi Mikael, Steve,

On 11/21/23 12:33, Mikael Morin wrote:

Harald, you mentioned the lack of GFC_STD_F2023_DEL feature group in
your first message, but I don't quite understand why you didn't add one.
  It seems to me the most natural way to do this.


thanks for insisting on this variant.

In my first attack at this problem, I overlooked one place in
libgfortran.h, which I now was able to find and adjust.
Now everything falls into place.


I suggest we emit a warning by default, error with -std=f2023 (I agree
with Steve that we should push towards strict f2023 conformance), and no
diagnostic with -std=gnu or -std=f2018 or lower.


As the majority agrees on this, I accept it.  The attached patch
now does this and fixes the testcases accordingly.


It seems that the solution is to fix the code in the testsuite.


Agreed, these seem to explicitly test mismatching kinds, so add an
option to prevent error.


Done.

I also fixed a few issues in the documentation in gfortran.texi .

As I currently cannot build a full compiler (see PR112643),
patch V3 is not properly regtested yet, but appears to give
results as discussed.

Comments?


Mikael


Thanks,
Harald


diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 6c45e6542f0..e5cf6a495b5 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -4357,6 +4357,9 @@ gfc_check_null (gfc_expr *mold)
   if (mold == NULL)
 return true;
 
+  if (mold->expr_type == EXPR_NULL)
+return true;
+
   if (!variable_check (mold, 0, true))
 return false;
 
@@ -5189,7 +5192,7 @@ is_c_interoperable (gfc_expr *expr, const char **msg, bool c_loc, bool c_f_ptr)
 {
   *msg = NULL;
 
-  if (expr->expr_type == EXPR_NULL)
+  if (expr->expr_type == EXPR_NULL && expr->ts.type == BT_UNKNOWN)
 {
   *msg = "NULL() is not interoperable";
   return false;
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index fc4fe662eab..641edf9d059 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -2387,6 +2387,8 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
   gfc_component *ppc;
   bool codimension = false;
   gfc_array_spec *formal_as;
+  bool pointer_arg, allocatable_arg;
+  bool pre2018 = ((gfc_option.allow_std & GFC_STD_F2018) == 0);
 
   /* If the formal arg has type BT_VOID, it's to one of the iso_c_binding
  procs c_f_pointer or c_f_procpointer, and we need to accept most
@@ -2564,13 +2566,20 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
 	}
 }
 
+  pointer_arg = gfc_expr_attr (actual).pointer;
+  allocatable_arg = gfc_expr_attr (actual).allocatable;
+
   /* F08: 12.5.2.5 Allocatable and pointer dummy variables.  However, this
  is necessary also for F03, so retain error for both.
+ F2018:15.5.2.5 relaxes this constraint to same attributes.
  NOTE: Other type/kind errors pre-empt this error.  Since they are F03
  compatible, no attempt has been made to channel to this one.  */
   if (UNLIMITED_POLY (formal) && !UNLIMITED_POLY (actual)
   && (CLASS_DATA (formal)->attr.allocatable
-	  ||CLASS_DATA (formal)->attr.class_pointer))
+	  || CLASS_DATA (formal)->attr.class_pointer)
+  && (pre2018
+	  || (allocatable_arg && CLASS_DATA (formal)->attr.allocatable)
+	  || (pointer_arg && CLASS_DATA (formal)->attr.class_pointer)))
 {
   if (where)
 	gfc_error ("Actual argument to %qs at %L must be unlimited "
@@ -2710,7 +2719,8 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
   rank_check = where != NULL && !is_elemental && formal_as
 && (formal_as->type == AS_ASSUMED_SHAPE
 	|| formal_as->type == AS_DEFERRED)
-&& actual->expr_type != EXPR_NULL;
+&& !(actual->expr_type == EXPR_NULL
+	 && actual->ts.type == BT_UNKNOWN);
 
   /* Skip rank checks for NO_ARG_CHECK.  */
   if (formal->attr.ext_attr & (1 << EXT_ATTR_NO_ARG_CHECK))
@@ -3184,8 +3194,10 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal,
   gfc_array_ref *actual_arr_ref;
   gfc_array_spec *fas, *aas;
   bool pointer_dummy, pointer_arg, allocatable_arg;
+  bool procptr_dummy, optional_dummy, allocatable_dummy;
 
   bool ok = true;
+  bool pre2018 = ((gfc_option.allow_std & GFC_STD_F2018) == 0);
 
   actual = *ap;
 
@@ -3296,15 +3308,66 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal,
 	  && a->expr->ts.type != BT_ASSUMED)
 	gfc_find_vtab (>expr->ts);
 
+  /* Checks for NULL() actual arguments without MOLD.  */
+  if (a->expr->expr_type == EXPR_NULL && a->expr->ts.type == BT_UNKNOWN)
+	{
+	  /* Interp J3/22-146:
+	 "If the context of the reference to NULL is an 
+	 corresponding to an  dummy argument, MOLD shall be
+	 present."  */
+	  fas = (f->sym->ts.type == BT_CLASS && CLASS_DATA (f->sym)
+		 ? CLASS_DATA (f->sym)->as
+		 : f->sym->as);
+	  if (fas && fas->type == AS_ASSUMED_RANK)
+	{
+	  gfc_error ("Intrinsic % without % argument "
+			 "at %L passed to assumed-rank dummy %qs",
+			 

Re: [PATCH] c++, v3: Implement C++26 P2741R3 - user-generated static_assert messages [PR110348]

2023-11-21 Thread Jason Merrill

On 11/21/23 12:17, Jakub Jelinek wrote:

On Thu, Oct 26, 2023 at 09:21:47PM -0400, Jason Merrill wrote:

On 9/18/23 13:21, Jakub Jelinek wrote:

Here is an updated version of the patch.
Compared to the last version, based on the discussion in the PR, the patch
1) warns (but only that) if size()/data() methods aren't declared
 constexpr/consteval (or implicitly constexpr)


The language requirements also seem to be satisfied by


Thanks, these 2 now work.

Most of review comments incorporated.


+ if (!tree_fits_uhwi_p (message_sz)
+ || ((unsigned HOST_WIDE_INT) (int) tree_to_uhwi (message_sz)
+ != tree_to_uhwi (message_sz)))
+   {
+ error_at (location,
+   "% message % member "
+   "function must be a constant expression");


This can use cxx_constant_value to show what makes it not a
constant-expression.  And also don't assume size is a member function.


In this case, I've split it, if !tree_fits_uhwi_p (message_sz)
(as the value is known to be size_t typed) it really means it isn't
constant expression, while the case when it is too large for host
int is just a restriction we imply on it because we don't really support
too large strings.
Furthermore, I've used cxx_constant_value in addition to the messages
(just removing "member function " part from the wording, and using [%d]
for data or adding "core ").  The reason is that the issues during
constant expression evaluation are typically diagnosed at a different
location and I think it is useful that people know both why it isn't
a constant expression and during evaluation of what it happened.


Agreed.


--- gcc/testsuite/g++.dg/cpp0x/udlit-error1.C.jj2023-09-18 
13:08:31.530448184 +0200
+++ gcc/testsuite/g++.dg/cpp0x/udlit-error1.C   2023-09-18 13:09:47.167440904 
+0200
@@ -11,7 +11,8 @@ void operator""_x(const char *, decltype
   #pragma message "hi"_x   // { dg-warning "string literal with user-defined 
suffix is invalid in this context" }
   extern "C"_x { void g(); } // { dg-error "before user-defined string 
literal" }
-static_assert(true, "foo"_x); // { dg-error "string literal with user-defined 
suffix is invalid in this context|expected" }
+static_assert(true, "foo"_x);// { dg-error "'static_assert' with non-string message 
only available with" "" { target c++23_down } }


This diagnostic message seems unclear for a UDL?


+   // { dg-error "'static_assert' message must be a string 
literal or object with 'size\\\(\\\)' and 'data\\\(\\\)' members" "" { target *-*-* 
} .-1 }


The real diagnostic is this line, not the first one (which is just a pedwarn
about trying to use something C++26 in older code).
And I'm not really sure what to do about it.

The
static_assert (false, "foo"_myd);
in the new testcase shows where it is valid (in C++26 and as extension in
older standards).  For C++26 we could use unevaluated string literal rather
than string literal in the wording, but C++23 and earlier don't have that,
so we would need to say something like non user-defined string literal without
encoding prefix or object with 'size' and 'data' members.



Or do you want to just use
  error_at (location, "% message must be a "
  "unevaluated string literal or object with "
  "% and % members");
wording (even when it is in C++26 term) regardless of the -std= level?


No, I think "unevaluated string literal" will be confusing to users.  I 
guess it's fine as it is, let's just print the type (as commented inline 
below).



   [[deprecated("oof"_x)]]// { dg-error "string literal with user-defined suffix is 
invalid in this context" "" { target c++26 } }
   void


Anyway, here is the updated patch with all the changes, but nothing done
about user-defined literals.

Note, as the placeholder patch hasn't been reviewed, I've moved the
-Wc++26-extensions hunks from that patch to this patch.

2023-11-21  Jakub Jelinek  

PR c++/110348
gcc/
* doc/invoke.texi (-Wno-c++26-extensions): Document.
gcc/c-family/
* c.opt (Wc++26-extensions): New option.
* c-cppbuiltin.cc (c_cpp_builtins): For C++26 predefine
__cpp_static_assert to 202306L rather than 201411L.
gcc/cp/
* parser.cc: Implement C++26 P2741R3 - user-generated static_assert
messages.
(cp_parser_static_assert): Parse message argument as
conditional-expression if it is not a pure string literal or
several of them concatenated followed by closing paren.
* semantics.cc (finish_static_assert): Handle message which is not
STRING_CST.
* pt.cc (tsubst_expr) : Also tsubst_expr
message and make sure that if it wasn't originally STRING_CST, it
isn't after tsubst_expr either.
gcc/testsuite/
* g++.dg/cpp26/static_assert1.C: New test.
* 

Re: [RFC PATCH] Detecting lifetime-dse issues via Valgrind

2023-11-21 Thread Hans-Peter Nilsson
> From: 
> Date: Tue, 24 Oct 2023 17:11:24 +0300

> From: Daniil Frolov 
> 
> PR 66487 is asking to provide sanitizer-like detection for C++ object lifetime
> violations that are worked around with -fno-lifetime-dse in Firefox, LLVM,
> OpenJade.
> 
> The discussion in the PR was centered around extending MSan, but MSan was not
> ported to GCC (and requires rebuilding everything with instrumentation).
> 
> Instead, allow Valgrind to see lifetime boundaries by emitting client requests
> along *this = { CLOBBER }.  The client request marks the "clobbered" memory as
> undefined for Valgrind; clobbering assignments mark the beginning of ctor and
> end of dtor execution for C++ objects.  Hence, attempts to read object storage
> after the destructor, or "pre-initialize" its fields prior to the constructor
> will be caught.

A long time ago, I hacked the first version of
valgrind-testing support into gcc and I think yours is a
great idea!

A natural follow-up then would be making
-fvalgrind-emit-annotations the default when building gcc
*and* --enable-checking=valgrind is in effect (i.e. not just
expanding the in-source annotations but the explicit testing
mode).  No need to cram it into the first version though.

Also, a preprocessor macro when -fvalgrind-emit-annotations
is in effect, may help dealing with quirky corner cases.

I agree with Arsen that if no valgrind headers are found,
just don't build __valgrind_make_mem_undefined and let its
absense be a linker error rather than trapping in
__valgrind_make_mem_undefined.

I think building libgcc __valgrind_make_mem_undefined should
actually be the *default* when valgrind headers are found,
i.e. in absense of --disable-valgrind-annotations.

A hard configure-time error is suitable when an
--enable-valgrind-annotations is explicitly specified in the
absence of valgrind headers.

BTW, if you use AS_IF, beware of its quirks.  See end of
this email-thread with conclusion when libstdc++ was hit:
https://gcc.gnu.org/pipermail/libstdc++/2023-June/056113.html

brgds, H-P


Re: Propagate value ranges of return values

2023-11-21 Thread Thomas Schwinge
Hi Honza!

On 2023-11-21T15:06:54+0100, Jan Hubicka  wrote:
>> After this patch in addition to the problem already reported about
>> vlda1.c and return-value-range-1.c, [...]

> return-value_range-1.c should be fixed now and I do not have vlda1.c in
> my tree.  I will check.

Typo, I suppose; probably 'gcc.dg/vla-1.c' is meant here:

PASS: gcc.dg/vla-1.c (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.dg/vla-1.c scan-tree-dump-times optimized " s=> i" 2

..., and can you please also check if the following also relates to your
commit?  I've not looked into any details, but noticed that you did
adjusted 'gcc.dg/tree-prof/time-profiler-1.c', and
'gcc.dg/tree-prof/time-profiler-2.c', but not
'gcc.dg/tree-prof/time-profiler-3.c':

@@ -142800,9 +142802,9 @@ PASS: gcc.dg/tree-prof/time-profiler-3.c 
compilation,  -fprofile-generate -D_PRO
PASS: gcc.dg/tree-prof/time-profiler-3.c compilation,  -fprofile-use 
-D_PROFILE_USE
PASS: gcc.dg/tree-prof/time-profiler-3.c execution,-fprofile-generate 
-D_PROFILE_GENERATE
PASS: gcc.dg/tree-prof/time-profiler-3.c execution,-fprofile-use 
-D_PROFILE_USE
[-PASS:-]{+FAIL:+} gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times 
profile "Read tp_first_run: 0" 1
PASS: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile "Read 
tp_first_run: 1" 1
[-PASS:-]{+FAIL:+} gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times 
profile "Read tp_first_run: 2" 1

>> > --- a/gcc/testsuite/gcc.dg/tree-prof/time-profiler-1.c
>> > +++ b/gcc/testsuite/gcc.dg/tree-prof/time-profiler-1.c
>> > @@ -1,4 +1,4 @@
>> > -/* { dg-options "-O2 -fdump-ipa-profile" } */
>> > +/* { dg-options "-O2 -fdump-ipa-profile -fno-ipa-vrp" } */

>> > --- a/gcc/testsuite/gcc.dg/tree-prof/time-profiler-2.c
>> > +++ b/gcc/testsuite/gcc.dg/tree-prof/time-profiler-2.c
>> > @@ -1,4 +1,4 @@
>> > -/* { dg-options "-O2 -fdump-ipa-profile" } */
>> > +/* { dg-options "-O2 -fdump-ipa-profile -fno-ipa-vrp" } */


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955


Fix 'gcc.dg/tree-ssa/return-value-range-1.c' for 'char' defaulting to 'unsigned' (was: Propagate value ranges of return values)

2023-11-21 Thread Thomas Schwinge
Hi!

On 2023-11-19T16:05:42+0100, Jan Hubicka  wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/return-value-range-1.c

Pushed to master branch commit a0240662b22312ffb3e3fefb85f258ab0e7010f4
"Fix 'gcc.dg/tree-ssa/return-value-range-1.c' for 'char' defaulting to
'unsigned'", see attached.  On powerpc64le-linux-gnu ('char' defaulting
to 'unsigned') I still saw:

/tmp/ccd1xwD7.o: In function `test':
return-value-range-1.c:(.text+0x50): undefined reference to `link_error'


Grüße
 Thomas


> @@ -0,0 +1,22 @@
> +/* { dg-do ling } */
> +/* { dg-options "-O1 -dump-tree-evrp-details" } */
> +__attribute__ ((__noinline__))
> +int a(char c)
> +{
> + return c;
> +}
> +void link_error ();
> +
> +void
> +test(int d)
> +{
> + if (a(d) > 200)
> + link_error ();
> +}
> +int
> +main(int argc, char **argv)
> +{
> + test(argc);
> + return 0;
> +}
> +/* { dg-final { scan-tree-dump-times "Recording return range" 2 "evrp"} } */


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From a0240662b22312ffb3e3fefb85f258ab0e7010f4 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Tue, 21 Nov 2023 22:07:13 +0100
Subject: [PATCH] Fix 'gcc.dg/tree-ssa/return-value-range-1.c' for 'char'
 defaulting to 'unsigned'

... added in recent commit 53ba8d669550d3a1f809048428b97ca607f95cf5
"inter-procedural value range propagation", fixed in
commit 878a860cae78146d98d7a21612f0bcec0930a9c2
"Fix 'gcc.dg/tree-ssa/return-value-range-1.c'".

	gcc/testsuite/
	* gcc.dg/tree-ssa/return-value-range-1.c: Fix.
---
 gcc/testsuite/gcc.dg/tree-ssa/return-value-range-1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/return-value-range-1.c b/gcc/testsuite/gcc.dg/tree-ssa/return-value-range-1.c
index 74f1a5080bb..97294482c05 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/return-value-range-1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/return-value-range-1.c
@@ -1,7 +1,7 @@
 /* { dg-do link } */
 /* { dg-options "-O2 -fdump-tree-evrp-details" } */
 __attribute__ ((__noinline__))
-int a(char c)
+int a(signed char c)
 {
 	return c;
 }
-- 
2.34.1



Re: [PATCH v2 5/8] c: Do not ignore some forms of -Wimplicit-int in system headers

2023-11-21 Thread Jason Merrill

On 11/15/23 00:13, Sam James wrote:

Florian Weimer  writes:

* Sam James:

Florian Weimer  writes:


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.


The situation with system headers is kind of a mess still. I went
looking for a bug for the -Wimplicit-int behaviour but I only found
PR78000 for -Wimplicit-function-declaration. But in the bug, Joseph
makes the same observation.

I don't suppose he'll want to block on that at this late point though.

Do you know offhand what Clang's behaviour is wrt warnings in system
headers?


Clang ignores these new errors in system headers by default.  I don't
know if that's deliberate or a bug.  Our permerrors are deliberately
active in system headers.  As the test shows, -Wimplicit-int really was
the outlier here because of that check outside the permerror machinery.


Thanks - my assumption was that it was more widespread because of a few
lingering bugs I've seen a few projects complain about, but maybe they
were using old versions or similar.


The permerror behavior was chosen for C++, which was the only front-end 
that used it before; we might want to reconsider if this patch set runs 
into problems with system C headers.


Jason



Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

2023-11-21 Thread Eric Gallager
On Tue, Nov 21, 2023 at 8:51 AM Arsen Arsenović  wrote:
>
>
> Arsen Arsenović  writes:
>
> > Bruno Haible  writes:
> >
> >> Arsen Arsenović wrote:
> >>>   Comparing stages 2 and 3
> >>>   Bootstrap comparison failure!
> >>>   gettext/libasprintf/autosprintf.o differs
> >>>   make[2]: *** [Makefile:23435: compare] Error 1
> >>
> >> You should be able to work around this by passing the additional option
> >> --disable-libasprintf to gettext-runtime/configure. Nothing in GCC needs
> >> libasprintf; therefore there is no need to build it.
> >
> > Ah, sure, that works for me too (note that the fix is to pass
> > -frandom-seed=, according to Jakub, should this show up again).
>
> Indeed, that got a bootstrap to pass.  I've also taken the opportunity
> to check the problems Eric Gallager reported.  The install tree seems
> clean now, and the info et al targets appear to work again.  David,
> Eric, could you check whether the attached patch works for you in the
> scenarios you ran into problems with?  Make sure to fetch gettext-0.22.4
> into your trees.
>

OK, I can confirm that with this patch, my GitHub Actions CI workflow
that had previously been failing is now passing again; you can see the
results here:
https://github.com/cooljeanius/gcc/actions/runs/6948834515/job/18905670645
...and here's a link to a zip of the logfiles generated from the build:
https://github.com/cooljeanius/gcc/suites/18389727422/artifacts/1065350046

>
> If these work, I'll update download_prerequisites and see about posting
> the patch for review.
>
> Thanks, have a lovely day.
>
> >> And while at it, I would also pass --disable-java and --disable-csharp.
> >
> > Yes, I noticed those and disabled them already.
> >
> >> Bruno
>
>
> --
> Arsen Arsenović


Re: [PATCH 3/3] OpenMP: Use enumerators for names of trait-sets and traits

2023-11-21 Thread Sandra Loosemore

On 11/19/23 02:21, Sandra Loosemore wrote:

This patch introduces enumerators to represent trait-set names and
trait names, which makes it easier to use tables to control other
behavior and for switch statements to dispatch on the tags.  The tags
are stored in the same place in the TREE_LIST structure (OMP_TSS_ID or
OMP_TS_ID) and are encoded there as integer constants.

This patch has only been lightly tested and still has at least one bug
that causes an ICE.  :-(


Update: I've tracked down the ICE to me having introduced an incorrect variable 
initialization in omp_context_compute_score.  I'm now looking at fixing 
interfaces to avoid the separate bug in omp_mark_declare_variant that Julian 
reported, and I'll post a revised part 3 in the next day or two.


-Sandra


Re: [PING][PATCH] c++: Introduce the extended attribute for asm declarations

2023-11-21 Thread Xi Ruoyao
On Mon, 2023-11-20 at 16:35 +0800, Julian Waters wrote:
> Hi all, I'd like to ping the following patch
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636924.html

You posted the patch Friday and then pinged it in Monday.  There is
literally zero working days for people to review the patch. 
https://gcc.gnu.org/contribute.html suggests to ping after at least two
weeks.  Sometimes I ping a patch after one week if it's urgent but 0
working days is definitely a no-go.

Also see the contribute patch for some basic style rules of the GCC code
and submitting a patch.  Bad-styled patches are often silently ignored.

On pure technical basis, you need to prove the new feature added is
really useful, for general use cases and not only your own use case. 
Once a feature is in GCC the developers need to pay efforts to maintain
it, so it won't be added unless it will benefit some general use case.

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


Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime

2023-11-21 Thread Simon Wright
On 21 Nov 2023, at 11:22, Iain Sandoe  wrote:
> 
> Hello Simon, Arno,
> 
>> On 17 Nov 2023, at 13:43, Simon Wright  wrote:
>> 
>>> 
 Apple’s naming is definitely confusing in this area!
 
 In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS 
 X variant, 
 which covers OSX, IOS, Watch … ; to determine which kind of device, you 
 have to check the 
 specific define for that device - OSX corresponds to macOS, i.e. laptops, 
 desktops.
 
 In older SDKs (specifically Xcode 3, for macOS Leopard (darwin 9) as 
 mentioned by Iain) 
 TARGET_OS_MAC means code is being generated for "Mac OS", i.e. laptops, 
 desktops as 
 above; TARGET_OS_OSX is undefined (as are TARGET_OS_IOS etc).
 
 If we are compiling for macOS, using a current macOS SDK, then 
 TARGET_OS_MAC is
 set to 1 and TARGET_OS_OSX is set to 1. 
 
 If we were compiling for iOS, using a current iOS SDK as supplied with 
 current Xcode, then 
 TARGET_OS_MAC would be set to 1, TARGET_OS_OSX would be set to 0, and 
 TARGET_OS_IOS would be set to 1.
>>> 
>>> OK so then the following is sufficient for our needs:
>>> 
>>> #elif defined (__APPLE__)
>>> /* By default, macOS volumes are case-insensitive, iOS
>>>volumes are case-sensitive.  */
>>> #if TARGET_OS_IOS
>>>  file_names_case_sensitive_cache = 1;
>>> #else
>>>  file_names_case_sensitive_cache = 0;
>>> #endif
>>> #else /* Neither Windows nor Apple.  */
>>>  file_names_case_sensitive_cache = 1;
>>> #endif
>>> 
>>> We want the default to be 0, and we only care about setting it to 1 on iOS 
>>> for recent
>>> SDKs, the case of an old SDK and iOS isn't interesting at this stage, so 
>>> it's fine if we set
>>> the var to 0 in this scenario.
>> 
>> I can’t speak for Darwin maintainers, so I’ll leave it to Iain to comment on 
>> this suggestion.
> 
> * We are far away from having support for watchOS (32b Arm64) so I think that 
> is a bridge
> that can be crossed later.
> 
> * It seems to me that the proposed solution is better matched to the defaults 
> on macOS/iOS.
> 
> * It would be better to have an automatic solution for folks (like me) who do 
> use case-
> sensitive file systems on macOS, but we do not have the resources right now 
> to figure
> out what is not working on the earlier systems.  I looked briefly, and found 
> that the libcalls
> are thin wrappers on a syscall, so that the different behaviours we are 
> seeing on earlier
> OS versions reflects the kernel’s handling of the provided path, rather than 
> some improvement
> in newer library functions.  That suggests to me that we will need to wrap 
> the call in some more
> complex logic to obtain the correct response.
> 
> So, I think that (with a test across the range of supported OS versions) the 
> proposed
> solution is an incremental improvement and we should take it.
> 
> When there’s a final proposed patch, I can add it into my testing across the 
> systems.
> 
> Iain

Herewith my proposed patch (still in thread, though the subject of the thread 
isn’t still appropriate):

In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current
assumption for __APPLE__ is that file names are case-insensitive
unless __arm__ or __arm64__ are defined, in which case file names are
declared case-sensitive.

The associated comment is
  "By default, we suppose filesystems aren't case sensitive on
  Windows and Darwin (but they are on arm-darwin)."

This means that on aarch64-apple-darwin, file names are treated as
case-sensitive, which is not the default case.

The true default position is that macOS file systems are
case-insensitive, iOS file systems are case-sensitive.

Apple provide a header file  which permits a
compile-time check for the compiler target (e.g. OSX vs IOS); if
TARGET_OS_IOS is defined as 1, this is a build for iOS.

gcc/ada/Changelog:

2023-11-21 Simon Wright mailto:si...@pushface.org>>

  * gcc/ada/adaint.c (__gnat_get_file_names_case_sensitive):
  Split out the __APPLE__ check and remove the checks for __arm__,
  __arm64__.
  For Apple, file names are by default case-insensitive unless
  TARGET_OS_IOS is set.

Signed-off-by: Simon Wright 
---
 gcc/ada/adaint.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
index bb4ed2607e5..0222791ed68 100644
--- a/gcc/ada/adaint.c
+++ b/gcc/ada/adaint.c
@@ -84,7 +84,7 @@
 #endif /* VxWorks */
 
 #if defined (__APPLE__)
-#include 
+#include 
 #endif
 
 #if defined (__hpux__)
@@ -613,11 +613,18 @@ __gnat_get_file_names_case_sensitive (void)
   else
{
  /* By default, we suppose filesystems aren't case sensitive on
-Windows and Darwin (but they are on arm-darwin).  */
-#if defined (WINNT) || defined (__DJGPP__) \
-  || (defined (__APPLE__) && !(defined (__arm__) || defined (__arm64__)))
+Windows or DOS.  */
+#if defined (WINNT) || defined 

[committed] sanitizer: Fix build on SPARC/Solaris with Solaris as [PR112562]

2023-11-21 Thread Jakub Jelinek
Hi!

Solaris as apparently doesn't accept %function and requires @function
instead.

This cherry-picks upstream commit.

Bootstrapped/regtested on x86_64-linux and i686-linux and built tested
on sparc-solaris2.11, committed to trunk as obvious.

2023-11-21  Jakub Jelinek  

PR sanitizer/112562
* sanitizer_common/sanitizer_asm.h: Cherry-pick llvm-project revision
a855a16a02e76a0f4192c038bb64f3773947a2f7.
* interception/interception.h: Likewise.

--- libsanitizer/sanitizer_common/sanitizer_asm.h.jj2023-11-15 
17:19:11.507783822 +0100
+++ libsanitizer/sanitizer_common/sanitizer_asm.h   2023-11-20 
18:16:48.740201609 +0100
@@ -62,7 +62,11 @@
 
 #if !defined(__APPLE__)
 # define ASM_HIDDEN(symbol) .hidden symbol
-# define ASM_TYPE_FUNCTION(symbol) .type symbol, %function
+# if defined(__arm__) || defined(__aarch64__)
+#  define ASM_TYPE_FUNCTION(symbol) .type symbol, %function
+# else
+#  define ASM_TYPE_FUNCTION(symbol) .type symbol, @function
+# endif
 # define ASM_SIZE(symbol) .size symbol, .-symbol
 # define ASM_SYMBOL(symbol) symbol
 # define ASM_SYMBOL_INTERCEPTOR(symbol) symbol
--- libsanitizer/interception/interception.h.jj 2023-11-15 17:19:11.505783850 
+0100
+++ libsanitizer/interception/interception.h2023-11-20 18:16:48.736201664 
+0100
@@ -185,6 +185,11 @@ const interpose_substitution substitutio
 #  else
 #   define __ASM_WEAK_WRAPPER(func) ".weak " #func "\n"
 #  endif  // SANITIZER_FREEBSD || SANITIZER_NETBSD
+#  if defined(__arm__) || defined(__aarch64__)
+#   define ASM_TYPE_FUNCTION_STR "%function"
+#  else
+#   define ASM_TYPE_FUNCTION_STR "@function"
+#  endif
 // Keep trampoline implementation in sync with sanitizer_common/sanitizer_asm.h
 #  define DECLARE_WRAPPER(ret_type, func, ...) 
\
  extern "C" ret_type func(__VA_ARGS__);
\
@@ -196,7 +201,8 @@ const interpose_substitution substitutio
__ASM_WEAK_WRAPPER(func)
\
".set " #func ", " SANITIZER_STRINGIFY(TRAMPOLINE(func)) "\n"   
\
".globl " SANITIZER_STRINGIFY(TRAMPOLINE(func)) "\n"
\
-   ".type  " SANITIZER_STRINGIFY(TRAMPOLINE(func)) ", %function\n" 
\
+   ".type  " SANITIZER_STRINGIFY(TRAMPOLINE(func)) ", "
\
+ ASM_TYPE_FUNCTION_STR "\n"
\
SANITIZER_STRINGIFY(TRAMPOLINE(func)) ":\n" 
\
SANITIZER_STRINGIFY(CFI_STARTPROC) "\n" 
\
SANITIZER_STRINGIFY(ASM_TAIL_CALL) " __interceptor_"
\

Jakub



Re: [PATCH] vect: Allow reduc_index != 1 for COND_OPs.

2023-11-21 Thread Robin Dapp
>> Bootstrapped and regtested on aarch64 and regtested on riscv.  x86 is
>> still running.

Just to confirm:  x86 bootstrap and regtest unchanged.  Going to commit
it soon.

Regards
 Robin



[PATCH] RISC-V: testsuite: Remove redundant vector_hw and zvfh_hw.

2023-11-21 Thread Robin Dapp
Hi,

this removes the now-redundant vector_hw and zvfh_hw checks in the
testsuite.

Regards
 Robin

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/binop/copysign-zvfh-run.c:
Remove zvfh_hw.
* gcc.target/riscv/rvv/autovec/binop/vadd-zvfh-run.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vdiv-zvfh-run.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vmax-zvfh-run.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vmin-zvfh-run.c: Ditto.
* gcc.target/riscv/rvv/autovec/binop/vmul-zvfh-run.c: Ditto.
* gcc.target/riscv/rvv/autovec/cond/cond_copysign-zvfh-run.c:
Ditto.
* gcc.target/riscv/rvv/autovec/struct/struct_vect_run-10.c:
Ditto.
* gcc.target/riscv/rvv/autovec/struct/struct_vect_run-6.c: Allow
overriding N.
* gcc.target/riscv/rvv/autovec/unop/abs-zvfh-run.c: Remove
zvfh_hw.
* gcc.target/riscv/rvv/autovec/unop/vneg-zvfh-run.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-10.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-11.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-12.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-2.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-3.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-5.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-6.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-7.c: Ditto.
* gcc.target/riscv/rvv/autovec/widen/widen_run_zvfh-8.c: Ditto.
* lib/target-supports.exp: Ditto.
---
 .../rvv/autovec/binop/copysign-zvfh-run.c |  2 +-
 .../riscv/rvv/autovec/binop/vadd-zvfh-run.c   |  2 +-
 .../riscv/rvv/autovec/binop/vdiv-zvfh-run.c   |  2 +-
 .../riscv/rvv/autovec/binop/vmax-zvfh-run.c   |  2 +-
 .../riscv/rvv/autovec/binop/vmin-zvfh-run.c   |  2 +-
 .../riscv/rvv/autovec/binop/vmul-zvfh-run.c   |  2 +-
 .../rvv/autovec/cond/cond_copysign-zvfh-run.c |  2 +-
 .../rvv/autovec/struct/struct_vect_run-10.c   |  5 +-
 .../rvv/autovec/struct/struct_vect_run-6.c|  2 +
 .../riscv/rvv/autovec/unop/abs-zvfh-run.c |  2 +-
 .../riscv/rvv/autovec/unop/vneg-zvfh-run.c|  2 +-
 .../rvv/autovec/widen/widen_run_zvfh-1.c  |  2 +-
 .../rvv/autovec/widen/widen_run_zvfh-10.c |  2 +-
 .../rvv/autovec/widen/widen_run_zvfh-11.c |  2 +-
 .../rvv/autovec/widen/widen_run_zvfh-12.c |  2 +-
 .../rvv/autovec/widen/widen_run_zvfh-2.c  |  2 +-
 .../rvv/autovec/widen/widen_run_zvfh-3.c  |  2 +-
 .../rvv/autovec/widen/widen_run_zvfh-5.c  |  2 +-
 .../rvv/autovec/widen/widen_run_zvfh-6.c  |  2 +-
 .../rvv/autovec/widen/widen_run_zvfh-7.c  |  2 +-
 .../rvv/autovec/widen/widen_run_zvfh-8.c  |  2 +-
 gcc/testsuite/lib/target-supports.exp | 51 +--
 22 files changed, 26 insertions(+), 70 deletions(-)

diff --git 
a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/copysign-zvfh-run.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/copysign-zvfh-run.c
index 3bf64ab72ef..e71b6589fc3 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/copysign-zvfh-run.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/copysign-zvfh-run.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { riscv_v && riscv_zvfh_hw } } } */
+/* { dg-do run { target { riscv_v && riscv_zvfh } } } */
 /* { dg-additional-options "-std=c99 -fno-vect-cost-model 
--param=riscv-autovec-preference=fixed-vlmax -ffast-math" } */
 
 #include "copysign-template.h"
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vadd-zvfh-run.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vadd-zvfh-run.c
index 2a8618ad09b..6c2d096e103 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vadd-zvfh-run.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vadd-zvfh-run.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { riscv_v && riscv_zvfh_hw } } } */
+/* { dg-do run { target { riscv_v && riscv_zvfh } } } */
 /* { dg-additional-options "-std=c99 -fno-vect-cost-model 
--param=riscv-autovec-preference=fixed-vlmax -ffast-math" } */
 
 #include "vadd-template.h"
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vdiv-zvfh-run.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vdiv-zvfh-run.c
index 1b8e69259ca..c9f9d83ccb8 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vdiv-zvfh-run.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vdiv-zvfh-run.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { riscv_v && riscv_zvfh_hw } } } */
+/* { dg-do run { target { riscv_v && riscv_zvfh } } } */
 /* { dg-additional-options "-std=c99 -fno-vect-cost-model 
--param=riscv-autovec-preference=fixed-vlmax -ffast-math" } */
 
 #include "vdiv-template.h"
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vmax-zvfh-run.c 

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

2023-11-21 Thread Björn Schäpers
I'll guess it is not needed here, but otherwise  defines the macros 
max and min, they then conflict e.g. with C++'s std::max/std::min. So I consider 
it best practice to always define it, before including .


Am 20.11.2023 um 21:07 schrieb Eli Zaretskii:

Date: Mon, 20 Nov 2023 20:57:38 +0100
Cc: gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
From: Björn Schäpers 

+#ifndef NOMINMAX
+#define NOMINMAX
+#endif


Why is this part needed?

Otherwise, LGTM, thanks.  (But I'm don't have the approval rights, so
please wait for Ian to chime in.)




Re: [PATCH v2] ifcvt: Handle multiple rewired regs and refactor noce_convert_multiple_sets

2023-11-21 Thread Manolis Tsamis
I have bootstrapped and checked for no testsuite regressions on x86 and aarch64.

Thanks,
Manolis

On Tue, Nov 21, 2023 at 8:00 PM Manolis Tsamis  wrote:
>
> The existing implementation of need_cmov_or_rewire and
> noce_convert_multiple_sets_1 assumes that sets are either REG or SUBREG.
> This commit enchances them so they can handle/rewire arbitrary set statements.
>
> To do that a new helper struct noce_multiple_sets_info is introduced which is
> used by noce_convert_multiple_sets and its helper functions. This results in
> cleaner function signatures, improved efficientcy (a number of vecs and hash
> set/map are replaced with a single vec of struct) and simplicity.
>
> gcc/ChangeLog:
>
> * ifcvt.cc (need_cmov_or_rewire): Renamed 
> init_noce_multiple_sets_info.
> (init_noce_multiple_sets_info): Initialize noce_multiple_sets_info.
> (noce_convert_multiple_sets_1): Use noce_multiple_sets_info and handle
> rewiring of multiple registers.
> (noce_convert_multiple_sets): Updated to use noce_multiple_sets_info.
> * ifcvt.h (struct noce_multiple_sets_info): Introduce new struct
> noce_multiple_sets_info to store info for noce_convert_multiple_sets.
>
> Signed-off-by: Manolis Tsamis 
> ---
>
> Changes in v2:
> - Made standalone patch.
> - Better comments, some more checks.
>
>  gcc/ifcvt.cc | 252 +++
>  gcc/ifcvt.h  |  16 
>  2 files changed, 129 insertions(+), 139 deletions(-)
>
> diff --git a/gcc/ifcvt.cc b/gcc/ifcvt.cc
> index a0af553b9ff..9486d54de34 100644
> --- a/gcc/ifcvt.cc
> +++ b/gcc/ifcvt.cc
> @@ -98,14 +98,10 @@ static bool dead_or_predicable (basic_block, basic_block, 
> basic_block,
> edge, bool);
>  static void noce_emit_move_insn (rtx, rtx);
>  static rtx_insn *block_has_only_trap (basic_block);
> -static void need_cmov_or_rewire (basic_block, hash_set *,
> -hash_map *);
> +static void init_noce_multiple_sets_info (basic_block,
> +  auto_delete_vec &);
>  static bool noce_convert_multiple_sets_1 (struct noce_if_info *,
> - hash_set *,
> - hash_map *,
> - auto_vec *,
> - auto_vec *,
> - auto_vec *, int *);
> +  auto_delete_vec &, int *);
>
>  /* Count the number of non-jump active insns in BB.  */
>
> @@ -3270,24 +3266,13 @@ noce_convert_multiple_sets (struct noce_if_info 
> *if_info)
>rtx x = XEXP (cond, 0);
>rtx y = XEXP (cond, 1);
>
> -  /* The true targets for a conditional move.  */
> -  auto_vec targets;
> -  /* The temporaries introduced to allow us to not consider register
> - overlap.  */
> -  auto_vec temporaries;
> -  /* The insns we've emitted.  */
> -  auto_vec unmodified_insns;
> -
> -  hash_set need_no_cmov;
> -  hash_map rewired_src;
> -
> -  need_cmov_or_rewire (then_bb, _no_cmov, _src);
> +  auto_delete_vec insn_info;
> +  init_noce_multiple_sets_info (then_bb, insn_info);
>
>int last_needs_comparison = -1;
>
>bool ok = noce_convert_multiple_sets_1
> -(if_info, _no_cmov, _src, , ,
> - _insns, _needs_comparison);
> +(if_info, insn_info, _needs_comparison);
>if (!ok)
>return false;
>
> @@ -3302,8 +3287,7 @@ noce_convert_multiple_sets (struct noce_if_info 
> *if_info)
>end_sequence ();
>start_sequence ();
>ok = noce_convert_multiple_sets_1
> -   (if_info, _no_cmov, _src, , ,
> -_insns, _needs_comparison);
> +   (if_info, insn_info, _needs_comparison);
>/* Actually we should not fail anymore if we reached here,
>  but better still check.  */
>if (!ok)
> @@ -3312,12 +3296,12 @@ noce_convert_multiple_sets (struct noce_if_info 
> *if_info)
>
>/* We must have seen some sort of insn to insert, otherwise we were
>   given an empty BB to convert, and we can't handle that.  */
> -  gcc_assert (!unmodified_insns.is_empty ());
> +  gcc_assert (!insn_info.is_empty ());
>
>/* Now fixup the assignments.  */
> -  for (unsigned i = 0; i < targets.length (); i++)
> -if (targets[i] != temporaries[i])
> -  noce_emit_move_insn (targets[i], temporaries[i]);
> +  for (unsigned i = 0; i < insn_info.length (); i++)
> +if (insn_info[i]->target != insn_info[i]->temporary)
> +  noce_emit_move_insn (insn_info[i]->target, insn_info[i]->temporary);
>
>/* Actually emit the sequence if it isn't too expensive.  */
>rtx_insn *seq = get_insns ();
> @@ -3332,10 +3316,10 @@ noce_convert_multiple_sets (struct noce_if_info 
> *if_info)
>  set_used_flags (insn);
>
>/* Mark all our temporaries and targets as used.  */
> -  for (unsigned i = 0; i < targets.length (); i++)
> +  for (unsigned i = 0; i < insn_info.length (); i++)
>  {
> -  set_used_flags (temporaries[i]);
> -  

Re: [PATCH v3 3/4] ifcvt: Handle multiple rewired regs and refactor noce_convert_multiple_sets

2023-11-21 Thread Manolis Tsamis
I have made this independent from the rest of the series, cleaned up
some comments and moved some code to its original position.
Re-submitted as
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637660.html.

Manolis

On Mon, Nov 13, 2023 at 2:40 PM Manolis Tsamis  wrote:
>
> Hi Jeff,
>
> Indeed, that sounds like a good idea. I will make this separate and
> send it after the required testing.
> I'll see what can be done about a testcase.
>
> Best,
> Manolis
>
> On Sat, Nov 11, 2023 at 1:20 AM Jeff Law  wrote:
> >
> >
> >
> > On 8/30/23 04:13, Manolis Tsamis wrote:
> > > The existing implementation of need_cmov_or_rewire and
> > > noce_convert_multiple_sets_1 assumes that sets are either REG or SUBREG.
> > > This commit enchances them so they can handle/rewire arbitrary set 
> > > statements.
> > >
> > > To do that a new helper struct noce_multiple_sets_info is introduced 
> > > which is
> > > used by noce_convert_multiple_sets and its helper functions. This results 
> > > in
> > > cleaner function signatures, improved efficientcy (a number of vecs and 
> > > hash
> > > set/map are replaced with a single vec of struct) and simplicity.
> > >
> > > gcc/ChangeLog:
> > >
> > >   * ifcvt.cc (need_cmov_or_rewire): Renamed 
> > > init_noce_multiple_sets_info.
> > >   (init_noce_multiple_sets_info): Initialize noce_multiple_sets_info.
> > >   (noce_convert_multiple_sets_1): Use noce_multiple_sets_info and 
> > > handle
> > >   rewiring of multiple registers.
> > >   (noce_convert_multiple_sets): Updated to use 
> > > noce_multiple_sets_info.
> > >   * ifcvt.h (struct noce_multiple_sets_info): Introduce new struct
> > >   noce_multiple_sets_info to store info for 
> > > noce_convert_multiple_sets.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > >   * gcc.target/aarch64/ifcvt_multiple_sets_rewire.c: New test.
> > So this seems like (in theory) it could move forward independently.  The
> > handling of arbitrary statements code wouldn't be exercised yet, but
> > that's OK IMHO as I don't think anyone is fundamentally against trying
> > to handle additional kinds of statements.
> >
> > So my suggestion would be to bootstrap & regression test this
> > independently.  AFAICT this should have no functional change if it were
> > to go in on its own.  Note the testsuite entry might not be applicable
> > if this were to go in on its own and would need to roll into another
> > patch in the series.
> >
> >
> > Jeff


Re: libstdc++: Turn memmove to memcpy in vector reallocations

2023-11-21 Thread Marc Glisse

On Tue, 21 Nov 2023, Jonathan Wakely wrote:


CC Marc Glisse who added the relocation support. He might recall why
we use memmove when all uses are for newly-allocated storage, which
cannot overlap the existing storage.


Going back a bit:

https://gcc.gnu.org/pipermail/gcc-patches/2019-April/520658.html

"I think the call to memmove in __relocate_a_1 could probably be
memcpy (I don't remember why I chose memmove)"

Going back a bit further:

https://gcc.gnu.org/pipermail/gcc-patches/2018-September/505800.html

"I had to add a special case for trivial types, using memmove, to avoid
perf regressions, since relocation takes precedence over the old path that
is specialized to call memmove."

So the reason seems to be because vector already used memmove before my 
patch. You can dig further if you want to check why that is ;-)


--
Marc Glisse


Re: [PATCH v3 4/4] ifcvt: Remove obsolete code for subreg handling in noce_convert_multiple_sets

2023-11-21 Thread Manolis Tsamis
Retested, made independent of the rest of the series and submitted as
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637662.html.

Manolis

On Mon, Nov 13, 2023 at 2:43 PM Manolis Tsamis  wrote:
>
> Yes, my finding back then was that this is leftover code from the
> initial implementation, nothing to do with the rest of the changes.
> I will first re-evaluate this and test it separately from the other
> series. If all is good I'll let you know so we can proceed.
>
> Manolis
>
> On Sat, Nov 11, 2023 at 12:03 AM Jeff Law  wrote:
> >
> >
> >
> > On 8/30/23 04:14, Manolis Tsamis wrote:
> > > This code used to handle register replacement issues with SUBREG before
> > > simplify_replace_rtx was introduced. This should not be needed anymore as
> > > new_val has the correct mode and that should be preserved by
> > > simplify_replace_rtx.
> > >
> > > gcc/ChangeLog:
> > >
> > >   * ifcvt.cc (noce_convert_multiple_sets_1): Remove old code.
> > So is it the case that this code is supposed to no longer be needed as a
> > result of your kit or it is unnecessary independent of patches 1..3?  If
> > the latter then it's OK for the trunk now.
> >
> > Jeff


Re: [PATCH v2] ifcvt: Remove obsolete code for subreg handling in noce_convert_multiple_sets

2023-11-21 Thread Manolis Tsamis
Bootstrapped and tested on x86 and aarch64. This only assumes that the
mode of what simplify_replace_rtx returns is the same with its first
argument.

Thanks,
Manolis

On Tue, Nov 21, 2023 at 8:04 PM Manolis Tsamis  wrote:
>
> This code used to handle SUBREG for register replacement when ifcvt was doing
> the replacements manually. This special handling is not needed anymore
> because simplify_replace_rtx is used for the replacements and it properly
> handles these cases.
>
> gcc/ChangeLog:
>
> * ifcvt.cc (noce_convert_multiple_sets_1): Remove old code.
>
> Signed-off-by: Manolis Tsamis 
> ---
>
> Changes in v2:
> - Made standalone patch.
>
>  gcc/ifcvt.cc | 38 --
>  1 file changed, 38 deletions(-)
>
> diff --git a/gcc/ifcvt.cc b/gcc/ifcvt.cc
> index a0af553b9ff..be42609a848 100644
> --- a/gcc/ifcvt.cc
> +++ b/gcc/ifcvt.cc
> @@ -3492,44 +3492,6 @@ noce_convert_multiple_sets_1 (struct noce_if_info 
> *if_info,
>if (if_info->then_else_reversed)
> std::swap (old_val, new_val);
>
> -
> -  /* We allow simple lowpart register subreg SET sources in
> -bb_ok_for_noce_convert_multiple_sets.  Be careful when processing
> -sequences like:
> -(set (reg:SI r1) (reg:SI r2))
> -(set (reg:HI r3) (subreg:HI (r1)))
> -For the second insn new_val or old_val (r1 in this example) will be
> -taken from the temporaries and have the wider mode which will not
> -match with the mode of the other source of the conditional move, so
> -we'll end up trying to emit r4:HI = cond ? (r1:SI) : (r3:HI).
> -Wrap the two cmove operands into subregs if appropriate to prevent
> -that.  */
> -
> -  if (!CONSTANT_P (new_val)
> - && GET_MODE (new_val) != GET_MODE (temp))
> -   {
> - machine_mode src_mode = GET_MODE (new_val);
> - machine_mode dst_mode = GET_MODE (temp);
> - if (!partial_subreg_p (dst_mode, src_mode))
> -   {
> - end_sequence ();
> - return false;
> -   }
> - new_val = lowpart_subreg (dst_mode, new_val, src_mode);
> -   }
> -  if (!CONSTANT_P (old_val)
> - && GET_MODE (old_val) != GET_MODE (temp))
> -   {
> - machine_mode src_mode = GET_MODE (old_val);
> - machine_mode dst_mode = GET_MODE (temp);
> - if (!partial_subreg_p (dst_mode, src_mode))
> -   {
> - end_sequence ();
> - return false;
> -   }
> - old_val = lowpart_subreg (dst_mode, old_val, src_mode);
> -   }
> -
>/* Try emitting a conditional move passing the backend the
>  canonicalized comparison.  The backend is then able to
>  recognize expressions like
> --
> 2.34.1
>


[PATCH] mingw: Exclude utf8 manifest [PR111170, PR108865]

2023-11-21 Thread Costas Argyris
This patch makes the inclusion of the utf8 manifest on the
mingw hosts optional by introducing the configure option
--disable-win32-utf8-manifest (has no effect on non-mingw
hosts).

Bootstrapped OK on i686-w64-mingw32 and x86_64-w64-mingw32
with and without --disable-win32-utf8-manifest.

Costas


Exclude-win32-utf8-manifest.patch
Description: Binary data


[PATCH v2] ifcvt: Remove obsolete code for subreg handling in noce_convert_multiple_sets

2023-11-21 Thread Manolis Tsamis
This code used to handle SUBREG for register replacement when ifcvt was doing
the replacements manually. This special handling is not needed anymore
because simplify_replace_rtx is used for the replacements and it properly
handles these cases.

gcc/ChangeLog:

* ifcvt.cc (noce_convert_multiple_sets_1): Remove old code.

Signed-off-by: Manolis Tsamis 
---

Changes in v2:
- Made standalone patch.

 gcc/ifcvt.cc | 38 --
 1 file changed, 38 deletions(-)

diff --git a/gcc/ifcvt.cc b/gcc/ifcvt.cc
index a0af553b9ff..be42609a848 100644
--- a/gcc/ifcvt.cc
+++ b/gcc/ifcvt.cc
@@ -3492,44 +3492,6 @@ noce_convert_multiple_sets_1 (struct noce_if_info 
*if_info,
   if (if_info->then_else_reversed)
std::swap (old_val, new_val);
 
-
-  /* We allow simple lowpart register subreg SET sources in
-bb_ok_for_noce_convert_multiple_sets.  Be careful when processing
-sequences like:
-(set (reg:SI r1) (reg:SI r2))
-(set (reg:HI r3) (subreg:HI (r1)))
-For the second insn new_val or old_val (r1 in this example) will be
-taken from the temporaries and have the wider mode which will not
-match with the mode of the other source of the conditional move, so
-we'll end up trying to emit r4:HI = cond ? (r1:SI) : (r3:HI).
-Wrap the two cmove operands into subregs if appropriate to prevent
-that.  */
-
-  if (!CONSTANT_P (new_val)
- && GET_MODE (new_val) != GET_MODE (temp))
-   {
- machine_mode src_mode = GET_MODE (new_val);
- machine_mode dst_mode = GET_MODE (temp);
- if (!partial_subreg_p (dst_mode, src_mode))
-   {
- end_sequence ();
- return false;
-   }
- new_val = lowpart_subreg (dst_mode, new_val, src_mode);
-   }
-  if (!CONSTANT_P (old_val)
- && GET_MODE (old_val) != GET_MODE (temp))
-   {
- machine_mode src_mode = GET_MODE (old_val);
- machine_mode dst_mode = GET_MODE (temp);
- if (!partial_subreg_p (dst_mode, src_mode))
-   {
- end_sequence ();
- return false;
-   }
- old_val = lowpart_subreg (dst_mode, old_val, src_mode);
-   }
-
   /* Try emitting a conditional move passing the backend the
 canonicalized comparison.  The backend is then able to
 recognize expressions like
-- 
2.34.1



[Committed] gfortran: Rely on dg-do-what-default to avoid running pr85853.f90, pr107254.f90 and vect-alias-check-1.F90 on non-vector targets

2023-11-21 Thread Patrick O'Neill



On 11/18/23 20:09, Jeff Law wrote:



On 11/15/23 17:03, Patrick O'Neill wrote:

Ping.

Testsuite fixup similar to:
https://inbox.sourceware.org/gcc-patches/974e9e5e-8f07-46dd-b9b9-db8aa4685...@gmail.com/T/#t 

https://inbox.sourceware.org/gcc-patches/7e78cd70-70c9-41b1-8a98-6977a1034...@rivosinc.com/T/#t 


OK.


Jeff


Committed.

Patrick



[PATCH v2] ifcvt: Handle multiple rewired regs and refactor noce_convert_multiple_sets

2023-11-21 Thread Manolis Tsamis
The existing implementation of need_cmov_or_rewire and
noce_convert_multiple_sets_1 assumes that sets are either REG or SUBREG.
This commit enchances them so they can handle/rewire arbitrary set statements.

To do that a new helper struct noce_multiple_sets_info is introduced which is
used by noce_convert_multiple_sets and its helper functions. This results in
cleaner function signatures, improved efficientcy (a number of vecs and hash
set/map are replaced with a single vec of struct) and simplicity.

gcc/ChangeLog:

* ifcvt.cc (need_cmov_or_rewire): Renamed init_noce_multiple_sets_info.
(init_noce_multiple_sets_info): Initialize noce_multiple_sets_info.
(noce_convert_multiple_sets_1): Use noce_multiple_sets_info and handle
rewiring of multiple registers.
(noce_convert_multiple_sets): Updated to use noce_multiple_sets_info.
* ifcvt.h (struct noce_multiple_sets_info): Introduce new struct
noce_multiple_sets_info to store info for noce_convert_multiple_sets.

Signed-off-by: Manolis Tsamis 
---

Changes in v2:
- Made standalone patch.
- Better comments, some more checks.

 gcc/ifcvt.cc | 252 +++
 gcc/ifcvt.h  |  16 
 2 files changed, 129 insertions(+), 139 deletions(-)

diff --git a/gcc/ifcvt.cc b/gcc/ifcvt.cc
index a0af553b9ff..9486d54de34 100644
--- a/gcc/ifcvt.cc
+++ b/gcc/ifcvt.cc
@@ -98,14 +98,10 @@ static bool dead_or_predicable (basic_block, basic_block, 
basic_block,
edge, bool);
 static void noce_emit_move_insn (rtx, rtx);
 static rtx_insn *block_has_only_trap (basic_block);
-static void need_cmov_or_rewire (basic_block, hash_set *,
-hash_map *);
+static void init_noce_multiple_sets_info (basic_block,
+  auto_delete_vec &);
 static bool noce_convert_multiple_sets_1 (struct noce_if_info *,
- hash_set *,
- hash_map *,
- auto_vec *,
- auto_vec *,
- auto_vec *, int *);
+  auto_delete_vec &, int *);
 
 /* Count the number of non-jump active insns in BB.  */
 
@@ -3270,24 +3266,13 @@ noce_convert_multiple_sets (struct noce_if_info 
*if_info)
   rtx x = XEXP (cond, 0);
   rtx y = XEXP (cond, 1);
 
-  /* The true targets for a conditional move.  */
-  auto_vec targets;
-  /* The temporaries introduced to allow us to not consider register
- overlap.  */
-  auto_vec temporaries;
-  /* The insns we've emitted.  */
-  auto_vec unmodified_insns;
-
-  hash_set need_no_cmov;
-  hash_map rewired_src;
-
-  need_cmov_or_rewire (then_bb, _no_cmov, _src);
+  auto_delete_vec insn_info;
+  init_noce_multiple_sets_info (then_bb, insn_info);
 
   int last_needs_comparison = -1;
 
   bool ok = noce_convert_multiple_sets_1
-(if_info, _no_cmov, _src, , ,
- _insns, _needs_comparison);
+(if_info, insn_info, _needs_comparison);
   if (!ok)
   return false;
 
@@ -3302,8 +3287,7 @@ noce_convert_multiple_sets (struct noce_if_info *if_info)
   end_sequence ();
   start_sequence ();
   ok = noce_convert_multiple_sets_1
-   (if_info, _no_cmov, _src, , ,
-_insns, _needs_comparison);
+   (if_info, insn_info, _needs_comparison);
   /* Actually we should not fail anymore if we reached here,
 but better still check.  */
   if (!ok)
@@ -3312,12 +3296,12 @@ noce_convert_multiple_sets (struct noce_if_info 
*if_info)
 
   /* We must have seen some sort of insn to insert, otherwise we were
  given an empty BB to convert, and we can't handle that.  */
-  gcc_assert (!unmodified_insns.is_empty ());
+  gcc_assert (!insn_info.is_empty ());
 
   /* Now fixup the assignments.  */
-  for (unsigned i = 0; i < targets.length (); i++)
-if (targets[i] != temporaries[i])
-  noce_emit_move_insn (targets[i], temporaries[i]);
+  for (unsigned i = 0; i < insn_info.length (); i++)
+if (insn_info[i]->target != insn_info[i]->temporary)
+  noce_emit_move_insn (insn_info[i]->target, insn_info[i]->temporary);
 
   /* Actually emit the sequence if it isn't too expensive.  */
   rtx_insn *seq = get_insns ();
@@ -3332,10 +3316,10 @@ noce_convert_multiple_sets (struct noce_if_info 
*if_info)
 set_used_flags (insn);
 
   /* Mark all our temporaries and targets as used.  */
-  for (unsigned i = 0; i < targets.length (); i++)
+  for (unsigned i = 0; i < insn_info.length (); i++)
 {
-  set_used_flags (temporaries[i]);
-  set_used_flags (targets[i]);
+  set_used_flags (insn_info[i]->temporary);
+  set_used_flags (insn_info[i]->target);
 }
 
   set_used_flags (cond);
@@ -3354,7 +3338,7 @@ noce_convert_multiple_sets (struct noce_if_info *if_info)
   return false;
 
   emit_insn_before_setloc (seq, if_info->jump,
-  INSN_LOCATION (unmodified_insns.last ()));

Re: [PATCH] c++, v3: Implement C++26 P2741R3 - user-generated static_assert messages [PR110348]

2023-11-21 Thread Jakub Jelinek
On Tue, Nov 21, 2023 at 06:17:02PM +0100, Jakub Jelinek wrote:
> The
> static_assert (false, "foo"_myd);
> in the new testcase shows where it is valid (in C++26 and as extension in
> older standards).  For C++26 we could use unevaluated string literal rather
> than string literal in the wording, but C++23 and earlier don't have that,
> so we would need to say something like non user-defined string literal without
> encoding prefix or object with 'size' and 'data' members.

Or do you want to just use
  error_at (location, "% message must be a "
  "unevaluated string literal or object with "
  "% and % members");
wording (even when it is in C++26 term) regardless of the -std= level?

Jakub



[PATCH] c++, v3: Implement C++26 P2741R3 - user-generated static_assert messages [PR110348]

2023-11-21 Thread Jakub Jelinek
On Thu, Oct 26, 2023 at 09:21:47PM -0400, Jason Merrill wrote:
> On 9/18/23 13:21, Jakub Jelinek wrote:
> > Here is an updated version of the patch.
> > Compared to the last version, based on the discussion in the PR, the patch
> > 1) warns (but only that) if size()/data() methods aren't declared
> > constexpr/consteval (or implicitly constexpr)
> 
> The language requirements also seem to be satisfied by

Thanks, these 2 now work.

Most of review comments incorporated.

> > + if (!tree_fits_uhwi_p (message_sz)
> > + || ((unsigned HOST_WIDE_INT) (int) tree_to_uhwi (message_sz)
> > + != tree_to_uhwi (message_sz)))
> > +   {
> > + error_at (location,
> > +   "% message % member "
> > +   "function must be a constant expression");
> 
> This can use cxx_constant_value to show what makes it not a
> constant-expression.  And also don't assume size is a member function.

In this case, I've split it, if !tree_fits_uhwi_p (message_sz)
(as the value is known to be size_t typed) it really means it isn't
constant expression, while the case when it is too large for host
int is just a restriction we imply on it because we don't really support
too large strings.
Furthermore, I've used cxx_constant_value in addition to the messages
(just removing "member function " part from the wording, and using [%d]
for data or adding "core ").  The reason is that the issues during
constant expression evaluation are typically diagnosed at a different
location and I think it is useful that people know both why it isn't
a constant expression and during evaluation of what it happened.
> > --- gcc/testsuite/g++.dg/cpp0x/udlit-error1.C.jj2023-09-18 
> > 13:08:31.530448184 +0200
> > +++ gcc/testsuite/g++.dg/cpp0x/udlit-error1.C   2023-09-18 
> > 13:09:47.167440904 +0200
> > @@ -11,7 +11,8 @@ void operator""_x(const char *, decltype
> >   #pragma message "hi"_x  // { dg-warning "string literal with 
> > user-defined suffix is invalid in this context" }
> >   extern "C"_x { void g(); } // { dg-error "before user-defined string 
> > literal" }
> > -static_assert(true, "foo"_x); // { dg-error "string literal with 
> > user-defined suffix is invalid in this context|expected" }
> > +static_assert(true, "foo"_x);  // { dg-error "'static_assert' with 
> > non-string message only available with" "" { target c++23_down } }
> 
> This diagnostic message seems unclear for a UDL?
> 
> > +   // { dg-error "'static_assert' message must be 
> > a string literal or object with 'size\\\(\\\)' and 'data\\\(\\\)' members" 
> > "" { target *-*-* } .-1 }

The real diagnostic is this line, not the first one (which is just a pedwarn
about trying to use something C++26 in older code).
And I'm not really sure what to do about it.

The
static_assert (false, "foo"_myd);
in the new testcase shows where it is valid (in C++26 and as extension in
older standards).  For C++26 we could use unevaluated string literal rather
than string literal in the wording, but C++23 and earlier don't have that,
so we would need to say something like non user-defined string literal without
encoding prefix or object with 'size' and 'data' members.

> >   [[deprecated("oof"_x)]]   // { dg-error "string literal with user-defined 
> > suffix is invalid in this context" "" { target c++26 } }
> >   void

Anyway, here is the updated patch with all the changes, but nothing done
about user-defined literals.

Note, as the placeholder patch hasn't been reviewed, I've moved the
-Wc++26-extensions hunks from that patch to this patch.

2023-11-21  Jakub Jelinek  

PR c++/110348
gcc/
* doc/invoke.texi (-Wno-c++26-extensions): Document.
gcc/c-family/
* c.opt (Wc++26-extensions): New option.
* c-cppbuiltin.cc (c_cpp_builtins): For C++26 predefine
__cpp_static_assert to 202306L rather than 201411L.
gcc/cp/
* parser.cc: Implement C++26 P2741R3 - user-generated static_assert
messages.
(cp_parser_static_assert): Parse message argument as
conditional-expression if it is not a pure string literal or
several of them concatenated followed by closing paren.
* semantics.cc (finish_static_assert): Handle message which is not
STRING_CST.
* pt.cc (tsubst_expr) : Also tsubst_expr
message and make sure that if it wasn't originally STRING_CST, it
isn't after tsubst_expr either.
gcc/testsuite/
* g++.dg/cpp26/static_assert1.C: New test.
* g++.dg/cpp26/feat-cxx26.C (__cpp_static_assert): Expect
202306L rather than 201411L.
* g++.dg/cpp0x/udlit-error1.C: Expect different diagnostics for
static_assert with user-defined literal.

--- gcc/doc/invoke.texi.jj  2023-11-21 09:31:36.008392269 +0100
+++ gcc/doc/invoke.texi 2023-11-21 15:39:52.448638303 +0100
@@ -9106,6 +9106,13 @@ Do not warn about C++23 constructs in co
 an older C++ 

Re: libstdc++: Turn memmove to memcpy in vector reallocations

2023-11-21 Thread Jonathan Wakely
On Tue, 21 Nov 2023 at 16:24, Jan Hubicka  wrote:
>
> Hi,
> this patch turns memmove to memcpy where we can and also avoids extra
> guard checking if block is non-empty.  This does not show as performance
> improvement in my push_back micro-benchmark because vector rellocation
> does not happen that often. In general, however, we optimize memcpy better
> then memove (can inline it in some cases).  Saving extra 3 instructions
> makes push_back more likely to be inlined though (estimate is now 23)
>
> I also filled in PR112653.  I think for default allocator we should be
> able to work out from PTA that the memmove can be memcpy.
>
> Honestly I am not quite sure if I need to have the first
> __relocat_copy_a_1 tempalte.  It handles the case we can't use memmove,
> but in my limited C++ skills I don't see how to get rid of it or make it
> a wrapper for __relocat_a_1 which is identical.

Just return std::__relocate_a_1(first, last, result, alloc) ?

>
> Regtested on x86_64-linux.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/stl_uninitialized.h (__relocate_copy_a_1): New member 
> fnctions.

It's not a member function.

> (__relocate_a_1): Do not check count to be non-zero
> before calling memmove.
> (__relocate_copy_a): New member function.
> * include/bits/stl_vector.h (_S_do_relocate_copy): New member 
> function.

Also not member functions.

These are also very confusing names, because they still fall back to a
std::move in the case that memcpy can't be used, so they are still
semantically a "move" operation not a "copy" operation. Calling them
"relocate_copy" suggests a copy.


> * include/bits/vector.tcc (reserve, _M_realloc_append, 
> _M_realloc_insert, _M_default_append):
> Use _S_relocate_copy.

This seems to be all uses of _S_relocate, so why not just change _S_relocate?

And _S_relocate is the only place in the library that uses
std::__relocate_a, so we could just change that to use memcpy instead
of memmove. That's technically an ABI change, as old code might have
instantiations of __relocate_a_1 which use memmove and new code would
have instantiations which use memcpy, and we don't know which
definition the linker will use. But we're claiming that both memmove
and memcpy are correct here, and the difference is just performance.
So I think it's a safe change.

If we want to add other uses of __relocate_a later, we can decide
whether they can use memcpy, and if not we can add a different
function that uses memmove instead (with a new name).

CC Marc Glisse who added the relocation support. He might recall why
we use memmove when all uses are for newly-allocated storage, which
cannot overlap the existing storage.


>
> diff --git a/libstdc++-v3/include/bits/stl_uninitialized.h 
> b/libstdc++-v3/include/bits/stl_uninitialized.h
> index 1282af3bc43..983fa315e1b 100644
> --- a/libstdc++-v3/include/bits/stl_uninitialized.h
> +++ b/libstdc++-v3/include/bits/stl_uninitialized.h
> @@ -1104,6 +1104,28 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  std::__addressof(*__first), __alloc);
>return __cur;
>  }
> +  template  +   typename _Allocator>
> +_GLIBCXX20_CONSTEXPR
> +inline _ForwardIterator
> +__relocate_copy_a_1(_InputIterator __first, _InputIterator __last,
> +   _ForwardIterator __result, _Allocator& __alloc)
> +noexcept(noexcept(std::__relocate_object_a(std::addressof(*__result),
> +  std::addressof(*__first),
> +  __alloc)))
> +{
> +  typedef typename iterator_traits<_InputIterator>::value_type
> +   _ValueType;
> +  typedef typename iterator_traits<_ForwardIterator>::value_type
> +   _ValueType2;
> +  static_assert(std::is_same<_ValueType, _ValueType2>::value,
> + "relocation is only possible for values of the same type");
> +  _ForwardIterator __cur = __result;
> +  for (; __first != __last; ++__first, (void)++__cur)
> +   std::__relocate_object_a(std::__addressof(*__cur),
> +std::__addressof(*__first), __alloc);
> +  return __cur;
> +}
>
>  #if _GLIBCXX_HOSTED
>template 
> @@ -1114,20 +1136,46 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>[[__maybe_unused__]] allocator<_Up>& __alloc) noexcept
>  {
>ptrdiff_t __count = __last - __first;
> -  if (__count > 0)

I think this check avoids calling memmove (or memcpy) with null
pointers, which would be UB.

For a vector which is initially empty, __old_start == __old_finish == nullptr.


> -   {
>  #ifdef __cpp_lib_is_constant_evaluated
> - if (std::is_constant_evaluated())
> +  if (std::is_constant_evaluated())
> +   {
> + // Can't use memmove. Wrap the pointer so that __relocate_a_1
> + // resolves to the non-trivial overload above.
> + if (__count > 0)
> {
> -

Re: [PATCH 02/11] rtl-ssa: Add some helpers for removing accesses

2023-11-21 Thread Richard Sandiford
Richard Sandiford  writes:
> Alex Coplan  writes:
>> This adds some helpers to access-utils.h for removing accesses from an
>> access_array.  This is needed by the upcoming aarch64 load/store pair
>> fusion pass.
>>
>> Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk?
>>
>> gcc/ChangeLog:
>>
>>  * rtl-ssa/access-utils.h (filter_accesses): New.
>>  (remove_regno_access): New.
>>  (check_remove_regno_access): New.
>> ---
>>  gcc/rtl-ssa/access-utils.h | 42 ++
>>  1 file changed, 42 insertions(+)
>>
>> diff --git a/gcc/rtl-ssa/access-utils.h b/gcc/rtl-ssa/access-utils.h
>> index f078625babf..31259d742d9 100644
>> --- a/gcc/rtl-ssa/access-utils.h
>> +++ b/gcc/rtl-ssa/access-utils.h
>> @@ -78,6 +78,48 @@ drop_memory_access (T accesses)
>>return T (arr.begin (), accesses.size () - 1);
>>  }
>>  
>> +// Filter ACCESSES to return an access_array of only those accesses that
>> +// satisfy PREDICATE.  Alocate the new array above WATERMARK.
>> +template
>> +inline T
>> +filter_accesses (obstack_watermark ,
>> + T accesses,
>> + FilterPredicate predicate)
>> +{
>> +  access_array_builder builder (watermark);
>> +  builder.reserve (accesses.size ());
>> +  auto it = accesses.begin ();
>> +  auto end = accesses.end ();
>> +  for (; it != end; it++)
>> +if (predicate (*it))
>> +  builder.quick_push (*it);
>
> It looks like the last five lines could be simplified to:
>
>   for (access_info *access : accesses)
> if (!predicate (access))
>   builder.quick_push (access);

Oops, I meant:

 if (predicate (access))

of course :)


Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

2023-11-21 Thread David Edelsohn
On Tue, Nov 21, 2023 at 8:51 AM Arsen Arsenović  wrote:

>
> Arsen Arsenović  writes:
>
> > Bruno Haible  writes:
> >
> >> Arsen Arsenović wrote:
> >>>   Comparing stages 2 and 3
> >>>   Bootstrap comparison failure!
> >>>   gettext/libasprintf/autosprintf.o differs
> >>>   make[2]: *** [Makefile:23435: compare] Error 1
> >>
> >> You should be able to work around this by passing the additional option
> >> --disable-libasprintf to gettext-runtime/configure. Nothing in GCC needs
> >> libasprintf; therefore there is no need to build it.
> >
> > Ah, sure, that works for me too (note that the fix is to pass
> > -frandom-seed=, according to Jakub, should this show up again).
>
> Indeed, that got a bootstrap to pass.  I've also taken the opportunity
> to check the problems Eric Gallager reported.  The install tree seems
> clean now, and the info et al targets appear to work again.  David,
> Eric, could you check whether the attached patch works for you in the
> scenarios you ran into problems with?  Make sure to fetch gettext-0.22.4
> into your trees.
>
>
> If these work, I'll update download_prerequisites and see about posting
> the patch for review.
>
> Thanks, have a lovely day.
>

I don't build in tree, but the patch seems to address the previous issues.

Thanks, David


libstdc++: Turn memmove to memcpy in vector reallocations

2023-11-21 Thread Jan Hubicka
Hi,
this patch turns memmove to memcpy where we can and also avoids extra
guard checking if block is non-empty.  This does not show as performance
improvement in my push_back micro-benchmark because vector rellocation
does not happen that often. In general, however, we optimize memcpy better
then memove (can inline it in some cases).  Saving extra 3 instructions
makes push_back more likely to be inlined though (estimate is now 23)

I also filled in PR112653.  I think for default allocator we should be
able to work out from PTA that the memmove can be memcpy.

Honestly I am not quite sure if I need to have the first
__relocat_copy_a_1 tempalte.  It handles the case we can't use memmove,
but in my limited C++ skills I don't see how to get rid of it or make it
a wrapper for __relocat_a_1 which is identical.

Regtested on x86_64-linux.

libstdc++-v3/ChangeLog:

* include/bits/stl_uninitialized.h (__relocate_copy_a_1): New member 
fnctions.
(__relocate_a_1): Do not check count to be non-zero
before calling memmove.
(__relocate_copy_a): New member function.
* include/bits/stl_vector.h (_S_do_relocate_copy): New member function.
* include/bits/vector.tcc (reserve, _M_realloc_append, 
_M_realloc_insert, _M_default_append):
Use _S_relocate_copy.

diff --git a/libstdc++-v3/include/bits/stl_uninitialized.h 
b/libstdc++-v3/include/bits/stl_uninitialized.h
index 1282af3bc43..983fa315e1b 100644
--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@ -1104,6 +1104,28 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 std::__addressof(*__first), __alloc);
   return __cur;
 }
+  template 
+_GLIBCXX20_CONSTEXPR
+inline _ForwardIterator
+__relocate_copy_a_1(_InputIterator __first, _InputIterator __last,
+   _ForwardIterator __result, _Allocator& __alloc)
+noexcept(noexcept(std::__relocate_object_a(std::addressof(*__result),
+  std::addressof(*__first),
+  __alloc)))
+{
+  typedef typename iterator_traits<_InputIterator>::value_type
+   _ValueType;
+  typedef typename iterator_traits<_ForwardIterator>::value_type
+   _ValueType2;
+  static_assert(std::is_same<_ValueType, _ValueType2>::value,
+ "relocation is only possible for values of the same type");
+  _ForwardIterator __cur = __result;
+  for (; __first != __last; ++__first, (void)++__cur)
+   std::__relocate_object_a(std::__addressof(*__cur),
+std::__addressof(*__first), __alloc);
+  return __cur;
+}
 
 #if _GLIBCXX_HOSTED
   template 
@@ -1114,20 +1136,46 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   [[__maybe_unused__]] allocator<_Up>& __alloc) noexcept
 {
   ptrdiff_t __count = __last - __first;
-  if (__count > 0)
-   {
 #ifdef __cpp_lib_is_constant_evaluated
- if (std::is_constant_evaluated())
+  if (std::is_constant_evaluated())
+   {
+ // Can't use memmove. Wrap the pointer so that __relocate_a_1
+ // resolves to the non-trivial overload above.
+ if (__count > 0)
{
- // Can't use memmove. Wrap the pointer so that __relocate_a_1
- // resolves to the non-trivial overload above.
  __gnu_cxx::__normal_iterator<_Tp*, void> __out(__result);
  __out = std::__relocate_a_1(__first, __last, __out, __alloc);
  return __out.base();
}
+ return __result;
+   }
 #endif
- __builtin_memmove(__result, __first, __count * sizeof(_Tp));
+  __builtin_memmove(__result, __first, __count * sizeof(_Tp));
+  return __result + __count;
+}
+  template 
+_GLIBCXX20_CONSTEXPR
+inline __enable_if_t::value, _Tp*>
+__relocate_copy_a_1(_Tp* __first, _Tp* __last,
+   _Tp* __result,
+   [[__maybe_unused__]] allocator<_Up>& __alloc) noexcept
+{
+  ptrdiff_t __count = __last - __first;
+#ifdef __cpp_lib_is_constant_evaluated
+  if (std::is_constant_evaluated())
+   {
+ // Can't use memcpy. Wrap the pointer so that __relocate_copy_a_1
+ // resolves to the non-trivial overload above.
+ if (__count > 0)
+   {
+ __gnu_cxx::__normal_iterator<_Tp*, void> __out(__result);
+ __out = std::__relocate_a_1(__first, __last, __out, __alloc);
+ return __out.base();
+   }
+ return __result;
}
+#endif
+  __builtin_memcpy(__result, __first, __count * sizeof(_Tp));
   return __result + __count;
 }
 #endif
@@ -1146,6 +1194,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 std::__niter_base(__last),
 std::__niter_base(__result), __alloc);
 }
+  template 
+_GLIBCXX20_CONSTEXPR
+

[committed] libstdc++: Do not declare strtok for C++26 freestanding (P2937R0)

2023-11-21 Thread Jonathan Wakely
Tested x86_64-linux. Pushed to trunk.

-- >8 --

This was recently approved for C++26.

We should define the __cpp_lib_freestanding_cstring macro in 
as well as , but we do not currently install our own 
for most targets.

libstdc++-v3/ChangeLog:

* include/bits/version.def (freestanding_cstring): Add.
* include/bits/version.h: Regenerate.
* include/c_compatibility/string.h (strtok): Do not declare for
C++26 freestanding.
* include/c_global/cstring (strtok): Likewise.
* testsuite/21_strings/headers/cstring/version.cc: New test.
---
 libstdc++-v3/include/bits/version.def |  9 ++
 libstdc++-v3/include/bits/version.h   | 89 +++
 libstdc++-v3/include/c_compatibility/string.h |  2 +
 libstdc++-v3/include/c_global/cstring |  5 +-
 .../21_strings/headers/cstring/version.cc | 19 
 5 files changed, 84 insertions(+), 40 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/21_strings/headers/cstring/version.cc

diff --git a/libstdc++-v3/include/bits/version.def 
b/libstdc++-v3/include/bits/version.def
index 1c49ecea25e..605708dfee7 100644
--- a/libstdc++-v3/include/bits/version.def
+++ b/libstdc++-v3/include/bits/version.def
@@ -1366,6 +1366,15 @@ ftms = {
   };
 };
 
+ftms = {
+  name = freestanding_cstring;
+  values = {
+v = 202311;
+// This is a C++26 feature, but we support it in C++23.
+cxxmin = 23;
+  };
+};
+
 ftms = {
   name = freestanding_expected;
   values = {
diff --git a/libstdc++-v3/include/bits/version.h 
b/libstdc++-v3/include/bits/version.h
index a61d482c662..cacd9375cab 100644
--- a/libstdc++-v3/include/bits/version.h
+++ b/libstdc++-v3/include/bits/version.h
@@ -1653,6 +1653,17 @@
 #undef __glibcxx_want_freestanding_array
 
 // from version.def line 1370
+#if !defined(__cpp_lib_freestanding_cstring)
+# if (__cplusplus >= 202100L)
+#  define __glibcxx_freestanding_cstring 202311L
+#  if defined(__glibcxx_want_all) || 
defined(__glibcxx_want_freestanding_cstring)
+#   define __cpp_lib_freestanding_cstring 202311L
+#  endif
+# endif
+#endif /* !defined(__cpp_lib_freestanding_cstring) && 
defined(__glibcxx_want_freestanding_cstring) */
+#undef __glibcxx_want_freestanding_cstring
+
+// from version.def line 1379
 #if !defined(__cpp_lib_freestanding_expected)
 # if (__cplusplus >= 202100L) && (__cpp_lib_expected)
 #  define __glibcxx_freestanding_expected 202311L
diff --git a/libstdc++-v3/include/c_compatibility/string.h 
b/libstdc++-v3/include/c_compatibility/string.h
index 1d9e0d2a9bd..06529af057c 100644
--- a/libstdc++-v3/include/c_compatibility/string.h
+++ b/libstdc++-v3/include/c_compatibility/string.h
@@ -50,7 +50,9 @@ using std::strpbrk;
 using std::strrchr;
 using std::strspn;
 using std::strstr;
+#if _GLIBCXX_HOSTED || __cplusplus <= 202302L
 using std::strtok;
+#endif
 using std::memset;
 using std::strerror;
 using std::strlen;
diff --git a/libstdc++-v3/include/c_global/cstring 
b/libstdc++-v3/include/c_global/cstring
index d0a129ac802..f39aae1c82e 100644
--- a/libstdc++-v3/include/c_global/cstring
+++ b/libstdc++-v3/include/c_global/cstring
@@ -38,7 +38,8 @@
 
 #pragma GCC system_header
 
-#include 
+#define __glibcxx_want_freestanding_cstring
+#include 
 #include 
 
 #ifndef _GLIBCXX_CSTRING
@@ -90,7 +91,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   using ::strncmp;
   using ::strncpy;
   using ::strspn;
+#if _GLIBCXX_HOSTED || __cplusplus <= 202302L
   using ::strtok;
+#endif
   using ::strxfrm;
   using ::strchr;
   using ::strpbrk;
diff --git a/libstdc++-v3/testsuite/21_strings/headers/cstring/version.cc 
b/libstdc++-v3/testsuite/21_strings/headers/cstring/version.cc
new file mode 100644
index 000..06735e86a76
--- /dev/null
+++ b/libstdc++-v3/testsuite/21_strings/headers/cstring/version.cc
@@ -0,0 +1,19 @@
+// { dg-do compile { target c++26 } }
+// { dg-add-options no_pch }
+
+#include 
+
+#ifndef __cpp_lib_freestanding_cstring
+# error "Feature test macro for freestanding  is missing in "
+#elif __cpp_lib_freestanding_cstring < 202311L
+# error "Feature test macro for freestanding  has wrong value in 
"
+#endif
+
+#undef __cpp_lib_freestanding_cstring
+#include 
+
+#ifndef __cpp_lib_freestanding_cstring
+# error "Feature test macro for freestanding  is missing in "
+#elif __cpp_lib_freestanding_cstring < 202311L
+# error "Feature test macro for freestanding  has wrong value in 
"
+#endif
-- 
2.42.0



[committed] libstdc++: Add freestanding feature test macros (P2407R5)

2023-11-21 Thread Jonathan Wakely
Tested x86_64-linux. Pushed to trunk.

-- >8 --

This C++26 change makes several classes "partially freestanding", but we
already fully supported them in freestanding mode. All we need to do is
define the new feature test macros and add tests for them.

libstdc++-v3/ChangeLog:

* include/bits/version.def (freestanding_algorithm)
(freestanding_array, freestanding_optional)
(freestanding_string_view, freestanding_variant): Add.
* include/bits/version.h: Regenerate.
* include/std/algorithm (__glibcxx_want_freestanding_algorithm):
Define.
* include/std/array (__glibcxx_want_freestanding_array):
Define.
* include/std/optional (__glibcxx_want_freestanding_optional):
Define.
* include/std/string_view
(__glibcxx_want_freestanding_string_view): Define.
* include/std/variant (__glibcxx_want_freestanding_variant):
Define.
* testsuite/20_util/optional/version.cc: Add checks for
__cpp_lib_freestanding_optional.
* testsuite/20_util/variant/version.cc: Add checks for
__cpp_lib_freestanding_variant.
* testsuite/23_containers/array/tuple_interface/get_neg.cc:
Adjust dg-error line numbers.
* testsuite/21_strings/basic_string_view/requirements/version.cc:
New test.
* testsuite/23_containers/array/requirements/version.cc: New
test.
* testsuite/25_algorithms/fill_n/requirements/version.cc: New
test.
* testsuite/25_algorithms/swap_ranges/requirements/version.cc:
New test.
---
 libstdc++-v3/include/bits/version.def |  45 +++
 libstdc++-v3/include/bits/version.h   | 127 +-
 libstdc++-v3/include/std/algorithm|   1 +
 libstdc++-v3/include/std/array|   1 +
 libstdc++-v3/include/std/optional |   1 +
 libstdc++-v3/include/std/string_view  |   3 +-
 libstdc++-v3/include/std/variant  |   1 +
 .../testsuite/20_util/optional/version.cc |  20 +++
 .../testsuite/20_util/variant/version.cc  |  20 +++
 .../basic_string_view/requirements/version.cc |  19 +++
 .../array/requirements/version.cc |  19 +++
 .../array/tuple_interface/get_neg.cc  |   6 +-
 .../fill_n/requirements/version.cc|  19 +++
 .../swap_ranges/requirements/version.cc   |  19 +++
 14 files changed, 261 insertions(+), 40 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/21_strings/basic_string_view/requirements/version.cc
 create mode 100644 
libstdc++-v3/testsuite/23_containers/array/requirements/version.cc
 create mode 100644 
libstdc++-v3/testsuite/25_algorithms/fill_n/requirements/version.cc
 create mode 100644 
libstdc++-v3/testsuite/25_algorithms/swap_ranges/requirements/version.cc

diff --git a/libstdc++-v3/include/bits/version.def 
b/libstdc++-v3/include/bits/version.def
index 59a751da77b..1c49ecea25e 100644
--- a/libstdc++-v3/include/bits/version.def
+++ b/libstdc++-v3/include/bits/version.def
@@ -1348,15 +1348,60 @@ ftms = {
   };
 };
 
+ftms = {
+  name = freestanding_algorithm;
+  values = {
+v = 202311;
+// This is a C++26 feature, but we support it in C++23.
+cxxmin = 23;
+  };
+};
+
+ftms = {
+  name = freestanding_array;
+  values = {
+v = 202311;
+// This is a C++26 feature, but we support it in C++23.
+cxxmin = 23;
+  };
+};
+
 ftms = {
   name = freestanding_expected;
   values = {
 v = 202311;
 cxxmin = 23;
+// This is a C++26 feature, but we support it in C++23.
 extra_cond = "__cpp_lib_expected";
   };
 };
 
+ftms = {
+  name = freestanding_optional;
+  values = {
+v = 202311;
+// This is a C++26 feature, but we support it in C++23.
+cxxmin = 23;
+  };
+};
+
+ftms = {
+  name = freestanding_string_view;
+  values = {
+v = 202311;
+// This is a C++26 feature, but we support it in C++23.
+cxxmin = 23;
+  };
+};
+
+ftms = {
+  name = freestanding_variant;
+  values = {
+v = 202311;
+// This is a C++26 feature, but we support it in C++23.
+cxxmin = 23;
+  };
+};
 
 ftms = {
   name = invoke_r;
diff --git a/libstdc++-v3/include/bits/version.h 
b/libstdc++-v3/include/bits/version.h
index b3dbfbbcd0d..a61d482c662 100644
--- a/libstdc++-v3/include/bits/version.h
+++ b/libstdc++-v3/include/bits/version.h
@@ -1631,6 +1631,28 @@
 #undef __glibcxx_want_expected
 
 // from version.def line 1352
+#if !defined(__cpp_lib_freestanding_algorithm)
+# if (__cplusplus >= 202100L)
+#  define __glibcxx_freestanding_algorithm 202311L
+#  if defined(__glibcxx_want_all) || 
defined(__glibcxx_want_freestanding_algorithm)
+#   define __cpp_lib_freestanding_algorithm 202311L
+#  endif
+# endif
+#endif /* !defined(__cpp_lib_freestanding_algorithm) && 
defined(__glibcxx_want_freestanding_algorithm) */
+#undef __glibcxx_want_freestanding_algorithm
+
+// from version.def line 1361
+#if !defined(__cpp_lib_freestanding_array)
+# if (__cplusplus >= 

[committed] libstdc++: Add std::span::at for C++26 (P2821R5)

2023-11-21 Thread Jonathan Wakely
Tested x86_64-linux. Pushed to trunk.

-- >8 --

Also define the new feature test macros from P2833R2, indicating that
std::span and std::expected are supported for freestanding mode.

libstdc++-v3/ChangeLog:

* include/bits/version.def (freestanding_expected): New macro.
(span): Add C++26 value.
* include/bits/version.h: Regenerate.
* include/std/expected (__glibcxx_want_freestanding_expected):
Define.
* include/std/span (span::at): New member function.
* testsuite/20_util/expected/version.cc: Add checks for
__cpp_lib_freestanding_expected.
* testsuite/23_containers/span/2.cc: Moved to...
* testsuite/23_containers/span/version.cc: ...here. Add checks
for __cpp_lib_span in  as well as in .
* testsuite/23_containers/span/1.cc: Removed.
* testsuite/23_containers/span/at.cc: New test.
---
 libstdc++-v3/include/bits/version.def |  17 +-
 libstdc++-v3/include/bits/version.h   | 170 ++
 libstdc++-v3/include/std/expected |   1 +
 libstdc++-v3/include/std/span |  10 ++
 .../testsuite/20_util/expected/version.cc |  22 +++
 .../testsuite/23_containers/span/1.cc |  27 ---
 .../testsuite/23_containers/span/at.cc|  36 
 .../23_containers/span/{2.cc => version.cc}   |  15 +-
 8 files changed, 192 insertions(+), 106 deletions(-)
 delete mode 100644 libstdc++-v3/testsuite/23_containers/span/1.cc
 create mode 100644 libstdc++-v3/testsuite/23_containers/span/at.cc
 rename libstdc++-v3/testsuite/23_containers/span/{2.cc => version.cc} (64%)

diff --git a/libstdc++-v3/include/bits/version.def 
b/libstdc++-v3/include/bits/version.def
index 447fdeb9519..59a751da77b 100644
--- a/libstdc++-v3/include/bits/version.def
+++ b/libstdc++-v3/include/bits/version.def
@@ -959,6 +959,11 @@ ftms = {
 
 ftms = {
   name = span;
+  values = {
+v = 202311;
+cxxmin = 26;
+extra_cond = "__glibcxx_concepts";
+  };
   values = {
 v = 202002;
 cxxmin = 20;
@@ -1343,6 +1348,16 @@ ftms = {
   };
 };
 
+ftms = {
+  name = freestanding_expected;
+  values = {
+v = 202311;
+cxxmin = 23;
+extra_cond = "__cpp_lib_expected";
+  };
+};
+
+
 ftms = {
   name = invoke_r;
   values = {
@@ -1571,7 +1586,7 @@ ftms = {
 ftms = {
   name = out_ptr;
   values = {
-v = 202106;
+v = 202311;
 cxxmin = 23;
   };
 };
diff --git a/libstdc++-v3/include/bits/version.h 
b/libstdc++-v3/include/bits/version.h
index 97c6d8508f4..b3dbfbbcd0d 100644
--- a/libstdc++-v3/include/bits/version.h
+++ b/libstdc++-v3/include/bits/version.h
@@ -1173,7 +1173,12 @@
 
 // from version.def line 961
 #if !defined(__cpp_lib_span)
-# if (__cplusplus >= 202002L) && (__glibcxx_concepts)
+# if (__cplusplus >  202302L) && (__glibcxx_concepts)
+#  define __glibcxx_span 202311L
+#  if defined(__glibcxx_want_all) || defined(__glibcxx_want_span)
+#   define __cpp_lib_span 202311L
+#  endif
+# elif (__cplusplus >= 202002L) && (__glibcxx_concepts)
 #  define __glibcxx_span 202002L
 #  if defined(__glibcxx_want_all) || defined(__glibcxx_want_span)
 #   define __cpp_lib_span 202002L
@@ -1182,7 +1187,7 @@
 #endif /* !defined(__cpp_lib_span) && defined(__glibcxx_want_span) */
 #undef __glibcxx_want_span
 
-// from version.def line 970
+// from version.def line 975
 #if !defined(__cpp_lib_ssize)
 # if (__cplusplus >= 202002L)
 #  define __glibcxx_ssize 201902L
@@ -1193,7 +1198,7 @@
 #endif /* !defined(__cpp_lib_ssize) && defined(__glibcxx_want_ssize) */
 #undef __glibcxx_want_ssize
 
-// from version.def line 978
+// from version.def line 983
 #if !defined(__cpp_lib_three_way_comparison)
 # if (__cplusplus >= 202002L) && (__cpp_impl_three_way_comparison >= 201907L 
&& __glibcxx_concepts)
 #  define __glibcxx_three_way_comparison 201907L
@@ -1204,7 +1209,7 @@
 #endif /* !defined(__cpp_lib_three_way_comparison) && 
defined(__glibcxx_want_three_way_comparison) */
 #undef __glibcxx_want_three_way_comparison
 
-// from version.def line 988
+// from version.def line 993
 #if !defined(__cpp_lib_to_address)
 # if (__cplusplus >= 202002L)
 #  define __glibcxx_to_address 201711L
@@ -1215,7 +1220,7 @@
 #endif /* !defined(__cpp_lib_to_address) && defined(__glibcxx_want_to_address) 
*/
 #undef __glibcxx_want_to_address
 
-// from version.def line 996
+// from version.def line 1001
 #if !defined(__cpp_lib_to_array)
 # if (__cplusplus >= 202002L) && (__cpp_generic_lambdas >= 201707L)
 #  define __glibcxx_to_array 201907L
@@ -1226,7 +1231,7 @@
 #endif /* !defined(__cpp_lib_to_array) && defined(__glibcxx_want_to_array) */
 #undef __glibcxx_want_to_array
 
-// from version.def line 1005
+// from version.def line 1010
 #if !defined(__cpp_lib_type_identity)
 # if (__cplusplus >= 202002L)
 #  define __glibcxx_type_identity 201806L
@@ -1237,7 +1242,7 @@
 #endif /* !defined(__cpp_lib_type_identity) && 
defined(__glibcxx_want_type_identity) */
 #undef __glibcxx_want_type_identity
 
-// from version.def 

[committed] libstdc++: Fix std::tr2::dynamic_bitset support for alternate characters

2023-11-21 Thread Jonathan Wakely
Tested x86_64-linux. Pushed to trunk. Backports to follow.

-- >8 --

libstdc++-v3/ChangeLog:

* include/tr2/dynamic_bitset (dynamic_bitset): Pass zero and one
characters to _M_copy_from_string.
* testsuite/tr2/dynamic_bitset/string.cc: New test.
---
 libstdc++-v3/include/tr2/dynamic_bitset   |  2 +-
 .../testsuite/tr2/dynamic_bitset/string.cc| 36 +++
 2 files changed, 37 insertions(+), 1 deletion(-)
 create mode 100644 libstdc++-v3/testsuite/tr2/dynamic_bitset/string.cc

diff --git a/libstdc++-v3/include/tr2/dynamic_bitset 
b/libstdc++-v3/include/tr2/dynamic_bitset
index dd2845bd26b..ffdce82590f 100644
--- a/libstdc++-v3/include/tr2/dynamic_bitset
+++ b/libstdc++-v3/include/tr2/dynamic_bitset
@@ -622,7 +622,7 @@ namespace tr2
  // Watch for npos.
  this->_M_Nb = (__n > __str.size() ? __str.size() - __pos : __n);
  this->resize(this->_M_Nb);
- this->_M_copy_from_string(__str, __pos, __n);
+ this->_M_copy_from_string(__str, __pos, __n, __zero, __one);
}
 
   /**
diff --git a/libstdc++-v3/testsuite/tr2/dynamic_bitset/string.cc 
b/libstdc++-v3/testsuite/tr2/dynamic_bitset/string.cc
new file mode 100644
index 000..c7d0efac35f
--- /dev/null
+++ b/libstdc++-v3/testsuite/tr2/dynamic_bitset/string.cc
@@ -0,0 +1,36 @@
+// { dg-do run { target c++11 } }
+
+#include 
+#include 
+#include 
+
+void
+test_string_ctor()
+{
+  std::tr2::dynamic_bitset<> b("101001");
+  VERIFY( b[0] == true );
+  VERIFY( b[1] == false );
+  VERIFY( b[2] == false );
+  VERIFY( b[3] == true );
+  VERIFY( b[4] == false );
+  VERIFY( b[5] == true );
+}
+
+void
+test_alt_chars()
+{
+  std::string str = "xOIOIOIOx";
+  std::tr2::dynamic_bitset<> b(str, 1, 6, 'I', 'O');
+  VERIFY( b[0] == false );
+  VERIFY( b[1] == true );
+  VERIFY( b[2] == false );
+  VERIFY( b[3] == true );
+  VERIFY( b[4] == false );
+  VERIFY( b[5] == true );
+}
+
+int main()
+{
+  test_string_ctor();
+  test_alt_chars();
+}
-- 
2.42.0



[PATCH] arm: libgcc: provide implementations of __sync_synchronize

2023-11-21 Thread Richard Earnshaw
I'm going to hold off for 24 hours on this to give some chance for
feedback before committing.  Is using EXTRA_PARTS in this way
acceptable?  If not, what method would you recommend?  Is there a
better way of achieving this than using --defsym (which seems to have
the side effect of causing the target function to be included in the
image even if the function isn't actually used)?

R.

Prior to Armv6 there was no architected method to synchronize data
across processors.  Armv6 saw the first introduction of
multi-processor support, using a CP15 operation; but this was
deprecated in Armv7 and is not supported on m-profile devices of any
form.  Armv7 (and armv6-m) and later support data synchronization via
the DMB instruction.

This all leads to difficulties when linking programs as the user
generally needs to know which synchronization method is needed, but
there seems no easy way around this, when there are no OS-related
primitives available.

I've addressed this by adding multiple variants of __sync_synchronize
to libgcc, one for each of the above use cases.  I've named these
__sync_synchronize_none, __sync_synchronize_cp15dmb and
__sync_synchronize_dmb.  I've also added three specs files that can be
used to direct the linker to pick the appropriate implementation.
Using specs fragments for this is preferable to directing the user to
directly use --defsym as the latter has to be placed at the correct
position on the command line to be effective and the spec rule ensures
this automatically.

I've also added a default implementation of __sync_synchronize.  The
default implementation will use DMB if that is available in the target
ISA, or fall back to a nul-implementation if it isn't.  In the latter
case it will cause the linker (GNU LD) to emit a warning that
specifies how to pick a specific implementation.  I've chosen not to
permit this default to use the CP15 solution as that has been
deprecated.

libgcc:

* config.host (arm*-*-eabi* | arm*-*-rtems*):
Add arm/t-sync to the makefile rules.
* config/arm/lib1funcs.S (__sync_synchronize_none)
(__sync_synchronize_cp15dmb, __sync_synchronize_dmb)
(__sync_synchronize): New functions.
* config/arm/t-sync: New file.
* config/arm/sync-none.specs: Likewise.
* config/arm/sync-dmb.specs: Likewise.
* config/arm/sync-cp15dmb.specs: Likewise.
---
 libgcc/config.host   |  2 +-
 libgcc/config/arm/lib1funcs.S| 72 
 libgcc/config/arm/sync-cp15dmb.specs |  4 ++
 libgcc/config/arm/sync-dmb.specs |  4 ++
 libgcc/config/arm/sync-none.specs|  4 ++
 libgcc/config/arm/t-sync | 13 +
 6 files changed, 98 insertions(+), 1 deletion(-)
 create mode 100644 libgcc/config/arm/sync-cp15dmb.specs
 create mode 100644 libgcc/config/arm/sync-dmb.specs
 create mode 100644 libgcc/config/arm/sync-none.specs
 create mode 100644 libgcc/config/arm/t-sync

diff --git a/libgcc/config.host b/libgcc/config.host
index 6afe8e56f7e..694e3e9f54c 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -554,7 +554,7 @@ arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems*)
 	tm_file="$tm_file arm/bpabi-lib.h"
 	case ${host} in
 	arm*-*-eabi* | arm*-*-rtems*)
-	  tmake_file="${tmake_file} arm/t-bpabi t-crtfm"
+	  tmake_file="${tmake_file} arm/t-bpabi arm/t-sync t-crtfm"
 	  extra_parts="crtbegin.o crtend.o crti.o crtn.o"
 	  ;;
 	arm*-*-symbianelf*)
diff --git a/libgcc/config/arm/lib1funcs.S b/libgcc/config/arm/lib1funcs.S
index d02a57c4564..78887861616 100644
--- a/libgcc/config/arm/lib1funcs.S
+++ b/libgcc/config/arm/lib1funcs.S
@@ -2147,6 +2147,78 @@ LSYM(Lchange_\register):
 	SIZE (__gnu_thumb1_case_uhi)
 #endif
 
+#ifdef L_sync_none
+	/* Null implementation of __sync_synchronize, for use when
+	   it is known that the system is single threaded.  */
+	.text
+	.align 0
+	FUNC_START sync_synchronize_none
+	bx	lr
+	FUNC_END sync_synchronize_none
+#endif
+
+#ifdef L_sync_dmb
+	/* Full memory barrier using DMB.  Requires Armv7 (all profiles)
+	or armv6-m, or later.  */
+	.text
+	.align 0
+#if __ARM_ARCH_PROFILE == 'M'
+	.arch armv6-m
+#else
+	.arch armv7-a
+#endif
+	FUNC_START sync_synchronize_dmb
+	/* M-profile devices only support SY as the synchronization level,
+	   but that's probably what we want here anyway.  */
+	dmb
+	RET
+	FUNC_END sync_synchronize_dmb
+#endif
+
+#ifdef L_sync_cp15dmb
+#ifndef NOT_ISA_TARGET_32BIT
+	/* Implementation of DMB using CP15 operations.  This was first
+	   defined in Armv6, but deprecated in Armv7 and can give
+	   sub-optimal performance.  */
+	.text
+	.align 0
+	ARM_FUNC_START sync_synchronize_cp15dmb
+	mcr	p15, 0, r0, c7, c10, 5
+	RET
+	FUNC_END sync_synchronize_cp15dmb
+#endif
+#endif
+
+#ifdef L_sync_synchronize
+	/* Generic version of the synchronization primitive.  If we know
+	   that DMB exists, then use it.  Otherwise, arrange for a link
+	   time warning explaining how to pick a suitable alternative.
+	   We choose not 

Re: [PATCH 09/11] aarch64: Rewrite non-writeback ldp/stp patterns

2023-11-21 Thread Richard Sandiford
Alex Coplan  writes:
> This patch overhauls the load/store pair patterns with two main goals:
>
> 1. Fixing a correctness issue (the current patterns are not RA-friendly).
> 2. Allowing more flexibility in which operand modes are supported, and which
>combinations of modes are allowed in the two arms of the load/store pair,
>while reducing the number of patterns required both in the source and in
>the generated code.
>
> The correctness issue (1) is due to the fact that the current patterns have
> two independent memory operands tied together only by a predicate on the 
> insns.
> Since LRA only looks at the constraints, one of the memory operands can get
> reloaded without the other one being changed, leading to the insn becoming
> unrecognizable after reload.
>
> We fix this issue by changing the patterns such that they only ever have one
> memory operand representing the entire pair.  For the store case, we use an
> unspec to logically concatenate the register operands before storing them.
> For the load case, we use unspecs to extract the "lanes" from the pair mem,
> with the second occurrence of the mem matched using a match_dup (such that 
> there
> is still really only one memory operand as far as the RA is concerned).
>
> In terms of the modes used for the pair memory operands, we canonicalize
> these to V2x4QImode, V2x8QImode, and V2x16QImode.  These modes have not
> only the correct size but also correct alignment requirement for a
> memory operand representing an entire load/store pair.  Unlike the other
> two, V2x4QImode didn't previously exist, so had to be added with the
> patch.
>
> As with the previous patch generalizing the writeback patterns, this
> patch aims to be flexible in the combinations of modes supported by the
> patterns without requiring a large number of generated patterns by using
> distinct mode iterators.
>
> The new scheme means we only need a single (generated) pattern for each
> load/store operation of a given operand size.  For the 4-byte and 8-byte
> operand cases, we use the GPI iterator to synthesize the two patterns.
> The 16-byte case is implemented as a separate pattern in the source (due
> to only having a single possible alternative).
>
> Since the UNSPEC patterns can't be interpreted by the dwarf2cfi code,
> we add REG_CFA_OFFSET notes to the store pair insns emitted by
> aarch64_save_callee_saves, so that correct CFI information can still be
> generated.  Furthermore, we now unconditionally generate these CFA
> notes on frame-related insns emitted by aarch64_save_callee_saves.
> This is done in case that the load/store pair pass forms these into
> pairs, in which case the CFA notes would be needed.
>
> We also adjust the ldp/stp peepholes to generate the new form.  This is
> done by switching the generation to use the
> aarch64_gen_{load,store}_pair interface, making it easier to change the
> form in the future if needed.  (Likewise, the upcoming aarch64
> load/store pair pass also makes use of this interface).
>
> This patch also adds an "ldpstp" attribute to the non-writeback
> load/store pair patterns, which is used by the post-RA load/store pair
> pass to identify existing patterns and see if they can be promoted to
> writeback variants.
>
> One potential concern with using unspecs for the patterns is that it can block
> optimization by the generic RTL passes.  This patch series tries to mitigate
> this in two ways:
>  1. The pre-RA load/store pair pass runs very late in the pre-RA pipeline.
>  2. A later patch in the series adjusts the aarch64 mem{cpy,set} expansion to
> emit individual loads/stores instead of ldp/stp.  These should then be
> formed back into load/store pairs much later in the RTL pipeline by the
> new load/store pair pass.
>
> Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk?
>
> Thanks,
> Alex
>
> gcc/ChangeLog:
>
>   * config/aarch64/aarch64-ldpstp.md: Abstract ldp/stp
>   representation from peepholes, allowing use of new form.
>   * config/aarch64/aarch64-modes.def (V2x4QImode): Define.
>   * config/aarch64/aarch64-protos.h
>   (aarch64_finish_ldpstp_peephole): Declare.
>   (aarch64_swap_ldrstr_operands): Delete declaration.
>   (aarch64_gen_load_pair): Declare.
>   (aarch64_gen_store_pair): Declare.
>   * config/aarch64/aarch64-simd.md (load_pair):
>   Delete.
>   (vec_store_pair): Delete.
>   (load_pair): Delete.
>   (vec_store_pair): Delete.
>   * config/aarch64/aarch64.cc (aarch64_pair_mode_for_mode): New.
>   (aarch64_gen_store_pair): Adjust to use new unspec form of stp.
>   Drop second mem from parameters.
>   (aarch64_gen_load_pair): Likewise.
>   (aarch64_pair_mem_from_base): New.
>   (aarch64_save_callee_saves): Emit REG_CFA_OFFSET notes for
>   frame-related saves.  Adjust call to aarch64_gen_store_pair
>   (aarch64_restore_callee_saves): Adjust calls to
>   aarch64_gen_load_pair to account for change 

Re: [committed] d: Merge upstream dmd ff57fec515, druntime ff57fec515, phobos 17bafda79.

2023-11-21 Thread Rainer Orth
Rainer Orth  writes:

> either this patch or the previous one broke D bootstrap with GCC 9.  On
> both i386-pc-solaris2.11 with gdc 9.4.0 and sparc-sun-solaris2.11 with
> gdc 9.3.0, stage 1 d21 fails to link with
>
> Undefined   first referenced
>  symbol in file
> _D3dmd4root11stringtable34__T11StringValueTC3dmd5mtype4TypeZ11StringValue7lstringMFNaNbNiNjZPa
>  d/func.o
> _D3dmd4root11stringtable34__T11StringValueTC3dmd5mtype4TypeZ11StringValue8toDcharsMxFNaNbNiNjZPxa
>  d/func.o
> _D3dmd4root11stringtable34__T11StringValueTC3dmd5mtype4TypeZ11StringValue8toStringMxFNaNbNiNjZAxa
>  d/func.o
> ld: fatal: symbol referencing errors
> collect2: error: ld returned 1 exit status
> make[3]: *** [/vol/gcc/src/hg/master/local/gcc/d/Make-lang.in:236: d21] Error 
> 1

Same on i686-pc-linux-gnu, btw.

Rainer

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


Re: [committed] d: Merge upstream dmd ff57fec515, druntime ff57fec515, phobos 17bafda79.

2023-11-21 Thread Rainer Orth
Hi Iain,

> This patch merges the D front-end and runtime library with upstream dmd
> ff57fec515, and the standard library with phobos 17bafda79.
>
> Synchronizing with the upstream release candidate of v2.106.0.
>
> D front-end changes:
>
> - Import dmd v2.106.0-rc.1.
> - New'ing multi-dimensional arrays are now are converted to a single
>   template call `_d_newarraymTX'.
>
> D runtime changes:
>
> - Import druntime v2.106.0-rc.1.
>
> Phobos changes:
>
> - Import phobos v2.106.0-rc.1.
>
> Bootstrapped and regression tested on x86_64-linux-gnu/-m32, committed
> to mainline.

either this patch or the previous one broke D bootstrap with GCC 9.  On
both i386-pc-solaris2.11 with gdc 9.4.0 and sparc-sun-solaris2.11 with
gdc 9.3.0, stage 1 d21 fails to link with

Undefined   first referenced
 symbol in file
_D3dmd4root11stringtable34__T11StringValueTC3dmd5mtype4TypeZ11StringValue7lstringMFNaNbNiNjZPa
 d/func.o
_D3dmd4root11stringtable34__T11StringValueTC3dmd5mtype4TypeZ11StringValue8toDcharsMxFNaNbNiNjZPxa
 d/func.o
_D3dmd4root11stringtable34__T11StringValueTC3dmd5mtype4TypeZ11StringValue8toStringMxFNaNbNiNjZAxa
 d/func.o
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status
make[3]: *** [/vol/gcc/src/hg/master/local/gcc/d/Make-lang.in:236: d21] Error 1

I'm now running bootstraps with gdc 11.1.0 instead, which seems to work:
in both cases, stage 1 d21 did link.

If this is intentional, install.texi should be updated accordingly.

Rainer

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


Re: [PATCH v5] gcc: Introduce -fhardened

2023-11-21 Thread Marek Polacek
On Mon, Nov 20, 2023 at 05:32:47PM +0100, Jakub Jelinek wrote:
> LGTM.

Thanks a lot.  Since Richi seems to be fine with the patch as well,
I'll push it tomorrow AM if no comments.

Marek



Re: [PATCH 0/4] v2 of Option handling: add documentation URLs

2023-11-21 Thread David Malcolm
On Tue, 2023-11-21 at 15:12 +0100, Tobias Burnus wrote:
> On 21.11.23 14:57, David Malcolm wrote:
> > On Tue, 2023-11-21 at 02:09 +0100, Hans-Peter Nilsson wrote:
> > > Sorry for barging in though I did try finding the relevant
> > > discussion, but is committing this generated stuff necessary?
> > > Is it because we don't want to depend on Python being
> > > present at build time?
> > Partly, yes, [...]
> 
> I wonder how to ensure that this remains up to date. Should there be
> an
> item at
> 
> https://gcc.gnu.org/branching.html and/or
> https://gcc.gnu.org/releasing.html similar to the .pot generation?

Good point; the releasing.html's Preparations could have as point 6:

  Regenerate the .opt.urls files by running "make regenerate-opt-urls"
in the build/gcc directory.

or similar.

We should also probably recommend that people do that when adding a new
option; is there a documentation page for that?

Dave



[Ping][PATCH v3] aarch64: SVE/NEON Bridging intrinsics

2023-11-21 Thread Richard Ball
Gentle Ping for the patch below:

On 11/9/23 16:14, Richard Ball wrote:
> ACLE has added intrinsics to bridge between SVE and Neon.
> 
> The NEON_SVE Bridge adds intrinsics that allow conversions between NEON and
> SVE vectors.
> 
> This patch adds support to GCC for the following 3 intrinsics:
> svset_neonq, svget_neonq and svdup_neonq
> 
> gcc/ChangeLog:
> 
>   * config.gcc: Adds new header to config.
>   * config/aarch64/aarch64-builtins.cc (enum aarch64_type_qualifiers):
>   Moved to header file.
>   (ENTRY): Likewise.
>   (enum aarch64_simd_type): Likewise.
>   (struct aarch64_simd_type_info): Make extern.
>   (GTY): Likewise.
>   * config/aarch64/aarch64-c.cc (aarch64_pragma_aarch64):
>   Defines pragma for arm_neon_sve_bridge.h.
>   * config/aarch64/aarch64-protos.h: New function.
>   * config/aarch64/aarch64-sve-builtins-base.h: New intrinsics.
>   * config/aarch64/aarch64-sve-builtins-base.cc
>   (class svget_neonq_impl): New intrinsic implementation.
>   (class svset_neonq_impl): Likewise.
>   (class svdup_neonq_impl): Likewise.
>   (NEON_SVE_BRIDGE_FUNCTION): New intrinsics.
>   * config/aarch64/aarch64-sve-builtins-functions.h
>   (NEON_SVE_BRIDGE_FUNCTION): Defines macro for NEON_SVE_BRIDGE
>   functions.
>   * config/aarch64/aarch64-sve-builtins-shapes.h: New shapes.
>   * config/aarch64/aarch64-sve-builtins-shapes.cc
>   (parse_element_type): Add NEON element types.
>   (parse_type): Likewise.
>   (struct get_neonq_def): Defines function shape for get_neonq.
>   (struct set_neonq_def): Defines function shape for set_neonq.
>   (struct dup_neonq_def): Defines function shape for dup_neonq.
>   * config/aarch64/aarch64-sve-builtins.cc (DEF_SVE_TYPE_SUFFIX):
>   (DEF_SVE_NEON_TYPE_SUFFIX): Defines 
> macro for NEON_SVE_BRIDGE type suffixes.
>   (DEF_NEON_SVE_FUNCTION): Defines 
> macro for NEON_SVE_BRIDGE functions.
>   (function_resolver::infer_neon128_vector_type): Infers type suffix
>   for overloaded functions.
>   (init_neon_sve_builtins): Initialise neon_sve_bridge_builtins for LTO.
>   (handle_arm_neon_sve_bridge_h): Handles #pragma arm_neon_sve_bridge.h.
>   * config/aarch64/aarch64-sve-builtins.def
>   (DEF_SVE_NEON_TYPE_SUFFIX): Macro for handling neon_sve type suffixes.
>   (bf16): Replace entry with neon-sve entry.
>   (f16): Likewise.
>   (f32): Likewise.
>   (f64): Likewise.
>   (s8): Likewise.
>   (s16): Likewise.
>   (s32): Likewise.
>   (s64): Likewise.
>   (u8): Likewise.
>   (u16): Likewise.
>   (u32): Likewise.
>   (u64): Likewise.
>   * config/aarch64/aarch64-sve-builtins.h
>   (GCC_AARCH64_SVE_BUILTINS_H): Include aarch64-builtins.h.
>   (ENTRY): Add aarch64_simd_type definiton.
>   (enum aarch64_simd_type): Add neon information to type_suffix_info.
>   (struct type_suffix_info): New function.
>   * config/aarch64/aarch64-sve.md
>   (@aarch64_sve_get_neonq_): New intrinsic insn for big endian.
>   (@aarch64_sve_set_neonq_): Likewise.
>   (@aarch64_sve_dup_neonq_): Likewise.
>   * config/aarch64/aarch64.cc 
>   (aarch64_init_builtins): Add call to init_neon_sve_builtins.
> (aarch64_output_sve_set_neonq): asm output for Big Endian set_neonq.
>   * config/aarch64/iterators.md: Add UNSPEC_SET_NEONQ.
>   * config/aarch64/aarch64-builtins.h: New file.
>   * config/aarch64/aarch64-neon-sve-bridge-builtins.def: New file.
>   * config/aarch64/arm_neon_sve_bridge.h: New file.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/aarch64/sve/acle/asm/test_sve_acle.h: Add include 
>   arm_neon_sve_bridge header file
>   * gcc.dg/torture/neon-sve-bridge.c: New test.
>   * gcc.target/aarch64/sve/acle/asm/dup_neonq_bf16.c: New test.
>   * gcc.target/aarch64/sve/acle/asm/dup_neonq_f16.c: New test.
>   * gcc.target/aarch64/sve/acle/asm/dup_neonq_f32.c: New test.
>   * gcc.target/aarch64/sve/acle/asm/dup_neonq_f64.c: New test.
>   * gcc.target/aarch64/sve/acle/asm/dup_neonq_s16.c: New test.
>   * gcc.target/aarch64/sve/acle/asm/dup_neonq_s32.c: New test.
>   * gcc.target/aarch64/sve/acle/asm/dup_neonq_s64.c: New test.
>   * gcc.target/aarch64/sve/acle/asm/dup_neonq_s8.c: New test.
>   * gcc.target/aarch64/sve/acle/asm/dup_neonq_u16.c: New test.
>   * gcc.target/aarch64/sve/acle/asm/dup_neonq_u32.c: New test.
>   * gcc.target/aarch64/sve/acle/asm/dup_neonq_u64.c: New test.
>   * gcc.target/aarch64/sve/acle/asm/dup_neonq_u8.c: New test.
>   * gcc.target/aarch64/sve/acle/asm/get_neonq_bf16.c: New test.
>   * gcc.target/aarch64/sve/acle/asm/get_neonq_f16.c: New test.
>   * gcc.target/aarch64/sve/acle/asm/get_neonq_f32.c: New test.
>   * gcc.target/aarch64/sve/acle/asm/get_neonq_f64.c: New test.
>   * gcc.target/aarch64/sve/acle/asm/get_neonq_s16.c: New 

Re: [PATCH 08/11] aarch64: Generalize writeback ldp/stp patterns

2023-11-21 Thread Richard Sandiford
Alex Coplan  writes:
> Thus far the writeback forms of ldp/stp have been exclusively used in
> prologue and epilogue code for saving/restoring of registers to/from the
> stack.
>
> As such, forms of ldp/stp that weren't needed for prologue/epilogue code
> weren't supported by the aarch64 backend.  This patch generalizes the
> load/store pair writeback patterns to allow:
>
>  - Base registers other than the stack pointer.
>  - Modes that weren't previously supported.
>  - Combinations of distinct modes provided they have the same size.
>  - Pre/post variants that weren't previously needed in prologue/epilogue
>code.
>
> We make quite some effort to avoid a combinatorial explosion in the
> number of patterns generated (and those in the source) by making
> extensive use of special predicates.
>
> An updated version of the upcoming ldp/stp pass can generate the
> writeback forms, so this patch is motivated by that.
>
> This patch doesn't add zero-extending or sign-extending forms of the
> writeback patterns; that is left for future work.
>
> Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk?
>
> gcc/ChangeLog:
>
>   * config/aarch64/aarch64-protos.h (aarch64_ldpstp_operand_mode_p): 
> Declare.
>   * config/aarch64/aarch64.cc (aarch64_gen_storewb_pair): Build RTL
>   directly instead of invoking named pattern.
>   (aarch64_gen_loadwb_pair): Likewise.
>   (aarch64_ldpstp_operand_mode_p): New.
>   * config/aarch64/aarch64.md (loadwb_pair_): Replace 
> with
>   ...
>   (*loadwb_post_pair_): ... this. Generalize as described
>   in cover letter.
>   (loadwb_pair_): Delete (superseded by the
>   above).
>   (*loadwb_post_pair_16): New.
>   (*loadwb_pre_pair_): New.
>   (loadwb_pair_): Delete.
>   (*loadwb_pre_pair_16): New.
>   (storewb_pair_): Replace with ...
>   (*storewb_pre_pair_): ... this.  Generalize as
>   described in cover letter.
>   (*storewb_pre_pair_16): New.
>   (storewb_pair_): Delete.
>   (*storewb_post_pair_): New.
>   (storewb_pair_): Delete.
>   (*storewb_post_pair_16): New.
>   * config/aarch64/predicates.md (aarch64_mem_pair_operator): New.
>   (pmode_plus_operator): New.
>   (aarch64_ldp_reg_operand): New.
>   (aarch64_stp_reg_operand): New.
> ---
>  gcc/config/aarch64/aarch64-protos.h |   1 +
>  gcc/config/aarch64/aarch64.cc   |  60 +++---
>  gcc/config/aarch64/aarch64.md   | 284 
>  gcc/config/aarch64/predicates.md|  38 
>  4 files changed, 271 insertions(+), 112 deletions(-)
>
> diff --git a/gcc/config/aarch64/aarch64-protos.h 
> b/gcc/config/aarch64/aarch64-protos.h
> index 36d6c688bc8..e463fd5c817 100644
> --- a/gcc/config/aarch64/aarch64-protos.h
> +++ b/gcc/config/aarch64/aarch64-protos.h
> @@ -1023,6 +1023,7 @@ bool aarch64_operands_ok_for_ldpstp (rtx *, bool, 
> machine_mode);
>  bool aarch64_operands_adjust_ok_for_ldpstp (rtx *, bool, machine_mode);
>  bool aarch64_mem_ok_with_ldpstp_policy_model (rtx, bool, machine_mode);
>  void aarch64_swap_ldrstr_operands (rtx *, bool);
> +bool aarch64_ldpstp_operand_mode_p (machine_mode);
>  
>  extern void aarch64_asm_output_pool_epilogue (FILE *, const char *,
> tree, HOST_WIDE_INT);
> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> index 4820fac67a1..ccf081d2a16 100644
> --- a/gcc/config/aarch64/aarch64.cc
> +++ b/gcc/config/aarch64/aarch64.cc
> @@ -8977,23 +8977,15 @@ static rtx
>  aarch64_gen_storewb_pair (machine_mode mode, rtx base, rtx reg, rtx reg2,
> HOST_WIDE_INT adjustment)
>  {
> -  switch (mode)
> -{
> -case E_DImode:
> -  return gen_storewb_pairdi_di (base, base, reg, reg2,
> - GEN_INT (-adjustment),
> - GEN_INT (UNITS_PER_WORD - adjustment));
> -case E_DFmode:
> -  return gen_storewb_pairdf_di (base, base, reg, reg2,
> - GEN_INT (-adjustment),
> - GEN_INT (UNITS_PER_WORD - adjustment));
> -case E_TFmode:
> -  return gen_storewb_pairtf_di (base, base, reg, reg2,
> - GEN_INT (-adjustment),
> - GEN_INT (UNITS_PER_VREG - adjustment));
> -default:
> -  gcc_unreachable ();
> -}
> +  rtx new_base = plus_constant (Pmode, base, -adjustment);
> +  rtx mem = gen_frame_mem (mode, new_base);
> +  rtx mem2 = adjust_address_nv (mem, mode, GET_MODE_SIZE (mode));
> +
> +  return gen_rtx_PARALLEL (VOIDmode,
> +gen_rtvec (3,
> +   gen_rtx_SET (base, new_base),
> +   gen_rtx_SET (mem, reg),
> +   gen_rtx_SET (mem2, reg2)));
>  }
>  
>  /* Push registers numbered REGNO1 and REGNO2 to the stack, adjusting the
> @@ -9025,20 +9017,15 @@ 

[PATCH] gcc.misc-tests/linkage-y.c: Compatibility with C99+ system compilers

2023-11-21 Thread Florian Weimer
This program is compiled with an installed "cc" compiler, not the
built GCC compiler, so it should be as compatible as possible across a
wide range of compilers.

gcc/testsuite/

* gcc.misc-tests/linkage-y.c (puts): Declare.
(main): Add int return type and return 0.

---
 gcc/testsuite/gcc.misc-tests/linkage-y.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/testsuite/gcc.misc-tests/linkage-y.c 
b/gcc/testsuite/gcc.misc-tests/linkage-y.c
index eaffa5e4bb7..4235325f2cb 100644
--- a/gcc/testsuite/gcc.misc-tests/linkage-y.c
+++ b/gcc/testsuite/gcc.misc-tests/linkage-y.c
@@ -1,8 +1,11 @@
 /* 920717-y.c */
 
 extern const char s[];
+extern int puts(const char *);
 
+int
 main()
 {
puts(s);
+   return 0;
 }

base-commit: 700d70e4a2874645ddb67a8a335131d83b242e69



Re: [PATCH] vect: Allow reduc_index != 1 for COND_OPs.

2023-11-21 Thread Richard Biener
On Tue, 21 Nov 2023, Robin Dapp wrote:

> Hi,
> 
> in PR112406 Tamar found another problem with COND_OP reductions.
> I wrongly assumed that the reduction variable will always remain in
> operand 1, just as we create the COND_OP in ifcvt.  But of course,
> addition being commutative, we are free to swap operand 1 and 2 and
> can end up with e.g.
> 
>  _ifc__60 = .COND_ADD (_2, _6, MADPictureC1_lsm.10_25, 
> MADPictureC1_lsm.10_25);
> 
> which does not pass the asserts I put in place.
> 
> This patch removes this restriction and allows the reduction index to be
> 2 as well.
> 
> Bootstrapped and regtested on aarch64 and regtested on riscv.  x86 is
> still running.

LGTM.

Thanks,
Richard.

> Regards
>  Robin
> 
> gcc/ChangeLog:
> 
>   PR middle-end/112406
> 
>   * tree-vect-loop.cc (vectorize_fold_left_reduction): Allow
>   reduction index != 1.
>   (vect_transform_reduction): Handle reduction index != 1.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/aarch64/pr112406-2.c: New test.
> ---
>  gcc/testsuite/gcc.target/aarch64/pr112406-2.c | 20 +++
>  gcc/tree-vect-loop.cc | 15 +-
>  2 files changed, 30 insertions(+), 5 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/pr112406-2.c
> 
> diff --git a/gcc/testsuite/gcc.target/aarch64/pr112406-2.c 
> b/gcc/testsuite/gcc.target/aarch64/pr112406-2.c
> new file mode 100644
> index 000..bb6e9cf7c70
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/pr112406-2.c
> @@ -0,0 +1,20 @@
> +/* { dg-do compile { target { aarch64*-*-* } } } */
> +/* { dg-options "-march=armv8-a+sve -Ofast" } */
> +
> +double MADPictureC1;
> +extern int PictureRejected[];
> +int PictureMAD_0, MADModelEstimator_n_windowSize_i, 
> MADModelEstimator_n_windowSize_oneSampleQ;
> +
> +void MADModelEstimator_n_windowSize() {
> +  int estimateX2 = 0;
> +  for (; MADModelEstimator_n_windowSize_i; 
> MADModelEstimator_n_windowSize_i++) {
> +if (MADModelEstimator_n_windowSize_oneSampleQ &&
> +!PictureRejected[MADModelEstimator_n_windowSize_i])
> +  estimateX2 = 1;
> +if (!PictureRejected[MADModelEstimator_n_windowSize_i])
> +  MADPictureC1 += PictureMAD_0;
> +  }
> +  if (estimateX2)
> +for (;;)
> +  ;
> +}
> diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
> index 58679e91c0a..044eacddf7e 100644
> --- a/gcc/tree-vect-loop.cc
> +++ b/gcc/tree-vect-loop.cc
> @@ -7070,7 +7070,7 @@ vectorize_fold_left_reduction (loop_vec_info loop_vinfo,
>  op0 = ops[1 - reduc_index];
>else
>  {
> -  op0 = ops[2];
> +  op0 = ops[2 + (1 - reduc_index)];
>opmask = ops[0];
>gcc_assert (!slp_node);
>  }
> @@ -8455,7 +8455,9 @@ vect_transform_reduction (loop_vec_info loop_vinfo,
>gcc_assert (code == IFN_COND_ADD || code == IFN_COND_SUB
> || code == IFN_COND_MUL || code == IFN_COND_AND
> || code == IFN_COND_IOR || code == IFN_COND_XOR);
> -  gcc_assert (op.num_ops == 4 && (op.ops[1] == op.ops[3]));
> +  gcc_assert (op.num_ops == 4
> +   && (op.ops[reduc_index]
> +   == op.ops[internal_fn_else_index ((internal_fn) code)]));
>  }
>  
>bool masked_loop_p = LOOP_VINFO_FULLY_MASKED_P (loop_vinfo);
> @@ -8498,12 +8500,15 @@ vect_transform_reduction (loop_vec_info loop_vinfo,
>  {
>/* For a conditional operation pass the truth type as mask
>vectype.  */
> -  gcc_assert (single_defuse_cycle && reduc_index == 1);
> +  gcc_assert (single_defuse_cycle
> +   && (reduc_index == 1 || reduc_index == 2));
>vect_get_vec_defs (loop_vinfo, stmt_info, slp_node, ncopies,
>op.ops[0], _oprnds0,
>truth_type_for (vectype_in),
> -  NULL_TREE, _oprnds1, NULL_TREE,
> -  op.ops[2], _oprnds2, NULL_TREE);
> +  reduc_index == 1 ? NULL_TREE : op.ops[1],
> +  _oprnds1, NULL_TREE,
> +  reduc_index == 2 ? NULL_TREE : op.ops[2],
> +  _oprnds2, NULL_TREE);
>  }
>  
>/* For single def-use cycles get one copy of the vectorized reduction
> 

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


[PATCH] vect: Allow reduc_index != 1 for COND_OPs.

2023-11-21 Thread Robin Dapp
Hi,

in PR112406 Tamar found another problem with COND_OP reductions.
I wrongly assumed that the reduction variable will always remain in
operand 1, just as we create the COND_OP in ifcvt.  But of course,
addition being commutative, we are free to swap operand 1 and 2 and
can end up with e.g.

 _ifc__60 = .COND_ADD (_2, _6, MADPictureC1_lsm.10_25, MADPictureC1_lsm.10_25);

which does not pass the asserts I put in place.

This patch removes this restriction and allows the reduction index to be
2 as well.

Bootstrapped and regtested on aarch64 and regtested on riscv.  x86 is
still running.

Regards
 Robin

gcc/ChangeLog:

PR middle-end/112406

* tree-vect-loop.cc (vectorize_fold_left_reduction): Allow
reduction index != 1.
(vect_transform_reduction): Handle reduction index != 1.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr112406-2.c: New test.
---
 gcc/testsuite/gcc.target/aarch64/pr112406-2.c | 20 +++
 gcc/tree-vect-loop.cc | 15 +-
 2 files changed, 30 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/pr112406-2.c

diff --git a/gcc/testsuite/gcc.target/aarch64/pr112406-2.c 
b/gcc/testsuite/gcc.target/aarch64/pr112406-2.c
new file mode 100644
index 000..bb6e9cf7c70
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr112406-2.c
@@ -0,0 +1,20 @@
+/* { dg-do compile { target { aarch64*-*-* } } } */
+/* { dg-options "-march=armv8-a+sve -Ofast" } */
+
+double MADPictureC1;
+extern int PictureRejected[];
+int PictureMAD_0, MADModelEstimator_n_windowSize_i, 
MADModelEstimator_n_windowSize_oneSampleQ;
+
+void MADModelEstimator_n_windowSize() {
+  int estimateX2 = 0;
+  for (; MADModelEstimator_n_windowSize_i; MADModelEstimator_n_windowSize_i++) 
{
+if (MADModelEstimator_n_windowSize_oneSampleQ &&
+!PictureRejected[MADModelEstimator_n_windowSize_i])
+  estimateX2 = 1;
+if (!PictureRejected[MADModelEstimator_n_windowSize_i])
+  MADPictureC1 += PictureMAD_0;
+  }
+  if (estimateX2)
+for (;;)
+  ;
+}
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 58679e91c0a..044eacddf7e 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -7070,7 +7070,7 @@ vectorize_fold_left_reduction (loop_vec_info loop_vinfo,
 op0 = ops[1 - reduc_index];
   else
 {
-  op0 = ops[2];
+  op0 = ops[2 + (1 - reduc_index)];
   opmask = ops[0];
   gcc_assert (!slp_node);
 }
@@ -8455,7 +8455,9 @@ vect_transform_reduction (loop_vec_info loop_vinfo,
   gcc_assert (code == IFN_COND_ADD || code == IFN_COND_SUB
  || code == IFN_COND_MUL || code == IFN_COND_AND
  || code == IFN_COND_IOR || code == IFN_COND_XOR);
-  gcc_assert (op.num_ops == 4 && (op.ops[1] == op.ops[3]));
+  gcc_assert (op.num_ops == 4
+ && (op.ops[reduc_index]
+ == op.ops[internal_fn_else_index ((internal_fn) code)]));
 }
 
   bool masked_loop_p = LOOP_VINFO_FULLY_MASKED_P (loop_vinfo);
@@ -8498,12 +8500,15 @@ vect_transform_reduction (loop_vec_info loop_vinfo,
 {
   /* For a conditional operation pass the truth type as mask
 vectype.  */
-  gcc_assert (single_defuse_cycle && reduc_index == 1);
+  gcc_assert (single_defuse_cycle
+ && (reduc_index == 1 || reduc_index == 2));
   vect_get_vec_defs (loop_vinfo, stmt_info, slp_node, ncopies,
 op.ops[0], _oprnds0,
 truth_type_for (vectype_in),
-NULL_TREE, _oprnds1, NULL_TREE,
-op.ops[2], _oprnds2, NULL_TREE);
+reduc_index == 1 ? NULL_TREE : op.ops[1],
+_oprnds1, NULL_TREE,
+reduc_index == 2 ? NULL_TREE : op.ops[2],
+_oprnds2, NULL_TREE);
 }
 
   /* For single def-use cycles get one copy of the vectorized reduction
-- 
2.42.0



Re: [PATCH] tree-optimization/112623 - forwprop VEC_PACK_TRUNC generation

2023-11-21 Thread Jakub Jelinek
On Tue, Nov 21, 2023 at 02:35:02PM +, Richard Biener wrote:
> For vec_pack_trunc patterns there can be an ambiguity for the
> source mode for BFmode vs HFmode.  The vectorizer checks
> the insns operand mode for this, the following makes forwprop
> do the same.  That of course doesn't help if the target supports
> both conversions.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
> 
> Thanks,
> Richard.
> 
>   PR tree-optimization/112623
>   * tree-ssa-forwprop.cc (simplify_vector_constructor):
>   Check the source mode of the insn for vector pack/unpacks.
> 
>   * gcc.target/i386/pr112623.c: New testcase.

LGTM, thanks.

Jakub



[PATCH] tree-optimization/112623 - forwprop VEC_PACK_TRUNC generation

2023-11-21 Thread Richard Biener
For vec_pack_trunc patterns there can be an ambiguity for the
source mode for BFmode vs HFmode.  The vectorizer checks
the insns operand mode for this, the following makes forwprop
do the same.  That of course doesn't help if the target supports
both conversions.

Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?

Thanks,
Richard.

PR tree-optimization/112623
* tree-ssa-forwprop.cc (simplify_vector_constructor):
Check the source mode of the insn for vector pack/unpacks.

* gcc.target/i386/pr112623.c: New testcase.
---
 gcc/testsuite/gcc.target/i386/pr112623.c | 11 +++
 gcc/tree-ssa-forwprop.cc | 13 +
 2 files changed, 20 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr112623.c

diff --git a/gcc/testsuite/gcc.target/i386/pr112623.c 
b/gcc/testsuite/gcc.target/i386/pr112623.c
new file mode 100644
index 000..c4ebacec85c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr112623.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O -mavx512vl -mavx512fp16" } */
+
+typedef __bf16 __attribute__((__vector_size__ (16))) BF;
+typedef float __attribute__((__vector_size__ (32))) F;
+
+BF
+foo (F f)
+{
+  return __builtin_convertvector (f, BF);
+}
diff --git a/gcc/tree-ssa-forwprop.cc b/gcc/tree-ssa-forwprop.cc
index d39dfc1065f..0fb21e58138 100644
--- a/gcc/tree-ssa-forwprop.cc
+++ b/gcc/tree-ssa-forwprop.cc
@@ -47,6 +47,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-cfgcleanup.h"
 #include "cfganal.h"
 #include "optabs-tree.h"
+#include "insn-config.h"
+#include "recog.h"
 #include "tree-vector-builder.h"
 #include "vec-perm-indices.h"
 #include "internal-fn.h"
@@ -2978,6 +2980,7 @@ simplify_vector_constructor (gimple_stmt_iterator *gsi)
  /* Only few targets implement direct conversion patterns so try
 some simple special cases via VEC_[UN]PACK[_FLOAT]_LO_EXPR.  */
  optab optab;
+ insn_code icode;
  tree halfvectype, dblvectype;
  enum tree_code unpack_op;
 
@@ -3015,8 +3018,9 @@ simplify_vector_constructor (gimple_stmt_iterator *gsi)
  && (optab = optab_for_tree_code (unpack_op,
   dblvectype,
   optab_default))
- && (optab_handler (optab, TYPE_MODE (dblvectype))
- != CODE_FOR_nothing))
+ && ((icode = optab_handler (optab, TYPE_MODE (dblvectype)))
+ != CODE_FOR_nothing)
+ && (insn_data[icode].operand[0].mode == TYPE_MODE (type)))
{
  gimple_seq stmts = NULL;
  tree dbl;
@@ -3054,8 +3058,9 @@ simplify_vector_constructor (gimple_stmt_iterator *gsi)
   && (optab = optab_for_tree_code (VEC_PACK_TRUNC_EXPR,
halfvectype,
optab_default))
-  && (optab_handler (optab, TYPE_MODE (halfvectype))
-  != CODE_FOR_nothing))
+  && ((icode = optab_handler (optab, TYPE_MODE (halfvectype)))
+  != CODE_FOR_nothing)
+  && (insn_data[icode].operand[0].mode == TYPE_MODE (type)))
{
  gimple_seq stmts = NULL;
  tree low = gimple_build (, BIT_FIELD_REF, halfvectype,
-- 
2.35.3


[PATCH] Move VF based dependence check

2023-11-21 Thread Richard Biener
The following moves the check whether the maximum vectorization
factor determined by data dependence analysis is in conflict with
the chosen vectorization factor to after the point where we applied
both the SLP and the unrolling adjustment to the vectorization
factor.  We check the latter before applying unrolling, but the
SLP adjustment can result in both missed optimization and wrong-code.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

* tree-vect-loop.cc (vect_analyze_loop_2): Move check
of VF against max_vf until VF is final.
---
 gcc/tree-vect-loop.cc | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 58679e91c0a..a73a533beb1 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -2817,9 +2817,6 @@ vect_analyze_loop_2 (loop_vec_info loop_vinfo, bool 
,
 "can't determine vectorization factor.\n");
   return ok;
 }
-  if (max_vf != MAX_VECTORIZATION_FACTOR
-  && maybe_lt (max_vf, LOOP_VINFO_VECT_FACTOR (loop_vinfo)))
-return opt_result::failure_at (vect_location, "bad data dependence.\n");
 
   /* Compute the scalar iteration cost.  */
   vect_compute_single_scalar_iteration_cost (loop_vinfo);
@@ -2881,6 +2878,10 @@ start_over:
   LOOP_VINFO_INT_NITERS (loop_vinfo));
 }
 
+  if (max_vf != MAX_VECTORIZATION_FACTOR
+  && maybe_lt (max_vf, LOOP_VINFO_VECT_FACTOR (loop_vinfo)))
+return opt_result::failure_at (vect_location, "bad data dependence.\n");
+
   loop_vinfo->vector_costs = init_cost (loop_vinfo, false);
 
   /* Analyze the alignment of the data-refs in the loop.
-- 
2.35.3


Re: GCC/Rust libgrust-v2/to-submit branch

2023-11-21 Thread Arthur Cohen

Hi Thomas!

A newer version of the library has been force-pushed to the branch 
`libgrust-v2/to-submit`.


On 11/20/23 15:55, Thomas Schwinge wrote:

Hi!

Arthur and Pierre-Emmanuel have prepared a GCC/Rust libgrust-v2/to-submit
branch: .
In that one, most of the issues raised have been addressed, and which
I've now successfully "tested" in my different GCC configurations,
requiring just one additional change (see end of this email).  I'm using
"tested" in quotes here, as libgrust currently is still missing its
eventual content, and still is without actual users, so we may still be
up for surprises later on.  ;-)

On 2023-10-27T22:41:52+0200, I wrote:

On 2023-09-27T00:25:16+0200, I wrote:

don't we also directly need to
incorporate here a few GCC/Rust master branch follow-on commits, like:

   - commit 171ea4e2b3e202067c50f9c206974fbe1da691c0 "fixup: Fix bootstrap 
build"
   - commit 61cbe201029658c32e5c360823b9a1a17d21b03c "fixup: Fix missing build 
dependency"


I've not yet run into the need for these two.  Let's please leave these
out of the upstream submission for now, until we understand what exactly
these are necessary for.


(Still the same.)


Do you mean that we should remove the content of these commits from the 
submission? If so, I believe it's now done.





However:


   - commit 6a8b207b9ef7f9038e0cae7766117428783825d8 "libgrust: Add dependency to 
libstdc++"


... this one definitely is necessary right now; see discussion in

"Disable target libgrust if we're not building target libstdc++".


This one still isn't in the GCC/Rust libgrust-v2/to-submit branch -- but
having now tested that branch, I'm now no longer seeing the respective
build failure.  Isn't that change "libgrust: Add dependency to libstdc++"
still necessary, conceptually?  (Maybe we're just lucky, currently?)
I'll be sure to re-test in my different GCC configurations once libgrust
gains actual content and use.  (..., which might then re-expose the
original problem?)


This commit was integrated into another one:

fb31093105e build: Add libgrust as compilation modules

(on libgrust-v2/to-submit as of 2 minutes ago)




And:


(Not sure if all of these are necessary and/or if that's the complete
list; haven't looked up the corresponding GCC/Rust GitHub PRs.)


--- a/gcc/rust/config-lang.in
+++ b/gcc/rust/config-lang.in



+target_libs="target-libffi target-libbacktrace target-libgrust"


Please don't add back 'target-libffi' and 'target-libbacktrace' here;
just 'target-libgrust'.  (As is present in GCC/Rust master branch, and
per commit 7411eca498beb13729cc2acec77e68250940aa81
"Rust: Don't depend on unused 'target-libffi', 'target-libbacktrace'".)


... that change is necessary, too.


That's still unchanged in the GCC/Rust libgrust-v2/to-submit branch;
please apply to 'gcc/rust/config-lang.in':

 -target_libs="target-libffi target-libbacktrace target-libgrust"
 +target_libs=target-libgrust

Then, still should re-order the commits so that (re)generation of
auto-generated files comes before use of libgrust (so that later
bisection doesn't break), and move the 'contrib/gcc_update' update into
the commit that adds the auto-generated files.


Do you mean that the regeneration should happen before the commit adding 
the proc_macro library? Or that when we keep going and adding more 
commits on top of this, we need to make sure the regeneration commit 
happens before any code starts using/depending on libgrust/?


And alright, we'll move the changes to contrib/gcc_update into the 
regeneration commit.


All the best, and thanks again for testing :)

Arthur




Grüße
  Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955


Re: Pushed: LoongArch: Fix libgcc build failure when libc is not available (was Re: genopts: Add infrastructure to generate code for new features in ISA evolution)

2023-11-21 Thread Jeff Law




On 11/20/23 20:09, Xi Ruoyao wrote:

On Tue, 2023-11-21 at 08:00 +0800, Xi Ruoyao wrote:

/* snip */


This has broken libgcc builds when target libc isn't yet available.

In file included from 
/scratch/jmyers/glibc-bot/src/gcc/libgcc/../gcc/config/loongarch/loongarch-def.h:49,
  from 
/scratch/jmyers/glibc-bot/src/gcc/libgcc/../gcc/config/loongarch/loongarch-opts.h:24,
  from ../.././gcc/options.h:8,
  from ../.././gcc/tm.h:49,
  from /scratch/jmyers/glibc-bot/src/gcc/libgcc/libgcc2.c:29:
/scratch/jmyers/glibc-bot/build/compilers/loongarch64-linux-gnu-lp64d/gcc-first/gcc/include/stdint.h:9:16:
 fatal error: stdint.h: No such file or directory
     9 | # include_next 
   |    ^~
compilation terminated.
make[3]: *** [Makefile:505: _muldi3.o] Error 1

[ ... ]
Thanks.  My tester had been tripping over that for a couple days.

Jeff


Re: [PATCH 0/4] v2 of Option handling: add documentation URLs

2023-11-21 Thread Tobias Burnus

On 21.11.23 14:57, David Malcolm wrote:

On Tue, 2023-11-21 at 02:09 +0100, Hans-Peter Nilsson wrote:

Sorry for barging in though I did try finding the relevant
discussion, but is committing this generated stuff necessary?
Is it because we don't want to depend on Python being
present at build time?

Partly, yes, [...]


I wonder how to ensure that this remains up to date. Should there be an
item at

https://gcc.gnu.org/branching.html and/or
https://gcc.gnu.org/releasing.html similar to the .pot generation?

Tobias

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955


Re: [PATCH] RISC-V: testsuite: Fix popcount test.

2023-11-21 Thread juzhe.zhong
ok Replied Message FromRobin DappDate11/21/2023 21:35 Togcc-patches,palmer,Kito Cheng,jeffreyalaw,juzhe.zh...@rivai.ai Ccrdapp@gmail.comSubjectRe: [PATCH] RISC-V: testsuite: Fix popcount test.> Mhm, not so obvious after all.  We vectorize 250 instances with
> rv32gcv, 229 with rv64gcv and 250 with rv64gcv_zbb.  Will have
> another look tomorrow.

The problem is that tree-vect-patterns is more restrictive than
necessary and does not vectorize everything it could.  Therefore
I'm going to commit the attached with a TODO comment and a
separate check for zbb.

Regards
 Robin

Subject: [PATCH v2] RISC-V: testsuite: Fix popcount test.

Due to Jakub's recent middle-end changes we now vectorize some more
popcount instances.  This patch just adjusts the dump check.

gcc/testsuite/ChangeLog:

    * gcc.target/riscv/rvv/autovec/unop/popcount.c: Adjust check.
    * lib/target-supports.exp: Add riscv_zbb.
---
 .../gcc.target/riscv/rvv/autovec/unop/popcount.c  | 10 +-
 gcc/testsuite/lib/target-supports.exp | 11 +++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/unop/popcount.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/unop/popcount.c
index 585a522aa81..ca1319c2e7e 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/unop/popcount.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/unop/popcount.c
@@ -1461,4 +1461,12 @@ main ()
   RUN_ALL ()
 }
  
-/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 229 "vect" } } */
+/* TODO: Due to an over-zealous check in tree-vect-patterns we do not vectorize
+   e.g.
+ uint64_t dst[];
+ uint32_t src[];
+ dst[i] = __builtin_popcountll (src[i]);
+   even though we could.  Therefore, for now, adjust the following checks.
+   This difference was exposed in r14-5557-g6dd4c703be17fa.  */
+/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 229 "vect" { target { { rv64 } && { ! riscv_zbb } } } } } */
+/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 250 "vect" { target { { rv32 } || { riscv_zbb } } } } } */
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index f3cd0311e27..87b2ae58720 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -1983,6 +1983,17 @@ proc check_effective_target_riscv_ztso { } {
 }]
 }
  
+# Return 1 if the target arch supports the Zbb extension, 0 otherwise.
+# Cache the result.
+
+proc check_effective_target_riscv_zbb { } {
+    return [check_no_compiler_messages riscv_ext_zbb assembly {
+   #ifndef __riscv_zbb
+   #error "Not __riscv_zbb"
+   #endif
+    }]
+}
+
 # Return 1 if we can execute code when using dg-add-options riscv_v
  
 proc check_effective_target_riscv_v_ok { } {
--  
2.42.0




Re: Propagate value ranges of return values

2023-11-21 Thread Jan Hubicka
> After this patch in addition to the problem already reported about
> vlda1.c and return-value-range-1.c, we have noticed these regressions
> on aarch64:
> Running gcc:gcc.target/aarch64/aarch64.exp ...
> FAIL: gcc.target/aarch64/movk.c scan-assembler movk\tx[0-9]+, 0x4667, lsl 16
> FAIL: gcc.target/aarch64/movk.c scan-assembler movk\tx[0-9]+, 0x7a3d, lsl 32
> 
> Running gcc:gcc.target/aarch64/simd/simd.exp ...
> FAIL: gcc.target/aarch64/simd/vmulxd_f64_2.c scan-assembler-times
> fmul[ \t]+[dD][0-9]+, ?[dD][0-9]+, ?[dD][0-9]+\n 1
> FAIL: gcc.target/aarch64/simd/vmulxd_f64_2.c scan-assembler-times
> fmulx[ \t]+[dD][0-9]+, ?[dD][0-9]+, ?[dD][0-9]+\n 4
> FAIL: gcc.target/aarch64/simd/vmulxs_f32_2.c scan-assembler-times
> fmul[ \t]+[sS][0-9]+, ?[sS][0-9]+, ?[sS][0-9]+\n 1
> FAIL: gcc.target/aarch64/simd/vmulxs_f32_2.c scan-assembler-times
> fmulx[ \t]+[sS][0-9]+, ?[sS][0-9]+, ?[sS][0-9]+\n 4

Sorry for that - I guess we will see some on various targets.
This is quite common issue - the testcase is having
dummy_number_generator function returning constant and prevents
inlining to avoid constant being visible to compiler.  This no longer
works, since we get it from the return value range.  This should fix it.

return-value_range-1.c should be fixed now and I do not have vlda1.c in
my tree.  I will check.

diff --git a/gcc/testsuite/gcc.target/aarch64/movk.c 
b/gcc/testsuite/gcc.target/aarch64/movk.c
index e6e4e3a8961..6b1f3f8ecf5 100644
--- a/gcc/testsuite/gcc.target/aarch64/movk.c
+++ b/gcc/testsuite/gcc.target/aarch64/movk.c
@@ -1,8 +1,9 @@
 /* { dg-do run } */
-/* { dg-options "-O2 --save-temps -fno-inline" } */
+/* { dg-options "-O2 --save-temps" } */
 
 extern void abort (void);
 
+__attribute__ ((noipa))
 long long int
 dummy_number_generator ()
 {

> 
> We have already sent you a notification for the regression on arm, but
> it includes on vla-1.c and return-value-range-1.c.
> The notification email contains a pointer to the page where we record
> all the configurations that regress because of this patch:
> 
> https://linaro.atlassian.net/browse/GNU-1025
> 
> Can you have a look?
> 
> Thanks,
> 
> Christophe
> 
> 
> 
> 
> > diff --git a/gcc/cgraph.cc b/gcc/cgraph.cc
> > index e41e5ad3ae7..71dacf23ce1 100644
> > --- a/gcc/cgraph.cc
> > +++ b/gcc/cgraph.cc
> > @@ -2629,6 +2629,54 @@ cgraph_node::set_malloc_flag (bool malloc_p)
> >return changed;
> >  }
> >
> > +/* Worker to set malloc flag.  */
> > +static void
> > +add_detected_attribute_1 (cgraph_node *node, const char *attr, bool 
> > *changed)
> > +{
> > +  if (!lookup_attribute (attr, DECL_ATTRIBUTES (node->decl)))
> > +{
> > +  DECL_ATTRIBUTES (node->decl) = tree_cons (get_identifier (attr),
> > +NULL_TREE, DECL_ATTRIBUTES 
> > (node->decl));
> > +  *changed = true;
> > +}
> > +
> > +  ipa_ref *ref;
> > +  FOR_EACH_ALIAS (node, ref)
> > +{
> > +  cgraph_node *alias = dyn_cast (ref->referring);
> > +  if (alias->get_availability () > AVAIL_INTERPOSABLE)
> > +   add_detected_attribute_1 (alias, attr, changed);
> > +}
> > +
> > +  for (cgraph_edge *e = node->callers; e; e = e->next_caller)
> > +if (e->caller->thunk
> > +   && (e->caller->get_availability () > AVAIL_INTERPOSABLE))
> > +  add_detected_attribute_1 (e->caller, attr, changed);
> > +}
> > +
> > +/* Set DECL_IS_MALLOC on NODE's decl and on NODE's aliases if any.  */
> > +
> > +bool
> > +cgraph_node::add_detected_attribute (const char *attr)
> > +{
> > +  bool changed = false;
> > +
> > +  if (get_availability () > AVAIL_INTERPOSABLE)
> > +add_detected_attribute_1 (this, attr, );
> > +  else
> > +{
> > +  ipa_ref *ref;
> > +
> > +  FOR_EACH_ALIAS (this, ref)
> > +   {
> > + cgraph_node *alias = dyn_cast (ref->referring);
> > + if (alias->get_availability () > AVAIL_INTERPOSABLE)
> > +   add_detected_attribute_1 (alias, attr, );
> > +   }
> > +}
> > +  return changed;
> > +}
> > +
> >  /* Worker to set noreturng flag.  */
> >  static void
> >  set_noreturn_flag_1 (cgraph_node *node, bool noreturn_p, bool *changed)
> > diff --git a/gcc/cgraph.h b/gcc/cgraph.h
> > index cedaaac3a45..cfdd9f693a8 100644
> > --- a/gcc/cgraph.h
> > +++ b/gcc/cgraph.h
> > @@ -1190,6 +1190,10 @@ struct GTY((tag ("SYMTAB_FUNCTION"))) cgraph_node : 
> > public symtab_node
> >
> >bool set_pure_flag (bool pure, bool looping);
> >
> > +  /* Add attribute ATTR to cgraph_node's decl and on aliases of the node
> > + if any.  */
> > +  bool add_detected_attribute (const char *attr);
> > +
> >/* Call callback on function and aliases associated to the function.
> >   When INCLUDE_OVERWRITABLE is false, overwritable aliases and thunks 
> > are
> >   skipped. */
> > diff --git a/gcc/common.opt b/gcc/common.opt
> > index d21db5d4a20..c6599c7147b 100644
> > --- a/gcc/common.opt
> > +++ b/gcc/common.opt
> > @@ -781,6 +781,10 @@ Wsuggest-attribute=malloc
> >  Common 

Re: [PATCH] testsuite: Fix up pr111309-2.c on arm [PR111309]

2023-11-21 Thread Christophe Lyon
On Tue, 21 Nov 2023 at 09:48, Jakub Jelinek  wrote:
>
> Hi!
>
> ARM defaults to -fshort-enums and the following testcase FAILs there in 2
> lines.  The difference is that in C++, E0 has enum E type, which normally
> has unsigned int underlying type, so it isn't int nor something that
> promotes to int, which is why we diagnose it (in C it is promoted to int).
> But with -fshort-enums, the underlying type is unsigned char in that case,
> which promotes to int just fine.
>
> The following patch adjusts the expectations, such that we don't expect
> it on arm or when people manually test with -fshort-enums.
>
> Tested on x86_64-linux and i686-linux, ok for trunk?
>
> 2023-11-21  Jakub Jelinek  
>
> PR c/111309
> * c-c++-common/pr111309-2.c (foo): Don't expect errors for C++ with
> -fshort-enums if second argument is E0.
>

Thanks for the fix!

I keep forgetting about the -fshort-enum difference between arm-linux
and arm-eabi targets

Christophe

> --- gcc/testsuite/c-c++-common/pr111309-2.c.jj  2023-11-14 10:52:16.191276028 
> +0100
> +++ gcc/testsuite/c-c++-common/pr111309-2.c 2023-11-20 17:52:30.606386073 
> +0100
> @@ -32,7 +32,7 @@ foo (void)
>__builtin_clzg (0U, 2LL);/* { dg-error "does not have 'int' type" } */
>__builtin_clzg (0U, 2U); /* { dg-error "does not have 'int' type" } */
>__builtin_clzg (0U, true);
> -  __builtin_clzg (0U, E0); /* { dg-error "does not have 'int' type" "" { 
> target c++ } } */
> +  __builtin_clzg (0U, E0); /* { dg-error "does not have 'int' type" "" { 
> target { c++ && { ! short_enums } } } } */
>__builtin_ctzg ();   /* { dg-error "too few arguments" } */
>__builtin_ctzg (0U, 1, 2);   /* { dg-error "too many arguments" } */
>__builtin_ctzg (0);  /* { dg-error "has signed type" } */
> @@ -51,7 +51,7 @@ foo (void)
>__builtin_ctzg (0U, 2LL);/* { dg-error "does not have 'int' type" } */
>__builtin_ctzg (0U, 2U); /* { dg-error "does not have 'int' type" } */
>__builtin_ctzg (0U, true);
> -  __builtin_ctzg (0U, E0); /* { dg-error "does not have 'int' type" "" { 
> target c++ } } */
> +  __builtin_ctzg (0U, E0); /* { dg-error "does not have 'int' type" "" { 
> target { c++ && { ! short_enums } } } } */
>__builtin_clrsbg (); /* { dg-error "too few arguments" } */
>__builtin_clrsbg (0, 1); /* { dg-error "too many arguments" } */
>__builtin_clrsbg (0U);   /* { dg-error "has unsigned type" } */
>
> Jakub
>


Re: Propagate value ranges of return values

2023-11-21 Thread Christophe Lyon
Hi!

On Sun, 19 Nov 2023 at 16:05, Jan Hubicka  wrote:
>
> Hi,
> this is updated version which also adds testuiste compensation
> I lost earlier while maintaining the patch in my testing tree.
> There are quite few testcases that use constant return values to hide
> something from optimizer.
>
> Bootstrapped/regtested x86_64-linux.
> gcc/ChangeLog:
>
> * cgraph.cc (add_detected_attribute_1): New function.
> (cgraph_node::add_detected_attribute): Likewise.
> * cgraph.h (cgraph_node::add_detected_attribute): Declare.
> * common.opt: Add -Wsuggest-attribute=returns_nonnull.
> * doc/invoke.texi: Document new flag.
> * gimple-range-fold.cc (fold_using_range::range_of_call):
> Use known reutrn value ranges.
> * ipa-prop.cc (struct ipa_return_value_summary): New type.
> (class ipa_return_value_sum_t): New type.
> (ipa_return_value_sum): New summary.
> (ipa_record_return_value_range): New function.
> (ipa_return_value_range): New function.
> * ipa-prop.h (ipa_return_value_range): Declare.
> (ipa_record_return_value_range): Declare.
> * ipa-pure-const.cc (warn_function_returns_nonnull): New funcion.
> * ipa-utils.h (warn_function_returns_nonnull): Declare.
> * symbol-summary.h: Fix comment.
> * tree-vrp.cc (execute_ranger_vrp): Record return values.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/ipa/devirt-2.C: Add noipa attribute to prevent ipa-vrp.
> * g++.dg/ipa/devirt-7.C: Disable ipa-vrp.
> * g++.dg/ipa/ipa-icf-2.C: Disable ipa-vrp.
> * g++.dg/ipa/ipa-icf-3.C: Disable ipa-vrp.
> * g++.dg/ipa/ivinline-1.C: Disable ipa-vrp.
> * g++.dg/ipa/ivinline-3.C: Disable ipa-vrp.
> * g++.dg/ipa/ivinline-5.C: Disable ipa-vrp.
> * g++.dg/ipa/ivinline-8.C: Disable ipa-vrp.
> * g++.dg/ipa/nothrow-1.C: Disable ipa-vrp.
> * g++.dg/ipa/pure-const-1.C: Disable ipa-vrp.
> * g++.dg/ipa/pure-const-2.C: Disable ipa-vrp.
> * g++.dg/lto/inline-crossmodule-1_0.C: Disable ipa-vrp.
> * gcc.c-torture/compile/pr106433.c: Add noipa attribute to prevent 
> ipa-vrp.
> * gcc.c-torture/execute/frame-address.c: Likewise.
> * gcc.dg/ipa/fopt-info-inline-1.c: Disable ipa-vrp.
> * gcc.dg/ipa/ipa-icf-25.c: Disable ipa-vrp.
> * gcc.dg/ipa/ipa-icf-38.c: Disable ipa-vrp.
> * gcc.dg/ipa/pure-const-1.c: Disable ipa-vrp.
> * gcc.dg/ipa/remref-0.c: Add noipa attribute to prevent ipa-vrp.
> * gcc.dg/tree-prof/time-profiler-1.c: Disable ipa-vrp.
> * gcc.dg/tree-prof/time-profiler-2.c: Disable ipa-vrp.
> * gcc.dg/tree-ssa/pr110269.c: Disable ipa-vrp.
> * gcc.dg/tree-ssa/pr20701.c: Disable ipa-vrp.
> * gcc.dg/tree-ssa/vrp05.c: Disable ipa-vrp.
> * gcc.dg/tree-ssa/return-value-range-1.c: New test.
>

After this patch in addition to the problem already reported about
vlda1.c and return-value-range-1.c, we have noticed these regressions
on aarch64:
Running gcc:gcc.target/aarch64/aarch64.exp ...
FAIL: gcc.target/aarch64/movk.c scan-assembler movk\tx[0-9]+, 0x4667, lsl 16
FAIL: gcc.target/aarch64/movk.c scan-assembler movk\tx[0-9]+, 0x7a3d, lsl 32

Running gcc:gcc.target/aarch64/simd/simd.exp ...
FAIL: gcc.target/aarch64/simd/vmulxd_f64_2.c scan-assembler-times
fmul[ \t]+[dD][0-9]+, ?[dD][0-9]+, ?[dD][0-9]+\n 1
FAIL: gcc.target/aarch64/simd/vmulxd_f64_2.c scan-assembler-times
fmulx[ \t]+[dD][0-9]+, ?[dD][0-9]+, ?[dD][0-9]+\n 4
FAIL: gcc.target/aarch64/simd/vmulxs_f32_2.c scan-assembler-times
fmul[ \t]+[sS][0-9]+, ?[sS][0-9]+, ?[sS][0-9]+\n 1
FAIL: gcc.target/aarch64/simd/vmulxs_f32_2.c scan-assembler-times
fmulx[ \t]+[sS][0-9]+, ?[sS][0-9]+, ?[sS][0-9]+\n 4

We have already sent you a notification for the regression on arm, but
it includes on vla-1.c and return-value-range-1.c.
The notification email contains a pointer to the page where we record
all the configurations that regress because of this patch:

https://linaro.atlassian.net/browse/GNU-1025

Can you have a look?

Thanks,

Christophe




> diff --git a/gcc/cgraph.cc b/gcc/cgraph.cc
> index e41e5ad3ae7..71dacf23ce1 100644
> --- a/gcc/cgraph.cc
> +++ b/gcc/cgraph.cc
> @@ -2629,6 +2629,54 @@ cgraph_node::set_malloc_flag (bool malloc_p)
>return changed;
>  }
>
> +/* Worker to set malloc flag.  */
> +static void
> +add_detected_attribute_1 (cgraph_node *node, const char *attr, bool *changed)
> +{
> +  if (!lookup_attribute (attr, DECL_ATTRIBUTES (node->decl)))
> +{
> +  DECL_ATTRIBUTES (node->decl) = tree_cons (get_identifier (attr),
> +NULL_TREE, DECL_ATTRIBUTES 
> (node->decl));
> +  *changed = true;
> +}
> +
> +  ipa_ref *ref;
> +  FOR_EACH_ALIAS (node, ref)
> +{
> +  cgraph_node *alias = dyn_cast (ref->referring);
> +  if (alias->get_availability () > AVAIL_INTERPOSABLE)
> +   add_detected_attribute_1 

  1   2   >