Re: [PATCH] testsuite: Fix pr108574-3.c failed in arch where sign defaults to unsigned.

[Richard Biener via Gcc-patches]

On Tue, 31 Jan 2023, Xianmiao Qu wrote:

> In the architecture where sign defaults to unsigned, the 'f' will be zero
> extended to int type in the expression 'd = ~(f & ~2880764155)', then the
> 'd' will become -1 wich cause the case to fail.
> So it's ok for the architectures where sign defaults to signed like x86,
> but failed for the architectures where sign defaults to unsigned like arm
> and csky. Change char to signed char to avoid this problem.

Whoops - thanks for fixing!

OK.

Richard.

> gcc/testsuite:
>   * gcc.dg/torture/pr108574-3.c (b, f): Change type from char to
>   signed char.
> ---
>  gcc/testsuite/gcc.dg/torture/pr108574-3.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/testsuite/gcc.dg/torture/pr108574-3.c 
> b/gcc/testsuite/gcc.dg/torture/pr108574-3.c
> index 3c9146e31ac..b4d5dae9f80 100644
> --- a/gcc/testsuite/gcc.dg/torture/pr108574-3.c
> +++ b/gcc/testsuite/gcc.dg/torture/pr108574-3.c
> @@ -1,7 +1,7 @@
>  /* { dg-do run } */
>  
>  int a = 3557301289, d;
> -char b, f;
> +signed char b, f;
>  unsigned short c = 241;
>  short e, g;
>  static void h() {
> 

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

Re: [aarch64] Use wzr/xzr for assigning vector element to 0

[Richard Sandiford via Gcc-patches]

Prathamesh Kulkarni  writes:
> On Mon, 23 Jan 2023 at 22:26, Richard Sandiford
>  wrote:
>>
>> Prathamesh Kulkarni  writes:
>> > On Wed, 18 Jan 2023 at 19:59, Richard Sandiford
>> >  wrote:
>> >>
>> >> Prathamesh Kulkarni  writes:
>> >> > On Tue, 17 Jan 2023 at 18:29, Richard Sandiford
>> >> >  wrote:
>> >> >>
>> >> >> Prathamesh Kulkarni  writes:
>> >> >> > Hi Richard,
>> >> >> > For the following (contrived) test:
>> >> >> >
>> >> >> > void foo(int32x4_t v)
>> >> >> > {
>> >> >> >   v[3] = 0;
>> >> >> >   return v;
>> >> >> > }
>> >> >> >
>> >> >> > -O2 code-gen:
>> >> >> > foo:
>> >> >> > fmovs1, wzr
>> >> >> > ins v0.s[3], v1.s[0]
>> >> >> > ret
>> >> >> >
>> >> >> > I suppose we can instead emit the following code-gen ?
>> >> >> > foo:
>> >> >> >  ins v0.s[3], wzr
>> >> >> >  ret
>> >> >> >
>> >> >> > combine produces:
>> >> >> > Failed to match this instruction:
>> >> >> > (set (reg:V4SI 95 [ v ])
>> >> >> > (vec_merge:V4SI (const_vector:V4SI [
>> >> >> > (const_int 0 [0]) repeated x4
>> >> >> > ])
>> >> >> > (reg:V4SI 97)
>> >> >> > (const_int 8 [0x8])))
>> >> >> >
>> >> >> > So, I wrote the following pattern to match the above insn:
>> >> >> > (define_insn "aarch64_simd_vec_set_zero"
>> >> >> >   [(set (match_operand:VALL_F16 0 "register_operand" "=w")
>> >> >> > (vec_merge:VALL_F16
>> >> >> > (match_operand:VALL_F16 1 "const_dup0_operand" "w")
>> >> >> > (match_operand:VALL_F16 3 "register_operand" "0")
>> >> >> > (match_operand:SI 2 "immediate_operand" "i")))]
>> >> >> >   "TARGET_SIMD"
>> >> >> >   {
>> >> >> > int elt = ENDIAN_LANE_N (, exact_log2 (INTVAL 
>> >> >> > (operands[2])));
>> >> >> > operands[2] = GEN_INT ((HOST_WIDE_INT) 1 << elt);
>> >> >> > return "ins\\t%0.[%p2], wzr";
>> >> >> >   }
>> >> >> > )
>> >> >> >
>> >> >> > which now matches the above insn produced by combine.
>> >> >> > However, in reload dump, it creates a new insn for assigning
>> >> >> > register to (const_vector (const_int 0)),
>> >> >> > which results in:
>> >> >> > (insn 19 8 13 2 (set (reg:V4SI 33 v1 [99])
>> >> >> > (const_vector:V4SI [
>> >> >> > (const_int 0 [0]) repeated x4
>> >> >> > ])) "wzr-test.c":8:1 1269 {*aarch64_simd_movv4si}
>> >> >> >  (nil))
>> >> >> > (insn 13 19 14 2 (set (reg/i:V4SI 32 v0)
>> >> >> > (vec_merge:V4SI (reg:V4SI 33 v1 [99])
>> >> >> > (reg:V4SI 32 v0 [97])
>> >> >> > (const_int 8 [0x8]))) "wzr-test.c":8:1 1808
>> >> >> > {aarch64_simd_vec_set_zerov4si}
>> >> >> >  (nil))
>> >> >> >
>> >> >> > and eventually the code-gen:
>> >> >> > foo:
>> >> >> > moviv1.4s, 0
>> >> >> > ins v0.s[3], wzr
>> >> >> > ret
>> >> >> >
>> >> >> > To get rid of redundant assignment of 0 to v1, I tried to split the
>> >> >> > above pattern
>> >> >> > as in the attached patch. This works to emit code-gen:
>> >> >> > foo:
>> >> >> > ins v0.s[3], wzr
>> >> >> > ret
>> >> >> >
>> >> >> > However, I am not sure if this is the right approach. Could you 
>> >> >> > suggest,
>> >> >> > if it'd be possible to get rid of UNSPEC_SETZERO in the patch ?
>> >> >>
>> >> >> The problem is with the "w" constraint on operand 1, which tells LRA
>> >> >> to force the zero into an FPR.  It should work if you remove the
>> >> >> constraint.
>> >> > Ah indeed, sorry about that, changing the constrained works.
>> >>
>> >> "i" isn't right though, because that's for scalar integers.
>> >> There's no need for any constraint here -- the predicate does
>> >> all of the work.
>> >>
>> >> > Does the attached patch look OK after bootstrap+test ?
>> >> > Since we're in stage-4, shall it be OK to commit now, or queue it for 
>> >> > stage-1 ?
>> >>
>> >> It needs tests as well. :-)
>> >>
>> >> Also:
>> >>
>> >> > Thanks,
>> >> > Prathamesh
>> >> >
>> >> >
>> >> >>
>> >> >> Also, I think you'll need to use zr for the zero, so that
>> >> >> it uses xzr for 64-bit elements.
>> >> >>
>> >> >> I think this and the existing patterns ought to test
>> >> >> exact_log2 (INTVAL (operands[2])) >= 0 in the insn condition,
>> >> >> since there's no guarantee that RTL optimisations won't form
>> >> >> vec_merges that have other masks.
>> >> >>
>> >> >> Thanks,
>> >> >> Richard
>> >> >
>> >> > [aarch64] Use wzr/xzr for assigning 0 to vector element.
>> >> >
>> >> > gcc/ChangeLog:
>> >> >   * config/aaarch64/aarch64-simd.md 
>> >> > (aarch64_simd_vec_set_zero):
>> >> >   New pattern.
>> >> >   * config/aarch64/predicates.md (const_dup0_operand): New.
>> >> >
>> >> > diff --git a/gcc/config/aarch64/aarch64-simd.md 
>> >> > b/gcc/config/aarch64/aarch64-simd.md
>> >> > index 104088f67d2..8e54ee4e886 100644
>> >> > --- a/gcc/config/aarch64/aarch64-simd.md
>> >> > +++ b/gcc/config/aarch64/aarch64-simd.md
>> >> > @@ -1083,6 +1083,20 @@
>> >> >[(set_attr "type" "neon_ins, neon_

Re: [PATCH 2/3] arm: Remove unnecessary zero-extending of MVE predicates before use [PR 107674]

[Richard Sandiford via Gcc-patches]

Richard Sandiford via Gcc-patches  writes:
> "Andre Vieira (lists)"  writes:
>> Hi,
>>
>> This patch teaches GCC that zero-extending a MVE predicate from 16-bits 
>> to 32-bits and then only using 16-bits is a no-op.
>> It does so in two steps:
>> - it lets gcc know that it can access any MVE predicate mode using any 
>> other MVE predicate mode without needing to copy it, using the 
>> TARGET_MODES_TIEABLE_P hook,
>> - it teaches simplify_subreg to optimize a subreg with a vector 
>> outermode, by replacing this outermode with a same-sized integer mode 
>> and trying the avalailable optimizations, then if successful it 
>> surrounds the result with a subreg casting it back to the original 
>> vector outermode.
>>
>> This removes the unnecessary zero-extending shown on PR 107674 (though 
>> it's a sign-extend there), that was introduced in gcc 11.
>>
>> Bootstrapped on aarch64-none-linux-gnu and regression tested on 
>> arm-none-eabi and armeb-none-eabi for armv8.1-m.main+mve.fp.
>>
>> OK for trunk?
>>
>> gcc/ChangeLog:
>>
>>  PR target/107674
>>  * conig/arm/arm.cc (arm_hard_regno_mode_ok): Use new MACRO.
>>  (arm_modes_tieable_p): Make MVE predicate modes tieable.
>>  * config/arm/arm.h (VALID_MVE_PRED_MODE):  New define.
>>  * simplify-rtx.cc (simplify_context::simplify_subreg): Teach
>>  simplify_subreg to simplify subregs where the outermode is not scalar.
>>
>> gcc/testsuite/ChangeLog:
>>
>>  * gcc.target/arm/mve/mve_vpt.c: Change to remove unecessary
>>  zero-extend.
>>
>> diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
>> index 
>> 6f7ecf9128047647fc41677e634cd9612a13242b..4352c830cb6d2e632a225edea861b5ceb35dd035
>>  100644
>> --- a/gcc/config/arm/arm.h
>> +++ b/gcc/config/arm/arm.h
>> @@ -1091,6 +1091,10 @@ extern const int arm_arch_cde_coproc_bits[];
>> || (MODE) == V16QImode || (MODE) == V8HFmode || (MODE) == V4SFmode \
>> || (MODE) == V2DFmode)
>>  
>> +#define VALID_MVE_PRED_MODE(MODE) \
>> +  ((MODE) == HImode \
>> +   || (MODE) == V16BImode || (MODE) == V8BImode || (MODE) == V4BImode)
>> +
>>  #define VALID_MVE_SI_MODE(MODE) \
>>((MODE) == V2DImode ||(MODE) == V4SImode || (MODE) == V8HImode \
>> || (MODE) == V16QImode)
>> diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
>> index 
>> 3f171188de513e258369397e4726afe27bd9fdbf..18460ef5280be8c1df85eff424a1bf66d6019c0a
>>  100644
>> --- a/gcc/config/arm/arm.cc
>> +++ b/gcc/config/arm/arm.cc
>> @@ -25564,10 +25564,7 @@ arm_hard_regno_mode_ok (unsigned int regno, 
>> machine_mode mode)
>>  return false;
>>  
>>if (IS_VPR_REGNUM (regno))
>> -return mode == HImode
>> -  || mode == V16BImode
>> -  || mode == V8BImode
>> -  || mode == V4BImode;
>> +return VALID_MVE_PRED_MODE (mode);
>>  
>>if (TARGET_THUMB1)
>>  /* For the Thumb we only allow values bigger than SImode in
>> @@ -25646,6 +25643,10 @@ arm_modes_tieable_p (machine_mode mode1, 
>> machine_mode mode2)
>>if (GET_MODE_CLASS (mode1) == GET_MODE_CLASS (mode2))
>>  return true;
>>  
>> +  if (TARGET_HAVE_MVE
>> +  && (VALID_MVE_PRED_MODE (mode1) && VALID_MVE_PRED_MODE (mode2)))
>> +return true;
>> +
>>/* We specifically want to allow elements of "structure" modes to
>>   be tieable to the structure.  This more general condition allows
>>   other rarer situations too.  */
>> diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc
>> index 
>> 7fb1e97fbea4e7b8b091f5724ebe0cb61eee7ec3..a951272186585c0a5cc3e0155285e7a635865f42
>>  100644
>> --- a/gcc/simplify-rtx.cc
>> +++ b/gcc/simplify-rtx.cc
>> @@ -7652,6 +7652,22 @@ simplify_context::simplify_subreg (machine_mode 
>> outermode, rtx op,
>>  }
>>  }
>>  
>> +  /* Try simplifying a SUBREG expression of a non-integer OUTERMODE by 
>> using a
>> + NEW_OUTERMODE of the same size instead, other simplifications rely on
>> + integer to integer subregs and we'd potentially miss out on 
>> optimizations
>> + otherwise.  */
>
> How about:
>
>   /* If the outer mode is not integral, try taking a subreg with the
>  equivalent integer outer mode and then bitcasting the result.
>  Other simplifications rely on integer to integer subregs and we'd
>  potentially miss out on optimizations otherwise.  */
>
> (Think it's easier to read as two sentences, and there's no
> new_outermode in the code.)
>
>> +  if (known_gt (GET_MODE_SIZE (innermode),
>> +GET_MODE_SIZE (outermode))
>> +  && SCALAR_INT_MODE_P (innermode)
>> +  && !SCALAR_INT_MODE_P (outermode)
>> +  && int_mode_for_size (GET_MODE_BITSIZE (outermode),
>> +0).exists (&int_outermode))
>> +{
>> +  rtx tem = simplify_subreg (int_outermode, op, innermode, byte);
>> +  if (tem)
>> +return simplify_gen_subreg (outermode, tem, GET_MODE (tem), byte);
>
> Perhaps safer as s/GET_MODE (tem)/int_outermode/, in case TEM turns
> out to be constan

[PATCH] testsuite: Fix pr108574-3.c failed in arch where sign defaults to unsigned.

[Xianmiao Qu via Gcc-patches]

In the architecture where sign defaults to unsigned, the 'f' will be zero
extended to int type in the expression 'd = ~(f & ~2880764155)', then the
'd' will become -1 wich cause the case to fail.
So it's ok for the architectures where sign defaults to signed like x86,
but failed for the architectures where sign defaults to unsigned like arm
and csky. Change char to signed char to avoid this problem.

gcc/testsuite:
* gcc.dg/torture/pr108574-3.c (b, f): Change type from char to
signed char.
---
 gcc/testsuite/gcc.dg/torture/pr108574-3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/torture/pr108574-3.c 
b/gcc/testsuite/gcc.dg/torture/pr108574-3.c
index 3c9146e31ac..b4d5dae9f80 100644
--- a/gcc/testsuite/gcc.dg/torture/pr108574-3.c
+++ b/gcc/testsuite/gcc.dg/torture/pr108574-3.c
@@ -1,7 +1,7 @@
 /* { dg-do run } */
 
 int a = 3557301289, d;
-char b, f;
+signed char b, f;
 unsigned short c = 241;
 short e, g;
 static void h() {
-- 
2.32.1 (Apple Git-133)

[committed] RISC-V: Simplify testcase condition for RVV tests [NFC]

[Kito Cheng]

We got some trouble on some platform, it show get twice for the asm, but
it only show once, seems like our pattern might be too complicated, so
simplify that make every platform happey with those testcase.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/vsetvl/vlmax_phi-10.c: Refine the scan
condition.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-11.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-12.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-13.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-14.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-15.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-16.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-17.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-18.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-19.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-20.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-21.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-22.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-23.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-24.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-25.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-26.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-27.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-28.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-2.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-3.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-4.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-5.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-6.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-7.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-8.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/vlmax_phi-9.c: Ditto.
---
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-10.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-11.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-12.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-13.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-14.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-15.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-16.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-17.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-18.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-19.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-2.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-20.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-21.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-22.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-23.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-24.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-25.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-26.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-27.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-28.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-3.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-4.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-5.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-6.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-7.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-8.c  | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-9.c  | 2 +-
 28 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c 
b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c
index cd58e53a822..be2406c 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c
@@ -34,4 +34,4 @@ void f (void * restrict in, void * restrict out, int n, int 
cond)
 }
 
 /* { dg-final { scan-assembler-times 
{vsetvli\s+[a-x0-9]+,\s*zero,\s*e8,\s*mf8,\s*t[au],\s*m[au]} 4 { target { 
no-opts "-O0"  no-opts "-Os" no-opts "-funroll-loops" no-opts "-g" no-opts 
"-flto" } } } } */
-/* { dg-final { scan-assembler-times 
{ble\tra|[sgtf]p|t[0-6]|s[0-9]|s10|s11|a[0-7],zero,\.L[0-9]+\s*\.L[0-9]+\:\s*vle8\.v\s+(?:v[0-9]|v[1-2][0-9]|v3[0-1]),0\s*\([a-x0-9]+\)}
 1 { target { no-opts "-O0"  no-opts "-Os" no-opts "-funroll-loops" no-opts 
"-g" no-opts "-flto" } } } } */
+/* { dg-final { scan-assembler-times 
{ble\t[a-x0-9]+,zero,\.L[0-9]+\s*\.L[0-9]+\:\s*vle8\.v\s+v[0-9]+,0\([a-x0-9]+\)}
 1 { target { no-opts "-O0"  no-opts "-Os" no-opts "-funroll-loops" no-opts 
"-g" no-opts "-flto" } } } } */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/vlm

[PATCH] c++: wrong error with constexpr array and value-init [PR108158]

[Marek Polacek via Gcc-patches]

In this test case, we find ourselves evaluating 't' which is
((const struct carray *) this)->data_[VIEW_CONVERT_EXPR(index)]
in cxx_eval_array_reference.  ctx->object is non-null, a RESULT_DECL, so
we replace it with 't':

  new_ctx.object = t; // result_decl replaced

and then we go to cxx_eval_constant_expression to evaluate an
AGGR_INIT_EXPR, where we end up evaluating an INIT_EXPR (which is in the
body of the constructor for seed_or_index):

  ((struct seed_or_index *) this)->value_ = NON_LVALUE_EXPR <0>

whereupon in cxx_eval_store_expression we go to the probe loop
where the 'this' is evaluated to

  ze_set.tables_.first_table_.data_[0]

so the 'object' is ze_set, but that isn't in ctx->global->get_value_ptr
so we fail with a bogus error.  ze_set is not there because it comes
from a different constexpr context (it's not in cv_cache either).

The problem started with r12-2304 where I added the new_ctx.object
replacement.  That was to prevent a type mismatch: the type of 't'
and ctx.object were different.

It seems clear that we shouldn't have replaced ctx.object here.
The cxx_eval_array_reference I mentioned earlier is called from
cxx_eval_store_expression:
 6257   init = cxx_eval_constant_expression (&new_ctx, init, vc_prvalue,
 6258non_constant_p, overflow_p);
which already created a new context, whose .object we should be
using unless, for instance, INIT contained a.b and we're evaluating
the 'a' part, which I think was the case for r12-2304; in that case
ctx.object has to be something different.

A relatively safe fix should be to check the types before replacing
ctx.object, as in the below.

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

PR c++/108158

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_array_reference): Don't replace
new_ctx.object if its type is the same as elem_type.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/constexpr-108158.C: New test.
---
 gcc/cp/constexpr.cc   |  8 +++--
 gcc/testsuite/g++.dg/cpp1y/constexpr-108158.C | 32 +++
 2 files changed, 38 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-108158.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index be99bec17e7..00582cfffe2 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -4301,9 +4301,13 @@ cxx_eval_array_reference (const constexpr_ctx *ctx, tree 
t,
   if (!SCALAR_TYPE_P (elem_type))
 {
   new_ctx = *ctx;
-  if (ctx->object)
+  if (ctx->object
+ && !same_type_ignoring_top_level_qualifiers_p
+ (elem_type, TREE_TYPE (ctx->object)))
/* If there was no object, don't add one: it could confuse us
-  into thinking we're modifying a const object.  */
+  into thinking we're modifying a const object.  Similarly, if
+  the types are the same, replacing .object could lead to a
+  failure to evaluate it (c++/108158).  */
new_ctx.object = t;
   new_ctx.ctor = build_constructor (elem_type, NULL);
   ctx = &new_ctx;
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-108158.C 
b/gcc/testsuite/g++.dg/cpp1y/constexpr-108158.C
new file mode 100644
index 000..e5f5e9954e5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-108158.C
@@ -0,0 +1,32 @@
+// PR c++/108158
+// { dg-do compile { target c++14 } }
+
+template  struct carray {
+  T data_[N]{};
+  constexpr T operator[](long index) const { return data_[index]; }
+};
+struct seed_or_index {
+private:
+  long value_ = 0;
+};
+template  struct pmh_tables {
+  carray first_table_;
+  template 
+  constexpr void lookup(KeyType, HasherType) const {
+first_table_[0];
+  }
+};
+template  struct unordered_set {
+  int equal_;
+  carray keys_;
+  pmh_tables tables_;
+  constexpr unordered_set() : equal_{} {}
+  template 
+  constexpr auto lookup(KeyType key, Hasher hash) const {
+tables_.lookup(key, hash);
+return keys_;
+  }
+};
+constexpr unordered_set<3> ze_set;
+constexpr auto nocount = ze_set.lookup(4, int());
+constexpr auto nocount2 = unordered_set<3>{}.lookup(4, int());

base-commit: 897a0502056e6cc6613f26e0b22d1c1e06b1490f
-- 
2.39.1

[PATCH v3] c++: fix ICE with -Wduplicated-cond [PR107593]

[Marek Polacek via Gcc-patches]

On Mon, Jan 30, 2023 at 01:12:00PM -0500, Jason Merrill wrote:
> On 1/30/23 11:00, Marek Polacek wrote:
> > On Fri, Jan 27, 2023 at 06:17:00PM -0500, Patrick Palka wrote:
> > > On Fri, 27 Jan 2023, Marek Polacek wrote:
> > > 
> > > > On Fri, Jan 27, 2023 at 05:15:00PM -0500, Patrick Palka wrote:
> > > > > On Thu, 26 Jan 2023, Marek Polacek via Gcc-patches wrote:
> > > > > 
> > > > > > Here we crash because a CAST_EXPR, representing T(), doesn't have
> > > > > > its operand, and operand_equal_p's STRIP_ANY_LOCATION_WRAPPER 
> > > > > > doesn't
> > > > > > expect that.  (o_e_p is called from 
> > > > > > warn_duplicated_cond_add_or_warn.)
> > > > > > 
> > > > > > In the past we've adjusted o_e_p to better cope with template codes,
> > > > > > but in this case I think we just want to avoid attempting to warn
> > > > > > about inst-dependent expressions; I don't think I've ever envisioned
> > > > > > -Wduplicated-cond to warn about them.
> > > > > > 
> > > > > > The ICE started with r12-6022, two-stage name lookup for overloaded
> > > > > > operators, which gave dependent operators a TREE_TYPE (in 
> > > > > > particular,
> > > > > > DEPENDENT_OPERATOR_TYPE), so we no longer bail out here in o_e_p:
> > > > > > 
> > > > > >/* Similar, if either does not have a type (like a template id),
> > > > > >   they aren't equal.  */
> > > > > >if (!TREE_TYPE (arg0) || !TREE_TYPE (arg1))
> > > > > >  return false;
> > > > > > 
> > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > > > > 
> > > > > > PR c++/107593
> > > > > > 
> > > > > > gcc/cp/ChangeLog:
> > > > > > 
> > > > > > * parser.cc (cp_parser_selection_statement): Don't do
> > > > > > -Wduplicated-cond when the condition is dependent.
> > > > > > 
> > > > > > gcc/testsuite/ChangeLog:
> > > > > > 
> > > > > > * g++.dg/warn/Wduplicated-cond3.C: New test.
> > > > > > ---
> > > > > >   gcc/cp/parser.cc  |  3 +-
> > > > > >   gcc/testsuite/g++.dg/warn/Wduplicated-cond3.C | 38 
> > > > > > +++
> > > > > >   2 files changed, 40 insertions(+), 1 deletion(-)
> > > > > >   create mode 100644 gcc/testsuite/g++.dg/warn/Wduplicated-cond3.C
> > > > > > 
> > > > > > diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
> > > > > > index 4cdc1cd472f..3df85d49e16 100644
> > > > > > --- a/gcc/cp/parser.cc
> > > > > > +++ b/gcc/cp/parser.cc
> > > > > > @@ -13209,7 +13209,8 @@ cp_parser_selection_statement (cp_parser* 
> > > > > > parser, bool *if_p,
> > > > > > /* Add the condition.  */
> > > > > > condition = finish_if_stmt_cond (condition, statement);
> > > > > > -   if (warn_duplicated_cond)
> > > > > > +   if (warn_duplicated_cond
> > > > > > +   && !instantiation_dependent_expression_p (condition))
> > > > > >   warn_duplicated_cond_add_or_warn (token->location, 
> > > > > > condition,
> > > > > > &chain);
> > > > > 
> > > > > I noticed warn_duplicated_cond_add_or_warn already has logic to handle
> > > > > TREE_SIDE_EFFECTS conditions by invaliding the entire chain.  I wonder
> > > > > if we'd want to do the same for instantiation-dep conditions?
> > > > 
> > > > warn_duplicated_cond_add_or_warn lives in c-family/c-warn.cc so I can't
> > > > use instantiation_dependent_expression_p there.  Sure, I could write a
> > > > C++ wrapper but with my patch we just won't add CONDITION to the chain
> > > > which I thought would work just as well.
> 
> Or maybe define instantiation_dependent_expression_p in the C front-end to
> just return false?

Like this?

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

-- >8 --
Here we crash because a CAST_EXPR, representing T(), doesn't have
its operand, and operand_equal_p's STRIP_ANY_LOCATION_WRAPPER doesn't
expect that.  (o_e_p is called from warn_duplicated_cond_add_or_warn.)

In the past we've adjusted o_e_p to better cope with template codes,
but in this case I think we just want to avoid attempting to warn
about inst-dependent expressions; I don't think I've ever envisioned
-Wduplicated-cond to warn about them.  Also destroy the chain when
an inst-dependent expression is encountered to not warn in
Wduplicated-cond4.C.

The ICE started with r12-6022, two-stage name lookup for overloaded
operators, which gave dependent operators a TREE_TYPE (in particular,
DEPENDENT_OPERATOR_TYPE), so we no longer bail out here in o_e_p:

  /* Similar, if either does not have a type (like a template id),
 they aren't equal.  */
  if (!TREE_TYPE (arg0) || !TREE_TYPE (arg1))
return false;

PR c++/107593
PR c++/108597

gcc/c-family/ChangeLog:

* c-common.h (instantiation_dependent_expression_p): Declare.
* c-warn.cc (warn_duplicated_cond_add_or_warn): If the condition
is dependent, invalidate the chain.

gcc/c/ChangeLog:

* c-objc-common.cc (instantiation_dependent_expression_p): New.

gcc/cp/ChangeLog:

* cp-t

[pushed] wwwdocs: cxx-dr-status: Switch www.open-std.org to https

[Gerald Pfeifer]

One more... Pushed.

Gerald

---
 htdocs/projects/cxx-dr-status.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/projects/cxx-dr-status.html 
b/htdocs/projects/cxx-dr-status.html
index 748226c2..d87466a3 100644
--- a/htdocs/projects/cxx-dr-status.html
+++ b/htdocs/projects/cxx-dr-status.html
@@ -15,7 +15,7 @@
 
   This table tracks the implementation status of C++ defect reports in GCC.
   It is based on C++ Standard Core Language Issue Table of Contents, Revision
-  109 (http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html";>here).
+  109 (https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html";>here).
 
   
 
-- 
2.39.1

[pushed] doc: Change fsf.org to www.fsf.org in URLs (GFDL)

[Gerald Pfeifer]

We have been getting a 301 (permanent redirect) http response from
the server for a long while.

Pushed.
Gerald

gcc/ChangeLog:

* doc/include/fdl.texi: Change fsf.org to www.fsf.org.
---
 gcc/doc/include/fdl.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/doc/include/fdl.texi b/gcc/doc/include/fdl.texi
index e2bcdfd579b..af1a9c1d196 100644
--- a/gcc/doc/include/fdl.texi
+++ b/gcc/doc/include/fdl.texi
@@ -7,7 +7,7 @@ gpl(7), fsf-funding(7).
 @c man end
 @c man begin COPYRIGHT
 Copyright @copyright{} 2000, 2001, 2002, 2007, 2008 Free Software Foundation, 
Inc.
-@uref{https://fsf.org/}
+@uref{https://www.fsf.org}
 
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.
@@ -46,7 +46,7 @@ of this license document, but changing it is not allowed.
 
 @display
 Copyright @copyright{} 2000, 2001, 2002, 2007, 2008 Free Software Foundation, 
Inc.
-@uref{https://fsf.org/}
+@uref{https://www.fsf.org}
 
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.
-- 
2.39.1

Re: [PATCH 2/3] arm: Remove unnecessary zero-extending of MVE predicates before use [PR 107674]

[Richard Sandiford via Gcc-patches]

"Andre Vieira (lists)"  writes:
> Hi,
>
> This patch teaches GCC that zero-extending a MVE predicate from 16-bits 
> to 32-bits and then only using 16-bits is a no-op.
> It does so in two steps:
> - it lets gcc know that it can access any MVE predicate mode using any 
> other MVE predicate mode without needing to copy it, using the 
> TARGET_MODES_TIEABLE_P hook,
> - it teaches simplify_subreg to optimize a subreg with a vector 
> outermode, by replacing this outermode with a same-sized integer mode 
> and trying the avalailable optimizations, then if successful it 
> surrounds the result with a subreg casting it back to the original 
> vector outermode.
>
> This removes the unnecessary zero-extending shown on PR 107674 (though 
> it's a sign-extend there), that was introduced in gcc 11.
>
> Bootstrapped on aarch64-none-linux-gnu and regression tested on 
> arm-none-eabi and armeb-none-eabi for armv8.1-m.main+mve.fp.
>
> OK for trunk?
>
> gcc/ChangeLog:
>
>   PR target/107674
>  * conig/arm/arm.cc (arm_hard_regno_mode_ok): Use new MACRO.
>  (arm_modes_tieable_p): Make MVE predicate modes tieable.
>   * config/arm/arm.h (VALID_MVE_PRED_MODE):  New define.
>   * simplify-rtx.cc (simplify_context::simplify_subreg): Teach
>   simplify_subreg to simplify subregs where the outermode is not scalar.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/arm/mve/mve_vpt.c: Change to remove unecessary
>   zero-extend.
>
> diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
> index 
> 6f7ecf9128047647fc41677e634cd9612a13242b..4352c830cb6d2e632a225edea861b5ceb35dd035
>  100644
> --- a/gcc/config/arm/arm.h
> +++ b/gcc/config/arm/arm.h
> @@ -1091,6 +1091,10 @@ extern const int arm_arch_cde_coproc_bits[];
> || (MODE) == V16QImode || (MODE) == V8HFmode || (MODE) == V4SFmode \
> || (MODE) == V2DFmode)
>  
> +#define VALID_MVE_PRED_MODE(MODE) \
> +  ((MODE) == HImode  \
> +   || (MODE) == V16BImode || (MODE) == V8BImode || (MODE) == V4BImode)
> +
>  #define VALID_MVE_SI_MODE(MODE) \
>((MODE) == V2DImode ||(MODE) == V4SImode || (MODE) == V8HImode \
> || (MODE) == V16QImode)
> diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
> index 
> 3f171188de513e258369397e4726afe27bd9fdbf..18460ef5280be8c1df85eff424a1bf66d6019c0a
>  100644
> --- a/gcc/config/arm/arm.cc
> +++ b/gcc/config/arm/arm.cc
> @@ -25564,10 +25564,7 @@ arm_hard_regno_mode_ok (unsigned int regno, 
> machine_mode mode)
>  return false;
>  
>if (IS_VPR_REGNUM (regno))
> -return mode == HImode
> -  || mode == V16BImode
> -  || mode == V8BImode
> -  || mode == V4BImode;
> +return VALID_MVE_PRED_MODE (mode);
>  
>if (TARGET_THUMB1)
>  /* For the Thumb we only allow values bigger than SImode in
> @@ -25646,6 +25643,10 @@ arm_modes_tieable_p (machine_mode mode1, 
> machine_mode mode2)
>if (GET_MODE_CLASS (mode1) == GET_MODE_CLASS (mode2))
>  return true;
>  
> +  if (TARGET_HAVE_MVE
> +  && (VALID_MVE_PRED_MODE (mode1) && VALID_MVE_PRED_MODE (mode2)))
> +return true;
> +
>/* We specifically want to allow elements of "structure" modes to
>   be tieable to the structure.  This more general condition allows
>   other rarer situations too.  */
> diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc
> index 
> 7fb1e97fbea4e7b8b091f5724ebe0cb61eee7ec3..a951272186585c0a5cc3e0155285e7a635865f42
>  100644
> --- a/gcc/simplify-rtx.cc
> +++ b/gcc/simplify-rtx.cc
> @@ -7652,6 +7652,22 @@ simplify_context::simplify_subreg (machine_mode 
> outermode, rtx op,
>   }
>  }
>  
> +  /* Try simplifying a SUBREG expression of a non-integer OUTERMODE by using 
> a
> + NEW_OUTERMODE of the same size instead, other simplifications rely on
> + integer to integer subregs and we'd potentially miss out on 
> optimizations
> + otherwise.  */

How about:

  /* If the outer mode is not integral, try taking a subreg with the
 equivalent integer outer mode and then bitcasting the result.
 Other simplifications rely on integer to integer subregs and we'd
 potentially miss out on optimizations otherwise.  */

(Think it's easier to read as two sentences, and there's no
new_outermode in the code.)

> +  if (known_gt (GET_MODE_SIZE (innermode),
> + GET_MODE_SIZE (outermode))
> +  && SCALAR_INT_MODE_P (innermode)
> +  && !SCALAR_INT_MODE_P (outermode)
> +  && int_mode_for_size (GET_MODE_BITSIZE (outermode),
> + 0).exists (&int_outermode))
> +{
> +  rtx tem = simplify_subreg (int_outermode, op, innermode, byte);
> +  if (tem)
> + return simplify_gen_subreg (outermode, tem, GET_MODE (tem), byte);

Perhaps safer as s/GET_MODE (tem)/int_outermode/, in case TEM turns
out to be constant.

OK for the simplify-rtx.cc part with those changes.

Thanks,
Richard


> +}
> +
>/* If OP is a vector comparison and the subreg is not changing the
>   

Re: Patch ping

[Richard Sandiford via Gcc-patches]

Jakub Jelinek  writes:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605965.html
>   - ABI - aarch64: Add bfloat16_t support for aarch64 (enabling it in GCC 14
> will be harder)

Sorry for the delay on this.  There's still an ongoing debate about
whether to keep the current AArch64 mangling or switch to the new one.

Thanks,
Richard

[pushed] libstdc++: Update links in the Memory section of the manual

[Gerald Pfeifer]

Consistency simplifies life.

Pushed.

Gerald


libstdc++-v3/ChangeLog:

* doc/xml/manual/shared_ptr.xml: Move links from both
http://open-std.org and http://www.open-std.org to
https://www.open-std.org.
* doc/html/manual/memory.html: Regenerate.
---
 libstdc++-v3/doc/html/manual/memory.html   | 8 
 libstdc++-v3/doc/xml/manual/shared_ptr.xml | 6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/libstdc++-v3/doc/html/manual/memory.html 
b/libstdc++-v3/doc/html/manual/memory.html
index d9abdaf8c88..a70613e8fd6 100644
--- a/libstdc++-v3/doc/html/manual/memory.html
+++ b/libstdc++-v3/doc/html/manual/memory.html
@@ -621,19 +621,19 @@ be private.
 invaluable advice on thread safety.  Phillip Jordan and Paolo
 Carlini for the lock policy implementation.
   Bibliography
-   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm"; 
target="_top">
+   https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm"; 
target="_top">
   Improving shared_ptr for C++0x, Revision 2

   . 
   N2351
 . 
-   http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2456.html"; 
target="_top">
+   https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2456.html"; 
target="_top">
   C++ Standard Library Active Issues List

   . 
   N2456
 . 
-   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf"; 
target="_top">
+   https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf"; 
target="_top">
   Working Draft, Standard for Programming Language C++

   . 
@@ -644,4 +644,4 @@ be private.

   . 
   N2461
-. Prev??Up??NextPairs??Home??Traits
\ No newline at end of file
+. Prev??Up??NextPairs??Home??Traits
diff --git a/libstdc++-v3/doc/xml/manual/shared_ptr.xml 
b/libstdc++-v3/doc/xml/manual/shared_ptr.xml
index 06fc662e6ef..07cc4d52715 100644
--- a/libstdc++-v3/doc/xml/manual/shared_ptr.xml
+++ b/libstdc++-v3/doc/xml/manual/shared_ptr.xml
@@ -423,7 +423,7 @@ be private.
   
   
http://www.w3.org/1999/xlink";
- 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm";>
+ 
xlink:href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm";>
   Improving shared_ptr for C++0x, Revision 2

   
@@ -436,7 +436,7 @@ be private.
   
   
http://www.w3.org/1999/xlink";
- 
xlink:href="http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2456.html";>
+ 
xlink:href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2456.html";>
   C++ Standard Library Active Issues List

   
@@ -449,7 +449,7 @@ be private.
   
   
http://www.w3.org/1999/xlink";
- 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf";>
+ 
xlink:href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf";>
   Working Draft, Standard for Programming Language C++

   
-- 
2.39.1

Re: [PATCH, wwwdocs] readings: Update AIX linker links

[David Edelsohn via Gcc-patches]

On Mon, Jan 30, 2023 at 4:52 PM Gerald Pfeifer  wrote:

> Hi David,
>
> the noticed the links to the AIX 4.3 and AIX 5L docs were broken and could
> not find a good replacement, though I did find one for AIX 7.2.
>
> How about the patch below?
>

Hi, Gerald

That change is fine with me.

Thanks, David


>
> Or should we omit such links? (Or do you have recommendations?)
>
> Thanks,
> Gerald
>
>
> diff --git a/htdocs/readings.html b/htdocs/readings.html
> index 3f41ef2a..0a978e8f 100644
> --- a/htdocs/readings.html
> +++ b/htdocs/readings.html
> @@ -270,8 +270,7 @@ names.
>Manufacturer: IBM, Motorola
>https://www.ibm.com/systems/power/openpower/";>Power
> ISA
>https://openpowerfoundation.org/?resource_lib=64-bit-elf-v2-abi-specification-power-architecture";>64-Bit
> ELF V2 ABI - OpenPOWER ABI
> -  http://publib16.boulder.ibm.com/pseries/en_US/infocenter/base/43_docs/aixassem/alangref/toc.htm";>AIX
> V4.3 Assembler Language Ref.
> -  http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixassem/alangref/alangreftfrm.htm";>AIX
> 5L Assembler Language Ref.
> +  https://www.ibm.com/docs/en/ssw_aix_72/assembler/assembler_pdf.pdf";>AIX
> 7.2 Assembler Language Reference
>   
>
>   rx
>

Re: [committed] wwwdocs: cxx-status: Move www.open-std.org to https

[Gerald Pfeifer]

On Sun, 31 Jul 2022, Jonathan Wakely wrote:
>> Marek, Jason, Jonathan - I noticed that (in other places) we have both
>> links to www.open-std.org and open-std.org, both of which seem to work.
>>
>> What is the preferred spelling of that site? With or without www? (The
>> latter would be shorter and sweeter. ;-)
> https://www.open-std.org/ says "The site www.open-std.org is holding a
> number of web pages for groups producing open standards:" but I don't
> think it really matters which we use.

It's not a biggie, though consistency never hurts (and makes it harder to 
miss something). :-)

At this point we only have two or so instances of open-std.org without
www. left, and I'll be moving those over as part of some broader changes.

Thanks,
Gerald

[PATCH] Fortran: prevent redundant integer division truncation warnings [PR108592]

[Harald Anlauf via Gcc-patches]

Dear Fortranners,

the subject says it all: in some cases we emit redundant integer division
truncation warnings (2 or 4), where just one would have been sufficient.
This is solved by using gfc_warning instead of gfc_warning_now.

The testcase uses a suggestion by Andrew to verify that we get the
desired warning exactly once.

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

Thanks,
Harald

From 8340523c8df8edd008174d44e87c0fa54b58b2c7 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Mon, 30 Jan 2023 22:46:43 +0100
Subject: [PATCH] Fortran: prevent redundant integer division truncation
 warnings [PR108592]

gcc/fortran/ChangeLog:

	PR fortran/108592
	* arith.cc (gfc_arith_divide): Emit integer division truncation
	warnings using gfc_warning instead of gfc_warning_now to prevent
	redundant messages.

gcc/testsuite/ChangeLog:

	PR fortran/108592
	* gfortran.dg/pr108592.f90: New test.
---
 gcc/fortran/arith.cc   | 2 +-
 gcc/testsuite/gfortran.dg/pr108592.f90 | 8 
 2 files changed, 9 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr108592.f90

diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index 6de6d21c73d..d0d1c0b03d2 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -778,7 +778,7 @@ gfc_arith_divide (gfc_expr *op1, gfc_expr *op2, gfc_expr **resultp)
 	{
 	  char *p;
 	  p = mpz_get_str (NULL, 10, result->value.integer);
-	  gfc_warning_now (OPT_Winteger_division, "Integer division "
+	  gfc_warning (OPT_Winteger_division, "Integer division "
 			   "truncated to constant %qs at %L", p,
 			   &op1->where);
 	  free (p);
diff --git a/gcc/testsuite/gfortran.dg/pr108592.f90 b/gcc/testsuite/gfortran.dg/pr108592.f90
new file mode 100644
index 000..224b1d8d1fc
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr108592.f90
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! { dg-options "-Winteger-division" }
+! PR fortran/108592 - warn only once for truncation of integer division
+
+program foo
+  if (8 < (20/9)) stop 1 ! { dg-bogus "Integer division.*Integer division" }
+! { dg-message "Integer division truncated" "" { target *-*-* } .-1 }
+end program
--
2.35.3

[PATCH, wwwdocs] readings: Update AIX linker links

[Gerald Pfeifer]

Hi David,

the noticed the links to the AIX 4.3 and AIX 5L docs were broken and could 
not find a good replacement, though I did find one for AIX 7.2.

How about the patch below?

Or should we omit such links? (Or do you have recommendations?)

Thanks,
Gerald


diff --git a/htdocs/readings.html b/htdocs/readings.html
index 3f41ef2a..0a978e8f 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -270,8 +270,7 @@ names.
   Manufacturer: IBM, Motorola
   https://www.ibm.com/systems/power/openpower/";>Power ISA
   https://openpowerfoundation.org/?resource_lib=64-bit-elf-v2-abi-specification-power-architecture";>64-Bit
 ELF V2 ABI - OpenPOWER ABI
-  http://publib16.boulder.ibm.com/pseries/en_US/infocenter/base/43_docs/aixassem/alangref/toc.htm";>AIX
 V4.3 Assembler Language Ref.
-  http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixassem/alangref/alangreftfrm.htm";>AIX
 5L Assembler Language Ref.
+  https://www.ibm.com/docs/en/ssw_aix_72/assembler/assembler_pdf.pdf";>AIX 
7.2 Assembler Language Reference
  
  
  rx

[pushed] wwwdocs: gcc-4.7: Adjust link to "Collecting User-Mode Dumps"

[Gerald Pfeifer]

After summer 2018 and summer 2019 the third time Microsoft shuffles around 
things... At least the put in place redirects.

Pushed.

Gerald
---
 htdocs/gcc-4.7/changes.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/gcc-4.7/changes.html b/htdocs/gcc-4.7/changes.html
index 3eec7d3d..f98f108c 100644
--- a/htdocs/gcc-4.7/changes.html
+++ b/htdocs/gcc-4.7/changes.html
@@ -636,7 +636,7 @@ well.
   depends on the user environment settings; see the ulimit -c
   setting for POSIX shells, limit coredumpsize for C shells,
   and the https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps";
+  
href="https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps";
   >WER user-mode dumps settings on Windows.
 The https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Debugging-Options.html#index-g_t_0040code_007bfno_002dbacktrace_007d-183";
-- 
2.39.1

[PATCH] c++: ICE on unviable/ambiguous constrained dtors [PR96745]

[Patrick Palka via Gcc-patches]

Here we're crashing from check_bases_and_members due to
CLASSTYPE_DESTRUCTOR being an OVERLOAD which, due to the pruning
performed by add_method, should only happen if there is no viable
destructor or the destructor is ambiguous.

This patch fixes this by making check_bases_and_members naturally handle
CLASSTYPE_DESTRUCTOR being an OVERLOAD.  It's then convenient to prune
the OVERLOAD after diagnosing the inevitable OR failure in check_methods.

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

PR c++/96745

gcc/cp/ChangeLog:

* class.cc (check_methods): Diagnose an unviable OVERLOAD
set for CLASSTYPE_DESTRUCTOR differently from an ambiguous one.
Then prune the OVERLOAD to a single function.
(check_bases_and_members): Handle CLASSTYPE_DESTRUCTOR being
an OVERLOAD when calling deduce_noexcept_on_destructor.
Document why it has to be called before check_methods.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-dtor1.C: New test.
---
 gcc/cp/class.cc | 22 ++---
 gcc/testsuite/g++.dg/cpp2a/concepts-dtor1.C | 18 +
 2 files changed, 37 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-dtor1.C

diff --git a/gcc/cp/class.cc b/gcc/cp/class.cc
index d3ce8532d56..c6878cba2ae 100644
--- a/gcc/cp/class.cc
+++ b/gcc/cp/class.cc
@@ -4808,9 +4808,23 @@ check_methods (tree t)
 in that class with an empty argument list to select the destructor
 for the class, also known as the selected destructor. The program
 is ill-formed if overload resolution fails. */
+ int viable = 0;
+ for (tree fn : ovl_range (dtor))
+   if (constraints_satisfied_p (fn))
+ ++viable;
+ gcc_checking_assert (viable != 1);
+
  auto_diagnostic_group d;
- error_at (location_of (t), "destructor for %qT is ambiguous", t);
+ if (viable == 0)
+   error_at (location_of (t), "no viable destructor for %qT", t);
+ else
+   error_at (location_of (t), "destructor for %qT is ambiguous", t);
  print_candidates (dtor);
+
+ /* Arbitrarily prune the overload set to a single function for
+sake of error recovery.  */
+ tree *slot = find_member_slot (t, dtor_identifier);
+ *slot = get_first_fn (dtor);
}
   else if (user_provided_p (dtor))
TYPE_HAS_NONTRIVIAL_DESTRUCTOR (t) = true;
@@ -6048,10 +6062,12 @@ check_bases_and_members (tree t)
   check_bases (t, &cant_have_const_ctor, &no_const_asn_ref);
 
   /* Deduce noexcept on destructor.  This needs to happen after we've set
- triviality flags appropriately for our bases.  */
+ triviality flags appropriately for our bases, and before checking
+ overriden virtual functions via check_methods.  */
   if (cxx_dialect >= cxx11)
 if (tree dtor = CLASSTYPE_DESTRUCTOR (t))
-  deduce_noexcept_on_destructor (dtor);
+  for (tree fn : ovl_range (dtor))
+   deduce_noexcept_on_destructor (fn);
 
   /* Check all the method declarations.  */
   check_methods (t);
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-dtor1.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-dtor1.C
new file mode 100644
index 000..b1f3b4e579f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-dtor1.C
@@ -0,0 +1,18 @@
+// PR c++/96745
+// { dg-do compile { target c++20 } }
+
+template
+struct A { // { dg-error "destructor for 'A' is ambiguous" }
+  ~A() requires true;
+  ~A() requires (!!true);
+};
+
+A a;
+
+template
+struct B { // { dg-error "no viable destructor for 'B'" }
+  ~B() requires false;
+  ~B() requires (!!false);
+};
+
+B b;
-- 
2.39.1.367.g5cc9858f1b

Re: [PATCH 2/2] c++: speculative constexpr and is_constant_evaluated [PR108243]

[Jason Merrill via Gcc-patches]

On 1/27/23 17:02, Patrick Palka wrote:

This PR illustrates that __builtin_is_constant_evaluated currently acts
as an optimization barrier for our speculative constexpr evaluation,
since we don't want to prematurely fold the builtin to false if the
expression in question would be later manifestly constant evaluated (in
which case it must be folded to true).

This patch fixes this by permitting __builtin_is_constant_evaluated
to get folded as false during cp_fold_function, since at that point
we're sure we're doing manifestly constant evaluation.  To that end
we add a flags parameter to cp_fold that controls what mce_value the
CALL_EXPR case passes to maybe_constant_value.

bootstrapped and rgetsted no x86_64-pc-linux-gnu, does this look OK for
trunk?

PR c++/108243

gcc/cp/ChangeLog:

* cp-gimplify.cc (enum fold_flags): Define.
(cp_fold_data::genericize): Replace this data member with ...
(cp_fold_data::fold_flags): ... this.
(cp_fold_r): Adjust cp_fold_data use and cp_fold_calls.
(cp_fold_function): Likewise.
(cp_fold_maybe_rvalue): Likewise.
(cp_fully_fold_init): Likewise.
(cp_fold): Add fold_flags parameter.  Don't cache if flags
isn't empty.
: Pass mce_false to maybe_constant_value
if if ff_genericize is set.

gcc/testsuite/ChangeLog:

* g++.dg/opt/pr108243.C: New test.
---
  gcc/cp/cp-gimplify.cc   | 76 ++---
  gcc/testsuite/g++.dg/opt/pr108243.C | 29 +++
  2 files changed, 76 insertions(+), 29 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/opt/pr108243.C

diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
index a35cedd05cc..d023a63768f 100644
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -43,12 +43,20 @@ along with GCC; see the file COPYING3.  If not see
  #include "omp-general.h"
  #include "opts.h"
  
+/* Flags for cp_fold and cp_fold_r.  */

+
+enum fold_flags {
+  ff_none = 0,
+  /* Whether we're being called from cp_fold_function.  */
+  ff_genericize = 1 << 0,
+};
+
  /* Forward declarations.  */
  
  static tree cp_genericize_r (tree *, int *, void *);

  static tree cp_fold_r (tree *, int *, void *);
  static void cp_genericize_tree (tree*, bool);
-static tree cp_fold (tree);
+static tree cp_fold (tree, fold_flags);
  
  /* Genericize a TRY_BLOCK.  */
  
@@ -996,9 +1004,8 @@ struct cp_genericize_data

  struct cp_fold_data
  {
hash_set pset;
-  bool genericize; // called from cp_fold_function?
-
-  cp_fold_data (bool g): genericize (g) {}
+  fold_flags flags;
+  cp_fold_data (fold_flags flags): flags (flags) {}
  };
  
  static tree

@@ -1039,7 +1046,7 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void *data_)
break;
  }
  
-  *stmt_p = stmt = cp_fold (*stmt_p);

+  *stmt_p = stmt = cp_fold (*stmt_p, data->flags);
  
if (data->pset.add (stmt))

  {
@@ -1119,12 +1126,12 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void 
*data_)
 here rather than in cp_genericize to avoid problems with the invisible
 reference transition.  */
  case INIT_EXPR:
-  if (data->genericize)
+  if (data->flags & ff_genericize)
cp_genericize_init_expr (stmt_p);
break;
  
  case TARGET_EXPR:

-  if (data->genericize)
+  if (data->flags & ff_genericize)
cp_genericize_target_expr (stmt_p);
  
/* Folding might replace e.g. a COND_EXPR with a TARGET_EXPR; in

@@ -1157,7 +1164,7 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void *data_)
  void
  cp_fold_function (tree fndecl)
  {
-  cp_fold_data data (/*genericize*/true);
+  cp_fold_data data (ff_genericize);
cp_walk_tree (&DECL_SAVED_TREE (fndecl), cp_fold_r, &data, NULL);
  }
  
@@ -2375,7 +2382,7 @@ cp_fold_maybe_rvalue (tree x, bool rval)

  {
while (true)
  {
-  x = cp_fold (x);
+  x = cp_fold (x, ff_none);
if (rval)
x = mark_rvalue_use (x);
if (rval && DECL_P (x)
@@ -2434,7 +2441,7 @@ cp_fully_fold_init (tree x)
if (processing_template_decl)
  return x;
x = cp_fully_fold (x);
-  cp_fold_data data (/*genericize*/false);
+  cp_fold_data data (ff_none);
cp_walk_tree (&x, cp_fold_r, &data, NULL);
return x;
  }
@@ -2469,7 +2476,7 @@ clear_fold_cache (void)
  Function returns X or its folded variant.  */
  
  static tree

-cp_fold (tree x)
+cp_fold (tree x, fold_flags flags)
  {
tree op0, op1, op2, op3;
tree org_x = x, r = NULL_TREE;
@@ -2490,8 +2497,11 @@ cp_fold (tree x)
if (fold_cache == NULL)
  fold_cache = hash_map::create_ggc (101);
  
-  if (tree *cached = fold_cache->get (x))

-return *cached;
+  bool cache_p = (flags == ff_none);
+
+  if (cache_p)
+if (tree *cached = fold_cache->get (x))
+  return *cached;
  
uid_sensitive_constexpr_evaluation_checker c;
  
@@ -2526,7 +2536,7 @@ cp_fold (tree x)

 Don't create a new tree if op0 != TREE_OPERAND (x, 0), the
 folding of t

Re: [PATCH 1/2] c++: make manifestly_const_eval tri-state

[Jason Merrill via Gcc-patches]

On 1/27/23 17:02, Patrick Palka wrote:

This patch turns the manifestly_const_eval flag used by the constexpr
machinery into a tri-state enum so that we're able to express wanting
to fold __builtin_is_constant_evaluated to false via late speculative
constexpr evaluation.  Of all the entry points to constexpr evaluation
only maybe_constant_value is changed to take a tri-state value; the
others continue to take bool.  The subsequent patch will use this to fold
the builtin to false when called from cp_fold_function.

gcc/cp/ChangeLog:

* constexpr.cc (constexpr_call::manifestly_const_eval): Give
it type int instead of bool.
(constexpr_ctx::manifestly_const_eval): Give it type mce_value
instead of bool.
(cxx_eval_builtin_function_call): Adjust after making
manifestly_const_eval tri-state.
(cxx_eval_call_expression): Likewise.
(cxx_eval_binary_expression): Likewise.
(cxx_eval_conditional_expression): Likewise.
(cxx_eval_constant_expression): Likewise.
(cxx_eval_outermost_constant_expr): Likewise.
(cxx_constant_value): Likewise.
(cxx_constant_dtor): Likewise.
(maybe_constant_value): Give manifestly_const_eval parameter
type mce_value instead of bool and adjust accordingly.
(fold_non_dependent_expr_template): Adjust call
to cxx_eval_outermost_constant_expr.
(fold_non_dependent_expr): Likewise.
(maybe_constant_init_1): Likewise.
* constraint.cc (satisfy_atom): Adjust call to
maybe_constant_value.
* cp-tree.h (enum class mce_value): Define.
(maybe_constant_value): Adjust manifestly_const_eval parameter
type and default argument.
* decl.cc (compute_array_index_type_loc): Adjust call to
maybe_constant_value.
* pt.cc (convert_nontype_argument): Likewise.
---
  gcc/cp/constexpr.cc  | 61 
  gcc/cp/constraint.cc |  3 +--
  gcc/cp/cp-tree.h | 18 -
  gcc/cp/decl.cc   |  2 +-

`>   gcc/cp/pt.cc |  6 ++---

  5 files changed, 54 insertions(+), 36 deletions(-)

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index be99bec17e7..34662198903 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -1119,8 +1119,8 @@ struct GTY((for_user)) constexpr_call {
/* The hash of this call; we remember it here to avoid having to
   recalculate it when expanding the hash table.  */
hashval_t hash;
-  /* Whether __builtin_is_constant_evaluated() should evaluate to true.  */
-  bool manifestly_const_eval;
+  /* The raw value of constexpr_ctx::manifestly_const_eval.  */
+  int manifestly_const_eval;


Why not mce_value?


  };
  
  struct constexpr_call_hasher : ggc_ptr_hash

@@ -1248,7 +1248,7 @@ struct constexpr_ctx {
   trying harder to get a constant value.  */
bool strict;
/* Whether __builtin_is_constant_evaluated () should be true.  */
-  bool manifestly_const_eval;
+  mce_value manifestly_const_eval;
  };
  
  /* This internal flag controls whether we should avoid doing anything during

@@ -1463,7 +1463,7 @@ cxx_eval_builtin_function_call (const constexpr_ctx *ctx, 
tree t, tree fun,
/* If we aren't requiring a constant expression, defer __builtin_constant_p
   in a constexpr function until we have values for the parameters.  */
if (bi_const_p
-  && !ctx->manifestly_const_eval
+  && ctx->manifestly_const_eval == mce_unknown
&& current_function_decl
&& DECL_DECLARED_CONSTEXPR_P (current_function_decl))
  {
@@ -1479,12 +1479,13 @@ cxx_eval_builtin_function_call (const constexpr_ctx 
*ctx, tree t, tree fun,
if (fndecl_built_in_p (fun, CP_BUILT_IN_IS_CONSTANT_EVALUATED,
 BUILT_IN_FRONTEND))
  {
-  if (!ctx->manifestly_const_eval)
+  if (ctx->manifestly_const_eval == mce_unknown)
{
  *non_constant_p = true;
  return t;
}
-  return boolean_true_node;
+  return constant_boolean_node (ctx->manifestly_const_eval == mce_true,
+   boolean_type_node);
  }
  
if (fndecl_built_in_p (fun, CP_BUILT_IN_SOURCE_LOCATION, BUILT_IN_FRONTEND))

@@ -1591,7 +1592,7 @@ cxx_eval_builtin_function_call (const constexpr_ctx *ctx, 
tree t, tree fun,
  }
  
bool save_ffbcp = force_folding_builtin_constant_p;

-  force_folding_builtin_constant_p |= ctx->manifestly_const_eval;
+  force_folding_builtin_constant_p |= ctx->manifestly_const_eval != 
mce_unknown;
tree save_cur_fn = current_function_decl;
/* Return name of ctx->call->fundef->decl for __builtin_FUNCTION ().  */
if (fndecl_built_in_p (fun, BUILT_IN_FUNCTION)
@@ -2644,7 +2645,7 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree 
t,
location_t loc = cp_expr_loc_or_input_loc (t);
tree fun = get_function_named_in_call (t);
constexpr_call new_call
-= { NULL, NULL, NULL, 0, ctx->manifestly_cons

[PATCH 3/3] tree-optimization/108385 - Add op2_range to pointer_plus.

[Andrew MacLeod via Gcc-patches]

Implement op2_range for pointer_plus to determine the offset (operand 2) 
is zero or non-zero based on equality/inequality between the LHS and op1.


Fairly trivial fix for the PR, dependent on the first patch in the set 
as it uses an accurate relation_trio in GORI to determine if LHS == OP1.



There was one tweak to GORI in that we use to stop calculating when the 
LHS was varying.  THis PR also exposed a case where the LHS is varying, 
but a relation between the operands can still cause us to find a useful 
result...  ie


VARYING = VARYING + OFFSET when LHS and OP1 are equal can produce a 
non-zero OFFSET calculation.


Bootstraps on x86_64-pc-linux-gnu with no regressions. OK for trunk?

Andrew

From 0730d9a6b856f6887bfffc4ce45d4164563a476e Mon Sep 17 00:00:00 2001
From: Andrew MacLeod 
Date: Tue, 17 Jan 2023 11:39:47 -0500
Subject: [PATCH 3/3] Add op2_range to pointer_plus.

Implement op2_range for pointer_plus to determine the offset (operand 2) is
zero or non-zero based on equality/inequality between the LHS and op1.
Also allow GORI computations to continue if the LHS is VARYING and there
is also a relation.

	PR tree-optimization/108385
	gcc/
	* gimple-range-gori.cc (gori_compute::compute_operand_range):
	Allow VARYING computations to continue if there is a relation.
	* range-op.cc (pointer_plus_operator::op2_range): New.

	gcc/testsuite/
	* gcc.dg/pr108385.c: New.
---
 gcc/gimple-range-gori.cc| 13 +++
 gcc/range-op.cc | 23 +++
 gcc/testsuite/gcc.dg/pr108385.c | 39 +
 3 files changed, 71 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr108385.c

diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc
index 3dc4576ff13..beb1c0064b9 100644
--- a/gcc/gimple-range-gori.cc
+++ b/gcc/gimple-range-gori.cc
@@ -607,10 +607,6 @@ gori_compute::compute_operand_range (vrange &r, gimple *stmt,
 {
   value_relation vrel;
   value_relation *vrel_ptr = rel;
-  // If the lhs doesn't tell us anything, neither will unwinding further.
-  if (lhs.varying_p ())
-return false;
-
   // Empty ranges are viral as they are on an unexecutable path.
   if (lhs.undefined_p ())
 {
@@ -657,10 +653,19 @@ gori_compute::compute_operand_range (vrange &r, gimple *stmt,
   if (!op1_in_chain && !op2_in_chain)
 return false;
 
+  // If the lhs doesn't tell us anything and there are no relations, there
+  // is nothing to be learned.
+  if (lhs.varying_p () && !vrel_ptr)
+return false;
+
   bool res;
   // Process logicals as they have special handling.
   if (is_gimple_logical_p (stmt))
 {
+  // If the lhs doesn't tell us anything, neither will combining operands.
+  if (lhs.varying_p ())
+	return false;
+
   unsigned idx;
   if ((idx = tracer.header ("compute_operand ")))
 	{
diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index f7c1e84e0bd..136b709385c 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -4212,6 +4212,10 @@ public:
 		const wide_int &lh_ub,
 		const wide_int &rh_lb,
 		const wide_int &rh_ub) const;
+  virtual bool op2_range (irange &r, tree type,
+			  const irange &lhs,
+			  const irange &op1,
+			  relation_trio = TRIO_VARYING) const;
 } op_pointer_plus;
 
 void
@@ -4258,6 +4262,25 @@ pointer_plus_operator::wi_fold (irange &r, tree type,
r.set_varying (type);
 }
 
+bool
+pointer_plus_operator::op2_range (irange &r, tree type,
+  const irange &lhs ATTRIBUTE_UNUSED,
+  const irange &op1 ATTRIBUTE_UNUSED,
+  relation_trio trio) const
+{
+  relation_kind rel = trio.lhs_op1 ();
+  r.set_varying (type);
+
+  // If the LHS and OP1 are equal, the op2 must be zero.
+  if (rel == VREL_EQ)
+r.set_zero (type);
+  // If the LHS and OP1 are not equal, the offset must be non-zero.
+  else if (rel == VREL_NE)
+r.set_nonzero (type);
+  else
+return false;
+  return true;
+}
 
 class pointer_min_max_operator : public range_operator
 {
diff --git a/gcc/testsuite/gcc.dg/pr108385.c b/gcc/testsuite/gcc.dg/pr108385.c
new file mode 100644
index 000..13babf06d9a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr108385.c
@@ -0,0 +1,39 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-evrp" } */
+
+void bar(char *);
+
+/* Ensure that PTR1 = PTR2 + OFF properly picks up the zero and non-zero
+   properties if PTR1 and PTR2 are known equal or non-equal.  */
+
+void foo1 (char *p, char *pp, int off)
+{
+  char *q = p + off;
+  if (q != p)
+{
+  if (off == 0)
+	  bar (q);
+}
+  else
+{
+  if (off != 0)
+bar (p);
+}
+}
+
+void foo2 (char *p, char *pp, int off)
+{
+  char *q = p + off;
+  if (q == p)
+{
+  if (off != 0)
+bar (p);
+}
+  else
+{
+  if (off == 0)
+	  bar (q);
+}
+}
+
+/* { dg-final { scan-tree-dump-not "bar" "evrp" } } */
-- 
2.39.0

[PATCH] c++: excessive satisfaction in check_methods [PR108579]

[Patrick Palka via Gcc-patches]

In check_methods we're unnecessarily checking satisfaction for all
constructors and assignment operators, even those that don't look like
copy/move special members.  In the testcase below this manifests as an
unstable satisfaction error because the satisfaction result is first
determined to be false during check_methods (since A is incomplete
at this point) and later true after completion of A.

This patch fixes this simply by swapping the order of the
constraint_satisfied_p and copy_fn_p / move_fn_p tests.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?  This doesn't fix the regression completely, since
we get a similar unstable satisfaction error if one of the constrained
members is actually a copy/move special member.  I suppose we need to
rearrange things in finish_struct_1 so that check_methods gets called in
a complete class context?

PR c++/108579

gcc/cp/ChangeLog:

* class.cc (check_methods): Test constraints_satisfied_p after
testing copy_fn_p / move_fn_p instead of beforehand.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-pr108579.C: New test.
---
 gcc/cp/class.cc| 16 
 gcc/testsuite/g++.dg/cpp2a/concepts-pr108579.C | 14 ++
 2 files changed, 22 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-pr108579.C

diff --git a/gcc/cp/class.cc b/gcc/cp/class.cc
index 351de6c5419..d3ce8532d56 100644
--- a/gcc/cp/class.cc
+++ b/gcc/cp/class.cc
@@ -4822,11 +4822,11 @@ check_methods (tree t)
/* Might be trivial.  */;
   else if (TREE_CODE (fn) == TEMPLATE_DECL)
/* Templates are never special members.  */;
-  else if (!constraints_satisfied_p (fn))
-   /* Not eligible.  */;
-  else if (copy_fn_p (fn))
+  else if (copy_fn_p (fn)
+  && constraints_satisfied_p (fn))
TYPE_HAS_COMPLEX_COPY_CTOR (t) = true;
-  else if (move_fn_p (fn))
+  else if (move_fn_p (fn)
+  && constraints_satisfied_p (fn))
TYPE_HAS_COMPLEX_MOVE_CTOR (t) = true;
 }
 
@@ -4836,11 +4836,11 @@ check_methods (tree t)
/* Might be trivial.  */;
   else if (TREE_CODE (fn) == TEMPLATE_DECL)
/* Templates are never special members.  */;
-  else if (!constraints_satisfied_p (fn))
-   /* Not eligible.  */;
-  else if (copy_fn_p (fn))
+  else if (copy_fn_p (fn)
+  && constraints_satisfied_p (fn))
TYPE_HAS_COMPLEX_COPY_ASSIGN (t) = true;
-  else if (move_fn_p (fn))
+  else if (move_fn_p (fn)
+  && constraints_satisfied_p (fn))
TYPE_HAS_COMPLEX_MOVE_ASSIGN (t) = true;
 }
 }
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-pr108579.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-pr108579.C
new file mode 100644
index 000..bc7d709f889
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-pr108579.C
@@ -0,0 +1,14 @@
+// PR c++/108579
+// { dg-do compile { target c++20 } }
+
+template
+struct A {
+  A(double, char);
+  A(int) requires requires { A(0.0, 'c'); };
+  A& operator=(int) requires requires { A(1.0, 'd'); };
+};
+
+int main() {
+  A x(3);
+  x = 5;
+}
-- 
2.39.1.367.g5cc9858f1b

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

[Jose E. Marchesi via Gcc-patches]

> On Thu, Dec 8, 2022 at 2:56 AM Jose E. Marchesi via Gcc-patches
>  wrote:
>>
>> The expand_expr_divmod function in expr.cc attempts to optimize cases
>> where both arguments of a division/modulus are known to be positive
>> when interpreted as signed.  In these cases, both signed division and
>> unsigned division will raise the same value, and therefore the
>> cheapest option can be used.
>
> I suspect this issue is also the same as PR 48783 .

Yeah I kinda dropped the ball here.

Will look into Jeff's suggestions on how to fix this without exhausting
the CALL_INSN bits.

> Thanks,
> Andrew
>
>>
>> In order to determine what is the cheaper option in the current
>> target, expand_expr_divmod actually expands both a signed divmod and
>> an unsigned divmod using local "sequences":
>>
>>   start_sequence ();
>>   ...
>>   expand_divmod (... signed ...);
>>   ...
>>   end_sequence ();
>>
>>   start_sequence ();
>>   ...
>>   expand_divmod (... unsigned ...);
>>   ...
>>   end_sequence ();
>>
>> And then compares the cost of each generated sequence, choosing the
>> best one.  Finally, it emits the selected expanded sequence and
>> returns the rtx with the result.
>>
>> This approach has a caveat.  Some targets do not provide instructions
>> for division/modulus instructions.  In the case of BPF, it provides
>> unsigned division/modulus, but not signed division/modulus.
>>
>> In these cases, the expand_divmod tries can contain calls to funcalls.
>> For example, in BPF:
>>
>>   start_sequence ();
>>   ...
>>   expand_divmod (... signed ...); -> This generates funcall to __divdi3
>>   ...
>>   end_sequence ();
>>
>>   start_sequence ();
>>   ...
>>   expand_divmod (... unsigned ...); -> This generates direct `div' insn.
>>   ...
>>   end_sequence ();
>>
>> The problem is that when a funcall is expanded, an accompanying global
>> symbol definition is written in the output stream:
>>
>>   .global __divdi3
>>
>> And this symbol definition remains in the compiled assembly file, even
>> if the sequence using the direct `div' instruction above is used.
>>
>> This is particularly bad in BPF, because the kernel bpf loader chokes
>> on the spurious symbol __divdi3 and makes the resulting BPF object
>> unloadable (note that BPF objects are not linked before processed by
>> the kernel.)
>>
>> In order to fix this, this patch modifies expand_expr_divmod in the
>> following way:
>>
>> - When trying each sequence (signed, unsigned) the expand_divmod calls
>>   are told to _not_ use libcalls if everything else fails.  This is
>>   done by passing OPTAB_WIDEN as the `methods' argument.  (Before it
>>   was using the default value OPTAB_LIB_WIDEN.)
>>
>> - If any of the tried expanded sequences contain a funcall, then the
>>   optimization is not attempted.
>>
>> A couple of BPF tests are also added to make sure this doesn't break
>> at any point in the future.
>>
>> Tested in bpf-unknown-none and x86_64-linux-gnu.
>> Regtested in x86_64-linux-gnu.  No regressions.
>>
>> gcc/ChangeLog
>>
>> * expr.cc (expand_expr_divmod): Avoid side-effects of trying
>> sequences involving funcalls in optimization.
>>
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.target/bpf/divmod-funcall-1.c: New test.
>> * gcc.target/bpf/divmod-funcall-2.c: Likewise.
>> ---
>>  gcc/expr.cc   | 44 +++
>>  .../gcc.target/bpf/divmod-funcall-1.c |  8 
>>  .../gcc.target/bpf/divmod-funcall-2.c |  8 
>>  3 files changed, 41 insertions(+), 19 deletions(-)
>>  create mode 100644 gcc/testsuite/gcc.target/bpf/divmod-funcall-1.c
>>  create mode 100644 gcc/testsuite/gcc.target/bpf/divmod-funcall-2.c
>>
>> diff --git a/gcc/expr.cc b/gcc/expr.cc
>> index d9407432ea5..4d4be5d7bda 100644
>> --- a/gcc/expr.cc
>> +++ b/gcc/expr.cc
>> @@ -9168,32 +9168,38 @@ expand_expr_divmod (tree_code code, machine_mode 
>> mode, tree treeop0,
>>do_pending_stack_adjust ();
>>start_sequence ();
>>rtx uns_ret = expand_divmod (mod_p, code, mode, treeop0, treeop1,
>> -  op0, op1, target, 1);
>> +  op0, op1, target, 1, OPTAB_WIDEN);
>>rtx_insn *uns_insns = get_insns ();
>>end_sequence ();
>>start_sequence ();
>>rtx sgn_ret = expand_divmod (mod_p, code, mode, treeop0, treeop1,
>> -  op0, op1, target, 0);
>> +  op0, op1, target, 0, OPTAB_WIDEN);
>>rtx_insn *sgn_insns = get_insns ();
>>end_sequence ();
>> -  unsigned uns_cost = seq_cost (uns_insns, speed_p);
>> -  unsigned sgn_cost = seq_cost (sgn_insns, speed_p);
>>
>> -  /* If costs are the same then use as tie breaker the other other
>> -factor.  */
>> -  if (uns_cost == sgn_cost)
>> -   {
>> - uns_cost = seq_cost (uns_insns, !speed_p);
>> - sgn_cost = seq_cost (sgn_insns, !speed_p);
>> -   }
>> -
>> - 

Re: [PATCH] expr.cc: avoid unexpected side effects in expand_expr_divmod optimization

[Andrew Pinski via Gcc-patches]

On Thu, Dec 8, 2022 at 2:56 AM Jose E. Marchesi via Gcc-patches
 wrote:
>
> The expand_expr_divmod function in expr.cc attempts to optimize cases
> where both arguments of a division/modulus are known to be positive
> when interpreted as signed.  In these cases, both signed division and
> unsigned division will raise the same value, and therefore the
> cheapest option can be used.

I suspect this issue is also the same as PR 48783 .

Thanks,
Andrew

>
> In order to determine what is the cheaper option in the current
> target, expand_expr_divmod actually expands both a signed divmod and
> an unsigned divmod using local "sequences":
>
>   start_sequence ();
>   ...
>   expand_divmod (... signed ...);
>   ...
>   end_sequence ();
>
>   start_sequence ();
>   ...
>   expand_divmod (... unsigned ...);
>   ...
>   end_sequence ();
>
> And then compares the cost of each generated sequence, choosing the
> best one.  Finally, it emits the selected expanded sequence and
> returns the rtx with the result.
>
> This approach has a caveat.  Some targets do not provide instructions
> for division/modulus instructions.  In the case of BPF, it provides
> unsigned division/modulus, but not signed division/modulus.
>
> In these cases, the expand_divmod tries can contain calls to funcalls.
> For example, in BPF:
>
>   start_sequence ();
>   ...
>   expand_divmod (... signed ...); -> This generates funcall to __divdi3
>   ...
>   end_sequence ();
>
>   start_sequence ();
>   ...
>   expand_divmod (... unsigned ...); -> This generates direct `div' insn.
>   ...
>   end_sequence ();
>
> The problem is that when a funcall is expanded, an accompanying global
> symbol definition is written in the output stream:
>
>   .global __divdi3
>
> And this symbol definition remains in the compiled assembly file, even
> if the sequence using the direct `div' instruction above is used.
>
> This is particularly bad in BPF, because the kernel bpf loader chokes
> on the spurious symbol __divdi3 and makes the resulting BPF object
> unloadable (note that BPF objects are not linked before processed by
> the kernel.)
>
> In order to fix this, this patch modifies expand_expr_divmod in the
> following way:
>
> - When trying each sequence (signed, unsigned) the expand_divmod calls
>   are told to _not_ use libcalls if everything else fails.  This is
>   done by passing OPTAB_WIDEN as the `methods' argument.  (Before it
>   was using the default value OPTAB_LIB_WIDEN.)
>
> - If any of the tried expanded sequences contain a funcall, then the
>   optimization is not attempted.
>
> A couple of BPF tests are also added to make sure this doesn't break
> at any point in the future.
>
> Tested in bpf-unknown-none and x86_64-linux-gnu.
> Regtested in x86_64-linux-gnu.  No regressions.
>
> gcc/ChangeLog
>
> * expr.cc (expand_expr_divmod): Avoid side-effects of trying
> sequences involving funcalls in optimization.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/bpf/divmod-funcall-1.c: New test.
> * gcc.target/bpf/divmod-funcall-2.c: Likewise.
> ---
>  gcc/expr.cc   | 44 +++
>  .../gcc.target/bpf/divmod-funcall-1.c |  8 
>  .../gcc.target/bpf/divmod-funcall-2.c |  8 
>  3 files changed, 41 insertions(+), 19 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/bpf/divmod-funcall-1.c
>  create mode 100644 gcc/testsuite/gcc.target/bpf/divmod-funcall-2.c
>
> diff --git a/gcc/expr.cc b/gcc/expr.cc
> index d9407432ea5..4d4be5d7bda 100644
> --- a/gcc/expr.cc
> +++ b/gcc/expr.cc
> @@ -9168,32 +9168,38 @@ expand_expr_divmod (tree_code code, machine_mode 
> mode, tree treeop0,
>do_pending_stack_adjust ();
>start_sequence ();
>rtx uns_ret = expand_divmod (mod_p, code, mode, treeop0, treeop1,
> -  op0, op1, target, 1);
> +  op0, op1, target, 1, OPTAB_WIDEN);
>rtx_insn *uns_insns = get_insns ();
>end_sequence ();
>start_sequence ();
>rtx sgn_ret = expand_divmod (mod_p, code, mode, treeop0, treeop1,
> -  op0, op1, target, 0);
> +  op0, op1, target, 0, OPTAB_WIDEN);
>rtx_insn *sgn_insns = get_insns ();
>end_sequence ();
> -  unsigned uns_cost = seq_cost (uns_insns, speed_p);
> -  unsigned sgn_cost = seq_cost (sgn_insns, speed_p);
>
> -  /* If costs are the same then use as tie breaker the other other
> -factor.  */
> -  if (uns_cost == sgn_cost)
> -   {
> - uns_cost = seq_cost (uns_insns, !speed_p);
> - sgn_cost = seq_cost (sgn_insns, !speed_p);
> -   }
> -
> -  if (uns_cost < sgn_cost || (uns_cost == sgn_cost && unsignedp))
> -   {
> - emit_insn (uns_insns);
> - return uns_ret;
> -   }
> -  emit_insn (sgn_insns);
> -  return sgn_ret;
> +  /* Do not try to optimize if any of the sequences 

Re: [COMMITTED] testsuite: Restore TORTURE_OPTIONS in gm2/warnings/returntype/fail/warnings-returntype-fail.exp

[Gaius Mulley via Gcc-patches]

Rainer Orth  writes:

> Between 20230126 and 20230127, 1100+ gm2 tests started to FAIL for the
> non-default multilib, e.g.
>
> FAIL: gm2/calling-c/datatypes/unbounded/run/pass/m.mod compilation, 
> {additional_flags= -O0 -g -Werror=return-type } timeout=10
> UNRESOLVED: gm2/calling-c/datatypes/unbounded/run/pass/m.mod execution, 
> {additional_flags= -O0 -g -Werror=return-type } timeout=10
> FAIL: gm2/case/pass/testcase1.mod,  -O0 -g -Werror=return-type  
> [...]
> cc1gm2: warning: '-Werror=' argument '-Werror=return-type' is not valid for 
> Modula-2
>
> I'm seeing this on all of Solaris/x86, Solaris/SPARC, and Linux/x86_64.
>
> I could trace this to
> gm2/warnings/returntype/fail/warnings-returntype-fail.exp not properly
> restoring TORTURE_OPTIONS.
>
> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11.  Installed on
> trunk.
>
>   Rainer

apologies and many thanks for detecting and fixing this bug

regards,
Gaius

Re: [PATCH v2] c++: fix ICE with -Wduplicated-cond [PR107593]

[Jason Merrill via Gcc-patches]

On 1/30/23 11:00, Marek Polacek wrote:

On Fri, Jan 27, 2023 at 06:17:00PM -0500, Patrick Palka wrote:

On Fri, 27 Jan 2023, Marek Polacek wrote:


On Fri, Jan 27, 2023 at 05:15:00PM -0500, Patrick Palka wrote:

On Thu, 26 Jan 2023, Marek Polacek via Gcc-patches wrote:


Here we crash because a CAST_EXPR, representing T(), doesn't have
its operand, and operand_equal_p's STRIP_ANY_LOCATION_WRAPPER doesn't
expect that.  (o_e_p is called from warn_duplicated_cond_add_or_warn.)

In the past we've adjusted o_e_p to better cope with template codes,
but in this case I think we just want to avoid attempting to warn
about inst-dependent expressions; I don't think I've ever envisioned
-Wduplicated-cond to warn about them.

The ICE started with r12-6022, two-stage name lookup for overloaded
operators, which gave dependent operators a TREE_TYPE (in particular,
DEPENDENT_OPERATOR_TYPE), so we no longer bail out here in o_e_p:

   /* Similar, if either does not have a type (like a template id),
  they aren't equal.  */
   if (!TREE_TYPE (arg0) || !TREE_TYPE (arg1))
 return false;

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

PR c++/107593

gcc/cp/ChangeLog:

* parser.cc (cp_parser_selection_statement): Don't do
-Wduplicated-cond when the condition is dependent.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wduplicated-cond3.C: New test.
---
  gcc/cp/parser.cc  |  3 +-
  gcc/testsuite/g++.dg/warn/Wduplicated-cond3.C | 38 +++
  2 files changed, 40 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/warn/Wduplicated-cond3.C

diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 4cdc1cd472f..3df85d49e16 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -13209,7 +13209,8 @@ cp_parser_selection_statement (cp_parser* parser, bool 
*if_p,
/* Add the condition.  */
condition = finish_if_stmt_cond (condition, statement);
  
-	if (warn_duplicated_cond)

+   if (warn_duplicated_cond
+   && !instantiation_dependent_expression_p (condition))
  warn_duplicated_cond_add_or_warn (token->location, condition,
&chain);


I noticed warn_duplicated_cond_add_or_warn already has logic to handle
TREE_SIDE_EFFECTS conditions by invaliding the entire chain.  I wonder
if we'd want to do the same for instantiation-dep conditions?


warn_duplicated_cond_add_or_warn lives in c-family/c-warn.cc so I can't
use instantiation_dependent_expression_p there.  Sure, I could write a
C++ wrapper but with my patch we just won't add CONDITION to the chain
which I thought would work just as well.


Or maybe define instantiation_dependent_expression_p in the C front-end 
to just return false?



Ah that's unfortunate :( ISTM desirable to conservatively assume an
inst-dep cond has side effects though (possibly directly from
cp_parser_selection_statement), to avoid false positives as in:

   int n;

   template bool g() { n = 42; }

   template
   void f() {
 if (n)
   ;
 else if (g())
   ;
 else if (n)
   ;
   }


You're right, we shouldn't warn there.  So I've just added a new param
with a default argument.  A new PR was just opened for the same problem
so I've added another test.

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

-- >8 --
Here we crash because a CAST_EXPR, representing T(), doesn't have
its operand, and operand_equal_p's STRIP_ANY_LOCATION_WRAPPER doesn't
expect that.  (o_e_p is called from warn_duplicated_cond_add_or_warn.)

In the past we've adjusted o_e_p to better cope with template codes,
but in this case I think we just want to avoid attempting to warn
about inst-dependent expressions; I don't think I've ever envisioned
-Wduplicated-cond to warn about them.  Also destroy the chain when
an inst-dependent expression is encountered to not warn in
Wduplicated-cond4.C.

The ICE started with r12-6022, two-stage name lookup for overloaded
operators, which gave dependent operators a TREE_TYPE (in particular,
DEPENDENT_OPERATOR_TYPE), so we no longer bail out here in o_e_p:

   /* Similar, if either does not have a type (like a template id),
  they aren't equal.  */
   if (!TREE_TYPE (arg0) || !TREE_TYPE (arg1))
 return false;

PR c++/107593
PR c++/108597

gcc/c-family/ChangeLog:

* c-common.h (warn_duplicated_cond_add_or_warn): New parameter.
* c-warn.cc (warn_duplicated_cond_add_or_warn): Add new parameter.
Use it.

gcc/cp/ChangeLog:

* parser.cc (cp_parser_selection_statement): Pass the result of
instantiation_dependent_expression_p down to
warn_duplicated_cond_add_or_warn.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wduplicated-cond3.C: New test.
* g++.dg/warn/Wduplicated-cond4.C: New test.
* g++.dg/warn/Wduplicated-cond5.C: New test.
---
  gcc/c-family/c-common.h   |  3 +

Re: [PATCH] RISC-V: Add indexed loads/stores constraints testcases

[Kito Cheng via Gcc-patches]

committed, thanks!


On Sun, Jan 29, 2023 at 11:37 PM  wrote:
>
> From: Ju-Zhe Zhong 
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/base/vlxei-vsxei-constraint-1.c: New test.
>
> ---
>  .../riscv/rvv/base/vlxei-vsxei-constraint-1.c | 121 ++
>  1 file changed, 121 insertions(+)
>  create mode 100644 
> gcc/testsuite/gcc.target/riscv/rvv/base/vlxei-vsxei-constraint-1.c
>
> diff --git 
> a/gcc/testsuite/gcc.target/riscv/rvv/base/vlxei-vsxei-constraint-1.c 
> b/gcc/testsuite/gcc.target/riscv/rvv/base/vlxei-vsxei-constraint-1.c
> new file mode 100644
> index 000..56e599391fd
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/base/vlxei-vsxei-constraint-1.c
> @@ -0,0 +1,121 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv32gcv -mabi=ilp32d -O3 -fno-schedule-insns 
> -fno-schedule-insns2" } */
> +/* { dg-final { check-function-bodies "**" "" } } */
> +
> +#include "riscv_vector.h"
> +
> +/*
> +** f1:
> +** vsetivli\s+zero,4,e32,mf2,tu,m[au]
> +** vlse32\.v\s+v[0-9]+,\s*0\([a-x0-9]+\),\s*zero
> +** vlse8\.v\s+v[0-9]+,\s*0\([a-x0-9]+\),\s*zero
> +** vluxei8\.v\s+v[0-9]+,\s*\([a-x0-9]+\),\s*v[0-9]+
> +** vsoxei8\.v\s+v[0-9]+,\s*\([a-x0-9]+\),\s*v[0-9]+
> +** ret
> +*/
> +void f1 (void * in, void * in2, void *out)
> +{
> +  vfloat32mf2_t v = __riscv_vlse32_v_f32mf2 (in, 0, 4);
> +  vuint8mf8_t index = __riscv_vlse8_v_u8mf8 (in2, 0, 4);
> +  vfloat32mf2_t v2 = __riscv_vluxei8_v_f32mf2_tu (v, in, index, 4);
> +  __riscv_vsoxei8_v_f32mf2 (out, index, v2, 4);
> +}
> +
> +/*
> +** f2:
> +** vsetvli\s+[a-x0-9]+,\s*zero,\s*e8,\s*mf8,\s*t[au],\s*m[au]
> +** vlm\.v\s+v[0-9]+,\s*0\([a-x0-9]+\)
> +** vsetivli\s+zero,4,e32,mf2,\s*t[au],\s*m[au]
> +** vlse8\.v\s+v[0-9]+,\s*0\([a-x0-9]+\),\s*zero
> +** vluxei8\.v\s+v[0-9]+,\s*\([a-x0-9]+\),\s*v[0-9]+,v0.t
> +** vsoxei8\.v\s+v[0-9]+,\s*\([a-x0-9]+\),\s*v[0-9]+
> +** ret
> +*/
> +void f2 (void * in, void * in2, void *out)
> +{
> +  vbool64_t mask = *(vbool64_t*)in;
> +  asm volatile ("":::"memory");
> +  vfloat32mf2_t v = __riscv_vlse32_v_f32mf2 (in, 0, 4);
> +  vuint8mf8_t index = __riscv_vlse8_v_u8mf8 (in2, 0, 4);
> +  vfloat32mf2_t v2 = __riscv_vluxei8_v_f32mf2_m (mask, in, index, 4);
> +  __riscv_vsoxei8_v_f32mf2 (out, index, v2, 4);
> +}
> +
> +/*
> +** f3:
> +** vsetvli\s+[a-x0-9]+,\s*zero,\s*e8,\s*mf8,\s*t[au],\s*m[au]
> +** vlm\.v\s+v[0-9]+,\s*0\([a-x0-9]+\)
> +** vsetivli\s+zero,\s*4,\s*e32,\s*mf2,\s*tu,\s*mu
> +** vlse32\.v\s+v[0-9]+,\s*0\([a-x0-9]+\),\s*zero
> +** vlse8\.v\s+v[0-9]+,\s*0\([a-x0-9]+\),\s*zero
> +** vluxei8\.v\s+v[0-9]+,\s*\([a-x0-9]+\),\s*v[0-9]+,v0.t
> +** vsoxei8\.v\s+v[0-9]+,\s*\([a-x0-9]+\),\s*v[0-9]+
> +** ret
> +*/
> +void f3 (void * in, void * in2, void *out)
> +{
> +  vbool64_t mask = *(vbool64_t*)in;
> +  asm volatile ("":::"memory");
> +  vfloat32mf2_t v = __riscv_vlse32_v_f32mf2 (in, 0, 4);
> +  vuint8mf8_t index = __riscv_vlse8_v_u8mf8 (in2, 0, 4);
> +  vfloat32mf2_t v2 = __riscv_vluxei8_v_f32mf2_tumu (mask, v, in, index, 4);
> +  __riscv_vsoxei8_v_f32mf2 (out, index, v2, 4);
> +}
> +
> +/*
> +** f4:
> +** vsetivli\s+zero,4,e8,mf8,tu,\s*m[au]
> +** vlse8\.v\s+v[0-9]+,\s*0\([a-x0-9]+\),zero
> +** vluxei8\.v\s+v[0-9]+,\s*\([a-x0-9]+\),\s*v[0-9]+
> +** vluxei8\.v\s+v[0-9]+,\s*\([a-x0-9]+\),\s*v[0-9]+
> +** vsoxei8\.v\s+v[0-9]+,\s*\([a-x0-9]+\),\s*v[0-9]+
> +** ret
> +*/
> +void f4 (void * in, void * in2, void *out)
> +{
> +  vuint8mf8_t index = __riscv_vlse8_v_u8mf8 (in2, 0, 4);
> +  vint8mf8_t v = __riscv_vluxei8_v_i8mf8 (in, index, 4);
> +  vint8mf8_t v2 = __riscv_vluxei8_v_i8mf8_tu (v, in, index, 4);
> +  __riscv_vsoxei8_v_i8mf8 (out, index, v2, 4);
> +}
> +
> +/*
> +** f5:
> +** vsetvli\s+[a-x0-9]+,\s*zero,\s*e8,\s*mf8,\s*t[au],\s*m[au]
> +** vlm\.v\s+v[0-9]+,\s*0\([a-x0-9]+\)
> +** vsetivli\s+zero,4,e8,mf8,t[au],m[au]
> +** vlse8\.v\s+v[0-9]+,\s*0\([a-x0-9]+\),zero
> +** vluxei8\.v\s+v[0-9]+,\s*\([a-x0-9]+\),\s*v[0-9]+,v0.t
> +** vsoxei8\.v\s+v[0-9]+,\s*\([a-x0-9]+\),\s*v[0-9]+
> +** ret
> +*/
> +void f5 (void * in, void * in2, void *out)
> +{
> +  vbool64_t mask = *(vbool64_t*)in;
> +  asm volatile ("":::"memory");
> +  vuint8mf8_t index = __riscv_vlse8_v_u8mf8 (in2, 0, 4);
> +  vint8mf8_t v = __riscv_vluxei8_v_i8mf8 (in, index, 4);
> +  vint8mf8_t v2 = __riscv_vluxei8_v_i8mf8_m (mask, in, index, 4);
> +  __riscv_vsoxei8_v_i8mf8 (out, index, v2, 4);
> +}
> +
> +/*
> +** f6:
> +** vsetvli\s+[a-x0-9]+,\s*zero,\s*e8,\s*mf8,\s*t[au],\s*m[au]
> +** vlm\.v\s+v[0-9]+,\s*0\([a-x0-9]+\)
> +** vsetivli\s+zero,4,e8,mf8,tu,mu
> +** vlse8\.v\s+v[0-9]+,\s*0\([a-x0-9]+\),zero
> +** vluxei8\.v\s+v[0-9]+,\s*\([a-x0-9]+\),\s*v[0-9]+
> +** vluxei8\.v\s+v[0-9]+,\s*\([a-x0-9]+\),\s*v[0-9]+,v0.t
> +** vsoxei8\.v\s+v[0-9]+,\s*\([a-x0-9]+\),\s*v[0-9]+
> +** ret
> +*/
> +void f6 (void * in, void * in2, void *out)
> +{
> +  vbool64_t mask = *

Re: [PATCH] RISC-V: Add vsoxei32 && vsoxei64 C++ API intrinsic testcase

[Kito Cheng via Gcc-patches]

committed, thanks!

On Mon, Jan 30, 2023 at 7:15 AM  wrote:
>
> From: Ju-Zhe Zhong 
>
> gcc/testsuite/ChangeLog:
>
> * g++.target/riscv/rvv/base/vsoxei32-1.C: New test.
> * g++.target/riscv/rvv/base/vsoxei32-2.C: New test.
> * g++.target/riscv/rvv/base/vsoxei32-3.C: New test.
> * g++.target/riscv/rvv/base/vsoxei64-1.C: New test.
> * g++.target/riscv/rvv/base/vsoxei64-2.C: New test.
> * g++.target/riscv/rvv/base/vsoxei64-3.C: New test.
>
> ---
>  .../g++.target/riscv/rvv/base/vsoxei32-1.C| 608 ++
>  .../g++.target/riscv/rvv/base/vsoxei32-2.C| 608 ++
>  .../g++.target/riscv/rvv/base/vsoxei32-3.C| 608 ++
>  .../g++.target/riscv/rvv/base/vsoxei64-1.C| 518 +++
>  .../g++.target/riscv/rvv/base/vsoxei64-2.C| 518 +++
>  .../g++.target/riscv/rvv/base/vsoxei64-3.C| 518 +++
>  6 files changed, 3378 insertions(+)
>  create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vsoxei32-1.C
>  create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vsoxei32-2.C
>  create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vsoxei32-3.C
>  create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vsoxei64-1.C
>  create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vsoxei64-2.C
>  create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/vsoxei64-3.C
>
> diff --git a/gcc/testsuite/g++.target/riscv/rvv/base/vsoxei32-1.C 
> b/gcc/testsuite/g++.target/riscv/rvv/base/vsoxei32-1.C
> new file mode 100644
> index 000..3f39f889d1f
> --- /dev/null
> +++ b/gcc/testsuite/g++.target/riscv/rvv/base/vsoxei32-1.C
> @@ -0,0 +1,608 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv64gcv -mabi=lp64d -O3 -fno-schedule-insns 
> -fno-schedule-insns2" } */
> +
> +#include "riscv_vector.h"
> +
> +void test___riscv_vsoxei32(int8_t* base,vuint32mf2_t bindex,vint8mf8_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(int8_t* base,vuint32m1_t bindex,vint8mf4_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(int8_t* base,vuint32m2_t bindex,vint8mf2_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(int8_t* base,vuint32m4_t bindex,vint8m1_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(int8_t* base,vuint32m8_t bindex,vint8m2_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(int16_t* base,vuint32mf2_t bindex,vint16mf4_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(int16_t* base,vuint32m1_t bindex,vint16mf2_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(int16_t* base,vuint32m2_t bindex,vint16m1_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(int16_t* base,vuint32m4_t bindex,vint16m2_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(int16_t* base,vuint32m8_t bindex,vint16m4_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(int32_t* base,vuint32mf2_t bindex,vint32mf2_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(int32_t* base,vuint32m1_t bindex,vint32m1_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(int32_t* base,vuint32m2_t bindex,vint32m2_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(int32_t* base,vuint32m4_t bindex,vint32m4_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(int32_t* base,vuint32m8_t bindex,vint32m8_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(int64_t* base,vuint32mf2_t bindex,vint64m1_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(int64_t* base,vuint32m1_t bindex,vint64m2_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(int64_t* base,vuint32m2_t bindex,vint64m4_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(int64_t* base,vuint32m4_t bindex,vint64m8_t 
> value,size_t vl)
> +{
> +__riscv_vsoxei32(base,bindex,value,vl);
> +}
> +
> +
> +void test___riscv_vsoxei32(uint8_t* base,vuint32mf2_t bindex,vuint8mf8_t 
> value,size_t vl)
> +{
> +__ris

Re: [PATCH] RISC-V: Add indexed loads/stores C/C++ intrinsic support

[Kito Cheng via Gcc-patches]

committed, thanks!

On Sun, Jan 29, 2023 at 11:33 PM  wrote:
>
> From: Ju-Zhe Zhong 
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-protos.h (get_vector_mode): New function.
> * config/riscv/riscv-v.cc (get_vector_mode): Ditto.
> * config/riscv/riscv-vector-builtins-bases.cc (enum lst_type): New 
> enum.
> (class loadstore): Adjust for indexed loads/stores support.
> (BASE): Ditto.
> * config/riscv/riscv-vector-builtins-bases.h: New function declare.
> * config/riscv/riscv-vector-builtins-functions.def (vluxei8): Ditto.
> (vluxei16): Ditto.
> (vluxei32): Ditto.
> (vluxei64): Ditto.
> (vloxei8): Ditto.
> (vloxei16): Ditto.
> (vloxei32): Ditto.
> (vloxei64): Ditto.
> (vsuxei8): Ditto.
> (vsuxei16): Ditto.
> (vsuxei32): Ditto.
> (vsuxei64): Ditto.
> (vsoxei8): Ditto.
> (vsoxei16): Ditto.
> (vsoxei32): Ditto.
> (vsoxei64): Ditto.
> * config/riscv/riscv-vector-builtins-shapes.cc (struct 
> indexed_loadstore_def): New class.
> (SHAPE): Ditto.
> * config/riscv/riscv-vector-builtins-shapes.h: Ditto.
> * config/riscv/riscv-vector-builtins.cc (required_extensions_p): 
> Adjust for indexed loads/stores support.
> (check_required_extensions): Ditto.
> (rvv_arg_type_info::get_base_vector_type): New function.
> (rvv_arg_type_info::get_tree_type): Ditto.
> (function_builder::add_unique_function): Adjust for indexed 
> loads/stores support.
> (function_expander::use_exact_insn): New function.
> * config/riscv/riscv-vector-builtins.h (enum rvv_base_type): Adjust 
> for indexed loads/stores support.
> (struct rvv_arg_type_info): Ditto.
> (function_expander::index_mode): New function.
> (function_base::apply_tail_policy_p): Ditto.
> (function_base::apply_mask_policy_p): Ditto.
> * config/riscv/vector-iterators.md (unspec): New unspec.
> * config/riscv/vector.md (unspec): Ditto.
> (@pred_indexed_load): New 
> pattern.
> (@pred_indexed_store): Ditto.
> (@pred_indexed_load): Ditto.
> (@pred_indexed_store): Ditto.
> (@pred_indexed_load): Ditto.
> (@pred_indexed_store): Ditto.
> (@pred_indexed_load): Ditto.
> (@pred_indexed_store): Ditto.
> (@pred_indexed_load): Ditto.
> (@pred_indexed_store): Ditto.
> (@pred_indexed_load): Ditto.
> (@pred_indexed_store): Ditto.
> (@pred_indexed_load): Ditto.
> (@pred_indexed_store): Ditto.
>
> ---
>  gcc/config/riscv/riscv-protos.h   |   1 +
>  gcc/config/riscv/riscv-v.cc   |  22 ++
>  .../riscv/riscv-vector-builtins-bases.cc  |  92 +-
>  .../riscv/riscv-vector-builtins-bases.h   |  16 +
>  .../riscv/riscv-vector-builtins-functions.def |  16 +
>  .../riscv/riscv-vector-builtins-shapes.cc |  49 +++
>  .../riscv/riscv-vector-builtins-shapes.h  |   1 +
>  gcc/config/riscv/riscv-vector-builtins.cc | 249 +-
>  gcc/config/riscv/riscv-vector-builtins.h  |  36 ++
>  gcc/config/riscv/vector-iterators.md  |  87 +
>  gcc/config/riscv/vector.md| 309 +-
>  11 files changed, 845 insertions(+), 33 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
> index 1facad74b3c..ceae4007fd1 100644
> --- a/gcc/config/riscv/riscv-protos.h
> +++ b/gcc/config/riscv/riscv-protos.h
> @@ -172,6 +172,7 @@ enum mask_policy
>  enum tail_policy get_prefer_tail_policy ();
>  enum mask_policy get_prefer_mask_policy ();
>  rtx get_avl_type_rtx (enum avl_type);
> +opt_machine_mode get_vector_mode (scalar_mode, poly_uint64);
>  }
>
>  /* We classify builtin types into two classes:
> diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
> index 47f2cef459b..992b3437926 100644
> --- a/gcc/config/riscv/riscv-v.cc
> +++ b/gcc/config/riscv/riscv-v.cc
> @@ -349,4 +349,26 @@ get_avl_type_rtx (enum avl_type type)
>return gen_int_mode (type, Pmode);
>  }
>
> +/* Return the RVV vector mode that has NUNITS elements of mode INNER_MODE.
> +   This function is not only used by builtins, but also will be used by
> +   auto-vectorization in the future.  */
> +opt_machine_mode
> +get_vector_mode (scalar_mode inner_mode, poly_uint64 nunits)
> +{
> +  enum mode_class mclass;
> +  if (inner_mode == E_BImode)
> +mclass = MODE_VECTOR_BOOL;
> +  else if (FLOAT_MODE_P (inner_mode))
> +mclass = MODE_VECTOR_FLOAT;
> +  else
> +mclass = MODE_VECTOR_INT;
> +  machine_mode mode;
> +  FOR_EACH_MODE_IN_CLASS (mode, mclass)
> +if (inner_mode == GET_MODE_INNER (mode)
> +   && known_eq (nunits, GET_MODE_NUNITS (mode))
> +   && riscv_v_ext_vector_mode_p (mode))
> +  return mode;
> +  return opt_machine_mode ();
> +}
> +
>  } // namespace riscv_vector
> diff --

Re: [PATCH] RISC-V: Add VSETVL testcases for indexed loads/stores.

[Kito Cheng via Gcc-patches]

committed, thanks!

On Sun, Jan 29, 2023 at 11:35 PM  wrote:
>
> From: Ju-Zhe Zhong 
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/vsetvl/avl_single-72.c: New test.
> * gcc.target/riscv/rvv/vsetvl/avl_single-76.c: New test.
> * gcc.target/riscv/rvv/vsetvl/avl_single-77.c: New test.
>
> ---
>  .../riscv/rvv/vsetvl/avl_single-72.c  | 27 +++
>  .../riscv/rvv/vsetvl/avl_single-76.c  | 24 +
>  .../riscv/rvv/vsetvl/avl_single-77.c  | 27 +++
>  3 files changed, 78 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-72.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-76.c
>  create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-77.c
>
> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-72.c 
> b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-72.c
> new file mode 100644
> index 000..b1e28abd4fe
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-72.c
> @@ -0,0 +1,27 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv32gcv -mabi=ilp32 -fno-schedule-insns 
> -fno-schedule-insns2" } */
> +
> +#include "riscv_vector.h"
> +
> +void f (void * restrict in, void * restrict out, int n, int cond)
> +{
> +  size_t vl = 101;
> +  for (size_t i = 0; i < n; i++)
> +{
> +  vint8mf8_t v = __riscv_vle8_v_i8mf8 (in + i, vl);
> +  __riscv_vse8_v_i8mf8 (out + i, v, vl);
> +
> +  vint8mf8_t v2 = __riscv_vle8_v_i8mf8_tu (v, in + i + 100, vl);
> +  __riscv_vse8_v_i8mf8 (out + i + 100, v2, vl);
> +}
> +
> +  for (size_t i = 0; i < n; i++)
> +{
> +  vuint8mf8_t index = __riscv_vle8_v_u8mf8 (in + i + 300, vl);
> +  vfloat32mf2_t v2 = __riscv_vluxei8_v_f32mf2 (in + i + 200, index, vl);
> +  __riscv_vse32_v_f32mf2 (out + i + 200, v2, vl);
> +}
> +}
> +
> +/* { dg-final { scan-assembler-times 
> {vsetvli\s+zero,\s*[a-x0-9]+,\s*e32,\s*mf2,\s*tu,\s*m[au]} 1 { target { 
> no-opts "-O0" no-opts "-g" no-opts "-funroll-loops" } } } } */
> +/* { dg-final { scan-assembler-times {vsetvli} 1 { target { no-opts "-O0" 
> no-opts "-g" no-opts "-funroll-loops" } } } } */
> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-76.c 
> b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-76.c
> new file mode 100644
> index 000..1b6e818d209
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-76.c
> @@ -0,0 +1,24 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv32gcv -mabi=ilp32 -fno-schedule-insns 
> -fno-schedule-insns2" } */
> +
> +#include "riscv_vector.h"
> +
> +void f (void * restrict in, void * restrict out, int n, int cond)
> +{
> +  size_t vl = 101;
> +  for (size_t i = 0; i < n; i++)
> +{
> +  vint8mf8_t v = __riscv_vle8_v_i8mf8 (in + i, vl);
> +  __riscv_vse8_v_i8mf8 (out + i, v, vl);
> +}
> +
> +  for (size_t i = 0; i < n; i++)
> +{
> +  vuint8mf8_t index = __riscv_vle8_v_u8mf8 (in + i + 300, vl);
> +  vfloat32mf2_t v = __riscv_vle32_v_f32mf2 (in + i + 600, vl);
> +  __riscv_vsoxei8_v_f32mf2 (out + i + 200, index, v, vl);
> +}
> +}
> +
> +/* { dg-final { scan-assembler-times 
> {vsetvli\s+zero,\s*[a-x0-9]+,\s*e32,\s*mf2,\s*t[au],\s*m[au]} 1 { target { 
> no-opts "-O0" no-opts "-g" no-opts "-funroll-loops" } } } } */
> +/* { dg-final { scan-assembler-times {vsetvli} 1 { target { no-opts "-O0" 
> no-opts "-g" no-opts "-funroll-loops" } } } } */
> diff --git a/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-77.c 
> b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-77.c
> new file mode 100644
> index 000..9fb16052385
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-77.c
> @@ -0,0 +1,27 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv32gcv -mabi=ilp32 -fno-schedule-insns 
> -fno-schedule-insns2" } */
> +
> +#include "riscv_vector.h"
> +
> +void f (void * restrict in, void * restrict out, int n, int cond)
> +{
> +  size_t vl = 101;
> +  for (size_t i = 0; i < n; i++)
> +{
> +  vint8mf8_t v = __riscv_vle8_v_i8mf8 (in + i, vl);
> +  __riscv_vse8_v_i8mf8 (out + i, v, vl);
> +}
> +
> +  for (size_t i = 0; i < n; i++)
> +{
> +  vbool64_t mask = __riscv_vlm_v_b64 (in + 1, vl);
> +  vuint8mf8_t index = __riscv_vle8_v_u8mf8 (in + i + 300, vl);
> +  vfloat32mf2_t v = __riscv_vle32_v_f32mf2 (in + i + 3, vl);
> +  vfloat32mf2_t v2 = __riscv_vluxei8_v_f32mf2_tumu (mask, v, in + i + 
> 200, index, vl);
> +  __riscv_vse32_v_f32mf2 (out + i + 200, v2, vl);
> +}
> +}
> +
> +/* { dg-final { scan-assembler-times 
> {vsetvli\s+zero,\s*[a-x0-9]+,\s*e32,\s*mf2,\s*tu,\s*mu} 1 { target { no-opts 
> "-O0" no-opts "-g" no-opts "-funroll-loops" } } } } */
> +/* { dg-final { scan-assembler-times {vsetvli} 1 { target { no-opts "-O0" 
> no-opts "-g" no-opts "-funroll-loops" } } } } */
> +
> --
>

Re: [PATCH 2/3] arm: Remove unnecessary zero-extending of MVE predicates before use [PR 107674]

[Andre Vieira (lists) via Gcc-patches]

Changed the testcase to be more robust (as per the discussion for the 
first patch).


Still need the OK for the mid-end (simplify-rtx) part.

Kind regards,
Andre

On 27/01/2023 09:59, Kyrylo Tkachov wrote:




-Original Message-
From: Andre Vieira (lists) 
Sent: Friday, January 27, 2023 9:58 AM
To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
Cc: Richard Sandiford ; Richard Earnshaw
; Richard Biener 
Subject: Re: [PATCH 2/3] arm: Remove unnecessary zero-extending of MVE
predicates before use [PR 107674]



On 26/01/2023 15:06, Kyrylo Tkachov wrote:

Hi Andre,


-Original Message-
From: Andre Vieira (lists) 
Sent: Tuesday, January 24, 2023 1:54 PM
To: gcc-patches@gcc.gnu.org
Cc: Richard Sandiford ; Richard Earnshaw
; Richard Biener ;
Kyrylo Tkachov 
Subject: [PATCH 2/3] arm: Remove unnecessary zero-extending of MVE
predicates before use [PR 107674]

Hi,

This patch teaches GCC that zero-extending a MVE predicate from 16-bits
to 32-bits and then only using 16-bits is a no-op.
It does so in two steps:
- it lets gcc know that it can access any MVE predicate mode using any
other MVE predicate mode without needing to copy it, using the
TARGET_MODES_TIEABLE_P hook,
- it teaches simplify_subreg to optimize a subreg with a vector
outermode, by replacing this outermode with a same-sized integer mode
and trying the avalailable optimizations, then if successful it
surrounds the result with a subreg casting it back to the original
vector outermode.

This removes the unnecessary zero-extending shown on PR 107674

(though

it's a sign-extend there), that was introduced in gcc 11.

Bootstrapped on aarch64-none-linux-gnu and regression tested on
arm-none-eabi and armeb-none-eabi for armv8.1-m.main+mve.fp.

OK for trunk?

gcc/ChangeLog:

PR target/107674
   * conig/arm/arm.cc (arm_hard_regno_mode_ok): Use new MACRO.
   (arm_modes_tieable_p): Make MVE predicate modes tieable.
* config/arm/arm.h (VALID_MVE_PRED_MODE):  New define.
* simplify-rtx.cc (simplify_context::simplify_subreg): Teach
simplify_subreg to simplify subregs where the outermode is not
scalar.


The arm changes look ok to me. We'll want a midend maintainer to have a

look at simplify-rtx.cc




gcc/testsuite/ChangeLog:

* gcc.target/arm/mve/mve_vpt.c: Change to remove unecessary
zero-extend.


diff --git a/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c

b/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c

index

26a565b79dd1348e361b3aa23a1d6e6d13bffce8..8e562a9f065eff157f63ebd5
acf9af0a2155b5c5 100644

--- a/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c
+++ b/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c
@@ -16,9 +16,6 @@ void test0 (uint8_t *a, uint8_t *b, uint8_t *c)
   **   vldrb.8 q2, \[r0\]
   **   vldrb.8 q1, \[r1\]
   **   vcmp.i8 eq, q2, q1
-** vmrsr3, p0  @ movhi
-** uxthr3, r3
-** vmsrp0, r3  @ movhi
   **   vpst
   **   vaddt.i8q3, q2, q1
   **   vpst

Ah I see, that's the testcase from patch 1/3 that I criticized :)
Maybe if we just scan for absence of an uxth, vmrs and vmsr it will be more

robust?

Thanks,
Kyrill

I could, but I would rather not. I have a patch series waiting for GCC
14 that does further improvements to this (and other VPST codegen)
sequences and if I do scan for 'absence' of an instruction I have to
break them up into single tests each. Also it wouldn't then fail if we
start spilling the predicate directly to memory for instance. Like I
mentioned in the previous patch, the sequence is unlikely to be able to
change through scheduling (other than maybe the reordering of the loads
through some bad luck, but I could make it robust to that).


Ok, looks like it was thought through, so fine by me.
Thanks,
Kyrilldiff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 
632728371d5cef364e47bf33bfa0faba738db871..8325e7a876e2e03f14cba07385cc5a1ddd771655
 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -1104,6 +1104,10 @@ extern const int arm_arch_cde_coproc_bits[];
|| (MODE) == V16QImode || (MODE) == V8HFmode || (MODE) == V4SFmode \
|| (MODE) == V2DFmode)
 
+#define VALID_MVE_PRED_MODE(MODE) \
+  ((MODE) == HImode\
+   || (MODE) == V16BImode || (MODE) == V8BImode || (MODE) == V4BImode)
+
 #define VALID_MVE_SI_MODE(MODE) \
   ((MODE) == V2DImode ||(MODE) == V4SImode || (MODE) == V8HImode \
|| (MODE) == V16QImode)
diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index 
efc48349dd3508e6790c1a9f3bba5da689a986bc..4d9d202cad1f39ba386df9d8e4277007fd960262
 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -25656,10 +25656,7 @@ arm_hard_regno_mode_ok (unsigned int regno, 
machine_mode mode)
 return false;
 
   if (IS_VPR_REGNUM (regno))
-return mode == HImode
-  || mode == V16BImode
-  || mode == V8BImode
-  || mode == V4BImode;
+return VALID_MVE_PRED_MODE (mode);
 
   if (TARGET_THUMB1)
 /* For the Thumb we only allo

RE: [PATCH 1/3] arm: Fix sign of MVE predicate mve_pred16_t [PR 107674]

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Andre Vieira (lists) 
> Sent: Monday, January 30, 2023 4:39 PM
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw 
> Subject: Re: [PATCH 1/3] arm: Fix sign of MVE predicate mve_pred16_t [PR
> 107674]
> 
> Here's a new version with a more robust test.
> 
> OK for trunk?

Ok.
Thanks,
Kyrill

> 
> On 27/01/2023 09:56, Kyrylo Tkachov wrote:
> 
> >
> >
> >> -Original Message-
> >> From: Andre Vieira (lists) 
> >> Sent: Friday, January 27, 2023 9:54 AM
> >> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> >> Cc: Richard Earnshaw 
> >> Subject: Re: [PATCH 1/3] arm: Fix sign of MVE predicate mve_pred16_t [PR
> >> 107674]
> >>
> >>
> >>
> >> On 26/01/2023 15:02, Kyrylo Tkachov wrote:
> >>> Hi Andre,
> >>>
>  -Original Message-
>  From: Andre Vieira (lists) 
>  Sent: Tuesday, January 24, 2023 1:41 PM
>  To: gcc-patches@gcc.gnu.org
>  Cc: Kyrylo Tkachov ; Richard Earnshaw
>  
>  Subject: [PATCH 1/3] arm: Fix sign of MVE predicate mve_pred16_t [PR
>  107674]
> 
>  Hi,
> 
>  The ACLE defines mve_pred16_t as an unsigned short.  This patch
> makes
>  sure GCC treats the predicate as an unsigned type, rather than signed.
> 
>  Bootstrapped on aarch64-none-eabi and regression tested on arm-
> none-
> >> eabi
>  and armeb-none-eabi for armv8.1-m.main+mve.fp.
> 
>  OK for trunk?
> 
>  gcc/ChangeLog:
> 
>   PR target/107674
>   * config/arm/arm-builtins.cc (arm_simd_builtin_type): Rewrite to
>  use
>   new qualifiers parameter and use unsigned short type for MVE
>  predicate.
>   (arm_init_builtin): Call arm_simd_builtin_type with qualifiers
>   parameter.
>   (arm_init_crypto_builtins): Likewise.
> 
>  gcc/testsuite/ChangeLog:
> 
>   PR target/107674
>   * gcc.target/arm/mve/mve_vpt.c: New test.
> >>>
> >>> diff --git a/gcc/config/arm/arm-builtins.cc b/gcc/config/arm/arm-
> builtins.cc
> >>> index
> >>
> 11d7478d9df69139802a9d42c09dd0de7480b60e..6c67cec93ff76a4b42f3a0b3
> >> 05f697142e88fcd9 100644
> >>> --- a/gcc/config/arm/arm-builtins.cc
> >>> +++ b/gcc/config/arm/arm-builtins.cc
> >>> @@ -1489,12 +1489,14 @@ arm_lookup_simd_builtin_type
> >> (machine_mode mode,
> >>>}
> >>>
> >>>static tree
> >>> -arm_simd_builtin_type (machine_mode mode, bool unsigned_p, bool
> >> poly_p)
> >>> +arm_simd_builtin_type (machine_mode mode, enum
> arm_type_qualifiers
> >> qualifiers)
> >>>{
> >>>
> >>> I think in C++ now we can leave out the "enum" here.
> >>>
> >>> diff --git a/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c
> >> b/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c
> >>> new file mode 100644
> >>> index
> >>
> ..26a565b79dd1348e361b3a
> >> a23a1d6e6d13bffce8
> >>> --- /dev/null
> >>> +++ b/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c
> >>> @@ -0,0 +1,27 @@
> >>> +/* { dg-options "-O2" } */
> >>> +/* { dg-require-effective-target arm_v8_1m_mve_ok } */
> >>> +/* { dg-add-options arm_v8_1m_mve } */
> >>> +/* { dg-final { check-function-bodies "**" "" } } */
> >>> +#include 
> >>> +void test0 (uint8_t *a, uint8_t *b, uint8_t *c)
> >>> +{
> >>> +uint8x16_t va = vldrbq_u8 (a);
> >>> +uint8x16_t vb = vldrbq_u8 (b);
> >>> +mve_pred16_t p = vcmpeqq_u8 (va, vb);
> >>> +uint8x16_t vc = vaddq_x_u8 (va, vb, p);
> >>> +vstrbq_p_u8 (c, vc, p);
> >>> +}
> >>> +/*
> >>> +** test0:
> >>> +**   vldrb.8 q2, \[r0\]
> >>> +**   vldrb.8 q1, \[r1\]
> >>> +**   vcmp.i8 eq, q2, q1
> >>> +**   vmrsr3, p0  @ movhi
> >>> +**   uxthr3, r3
> >>> +**   vmsrp0, r3  @ movhi
> >>> +**   vpst
> >>> +**   vaddt.i8q3, q2, q1
> >>> +**   vpst
> >>> +**   vstrbt.8q3, \[r2\]
> >>> +**   bx  lr
> >>> +*/
> >>>
> >>> This explicit assembly matching looks quite fragile and sensitive to 
> >>> future
> >> scheduling and RA changes.
> >>> Is there something more targeted we could scan for to check that the
> >> predicate is unsigned now?
> >> No not really, as it's not unsigned everywhere, only in its intermediate
> >> representation between intrinsics. GCC is aware that mve_pred16_t is an
> >> unsigned short, so as soon as you try to use the value on its own or
> >> pass it as an argument or return, there is an implicit cast.
> >>
> >> I could make this particular test-case more robust by not checking
> >> specific registers. Though the sequence of loads-cmp-add-store will
> >> always be the same as it's data-dependent.
> >
> > Yeah, I suspected as such. Ok, let's abstract the registers away (I think
> check-function-bodies can use regex capturing to record particular registers)
> then.
> > Thanks,
> > Kyrill
> >

Re: [PATCH 1/3] arm: Fix sign of MVE predicate mve_pred16_t [PR 107674]

[Andre Vieira (lists) via Gcc-patches]

Here's a new version with a more robust test.

OK for trunk?

On 27/01/2023 09:56, Kyrylo Tkachov wrote:





-Original Message-
From: Andre Vieira (lists) 
Sent: Friday, January 27, 2023 9:54 AM
To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
Cc: Richard Earnshaw 
Subject: Re: [PATCH 1/3] arm: Fix sign of MVE predicate mve_pred16_t [PR
107674]



On 26/01/2023 15:02, Kyrylo Tkachov wrote:

Hi Andre,


-Original Message-
From: Andre Vieira (lists) 
Sent: Tuesday, January 24, 2023 1:41 PM
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov ; Richard Earnshaw

Subject: [PATCH 1/3] arm: Fix sign of MVE predicate mve_pred16_t [PR
107674]

Hi,

The ACLE defines mve_pred16_t as an unsigned short.  This patch makes
sure GCC treats the predicate as an unsigned type, rather than signed.

Bootstrapped on aarch64-none-eabi and regression tested on arm-none-

eabi

and armeb-none-eabi for armv8.1-m.main+mve.fp.

OK for trunk?

gcc/ChangeLog:

PR target/107674
* config/arm/arm-builtins.cc (arm_simd_builtin_type): Rewrite to
use
new qualifiers parameter and use unsigned short type for MVE
predicate.
(arm_init_builtin): Call arm_simd_builtin_type with qualifiers
parameter.
(arm_init_crypto_builtins): Likewise.

gcc/testsuite/ChangeLog:

PR target/107674
* gcc.target/arm/mve/mve_vpt.c: New test.


diff --git a/gcc/config/arm/arm-builtins.cc b/gcc/config/arm/arm-builtins.cc
index

11d7478d9df69139802a9d42c09dd0de7480b60e..6c67cec93ff76a4b42f3a0b3
05f697142e88fcd9 100644

--- a/gcc/config/arm/arm-builtins.cc
+++ b/gcc/config/arm/arm-builtins.cc
@@ -1489,12 +1489,14 @@ arm_lookup_simd_builtin_type

(machine_mode mode,

   }

   static tree
-arm_simd_builtin_type (machine_mode mode, bool unsigned_p, bool

poly_p)

+arm_simd_builtin_type (machine_mode mode, enum arm_type_qualifiers

qualifiers)

   {

I think in C++ now we can leave out the "enum" here.

diff --git a/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c

b/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c

new file mode 100644
index

..26a565b79dd1348e361b3a
a23a1d6e6d13bffce8

--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/mve/mve_vpt.c
@@ -0,0 +1,27 @@
+/* { dg-options "-O2" } */
+/* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-add-options arm_v8_1m_mve } */
+/* { dg-final { check-function-bodies "**" "" } } */
+#include 
+void test0 (uint8_t *a, uint8_t *b, uint8_t *c)
+{
+uint8x16_t va = vldrbq_u8 (a);
+uint8x16_t vb = vldrbq_u8 (b);
+mve_pred16_t p = vcmpeqq_u8 (va, vb);
+uint8x16_t vc = vaddq_x_u8 (va, vb, p);
+vstrbq_p_u8 (c, vc, p);
+}
+/*
+** test0:
+** vldrb.8 q2, \[r0\]
+** vldrb.8 q1, \[r1\]
+** vcmp.i8 eq, q2, q1
+** vmrsr3, p0  @ movhi
+** uxthr3, r3
+** vmsrp0, r3  @ movhi
+** vpst
+** vaddt.i8q3, q2, q1
+** vpst
+** vstrbt.8q3, \[r2\]
+** bx  lr
+*/

This explicit assembly matching looks quite fragile and sensitive to future

scheduling and RA changes.

Is there something more targeted we could scan for to check that the

predicate is unsigned now?
No not really, as it's not unsigned everywhere, only in its intermediate
representation between intrinsics. GCC is aware that mve_pred16_t is an
unsigned short, so as soon as you try to use the value on its own or
pass it as an argument or return, there is an implicit cast.

I could make this particular test-case more robust by not checking
specific registers. Though the sequence of loads-cmp-add-store will
always be the same as it's data-dependent.


Yeah, I suspected as such. Ok, let's abstract the registers away (I think 
check-function-bodies can use regex capturing to record particular registers) 
then.
Thanks,
Kyrill
diff --git a/gcc/config/arm/arm-builtins.cc b/gcc/config/arm/arm-builtins.cc
index 
11d7478d9df69139802a9d42c09dd0de7480b60e..58bf856f08d8d4836d01c5e4545dc5bab2f39c14
 100644
--- a/gcc/config/arm/arm-builtins.cc
+++ b/gcc/config/arm/arm-builtins.cc
@@ -1489,12 +1489,14 @@ arm_lookup_simd_builtin_type (machine_mode mode,
 }
 
 static tree
-arm_simd_builtin_type (machine_mode mode, bool unsigned_p, bool poly_p)
+arm_simd_builtin_type (machine_mode mode, arm_type_qualifiers qualifiers)
 {
-  if (poly_p)
+  if ((qualifiers & qualifier_poly) != 0)
 return arm_lookup_simd_builtin_type (mode, qualifier_poly);
-  else if (unsigned_p)
+  else if ((qualifiers & qualifier_unsigned) != 0)
 return arm_lookup_simd_builtin_type (mode, qualifier_unsigned);
+  else if ((qualifiers & qualifier_predicate) != 0)
+return unsigned_intHI_type_node;
   else
 return arm_lookup_simd_builtin_type (mode, qualifier_none);
 }
@@ -1755,9 +1757,7 @@ arm_init_builtin (unsigned int fcode, arm_builtin_datum 
*d,
   else
{
  eltype
-   = arm_simd_builtin_type (op_mode,
-(qualifiers & qualifier_unsigned) != 0,
-   

[PATCH v2] c++: fix ICE with -Wduplicated-cond [PR107593]

[Marek Polacek via Gcc-patches]

On Fri, Jan 27, 2023 at 06:17:00PM -0500, Patrick Palka wrote:
> On Fri, 27 Jan 2023, Marek Polacek wrote:
> 
> > On Fri, Jan 27, 2023 at 05:15:00PM -0500, Patrick Palka wrote:
> > > On Thu, 26 Jan 2023, Marek Polacek via Gcc-patches wrote:
> > > 
> > > > Here we crash because a CAST_EXPR, representing T(), doesn't have
> > > > its operand, and operand_equal_p's STRIP_ANY_LOCATION_WRAPPER doesn't
> > > > expect that.  (o_e_p is called from warn_duplicated_cond_add_or_warn.)
> > > > 
> > > > In the past we've adjusted o_e_p to better cope with template codes,
> > > > but in this case I think we just want to avoid attempting to warn
> > > > about inst-dependent expressions; I don't think I've ever envisioned
> > > > -Wduplicated-cond to warn about them.
> > > > 
> > > > The ICE started with r12-6022, two-stage name lookup for overloaded
> > > > operators, which gave dependent operators a TREE_TYPE (in particular,
> > > > DEPENDENT_OPERATOR_TYPE), so we no longer bail out here in o_e_p:
> > > > 
> > > >   /* Similar, if either does not have a type (like a template id),
> > > >  they aren't equal.  */
> > > >   if (!TREE_TYPE (arg0) || !TREE_TYPE (arg1))
> > > > return false;
> > > > 
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > > 
> > > > PR c++/107593
> > > > 
> > > > gcc/cp/ChangeLog:
> > > > 
> > > > * parser.cc (cp_parser_selection_statement): Don't do
> > > > -Wduplicated-cond when the condition is dependent.
> > > > 
> > > > gcc/testsuite/ChangeLog:
> > > > 
> > > > * g++.dg/warn/Wduplicated-cond3.C: New test.
> > > > ---
> > > >  gcc/cp/parser.cc  |  3 +-
> > > >  gcc/testsuite/g++.dg/warn/Wduplicated-cond3.C | 38 +++
> > > >  2 files changed, 40 insertions(+), 1 deletion(-)
> > > >  create mode 100644 gcc/testsuite/g++.dg/warn/Wduplicated-cond3.C
> > > > 
> > > > diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
> > > > index 4cdc1cd472f..3df85d49e16 100644
> > > > --- a/gcc/cp/parser.cc
> > > > +++ b/gcc/cp/parser.cc
> > > > @@ -13209,7 +13209,8 @@ cp_parser_selection_statement (cp_parser* 
> > > > parser, bool *if_p,
> > > > /* Add the condition.  */
> > > > condition = finish_if_stmt_cond (condition, statement);
> > > >  
> > > > -   if (warn_duplicated_cond)
> > > > +   if (warn_duplicated_cond
> > > > +   && !instantiation_dependent_expression_p (condition))
> > > >   warn_duplicated_cond_add_or_warn (token->location, 
> > > > condition,
> > > > &chain);
> > > 
> > > I noticed warn_duplicated_cond_add_or_warn already has logic to handle
> > > TREE_SIDE_EFFECTS conditions by invaliding the entire chain.  I wonder
> > > if we'd want to do the same for instantiation-dep conditions?
> > 
> > warn_duplicated_cond_add_or_warn lives in c-family/c-warn.cc so I can't
> > use instantiation_dependent_expression_p there.  Sure, I could write a
> > C++ wrapper but with my patch we just won't add CONDITION to the chain
> > which I thought would work just as well.
> 
> Ah that's unfortunate :( ISTM desirable to conservatively assume an
> inst-dep cond has side effects though (possibly directly from
> cp_parser_selection_statement), to avoid false positives as in:
> 
>   int n;
> 
>   template bool g() { n = 42; }
> 
>   template
>   void f() {
> if (n)
>   ;
> else if (g())
>   ;
> else if (n)
>   ;
>   }

You're right, we shouldn't warn there.  So I've just added a new param
with a default argument.  A new PR was just opened for the same problem
so I've added another test.

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

-- >8 --
Here we crash because a CAST_EXPR, representing T(), doesn't have
its operand, and operand_equal_p's STRIP_ANY_LOCATION_WRAPPER doesn't
expect that.  (o_e_p is called from warn_duplicated_cond_add_or_warn.)

In the past we've adjusted o_e_p to better cope with template codes,
but in this case I think we just want to avoid attempting to warn
about inst-dependent expressions; I don't think I've ever envisioned
-Wduplicated-cond to warn about them.  Also destroy the chain when
an inst-dependent expression is encountered to not warn in
Wduplicated-cond4.C.

The ICE started with r12-6022, two-stage name lookup for overloaded
operators, which gave dependent operators a TREE_TYPE (in particular,
DEPENDENT_OPERATOR_TYPE), so we no longer bail out here in o_e_p:

  /* Similar, if either does not have a type (like a template id),
 they aren't equal.  */
  if (!TREE_TYPE (arg0) || !TREE_TYPE (arg1))
return false;

PR c++/107593
PR c++/108597

gcc/c-family/ChangeLog:

* c-common.h (warn_duplicated_cond_add_or_warn): New parameter.
* c-warn.cc (warn_duplicated_cond_add_or_warn): Add new parameter.
Use it.

gcc/cp/ChangeLog:

* parser.cc (cp_parser_selection_statement): Pass the result

Re: [PATCH] Add support for x86_64-*-gnu-* targets to build x86_64 gnumach/hurd

[Thomas Schwinge]

Hi!

On 2023-01-27T21:15:01-0500, Flávio Cruz  wrote:
> Not sure what happened, but here's the patch as an attachment. Thanks for
> your patience.

Thanks, that worked.  Without any changes now pushed to master branch in
commit 5f8950b403f6351f125d8281d2e7430a43e7d125
"Add support for x86_64-*-gnu-* targets to build x86_64 gnumach/hurd",
see attached.

I'll watch how x86_64 GNU/Hurd develops!  :-)


Grüße
 Thomas


> On Fri, Jan 27, 2023 at 4:16 PM Thomas Schwinge 
> wrote:
>
>> Hi Flavio!
>>
>> Sorry to bother you one last time (hopefully):
>>
>> On 2023-01-27T01:49:25-0500, Flavio Cruz  wrote:
>> > On Thu, Jan 26, 2023 at 09:34:16AM +0100, Thomas Schwinge wrote:
>> >>As you don't have FSF Copyright Assignment on file for GCC (as far as I
>> >>can tell), are you either going to get that, or re-submit this patch with
>> >>DCO ('Signed-off-by:' tag), ?
>> >
>> > Yes, I think I have it for Hurd related projects
>>
>> Yes.
>>
>> > but not GCC. Added Signed-off-by.
>>
>> ACK, thanks.
>>
>> > Revisted patch is inlined below. Also added the ChangeLog details.
>>
>> Thanks!
>>
>> If I 'git am' that one, I get:
>>
>> warning: Patch sent with format=flowed; space at the end of lines might 
>> be lost.
>> Applying: Add support for x86_64-*-gnu-* targets to build x86_64 
>> gnumach/hurd
>> error: corrupt patch at line 180
>> Patch failed at 0001 Add support for x86_64-*-gnu-* targets to build 
>> x86_64 gnumach/hurd
>> [...]
>>
>> That's due to:
>>
>> Content-Type: text/plain; charset="iso-8859-1"; format=flowed
>>
>> Is it easy for you to re-send that "differently"?  (Or, just attach the
>> file generated by 'git format-patch'.)  If that's inconvenient, then I'll
>> fix it up manually, no worries.
>>
>>
>> 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
>From 5f8950b403f6351f125d8281d2e7430a43e7d125 Mon Sep 17 00:00:00 2001
From: Flavio Cruz 
Date: Thu, 26 Jan 2023 22:45:27 -0500
Subject: [PATCH] Add support for x86_64-*-gnu-* targets to build x86_64
 gnumach/hurd

Tested by building a toolchain and compiling gnumach for x86_64 [1].
This is the basic version without unwind support which I think is only
required to implement exceptions.

[1]
https://github.com/flavioc/cross-hurd/blob/master/bootstrap-kernel.sh.

gcc/ChangeLog:
	* config.gcc: Recognize x86_64-*-gnu* targets and include
	i386/gnu64.h.
	* config/i386/gnu64.h: Define configuration for new target
	including ld.so location.

libgcc/ChangeLog:
	* config.host: Recognize x86_64-*-gnu* targets.
	* config/i386/gnu-unwind.h: Update to handle __x86_64__ with a
	TODO for now.

Signed-off-by: Flavio Cruz 
---
 gcc/config.gcc  |  5 -
 gcc/config/i386/gnu64.h | 40 +
 libgcc/config.host  |  8 ++-
 libgcc/config/i386/gnu-unwind.h | 10 +
 4 files changed, 61 insertions(+), 2 deletions(-)
 create mode 100644 gcc/config/i386/gnu64.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 744b46fb3b0..f0958e1c959 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1971,7 +1971,7 @@ i[34567]86-*-linux* | i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-gnu* | i[34567]8
 		;;
 	esac
 	;;
-x86_64-*-linux* | x86_64-*-kfreebsd*-gnu)
+x86_64-*-linux* | x86_64-*-kfreebsd*-gnu | x86_64-*-gnu*)
 	tm_file="${tm_file} i386/unix.h i386/att.h elfos.h gnu-user.h glibc-stdint.h \
 		 i386/x86-64.h i386/gnu-user-common.h i386/gnu-user64.h"
 	case ${target} in
@@ -1982,6 +1982,9 @@ x86_64-*-linux* | x86_64-*-kfreebsd*-gnu)
 	x86_64-*-kfreebsd*-gnu)
 		tm_file="${tm_file} kfreebsd-gnu.h i386/kfreebsd-gnu64.h"
 		;;
+	x86_64-*-gnu*)
+		tm_file="${tm_file} gnu.h i386/gnu64.h"
+		;;
 	esac
 	tmake_file="${tmake_file} i386/t-linux64"
 	x86_multilibs="${with_multilib_list}"
diff --git a/gcc/config/i386/gnu64.h b/gcc/config/i386/gnu64.h
new file mode 100644
index 000..a411f0e802a
--- /dev/null
+++ b/gcc/config/i386/gnu64.h
@@ -0,0 +1,40 @@
+/* Configuration for an x86_64 running GNU with ELF as the target machine.  */
+
+/*
+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 of the License, 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.  If not, see .
+*/
+
+#define GNU_USER_LINK_EM

Re: [COMMITTED] testsuite: Restore TORTURE_OPTIONS in gm2/warnings/returntype/fail/warnings-returntype-fail.exp

[Rainer Orth]

Hi Thomas,

> And note that this is independent of (or: complements) Iain's
> commit r13-5473-gfe4608efc15b881ac908a3f90d7322736495ae72
> "Modula-2: Claim Wreturn-type in lang.opt",
> ,
> which remains necessary for:
> 'gm2/warnings/returntype/pass/Termbase.mod',
> 'gm2/warnings/returntype/pass/goodreturn.mod',
> 'gm2/warnings/returntype/pass/keypressedsimple.mod'.

indeed: those failures happened for the default multilib, while the ones
I observed affect the non-default ones.

Rainer

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

Re: [COMMITTED] testsuite: Restore TORTURE_OPTIONS in gm2/warnings/returntype/fail/warnings-returntype-fail.exp

[Thomas Schwinge]

Hi!

On 2023-01-30T14:24:43+0100, Rainer Orth  wrote:
> Between 20230126 and 20230127, 1100+ gm2 tests started to FAIL for the
> non-default multilib, e.g.
>
> FAIL: gm2/calling-c/datatypes/unbounded/run/pass/m.mod compilation, 
> {additional_flags= -O0 -g -Werror=return-type } timeout=10
> UNRESOLVED: gm2/calling-c/datatypes/unbounded/run/pass/m.mod execution, 
> {additional_flags= -O0 -g -Werror=return-type } timeout=10
> FAIL: gm2/case/pass/testcase1.mod,  -O0 -g -Werror=return-type
> [...]
> cc1gm2: warning: '-Werror=' argument '-Werror=return-type' is not valid for 
> Modula-2
>
> I'm seeing this on all of Solaris/x86, Solaris/SPARC, and Linux/x86_64.

ACK.

> I could trace this to
> gm2/warnings/returntype/fail/warnings-returntype-fail.exp not properly
> restoring TORTURE_OPTIONS.
>
> Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11.  Installed on
> trunk.

ACK, thanks.


And note that this is independent of (or: complements) Iain's
commit r13-5473-gfe4608efc15b881ac908a3f90d7322736495ae72
"Modula-2: Claim Wreturn-type in lang.opt",
,
which remains necessary for:
'gm2/warnings/returntype/pass/Termbase.mod',
'gm2/warnings/returntype/pass/goodreturn.mod',
'gm2/warnings/returntype/pass/keypressedsimple.mod'.


Grüße
 Thomas


> 2023-01-30  Rainer Orth  
>
>   gcc/testsuite:
>   * gm2/warnings/returntype/fail/warnings-returntype-fail.exp: Save,
>   restore TORTURE_OPTIONS.
>
> diff --git 
> a/gcc/testsuite/gm2/warnings/returntype/fail/warnings-returntype-fail.exp 
> b/gcc/testsuite/gm2/warnings/returntype/fail/warnings-returntype-fail.exp
> --- a/gcc/testsuite/gm2/warnings/returntype/fail/warnings-returntype-fail.exp
> +++ b/gcc/testsuite/gm2/warnings/returntype/fail/warnings-returntype-fail.exp
> @@ -28,6 +28,8 @@ load_lib gm2-torture.exp
>  gm2_init_pim "${srcdir}/gm2/warnings/returntype/fail"
>
>  global TORTURE_OPTIONS
> +
> +set old_options $TORTURE_OPTIONS
>  set TORTURE_OPTIONS { { -O0 -g -Werror=return-type } }
>
>  foreach testcase [lsort [glob -nocomplain $srcdir/$subdir/*.mod]] {
> @@ -38,3 +40,5 @@ foreach testcase [lsort [glob -nocomplai
>
>  gm2-torture-fail $testcase
>  }
> +
> +set TORTURE_OPTIONS $old_options
-
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] aarch64: Update Ampere-1A (-mcpu=ampere1a) to include SM4

[Philipp Tomsich]

On Mon, 30 Jan 2023 at 15:18, Kyrylo Tkachov  wrote:
>
>
>
> > -Original Message-
> > From: Gcc-patches  > bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Philipp
> > Tomsich
> > Sent: Saturday, January 28, 2023 11:12 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Manolis Tsamis ; Richard Sandiford
> > ; Tamar Christina
> > ; Philipp Tomsich 
> > Subject: [PATCH] aarch64: Update Ampere-1A (-mcpu=ampere1a) to include
> > SM4
> >
> > gcc/ChangeLog:
> >
> >   * config/aarch64/aarch64-cores.def (AARCH64_CORE): Update
> > ampere1a to include SM4.
>
> Ok, this looks consistent with what recently went in to LLVM.
> Thanks,
> Kyrill

Thanks, applied to master!
Philipp.

>
> >
> > Signed-off-by: Philipp Tomsich 
> > ---
> >
> >  gcc/config/aarch64/aarch64-cores.def | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/gcc/config/aarch64/aarch64-cores.def
> > b/gcc/config/aarch64/aarch64-cores.def
> > index 2a0f52e1dd9..85fdfd8bf74 100644
> > --- a/gcc/config/aarch64/aarch64-cores.def
> > +++ b/gcc/config/aarch64/aarch64-cores.def
> > @@ -70,7 +70,7 @@ AARCH64_CORE("thunderxt83",   thunderxt83,
> > thunderx,  V8A,  (CRC, CRYPTO), thu
> >
> >  /* Ampere Computing ('\xC0') cores. */
> >  AARCH64_CORE("ampere1", ampere1, cortexa57, V8_6A, (F16, RNG, AES,
> > SHA3), ampere1, 0xC0, 0xac3, -1)
> > -AARCH64_CORE("ampere1a", ampere1a, cortexa57, V8_6A, (F16, RNG, AES,
> > SHA3, MEMTAG), ampere1a, 0xC0, 0xac4, -1)
> > +AARCH64_CORE("ampere1a", ampere1a, cortexa57, V8_6A, (F16, RNG, AES,
> > SHA3, SM4, MEMTAG), ampere1a, 0xC0, 0xac4, -1)
> >  /* Do not swap around "emag" and "xgene1",
> > this order is required to handle variant correctly. */
> >  AARCH64_CORE("emag",emag,  xgene1,V8A,  (CRC, CRYPTO), 
> > emag,
> > 0x50, 0x000, 3)
> > --
> > 2.34.1
>

Re: Fix wrong code issues with ipa-sra

[Jan Hubicka via Gcc-patches]

> Hello,
> 
> Coverity flagged a real issue in this patch:
> 
> On Mon, 16 Jan 2023, Jan Hubicka via Gcc-patches wrote:
> > --- a/gcc/ipa-utils.cc
> > +++ b/gcc/ipa-utils.cc
> [...]
> > +bitmap
> > +find_always_executed_bbs (function *fun, bool assume_return_or_eh)
> > +{
> > +  auto_vec stack;
> > +  auto_vec terminating_bbs;
> > +  hash_set visited;
> > +  edge e;
> > +  edge_iterator ei;
> > +
> > +  /* First walk all BBs reachable from entry stopping on statements that 
> > may
> > + terminate execution.  Everything past this statement is not going to 
> > be executed
> > + each invocation.  */
> > +  stack.safe_push (ENTRY_BLOCK_PTR_FOR_FN (fun));
> > +  while (!stack.is_empty ())
> > +{
> > +  basic_block bb = stack.pop ();
> > +  bool found = false, found_exit = false;
> > +  if (!assume_return_or_eh
> > + && (EDGE_COUNT (bb->succs) == 0 || (bb->flags & BB_IRREDUCIBLE_LOOP)))
> > +   found = true;
> > +  FOR_EACH_EDGE (e, ei, bb->succs)
> > +   {
> > + if (e->dest == EXIT_BLOCK_PTR_FOR_FN (fun))
> > +   {
> > + found_exit = true;
> > + break;
> > +   }
> > + /* Watch for infinite loops.  */
> > + if (!found && (assume_return_or_eh & EDGE_DFS_BACK)
>  ^^^
> This bitwise 'and' always evaluates to zero, making the entire clause 
> always-false.
Hi,
that is a good catch.  This patch fixes the stupid typo info
find_always_executed_bbs which made all edges to be considered as ones
closing infinite loops.  This fix has somewhat snowballed as, comparing
it to finite_function_p, I noticed a divergence in handling of volatile
asms (find_always_executed_bbs is conservative and thinks that volatile
statement may return or do EH, but it is really impossible and elsewhere
we expects that we dont) and I also noticed a bug in handling early
returns which made some loops to be missed.

I also noticed that function assumes that irreducible loops are marked in CFG
which is not necessarily true and it is easy to detect them during the walk.

Bootstrapped/regtested x86_64-linux, comitted.

gcc/ChangeLog:

2023-01-29  Jan Hubicka  

* ipa-utils.cc: Include calls.h, cfgloop.h and cfganal.h
(stmt_may_terminate_function_p): If assuming return or EH
volatile asm is safe.
(find_always_executed_bbs): Fix handling of terminating BBS and
infinite loops; add debug output.
* tree-ssa-alias.cc (stmt_kills_ref_p): Fix debug output

gcc/testsuite/ChangeLog:

2023-01-29  Jan Hubicka  

* gcc.dg/ipa/ipa-sra-30.c: New test.
* gcc.dg/ipa/ipa-sra-31.c: New test.
* gcc.dg/tree-ssa/modref-dse-7.c: New test.

diff --git a/gcc/ipa-utils.cc b/gcc/ipa-utils.cc
index 3d5633340f1..8badcc2c110 100644
--- a/gcc/ipa-utils.cc
+++ b/gcc/ipa-utils.cc
@@ -40,6 +40,9 @@ along with GCC; see the file COPYING3.  If not see
 #include "ipa-modref-tree.h"
 #include "ipa-modref.h"
 #include "tree-ssa-loop-niter.h"
+#include "calls.h"
+#include "cfgloop.h"
+#include "cfganal.h"
 
 /* Debugging function for postorder and inorder code. NOTE is a string
that is printed before the nodes are printed.  ORDER is an array of
@@ -796,11 +799,11 @@ stmt_may_terminate_function_p (function *fun, gimple 
*stmt, bool assume_return_o
 {
   if (stmt_can_throw_external (fun, stmt))
 return true;
+  if (assume_return_or_eh)
+return false;
   gasm *astmt = dyn_cast  (stmt);
   if (astmt && gimple_asm_volatile_p (astmt))
 return true;
-  if (assume_return_or_eh)
-return false;
   if (gimple_could_trap_p (stmt))
 return true;
   if (gcall *call = dyn_cast  (stmt))
@@ -832,8 +835,14 @@ find_always_executed_bbs (function *fun, bool 
assume_return_or_eh)
   auto_vec stack;
   auto_vec terminating_bbs;
   hash_set visited;
+  hash_set terminating_bbs_set;
   edge e;
   edge_iterator ei;
+  int flags = flags_from_decl_or_type (fun->decl);
+  /* PUre and const functions always return.  */
+  assume_return_or_eh |= (flags & (ECF_CONST|ECF_PURE)) && !(flags & 
ECF_LOOPING_CONST_OR_PURE);
+  if (!assume_return_or_eh)
+mark_dfs_back_edges (fun);
 
   /* First walk all BBs reachable from entry stopping on statements that may
  terminate execution.  Everything past this statement is not going to be 
executed
@@ -843,9 +852,8 @@ find_always_executed_bbs (function *fun, bool 
assume_return_or_eh)
 {
   basic_block bb = stack.pop ();
   bool found = false, found_exit = false;
-  if (!assume_return_or_eh
- && (EDGE_COUNT (bb->succs) == 0 || (bb->flags & BB_IRREDUCIBLE_LOOP)))
-   found = true;
+  if (bb->index == EXIT_BLOCK)
+   continue;
   FOR_EACH_EDGE (e, ei, bb->succs)
{
  if (e->dest == EXIT_BLOCK_PTR_FOR_FN (fun))
@@ -854,10 +862,28 @@ find_always_executed_bbs (function *fun, bool 
assume_return_or_eh)
  break;
}
  /* Watch for infinite loops.  */
- if (!found && (assume_re

RE: [PATCH] aarch64: Update Ampere-1A (-mcpu=ampere1a) to include SM4

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Gcc-patches  bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Philipp
> Tomsich
> Sent: Saturday, January 28, 2023 11:12 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Manolis Tsamis ; Richard Sandiford
> ; Tamar Christina
> ; Philipp Tomsich 
> Subject: [PATCH] aarch64: Update Ampere-1A (-mcpu=ampere1a) to include
> SM4
> 
> gcc/ChangeLog:
> 
>   * config/aarch64/aarch64-cores.def (AARCH64_CORE): Update
> ampere1a to include SM4.

Ok, this looks consistent with what recently went in to LLVM.
Thanks,
Kyrill

> 
> Signed-off-by: Philipp Tomsich 
> ---
> 
>  gcc/config/aarch64/aarch64-cores.def | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/config/aarch64/aarch64-cores.def
> b/gcc/config/aarch64/aarch64-cores.def
> index 2a0f52e1dd9..85fdfd8bf74 100644
> --- a/gcc/config/aarch64/aarch64-cores.def
> +++ b/gcc/config/aarch64/aarch64-cores.def
> @@ -70,7 +70,7 @@ AARCH64_CORE("thunderxt83",   thunderxt83,
> thunderx,  V8A,  (CRC, CRYPTO), thu
> 
>  /* Ampere Computing ('\xC0') cores. */
>  AARCH64_CORE("ampere1", ampere1, cortexa57, V8_6A, (F16, RNG, AES,
> SHA3), ampere1, 0xC0, 0xac3, -1)
> -AARCH64_CORE("ampere1a", ampere1a, cortexa57, V8_6A, (F16, RNG, AES,
> SHA3, MEMTAG), ampere1a, 0xC0, 0xac4, -1)
> +AARCH64_CORE("ampere1a", ampere1a, cortexa57, V8_6A, (F16, RNG, AES,
> SHA3, SM4, MEMTAG), ampere1a, 0xC0, 0xac4, -1)
>  /* Do not swap around "emag" and "xgene1",
> this order is required to handle variant correctly. */
>  AARCH64_CORE("emag",emag,  xgene1,V8A,  (CRC, CRYPTO), emag,
> 0x50, 0x000, 3)
> --
> 2.34.1

RE: [PATCH]AArch64: Fix codegen regressions around tbz.

[Tamar Christina via Gcc-patches]

> -Original Message-
> From: Richard Sandiford 
> Sent: Friday, January 27, 2023 12:26 PM
> To: Tamar Christina 
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov 
> Subject: Re: [PATCH]AArch64: Fix codegen regressions around tbz.
> 
> Tamar Christina  writes:
> > Hi All,
> >
> > We were analyzing code quality after recent changes and have noticed
> > that the tbz support somehow managed to increase the number of
> > branches overall rather than decreased them.
> >
> > While investigating this we figured out that the problem is that when
> > an existing &  exists in gimple and the instruction is
> > generated because of the range information gotten from the ANDed
> > constant that we end up with the situation that you get a NOP AND in the
> RTL expansion.
> >
> > This is not a problem as CSE will take care of it normally.   The issue is 
> > when
> > this original AND was done in a location where PRE or FRE "lift" the
> > AND to a different basic block.  This triggers a problem when the
> > resulting value is not single use.  Instead of having an AND and tbz,
> > we end up generating an AND + TST + BR if the mode is HI or QI.
> >
> > This CSE across BB was a problem before but this change made it worse.
> > Our branch patterns rely on combine being able to fold AND or
> > zero_extends into the instructions.
> >
> > To work around this (since a proper fix is outside of the scope of
> > stage-4) we are limiting the new tbranch optab to only HI and QI mode
> > values.  This isn't a problem because these two modes are modes for
> > which we don't have CBZ support, so they are the problematic cases to
> begin with.  Additionally booleans are QI.
> >
> > The second thing we're doing is limiting the only legal bitpos to pos 0. 
> > i.e.
> > only the bottom bit.  This such that we prevent the double ANDs as
> > much as possible.
> >
> > Now most other cases, i.e. where we had an explicit & in the source
> > code are still handled correctly by the anonymous
> > (*tb1)
> > pattern that was added along with tbranch support.
> >
> > This means we don't expand the superflous AND here, and while it
> > doesn't fix the problem that in the cross BB case we loss tbz, it also 
> > doesn't
> make things worse.
> >
> > With these tweaks we've now reduced the number of insn uniformly as
> > originally expected.
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> >
> > Ok for master?
> >
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > * config/aarch64/aarch64.md (tbranch_3): Restrict to
> SHORT
> > and bottom bit only.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/aarch64/tbz_2.c: New test.
> 
> Agreed that reducing the scope of the new optimisation seems like a safe
> compromise for GCC 13.  But could you add a testcase that shows the effect
> of both changes (reducing the mode selection and the bit selection)?  The
> test above passes even without the patch.
> 
> It would be good to have a PR tracking this too.

I've been trying to isolate a small testcase to include, and it's not been 
trivial as GCC
will do various transformations on smaller sequences to still do the right 
thing.

I have various testcase where GCC is doing the wrong thing for the branches but 
as soon
As my repro for the cases this fixes gets too small problem gets hidden..

> 
> Personally, I think we should try to get to the stage where gimple does the
> CSE optimisations we need, and where the tbranch optab can generate a tbz
> directly (rather than splitting it apart and hoping that combine will put it 
> back
> together later).

Agreed, but that doesn't solve all the problems though. GCC is in general quite 
bad at branch
layouts especially wrt. To branch distances. For instance BB rotation doesn't 
take distance into
account. And TBZ, CBZ, B have different ranges.  Since the distance isn't taken 
into account we
end up "optimizing" the branch and then at codegen doing an emergency distance 
enlargement
using a TST + B to replace whatever we optimized too.

LLVM does much better in all of these scenarios, so it's likely that the entire 
branch strategy needs
an overhaul.

https://godbolt.org/z/1dhf7T5he  shows some of the mini examples.  I can keep 
trying to make a
reproducer for what my patch changes if you'd like, but I don't think it will 
be small..  The general
problem is the same as in f2 but we introduce it in the cases of f3 as well 
(bool), but adding & to a bool
will get it trivially optimized out.

Thanks,
Tamar

> 
> Thanks,
> Richard
> 
> > --- inline copy of patch --
> > diff --git a/gcc/config/aarch64/aarch64.md
> > b/gcc/config/aarch64/aarch64.md index
> >
> 2c1367977a68fc8e4289118e07bb61398856791e..aa09e93d85e9628e8944e0349
> 869
> > 7eb9597ef867 100644
> > --- a/gcc/config/aarch64/aarch64.md
> > +++ b/gcc/config/aarch64/aarch64.md
> > @@ -949,8 +949,8 @@ (define_insn "*cb1"
> >
> >  (define_expand "tbranch_3"
> >[(set (pc) (if_then_

[COMMITTED] testsuite: Restore TORTURE_OPTIONS in gm2/warnings/returntype/fail/warnings-returntype-fail.exp

[Rainer Orth]

Between 20230126 and 20230127, 1100+ gm2 tests started to FAIL for the
non-default multilib, e.g.

FAIL: gm2/calling-c/datatypes/unbounded/run/pass/m.mod compilation, 
{additional_flags= -O0 -g -Werror=return-type } timeout=10
UNRESOLVED: gm2/calling-c/datatypes/unbounded/run/pass/m.mod execution, 
{additional_flags= -O0 -g -Werror=return-type } timeout=10
FAIL: gm2/case/pass/testcase1.mod,  -O0 -g -Werror=return-type  
[...]
cc1gm2: warning: '-Werror=' argument '-Werror=return-type' is not valid for 
Modula-2

I'm seeing this on all of Solaris/x86, Solaris/SPARC, and Linux/x86_64.

I could trace this to
gm2/warnings/returntype/fail/warnings-returntype-fail.exp not properly
restoring TORTURE_OPTIONS.

Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11.  Installed on
trunk.

Rainer

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


2023-01-30  Rainer Orth  

gcc/testsuite:
* gm2/warnings/returntype/fail/warnings-returntype-fail.exp: Save,
restore TORTURE_OPTIONS.

diff --git a/gcc/testsuite/gm2/warnings/returntype/fail/warnings-returntype-fail.exp b/gcc/testsuite/gm2/warnings/returntype/fail/warnings-returntype-fail.exp
--- a/gcc/testsuite/gm2/warnings/returntype/fail/warnings-returntype-fail.exp
+++ b/gcc/testsuite/gm2/warnings/returntype/fail/warnings-returntype-fail.exp
@@ -28,6 +28,8 @@ load_lib gm2-torture.exp
 gm2_init_pim "${srcdir}/gm2/warnings/returntype/fail"
 
 global TORTURE_OPTIONS
+
+set old_options $TORTURE_OPTIONS
 set TORTURE_OPTIONS { { -O0 -g -Werror=return-type } }
 
 foreach testcase [lsort [glob -nocomplain $srcdir/$subdir/*.mod]] {
@@ -38,3 +40,5 @@ foreach testcase [lsort [glob -nocomplai
 
 gm2-torture-fail $testcase
 }
+
+set TORTURE_OPTIONS $old_options

Patch ping

[Jakub Jelinek via Gcc-patches]

I'd like to ping a few pending patches:

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607534.html
  - PR107846 - P1 - c-family: Account for integral promotions of left shifts 
for -Wshift-overflow warning

https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610285.html
  - PR108464 - P1 - file-prefix-map: Fix up -f*-prefix-map= (3 variants)

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606382.html
  - PR107703 - P3, ABI - libgcc, i386: Add __fix{,uns}bfti and __float{,un}tibf

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606973.html
  - PR107465 - P2 - c-family: Fix up -Wsign-compare BIT_NOT_EXPR handling

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607104.html
  - PR107465 - P2 - c-family: Incremental fix for -Wsign-compare BIT_NOT_EXPR 
handling

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607145.html
  - PR107558 - P2 - c++: Don't clear TREE_READONLY for -fmerge-all-constants 
for non-aggregates

https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608932.html
  - PR108079 - P2 - c, c++, cgraphunit: Prevent duplicated -Wunused-value 
warnings

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605965.html
  - ABI - aarch64: Add bfloat16_t support for aarch64 (enabling it in GCC 14
will be harder)

Thanks

Jakub

[PATCH] tree-optimization/108574 - wrong-code with PRE PHI node processing

[Richard Biener via Gcc-patches]

The PR108523 was too optimistic in replacing the same value with
an equivalence from a possibly not taken edge.  The following
rectifies this and instead refrains from using the equivalence in
the problematic cases.

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

PR tree-optimization/108574
* tree-ssa-sccvn.cc (visit_phi): Instead of swapping
sameval and def, ignore the equivalence if there's the
danger of oscillating between two values.

* gcc.dg/torture/pr108574-1.c: New testcase.
* gcc.dg/torture/pr108574-2.c: Likewise.
* gcc.dg/torture/pr108574-3.c: Likewise.
---
 gcc/testsuite/gcc.dg/torture/pr108574-1.c | 19 
 gcc/testsuite/gcc.dg/torture/pr108574-2.c | 25 +
 gcc/testsuite/gcc.dg/torture/pr108574-3.c | 27 +++
 gcc/tree-ssa-sccvn.cc | 11 +
 4 files changed, 76 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr108574-1.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr108574-2.c
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr108574-3.c

diff --git a/gcc/testsuite/gcc.dg/torture/pr108574-1.c 
b/gcc/testsuite/gcc.dg/torture/pr108574-1.c
new file mode 100644
index 000..7066b5ee2a2
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr108574-1.c
@@ -0,0 +1,19 @@
+/* { dg-do run } */
+
+int a = 1, b, c = 2, d;
+int main() {
+  if (b)
+goto L2;
+ L1:
+  {
+int e = c;
+a = 1 % a;
+while (e && 1 <= d)
+  ;
+d >= b;
+  L2:
+if (1 >= e)
+  goto L1;
+  }
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/torture/pr108574-2.c 
b/gcc/testsuite/gcc.dg/torture/pr108574-2.c
new file mode 100644
index 000..1e38d087646
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr108574-2.c
@@ -0,0 +1,25 @@
+/* { dg-do run } */
+
+int a, b, c, d, e, f, g = -1, h;
+void l() {
+  if (!e)
+goto i;
+  for (; g; g++) {
+b = ~d;
+int j = 0, k = 1;
+if (k && (b || f))
+  j = b;
+  i:
+a = ~j;
+  }
+}
+int main() {
+  h = 3;
+  for (; h; h--) {
+e = 1;
+int m = ~a, n = 1 % m;
+c = n;
+l();
+  }
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/torture/pr108574-3.c 
b/gcc/testsuite/gcc.dg/torture/pr108574-3.c
new file mode 100644
index 000..3c9146e31ac
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr108574-3.c
@@ -0,0 +1,27 @@
+/* { dg-do run } */
+
+int a = 3557301289, d;
+char b, f;
+unsigned short c = 241;
+short e, g;
+static void h() {
+  if (!a)
+goto i;
+  b = a;
+  for (; a < 2; a = b) {
+unsigned short j;
+if (c || !g) {
+  j = c;
+i:
+  e = j;
+}
+f = j;
+d = ~(f & ~2880764155);
+while (d > -2316069)
+  ;
+  }
+}
+int main() {
+  h();
+  return 0;
+}
diff --git a/gcc/tree-ssa-sccvn.cc b/gcc/tree-ssa-sccvn.cc
index edb553b07cb..028bedbc9a0 100644
--- a/gcc/tree-ssa-sccvn.cc
+++ b/gcc/tree-ssa-sccvn.cc
@@ -5908,7 +5908,8 @@ visit_phi (gimple *phi, bool *inserted, bool 
backedges_varying_p)
if (! val && vnresult && vnresult->predicated_values)
  {
val = vn_nary_op_get_predicated_value (vnresult, e->src);
-   if (val && integer_truep (val))
+   if (val && integer_truep (val)
+   && !(sameval_e && (sameval_e->flags & EDGE_DFS_BACK)))
  {
if (dump_file && (dump_flags & TDF_DETAILS))
  {
@@ -5919,8 +5920,6 @@ visit_phi (gimple *phi, bool *inserted, bool 
backedges_varying_p)
fprintf (dump_file, " are equal on edge %d -> %d\n",
 e->src->index, e->dest->index);
  }
-   if (sameval_e && (sameval_e->flags & EDGE_DFS_BACK))
- sameval = def;
continue;
  }
/* If on all previous edges the value was equal to def
@@ -5928,7 +5927,8 @@ visit_phi (gimple *phi, bool *inserted, bool 
backedges_varying_p)
if (EDGE_COUNT (bb->preds) == 2
&& (val = vn_nary_op_get_predicated_value
(vnresult, EDGE_PRED (bb, 0)->src))
-   && integer_truep (val))
+   && integer_truep (val)
+   && !(e->flags & EDGE_DFS_BACK))
  {
if (dump_file && (dump_flags & TDF_DETAILS))
  {
@@ -5940,8 +5940,7 @@ visit_phi (gimple *phi, bool *inserted, bool 
backedges_varying_p)
 EDGE_PRED (bb, 0)->src->index,
 EDGE_PRED (bb, 0)->dest->index);
  }
-   if (!(e->flags & EDGE_DFS_BACK))
- sameval = def;
+   sameval = def;
  

[PATCH] ipa/108511 - relax assert for undefined local statics

[Richard Biener via Gcc-patches]

Since we no longer promote undefined local statics extern the
assert in possibly_call_in_translation_unit_p triggers.  The
following relaxes it according to Honzas advice.

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

PR ipa/108511
* cgraph.cc (possibly_call_in_translation_unit_p): Relax
assert.
---
 gcc/cgraph.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/cgraph.cc b/gcc/cgraph.cc
index b810237c919..06bc980fa52 100644
--- a/gcc/cgraph.cc
+++ b/gcc/cgraph.cc
@@ -4183,7 +4183,7 @@ cgraph_edge::possibly_call_in_translation_unit_p (void)
 node = node->previous_sharing_asm_name;
   if (node->previous_sharing_asm_name)
 node = symtab_node::get_for_asmname (DECL_ASSEMBLER_NAME (callee->decl));
-  gcc_assert (TREE_PUBLIC (node->decl));
+  gcc_assert (TREE_PUBLIC (node->decl) || DECL_EXTERNAL (node->decl));
   return node->get_availability () >= AVAIL_INTERPOSABLE;
 }
 
-- 
2.35.3