Re: Re: [PATCH v3] RISC-V:Optimize the MASK opt generation

2023-09-06 Thread Kito Cheng via Gcc-patches
I saw RVC has MASK_RVC and TARGET_RVC in options.h?

On Wed, Sep 6, 2023 at 2:39 PM Feng Wang  wrote:
>
> According to the doc, take“Mask(VECTOR_ELEN_32)
> Var(riscv_vector_elen_flags)”as example,
> it just generates the OPTION_MASK_VECTOR_ELEN_32, will not generate 
> MASK_VECTOR_ELEN_32
> and TARGET_VECTOR_ELEN_32.
> Do you want to use "MASK(name) Var(other_flags)" to generate the MASK and 
> TARGET Macro?
> I think it will change a lot of code and the original meaning is changed.
> --
> Feng Wang
> >Reading the manual again, it seems I missed something in the manual
> >before, the MASK syntax already says we can specify Var to select the
> >variable other than target_flags, but I tried that not work when we
> >only declare Mask with Var (e.g. "Mask(VECTOR_ELEN_32)
> >Var(riscv_vector_elen_flags)" still using target_flags)
> >
> >So maybe we should just fix that instead of extending the syntax?
> >e.g.
> >Mask(VECTOR_ELEN_32)Var(riscv_vector_elen_flags)
> >rather than
> >Mask(VECTOR_ELEN_32)in TargetVariable(riscv_vector_elen_flags)
> >
> >
> >On Wed, Sep 6, 2023 at 10:03 AM Feng Wang  
> >wrote:
> >>
> >> This patch rebases the change of "[PATCH] RISC-V: Optimize the MASK opt
> >> generation" and add the new explanation in the options.texi.
> >> Please check the detail info on the
> >> "https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg302295.html";
> >> gcc/ChangeLog:
> >>
> >> * config/riscv/riscv-opts.h (MASK_ZICSR):
> >> (MASK_ZIFENCEI): Delete;
> >> (MASK_ZIHINTNTL):Ditto;
> >> (MASK_ZIHINTPAUSE):  Ditto;
> >> (TARGET_ZICSR):  Ditto;
> >> (TARGET_ZIFENCEI):   Ditto;
> >> (TARGET_ZIHINTNTL):  Ditto;
> >> (TARGET_ZIHINTPAUSE):Ditto;
> >> (MASK_ZAWRS):Ditto;
> >> (TARGET_ZAWRS):  Ditto;
> >> (MASK_ZBA):  Ditto;
> >> (MASK_ZBB):  Ditto;
> >> (MASK_ZBC):  Ditto;
> >> (MASK_ZBS):  Ditto;
> >> (TARGET_ZBA):Ditto;
> >> (TARGET_ZBB):Ditto;
> >> (TARGET_ZBC):Ditto;
> >> (TARGET_ZBS):Ditto;
> >> (MASK_ZFINX):Ditto;
> >> (MASK_ZDINX):Ditto;
> >> (MASK_ZHINX):Ditto;
> >> (MASK_ZHINXMIN): Ditto;
> >> (TARGET_ZFINX):  Ditto;
> >> (TARGET_ZDINX):  Ditto;
> >> (TARGET_ZHINX):  Ditto;
> >> (TARGET_ZHINXMIN):   Ditto;
> >> (MASK_ZBKB): Ditto;
> >> (MASK_ZBKC): Ditto;
> >> (MASK_ZBKX): Ditto;
> >> (MASK_ZKNE): Ditto;
> >> (MASK_ZKND): Ditto;
> >> (MASK_ZKNH): Ditto;
> >> (MASK_ZKR):  Ditto;
> >> (MASK_ZKSED):Ditto;
> >> (MASK_ZKSH): Ditto;
> >> (MASK_ZKT):  Ditto;
> >> (TARGET_ZBKB):   Ditto;
> >> (TARGET_ZBKC):   Ditto;
> >> (TARGET_ZBKX):   Ditto;
> >> (TARGET_ZKNE):   Ditto;
> >> (TARGET_ZKND):   Ditto;
> >> (TARGET_ZKNH):   Ditto;
> >> (TARGET_ZKR):Ditto;
> >> (TARGET_ZKSED):  Ditto;
> >> (TARGET_ZKSH):   Ditto;
> >> (TARGET_ZKT):Ditto;
> >> (MASK_ZTSO): Ditto;
> >> (TARGET_ZTSO):   Ditto;
> >> (MASK_VECTOR_ELEN_32):   Ditto;
> >> (MASK_VECTOR_ELEN_64):   Ditto;
> >> (MASK_VECTOR_ELEN_FP_32):Ditto;
> >> (MASK_VECTOR_ELEN_FP_64):Ditto;
> >> (MASK_VECTOR_ELEN_FP_16):Ditto;
> >> (TARGET_VECTOR_ELEN_32): Ditto;
> >> (TARGET_VECTOR_ELEN_64): Ditto;
> >> (TARGET_VECTOR_ELEN_FP_32):Ditto;
> >> (TARGET_VECTOR_ELEN_FP_64):Ditto;
> >> (TARGET_VECTOR_ELEN_FP_16):Ditto;
> >>  (MASK_ZVBB):   Ditto;
> >> (MASK_ZVBC):   Ditto;
> >> (TARGET_ZVBB): Ditto;
> >> (TARGET_ZVBC): Ditto;
> >> (MASK_ZVKG):   Ditto;
> >> (MASK_ZVKNED): Ditto;
> >> (MASK_ZVKNHA): Ditto;
> >> (MASK_ZVKNHB): Ditto;
> >> (MASK_ZVKSED): Ditto;
> >> (MASK_ZVKSH):  Ditto;
> >> (MASK_ZVKN):   Ditto;
> >> (MASK_ZVKNC):  Ditto;
> >> (MASK_ZVKNG):  Ditto;
> >> (MASK_ZVKS):   Ditto;
> >> (MASK_ZVKSC):  Ditto;
> >> (MASK_ZVKSG):  Ditto;
> >> (MASK_ZVKT):   Ditto;
> >> (TARGET_ZVKG): Ditto;
> >> (TARGET_ZVKNED):   Ditto;
> >> (TARGET_ZVKNHA):   Ditto;
> >> (TARGET_ZVKNHB):   Ditto;
> >> (TARGET_ZVKSED):   Ditto;
> >> (TARGET_ZVKSH):Ditto;
> >> (TARGET_ZVKN): Ditto;
> >> (TARGET_ZVKNC):Ditto;
> >> (TARGET_ZVKNG):Ditto;
> >>   

Re: Re: [PATCH 2/2] [RISC-V] Enalble zcmp for -Os

2023-09-06 Thread Kito Cheng via Gcc-patches
On Wed, Sep 6, 2023 at 9:47 AM Fei Gao  wrote:
>
> On 2023-09-05 20:02  Kito Cheng  wrote:
> >
> >> @@ -5569,7 +5571,9 @@ riscv_avoid_multi_push (const struct 
> >> riscv_frame_info *frame)
> >>  {
> >>if (!TARGET_ZCMP || crtl->calls_eh_return || frame_pointer_needed
> >>|| cfun->machine->interrupt_handler_p || 
> >> cfun->machine->varargs_size != 0
> >> -  || crtl->args.pretend_args_size != 0 || flag_shrink_wrap_separate
> >> +  || crtl->args.pretend_args_size != 0
> >> +  || (use_shrink_wrapping_separate ()
> >> + && !riscv_avoid_shrink_wrapping_separate ())
> >
> >I think we should also check "!optimize_function_for_size_p (cfun)"
> >here, otherwise that does not really match what we claim in the commit
> >message.
> >
> A similar check optimize_function_for_speed_p is included in
> use_shrink_wrapping_separate of [1/2] allow targets to check
> shrink-wrap-separate enabled or not.
>
> >e.g. it still will enable with -O2 -fno-shrink-wrap-separate
> It's intentional to enable zcmp with -O2 -fno-shrink-wrap-separate.
> Maybe I should have given a better commit message saying
> "enable muti push and pop for Zcmp extension when
> shrink-wrap-separate is inactive".
>
> Would you like a new patch from me or agree with my
> explanation and modify commit message in your side?

Could you send a new patch with updated commit message.


>
> BR
> Fei
> >
> >>|| (frame->mask & ~MULTI_PUSH_GPR_MASK))
> >>  return true;
> >>
>


Re: [PATCH] RISC-V: Add conditional sqrt autovec pattern

2023-09-06 Thread Kito Cheng via Gcc-patches
Got failed on the trunk, could you take a look?

=== gcc: Unexpected fails for rv32imafdc ilp32d medlow ===
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
   === gcc: Unexpected fails for rv64imac lp64 medlow ===
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL:

Re: [PATCH] RISC-V: Add conditional sqrt autovec pattern

2023-09-06 Thread Lehua Ding

Okay, I'll take a look at it right away. Thanks reporting.

On 2023/9/6 16:17, Kito Cheng via Gcc-patches wrote:

Got failed on the trunk, could you take a look?

 === gcc: Unexpected fails for rv32imafdc ilp32d medlow ===
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-2.c
scan-assembler-times \\tvfsqrt\\.v\\tv[0-9]+,v[0-9]+,v0\\.t 3
=== gcc: Unexpected fails for rv64imac lp64 medlow ===
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target/riscv/rvv/autovec/cond/cond_sqrt-1.c scan-assembler
\\tvsetvli\\t[a-z0-9]+,[a-z0-9]+,e[0-9]+,m[f0-9]+,t[au],mu
FAIL: gcc.target

Re: [PATCH V5 0/3] RISC-V: Add an experimental vector calling convention

2023-09-06 Thread Kito Cheng via Gcc-patches
Pushed to trunk with few testcase modifications, e.g. adding { target
{ riscv_vector } } to dg-run and adding -march / -mabi for compile
tests.

On Tue, Sep 5, 2023 at 4:18 PM Kito Cheng  wrote:
>
> Thanks for fixing the issue! I guess I could find time tonight to do
> the final round review and test :P then we could land this patch this
> week.
>
> On Tue, Sep 5, 2023 at 3:45 PM Lehua Ding  wrote:
> >
> > V5 change: Rebase and fix vsetvl testcase fail by change
> > `(unspec [...] UNSPEC_CALLEE_CC)` to `(use (unspec [...] 
> > UNSPEC_CALLEE_CC))`.
> > This change makes single_set function re-think call_insn as a
> > single set pattern.
> >
> > Hi RISC-V folks,
> >
> > This patch implement the proposal of RISC-V vector calling convention[1] and
> > this feature can be enabled by `--param=riscv-vector-abi` option. Currently,
> > all vector type arguments and return values are pass by reference. With this
> > patch, these arguments and return values can pass through vector registers.
> > Currently only vector types defined in the RISC-V Vector Extension 
> > Intrinsic Document[2]
> > are supported. GNU-ext vector types are unsupported for now since the
> > corresponding proposal was not presented.
> >
> > The proposal introduce a new calling convention variant, functions which 
> > follow
> > this variant need follow the bellow vector register convention.
> >
> > | Name| ABI Mnemonic | Meaning  | Preserved across 
> > calls?
> > =
> > | v0  |  | Argument register| No
> > | v1-v7   |  | Callee-saved registers   | Yes
> > | v8-v23  |  | Argument registers   | No
> > | v24-v31 |  | Callee-saved registers   | Yes
> >
> > If a functions follow this vector calling convention, then the function 
> > symbole
> > must be annotated with .variant_cc directive[3] (used to indicate that it 
> > is a
> > calling convention variant).
> >
> > This implementation split into three parts, each part corresponds to a 
> > sub-patch.
> >
> > - Part-1: Select suitable vector regsiters for vector type arguments and 
> > return
> >   values according to the proposal.
> > - Part-2: Allocate frame area for callee-saved vector registers and 
> > save/restore
> >   them in prologue and epilogue.
> > - Part-3: Generate .variant_cc directive for vector function in assembly 
> > code.
> >
> > [1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/389
> > [2] 
> > https://github.com/riscv-non-isa/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md#type-system
> > [3] 
> > https://github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm.md#pseudo-ops
> >
> > Best,
> > Lehua
> >
> > Lehua Ding (3):
> >   RISC-V: Part-1: Select suitable vector registers for vector type args
> > and returns
> >   RISC-V: Part-2: Save/Restore vector registers which need to be
> > preversed
> >   RISC-V: Part-3: Output .variant_cc directive for vector function
> >
> >  gcc/config/riscv/riscv-protos.h   |   4 +
> >  gcc/config/riscv/riscv-sr.cc  |   8 +-
> >  gcc/config/riscv/riscv-vector-builtins.cc |  10 +
> >  gcc/config/riscv/riscv.cc | 484 --
> >  gcc/config/riscv/riscv.h  |  43 ++
> >  gcc/config/riscv/riscv.md |  51 +-
> >  gcc/config/riscv/riscv.opt|   5 +
> >  .../riscv/rvv/base/abi-call-args-1-run.c  | 127 +
> >  .../riscv/rvv/base/abi-call-args-1.c  | 197 +++
> >  .../riscv/rvv/base/abi-call-args-2-run.c  |  34 ++
> >  .../riscv/rvv/base/abi-call-args-2.c  |  27 +
> >  .../riscv/rvv/base/abi-call-args-3-run.c  | 260 ++
> >  .../riscv/rvv/base/abi-call-args-3.c  | 116 +
> >  .../riscv/rvv/base/abi-call-args-4-run.c  | 145 ++
> >  .../riscv/rvv/base/abi-call-args-4.c  | 111 
> >  .../riscv/rvv/base/abi-call-error-1.c |  11 +
> >  .../riscv/rvv/base/abi-call-return-run.c  | 127 +
> >  .../riscv/rvv/base/abi-call-return.c  | 197 +++
> >  .../riscv/rvv/base/abi-call-variant_cc.c  |  39 ++
> >  .../rvv/base/abi-callee-saved-1-fixed-1.c |  86 
> >  .../rvv/base/abi-callee-saved-1-fixed-2.c |  86 
> >  .../base/abi-callee-saved-1-save-restore.c|  85 +++
> >  .../riscv/rvv/base/abi-callee-saved-1-zcmp.c  |  85 +++
> >  .../riscv/rvv/base/abi-callee-saved-1.c   |  88 
> >  .../base/abi-callee-saved-2-save-restore.c| 108 
> >  .../riscv/rvv/base/abi-callee-saved-2-zcmp.c  | 107 
> >  .../riscv/rvv/base/abi-callee-saved-2.c   | 117 +
> >  27 files changed, 2709 insertions(+), 49 deletions(-)
> >  create mode 100644 
> > gcc/testsuite/gcc.target/riscv/rvv/base/abi-call-args-1-run.c
> >  create mode 100644 
> > gcc/testsuite/gcc.target/riscv/rvv/base/abi-call-args-1.c
> >  create mode 100

Re: [PATCH] RISC-V: Keep vlmax vector operators in simple form until split1 pass

2023-09-06 Thread Kito Cheng via Gcc-patches
Thanks for explaining, LGTM :)


On Mon, Sep 4, 2023 at 11:39 PM Lehua Ding  wrote:
>
> Hi Kito,
>
> > Can those intermediate patterns be used for intrinsic? I would prefer
> > to keep those stuff *IF* possible used for intrinsics.
>
> I think we don't need those patterns for intrinisc. First, the deleted
> pattern does not directly correspond to intrinisc. Second, if you want
> to use these patterns to optimize the following intrinisc program (e.g.
> combine to a single vwadd.vv instruction), we'd better fold them
> directly into the internal function of autovec in Gimple IR.
>
>vint32m1_t foo(vint16mf2_t va1, vint16mf2_t vb1) {
>  vint32m1_t va2 = __riscv_vsext_vf2_i32m1(va1,
> __riscv_vsetvlmax_e32m1());
>  vint32m1_t vb2 = __riscv_vsext_vf2_i32m1(vb1,
> __riscv_vsetvlmax_e32m1());
>  vint32m1_t vc = __riscv_vadd_vv_i32m1(va2, vb2,
> __riscv_vsetvlmax_e32m1());
>  return vc;
>}
> --
> Best,
> Lehua
>
>


[PATCH 1/5] OpenMP, NVPTX: memcpy[23]D bias correction

2023-09-06 Thread Julian Brown
This patch works around behaviour of the 2D and 3D memcpy operations in
the CUDA driver runtime.  Particularly in Fortran, the "base pointer"
of an array (used for either source or destination of a host/device copy)
may lie outside of data that is actually stored on the device.  The fix
is to make sure that we use the first element of data to be transferred
instead, and adjust parameters accordingly.

2023-09-05  Julian Brown  

libgomp/
* plugin/plugin-nvptx.c (GOMP_OFFLOAD_memcpy2d): Adjust parameters to
avoid out-of-bounds array checks in CUDA runtime.
(GOMP_OFFLOAD_memcpy3d): Likewise.
---
 libgomp/plugin/plugin-nvptx.c | 67 +++
 1 file changed, 67 insertions(+)

diff --git a/libgomp/plugin/plugin-nvptx.c b/libgomp/plugin/plugin-nvptx.c
index 00d4241ae02b..cefe288a8aab 100644
--- a/libgomp/plugin/plugin-nvptx.c
+++ b/libgomp/plugin/plugin-nvptx.c
@@ -1827,6 +1827,35 @@ GOMP_OFFLOAD_memcpy2d (int dst_ord, int src_ord, size_t 
dim1_size,
   data.srcXInBytes = src_offset1_size;
   data.srcY = src_offset0_len;
 
+  if (data.srcXInBytes != 0 || data.srcY != 0)
+{
+  /* Adjust origin to the actual array data, else the CUDA 2D memory
+copy API calls below may fail to validate source/dest pointers
+correctly (especially for Fortran where the "virtual origin" of an
+array is often outside the stored data).  */
+  if (src_ord == -1)
+   data.srcHost = (const void *) ((const char *) data.srcHost
+ + data.srcY * data.srcPitch
+ + data.srcXInBytes);
+  else
+   data.srcDevice += data.srcY * data.srcPitch + data.srcXInBytes;
+  data.srcXInBytes = 0;
+  data.srcY = 0;
+}
+
+  if (data.dstXInBytes != 0 || data.dstY != 0)
+{
+  /* As above.  */
+  if (dst_ord == -1)
+   data.dstHost = (void *) ((char *) data.dstHost
++ data.dstY * data.dstPitch
++ data.dstXInBytes);
+  else
+   data.dstDevice += data.dstY * data.dstPitch + data.dstXInBytes;
+  data.dstXInBytes = 0;
+  data.dstY = 0;
+}
+
   CUresult res = CUDA_CALL_NOCHECK (cuMemcpy2D, &data);
   if (res == CUDA_ERROR_INVALID_VALUE)
 /* If pitch > CU_DEVICE_ATTRIBUTE_MAX_PITCH or for device-to-device
@@ -1895,6 +1924,44 @@ GOMP_OFFLOAD_memcpy3d (int dst_ord, int src_ord, size_t 
dim2_size,
   data.srcY = src_offset1_len;
   data.srcZ = src_offset0_len;
 
+  if (data.srcXInBytes != 0 || data.srcY != 0 || data.srcZ != 0)
+{
+  /* Adjust origin to the actual array data, else the CUDA 3D memory
+copy API call below may fail to validate source/dest pointers
+correctly (especially for Fortran where the "virtual origin" of an
+array is often outside the stored data).  */
+  if (src_ord == -1)
+   data.srcHost
+ = (const void *) ((const char *) data.srcHost
+   + (data.srcZ * data.srcHeight + data.srcY)
+ * data.srcPitch
+   + data.srcXInBytes);
+  else
+   data.srcDevice
+ += (data.srcZ * data.srcHeight + data.srcY) * data.srcPitch
++ data.srcXInBytes;
+  data.srcXInBytes = 0;
+  data.srcY = 0;
+  data.srcZ = 0;
+}
+
+  if (data.dstXInBytes != 0 || data.dstY != 0 || data.dstZ != 0)
+{
+  /* As above.  */
+  if (dst_ord == -1)
+   data.dstHost = (void *) ((char *) data.dstHost
++ (data.dstZ * data.dstHeight + data.dstY)
+  * data.dstPitch
++ data.dstXInBytes);
+  else
+   data.dstDevice
+ += (data.dstZ * data.dstHeight + data.dstY) * data.dstPitch
++ data.dstXInBytes;
+  data.dstXInBytes = 0;
+  data.dstY = 0;
+  data.dstZ = 0;
+}
+
   CUDA_CALL (cuMemcpy3D, &data);
   return true;
 }
-- 
2.41.0



[PATCH 0/5] OpenMP: Array-shaping operator and strided/rectangular 'target update' support

2023-09-06 Thread Julian Brown
This patch series provides support for the OpenMP 5.0+ array-shaping
operator and for strided/rectangular updates for 'target update'
directives.  Each of C, C++ and Fortran is supported (using existing
base language syntax for the last).

This series applies on top of the "infrastructure" support series:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627895.html

and the lvalue parsing/declare mapper series:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629363.html

The og13 version of this series was posted here:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623502.html

This version of the series contains several follow-up fixes relative
to the og13 version, and omits some parts that are only present on the
branch for now.  Further comments on individual patches.

Tested with offloading to NVPTX and bootstrapped. OK?

Julian Brown (5):
  OpenMP, NVPTX: memcpy[23]D bias correction
  OpenMP: Allow complete replacement of clause during map/to/from
expansion
  OpenMP: Support strided and shaped-array updates for C++
  OpenMP: Array shaping operator and strided "target update" for C
  OpenMP: Noncontiguous "target update" for Fortran

 gcc/c-family/c-common.h   |  12 +-
 gcc/c-family/c-omp.cc | 277 --
 gcc/c-family/c-pretty-print.cc|   5 +
 gcc/c/c-parser.cc | 330 +++-
 gcc/c/c-tree.h|   6 +-
 gcc/c/c-typeck.cc | 281 --
 gcc/cp/cp-objcp-common.cc |   1 +
 gcc/cp/cp-tree.def|   1 +
 gcc/cp/cp-tree.h  |  13 +-
 gcc/cp/decl.cc|  75 +++
 gcc/cp/decl2.cc   |  19 +-
 gcc/cp/error.cc   |   5 +
 gcc/cp/mangle.cc  |   1 +
 gcc/cp/operators.def  |   1 +
 gcc/cp/parser.cc  | 303 ++-
 gcc/cp/parser.h   |   7 +
 gcc/cp/pt.cc  |  39 +-
 gcc/cp/semantics.cc   | 289 --
 gcc/cp/typeck.cc  |  12 +-
 gcc/fortran/openmp.cc |   5 +-
 gcc/fortran/trans-openmp.cc   | 499 ++
 gcc/gimplify.cc   |  54 +-
 gcc/omp-general.cc|  47 ++
 gcc/omp-general.h |   4 +-
 gcc/omp-low.cc| 476 -
 gcc/testsuite/g++.dg/gomp/array-shaping-1.C   |  22 +
 gcc/testsuite/g++.dg/gomp/array-shaping-2.C   | 134 +
 .../g++.dg/gomp/bad-array-shaping-1.C |  47 ++
 .../g++.dg/gomp/bad-array-shaping-2.C |  52 ++
 .../g++.dg/gomp/bad-array-shaping-3.C |  53 ++
 .../g++.dg/gomp/bad-array-shaping-4.C |  60 +++
 .../g++.dg/gomp/bad-array-shaping-5.C |  55 ++
 .../g++.dg/gomp/bad-array-shaping-6.C |  59 +++
 .../g++.dg/gomp/bad-array-shaping-7.C |  48 ++
 .../g++.dg/gomp/bad-array-shaping-8.C |  50 ++
 .../gcc.dg/gomp/bad-array-shaping-c-1.c   |  26 +
 .../gcc.dg/gomp/bad-array-shaping-c-2.c   |  24 +
 .../gcc.dg/gomp/bad-array-shaping-c-3.c   |  30 ++
 .../gcc.dg/gomp/bad-array-shaping-c-4.c   |  27 +
 .../gcc.dg/gomp/bad-array-shaping-c-5.c   |  17 +
 .../gcc.dg/gomp/bad-array-shaping-c-6.c   |  26 +
 .../gcc.dg/gomp/bad-array-shaping-c-7.c   |  15 +
 .../gfortran.dg/gomp/noncontig-updates-1.f90  |  19 +
 .../gfortran.dg/gomp/noncontig-updates-2.f90  |  16 +
 .../gfortran.dg/gomp/noncontig-updates-3.f90  |  16 +
 .../gfortran.dg/gomp/noncontig-updates-4.f90  |  15 +
 gcc/tree-pretty-print.cc  |  17 +
 gcc/tree.def  |   2 +-
 include/gomp-constants.h  |   7 +-
 libgomp/libgomp.h |  15 +
 libgomp/plugin/plugin-nvptx.c |  67 +++
 libgomp/target.c  | 271 +++---
 .../testsuite/libgomp.c++/array-shaping-1.C   | 469 
 .../testsuite/libgomp.c++/array-shaping-10.C  |  61 +++
 .../testsuite/libgomp.c++/array-shaping-11.C  |  63 +++
 .../testsuite/libgomp.c++/array-shaping-12.C  |  65 +++
 .../testsuite/libgomp.c++/array-shaping-13.C  |  89 
 .../testsuite/libgomp.c++/array-shaping-2.C   |  38 ++
 .../testsuite/libgomp.c++/array-shaping-3.C   |  38 ++
 .../testsuite/libgomp.c++/array-shaping-4.C   |  38 ++
 .../testsuite/libgomp.c++/array-shaping-5.C   |  38 ++
 .../testsuite/libgomp.c++/array-shaping-6.C   |  54 ++
 .../testsuite/libgomp.c++/array-shaping-7.C   |  54 ++
 .../testsuite/libgomp.c++/array-shaping-8.C   |  65 +++
 .../testsuite/libgomp.c++/array-shaping-9.C   |  95 
 .../libgomp.c-c++-common/array-shaping-14.c   |  34 ++
 libgomp/testsuite/libgo

[PATCH 2/5] OpenMP: Allow complete replacement of clause during map/to/from expansion

2023-09-06 Thread Julian Brown
At present, map/to/from clauses on OpenMP "target" directives may be
expanded into several mapping nodes if they describe array sections with
pointer or reference bases, or similar.  This patch allows the original
clause to be replaced during that expansion, mostly by passing the list
pointer to the node to various functions rather than the node itself.

This is needed by the following patch. There shouldn't be any functional
changes introduced by this patch itself.

2023-09-05  Julian Brown  

gcc/c-family/
* c-common.h (expand_array_base, expand_component_selector,
expand_map_clause): Adjust member declarations.
* c-omp.cc (omp_expand_access_chain): Pass and return pointer to
clause.
(c_omp_address_inspector::expand_array_base): Likewise.
(c_omp_address_inspector::expand_component_selector): Likewise.
(c_omp_address_inspector::expand_map_clause): Likewise.

gcc/c/
* c-typeck.cc (handle_omp_array_sections): Pass pointer to clause to
process instead of clause.
(c_finish_omp_clauses): Update calls to handle_omp_array_sections.
Handle cases where initial clause might be replaced.

gcc/cp/
* semantics.cc (handle_omp_array_sections): Pass pointer to clause
instead of clause.  Add PNEXT return parameter for next clause in list
to process.
(finish_omp_clauses): Update calls to handle_omp_array_sections.
Handle cases where initial clause might be replaced.
---
 gcc/c-family/c-common.h | 12 +++
 gcc/c-family/c-omp.cc   | 75 +
 gcc/c/c-typeck.cc   | 32 +++---
 gcc/cp/semantics.cc | 37 +---
 4 files changed, 88 insertions(+), 68 deletions(-)

diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index b4e49c7d0cbc..e2b85d394d32 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -1383,12 +1383,12 @@ public:
 
   bool maybe_zero_length_array_section (tree);
 
-  tree expand_array_base (tree, vec &, tree, unsigned *,
- c_omp_region_type, bool);
-  tree expand_component_selector (tree, vec &, tree,
- unsigned *);
-  tree expand_map_clause (tree, tree, vec &,
- c_omp_region_type);
+  tree * expand_array_base (tree *, vec &, tree, unsigned *,
+   c_omp_region_type, bool);
+  tree * expand_component_selector (tree *, vec &, tree,
+   unsigned *);
+  tree * expand_map_clause (tree *, tree, vec &,
+   c_omp_region_type);
 };
 
 enum c_omp_directive_kind {
diff --git a/gcc/c-family/c-omp.cc b/gcc/c-family/c-omp.cc
index b73f9682f460..3c6b79107edc 100644
--- a/gcc/c-family/c-omp.cc
+++ b/gcc/c-family/c-omp.cc
@@ -3331,11 +3331,12 @@ 
c_omp_address_inspector::maybe_zero_length_array_section (tree clause)
expression types here, because e.g. you can't have an array of
references.  See also gimplify.cc:omp_expand_access_chain.  */
 
-static tree
-omp_expand_access_chain (tree c, tree expr, vec &addr_tokens,
-unsigned *idx)
+static tree *
+omp_expand_access_chain (tree *pc, tree expr,
+vec &addr_tokens, unsigned *idx)
 {
   using namespace omp_addr_tokenizer;
+  tree c = *pc;
   location_t loc = OMP_CLAUSE_LOCATION (c);
   unsigned i = *idx;
   tree c2 = NULL_TREE;
@@ -3373,35 +3374,36 @@ omp_expand_access_chain (tree c, tree expr, 
vec &addr_tokens,
   break;
 
 default:
-  return error_mark_node;
+  return NULL;
 }
 
   if (c2)
 {
   OMP_CLAUSE_CHAIN (c2) = OMP_CLAUSE_CHAIN (c);
   OMP_CLAUSE_CHAIN (c) = c2;
-  c = c2;
+  pc = &OMP_CLAUSE_CHAIN (c);
 }
 
   *idx = ++i;
 
   if (i < addr_tokens.length ()
   && addr_tokens[i]->type == ACCESS_METHOD)
-return omp_expand_access_chain (c, expr, addr_tokens, idx);
+return omp_expand_access_chain (pc, expr, addr_tokens, idx);
 
-  return c;
+  return pc;
 }
 
 /* Translate "array_base_decl access_method" to OMP mapping clauses.  */
 
-tree
-c_omp_address_inspector::expand_array_base (tree c,
+tree *
+c_omp_address_inspector::expand_array_base (tree *pc,
vec &addr_tokens,
tree expr, unsigned *idx,
c_omp_region_type ort,
bool decl_p)
 {
   using namespace omp_addr_tokenizer;
+  tree c = *pc;
   location_t loc = OMP_CLAUSE_LOCATION (c);
   int i = *idx;
   tree decl = addr_tokens[i + 1]->expr;
@@ -3426,7 +3428,7 @@ c_omp_address_inspector::expand_array_base (tree c,
  || OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_DETACH))
 {
   *idx = ++i;
-  return c;
+  return pc;
 }
 
   switch (addr_tokens[i + 1]->u.access_kind)
@@ -3672,7 +3674,7 @@ c_omp_address_inspector::expand_array_base (tree c,
 
 def

[PATCH 5/5] OpenMP: Noncontiguous "target update" for Fortran

2023-09-06 Thread Julian Brown
This patch implements noncontiguous "target update" for Fortran.
The existing middle end/runtime bits relating to C and C++ support are
reused, with some small adjustments, e.g.:

  1. The node used to map the OMP "array descriptor" (from omp-low.cc
 onwards) now uses the OMP_CLAUSE_SIZE field as a bias (the difference
 between the "virtual origin" element with zero indices in each
 dimension and the first element actually stored in memory).

  2. The OMP_CLAUSE_SIZE field of a GOMP_MAP_DIM_STRIDE node may now be
 used to store a "span", which is the distance in bytes between
 two adjacent elements in an array (with unit stride) when that is
 different from the element size, as it can be in Fortran.

The implementation goes to some effort to massage Fortran array metadata
(array descriptors) into a form that can ultimately be consumed by
omp_target_memcpy_rect_worker. The method for doing this is described
in comments in the patch body.

This version of the patch has been rebased and contains some additional
minor fixes relative to the version posted for the og13 branch.

2023-09-05  Julian Brown  

gcc/fortran/
* openmp.cc (omp_verify_map_motion_clauses): Allow strided array
sections with 'omp target update'.
* trans-openmp.cc (gfc_trans_omp_arrayshape_type, gfc_omp_calculate_gcd,
gfc_desc_to_omp_noncontig_array, gfc_omp_contiguous_update_p): New
functions.
(gfc_trans_omp_clauses): Handle noncontiguous to/from clauses for OMP
"target update" directives.

gcc/
* gimplify.cc (gimplify_adjust_omp_clauses): Don't gimplify
VIEW_CONVERT_EXPR away in GOMP_MAP_TO_GRID/GOMP_MAP_FROM_GRID clauses.
* omp-low.cc (omp_noncontig_descriptor_type): Add SPAN field.
(scan_sharing_clauses): Don't store descriptor size in its
OMP_CLAUSE_SIZE field.
(lower_omp_target): Add missing OMP_CLAUSE_MAP check.  Add special-case
string handling.  Handle span and bias.  Use low bound instead of zero
as index for trailing full dimensions.

gcc/testsuite/
* gfortran.dg/gomp/noncontig-updates-1.f90: New test.
* gfortran.dg/gomp/noncontig-updates-2.f90: New test.
* gfortran.dg/gomp/noncontig-updates-3.f90: New test.
* gfortran.dg/gomp/noncontig-updates-4.f90: New test.

libgomp/
* libgomp.h (omp_noncontig_array_desc): Add span field.
* target.c (omp_target_memcpy_rect_worker): Add span parameter. Update
forward declaration. Handle span != element_size.
(gomp_update): Handle bias in descriptor's size slot.  Update calls to
omp_target_memcpy_rect_worker.
(omp_target_memcpy_rect_worker): Add element_size == span checks (to
existing stride == 1 check) to guard use of target plugin's 2D/3D
memcpy hooks.
* testsuite/libgomp.fortran/noncontig-updates-1.f90: New test.
* testsuite/libgomp.fortran/noncontig-updates-2.f90: New test.
* testsuite/libgomp.fortran/noncontig-updates-3.f90: New test.
* testsuite/libgomp.fortran/noncontig-updates-4.f90: New test.
* testsuite/libgomp.fortran/noncontig-updates-5.f90: New test.
* testsuite/libgomp.fortran/noncontig-updates-6.f90: New test.
* testsuite/libgomp.fortran/noncontig-updates-7.f90: New test.
* testsuite/libgomp.fortran/noncontig-updates-8.f90: New test.
* testsuite/libgomp.fortran/noncontig-updates-9.f90: New test.
* testsuite/libgomp.fortran/noncontig-updates-10.f90: New test.
* testsuite/libgomp.fortran/noncontig-updates-11.f90: New test.
* testsuite/libgomp.fortran/noncontig-updates-12.f90: New test.
* testsuite/libgomp.fortran/noncontig-updates-13.f90: New test.
---
 gcc/fortran/openmp.cc |   5 +-
 gcc/fortran/trans-openmp.cc   | 499 ++
 gcc/gimplify.cc   |  10 +
 gcc/omp-low.cc|  53 +-
 .../gfortran.dg/gomp/noncontig-updates-1.f90  |  19 +
 .../gfortran.dg/gomp/noncontig-updates-2.f90  |  16 +
 .../gfortran.dg/gomp/noncontig-updates-3.f90  |  16 +
 .../gfortran.dg/gomp/noncontig-updates-4.f90  |  15 +
 libgomp/libgomp.h |   1 +
 libgomp/target.c  |  57 +-
 .../libgomp.fortran/noncontig-updates-1.f90   |  54 ++
 .../libgomp.fortran/noncontig-updates-10.f90  |  29 +
 .../libgomp.fortran/noncontig-updates-11.f90  |  51 ++
 .../libgomp.fortran/noncontig-updates-12.f90  |  59 +++
 .../libgomp.fortran/noncontig-updates-13.f90  |  42 ++
 .../libgomp.fortran/noncontig-updates-2.f90   | 101 
 .../libgomp.fortran/noncontig-updates-3.f90   |  47 ++
 .../libgomp.fortran/noncontig-updates-4.f90   |  78 +++
 .../libgomp.fortran/noncontig-updates-5.f90   |  55 ++
 .../libgomp.fortran/noncontig-updates-6.f90   |  34 ++
 .../libgomp.fortran/noncontig-updates-7.f90   |  36 ++
 .../libgomp.fortran/noncon

[PATCH 4/5] OpenMP: Array shaping operator and strided "target update" for C

2023-09-06 Thread Julian Brown
Following the similar support for C++, here is the C implementation for
the OpenMP 5.0 array-shaping operator, and for strided and rectangular
updates for "target update".

Much of the implementation is shared with the C++ support added by the
previous patch.  Some details of parsing necessarily differ for C,
but the general ideas are the same.

This version of the patch has been rebased and contains a couple of
minor fixes relative to versions posted previously.

2023-09-05  Julian Brown  

gcc/c/
* c-parser.cc (c_parser_braced_init): Disallow array-shaping operator
in braced init.
(c_parser_conditional_expression): Disallow array-shaping operator in
conditional expression.
(c_parser_cast_expression): Add array-shaping operator support.
(c_parser_postfix_expression): Disallow array-shaping operator in
statement expressions.
(c_parser_postfix_expression_after_primary): Add OpenMP array section
stride support.
(c_parser_expr_list): Disallow array-shaping operator in expression
lists.
(c_array_type_nelts_top, c_array_type_nelts_total): New functions.
(c_parser_omp_variable_list): Support array-shaping operator.
(c_parser_omp_target_update): Recognize GOMP_MAP_TO_GRID and
GOMP_MAP_FROM_GRID map kinds as well as OMP_CLAUSE_TO/OMP_CLAUSE_FROM.
* c-tree.h (c_omp_array_shaping_op_p, c_omp_has_array_shape_p): New
extern declarations.
(create_omp_arrayshape_type): Add prototype.
* c-typeck.cc (c_omp_array_shaping_op_p, c_omp_has_array_shape_p): New
globals.
(build_omp_array_section): Permit integral types, not just integer
constants, when creating array types for array sections.
(create_omp_arrayshape_type): New function.
(handle_omp_array_sections_1): Add DISCONTIGUOUS parameter.  Add
strided/rectangular array section support.
(omp_array_section_low_bound): New function.
(handle_omp_array_sections): Add DISCONTIGUOUS parameter.  Add
strided/rectangular array section support.
(c_finish_omp_clauses): Update calls to handle_omp_array_sections.
Handle discontiguous updates.

gcc/testsuite/
* gcc.dg/gomp/bad-array-shaping-c-1.c: New test.
* gcc.dg/gomp/bad-array-shaping-c-2.c: New test.
* gcc.dg/gomp/bad-array-shaping-c-3.c: New test.
* gcc.dg/gomp/bad-array-shaping-c-4.c: New test.
* gcc.dg/gomp/bad-array-shaping-c-5.c: New test.
* gcc.dg/gomp/bad-array-shaping-c-6.c: New test.
* gcc.dg/gomp/bad-array-shaping-c-7.c: New test.

libgomp/
* testsuite/libgomp.c/array-shaping-1.c: New test.
* testsuite/libgomp.c/array-shaping-2.c: New test.
* testsuite/libgomp.c/array-shaping-3.c: New test.
* testsuite/libgomp.c/array-shaping-4.c: New test.
* testsuite/libgomp.c/array-shaping-5.c: New test.
* testsuite/libgomp.c/array-shaping-6.c: New test.
---
 gcc/c/c-parser.cc | 300 +-
 gcc/c/c-tree.h|   4 +
 gcc/c/c-typeck.cc | 235 --
 .../gcc.dg/gomp/bad-array-shaping-c-1.c   |  26 ++
 .../gcc.dg/gomp/bad-array-shaping-c-2.c   |  24 ++
 .../gcc.dg/gomp/bad-array-shaping-c-3.c   |  30 ++
 .../gcc.dg/gomp/bad-array-shaping-c-4.c   |  27 ++
 .../gcc.dg/gomp/bad-array-shaping-c-5.c   |  17 +
 .../gcc.dg/gomp/bad-array-shaping-c-6.c   |  26 ++
 .../gcc.dg/gomp/bad-array-shaping-c-7.c   |  15 +
 libgomp/testsuite/libgomp.c/array-shaping-1.c | 236 ++
 libgomp/testsuite/libgomp.c/array-shaping-2.c |  39 +++
 libgomp/testsuite/libgomp.c/array-shaping-3.c |  42 +++
 libgomp/testsuite/libgomp.c/array-shaping-4.c |  36 +++
 libgomp/testsuite/libgomp.c/array-shaping-5.c |  38 +++
 libgomp/testsuite/libgomp.c/array-shaping-6.c |  45 +++
 16 files changed, 1097 insertions(+), 43 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/gomp/bad-array-shaping-c-1.c
 create mode 100644 gcc/testsuite/gcc.dg/gomp/bad-array-shaping-c-2.c
 create mode 100644 gcc/testsuite/gcc.dg/gomp/bad-array-shaping-c-3.c
 create mode 100644 gcc/testsuite/gcc.dg/gomp/bad-array-shaping-c-4.c
 create mode 100644 gcc/testsuite/gcc.dg/gomp/bad-array-shaping-c-5.c
 create mode 100644 gcc/testsuite/gcc.dg/gomp/bad-array-shaping-c-6.c
 create mode 100644 gcc/testsuite/gcc.dg/gomp/bad-array-shaping-c-7.c
 create mode 100644 libgomp/testsuite/libgomp.c/array-shaping-1.c
 create mode 100644 libgomp/testsuite/libgomp.c/array-shaping-2.c
 create mode 100644 libgomp/testsuite/libgomp.c/array-shaping-3.c
 create mode 100644 libgomp/testsuite/libgomp.c/array-shaping-4.c
 create mode 100644 libgomp/testsuite/libgomp.c/array-shaping-5.c
 create mode 100644 libgomp/testsuite/libgomp.c/array-shaping-6.c

diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index be80c2723ef0..1c28f763c8a0 100644
--- a/gc

[PATCH 1/2] allow targets to check shrink-wrap-separate enabled or not

2023-09-06 Thread Fei Gao
No functional changes but restructure and expose use_shrink_wrapping_separate
to the TARGETs.

gcc/ChangeLog:

* shrink-wrap.cc (try_shrink_wrapping_separate):call
  use_shrink_wrapping_separate.
(use_shrink_wrapping_separate): wrap the condition
  check in use_shrink_wrapping_separate.
* shrink-wrap.h (use_shrink_wrapping_separate): add to extern
---
 gcc/shrink-wrap.cc | 22 +++---
 gcc/shrink-wrap.h  |  1 +
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/gcc/shrink-wrap.cc b/gcc/shrink-wrap.cc
index b8d7b557130..28301f04f89 100644
--- a/gcc/shrink-wrap.cc
+++ b/gcc/shrink-wrap.cc
@@ -1776,16 +1776,13 @@ insert_prologue_epilogue_for_components (sbitmap 
components)
   commit_edge_insertions ();
 }
 
-/* The main entry point to this subpass.  FIRST_BB is where the prologue
-   would be normally put.  */
-void
-try_shrink_wrapping_separate (basic_block first_bb)
+bool
+use_shrink_wrapping_separate (void)
 {
-  if (!(SHRINK_WRAPPING_ENABLED
-   && flag_shrink_wrap_separate
+  if (!(SHRINK_WRAPPING_ENABLED && flag_shrink_wrap_separate
&& optimize_function_for_speed_p (cfun)
&& targetm.shrink_wrap.get_separate_components))
-return;
+return false;
 
   /* We don't handle "strange" functions.  */
   if (cfun->calls_alloca
@@ -1794,6 +1791,17 @@ try_shrink_wrapping_separate (basic_block first_bb)
   || crtl->calls_eh_return
   || crtl->has_nonlocal_goto
   || crtl->saves_all_registers)
+return false;
+
+  return true;
+}
+
+/* The main entry point to this subpass.  FIRST_BB is where the prologue
+   would be normally put.  */
+void
+try_shrink_wrapping_separate (basic_block first_bb)
+{
+  if (!use_shrink_wrapping_separate ())
 return;
 
   /* Ask the target what components there are.  If it returns NULL, don't
diff --git a/gcc/shrink-wrap.h b/gcc/shrink-wrap.h
index 161647711a3..82386c2b712 100644
--- a/gcc/shrink-wrap.h
+++ b/gcc/shrink-wrap.h
@@ -26,6 +26,7 @@ along with GCC; see the file COPYING3.  If not see
 extern bool requires_stack_frame_p (rtx_insn *, HARD_REG_SET, HARD_REG_SET);
 extern void try_shrink_wrapping (edge *entry_edge, rtx_insn *prologue_seq);
 extern void try_shrink_wrapping_separate (basic_block first_bb);
+extern bool use_shrink_wrapping_separate (void);
 #define SHRINK_WRAPPING_ENABLED \
   (flag_shrink_wrap && targetm.have_simple_return ())
 
-- 
2.17.1



[PATCH 0/2] resolve confilct between zcmp multi push/pop and shrink-wrap-separate

2023-09-06 Thread Fei Gao
Enable muti push and pop for Zcmp when shrink-wrap-separate is ineffective.

Fei Gao (2):
  allow targets to check shrink-wrap-separate enabled or not
  [V2][RISC-V] enable muti push and pop for Zcmp when shrink-wrap-separate is 
ineffective

 gcc/config/riscv/riscv.cc | 21 -
 gcc/shrink-wrap.cc| 22 +++--
 gcc/shrink-wrap.h |  1 +
 gcc/testsuite/gcc.target/riscv/rv32e_zcmp.c   |  2 +-
 gcc/testsuite/gcc.target/riscv/rv32i_zcmp.c   |  2 +-
 .../gcc.target/riscv/zcmp_push_fpr.c  |  2 +-
 .../riscv/zcmp_shrink_wrap_separate.c | 93 +++
 .../riscv/zcmp_shrink_wrap_separate2.c| 93 +++
 .../gcc.target/riscv/zcmp_stack_alignment.c   |  2 +-
 9 files changed, 223 insertions(+), 15 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/zcmp_shrink_wrap_separate.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zcmp_shrink_wrap_separate2.c

-- 
2.17.1



[PATCH 2/2] [V2][RISC-V] enable muti push and pop for Zcmp when shrink-wrap-separate is ineffective

2023-09-06 Thread Fei Gao
So that zcmp can be enabled in -Os where
shrink-wrap-separate is not effective.

To force enabling zcmp multi push/pop in speed perfered case,
fno-shrink-wrap-separate has to be explictly given.

gcc/ChangeLog:

* config/riscv/riscv.cc 
(riscv_avoid_shrink_wrapping_separate): wrap the condition check in
riscv_avoid_shrink_wrapping_separate.
(riscv_avoid_multi_push):avoid multi push if shrink_wrapping_separate
  is active.
(riscv_get_separate_components):call 
riscv_avoid_shrink_wrapping_separate

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rv32e_zcmp.c: remove -fno-shrink-wrap-separate
* gcc.target/riscv/rv32i_zcmp.c: likewise
* gcc.target/riscv/zcmp_push_fpr.c: likewise
* gcc.target/riscv/zcmp_stack_alignment.c: likewise
* gcc.target/riscv/zcmp_shrink_wrap_separate.c: New test.
* gcc.target/riscv/zcmp_shrink_wrap_separate2.c: New test.
---
 gcc/config/riscv/riscv.cc | 21 -
 gcc/testsuite/gcc.target/riscv/rv32e_zcmp.c   |  2 +-
 gcc/testsuite/gcc.target/riscv/rv32i_zcmp.c   |  2 +-
 .../gcc.target/riscv/zcmp_push_fpr.c  |  2 +-
 .../riscv/zcmp_shrink_wrap_separate.c | 93 +++
 .../riscv/zcmp_shrink_wrap_separate2.c| 93 +++
 .../gcc.target/riscv/zcmp_stack_alignment.c   |  2 +-
 7 files changed, 207 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/zcmp_shrink_wrap_separate.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zcmp_shrink_wrap_separate2.c

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 78600ba73b6..3f71000c88b 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -64,6 +64,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "cfghooks.h"
 #include "cfgloop.h"
 #include "cfgrtl.h"
+#include "shrink-wrap.h"
 #include "sel-sched.h"
 #include "sched-int.h"
 #include "fold-const.h"
@@ -372,6 +373,7 @@ static const struct riscv_tune_param 
optimize_size_tune_info = {
   false,   /* use_divmod_expansion */
 };
 
+static bool riscv_avoid_shrink_wrapping_separate ();
 static tree riscv_handle_fndecl_attribute (tree *, tree, tree, int, bool *);
 static tree riscv_handle_type_attribute (tree *, tree, tree, int, bool *);
 
@@ -5569,7 +5571,9 @@ riscv_avoid_multi_push (const struct riscv_frame_info 
*frame)
 {
   if (!TARGET_ZCMP || crtl->calls_eh_return || frame_pointer_needed
   || cfun->machine->interrupt_handler_p || cfun->machine->varargs_size != 0
-  || crtl->args.pretend_args_size != 0 || flag_shrink_wrap_separate
+  || crtl->args.pretend_args_size != 0
+  || (use_shrink_wrapping_separate ()
+ && !riscv_avoid_shrink_wrapping_separate ())
   || (frame->mask & ~MULTI_PUSH_GPR_MASK))
 return true;
 
@@ -6831,6 +6835,17 @@ riscv_epilogue_uses (unsigned int regno)
   return false;
 }
 
+static bool
+riscv_avoid_shrink_wrapping_separate ()
+{
+  if (riscv_use_save_libcall (&cfun->machine->frame)
+  || cfun->machine->interrupt_handler_p
+  || !cfun->machine->frame.gp_sp_offset.is_constant ())
+return true;
+
+  return false;
+}
+
 /* Implement TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS.  */
 
 static sbitmap
@@ -6840,9 +6855,7 @@ riscv_get_separate_components (void)
   sbitmap components = sbitmap_alloc (FIRST_PSEUDO_REGISTER);
   bitmap_clear (components);
 
-  if (riscv_use_save_libcall (&cfun->machine->frame)
-  || cfun->machine->interrupt_handler_p
-  || !cfun->machine->frame.gp_sp_offset.is_constant ())
+  if (riscv_avoid_shrink_wrapping_separate ())
 return components;
 
   offset = cfun->machine->frame.gp_sp_offset.to_constant ();
diff --git a/gcc/testsuite/gcc.target/riscv/rv32e_zcmp.c 
b/gcc/testsuite/gcc.target/riscv/rv32e_zcmp.c
index 394459c4ed7..50e443573ad 100644
--- a/gcc/testsuite/gcc.target/riscv/rv32e_zcmp.c
+++ b/gcc/testsuite/gcc.target/riscv/rv32e_zcmp.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options " -Os -march=rv32e_zca_zcmp -mabi=ilp32e -mcmodel=medlow 
-fno-shrink-wrap-separate" } */
+/* { dg-options " -Os -march=rv32e_zca_zcmp -mabi=ilp32e -mcmodel=medlow" } */
 /* { dg-skip-if "" { *-*-* } {"-O0" "-O1" "-O2" "-Og" "-O3" "-Oz" "-flto"} } */
 /* { dg-final { check-function-bodies "**" "" } } */
 
diff --git a/gcc/testsuite/gcc.target/riscv/rv32i_zcmp.c 
b/gcc/testsuite/gcc.target/riscv/rv32i_zcmp.c
index f00338a9d17..ea562b7a233 100644
--- a/gcc/testsuite/gcc.target/riscv/rv32i_zcmp.c
+++ b/gcc/testsuite/gcc.target/riscv/rv32i_zcmp.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options " -Os -march=rv32imaf_zca_zcmp -mabi=ilp32f -mcmodel=medlow 
-fno-shrink-wrap-separate" }*/
+/* { dg-options " -Os -march=rv32imaf_zca_zcmp -mabi=ilp32f -mcmodel=medlow" 
}*/
 /* { dg-skip-if "" { *-*-* } {"-O0" "-O1" "-O2" "-Og" "-O3" "-Oz" "-flto"} } */
 /* { dg-final { check-function-bodies "**" "" } } */
 
diff --git a/gcc/tes

Re: [PATCH v3] RISC-V: Add autovec FP binary operations.

2023-09-06 Thread Lehua Ding

Hi Robin,


+# Return 1 if the we can build a vector example with proper -march flags
+# and the current target can execute it, 0 otherwise.  Cache the result.
+
+proc check_effective_target_riscv_vector_hw { } {
+
+return [check_runtime riscv_vector_hw32 {
+int main (void)
+{
+asm ("vsetivli zero,8,e16,m1,ta,ma");
+asm ("vadd.vv v8,v8,v16" : : : "v8");
+return 0;
+}
+} "-march=rv32gcv -mabi=ilp32d"] || [check_runtime riscv_vector_hw64 {
+int main (void)
+{
+asm ("vsetivli zero,8,e16,m1,ta,ma");
+asm ("vadd.vv v8,v8,v16" : : : "v8");
+return 0;
+}
+} "-march=rv64gcv -mabi=lp64d"]
+}
+
+# Return 1 if the we can build a Zvfh vector example with proper -march flags
+# and the current target can execute it, 0 otherwise.  Cache the result.
+
+proc check_effective_target_riscv_zvfh_hw { } {
+if ![check_effective_target_riscv_vector_hw] then {
+return 0
+}
+
+return [check_runtime riscv_zvfh_hw32 {
+int main (void)
+{
+asm ("vsetivli zero,8,e16,m1,ta,ma");
+asm ("vfadd.vv v8,v8,v16" : : : "v8");
+return 0;
+}
+} "-march=rv32gcv_zvfh -mabi=ilp32d"]
+|| [check_runtime riscv_zvfh_hw64 {
+int main (void)
+{
+asm ("vsetivli zero,8,e16,m1,ta,ma");
+asm ("vfadd.vv v8,v8,v16" : : : "v8");
+return 0;
+}
+} "-march=rv64gcv_zvfh -mabi=lp64d"]


May I ask if the compiler options "-march=rv64gcv_zvfh -mabi=lp64d" 
should be removed? Because we don't specify -march and -mabi when we run 
testcase (so but why we need to specify the -march and -mabi in this 
target check?), we run it with the default values. Assuming that the 
default is rv64gcv_zvfh_zfh, `riscv_vector` check will fail because 
compile and link with -march=rv64gcv will throw the following error if I 
doesn't compile a multilibs compilers. But in fact rv64gcv_zvfh_zfh 
contains rv64gcv, we should not let this case report link error.:


riscv64-unknown-elf-gcc: fatal error: Cannot find suitable multilib set 
for 
'-march=rv64imafdcv_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b'/'-mabi=lp64d'


I think we should use the default march and mabi to check whether we can 
compile and execute specified instructions.


--
Best,
Lehua



[PATCH] RISC-V: Fix incorrect mode tieable which cause ICE in RA[PR111296]

2023-09-06 Thread Juzhe-Zhong
This patch fix incorrect mode tieable between DI and V2SI which cause ICE
in RA.

PR target/111296

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_modes_tieable_p): Fix bug.

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/base/pr111296.C: New test.

---
 gcc/config/riscv/riscv.cc  |  7 +++
 .../g++.target/riscv/rvv/base/pr111296.C   | 18 ++
 2 files changed, 25 insertions(+)
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/pr111296.C

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 228515acc1f..2c0c4c2f3ae 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -7648,6 +7648,13 @@ riscv_hard_regno_mode_ok (unsigned int regno, 
machine_mode mode)
 static bool
 riscv_modes_tieable_p (machine_mode mode1, machine_mode mode2)
 {
+  /* We don't allow different REG_CLASS modes tieable since it
+ will cause ICE in register allocation (RA).
+ E.g. V2SI and DI are not tieable.  */
+  if (riscv_v_ext_mode_p (mode1) && !riscv_v_ext_mode_p (mode2))
+return false;
+  else if (riscv_v_ext_mode_p (mode2) && !riscv_v_ext_mode_p (mode1))
+return false;
   return (mode1 == mode2
  || !(GET_MODE_CLASS (mode1) == MODE_FLOAT
   && GET_MODE_CLASS (mode2) == MODE_FLOAT));
diff --git a/gcc/testsuite/g++.target/riscv/rvv/base/pr111296.C 
b/gcc/testsuite/g++.target/riscv/rvv/base/pr111296.C
new file mode 100644
index 000..6eb14fd83a8
--- /dev/null
+++ b/gcc/testsuite/g++.target/riscv/rvv/base/pr111296.C
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-std=c++03 -march=rv64gcv -mabi=lp64d -Ofast -ftree-vectorize 
--param=riscv-autovec-preference=scalable" } */
+
+struct a
+{
+  int b;
+  int c;
+};
+int d;
+a
+e ()
+{
+  a f;
+  int g = d - 1, h = d / 2 - 1;
+  f.b = g;
+  f.c = h;
+  return f;
+}
-- 
2.36.3



[PATCH] OpenMP: Enable 'declare mapper' mappers for 'target update' directives

2023-09-06 Thread Julian Brown
This patch enables use of 'declare mapper' for 'target update' directives,
for each of C, C++ and Fortran.

There are some implementation choices here and some
"read-between-the-lines" consequences regarding this functionality,
as follows:

 * It is possible to invoke a mapper which contains clauses that
   don't make sense for a given 'target update' operation.  E.g. if a
   mapper definition specifies a "from:" mapping and the user does "target
   update to(...)" which triggers that mapper, the resulting map kind
   (OpenMP 5.2, "Table 5.3: Map-Type Decay of Map Type Combinations")
   is "alloc" (and for the inverse case "release").  For such cases,
   an unconditional warning is issued and the map clause in question is
   dropped from the mapper expansion.  (Other choices might be to make
   this an error, or to do the same thing but silently, or warn only
   given some special option.)

 * The array-shaping operator is *permitted* for map clauses within
   'declare mapper' definitions.  That is because such mappers may be used
   for 'target update' directives, where the array-shaping operator is
   permitted.  I think that makes sense, depending on the semantic model
   of how and when substitution is supposed to take place, but I couldn't
   find such behaviour explicitly mentioned in the spec (as of 5.2).
   If the mapper is triggered by a different directive ("omp target",
   "omp target data", etc.), an error will be raised.

Support is also added for the "mapper" modifier on to/from clauses for
all three base languages.

This version of the patch incorporates signature changes to OpenMP
variable list parsing functions for C and C++ that are already present
on the og13 branch.  It applies on top of the "infrastructure" support
series:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627895.html

and the lvalue parsing/declare mapper series:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629363.html

and the array-shaping operator and strided/rectangular 'target update'
support series:

  https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629422.html

Tested with offloading to NVPTX. OK?

2023-09-06  Julian Brown  

gcc/c-family/
* c-common.h (c_omp_region_type): Add C_ORT_UPDATE and C_ORT_OMP_UPDATE
codes.
* c-omp.cc (omp_basic_map_kind_name): New function.
(omp_instantiate_mapper): Add 'target update' support.
(c_omp_instantiate_mappers): Add 'target update' support.

gcc/c/
* c-parser.cc (c_parser_omp_variable_list): Add ORT parameter.
Support array-shaping operator in 'declare mapper' definitions.
(c_parser_omp_var_list_parens): Add ORT parameter.  Pass to
c_parser_omp_variable_list.
(c_parser_oacc_data_clause): Update calls to
c_parser_omp_var_list_parens.
(c_parser_omp_clause_map): Pass C_ORT_OMP_DECLARE_MAPPER to
c_parser_omp_variable_list in mapper definitions.
(c_parser_omp_clause_from_to): Add parsing for mapper modifier.
(c_parser_omp_target_update): Instantiate mappers.

gcc/cp/
* parser.cc (cp_parser_omp_var_list_no_open): Add ORT parameter.
Support array-shaping operator in 'declare mapper' definitions.
(cp_parser_omp_var_list): Add ORT parameter.
(cp_parser_oacc_data_clause): Update call to cp_parser_omp_var_list.
(cp_parser_omp_clause_from_to): Add parsing for mapper modifier.
(cp_parser_omp_clause_map): Pass C_ORT_OMP_DECLARE_MAPPER to
cp_parser_omp_var_list_no_open in mapper definitions.
(cp_parser_omp_target_update): Instantiate mappers.

gcc/fortran/
* openmp.cc (gfc_match_motion_var_list): Add parsing for mapper
modifier.
(gfc_match_omp_clauses): Adjust error handling for changes to
gfc_match_motion_var_list.
* trans-openmp.cc (gfc_trans_omp_target_update): Instantiate mappers.

gcc/testsuite/
* c-c++-common/gomp/declare-mapper-17.c: New test.
* c-c++-common/gomp/declare-mapper-19.c: New test.
* gfortran.dg/gomp/declare-mapper-24.f90: New test.
* gfortran.dg/gomp/declare-mapper-26.f90: Uncomment 'target update' part
of test.
* gfortran.dg/gomp/declare-mapper-26-p.f90: Likewise.
* gfortran.dg/gomp/declare-mapper-27.f90: New test.

libgomp/
* testsuite/libgomp.c-c++-common/declare-mapper-18.c: New test.
* testsuite/libgomp.fortran/declare-mapper-25.f90: New test.
* testsuite/libgomp.fortran/declare-mapper-25-p.f90: New test.
* testsuite/libgomp.fortran/declare-mapper-28.f90: New test.
---
 gcc/c-family/c-common.h   |   2 +
 gcc/c-family/c-omp.cc | 107 ++-
 gcc/c/c-parser.cc | 165 +++--
 gcc/cp/parser.cc  | 169 --
 gcc/fortran/openmp.cc |  86 +++--
 gcc/fortran/trans-openmp.cc   

[PATCH] LoongArch: Fix unintentional bash-ism in r14-3665.

2023-09-06 Thread Yang Yujie
gcc/ChangeLog:

* config.gcc: remove non-POSIX syntax "<<<".
---
 gcc/config.gcc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index b2fe7c7ceef..6d4c8becd28 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -5189,7 +5189,7 @@ case "${target}" in
if test x${parse_state} = x"abi-base"; then
# Base ABI type
case ${component} in
-   lp64d | lp64f | lp64s) 
elem_tmp="ABI_BASE_$(tr a-z A-Z <<< ${component}),";;
+   lp64d | lp64f | lp64s) 
elem_tmp="ABI_BASE_$(echo ${component} | tr a-z A-Z),";;
*)
echo "Unknown base ABI 
\"${component}\" in --with-multilib-list." 1>&2
exit 1
-- 
2.36.0



[PATCH] riscv: xtheadbb: Fix xtheadbb-li-rotr test for rv32

2023-09-06 Thread Christoph Muellner
From: Christoph Müllner 

The test was introduced recently and tests a RV64-only feature.
However, when testing an RV32 compiler, the test gets executed as well
and fails with "cc1: error: ABI requires '-march=rv32'".
This patch fixes this by adding '-mabi=lp64' (like it is done for
other RV64-only tests as well).

Retested with RV32 and RV64 to ensure this won't pop up again.

Signed-off-by: Christoph Müllner 

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xtheadbb-li-rotr.c: Don't run for RV32.
---
 gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c 
b/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
index 136dcb01cf4..01f4215179a 100644
--- a/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
+++ b/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-march=rv64gc_xtheadbb" } */
+/* { dg-options "-march=rv64gc_xtheadbb -mabi=lp64" } */
 /* { dg-skip-if "" { *-*-* } {"-O0" "-Os" "-Og" "-Oz" "-flto" } } */
 /* { dg-final { check-function-bodies "**" "" } } */
 
-- 
2.41.0



[PATCH] LoongArch: Link c++ header directory in the default ABI to the toplevel.

2023-09-06 Thread Yang Yujie
When multilib is enabled, the c++ header directory of the default multilib
variant needs to be linked to the toplevel since g++ does not search the
toplevel in this case.

libstdc++-v3/ChangeLog:

* configure.host: Register t-loongarch in tmake_file.
* config/cpu/loongarch/t-loongarch: New file.  Link c++ header
directory in the default ABI to the toplevel.
---
 libstdc++-v3/config/cpu/loongarch/t-loongarch | 12 
 libstdc++-v3/configure.host   |  5 -
 2 files changed, 16 insertions(+), 1 deletion(-)
 create mode 100644 libstdc++-v3/config/cpu/loongarch/t-loongarch

diff --git a/libstdc++-v3/config/cpu/loongarch/t-loongarch 
b/libstdc++-v3/config/cpu/loongarch/t-loongarch
new file mode 100644
index 000..942eddeb3be
--- /dev/null
+++ b/libstdc++-v3/config/cpu/loongarch/t-loongarch
@@ -0,0 +1,12 @@
+LA_DEFAULT_MULTIDIR = $(shell $(CXX) --print-multi-directory)
+TOPLEV_HEADERS = 
$(DESTDIR)${gxx_include_dir}/${host_alias}/$(LA_DEFAULT_MULTIDIR)
+
+.PHONY: install-toplevel-link
+install: install-toplevel-link
+install-toplevel-link:
+   if test x$(MULTIDO) != xtrue && \
+  test x$(LA_DEFAULT_MULTIDIR) != x.; then \
+   $(MKDIR_P) "$(dir $(TOPLEV_HEADERS))"; \
+   rm -rf "$(TOPLEV_HEADERS)"; \
+   $(LN_S) ../ "$(TOPLEV_HEADERS)"; \
+   fi
diff --git a/libstdc++-v3/configure.host b/libstdc++-v3/configure.host
index 9e7c7f02dfd..9dc42ad3edb 100644
--- a/libstdc++-v3/configure.host
+++ b/libstdc++-v3/configure.host
@@ -315,7 +315,10 @@ esac
 # Set any OS-dependent and CPU-dependent bits.
 # THIS TABLE IS SORTED.  KEEP IT THAT WAY.
 case "${host}" in
-  *-*-linux* | *-*-uclinux*)
+ loongarch*)
+tmake_file="cpu/loongarch/t-loongarch"
+;;
+ *-*-linux* | *-*-uclinux*)
 case "${host_cpu}" in
   i[567]86)
 abi_baseline_pair=i486-linux-gnu
-- 
2.36.0



Re: [PATCH] riscv: xtheadbb: Fix xtheadbb-li-rotr test for rv32

2023-09-06 Thread Philipp Tomsich
Committed as "obvious" to master.
--Philipp.

On Wed, 6 Sept 2023 at 12:04, Christoph Muellner <
christoph.muell...@vrull.eu> wrote:

> From: Christoph Müllner 
>
> The test was introduced recently and tests a RV64-only feature.
> However, when testing an RV32 compiler, the test gets executed as well
> and fails with "cc1: error: ABI requires '-march=rv32'".
> This patch fixes this by adding '-mabi=lp64' (like it is done for
> other RV64-only tests as well).
>
> Retested with RV32 and RV64 to ensure this won't pop up again.
>
> Signed-off-by: Christoph Müllner 
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/xtheadbb-li-rotr.c: Don't run for RV32.
> ---
>  gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
> b/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
> index 136dcb01cf4..01f4215179a 100644
> --- a/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
> +++ b/gcc/testsuite/gcc.target/riscv/xtheadbb-li-rotr.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-march=rv64gc_xtheadbb" } */
> +/* { dg-options "-march=rv64gc_xtheadbb -mabi=lp64" } */
>  /* { dg-skip-if "" { *-*-* } {"-O0" "-Os" "-Og" "-Oz" "-flto" } } */
>  /* { dg-final { check-function-bodies "**" "" } } */
>
> --
> 2.41.0
>
>


Re: [PATCH v5] c++: extend cold, hot attributes to classes

2023-09-06 Thread Javier Martinez via Gcc-patches
reminder: ready for commit?

- Javier

On Wed 23. Aug 2023 at 15:02, Javier Martinez <
javier.martinez.bugzi...@gmail.com> wrote:

> On Tue, Aug 22, 2023 at 7:50 PM Jason Merrill  wrote:
> > You still need an update to doc/extend.texi for this additional use of
> > the attribute.  Sorry I didn't think of that before.
>
> I should have caught that too, many thanks.
>
> Also addressed the formatting comments. Patch attached.
>
> Signed-off-by: Javier Martinez 
>


Re: [PATCH] xtensa: Optimize boolean evaluation when SImode EQ/NE to zero if TARGET_MINMAX

2023-09-06 Thread Max Filippov via Gcc-patches
On Tue, Sep 5, 2023 at 9:24 PM Takayuki 'January June' Suwa
 wrote:
> On 2023/09/06 8:01, Max Filippov wrote:
> > On Tue, Sep 5, 2023 at 2:29 AM Takayuki 'January June' Suwa
> >  wrote:
> >> ;; after (prereq. TARGET_MINMAX)
> >> test0:
> >> movi.n  a9, 1
> >> minua2, a2, a9
> >> xor a2, a2, a9
> >> ret.n
> >
> > ISTM that test0 could be done with movnez in the same three instructions:
> >
> >   movi a9, 1
> >   movnez a2, a9, a2
> >   xor a2, a2, a9
>
> Unfortunately, the MOV[EQ/NE]Z machine instruction can only be used
> to implement the functionality if the input and output physical registers
> are the same (a2 in the example).

Oh yeah, you're right, I missed that.

-- 
Thanks.
-- Max


Re: [PATCH] xtensa: Optimize boolean evaluation when SImode EQ/NE to zero if TARGET_MINMAX

2023-09-06 Thread Max Filippov via Gcc-patches
On Tue, Sep 5, 2023 at 2:29 AM Takayuki 'January June' Suwa
 wrote:
>
> This patch optimizes the boolean evaluation for equality to 0 in SImode
> using the MINU (Minimum Value Unsigned) machine instruction available
> when TARGET_MINMAX is configured, for example, (x != 0) to MINU(x, 1)
> and (x == 0) to (MINU(x, 1) ^ 1).
>
> /* example */
> int test0(int x) {
>   return x == 0;
> }
> int test1(int x) {
>   return x != 0;
> }
>
> ;; before
> test0:
> mov.n   a10, a2
> movi.n  a9, 1
> movi.n  a2, 0
> moveqz  a2, a9, a10
> ret.n
> test1:
> mov.n   a10, a2
> movi.n  a9, 1
> movi.n  a2, 0
> movnez  a2, a9, a10
> ret.n
>
> ;; after (prereq. TARGET_MINMAX)
> test0:
> movi.n  a9, 1
> minua2, a2, a9
> xor a2, a2, a9
> ret.n
> test1:
> movi.n  a9, 1
> minua2, a2, a9
> ret.n
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.cc (xtensa_expand_scc):
> Add code for particular constants (only 0 and INT_MIN for now)
> for EQ/NE boolean evaluation in SImode.
> * config/xtensa/xtensa.md (*eqne_INT_MIN): Remove because its
> implementation has been integrated into the above.
> ---
>  gcc/config/xtensa/xtensa.cc | 43 +++--
>  gcc/config/xtensa/xtensa.md | 34 -
>  2 files changed, 37 insertions(+), 40 deletions(-)

Regtested for target=xtensa-linux-uclibc, no new regressions.
Committed to master.

-- 
Thanks.
-- Max


Re: [PATCH] LoongArch: Link c++ header directory in the default ABI to the toplevel.

2023-09-06 Thread Xi Ruoyao via Gcc-patches
On Wed, 2023-09-06 at 18:06 +0800, Yang Yujie wrote:
> When multilib is enabled, the c++ header directory of the default multilib
> variant needs to be linked to the toplevel since g++ does not search the
> toplevel in this case.
> 
> libstdc++-v3/ChangeLog:
> 
> * configure.host: Register t-loongarch in tmake_file.
> * config/cpu/loongarch/t-loongarch: New file.  Link c++ header
> directory in the default ABI to the toplevel.
> ---
>  libstdc++-v3/config/cpu/loongarch/t-loongarch | 12 
>  libstdc++-v3/configure.host   |  5 -
>  2 files changed, 16 insertions(+), 1 deletion(-)
>  create mode 100644 libstdc++-v3/config/cpu/loongarch/t-loongarch
> 
> diff --git a/libstdc++-v3/config/cpu/loongarch/t-loongarch
> b/libstdc++-v3/config/cpu/loongarch/t-loongarch
> new file mode 100644
> index 000..942eddeb3be
> --- /dev/null
> +++ b/libstdc++-v3/config/cpu/loongarch/t-loongarch
> @@ -0,0 +1,12 @@
> +LA_DEFAULT_MULTIDIR = $(shell $(CXX) --print-multi-directory)
> +TOPLEV_HEADERS = 
> $(DESTDIR)${gxx_include_dir}/${host_alias}/$(LA_DEFAULT_MULTIDIR)
> +
> +.PHONY: install-toplevel-link
> +install: install-toplevel-link
> +install-toplevel-link:
> +   if test x$(MULTIDO) != xtrue && \
> +  test x$(LA_DEFAULT_MULTIDIR) != x.; then \
> +   $(MKDIR_P) "$(dir $(TOPLEV_HEADERS))"; \
> +   rm -rf "$(TOPLEV_HEADERS)"; \
> +   $(LN_S) ../ "$(TOPLEV_HEADERS)"; \

>From autoconf info page:

 -- Macro: AC_PROG_LN_S
 If ‘ln -s’ works on the current file system (the operating system
 and file system support symbolic links), set the output variable
 ‘LN_S’ to ‘ln -s’; otherwise, if ‘ln’ works, set ‘LN_S’ to ‘ln’,
 and otherwise set it to ‘cp -pR’.

 If you make a link in a directory other than the current directory,
 its meaning depends on whether ‘ln’ or ‘ln -s’ is used.  To safely
 create links using ‘$(LN_S)’, either find out which form is used
 and adjust the arguments, or always invoke ‘ln’ in the directory
 where the link is to be created.

 In other words, it does not work to do:
  $(LN_S) foo /x/bar

 Instead, do:

  (cd /x && $(LN_S) foo bar)

But for this special case we cannot "cp -pR ../ $(TOPLEV_HEADERS)"
either:

$ cp ../* -pR something
cp: cannot copy a directory, '../g', into itself, 'h/g'

So I guess we'll need something like

if ln -s ../ "$(TOPLEV_HEADERS)"; then
  # OK!
  true
else
  # system does not support symlink :(
  # install another copy of toplevel headers into default multilib subdir
  TODO: 
fi

And all libstdc++ patches should Cc: libstd...@gcc.gnu.org.

> +   fi
> diff --git a/libstdc++-v3/configure.host b/libstdc++-v3/configure.host
> index 9e7c7f02dfd..9dc42ad3edb 100644
> --- a/libstdc++-v3/configure.host
> +++ b/libstdc++-v3/configure.host
> @@ -315,7 +315,10 @@ esac
>  # Set any OS-dependent and CPU-dependent bits.
>  # THIS TABLE IS SORTED.  KEEP IT THAT WAY.
>  case "${host}" in
> -  *-*-linux* | *-*-uclinux*)
> + loongarch*)
> +    tmake_file="cpu/loongarch/t-loongarch"
> +    ;;
> + *-*-linux* | *-*-uclinux*)
>  case "${host_cpu}" in
>    i[567]86)
>  abi_baseline_pair=i486-linux-gnu

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


[PATCH v1 0/4] Add Loongson SX/ASX instruction support to LoongArch

2023-09-06 Thread Xiaolong Chen
In order to better test the function of the vector instruction, the 128 and 256 
bit test cases are further split according to the function of the instruction.

Xiaolong Chen (4):
  LoongArch: Add tests of -mstrict-align option.
  LoongArch: Add testsuite framework for Loongson SX/ASX.
  LoongArch: Add tests for Loongson SX builtin functions.
  LoongArch: Add tests for Loongson SX floating-point conversion
instructions.

 .../gcc.target/loongarch/strict-align.c   |   13 +
 .../loongarch/vector/loongarch-vector.exp |   42 +
 .../loongarch/vector/lsx/lsx-builtin.c| 1461 +
 .../loongarch/vector/lsx/lsx-vfcvt-1.c|  397 +
 .../loongarch/vector/lsx/lsx-vfcvt-2.c|  277 
 .../loongarch/vector/lsx/lsx-vffint-1.c   |  160 ++
 .../loongarch/vector/lsx/lsx-vffint-2.c   |  263 +++
 .../loongarch/vector/lsx/lsx-vffint-3.c   |  101 ++
 .../loongarch/vector/lsx/lsx-vfrint_d.c   |  229 +++
 .../loongarch/vector/lsx/lsx-vfrint_s.c   |  349 
 .../loongarch/vector/lsx/lsx-vftint-1.c   |  348 
 .../loongarch/vector/lsx/lsx-vftint-2.c   |  694 
 .../loongarch/vector/lsx/lsx-vftint-3.c   | 1027 
 .../loongarch/vector/lsx/lsx-vftint-4.c   |  344 
 .../loongarch/vector/simd_correctness_check.h |   39 +
 15 files changed, 5744 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/strict-align.c
 create mode 100644 
gcc/testsuite/gcc.target/loongarch/vector/loongarch-vector.exp
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-builtin.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfcvt-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfcvt-2.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vffint-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vffint-2.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vffint-3.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfrint_d.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vfrint_s.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vftint-1.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vftint-2.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vftint-3.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/vector/lsx/lsx-vftint-4.c
 create mode 100644 
gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h

-- 
2.20.1



[PATCH v1 1/4] LoongArch: Add tests of -mstrict-align option.

2023-09-06 Thread Xiaolong Chen
gcc/testsuite/ChangeLog:

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

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



[PATCH v1 2/4] LoongArch: Add testsuite framework for Loongson SX/ASX.

2023-09-06 Thread Xiaolong Chen
gcc/testsuite/ChangeLog:

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

diff --git a/gcc/testsuite/gcc.target/loongarch/vector/loongarch-vector.exp 
b/gcc/testsuite/gcc.target/loongarch/vector/loongarch-vector.exp
new file mode 100644
index 000..b0616a26b0e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/loongarch-vector.exp
@@ -0,0 +1,42 @@
+# Copyright (C) 2021-2023 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+# GCC testsuite that uses the `dg.exp' driver.
+
+# Exit immediately if this isn't a LoongArch target.
+if ![istarget loongarch*-*-*] then {
+  return
+}
+
+# Load support procs.
+load_lib gcc-dg.exp
+
+# If a testcase doesn't have special options, use these.
+global DEFAULT_CFLAGS
+if ![info exists DEFAULT_CFLAGS] then {
+set DEFAULT_CFLAGS " -mlasx"
+}
+
+# Initialize `dg'.
+dg-init
+
+# Main loop.
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/lsx/*.\[cS\]]] \
+   "" $DEFAULT_CFLAGS
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/lasx/*.\[cS\]]] \
+   "" $DEFAULT_CFLAGS
+# All done.
+dg-finish
diff --git a/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h 
b/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h
new file mode 100644
index 000..7be199ee3a0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h
@@ -0,0 +1,39 @@
+#include 
+#include 
+#include 
+
+#define ASSERTEQ_64(line, ref, res)
\
+do{
\
+int fail = 0;  
\
+for(size_t i = 0; i < sizeof(res)/sizeof(res[0]); ++i){
\
+   long *temp_ref = &ref[i], *temp_res = &res[i];  
\
+   if(abs(*temp_ref - *temp_res) > 0){ 
\
+   printf(" error: %s at line %ld , expected "#ref"[%ld]:0x%lx, got: 
0x%lx\n", \
+   __FILE__, line, i, *temp_ref, *temp_res);   
\
+   fail = 1;   
\
+   }   
\
+}  
\
+if(fail == 1) abort(); 
\
+}while(0) 
+
+#define ASSERTEQ_32(line, ref, res)
\
+do{
\
+int fail = 0;  
\
+for(size_t i = 0; i < sizeof(res)/sizeof(res[0]); ++i){
\
+   int *temp_ref = &ref[i], *temp_res = &res[i];   
\
+   if(abs(*temp_ref - *temp_res) > 0){ 
\
+   printf(" error: %s at line %ld , expected "#ref"[%ld]:0x%x, got: 
0x%x\n",   \
+  __FILE__, line, i, *temp_ref, *temp_res);
\
+   fail = 1;   
\
+   }   
\
+}  
\
+if(fail == 1) abort(); 
\
+}while(0) 
+
+#define ASSERTEQ_int(line, ref, res)   
\
+do{
\
+if (ref != res){   
\
+  

[PATCH v1 3/4] LoongArch: Add tests for Loongson SX builtin functions.

2023-09-06 Thread Xiaolong Chen
gcc/testsuite/ChangeLog:

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

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

[PATCH] LoongArch: Use bstrins instruction for (a & ~mask) and (a & mask) | (b & ~mask) [PR111252]

2023-09-06 Thread Xi Ruoyao via Gcc-patches
If mask is a constant with value ((1 << N) - 1) << M we can perform this
optimization.

gcc/ChangeLog:

PR target/111252
* config/loongarch/loongarch-protos.h
(loongarch_pre_reload_split): Declare new function.
(loongarch_use_bstrins_for_ior_with_mask): Likewise.
* config/loongarch/loongarch.cc
(loongarch_pre_reload_split): Implement.
(loongarch_use_bstrins_for_ior_with_mask): Likewise.
* config/loongarch/predicates.md (ins_zero_bitmask_operand):
New predicate.
* config/loongarch/loongarch.md (bstrins__for_mask):
New define_insn_and_split.
(bstrins__for_ior_mask): Likewise.
(define_peephole2): Further optimize code sequence produced by
bstrins__for_ior_mask if possible.

gcc/testsuite/ChangeLog:

* g++.target/loongarch/bstrins-compile.C: New test.
* g++.target/loongarch/bstrins-run.C: New test.
---
 gcc/config/loongarch/loongarch-protos.h   |  4 +-
 gcc/config/loongarch/loongarch.cc | 36 
 gcc/config/loongarch/loongarch.md | 91 +++
 gcc/config/loongarch/predicates.md|  8 ++
 .../g++.target/loongarch/bstrins-compile.C| 22 +
 .../g++.target/loongarch/bstrins-run.C| 65 +
 6 files changed, 225 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.target/loongarch/bstrins-compile.C
 create mode 100644 gcc/testsuite/g++.target/loongarch/bstrins-run.C

diff --git a/gcc/config/loongarch/loongarch-protos.h 
b/gcc/config/loongarch/loongarch-protos.h
index f4430d0d418..251011c5414 100644
--- a/gcc/config/loongarch/loongarch-protos.h
+++ b/gcc/config/loongarch/loongarch-protos.h
@@ -56,7 +56,7 @@ enum loongarch_symbol_type {
 };
 #define NUM_SYMBOL_TYPES (SYMBOL_TLSLDM + 1)
 
-/* Routines implemented in loongarch.c.  */
+/* Routines implemented in loongarch.cc.  */
 extern rtx loongarch_emit_move (rtx, rtx);
 extern HOST_WIDE_INT loongarch_initial_elimination_offset (int, int);
 extern void loongarch_expand_prologue (void);
@@ -163,6 +163,8 @@ extern const char *current_section_name (void);
 extern unsigned int current_section_flags (void);
 extern bool loongarch_use_ins_ext_p (rtx, HOST_WIDE_INT, HOST_WIDE_INT);
 extern bool loongarch_check_zero_div_p (void);
+extern bool loongarch_pre_reload_split (void);
+extern int loongarch_use_bstrins_for_ior_with_mask (machine_mode, rtx *);
 
 union loongarch_gen_fn_ptrs
 {
diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc
index aeb37f0f2f7..6698414281e 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -5482,6 +5482,42 @@ loongarch_use_ins_ext_p (rtx op, HOST_WIDE_INT width, 
HOST_WIDE_INT bitpos)
   return true;
 }
 
+/* Predicate for pre-reload splitters with associated instructions,
+   which can match any time before the split1 pass (usually combine),
+   then are unconditionally split in that pass and should not be
+   matched again afterwards.  */
+
+bool loongarch_pre_reload_split (void)
+{
+  return (can_create_pseudo_p ()
+ && !(cfun->curr_properties & PROP_rtl_split_insns));
+}
+
+/* Check if we can use bstrins. for
+   op0 = (op1 & op2) | (op3 & op4)
+   where op0, op1, op3 are regs, and op2, op4 are integer constants.  */
+int
+loongarch_use_bstrins_for_ior_with_mask (machine_mode mode, rtx *op)
+{
+  unsigned HOST_WIDE_INT mask1 = UINTVAL (op[2]);
+  unsigned HOST_WIDE_INT mask2 = UINTVAL (op[4]);
+
+  if (mask1 != ~mask2 || !mask1 || !mask2)
+return 0;
+
+  /* Try to avoid a right-shift.  */
+  if (low_bitmask_len (mode, mask1) != -1)
+return -1;
+
+  if (low_bitmask_len (mode, mask2 >> (ffs_hwi (mask2) - 1)) != -1)
+return 1;
+
+  if (low_bitmask_len (mode, mask1 >> (ffs_hwi (mask1) - 1)) != -1)
+return -1;
+
+  return 0;
+}
+
 /* Print the text for PRINT_OPERAND punctation character CH to FILE.
The punctuation characters are:
 
diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index 2308db16902..75f641b38ee 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -1322,6 +1322,97 @@ (define_insn "and3_extended"
   [(set_attr "move_type" "pick_ins")
(set_attr "mode" "")])
 
+(define_insn_and_split "*bstrins__for_mask"
+  [(set (match_operand:GPR 0 "register_operand")
+   (and:GPR (match_operand:GPR 1 "register_operand")
+(match_operand:GPR 2 "ins_zero_bitmask_operand")))]
+  ""
+  "#"
+  ""
+  [(set (match_dup 0) (match_dup 1))
+   (set (zero_extract:GPR (match_dup 0) (match_dup 2) (match_dup 3))
+   (const_int 0))]
+  {
+unsigned HOST_WIDE_INT mask = ~UINTVAL (operands[2]);
+int lo = ffs_hwi (mask) - 1;
+int len = low_bitmask_len (mode, mask >> lo);
+
+len = MIN (len, GET_MODE_BITSIZE (mode) - lo);
+operands[2] = GEN_INT (len);
+operands[3] = GEN_INT (lo);
+  })
+
+(define_insn_and_split "*bstrins__for_ior_mask"
+  [

Re: [PATCH v1 4/4] LoongArch: Add tests for Loongson SX floating-point conversion instructions.

2023-09-06 Thread Xi Ruoyao via Gcc-patches
On Wed, 2023-09-06 at 18:45 +0800, Xiaolong Chen wrote:
> +  *((int*)& __m128_op0[3]) = 0x004200a0;
> +  *((int*)& __m128_op0[2]) = 0x;
> +  *((int*)& __m128_op0[1]) = 0x004200a0;
> +  *((int*)& __m128_op0[0]) = 0x0021;

These are aliasing rule violation and they will suddenly blow up when
GCC optimizer starts to optimize more aggressively based on the aliasing
rule.

Try not to use these (you can write a helper function to memcpy() into a
__m128).  Or use -fno-strict-alising in dg-options.

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


Re: [PATCH] LoongArch: Use bstrins instruction for (a & ~mask) and (a & mask) | (b & ~mask) [PR111252]

2023-09-06 Thread Xi Ruoyao via Gcc-patches
Forgot to mention: I've bootstrapped and regtested this patch on
loongarch64-linux-gnu (with PR110939 patch applied to unbreak the
bootstrapping).  Ok for trunk?

On Wed, 2023-09-06 at 18:46 +0800, Xi Ruoyao wrote:

> If mask is a constant with value ((1 << N) - 1) << M we can perform this
> optimization.
> 
> gcc/ChangeLog:
> 
> PR target/111252
> * config/loongarch/loongarch-protos.h
> (loongarch_pre_reload_split): Declare new function.
> (loongarch_use_bstrins_for_ior_with_mask): Likewise.
> * config/loongarch/loongarch.cc
> (loongarch_pre_reload_split): Implement.
> (loongarch_use_bstrins_for_ior_with_mask): Likewise.
> * config/loongarch/predicates.md (ins_zero_bitmask_operand):
> New predicate.
> * config/loongarch/loongarch.md (bstrins__for_mask):
> New define_insn_and_split.
> (bstrins__for_ior_mask): Likewise.
> (define_peephole2): Further optimize code sequence produced by
> bstrins__for_ior_mask if possible.
> 
> gcc/testsuite/ChangeLog:
> 
> * g++.target/loongarch/bstrins-compile.C: New test.
> * g++.target/loongarch/bstrins-run.C: New test.

/* snip */

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


Re: [PATCH] LoongArch: Fix unintentional bash-ism in r14-3665.

2023-09-06 Thread Sam James via Gcc-patches


Yang Yujie  writes:

> gcc/ChangeLog:
>
>   * config.gcc: remove non-POSIX syntax "<<<".
> ---

Thanks, I was just about to report this.

>  gcc/config.gcc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index b2fe7c7ceef..6d4c8becd28 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -5189,7 +5189,7 @@ case "${target}" in
>   if test x${parse_state} = x"abi-base"; then
>   # Base ABI type
>   case ${component} in
> - lp64d | lp64f | lp64s) 
> elem_tmp="ABI_BASE_$(tr a-z A-Z <<< ${component}),";;
> + lp64d | lp64f | lp64s) 
> elem_tmp="ABI_BASE_$(echo ${component} | tr a-z A-Z),";;
>   *)
>   echo "Unknown base ABI 
> \"${component}\" in --with-multilib-list." 1>&2
>   exit 1



Re: [PATCH v1 1/4] LoongArch: Add tests of -mstrict-align option.

2023-09-06 Thread Xi Ruoyao via Gcc-patches
On Wed, 2023-09-06 at 18:43 +0800, Xiaolong Chen wrote:
> gcc/testsuite/ChangeLog:
> 
> * gcc.target/loongarch/strict-align.c: New test.

A question: is there really a CPU model with LSX/LASX but without
unaligned access support?  If not I think we'd just reject -mstrict-
align -mlsx.

Currently Glibc assumes if LSX is available then unaligned access must
be available too.

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

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


Re: [PATCH] RISC-V: Keep vlmax vector operators in simple form until split1 pass

2023-09-06 Thread Lehua Ding

Committed, thanks Kito.

--
Best,
Lehua



Re: [PATCH] fwprop: Allow UNARY_P and check register pressure.

2023-09-06 Thread Robin Dapp via Gcc-patches
Hi Richard,

I did some testing with the attached v2 that does not restrict to UNARY
anymore.  As feared ;) there is some more fallout that I'm detailing below.

On Power there is one guality fail (pr43051-1.c) that I would take
the liberty of ignoring for now.

On x86 there are four fails:

 - cond_op_addsubmuldiv__Float16-2.c: assembler error
   unsupported masking for `vmovsh'.  I guess that's a latent backend
   problem.

 - ifcvt-3.c, pr49095.c: Here we propagate into a compare.  Before, we had
   (cmp (reg/CC) 0) and now we have (cmp (plus (reg1 reg2) 0).
   That looks like a costing problem and can hopefully solveable by making
   the second compare more expensive, preventing the propagation.
   i386 costing (or every costing?) is brittle so that could well break other
   things. 

 - pr88873.c: This is interesting because even before this patch we
   propagated with different register classes (V2DF vs DI).  With the patch
   we check the register pressure, find the class NO_REGS for V2DF and
   abort (because the patch assumes NO_REGS = high pressure).  I'm thinking
   of keeping the old behavior for reg-reg propagations and only checking
   the pressure for more complex operations.

aarch64 has the most fails:

 - One guality fail (same as Power).
 - shrn-combine-[123].c as before.

 - A class of (hopefully, I only checked some) similar cases where we
   propagate an unspec_whilelo into an unspec_ptest.  Before we would only
   set a REG_EQUALS note.
   Before we managed to create a while_ultsivnx16bi_cc whereas now we have
   while_ultsivnx16bi and while_ultsivnx16bi_ptest that won't be combined.
   We create redundant whilelos and I'm not sure how to improve that. I
   guess a peephole is out of the question :)

 - pred-combine-and.c: Here the new propagation appears useful at first.
   We propagate a "vector mask and" into a while_ultsivnx4bi_ptest and the
   individual and registers remain live up to the propagation site (while
   being dead before the patch).
   With the registers dead, combine could create a single fcmgt before.
   Now it only manages a 2->2 combination because we still need the registers
   and end up with two fcmgts.
   The code is worse but this seems more bad luck than anything.

 - Addressing fails from before:  I looked into these and suspect all of
   them are a similar.
   What happens is that we have a poly_int offset that we shift, negate
   and then add to x0.  The result is used as load address.
   Before, we would pull (combine) the (plus x0 reg) into the load keeping
   the neg and shift.
   Now we propagate everything into a single (set (minus x0 offset)).
   The propagation itself seems worthwhile because we save one insn.
   However as we got rid of the base/offset split by lumping everything
   together, combine cannot pull the (plus) into the address load and
   we require an aarch64_split_add_offset.  This will emit the longer
   sequence of ashiftl and subtract.  The "base" address is x0 here so
   we cannot convert (minus x0 ...)) into neg.
   I didn't go through all of aarch64_split_add_offset.  I suppose we
   could re-add the separation of base/offset there but that might be
   a loss when the result is not used as an address. 
   
Again, all in all no fatal problems but pretty annoying :)  It's not much
but just gradually worse than with just UNARY.  Any idea on how/whether to
continue?

Regards
 Robin

gcc/ChangeLog:

* fwprop.cc (fwprop_propagation::profitable_p): Add unary
handling.
(fwprop_propagation::update_register_pressure): New function.
(fwprop_propagation::register_pressure_high_p): New function
(reg_single_def_for_src_p): Look through unary expressions.
(try_fwprop_subst_pattern): Check register pressure.
(forward_propagate_into): Call new function.
(fwprop_init): Init register pressure.
(fwprop_done): Clean up register pressure.
(fwprop_insn): Add comment.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/binop/vadd-vx-fwprop.c: New test.
---
 gcc/fwprop.cc | 359 +-
 .../riscv/rvv/autovec/binop/vadd-vx-fwprop.c  |  64 
 2 files changed, 419 insertions(+), 4 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vadd-vx-fwprop.c

diff --git a/gcc/fwprop.cc b/gcc/fwprop.cc
index 0707a234726..ce6f5a74b00 100644
--- a/gcc/fwprop.cc
+++ b/gcc/fwprop.cc
@@ -36,6 +36,10 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-pass.h"
 #include "rtl-iter.h"
 #include "target.h"
+#include "dominance.h"
+
+#include "ira.h"
+#include "regpressure.h"
 
 /* This pass does simple forward propagation and simplification when an
operand of an insn can only come from a single def.  This pass uses
@@ -103,6 +107,10 @@ using namespace rtl_ssa;
 
 static int num_changes;
 
+/* Keep track of which registers already increased the pressure to avoid double
+   booking.  *

Re: [RFC] GCC Security policy

2023-09-06 Thread Siddhesh Poyarekar

Hello folks,

Here's v3 of the top part of the security policy.  Hopefully this 
addresses all concerns raised so far.


Thanks,
Sid


What is a GCC security bug?
===

A security bug is one that threatens the security of a system or
network, or might compromise the security of data stored on it.
In the context of GCC there are multiple ways in which this might
happen and they're detailed below.

Compiler drivers, programs, libgccjit and support libraries
---

The compiler driver processes source code, invokes other programs
such as the assembler and linker and generates the output result,
which may be assembly code or machine code.  Compiling untrusted
sources can result in arbitrary code execution and unconstrained
resource consumption in the compiler. As a result, compilation of
such code should be done inside a sandboxed environment to ensure
that it does not compromise the development environment.

The libgccjit library can, despite the name, be used both for
ahead-of-time compilation and for just-in-compilation.  In both
cases it can be used to translate input representations (such as
source code) in the application context; in the latter case the
generated code is also run in the application context.

Limitations that apply to the compiler driver, apply here too in
terms of sanitizing inputs and it is recommended that both the
compilation *and* execution context of the code are appropriately
sandboxed to contain the effects of any bugs in libgccjit, the
application code using it, or its generated code to the sandboxed
environment.

Support libraries such as libiberty, libcc1 libvtv and libcpp have
been developed separately to share code with other tools such as
binutils and gdb.  These libraries again have similar challenges to
compiler drivers.  While they are expected to be robust against
arbitrary input, they should only be used with trusted inputs.

Libraries such as zlib that bundled into GCC to build it will be
treated the same as the compiler drivers and programs as far as
security coverage is concerned.  However if you find an issue in
these libraries independent of their use in GCC, you should reach
out to their upstream projects to report them.

As a result, the only case for a potential security issue in the
compiler is when it generates vulnerable application code for
trusted input source code that is conforming to the relevant
programming standard or extensions documented as supported by GCC
and the algorithm expressed in the source code does not have the
vulnerability.  The output application code could be considered
vulnerable if it produces an actual vulnerability in the target
application, specifically in the following cases:

- The application dereferences an invalid memory location despite
  the application sources being valid.
- The application reads from or writes to a valid but incorrect
  memory location, resulting in an information integrity issue or an
  information leak.
- The application ends up running in an infinite loop or with
  severe degradation in performance despite the input sources having
  no such issue, resulting in a Denial of Service.  Note that
  correct but non-performant code is not a security issue candidate,
  this only applies to incorrect code that may result in performance
  degradation severe enough to amount to a denial of service.
- The application crashes due to the generated incorrect code,
  resulting in a Denial of Service.

Language runtime libraries
--

GCC also builds and distributes libraries that are intended to be
used widely to implement runtime support for various programming
languages.  These include the following:

* libada
* libatomic
* libbacktrace
* libcc1
* libcody
* libcpp
* libdecnumber
* libffi
* libgcc
* libgfortran
* libgm2
* libgo
* libgomp
* libiberty
* libitm
* libobjc
* libphobos
* libquadmath
* libsanitizer
* libssp
* libstdc++

These libraries are intended to be used in arbitrary contexts and as
a result, bugs in these libraries may be evaluated for security
impact.  However, some of these libraries, e.g. libgo, libphobos,
etc.  are not maintained in the GCC project, due to which the GCC
project may not be the correct point of contact for them.  You are
encouraged to look at README files within those library directories
to locate the canonical security contact point for those projects
and include them in the report.  Once the issue is fixed in the
upstream project, the fix will be synced into GCC in a future
release.

Most security vulnerabilities in these runtime librarie

[PATCH] RISC-V: Remove unreasonable TARGET_64BIT for VLS modes with size = 64bit

2023-09-06 Thread Juzhe-Zhong
Previously,  I add TARGET_64BIT condtion to block VLS modes with size = 64bit 
in RV32 system
E.g. V8QI

Since I realized such modes may cause inferior codegen for some situations in 
RV32 system.

However, this is really quite ugly and it cause ICE for some cases in RV32:

FAIL: gcc.target/riscv/rvv/autovec/conversions/vfncvt-ftoi-run.c (internal 
compiler error: in require, at machmode.h:313)
3937FAIL: gcc.target/riscv/rvv/autovec/conversions/vfncvt-ftoi-run.c (test for 
excess errors)

For inferior codegen in RV32 system, we should try another reasonable approach 
to fix it.

Remove those TARGET_64BIT and fix ICE.

gcc/ChangeLog:

* config/riscv/riscv-vector-switch.def (VLS_ENTRY): Remove TARGET_64BIT

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/partial/slp-9.c: Adapt test.
* gcc.target/riscv/rvv/autovec/zve32f_zvl1024b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32f_zvl128b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32f_zvl2048b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32f_zvl256b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32f_zvl4096b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32f_zvl512b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32x_zvl1024b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32x_zvl128b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32x_zvl2048b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32x_zvl256b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32x_zvl4096b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve32x_zvl512b-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve64d-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve64f-1.c: Ditto.
* gcc.target/riscv/rvv/autovec/zve64x-1.c: Ditto.

---
 gcc/config/riscv/riscv-vector-switch.def  | 8 
 .../gcc.target/riscv/rvv/autovec/partial/slp-9.c  | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32f_zvl1024b-1.c  | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32f_zvl128b-1.c   | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32f_zvl2048b-1.c  | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32f_zvl256b-1.c   | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32f_zvl4096b-1.c  | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32f_zvl512b-1.c   | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32x_zvl1024b-1.c  | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32x_zvl128b-1.c   | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32x_zvl2048b-1.c  | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32x_zvl256b-1.c   | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32x_zvl4096b-1.c  | 2 +-
 .../gcc.target/riscv/rvv/autovec/zve32x_zvl512b-1.c   | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64d-1.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64f-1.c | 2 +-
 gcc/testsuite/gcc.target/riscv/rvv/autovec/zve64x-1.c | 2 +-
 17 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/gcc/config/riscv/riscv-vector-switch.def 
b/gcc/config/riscv/riscv-vector-switch.def
index c035dc3558b..174e5a181c6 100644
--- a/gcc/config/riscv/riscv-vector-switch.def
+++ b/gcc/config/riscv/riscv-vector-switch.def
@@ -309,7 +309,7 @@ VLS_ENTRY (V4096BI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 
4096)
 VLS_ENTRY (V1QI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V2QI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V4QI, TARGET_VECTOR_VLS)
-VLS_ENTRY (V8QI, TARGET_VECTOR_VLS && TARGET_64BIT)
+VLS_ENTRY (V8QI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V16QI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V32QI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V64QI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 64)
@@ -321,7 +321,7 @@ VLS_ENTRY (V2048QI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 
2048)
 VLS_ENTRY (V4096QI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 4096)
 VLS_ENTRY (V1HI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V2HI, TARGET_VECTOR_VLS)
-VLS_ENTRY (V4HI, TARGET_VECTOR_VLS && TARGET_64BIT)
+VLS_ENTRY (V4HI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V8HI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V16HI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V32HI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 64)
@@ -332,7 +332,7 @@ VLS_ENTRY (V512HI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 
1024)
 VLS_ENTRY (V1024HI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 2048)
 VLS_ENTRY (V2048HI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 4096)
 VLS_ENTRY (V1SI, TARGET_VECTOR_VLS)
-VLS_ENTRY (V2SI, TARGET_VECTOR_VLS && TARGET_64BIT)
+VLS_ENTRY (V2SI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V4SI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V8SI, TARGET_VECTOR_VLS)
 VLS_ENTRY (V16SI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 64)
@@ -342,7 +342,7 @@ VLS_ENTRY (V128SI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 
512)
 VLS_ENTRY (V256SI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 1024)
 VLS_ENTRY (V512SI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 2048)
 VLS_ENTRY (V1024SI, TARGET_VECTOR_VLS && TARGET_MIN_VLEN >= 4096)
-VLS_ENTRY (V1DI, TARGET_VECTOR_VLS && TARGET_VECTOR_ELEN_64 && TARGET_64BIT)
+VLS_ENTRY (V1DI, TARGET_VECTOR_VLS && TARGET_VECTOR_ELEN_64)
 V

Re: [PATCH] LoongArch: Fix unintentional bash-ism in r14-3665.

2023-09-06 Thread Richard Sandiford via Gcc-patches
Yang Yujie  writes:
> gcc/ChangeLog:
>
>   * config.gcc: remove non-POSIX syntax "<<<".

OK.  Thanks for the quick fix.

Richard.

> ---
>  gcc/config.gcc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index b2fe7c7ceef..6d4c8becd28 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -5189,7 +5189,7 @@ case "${target}" in
>   if test x${parse_state} = x"abi-base"; then
>   # Base ABI type
>   case ${component} in
> - lp64d | lp64f | lp64s) 
> elem_tmp="ABI_BASE_$(tr a-z A-Z <<< ${component}),";;
> + lp64d | lp64f | lp64s) 
> elem_tmp="ABI_BASE_$(echo ${component} | tr a-z A-Z),";;
>   *)
>   echo "Unknown base ABI 
> \"${component}\" in --with-multilib-list." 1>&2
>   exit 1


[PATCH] RISC-V: Fix VSETVL PASS AVL/VL fetch bug[111295]

2023-09-06 Thread Juzhe-Zhong
Fix bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111295

PR target/111295

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc (insert_vsetvl):

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr111295.c: New test.

---
 gcc/config/riscv/riscv-vsetvl.cc  |  3 +-
 .../gcc.target/riscv/rvv/autovec/pr111295.c   | 36 +++
 2 files changed, 37 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/pr111295.c

diff --git a/gcc/config/riscv/riscv-vsetvl.cc b/gcc/config/riscv/riscv-vsetvl.cc
index e7e5c14617e..dd9aeb32b56 100644
--- a/gcc/config/riscv/riscv-vsetvl.cc
+++ b/gcc/config/riscv/riscv-vsetvl.cc
@@ -721,8 +721,7 @@ insert_vsetvl (enum emit_type emit_type, rtx_insn *rinsn,
   gcc_assert (has_vtype_op (rinsn) || vsetvl_insn_p (rinsn));
   /* For user vsetvli a5, zero, we should use get_vl to get the VL
 operand "a5".  */
-  rtx vl_op
-   = vsetvl_insn_p (rinsn) ? get_vl (rinsn) : info.get_avl_reg_rtx ();
+  rtx vl_op = info.get_avl_or_vl_reg ();
   gcc_assert (!vlmax_avl_p (vl_op));
   emit_vsetvl_insn (VSETVL_NORMAL, emit_type, info, vl_op, rinsn);
   return VSETVL_NORMAL;
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr111295.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr111295.c
new file mode 100644
index 000..fa20a21338a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr111295.c
@@ -0,0 +1,36 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -Ofast -ftree-vectorize 
--param=riscv-autovec-preference=scalable -Wno-implicit-function-declaration" } 
*/
+
+#include 
+int a, b, c, e, f, g, h, i, j, k;
+long l;
+int q ()
+{
+  int r ();
+  char *o, *d;
+  _Bool p = f;
+  while (g)
+{
+  int m, n;
+  for (; m <= n; m++)
+   *d++ = m;
+  k = 1;
+  if (e)
+   break;
+  switch (*o)
+   {
+   case 'N':
+ o++;
+ if (c)
+   if (h)
+ while (i)
+   {
+ s (-l, ~0);
+ t (j);
+ d = d + (a & 1000 ? u (r, 2) : b);
+   }
+   }
+  if (*o)
+   p ? s () : 0;
+}
+}
-- 
2.36.3



[PATCH 1/2] ARC: Use intrinsics for __builtin_add_overflow*()

2023-09-06 Thread Shahab Vahedi via Gcc-patches
This patch covers signed and unsigned additions.  The generated code
would be something along these lines:

signed:
  add.f   r0, r1, r2
  b.v @label

unsigned:
  add.f   r0, r1, r2
  b.c @label

gcc/ChangeLog:

* config/arc/arc-modes.def: Add CC_V mode.
* config/arc/predicates.md (proper_comparison_operator): Handle
E_CC_Vmode.
(equality_comparison_operator): Exclude CC_Vmode from eq/ne.
(cc_set_register): Handle CC_Vmode.
(cc_use_register): Likewise.
* config/arc/arc.md (addsi3_v): New insn.
(addvsi4): New expand.
(addsi3_c): New insn.
(uaddvsi4): New expand.
* config/arc/arc-protos.h (arc_gen_unlikely_cbranch): New.
* config/arc/arc.cc (arc_gen_unlikely_cbranch): New.
(get_arc_condition_code): Handle E_CC_Vmode.
(arc_init_reg_tables): Handle CC_Vmode.

gcc/testsuite/ChangeLog:

* gcc.target/arc/overflow-1.c: New.

Signed-off-by: Shahab Vahedi 
---
 gcc/config/arc/arc-modes.def  |   1 +
 gcc/config/arc/arc-protos.h   |   1 +
 gcc/config/arc/arc.cc |  26 +-
 gcc/config/arc/arc.md |  49 +++
 gcc/config/arc/predicates.md  |  14 ++-
 gcc/testsuite/gcc.target/arc/overflow-1.c | 100 ++
 6 files changed, 187 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arc/overflow-1.c

diff --git a/gcc/config/arc/arc-modes.def b/gcc/config/arc/arc-modes.def
index 763e880317d..69eeec5935a 100644
--- a/gcc/config/arc/arc-modes.def
+++ b/gcc/config/arc/arc-modes.def
@@ -24,6 +24,7 @@ along with GCC; see the file COPYING3.  If not see
 
 CC_MODE (CC_ZN);
 CC_MODE (CC_Z);
+CC_MODE (CC_V);
 CC_MODE (CC_C);
 CC_MODE (CC_FP_GT);
 CC_MODE (CC_FP_GE);
diff --git a/gcc/config/arc/arc-protos.h b/gcc/config/arc/arc-protos.h
index 4f2db7ffb59..bc78fb0b370 100644
--- a/gcc/config/arc/arc-protos.h
+++ b/gcc/config/arc/arc-protos.h
@@ -50,6 +50,7 @@ extern bool arc_check_mov_const (HOST_WIDE_INT );
 extern bool arc_split_mov_const (rtx *);
 extern bool arc_can_use_return_insn (void);
 extern bool arc_split_move_p (rtx *);
+extern void arc_gen_unlikely_cbranch (enum rtx_code, machine_mode, rtx);
 #endif /* RTX_CODE */
 
 extern bool arc_ccfsm_branch_deleted_p (void);
diff --git a/gcc/config/arc/arc.cc b/gcc/config/arc/arc.cc
index f8c9bf17e2c..ec93d40aeb9 100644
--- a/gcc/config/arc/arc.cc
+++ b/gcc/config/arc/arc.cc
@@ -1538,6 +1538,13 @@ get_arc_condition_code (rtx comparison)
case GEU : return ARC_CC_NC;
default : gcc_unreachable ();
}
+case E_CC_Vmode:
+  switch (GET_CODE (comparison))
+   {
+   case EQ : return ARC_CC_NV;
+   case NE : return ARC_CC_V;
+   default : gcc_unreachable ();
+   }
 case E_CC_FP_GTmode:
   if (TARGET_ARGONAUT_SET && TARGET_SPFP)
switch (GET_CODE (comparison))
@@ -1868,7 +1875,7 @@ arc_init_reg_tables (void)
  /* mode_class hasn't been initialized yet for EXTRA_CC_MODES, so
 we must explicitly check for them here.  */
  if (i == (int) CCmode || i == (int) CC_ZNmode || i == (int) CC_Zmode
- || i == (int) CC_Cmode
+ || i == (int) CC_Cmode || i == (int) CC_Vmode
  || i == CC_FP_GTmode || i == CC_FP_GEmode || i == CC_FP_ORDmode
  || i == CC_FPUmode || i == CC_FPUEmode || i == CC_FPU_UNEQmode)
arc_mode_class[i] = 1 << (int) C_MODE;
@@ -11852,6 +11859,23 @@ arc_libm_function_max_error (unsigned cfn, 
machine_mode mode,
   return default_libm_function_max_error (cfn, mode, boundary_p);
 }
 
+/* Generate RTL for conditional branch with rtx comparison CODE in mode
+   CC_MODE.  */
+
+void
+arc_gen_unlikely_cbranch (enum rtx_code cmp, machine_mode cc_mode, rtx label)
+{
+  rtx cc_reg, x;
+
+  cc_reg = gen_rtx_REG (cc_mode, CC_REG);
+  label = gen_rtx_LABEL_REF (VOIDmode, label);
+
+  x = gen_rtx_fmt_ee (cmp, VOIDmode, cc_reg, const0_rtx);
+  x = gen_rtx_IF_THEN_ELSE (VOIDmode, x, label, pc_rtx);
+
+  emit_unlikely_jump (gen_rtx_SET (pc_rtx, x));
+}
+
 #undef TARGET_USE_ANCHORS_FOR_SYMBOL_P
 #define TARGET_USE_ANCHORS_FOR_SYMBOL_P arc_use_anchors_for_symbol_p
 
diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
index d37ecbf4292..9d011f6b4a9 100644
--- a/gcc/config/arc/arc.md
+++ b/gcc/config/arc/arc.md
@@ -2725,6 +2725,55 @@ archs4x, archs4xd"
  }
   ")
 
+(define_insn "addsi3_v"
+ [(set (match_operand:SI 0 "register_operand"  "=r,r,r,  r")
+   (plus:SI (match_operand:SI 1 "register_operand"   "r,r,0,  r")
+   (match_operand:SI 2 "nonmemory_operand"  "r,L,I,C32")))
+  (set (reg:CC_V CC_REG)
+   (compare:CC_V (sign_extend:DI (plus:SI (match_dup 1)
+ (match_dup 2)))
+(plus:DI (sign_extend:DI (match_dup 1))
+ (sign_extend:DI (match_dup 2)]
+ ""
+ "add.f\\t%0,%1,%2"
+ [(set_attr "

[PATCH 2/2] ARC: Use intrinsics for __builtin_sub_overflow*()

2023-09-06 Thread Shahab Vahedi via Gcc-patches
This patch covers signed and unsigned subtractions.  The generated code
would be something along these lines:

signed:
  sub.f   r0, r1, r2
  b.v @label

unsigned:
  sub.f   r0, r1, r2
  b.c @label

gcc/ChangeLog:

* config/arc/arc.md (subsi3_v): New insn.
(subvsi4): New expand.
(subsi3_c): New insn.
(usubvsi4): New expand.

gcc/testsuite/ChangeLog:

* gcc.target/arc/overflow-2.c: New.

Signed-off-by: Shahab Vahedi 
---
 gcc/config/arc/arc.md | 48 +++
 gcc/testsuite/gcc.target/arc/overflow-2.c | 97 +++
 2 files changed, 145 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/arc/overflow-2.c

diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
index 9d011f6b4a9..34e9e1a7f1d 100644
--- a/gcc/config/arc/arc.md
+++ b/gcc/config/arc/arc.md
@@ -2973,6 +2973,54 @@ archs4x, archs4xd"
   (set_attr "cpu_facility" "*,cd,*,*,*,*,*,*,*,*")
   ])
 
+(define_insn "subsi3_v"
+  [(set (match_operand:SI  0 "register_operand"  "=r,r,r,  r")
+   (minus:SI (match_operand:SI 1 "register_operand"   "r,r,0,  r")
+ (match_operand:SI 2 "nonmemory_operand"  "r,L,I,C32")))
+   (set (reg:CC_V CC_REG)
+   (compare:CC_V (sign_extend:DI (minus:SI (match_dup 1)
+   (match_dup 2)))
+ (minus:DI (sign_extend:DI (match_dup 1))
+   (sign_extend:DI (match_dup 2)]
+   ""
+   "sub.f\\t%0,%1,%2"
+   [(set_attr "cond"   "set")
+(set_attr "type"   "compare")
+(set_attr "length" "4,4,4,8")])
+
+(define_expand "subvsi4"
+ [(match_operand:SI 0 "register_operand")
+  (match_operand:SI 1 "register_operand")
+  (match_operand:SI 2 "nonmemory_operand")
+  (label_ref (match_operand 3 "" ""))]
+  ""
+  "emit_insn (gen_subsi3_v (operands[0], operands[1], operands[2]));
+   arc_gen_unlikely_cbranch (NE, CC_Vmode, operands[3]);
+   DONE;")
+
+(define_insn "subsi3_c"
+  [(set (match_operand:SI  0 "register_operand"  "=r,r,r,  r")
+   (minus:SI (match_operand:SI 1 "register_operand"   "r,r,0,  r")
+ (match_operand:SI 2 "nonmemory_operand"  "r,L,I,C32")))
+   (set (reg:CC_C CC_REG)
+   (compare:CC_C (match_dup 1)
+ (match_dup 2)))]
+   ""
+   "sub.f\\t%0,%1,%2"
+   [(set_attr "cond"   "set")
+(set_attr "type"   "compare")
+(set_attr "length" "4,4,4,8")])
+
+(define_expand "usubvsi4"
+  [(match_operand:SI 0 "register_operand")
+   (match_operand:SI 1 "register_operand")
+   (match_operand:SI 2 "nonmemory_operand")
+   (label_ref (match_operand 3 "" ""))]
+   ""
+   "emit_insn (gen_subsi3_c (operands[0], operands[1], operands[2]));
+arc_gen_unlikely_cbranch (LTU, CC_Cmode, operands[3]);
+DONE;")
+
 (define_expand "subdi3"
   [(set (match_operand:DI 0 "register_operand" "")
(minus:DI (match_operand:DI 1 "register_operand" "")
diff --git a/gcc/testsuite/gcc.target/arc/overflow-2.c 
b/gcc/testsuite/gcc.target/arc/overflow-2.c
new file mode 100644
index 000..b4de8c03b22
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arc/overflow-2.c
@@ -0,0 +1,97 @@
+/* { dg-do compile } */
+/* { dg-options "-O1" } */
+
+#include 
+#include 
+
+/*
+ * sub.f  r0,r0,r1
+ * st_s   r0,[r2]
+ * mov_s  r0,1
+ * j_s.d  [blink]
+ * mov.nv r0,0
+ */
+bool sub_overflow (int32_t a, int32_t b, int32_t *res)
+{
+  return __builtin_sub_overflow (a, b, res);
+}
+
+/*
+ * sub.f  r0,r0,-1234
+ * st_s   r0,[r1]
+ * mov_s  r0,1
+ * j_s.d  [blink]
+ * mov.nv r0,0
+ */
+bool subi_overflow (int32_t a, int32_t *res)
+{
+  return __builtin_sub_overflow (a, -1234, res);
+}
+
+/*
+ * sub.f  r3,r0,r1
+ * st_s   r3,[r2]
+ * j_s.d  [blink]
+ * setlo  r0,r0,r1
+ */
+bool usub_overflow (uint32_t a, uint32_t b, uint32_t *res)
+{
+  return __builtin_sub_overflow (a, b, res);
+}
+
+/*
+ * sub.f  r2,r0,4321
+ * seths  r0,4320,r0
+ * j_s.d  [blink]
+ * st_s   r2,[r1]
+ */
+bool usubi_overflow (uint32_t a, uint32_t *res)
+{
+  return __builtin_sub_overflow (a, 4321, res);
+}
+
+/*
+ * sub.f  r0,r0,r1
+ * mov_s  r0,1
+ * j_s.d  [blink]
+ * mov.nv r0,0
+ */
+bool sub_overflow_p (int32_t a, int32_t b, int32_t res)
+{
+  return __builtin_sub_overflow_p (a, b, res);
+}
+
+/*
+ * sub.f  r0,r0,-1000
+ * mov_s  r0,1
+ * j_s.d  [blink]
+ * mov.nv r0,0
+ */
+bool subi_overflow_p (int32_t a, int32_t res)
+{
+  return __builtin_sub_overflow_p (a, -1000, res);
+}
+
+/*
+ * j_s.d  [blink]
+ * setlo  r0,r0,r1
+ */
+bool usub_overflow_p (uint32_t a, uint32_t b, uint32_t res)
+{
+  return __builtin_sub_overflow_p (a, b, res);
+}
+
+/*
+ * seths  r0,1999,r0
+ * j_s.d  [blink]
+ */
+bool usubi_overflow_p (uint32_t a, uint32_t res)
+{
+  return __builtin_sub_overflow_p (a, 2000, res);
+}
+
+/* { dg-final { scan-assembler-times "sub.f\\s\+"   6 } } */
+/* { dg-final { scan-assembler-times "mov\.nv\\s\+" 4 } } */
+/* { dg-final { scan-assembler-times "setlo\\s\+"   2 } } */
+/* { dg-final { scan-assembler-times "seths\\s\

[PATCH v1] RISC-V: Fix incorrect folder for VRGATHERI16 test case

2023-09-06 Thread Pan Li via Gcc-patches
From: Pan Li 

Put the test file to the incorrect folder, this patch would like to
fix it.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/intrisinc-vrgatherei16.c: Moved to...
* gcc.target/riscv/rvv/base/intrisinc-vrgatherei16.c: ...here.

Signed-off-by: Pan Li 
---
 .../gcc.target/riscv/rvv/{ => base}/intrisinc-vrgatherei16.c  | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename gcc/testsuite/gcc.target/riscv/rvv/{ => base}/intrisinc-vrgatherei16.c 
(100%)

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/intrisinc-vrgatherei16.c 
b/gcc/testsuite/gcc.target/riscv/rvv/base/intrisinc-vrgatherei16.c
similarity index 100%
rename from gcc/testsuite/gcc.target/riscv/rvv/intrisinc-vrgatherei16.c
rename to gcc/testsuite/gcc.target/riscv/rvv/base/intrisinc-vrgatherei16.c
-- 
2.34.1



RE: [PATCH v1] RISC-V: Fix incorrect folder for VRGATHERI16 test case

2023-09-06 Thread Li, Pan2 via Gcc-patches
Committed, thanks Juzhe and sorry for my silly mistake.

Pan

From: juzhe.zhong 
Sent: Wednesday, September 6, 2023 8:53 PM
To: Li, Pan2 
Cc: gcc-patches@gcc.gnu.org; Li, Pan2 ; Wang, Yanzhang 
; kito.ch...@gmail.com
Subject: Re: [PATCH v1] RISC-V: Fix incorrect folder for VRGATHERI16 test case

lgtm
 Replied Message 
From
pan2...@intel.com
Date
09/06/2023 20:52
To
gcc-patches@gcc.gnu.org
Cc
juzhe.zh...@rivai.ai,
pan2...@intel.com,
yanzhang.w...@intel.com,
kito.ch...@gmail.com
Subject
[PATCH v1] RISC-V: Fix incorrect folder for VRGATHERI16 test case



Re: [PATCH V2] RISC-V: Support Dynamic LMUL Cost model

2023-09-06 Thread Robin Dapp via Gcc-patches
Hi Juzhe,

general remark upfront:  Please add function-level comments for all
functions.  This makes reading and reviewing much easier.  I had to sweep
back and forth quite a bit.

> +
> +static int
> +get_last_live_range (const vec &live_ranges, tree var)
> +{
> +  unsigned int ix;
> +  var_live_range *live_range;
> +  FOR_EACH_VEC_ELT_REVERSE (live_ranges, ix, live_range)
> +if (live_range->var == var)
> +  return ix;
> +  return -1;
> +}

>From reading the usage site of this function it looks like we could benefit
from having the live ranges be a hash_map as well?  That way we wouldn't
need to scan through the list every time.  Something like
hash_map>.  It looks like we only consider the range
end anyway.

> +   int index = get_last_live_range (live_ranges, var);

That way we could avoid some worst-case behavior here for pathological
inputs.

> +   if (index == -1)
> + {
> +   var_live_range range = {var, 0, point};
> +   live_ranges.safe_push (range);
> + }

Please add a comment that we assume the variable is live from the start
of this block. 

> +   else
> + live_ranges[index].end = point;

And here a comment that we will grow the live range for each use.

> +static bool
> +live_range_conflict_p (const var_live_range &live_range1,
> +const var_live_range &live_range2)
> +{
> +  if (live_range1.start >= live_range2.end)
> +return false;
> +  if (live_range1.end <= live_range2.start)
> +return false;
> +  if (live_range2.start >= live_range1.end)
> +return false;
> +  if (live_range2.end <= live_range1.start)
> +return false;
> +  return true;
> +}

Rename to live_range_overlap_p and simplify to
 return a.end >= b.start || b.end >= a.start;

> +
> +static unsigned int
> +max_number_of_live_regs (const basic_block bb,
> +  const vec &live_ranges,
> +  machine_mode biggest_mode, int lmul)
> +{
> +  unsigned int max_nregs = 0;
> +  unsigned int i, j, k;
> +  unsigned int live_point = 0;
> +  for (i = 0; i < live_ranges.length (); i++)
> +{
> +  auto_vec conflict_live_ranges;
> +  var_live_range live_range = live_ranges[i];
> +  conflict_live_ranges.safe_push (live_range);
> +  unsigned int min_point = live_range.start;
> +  unsigned int max_point = live_range.end;
> +  for (j = 0; j < live_ranges.length (); j++)
> + {
> +   if (j == i)
> + continue;
> +   if (live_range_conflict_p (live_range, live_ranges[j]))
> + {
> +   conflict_live_ranges.safe_push (live_ranges[j]);
> +   min_point
> + = std::min (min_point, (unsigned int) live_ranges[j].start);
> +   max_point
> + = std::max (max_point, (unsigned int) live_ranges[j].end);
> + }
> + }
> +  for (j = min_point; j <= max_point; j++)
> + {
> +   unsigned int nregs = 0;
> +   for (k = 0; k < conflict_live_ranges.length (); k++)
> + {
> +   if (j >= (unsigned int) conflict_live_ranges[k].start
> +   && j <= (unsigned int) conflict_live_ranges[k].end)
> + {
> +   machine_mode mode
> + = TYPE_MODE (TREE_TYPE (conflict_live_ranges[k].var));
> +   nregs += compute_nregs_for_mode (mode, biggest_mode, lmul);
> + }
> + }
> +   if (nregs > max_nregs)
> + {
> +   max_nregs = nregs;
> +   live_point = j;
> + }
> + }
> +}

This looks pretty quadratic in the number of live ranges (or even cubic?).
Can't it be done more efficiently using a sliding-window approach by sorting
the live ranges according to their start point before?
Also std::min/max -> MIN/MAX.

> +
> +  /* Collect user explicit RVV type.  */
> +  hash_set all_preds = get_all_predecessors (bb);
> +  hash_set all_succs = get_all_successors (bb);

As mentioned before, maybe dominator info could help here?

> +  for (i = 0; i < cfun->gimple_df->ssa_names->length (); i++)
> +{
> +  tree t = ssa_name (i);
> +  if (!t)
> + continue;
> +  machine_mode mode = TYPE_MODE (TREE_TYPE (t));
> +  if (!lookup_vector_type_attribute (TREE_TYPE (t))
> +   && !riscv_v_ext_vls_mode_p (mode))
> + continue;
> +
> +  gimple *def = SSA_NAME_DEF_STMT (t);
> +  if (gimple_bb (def) && !all_preds.contains (gimple_bb (def)))
> + continue;
> +  const ssa_use_operand_t *const head = &(SSA_NAME_IMM_USE_NODE (t));
> +  const ssa_use_operand_t *ptr;
> +
> +  for (ptr = head->next; ptr != head; ptr = ptr->next)
> + {
> +   if (USE_STMT (ptr) && !is_gimple_debug (USE_STMT (ptr)))
> + {
> +   if (all_succs.contains (gimple_bb (USE_STMT (ptr
> + {

Reverse the conditions and continue, i.e. if (!USE_STMT || is_gimple_debug
 || !all_succs.contains).

>

Re: [PATCH v3] RISC-V: Add autovec FP binary operations.

2023-09-06 Thread Robin Dapp via Gcc-patches


Hi Lehua,

> May I ask if the compiler options "-march=rv64gcv_zvfh -mabi=lp64d"
> should be removed? Because we don't specify -march and -mabi when we
> run testcase (so but why we need to specify the -march and -mabi in
> this target check?), we run it with the default values. Assuming that
> the default is rv64gcv_zvfh_zfh, `riscv_vector` check will fail
> because compile and link with -march=rv64gcv will throw the following
> error if I doesn't compile a multilibs compilers. But in fact
> rv64gcv_zvfh_zfh contains rv64gcv, we should not let this case report
> link error.:

Yes, you're right, this should not be necessary.  This is more of a
test for the execution environment than the compiler.  I think Juzhe
removed it already in his patch that enables the vector test suite.
In the future we would use the checks that Joern added, not sure if
they are already upstream.

Regards
 Robin



Re: [PATCH] RISC-V: Fix VSETVL PASS AVL/VL fetch bug[111295]

2023-09-06 Thread Robin Dapp via Gcc-patches
OK.

Regards
 Robin


Re: [PATCH] RISC-V: Remove unreasonable TARGET_64BIT for VLS modes with size = 64bit

2023-09-06 Thread Robin Dapp via Gcc-patches
LGTM.

Regards
 Robin



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

2023-09-06 Thread David Malcolm via Gcc-patches
As part of Antoyo's work on supporting LTO in rustc_codegen_gcc, he
noticed an ICE inside libgccjit when compiling certain rust files.

Debugging libgccjit showed that outdated information from a previous
in-memory compile was referring to ad-hoc locations in the previous
compile's line_table.

The issue turned out to be the function decls in internal_fn_fnspec_array
from the previous compile keeping alive the symtab nodes for these
functions, and from this finding other functions in the previous
compile, walking their CFGs, and finding ad-hoc data pointers in an edge
with a location_t using ad-hoc data from the previous line_table
instance, and thus a use-after-free ICE attempting to use this ad-hoc
data.

Previously in toplev::finalize we've fixed global state "piecemeal" by
calling out to individual source_name_cc_finalize functions.  However,
it occurred to me that we have run-time information on where the
GTY-marked pointers are.

Hence this patch takes something of a "big hammer" approach by adding a
new ggc_common_finalize that walks the GC roots, zeroing all of the
pointers.  I stepped through this in the debugger and observed that, in
particular, this correctly zeroes the internal_fn_fnspec_array at the end
of a libgccjit compile.  Antoyo reports that this fixes the ICE for him.
Doing so uncovered an ICE with libgccjit in dwarf2cfi.cc due to reuse of
global variables from the previous compile, which this patch also fixes.

I noticed that in ggc_mark_roots when clearing deletable roots we only
clear the initial element in each gcc_root_tab_t.  This looks like a
latent bug to me, which the patch fixes.  That said, there don't seem to
be any deletable roots where the number of elements != 1.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

OK for trunk?

Thanks
Dave

gcc/ChangeLog:
* dwarf2cfi.cc (dwarf2cfi_cc_finalize): New.
* dwarf2out.h (dwarf2cfi_cc_finalize): New decl.
* ggc-common.cc (ggc_mark_roots): Multiply by rti->nelt when
clearing the deletable gcc_root_tab_t.
(ggc_common_finalize): New.
* ggc.h (ggc_common_finalize): New decl.
* toplev.cc (toplev::finalize): Call dwarf2cfi_cc_finalize and
ggc_common_finalize.
---
 gcc/dwarf2cfi.cc  |  9 +
 gcc/dwarf2out.h   |  1 +
 gcc/ggc-common.cc | 23 ++-
 gcc/ggc.h |  2 ++
 gcc/toplev.cc |  3 +++
 5 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/gcc/dwarf2cfi.cc b/gcc/dwarf2cfi.cc
index ddc728f4ad00..f1777c0a4cf1 100644
--- a/gcc/dwarf2cfi.cc
+++ b/gcc/dwarf2cfi.cc
@@ -3822,4 +3822,13 @@ make_pass_dwarf2_frame (gcc::context *ctxt)
   return new pass_dwarf2_frame (ctxt);
 }
 
+void dwarf2cfi_cc_finalize ()
+{
+  add_cfi_insn = NULL;
+  add_cfi_vec = NULL;
+  cur_trace = NULL;
+  cur_row = NULL;
+  cur_cfa = NULL;
+}
+
 #include "gt-dwarf2cfi.h"
diff --git a/gcc/dwarf2out.h b/gcc/dwarf2out.h
index 870b56a6a372..61a996050ff9 100644
--- a/gcc/dwarf2out.h
+++ b/gcc/dwarf2out.h
@@ -419,6 +419,7 @@ struct fixed_point_type_info
 } scale_factor;
 };
 
+void dwarf2cfi_cc_finalize (void);
 void dwarf2out_cc_finalize (void);
 
 /* Some DWARF internals are exposed for the needs of DWARF-based debug
diff --git a/gcc/ggc-common.cc b/gcc/ggc-common.cc
index bed7a9d4d021..95803fa95a17 100644
--- a/gcc/ggc-common.cc
+++ b/gcc/ggc-common.cc
@@ -86,7 +86,7 @@ ggc_mark_roots (void)
 
   for (rt = gt_ggc_deletable_rtab; *rt; rt++)
 for (rti = *rt; rti->base != NULL; rti++)
-  memset (rti->base, 0, rti->stride);
+  memset (rti->base, 0, rti->stride * rti->nelt);
 
   for (rt = gt_ggc_rtab; *rt; rt++)
 ggc_mark_root_tab (*rt);
@@ -1293,3 +1293,24 @@ report_heap_memory_use ()
 SIZE_AMOUNT (MALLINFO_FN ().arena));
 #endif
 }
+
+/* Forcibly clear all GTY roots.  */
+
+void
+ggc_common_finalize ()
+{
+  const struct ggc_root_tab *const *rt;
+  const_ggc_root_tab_t rti;
+
+  for (rt = gt_ggc_deletable_rtab; *rt; rt++)
+for (rti = *rt; rti->base != NULL; rti++)
+  memset (rti->base, 0, rti->stride * rti->nelt);
+
+  for (rt = gt_ggc_rtab; *rt; rt++)
+for (rti = *rt; rti->base != NULL; rti++)
+  memset (rti->base, 0, rti->stride * rti->nelt);
+
+  for (rt = gt_pch_scalar_rtab; *rt; rt++)
+for (rti = *rt; rti->base != NULL; rti++)
+  memset (rti->base, 0, rti->stride * rti->nelt);
+}
diff --git a/gcc/ggc.h b/gcc/ggc.h
index 34108e2f0061..3280314f8481 100644
--- a/gcc/ggc.h
+++ b/gcc/ggc.h
@@ -368,4 +368,6 @@ inline void gt_ggc_mx (unsigned long int) { }
 inline void gt_ggc_mx (long long int) { }
 inline void gt_ggc_mx (unsigned long long int) { }
 
+extern void ggc_common_finalize ();
+
 #endif
diff --git a/gcc/toplev.cc b/gcc/toplev.cc
index 6c1a6f443c16..db62e3e995ec 100644
--- a/gcc/toplev.cc
+++ b/gcc/toplev.cc
@@ -2336,6 +2336,7 @@ toplev::finalize (void)
   cgraph_cc_finalize ();
   cgraphunit_cc_finalize ();
   symtab_thunks_cc_finalize ();
+  dwarf2cfi_cc_finalize ();
   dwarf2out_cc_fin

[pushed] analyzer: add ctxt to fill_region/zero_fill_region

2023-09-06 Thread David Malcolm via Gcc-patches
I noticed that region_model's fill_region/zero_fill_region member
functions weren't checking that the write to the region was valid.

Fixed thusly.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-3739-gb923978a6ec447.

gcc/analyzer/ChangeLog:
* kf.cc (kf_calloc::impl_call_pre): Pass ctxt to zero_fill_region.
(kf_memset::impl_call_pre): Move responsibility for calling
check_region_for_write to fill_region.
* region-model.cc (region_model::on_assignment): Pass ctxt to
zero_fill_region.
(region_model::fill_region): Add "ctxt" param, using it to call
check_region_for_write.
(region_model::zero_fill_region): Likewise.
* region-model.h (region_model::fill_region): Add "ctxt" param.
(region_model::zero_fill_region): Likewise.

gcc/testsuite/ChangeLog:
* gcc.dg/plugin/analyzer_cpython_plugin.c: Pass ctxt to
zero_fill_region.
---
 gcc/analyzer/kf.cc|  7 ++-
 gcc/analyzer/region-model.cc  | 19 ++-
 gcc/analyzer/region-model.h   |  7 +--
 .../gcc.dg/plugin/analyzer_cpython_plugin.c   |  2 +-
 4 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/gcc/analyzer/kf.cc b/gcc/analyzer/kf.cc
index e5bd7459f271..a62227729991 100644
--- a/gcc/analyzer/kf.cc
+++ b/gcc/analyzer/kf.cc
@@ -358,7 +358,7 @@ kf_calloc::impl_call_pre (const call_details &cd) const
 = model->get_or_create_region_for_heap_alloc (prod_sval, cd.get_ctxt ());
   const region *sized_reg
 = mgr->get_sized_region (new_reg, NULL_TREE, prod_sval);
-  model->zero_fill_region (sized_reg);
+  model->zero_fill_region (sized_reg, cd.get_ctxt ());
   if (cd.get_lhs_type ())
 {
   const svalue *ptr_sval
@@ -650,10 +650,7 @@ kf_memset::impl_call_pre (const call_details &cd) const
   const region *sized_dest_reg = mgr->get_sized_region (dest_reg,
NULL_TREE,
num_bytes_sval);
-  model->check_region_for_write (sized_dest_reg,
-nullptr,
-cd.get_ctxt ());
-  model->fill_region (sized_dest_reg, fill_value_u8);
+  model->fill_region (sized_dest_reg, fill_value_u8, cd.get_ctxt ());
 
   cd.maybe_set_lhs (dest_sval);
 }
diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index 82bc3b2c3826..6be0ad72aaae 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -1204,7 +1204,7 @@ region_model::on_assignment (const gassign *assign, 
region_model_context *ctxt)
/* Any CONSTRUCTOR that survives to this point is either
   just a zero-init of everything, or a vector.  */
if (!CONSTRUCTOR_NO_CLEARING (rhs1))
- zero_fill_region (lhs_reg);
+ zero_fill_region (lhs_reg, ctxt);
unsigned ix;
tree index;
tree val;
@@ -3929,19 +3929,28 @@ region_model::purge_region (const region *reg)
   m_store.purge_region (m_mgr->get_store_manager(), reg);
 }
 
-/* Fill REG with SVAL.  */
+/* Fill REG with SVAL.
+   Use CTXT to report any warnings associated with the write
+   (e.g. out-of-bounds).  */
 
 void
-region_model::fill_region (const region *reg, const svalue *sval)
+region_model::fill_region (const region *reg,
+  const svalue *sval,
+  region_model_context *ctxt)
 {
+  check_region_for_write (reg, nullptr, ctxt);
   m_store.fill_region (m_mgr->get_store_manager(), reg, sval);
 }
 
-/* Zero-fill REG.  */
+/* Zero-fill REG.
+   Use CTXT to report any warnings associated with the write
+   (e.g. out-of-bounds).  */
 
 void
-region_model::zero_fill_region (const region *reg)
+region_model::zero_fill_region (const region *reg,
+   region_model_context *ctxt)
 {
+  check_region_for_write (reg, nullptr, ctxt);
   m_store.zero_fill_region (m_mgr->get_store_manager(), reg);
 }
 
diff --git a/gcc/analyzer/region-model.h b/gcc/analyzer/region-model.h
index bb50ff12b12e..625f68805361 100644
--- a/gcc/analyzer/region-model.h
+++ b/gcc/analyzer/region-model.h
@@ -370,8 +370,11 @@ class region_model
   void set_value (tree lhs, tree rhs, region_model_context *ctxt);
   void clobber_region (const region *reg);
   void purge_region (const region *reg);
-  void fill_region (const region *reg, const svalue *sval);
-  void zero_fill_region (const region *reg);
+  void fill_region (const region *reg,
+   const svalue *sval,
+   region_model_context *ctxt);
+  void zero_fill_region (const region *reg,
+region_model_context *ctxt);
   void write_bytes (const region *dest_reg,
const svalue *num_bytes_sval,
const svalue *sval,
diff --git a/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.c 
b/gcc/

[pushed] analyzer: implement kf_strncpy [PR105899]

2023-09-06 Thread David Malcolm via Gcc-patches
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-3740-gb51cde34d4e750.

gcc/analyzer/ChangeLog:
PR analyzer/105899
* kf.cc (class kf_strncpy): New.
(kf_strncpy::impl_call_post): New.
(register_known_functions): Register it.
* region-model.cc (region_model::read_bytes): Handle unknown
number of bytes.

gcc/testsuite/ChangeLog:
PR analyzer/105899
* c-c++-common/analyzer/null-terminated-strings-2.c: New test.
* c-c++-common/analyzer/overlapping-buffers.c: Update dg-bogus
directives to avoid clashing with note from  that might
happen to have the same line number.  Add strpncpy test coverage.
* c-c++-common/analyzer/strncpy-1.c: New test.
* gcc.dg/analyzer/null-terminated-strings-1.c
(test_filled_nonzero): New.
(void test_filled_zero): New.
(test_filled_symbolic): New.
---
 gcc/analyzer/kf.cc| 182 ++
 gcc/analyzer/region-model.cc  |   2 +
 .../analyzer/null-terminated-strings-2.c  |  17 ++
 .../analyzer/overlapping-buffers.c|  24 ++-
 .../c-c++-common/analyzer/strncpy-1.c | 157 +++
 .../analyzer/null-terminated-strings-1.c  |  24 +++
 6 files changed, 398 insertions(+), 8 deletions(-)
 create mode 100644 
gcc/testsuite/c-c++-common/analyzer/null-terminated-strings-2.c
 create mode 100644 gcc/testsuite/c-c++-common/analyzer/strncpy-1.c

diff --git a/gcc/analyzer/kf.cc b/gcc/analyzer/kf.cc
index a62227729991..8a45c329c282 100644
--- a/gcc/analyzer/kf.cc
+++ b/gcc/analyzer/kf.cc
@@ -1375,6 +1375,186 @@ make_kf_strlen ()
   return make_unique ();
 }
 
+/* Handler for "strncpy" and "__builtin_strncpy".
+   See e.g. https://en.cppreference.com/w/c/string/byte/strncpy
+
+ extern char *strncpy (char *dst, const char *src, size_t count);
+
+   Handle this by splitting into two outcomes:
+   (a) truncated read from "src" of "count" bytes,
+   writing "count" bytes to "dst"
+   (b) read from "src" of up to (and including) the null terminator,
+   where the number of bytes read < "count" bytes,
+   writing those bytes to "dst", and zero-filling the rest,
+   up to "count".  */
+
+class kf_strncpy : public builtin_known_function
+{
+public:
+  bool matches_call_types_p (const call_details &cd) const final override
+  {
+return (cd.num_args () == 3
+   && cd.arg_is_pointer_p (0)
+   && cd.arg_is_pointer_p (1)
+   && cd.arg_is_integral_p (2));
+  }
+  enum built_in_function builtin_code () const final override
+  {
+return BUILT_IN_STRNCPY;
+  }
+  void impl_call_post (const call_details &cd) const final override;
+};
+
+void
+kf_strncpy::impl_call_post (const call_details &cd) const
+{
+  class strncpy_call_info : public call_info
+  {
+  public:
+strncpy_call_info (const call_details &cd,
+  const svalue *num_bytes_with_terminator_sval,
+  bool truncated_read)
+: call_info (cd),
+  m_num_bytes_with_terminator_sval (num_bytes_with_terminator_sval),
+  m_truncated_read (truncated_read)
+{
+}
+
+label_text get_desc (bool can_colorize) const final override
+{
+  if (m_truncated_read)
+   return make_label_text (can_colorize,
+   "when %qE truncates the source string",
+   get_fndecl ());
+  else
+   return make_label_text (can_colorize,
+   "when %qE copies the full source string",
+   get_fndecl ());
+}
+
+bool update_model (region_model *model,
+  const exploded_edge *,
+  region_model_context *ctxt) const final override
+{
+  const call_details cd (get_call_details (model, ctxt));
+
+  const svalue *dest_sval = cd.get_arg_svalue (0);
+  const region *dest_reg
+   = model->deref_rvalue (dest_sval, cd.get_arg_tree (0), ctxt);
+
+  const svalue *src_sval = cd.get_arg_svalue (1);
+  const region *src_reg
+   = model->deref_rvalue (src_sval, cd.get_arg_tree (1), ctxt);
+
+  const svalue *count_sval = cd.get_arg_svalue (2);
+
+  /* strncpy returns the initial param.  */
+  cd.maybe_set_lhs (dest_sval);
+
+  const svalue *num_bytes_read_sval;
+  if (m_truncated_read)
+   {
+ /* Truncated read.  */
+ num_bytes_read_sval = count_sval;
+
+ if (m_num_bytes_with_terminator_sval)
+   {
+ /* The terminator is after the limit.  */
+ if (!model->add_constraint (m_num_bytes_with_terminator_sval,
+ GT_EXPR,
+ count_sval,
+ ctxt))
+   return false;
+   }
+ else
+   {
+ /* We don't know where the terminator is, or i

[pushed] analyzer: implement kf_strstr [PR105899]

2023-09-06 Thread David Malcolm via Gcc-patches
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-3741-gf2d7a4001a3388.

gcc/analyzer/ChangeLog:
PR analyzer/105899
* kf.cc (class kf_strstr): New.
(kf_strstr::impl_call_post): New.
(register_known_functions): Register it.

gcc/testsuite/ChangeLog:
PR analyzer/105899
* c-c++-common/analyzer/strstr-1.c: New test.
---
 gcc/analyzer/kf.cc| 96 +++
 .../c-c++-common/analyzer/strstr-1.c  | 54 +++
 2 files changed, 150 insertions(+)
 create mode 100644 gcc/testsuite/c-c++-common/analyzer/strstr-1.c

diff --git a/gcc/analyzer/kf.cc b/gcc/analyzer/kf.cc
index 8a45c329c282..92959891fe44 100644
--- a/gcc/analyzer/kf.cc
+++ b/gcc/analyzer/kf.cc
@@ -1585,6 +1585,100 @@ public:
   }
 };
 
+/* Handler for "strstr" and "__builtin_strstr".
+ extern char *strstr (const char* str, const char* substr);
+   See e.g. https://en.cppreference.com/w/c/string/byte/strstr  */
+
+class kf_strstr : public builtin_known_function
+{
+public:
+  bool matches_call_types_p (const call_details &cd) const final override
+  {
+return (cd.num_args () == 2
+   && cd.arg_is_pointer_p (0)
+   && cd.arg_is_pointer_p (1));
+  }
+  enum built_in_function builtin_code () const final override
+  {
+return BUILT_IN_STRSTR;
+  }
+  void impl_call_pre (const call_details &cd) const final override
+  {
+cd.check_for_null_terminated_string_arg (0);
+cd.check_for_null_terminated_string_arg (1);
+  }
+  void impl_call_post (const call_details &cd) const final override;
+};
+
+void
+kf_strstr::impl_call_post (const call_details &cd) const
+{
+  class strstr_call_info : public call_info
+  {
+  public:
+strstr_call_info (const call_details &cd, bool found)
+: call_info (cd), m_found (found)
+{
+}
+
+label_text get_desc (bool can_colorize) const final override
+{
+  if (m_found)
+   return make_label_text (can_colorize,
+   "when %qE returns non-NULL",
+   get_fndecl ());
+  else
+   return make_label_text (can_colorize,
+   "when %qE returns NULL",
+   get_fndecl ());
+}
+
+bool update_model (region_model *model,
+  const exploded_edge *,
+  region_model_context *ctxt) const final override
+{
+  const call_details cd (get_call_details (model, ctxt));
+  if (tree lhs_type = cd.get_lhs_type ())
+   {
+ region_model_manager *mgr = model->get_manager ();
+ const svalue *result;
+ if (m_found)
+   {
+ const svalue *str_sval = cd.get_arg_svalue (0);
+ const region *str_reg
+   = model->deref_rvalue (str_sval, cd.get_arg_tree (0),
+  cd.get_ctxt ());
+ /* We want str_sval + OFFSET for some unknown OFFSET.
+Use a conjured_svalue to represent the offset,
+using the str_reg as the id of the conjured_svalue.  */
+ const svalue *offset
+   = mgr->get_or_create_conjured_svalue (size_type_node,
+ cd.get_call_stmt (),
+ str_reg,
+ conjured_purge (model,
+ ctxt));
+ result = mgr->get_or_create_binop (lhs_type, POINTER_PLUS_EXPR,
+str_sval, offset);
+   }
+ else
+   result = mgr->get_or_create_int_cst (lhs_type, 0);
+ cd.maybe_set_lhs (result);
+   }
+  return true;
+}
+  private:
+bool m_found;
+  };
+
+  /* Body of kf_strstr::impl_call_post.  */
+  if (cd.get_ctxt ())
+{
+  cd.get_ctxt ()->bifurcate (make_unique (cd, false));
+  cd.get_ctxt ()->bifurcate (make_unique (cd, true));
+  cd.get_ctxt ()->terminate_path ();
+}
+}
+
 class kf_ubsan_bounds : public internal_known_function
 {
   /* Empty.  */
@@ -1806,6 +1900,8 @@ register_known_functions (known_function_manager &kfm)
 kfm.add ("__builtin_strndup", make_unique ());
 kfm.add ("strlen", make_unique ());
 kfm.add ("__builtin_strlen", make_unique ());
+kfm.add ("strstr", make_unique ());
+kfm.add ("__builtin_strstr", make_unique ());
 
 register_atomic_builtins (kfm);
 register_varargs_builtins (kfm);
diff --git a/gcc/testsuite/c-c++-common/analyzer/strstr-1.c 
b/gcc/testsuite/c-c++-common/analyzer/strstr-1.c
new file mode 100644
index ..469e6a817d0d
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/analyzer/strstr-1.c
@@ -0,0 +1,54 @@
+/* See e.g. https://en.cppreference.com/w/c/string/byte/strstr  */
+
+/* { dg-additional-options "-fpermissive" { target c++ } } */
+
+#include "../.

[PATCHSET] Add error metadata to diagnostics

2023-09-06 Thread Arthur Cohen
This short patchset from David Malcolm enables errors to contain extra
metadata - this is particularly useful for the Rust frontend, which will
rely on that implementation to emit standard Rust error codes [1].

This series of patches is necessary for much of our more recent
additions to the frontend, including the work of one of this year's GSoC
student, Mahad Muhammad, who has spent a lot of time working on emitting
these error codes from the Rust frontend for GCC.

We will soon resume upstreaming patches from our development repository
to the main GCC repository, in the hopes of distributing the Rust frontend
as part of the GCC 14.1 release.

[PATCH 1/2] diagnostics: add error_meta
[PATCH 2/2] Experiment with adding an error code to an error

Are these OK for trunk?

Kindly,

Arthur



[PATCH 1/2] diagnostics: add error_meta

2023-09-06 Thread Arthur Cohen
From: David Malcolm 

---
 gcc/diagnostic-core.h |  3 +++
 gcc/diagnostic.cc | 15 +++
 2 files changed, 18 insertions(+)

diff --git a/gcc/diagnostic-core.h b/gcc/diagnostic-core.h
index 7334c79e8e6..c9e27fd2e6e 100644
--- a/gcc/diagnostic-core.h
+++ b/gcc/diagnostic-core.h
@@ -92,6 +92,9 @@ extern void error_n (location_t, unsigned HOST_WIDE_INT, 
const char *,
 extern void error_at (location_t, const char *, ...) ATTRIBUTE_GCC_DIAG(2,3);
 extern void error_at (rich_location *, const char *, ...)
   ATTRIBUTE_GCC_DIAG(2,3);
+extern void error_meta (rich_location *, const diagnostic_metadata &,
+   const char *, ...)
+  ATTRIBUTE_GCC_DIAG(3,4);
 extern void fatal_error (location_t, const char *, ...) ATTRIBUTE_GCC_DIAG(2,3)
  ATTRIBUTE_NORETURN;
 /* Pass one of the OPT_W* from options.h as the second parameter.  */
diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
index c523f215bae..65c0cfbf11a 100644
--- a/gcc/diagnostic.cc
+++ b/gcc/diagnostic.cc
@@ -2108,6 +2108,21 @@ error_at (rich_location *richloc, const char *gmsgid, 
...)
   va_end (ap);
 }
 
+/* Same as above, but with metadata.  */
+
+void
+error_meta (rich_location *richloc, const diagnostic_metadata &metadata,
+   const char *gmsgid, ...)
+{
+  gcc_assert (richloc);
+
+  auto_diagnostic_group d;
+  va_list ap;
+  va_start (ap, gmsgid);
+  diagnostic_impl (richloc, &metadata, -1, gmsgid, &ap, DK_ERROR);
+  va_end (ap);
+}
+
 /* "Sorry, not implemented."  Use for a language feature which is
required by the relevant specification but not implemented by GCC.
An object file will not be produced.  */
-- 
2.40.0



[PATCH 2/2] Experiment with adding an error code to an error

2023-09-06 Thread Arthur Cohen
From: David Malcolm 

---
 gcc/rust/rust-diagnostics.cc  | 11 +++
 gcc/rust/rust-diagnostics.h   | 18 ++
 gcc/rust/rust-gcc-diagnostics.cc  | 33 +++
 gcc/rust/typecheck/rust-casts.cc  |  2 +-
 .../rust/compile/bad_as_bool_char.rs  |  4 +--
 5 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/gcc/rust/rust-diagnostics.cc b/gcc/rust/rust-diagnostics.cc
index 4e5c2ececd4..f29aec67652 100644
--- a/gcc/rust/rust-diagnostics.cc
+++ b/gcc/rust/rust-diagnostics.cc
@@ -166,6 +166,17 @@ rust_error_at (const Location location, const char *fmt, 
...)
   va_end (ap);
 }
 
+void
+rust_error_at (const RichLocation &location, const ErrorCode code,
+  const char *fmt, ...)
+{
+  va_list ap;
+
+  va_start (ap, fmt);
+  rust_be_error_at (location, code, expand_message (fmt, ap));
+  va_end (ap);
+}
+
 void
 rust_warning_at (const Location location, int opt, const char *fmt, ...)
 {
diff --git a/gcc/rust/rust-diagnostics.h b/gcc/rust/rust-diagnostics.h
index 43fee8baf4f..d198bd5736f 100644
--- a/gcc/rust/rust-diagnostics.h
+++ b/gcc/rust/rust-diagnostics.h
@@ -50,6 +50,18 @@
 
 // clang-format off
 // simple location
+
+struct ErrorCode
+{
+  explicit ErrorCode (const char *str) : m_str (str)
+  {
+gcc_assert (str);
+gcc_assert (str[0] == 'E');
+  }
+
+  const char *m_str;
+};
+
 extern void
 rust_internal_error_at (const Location, const char *fmt, ...)
   RUST_ATTRIBUTE_GCC_DIAG (2, 3)
@@ -72,6 +84,9 @@ rust_inform (const Location, const char *fmt, ...)
 extern void
 rust_error_at (const RichLocation &, const char *fmt, ...)
   RUST_ATTRIBUTE_GCC_DIAG (2, 3);
+extern void
+rust_error_at (const RichLocation &, const ErrorCode, const char *fmt, ...)
+  RUST_ATTRIBUTE_GCC_DIAG (3, 4);
 // clang-format on
 
 // These interfaces provide a way for the front end to ask for
@@ -97,6 +112,9 @@ rust_be_error_at (const Location, const std::string &errmsg);
 extern void
 rust_be_error_at (const RichLocation &, const std::string &errmsg);
 extern void
+rust_be_error_at (const RichLocation &, const ErrorCode,
+ const std::string &errmsg);
+extern void
 rust_be_warning_at (const Location, int opt, const std::string &warningmsg);
 extern void
 rust_be_fatal_error (const Location, const std::string &errmsg)
diff --git a/gcc/rust/rust-gcc-diagnostics.cc b/gcc/rust/rust-gcc-diagnostics.cc
index 72d2c068541..58c0a5654ea 100644
--- a/gcc/rust/rust-gcc-diagnostics.cc
+++ b/gcc/rust/rust-gcc-diagnostics.cc
@@ -22,6 +22,7 @@
 #include "rust-diagnostics.h"
 
 #include "options.h"
+#include "diagnostic-metadata.h"
 
 void
 rust_be_internal_error_at (const Location location, const std::string &errmsg)
@@ -70,6 +71,38 @@ rust_be_error_at (const RichLocation &location, const 
std::string &errmsg)
   error_at (&gcc_loc, "%s", errmsg.c_str ());
 }
 
+class rust_error_code_rule : public diagnostic_metadata::rule
+{
+public:
+  rust_error_code_rule (const ErrorCode code) : m_code (code) {}
+
+  char *make_description () const final override
+  {
+return xstrdup (m_code.m_str);
+  }
+
+  char *make_url () const final override
+  {
+return concat ("https://doc.rust-lang.org/error-index.html#";, m_code.m_str,
+  NULL);
+  }
+
+private:
+  const ErrorCode m_code;
+};
+
+void
+rust_be_error_at (const RichLocation &location, const ErrorCode code,
+ const std::string &errmsg)
+{
+  /* TODO: 'error_at' would like a non-'const' 'rich_location *'.  */
+  rich_location &gcc_loc = const_cast (location.get ());
+  diagnostic_metadata m;
+  rust_error_code_rule rule (code);
+  m.add_rule (rule);
+  error_meta (&gcc_loc, m, "%s", errmsg.c_str ());
+}
+
 void
 rust_be_get_quotechars (const char **open_qu, const char **close_qu)
 {
diff --git a/gcc/rust/typecheck/rust-casts.cc b/gcc/rust/typecheck/rust-casts.cc
index e379216b948..987542e59c4 100644
--- a/gcc/rust/typecheck/rust-casts.cc
+++ b/gcc/rust/typecheck/rust-casts.cc
@@ -283,7 +283,7 @@ TypeCastRules::emit_cast_error () const
   RichLocation r (locus);
   r.add_range (from.get_locus ());
   r.add_range (to.get_locus ());
-  rust_error_at (r, "invalid cast %<%s%> to %<%s%>",
+  rust_error_at (r, ErrorCode ("E0054"), "invalid cast %<%s%> to %<%s%>",
 from.get_ty ()->get_name ().c_str (),
 to.get_ty ()->get_name ().c_str ());
 }
diff --git a/gcc/testsuite/rust/compile/bad_as_bool_char.rs 
b/gcc/testsuite/rust/compile/bad_as_bool_char.rs
index 91a28eebe00..9652915fe11 100644
--- a/gcc/testsuite/rust/compile/bad_as_bool_char.rs
+++ b/gcc/testsuite/rust/compile/bad_as_bool_char.rs
@@ -5,13 +5,13 @@ pub fn main ()
   let fone = t as f32;   // { dg-error "invalid cast" }
   let fzero = f as f64;  // { dg-error "invalid cast" }
 
-  let nb = 0u8 as bool;  // { dg-error "invalid cast" }
+  let nb = 0u8 as bool;  // { dg-error "invalid cast .u8. to .bool. 
\\\[E0054\\\]" }
   let nc = true as char; // { dg-error "inval

Re: [PATCH] analyzer: Move gcc.dg/analyzer tests to c-c++-common (2) [PR96395]

2023-09-06 Thread Benjamin Priour via Gcc-patches
Hi David,
Thanks for the review.



On Tue, Sep 5, 2023 at 1:53 PM David Malcolm  wrote:

> On Mon, 2023-09-04 at 20:00 +0200, priour...@gmail.com wrote:
>
>
[...snip...]


> All of these "new" tests (apart from the "-noexcept" ones) look like
> they're meant to be existing tests that were moved, but where the copy
> of the test in gcc.dg/analyzer didn't get deleted, so they show up as a
> duplicate.  See the details below.
>

> >   * c-c++-common/analyzer/file-pr58237-noexcept.c: New test.
>
> When duplicating a test like this, the test isn't entirely "new", so
> please say something like this in the ChangeLog entry, to make it clear
> where it came from:
>
>
I actually wasn't sure about these -noexcept tests. They were part
of gcc.dg/analyzer, thus only gcc was running them. Exceptions
were not disabled *explicitly*, but since it was C, they weren't enabled
either.

Therefore, the -noexcept tests are basically a copy, but with an explicit
-fno-exceptions specification.
When I duplicated them in that way I was thinking about making it clear
that these tests fail in C++ with exceptions enabled, so that we would
already
have easy-to-spot failing tests to challenge a future exception support.

Though perhaps *not* duplicating the tests but rather simply specify
-fno-exceptions,
with a comment "Fails with exceptions" may be better.


> * c-c++-common/analyzer/file-pr58237-noexcept.c: New test,
> based on gcc.dg/analyzer/file-pr58237.c.
>
> >   * c-c++-common/analyzer/fopen-2.c: New test.
>
> Looks fopen-2.c is a move of the parts of gcc.dg/analyzer/fopen-1.c
> that can also be C++, so please state that in the ChangeLog.
>

Nods.

[...snip...]


> Nice - thanks.
>
> Can this be combined with the EQ_EXPR and NE_EXPR cases? (possibly
> updating the comment)  The code looks identical to me, but I might be
> misreading it.
>
>
Totally, I forgot to move it after making sure it worked.
Thanks.


> [...snip...]
>
> > diff --git a/gcc/testsuite/c-c++-common/analyzer/compound-assignment-1.c
> b/gcc/testsuite/c-c++-common/analyzer/compound-assignment-1.c
> > new file mode 100644
> > index 000..b208f58f09f
> > --- /dev/null
> > +++ b/gcc/testsuite/c-c++-common/analyzer/compound-assignment-1.c
> > @@ -0,0 +1,72 @@
> > +#include 
> > +
> > +struct ptr_wrapper
> > +{
> > +  int *ptr;
> > +};
> > +
> > +struct ptr_wrapper
> > +test_1 (void)
> > +{
> > +  struct ptr_wrapper r;
> > +  r.ptr = (int *) malloc (sizeof (int));
> > +  return r;
> > +}
>
> This looks the same as gcc.dg/analyzer/compound-assignment-1.c
>
> Should this be a move, rather than a new file?  i.e. is the patch
> missing a deletion of the file in the old location?
>
> [...snip...]
>
> > diff --git a/gcc/testsuite/c-c++-common/analyzer/infinite-recursion.c
> b/gcc/testsuite/c-c++-common/analyzer/infinite-recursion.c
> > new file mode 100644
> > index 000..6b7d25cfabe
> > --- /dev/null
> > +++ b/gcc/testsuite/c-c++-common/analyzer/infinite-recursion.c
>
> Likewise here for infinite-recursion.c.
>
> [...snip...]
>
> > diff --git
> a/gcc/testsuite/gcc.dg/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c
> b/gcc/testsuite/c-c++-common/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c
> > similarity index 97%
> > rename from
> gcc/testsuite/gcc.dg/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c
> > rename to
> gcc/testsuite/c-c++-common/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c
> > index 0172c9b324c..1b657697ef4 100644
> > --- a/gcc/testsuite/gcc.dg/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c
> > +++
> b/gcc/testsuite/c-c++-common/analyzer/loop-0-up-to-n-by-1-with-iter-obj.c
> > @@ -1,6 +1,6 @@
> >  #include 
> >
> > -#include "analyzer-decls.h"
> > +#include "../../gcc.dg/analyzer/analyzer-decls.h"
> >
> >  struct iter
> >  {
> > @@ -45,7 +45,7 @@ void test(int n)
> >struct iter *it = iter_new (0, n, 1);
> >while (!iter_done_p (it))
> >  {
> > -  __analyzer_eval (it->val < n); /* { dg-warning "TRUE" "true" {
> xfail *-*-* } } */
> > +  __analyzer_eval (it->val < n); /* { dg-warning "TRUE" "true" } */
> >/* { dg-bogus "UNKNOWN" "unknown" { xfail *-*-* } .-1 } */
> >/* TODO(xfail^^^): ideally we ought to figure out i > 0 after 1st
> iteration.  */
> >
>
> Presumably due to the change to
> region_model::add_constraints_from_binop, right?
> Looking at that dg-bogus "UNKNOWN", do we still get an UNKNOWN here, or
> can that line be removed?
> If so, then the 3rd comment can presumably become:
>
>
The bogus here still make sense - without it there is an excess error -.
I had checked for it because I too thought it could be removed.
If I remember it correctly, we get UNKNOWN during the widening pass.


> >/* TODO: ideally we ought to figure out i > 0 after 1st
> iteration.  */
>
> [...snip...]
>
>
>
[...snip...]

Thanks for spotting the files I forgot to remove from gcc.dg.
Sorry about them, I had messed up my test folder when checking for arm-eabi,
and I apparently missed some duplicates when re

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

2023-09-06 Thread Antoni Boucher via Gcc-patches
Hi.
I'll do another test to make sure this is enough since I tested with a
few more finalize functions.
Thanks a lot for finding this!

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

RE: [PATCH] RISC-V: Fix VSETVL PASS AVL/VL fetch bug[111295]

2023-09-06 Thread Li, Pan2 via Gcc-patches
Committed, thanks Robin.

Pan

-Original Message-
From: Gcc-patches  On Behalf 
Of Robin Dapp via Gcc-patches
Sent: Wednesday, September 6, 2023 9:38 PM
To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org
Cc: kito.ch...@sifive.com; kito.ch...@gmail.com
Subject: Re: [PATCH] RISC-V: Fix VSETVL PASS AVL/VL fetch bug[111295]

OK.

Regards
 Robin


RE: [PATCH] RISC-V: Remove unreasonable TARGET_64BIT for VLS modes with size = 64bit

2023-09-06 Thread Li, Pan2 via Gcc-patches
Committed, thanks Robin.

Pan

-Original Message-
From: Gcc-patches  On Behalf 
Of Robin Dapp via Gcc-patches
Sent: Wednesday, September 6, 2023 9:39 PM
To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org
Cc: kito.ch...@sifive.com; kito.ch...@gmail.com
Subject: Re: [PATCH] RISC-V: Remove unreasonable TARGET_64BIT for VLS modes 
with size = 64bit

LGTM.

Regards
 Robin



Re: [PATCH] RISC-V: Fix incorrect mode tieable which cause ICE in RA[PR111296]

2023-09-06 Thread Jeff Law via Gcc-patches




On 9/6/23 03:47, Juzhe-Zhong wrote:

This patch fix incorrect mode tieable between DI and V2SI which cause ICE
in RA.

PR target/111296

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_modes_tieable_p): Fix bug.

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/base/pr111296.C: New test.




---
  gcc/config/riscv/riscv.cc  |  7 +++
  .../g++.target/riscv/rvv/base/pr111296.C   | 18 ++
  2 files changed, 25 insertions(+)
  create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/pr111296.C

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 228515acc1f..2c0c4c2f3ae 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -7648,6 +7648,13 @@ riscv_hard_regno_mode_ok (unsigned int regno, 
machine_mode mode)
  static bool
  riscv_modes_tieable_p (machine_mode mode1, machine_mode mode2)
  {
+  /* We don't allow different REG_CLASS modes tieable since it
+ will cause ICE in register allocation (RA).
+ E.g. V2SI and DI are not tieable.  */
+  if (riscv_v_ext_mode_p (mode1) && !riscv_v_ext_mode_p (mode2))
+return false;
+  else if (riscv_v_ext_mode_p (mode2) && !riscv_v_ext_mode_p (mode1))
+return false;

Isn't this just
if (riscv_v_ext_mode_p (mode1) != riscv_v_ext_mode_p (mode2))

OK with that change.

jeff


Re: [PATCH v4 1/1] RISC-V: Add support for 'XVentanaCondOps' reusing 'Zicond' support

2023-09-06 Thread Jeff Law via Gcc-patches




On 9/5/23 23:47, Tsukasa OI wrote:

From: Tsukasa OI 

'XVentanaCondOps' is a vendor extension from Ventana Micro Systems
containing two instructions for conditional move and will be supported on
their Veyron V1 CPU.

And most notably (for historical reasons), 'XVentanaCondOps' and the
standard 'Zicond' extension are functionally equivalent (only encodings and
instruction names are different).

*   czero.eqz == vt.maskc
*   czero.nez == vt.maskcn

This commit adds support for the 'XVentanaCondOps' extension by extending
'Zicond' extension support.  With this, we can now reuse the optimization
using the 'Zicond' extension for the 'XVentanaCondOps' extension.

The specification for the 'XVentanaCondOps' extension is based on:


gcc/ChangeLog:

* common/config/riscv/riscv-common.cc (riscv_ext_flag_table):
Parse 'XVentanaCondOps' extension.
* config/riscv/riscv-opts.h (MASK_XVENTANACONDOPS): New.
(TARGET_XVENTANACONDOPS): Ditto.
(TARGET_ZICOND_LIKE): New to represent targets with conditional
moves like 'Zicond'.  It includes RV64 + 'XVentanaCondOps'.
* config/riscv/riscv.cc (riscv_rtx_costs): Replace TARGET_ZICOND
with TARGET_ZICOND_LIKE.
(riscv_expand_conditional_move): Ditto.
* config/riscv/riscv.md (movcc): Replace TARGET_ZICOND with
TARGET_ZICOND_LIKE.
* config/riscv/riscv.opt: Add new riscv_xventana_subext.
* config/riscv/zicond.md: Modify description.
(eqz_ventana): New to match corresponding czero instructions.
(nez_ventana): Ditto.
(*czero..): Emit a 'XVentanaCondOps' instruction if
'Zicond' is not available but 'XVentanaCondOps' + RV64 is.
(*czero..): Ditto.
(*czero.eqz..opt1): Ditto.
(*czero.nez..opt2): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xventanacondops-primitiveSemantics.c: New test,
* gcc.target/riscv/xventanacondops-primitiveSemantics-rv32.c: New
test to make sure that XVentanaCondOps instructions are disabled
on RV32.
* gcc.target/riscv/xventanacondops-xor-01.c: New test,
OK.  Thanks for taking care of this.  I guess Raphael and I should get 
more active on pushing the rest of the veyron-v1 bits upstream :-)


Jeff


Re: [PATCH 1/2] diagnostics: add error_meta

2023-09-06 Thread David Malcolm via Gcc-patches
On Wed, 2023-09-06 at 15:53 +0200, Arthur Cohen wrote:
> From: David Malcolm 

I guess I can review this patch :)

Needs a ChangeLog entry, so here's one:

gcc/ChangeLog
* diagnostic-core.h (error_meta): New decl.
* diagnostic.cc (error_meta): New.

Also, needs a signed-off-by, so here's one:

Signed-off-by: David Malcolm 


OK for trunk with those added.

Thanks
Dave



> 
> ---
>  gcc/diagnostic-core.h |  3 +++
>  gcc/diagnostic.cc | 15 +++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/gcc/diagnostic-core.h b/gcc/diagnostic-core.h
> index 7334c79e8e6..c9e27fd2e6e 100644
> --- a/gcc/diagnostic-core.h
> +++ b/gcc/diagnostic-core.h
> @@ -92,6 +92,9 @@ extern void error_n (location_t, unsigned
> HOST_WIDE_INT, const char *,
>  extern void error_at (location_t, const char *, ...)
> ATTRIBUTE_GCC_DIAG(2,3);
>  extern void error_at (rich_location *, const char *, ...)
>    ATTRIBUTE_GCC_DIAG(2,3);
> +extern void error_meta (rich_location *, const diagnostic_metadata
> &,
> +   const char *, ...)
> +  ATTRIBUTE_GCC_DIAG(3,4);
>  extern void fatal_error (location_t, const char *, ...)
> ATTRIBUTE_GCC_DIAG(2,3)
>   ATTRIBUTE_NORETURN;
>  /* Pass one of the OPT_W* from options.h as the second parameter. 
> */
> diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
> index c523f215bae..65c0cfbf11a 100644
> --- a/gcc/diagnostic.cc
> +++ b/gcc/diagnostic.cc
> @@ -2108,6 +2108,21 @@ error_at (rich_location *richloc, const char
> *gmsgid, ...)
>    va_end (ap);
>  }
>  
> +/* Same as above, but with metadata.  */
> +
> +void
> +error_meta (rich_location *richloc, const diagnostic_metadata
> &metadata,
> +   const char *gmsgid, ...)
> +{
> +  gcc_assert (richloc);
> +
> +  auto_diagnostic_group d;
> +  va_list ap;
> +  va_start (ap, gmsgid);
> +  diagnostic_impl (richloc, &metadata, -1, gmsgid, &ap, DK_ERROR);
> +  va_end (ap);
> +}
> +
>  /* "Sorry, not implemented."  Use for a language feature which is
>     required by the relevant specification but not implemented by
> GCC.
>     An object file will not be produced.  */



Re: [PATCH 2/2] Experiment with adding an error code to an error

2023-09-06 Thread David Malcolm via Gcc-patches
On Wed, 2023-09-06 at 15:53 +0200, Arthur Cohen wrote:
> From: David Malcolm 

This is probably something for the gcc-rust maintainers to review
(rather than me self-reviewing with my "diagnostics maintainer" hat
on).

Doesn't have a ChangeLog entry, FWIW.
Doesn't have a signed-off-by, so here's one:

Signed-off-by: David Malcolm 

[...snip...]

> diff --git a/gcc/rust/rust-gcc-diagnostics.cc b/gcc/rust/rust-gcc-
> diagnostics.cc
> index 72d2c068541..58c0a5654ea 100644
> --- a/gcc/rust/rust-gcc-diagnostics.cc
> +++ b/gcc/rust/rust-gcc-diagnostics.cc

[...snip...]

> +void
> +rust_be_error_at (const RichLocation &location, const ErrorCode
> code,
> + const std::string &errmsg)
> +{
> +  /* TODO: 'error_at' would like a non-'const' 'rich_location *'. 

The above comment should refer to "error_meta", rather than
"error_at"...

> */
> +  rich_location &gcc_loc = const_cast (location.get
> ());
> +  diagnostic_metadata m;
> +  rust_error_code_rule rule (code);
> +  m.add_rule (rule);
> +  error_meta (&gcc_loc, m, "%s", errmsg.c_str ());

... to match this call.

[...snip...]

Otherwise, LGTM, but as I said, this is more in the gcc-rust
maintainers' area.

Dave



Re: [PATCH 1/2] diagnostics: add error_meta

2023-09-06 Thread Arthur Cohen

On 9/6/23 16:12, David Malcolm wrote:

On Wed, 2023-09-06 at 15:53 +0200, Arthur Cohen wrote:

From: David Malcolm 


I guess I can review this patch :)

Needs a ChangeLog entry, so here's one:

gcc/ChangeLog
* diagnostic-core.h (error_meta): New decl.
* diagnostic.cc (error_meta): New.

Also, needs a signed-off-by, so here's one:

Signed-off-by: David Malcolm 



Right! Now that we enforce Changelogs and SoB lines in our CI, I 
completely forgot to add them back to older commits. I'll fix the second 
commit too. Thanks for the fast review!




OK for trunk with those added.

Thanks
Dave





---
  gcc/diagnostic-core.h |  3 +++
  gcc/diagnostic.cc | 15 +++
  2 files changed, 18 insertions(+)

diff --git a/gcc/diagnostic-core.h b/gcc/diagnostic-core.h
index 7334c79e8e6..c9e27fd2e6e 100644
--- a/gcc/diagnostic-core.h
+++ b/gcc/diagnostic-core.h
@@ -92,6 +92,9 @@ extern void error_n (location_t, unsigned
HOST_WIDE_INT, const char *,
  extern void error_at (location_t, const char *, ...)
ATTRIBUTE_GCC_DIAG(2,3);
  extern void error_at (rich_location *, const char *, ...)
    ATTRIBUTE_GCC_DIAG(2,3);
+extern void error_meta (rich_location *, const diagnostic_metadata
&,
+   const char *, ...)
+  ATTRIBUTE_GCC_DIAG(3,4);
  extern void fatal_error (location_t, const char *, ...)
ATTRIBUTE_GCC_DIAG(2,3)
   ATTRIBUTE_NORETURN;
  /* Pass one of the OPT_W* from options.h as the second parameter.
*/
diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
index c523f215bae..65c0cfbf11a 100644
--- a/gcc/diagnostic.cc
+++ b/gcc/diagnostic.cc
@@ -2108,6 +2108,21 @@ error_at (rich_location *richloc, const char
*gmsgid, ...)
    va_end (ap);
  }
  
+/* Same as above, but with metadata.  */

+
+void
+error_meta (rich_location *richloc, const diagnostic_metadata
&metadata,
+   const char *gmsgid, ...)
+{
+  gcc_assert (richloc);
+
+  auto_diagnostic_group d;
+  va_list ap;
+  va_start (ap, gmsgid);
+  diagnostic_impl (richloc, &metadata, -1, gmsgid, &ap, DK_ERROR);
+  va_end (ap);
+}
+
  /* "Sorry, not implemented."  Use for a language feature which is
     required by the relevant specification but not implemented by
GCC.
     An object file will not be produced.  */




[Committed V2] RISC-V: Fix incorrect mode tieable which cause ICE in RA[PR111296]

2023-09-06 Thread Juzhe-Zhong
This patch fix incorrect mode tieable between DI and V2SI which cause ICE
in RA.

PR target/111296

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_modes_tieable_p): Fix incorrect mode 
tieable for RVV modes.

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/base/pr111296.C: New test.

---
 gcc/config/riscv/riscv.cc  |  5 +
 .../g++.target/riscv/rvv/base/pr111296.C   | 18 ++
 2 files changed, 23 insertions(+)
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/base/pr111296.C

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 228515acc1f..a3d3389e7e2 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -7648,6 +7648,11 @@ riscv_hard_regno_mode_ok (unsigned int regno, 
machine_mode mode)
 static bool
 riscv_modes_tieable_p (machine_mode mode1, machine_mode mode2)
 {
+  /* We don't allow different REG_CLASS modes tieable since it
+ will cause ICE in register allocation (RA).
+ E.g. V2SI and DI are not tieable.  */
+  if (riscv_v_ext_mode_p (mode1) != riscv_v_ext_mode_p (mode2))
+return false;
   return (mode1 == mode2
  || !(GET_MODE_CLASS (mode1) == MODE_FLOAT
   && GET_MODE_CLASS (mode2) == MODE_FLOAT));
diff --git a/gcc/testsuite/g++.target/riscv/rvv/base/pr111296.C 
b/gcc/testsuite/g++.target/riscv/rvv/base/pr111296.C
new file mode 100644
index 000..6eb14fd83a8
--- /dev/null
+++ b/gcc/testsuite/g++.target/riscv/rvv/base/pr111296.C
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-std=c++03 -march=rv64gcv -mabi=lp64d -Ofast -ftree-vectorize 
--param=riscv-autovec-preference=scalable" } */
+
+struct a
+{
+  int b;
+  int c;
+};
+int d;
+a
+e ()
+{
+  a f;
+  int g = d - 1, h = d / 2 - 1;
+  f.b = g;
+  f.c = h;
+  return f;
+}
-- 
2.36.3



Re: [PATCH] core: Support heap-based trampolines

2023-09-06 Thread FX Coudert via Gcc-patches
Hi,

ping**2 on the revised patch, for Richard or another global reviewer. So far 
all review feedback is that it’s a step forward, and it’s been widely used for 
both aarch64-darwin and x86_64-darwin distributions for almost three years now.

OK to commit?
FX



> Le 5 août 2023 à 16:20, FX Coudert  a écrit :
> 
> Hi Richard,
> 
> Thanks for your feedback. Here is an amended version of the patch, taking 
> into consideration your requests and the following discussion. There is no 
> configure option for the libgcc part, and the documentation is amended. The 
> patch is split into three commits for core, target and libgcc.
> 
> Currently regtesting on x86_64 linux and darwin (it was fine before I split 
> up into three commits, so I’m re-testing to make sure I didn’t screw anything 
> up).
> 
> OK to commit?
> FX



0001-core-Support-heap-based-trampolines.patch
Description: Binary data


0002-target-Support-heap-based-trampolines.patch
Description: Binary data


0003-libgcc-support-heap-based-trampolines.patch
Description: Binary data


[committed 10/12 v2] C _BitInt support [PR102989]

2023-09-06 Thread Jakub Jelinek via Gcc-patches
Hi!

Thanks for the patch reviews (and to Richi and Uros as well) and everyone
who participated in discussions.

Here is the updated version of the C _BitInt support [PR102989] patch
I've committed to trunk in addition to the rest of the series (except the
_BitInt a ? ~b : b match.pd fix patch, which will need to be resolved
eventually).

On Tue, Sep 05, 2023 at 10:40:26PM +, Joseph Myers wrote:
> Maybe c-ada-spec.cc, though it might be best to ask 
> the Ada maintainers there.

I've skipped c-ada-spec.cc and will file a PR for Ada maintainers,
it is up to them to decide what they want and how to implement that.

2023-09-06  Jakub Jelinek  

PR c/102989
gcc/
* glimits.h (BITINT_MAXWIDTH): Define if __BITINT_MAXWIDTH__ is
predefined.
gcc/c-family/
* c-common.cc (c_common_reswords): Add _BitInt as keyword.
(unsafe_conversion_p): Handle BITINT_TYPE like INTEGER_TYPE.
(c_common_signed_or_unsigned_type): Handle BITINT_TYPE.
(c_common_truthvalue_conversion, c_common_get_alias_set,
check_builtin_function_arguments): Handle BITINT_TYPE like
INTEGER_TYPE.
(sync_resolve_size): Add ORIG_FORMAT argument.  If
FETCH && !ORIG_FORMAT, type is BITINT_TYPE, return -1 if size isn't
one of 1, 2, 4, 8 or 16 or if it is 16 but TImode is not supported.
(atomic_bitint_fetch_using_cas_loop): New function.
(resolve_overloaded_builtin): Adjust sync_resolve_size caller.  If
-1 is returned, use atomic_bitint_fetch_using_cas_loop to lower it.
Formatting fix.
(keyword_begins_type_specifier): Handle RID_BITINT.
* c-common.h (enum rid): Add RID_BITINT enumerator.
* c-cppbuiltin.cc (c_cpp_builtins): For C call
targetm.c.bitint_type_info and predefine __BITINT_MAXWIDTH__
and for -fbuilding-libgcc also __LIBGCC_BITINT_LIMB_WIDTH__ and
__LIBGCC_BITINT_ORDER__ macros if _BitInt is supported.
* c-lex.cc (interpret_integer): Handle CPP_N_BITINT.
* c-pretty-print.cc (c_pretty_printer::simple_type_specifier,
c_pretty_printer::direct_abstract_declarator,
c_pretty_printer::direct_declarator, c_pretty_printer::declarator):
Handle BITINT_TYPE.
(pp_c_integer_constant): Handle printing of large precision wide_ints
which would buffer overflow digit_buffer.
* c-warn.cc (conversion_warning, warnings_for_convert_and_check,
warnings_for_convert_and_check): Handle BITINT_TYPE like
INTEGER_TYPE.
gcc/c/
* c-convert.cc (c_convert): Handle BITINT_TYPE like INTEGER_TYPE.
* c-decl.cc (check_bitfield_type_and_width): Allow BITINT_TYPE
bit-fields.
(finish_struct): Prefer to use BITINT_TYPE for BITINT_TYPE bit-fields
if possible.
(declspecs_add_type): Formatting fixes.  Handle cts_bitint.  Adjust
for added union in *specs.  Handle RID_BITINT.
(finish_declspecs): Handle cts_bitint.  Adjust for added union
in *specs.
* c-parser.cc (c_keyword_starts_typename, c_token_starts_declspecs,
c_parser_declspecs, c_parser_gnu_attribute_any_word): Handle
RID_BITINT.
(c_parser_omp_clause_schedule): Handle BITINT_TYPE like INTEGER_TYPE.
* c-tree.h (enum c_typespec_keyword): Mention _BitInt in comment.
Add cts_bitint enumerator.
(struct c_declspecs): Move int_n_idx and floatn_nx_idx into a union
and add bitint_prec there as well.
* c-typeck.cc (c_common_type, comptypes_internal):
Handle BITINT_TYPE.
(perform_integral_promotions): Promote BITINT_TYPE bit-fields to
their declared type.
(build_array_ref, build_unary_op, build_conditional_expr,
build_c_cast, convert_for_assignment, digest_init, build_binary_op):
Handle BITINT_TYPE.
* c-fold.cc (c_fully_fold_internal): Handle BITINT_TYPE like
INTEGER_TYPE.
* c-aux-info.cc (gen_type): Handle BITINT_TYPE.
libcpp/
* expr.cc (interpret_int_suffix): Handle wb and WB suffixes.
* include/cpplib.h (CPP_N_BITINT): Define.

--- gcc/glimits.h.jj2023-09-05 16:44:32.269305435 +0200
+++ gcc/glimits.h   2023-09-06 09:14:53.950335938 +0200
@@ -157,6 +157,11 @@ see the files COPYING3 and COPYING.RUNTI
 # undef BOOL_WIDTH
 # define BOOL_WIDTH 1
 
+# ifdef __BITINT_MAXWIDTH__
+#  undef BITINT_MAXWIDTH
+#  define BITINT_MAXWIDTH __BITINT_MAXWIDTH__
+# endif
+
 # define __STDC_VERSION_LIMITS_H__ 202311L
 #endif
 
--- gcc/c-family/c-common.cc.jj 2023-09-05 16:44:32.110307593 +0200
+++ gcc/c-family/c-common.cc2023-09-06 09:55:30.836992346 +0200
@@ -349,6 +349,7 @@ const struct c_common_resword c_common_r
   { "_Alignas",RID_ALIGNAS,   D_CONLY },
   { "_Alignof",RID_ALIGNOF,   D_CONLY },
   { "_Atomic", RID_ATOMIC,D_CONLY },
+  { "_BitInt", RID_BITINT,D_CONLY },
   { "_Bool",   RID_BOOL,  D_CONLY 

[PATCH v2 0/2] riscv: Introduce strlen/strcmp/strncmp inline expansion

2023-09-06 Thread Christoph Muellner
From: Christoph Müllner 

This series introduces strlen/strcmp/strncmp inline expansion for Zbb/XTheadBb.

In the last months, glibc as well as the Linux kernel merged changes for
optimized string processing for RISC-V. The instruction, which enables
optimized string routines is Zbb's orc.b (or T-Head's th.tstnbz) instruction.

This patch attempts to add optimized string processing to GCC with the
following properties:
* strlen: inline a loop if the string is xlen-aligned
* strcmp/strncmp: inline a peeled comparison loop sequence if both strings
  are xlen-aligned

I've already posted the idea in a previous series last November
(therefore, this series is called 'v2'):
* https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605996.html
* https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605998.html

Back then, there were a couple of comments, which have been addressed,
but the str(n)cmp patch has been restructured to make the code easier
to digest.  In total the following changes are made:
* Address Jeff's comments for the strlen patch
* Change str(n)cmp flags according to Kito's comments
* Ensure that all flags are documented
* Break str(n)cmp expansion into several functions
* Add support for XTheadBb's th.tstnbz

I have not introduced "-minline-str[n]cmp=[bitmanip|vector|auto]"
or "-mstringop-strategy=alg" because we only have one bitmanip/scalar
expansion.  But it is possible to add this in the future (or not and
decide based on mtune).

By default all optimizations are disabled, so there should be no risk
of regressions.

Testing was done using the following strategy:
* Enablement/flag tests are part of the patches
* Correctness was tested using qemu-user with glibc's string tests compiled for:
** rv64gc (baseline) QEMU_CPU=rv64
** rv64gc_zbb (limit=64) QEMU_CPU=rv64,zbb=false (must fail)
** rv64gc_zbb (limit=64) QEMU_CPU=rv64,zbb=true
** rv64gc_zbb (limit=32) QEMU_CPU=rv64,zbb=true
** rv64gc_xtheadbb (limit=64) QEMU_CPU=rv64 (must fail)
** rv64gc_xtheadbb (limit=64) QEMU_CPU=thead-c906
** rv64gc_xtheadbb (limit=8) QEMU_CPU=thead-c906
** rv32gc_zbb (limit=64) QEMU_CPU=rv32,zbb=true
* SPEC CPU 2017 intrate base/peak with LTO

Christoph Müllner (2):
  riscv: Add support for strlen inline expansion
  riscv: Add support for str(n)cmp inline expansion

 gcc/config.gcc|   3 +-
 gcc/config/riscv/bitmanip.md  |   2 +-
 gcc/config/riscv/riscv-protos.h   |   4 +
 gcc/config/riscv/riscv-string.cc  | 594 ++
 gcc/config/riscv/riscv.md |  72 ++-
 gcc/config/riscv/riscv.opt|  16 +
 gcc/config/riscv/t-riscv  |   6 +
 gcc/config/riscv/thead.md |   9 +-
 gcc/doc/invoke.texi   |  29 +-
 gcc/emit-rtl.cc   |  24 +
 gcc/rtl.h |   2 +
 .../gcc.target/riscv/xtheadbb-strcmp.c|  57 ++
 .../riscv/xtheadbb-strlen-unaligned.c |  14 +
 .../gcc.target/riscv/xtheadbb-strlen.c|  19 +
 .../gcc.target/riscv/zbb-strcmp-disabled-2.c  |  38 ++
 .../gcc.target/riscv/zbb-strcmp-disabled.c|  38 ++
 .../gcc.target/riscv/zbb-strcmp-limit.c   |  57 ++
 .../gcc.target/riscv/zbb-strcmp-unaligned.c   |  38 ++
 gcc/testsuite/gcc.target/riscv/zbb-strcmp.c   |  57 ++
 .../gcc.target/riscv/zbb-strlen-disabled-2.c  |  15 +
 .../gcc.target/riscv/zbb-strlen-disabled.c|  15 +
 .../gcc.target/riscv/zbb-strlen-unaligned.c   |  14 +
 gcc/testsuite/gcc.target/riscv/zbb-strlen.c   |  19 +
 23 files changed, 1137 insertions(+), 5 deletions(-)
 create mode 100644 gcc/config/riscv/riscv-string.cc
 create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strcmp.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strlen-unaligned.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strlen.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-disabled-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-disabled.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-limit.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-unaligned.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-disabled-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-disabled.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-unaligned.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen.c

-- 
2.41.0



[PATCH v2 2/2] riscv: Add support for str(n)cmp inline expansion

2023-09-06 Thread Christoph Muellner
From: Christoph Müllner 

This patch implements expansions for the cmpstrsi and cmpstrnsi
builtins for RV32/RV64 for xlen-aligned strings if Zbb or XTheadBb
instructions are available.  The expansion basically emits a comparison
sequence which compares XLEN bits per step if possible.

This allows to inline calls to strcmp() and strncmp() if both strings
are xlen-aligned.  For strncmp() the length parameter needs to be known.
The benefits over calls to libc are:
* no call/ret instructions
* no stack frame allocation
* no register saving/restoring
* no alignment tests

The inlining mechanism is gated by a new switches ('-minline-strcmp' and
'-minline-strncmp') and by the variable 'optimize_size'.
The amount of emitted unrolled loop iterations can be controlled by the
parameter '--param=riscv-strcmp-inline-limit=N', which defaults to 64.

The comparision sequence is inspired by the strcmp example
in the appendix of the Bitmanip specification (incl. the fast
result calculation in case the first word does not contain
a NULL byte).  Additional inspiration comes from rs6000-string.c.

The emitted sequence is not triggering any readahead pagefault issues,
because only aligned strings are accessed by aligned xlen-loads.

This patch has been tested using the glibc string tests on QEMU:
* rv64gc_zbb/rv64gc_xtheadbb with riscv-strcmp-inline-limit=64
* rv64gc_zbb/rv64gc_xtheadbb with riscv-strcmp-inline-limit=8
* rv32gc_zbb/rv32gc_xtheadbb with riscv-strcmp-inline-limit=64

Signed-off-by: Christoph Müllner 

gcc/ChangeLog:

* config/riscv/bitmanip.md (*_not): Export INSN name.
(_not3): Likewise.
* config/riscv/riscv-protos.h (riscv_expand_strcmp): New
prototype.
* config/riscv/riscv-string.cc (GEN_EMIT_HELPER3): New helper
macros.
(GEN_EMIT_HELPER2): Likewise.
(emit_strcmp_scalar_compare_byte): New function.
(emit_strcmp_scalar_compare_subword): Likewise.
(emit_strcmp_scalar_compare_word): Likewise.
(emit_strcmp_scalar_load_and_compare): Likewise.
(emit_strcmp_scalar_call_to_libc): Likewise.
(emit_strcmp_scalar_result_calculation_nonul): Likewise.
(emit_strcmp_scalar_result_calculation): Likewise.
(riscv_expand_strcmp_scalar): Likewise.
(riscv_expand_strcmp): Likewise.
* config/riscv/riscv.md (*slt_): Export
INSN name.
(@slt_3): Likewise.
(cmpstrnsi): Invoke expansion function for str(n)cmp.
(cmpstrsi): Likewise.
* config/riscv/riscv.opt: Add new parameter
'-mstring-compare-inline-limit'.
* doc/invoke.texi: Document new parameter
'-mstring-compare-inline-limit'.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xtheadbb-strcmp-unaligned.c: New test.
* gcc.target/riscv/xtheadbb-strcmp.c: New test.
* gcc.target/riscv/zbb-strcmp-disabled-2.c: New test.
* gcc.target/riscv/zbb-strcmp-disabled.c: New test.
* gcc.target/riscv/zbb-strcmp-unaligned.c: New test.
* gcc.target/riscv/zbb-strcmp.c: New test.
---
 gcc/config/riscv/bitmanip.md  |   2 +-
 gcc/config/riscv/riscv-protos.h   |   1 +
 gcc/config/riscv/riscv-string.cc  | 411 ++
 gcc/config/riscv/riscv.md |  44 +-
 gcc/config/riscv/riscv.opt|  12 +
 gcc/doc/invoke.texi   |  20 +-
 .../gcc.target/riscv/xtheadbb-strcmp.c|  57 +++
 .../gcc.target/riscv/zbb-strcmp-disabled-2.c  |  38 ++
 .../gcc.target/riscv/zbb-strcmp-disabled.c|  38 ++
 .../gcc.target/riscv/zbb-strcmp-limit.c   |  57 +++
 .../gcc.target/riscv/zbb-strcmp-unaligned.c   |  38 ++
 gcc/testsuite/gcc.target/riscv/zbb-strcmp.c   |  57 +++
 12 files changed, 772 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strcmp.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-disabled-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-disabled.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-limit.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp-unaligned.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strcmp.c

diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index 1544ef4e125..1e90636dd60 100644
--- a/gcc/config/riscv/bitmanip.md
+++ b/gcc/config/riscv/bitmanip.md
@@ -206,7 +206,7 @@ (define_expand "popcount2"
(popcount:GPR (match_operand:GPR 1 "register_operand")))]
   "TARGET_ZBB")
 
-(define_insn "*_not"
+(define_insn "_not3"
   [(set (match_operand:X 0 "register_operand" "=r")
 (bitmanip_bitwise:X (not:X (match_operand:X 1 "register_operand" "r"))
 (match_operand:X 2 "register_operand" "r")))]
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index b060d047f01..0006fe0564e 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-p

[PATCH v2 1/2] riscv: Add support for strlen inline expansion

2023-09-06 Thread Christoph Muellner
From: Christoph Müllner 

This patch implements the expansion of the strlen builtin for RV32/RV64
for xlen-aligned aligned strings if Zbb or XTheadBb instructions are available.
The inserted sequences are:

rv32gc_zbb (RV64 is similar):
  add a3,a0,4
  li  a4,-1
.L1:  lw  a5,0(a0)
  add a0,a0,4
  orc.b   a5,a5
  beq a5,a4,.L1
  not a5,a5
  ctz a5,a5
  srl a5,a5,0x3
  add a0,a0,a5
  sub a0,a0,a3

rv64gc_xtheadbb (RV32 is similar):
  add   a4,a0,8
.L2:  lda5,0(a0)
  add   a0,a0,8
  th.tstnbz a5,a5
  beqz  a5,.L2
  th.reva5,a5
  th.ff1a5,a5
  srl   a5,a5,0x3
  add   a0,a0,a5
  sub   a0,a0,a4

This allows to inline calls to strlen(), with optimized code for
xlen-aligned strings, resulting in the following benefits over
a call to libc:
* no call/ret instructions
* no stack frame allocation
* no register saving/restoring
* no alignment test

The inlining mechanism is gated by a new switch ('-minline-strlen')
and by the variable 'optimize_size'.

Tested using the glibc string tests.

Signed-off-by: Christoph Müllner 

gcc/ChangeLog:

* config.gcc: Add new object riscv-string.o.
riscv-string.cc.
* config/riscv/riscv-protos.h (riscv_expand_strlen):
New function.
* config/riscv/riscv.md (strlen): New expand INSN.
* config/riscv/riscv.opt: New flag 'minline-strlen'.
* config/riscv/t-riscv: Add new object riscv-string.o.
* config/riscv/thead.md (th_rev2): Export INSN name.
(th_rev2): Likewise.
(th_tstnbz2): New INSN.
* doc/invoke.texi: Document '-minline-strlen'.
* emit-rtl.cc (emit_likely_jump_insn): New helper function.
(emit_unlikely_jump_insn): Likewise.
* rtl.h (emit_likely_jump_insn): New prototype.
(emit_unlikely_jump_insn): Likewise.
* config/riscv/riscv-string.cc: New file.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xtheadbb-strlen-unaligned.c: New test.
* gcc.target/riscv/xtheadbb-strlen.c: New test.
* gcc.target/riscv/zbb-strlen-disabled-2.c: New test.
* gcc.target/riscv/zbb-strlen-disabled.c: New test.
* gcc.target/riscv/zbb-strlen-unaligned.c: New test.
* gcc.target/riscv/zbb-strlen.c: New test.
---
 gcc/config.gcc|   3 +-
 gcc/config/riscv/riscv-protos.h   |   3 +
 gcc/config/riscv/riscv-string.cc  | 183 ++
 gcc/config/riscv/riscv.md |  28 +++
 gcc/config/riscv/riscv.opt|   4 +
 gcc/config/riscv/t-riscv  |   6 +
 gcc/config/riscv/thead.md |   9 +-
 gcc/doc/invoke.texi   |  11 +-
 gcc/emit-rtl.cc   |  24 +++
 gcc/rtl.h |   2 +
 .../riscv/xtheadbb-strlen-unaligned.c |  14 ++
 .../gcc.target/riscv/xtheadbb-strlen.c|  19 ++
 .../gcc.target/riscv/zbb-strlen-disabled-2.c  |  15 ++
 .../gcc.target/riscv/zbb-strlen-disabled.c|  15 ++
 .../gcc.target/riscv/zbb-strlen-unaligned.c   |  14 ++
 gcc/testsuite/gcc.target/riscv/zbb-strlen.c   |  19 ++
 16 files changed, 366 insertions(+), 3 deletions(-)
 create mode 100644 gcc/config/riscv/riscv-string.cc
 create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strlen-unaligned.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strlen.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-disabled-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-disabled.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-unaligned.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen.c

diff --git a/gcc/config.gcc b/gcc/config.gcc
index b2fe7c7ceef..aff6b6a5601 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -530,7 +530,8 @@ pru-*-*)
;;
 riscv*)
cpu_type=riscv
-   extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o 
riscv-shorten-memrefs.o riscv-selftests.o riscv-v.o riscv-vsetvl.o 
riscv-vector-costs.o"
+   extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o 
riscv-shorten-memrefs.o riscv-selftests.o riscv-string.o"
+   extra_objs="${extra_objs} riscv-v.o riscv-vsetvl.o riscv-vector-costs.o"
extra_objs="${extra_objs} riscv-vector-builtins.o 
riscv-vector-builtins-shapes.o riscv-vector-builtins-bases.o"
extra_objs="${extra_objs} thead.o"
d_target_objs="riscv-d.o"
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 6dbf6b9f943..b060d047f01 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -517,6 +517,9 @@ const unsigned int RISCV_BUILTIN_SHIFT = 1;
 /* Mask that selects the riscv_builtin_class part of a function code.  */
 const unsigned int RISCV_BUILTIN_CLASS = (1 << RISCV_BUILTIN_SHIFT) - 1;
 
+/* Routines implemented in

[committed 19/12] Additional _BitInt test coverage [PR102989]

2023-09-06 Thread Jakub Jelinek via Gcc-patches
On Tue, Sep 05, 2023 at 10:40:26PM +, Joseph Myers wrote:
> Additional tests I think should be added (for things I expect should 
> already work):
> 
> * Tests for BITINT_MAXWIDTH in .  Test that it's defined for 
> C2x, but not defined for C11/C17 (the latter independent of whether the 
> target has _BitInt support).  Test the value as well: _BitInt 
> (BITINT_MAXWIDTH) should be OK (both signed and unsigned) but _BitInt 
> (BITINT_MAXWIDTH + 1) should not be OK.  Also test that BITINT_MAXWIDTH >= 
> ULLONG_MAX.
> 
> * Test _BitInt (N) where N is a constexpr variable or enum constant (I 
> expect these should work - the required call to convert_lvalue_to_rvalue 
> for constexpr to work is present - but I don't see such tests in the 
> testsuite).
> 
> * Test that -funsigned-bitfields does not affect the signedness of _BitInt 
> (N) bit-fields (the standard wording isn't entirely clear, but that's 
> what's implemented in the patches).
> 
> * Test the errors for _Sat used with _BitInt (though such a test might not 
> actually run at present because no target supports both features).

Here is a patch which adds that test coverage.

> I looked at places in c-family/ and c/ that refer to INTEGER_TYPE to 
> consider whether they should handle BITINT_TYPE and whether that matches 
> what the patch does there.  I think the following places that don't handle 
> it probably should (with appropriate testcases added for the relevant 
> functionality, e.g. warnings) unless there is some specific reason in each 
> case why that's unnecessary or incorrect.  c-pretty-print.cc: 
> c_pretty_printer::direct_declarator and c_pretty_printer::declarator.  
> c-warn.cc throughout.  Maybe c-ada-spec.cc, though it might be best to ask 
> the Ada maintainers there.  c-common.cc: unsafe_conversion_p, 
> c_common_truthvalue_conversion warnings, c_common_get_alias_set, 
> check_builtin_function_arguments BUILT_IN_ASSUME_ALIGNED case.  
> c-aux-info.cc (might need other support for generating appropriate names 
> in output).  c-parser.cc:c_parser_omp_clause_schedule.  c-fold.cc 
> throughout.  c-typeck.c: the build_conditional_expr case where one operand 
> is EXCESS_PRECISION_EXPR; build_c_cast; convert_for_assignment checks for 
> integer/pointer conversions.

As well as what I've managed to come up for the above changes.

2023-09-06  Jakub Jelinek  

PR c/102989
* gcc.dg/bitint-2.c (foo): Add tests for constexpr var or enumerator
arguments of _BitInt.
* gcc.dg/bitint-31.c: Remove forgotten 0 &&.
* gcc.dg/bitint-32.c: New test.
* gcc.dg/bitint-33.c: New test.
* gcc.dg/bitint-34.c: New test.
* gcc.dg/bitint-35.c: New test.
* gcc.dg/bitint-36.c: New test.
* gcc.dg/fixed-point/bitint-1.c: New test.

--- gcc/testsuite/gcc.dg/bitint-2.c.jj  2023-09-06 10:57:48.771535739 +0200
+++ gcc/testsuite/gcc.dg/bitint-2.c 2023-09-06 12:17:39.764073758 +0200
@@ -14,6 +14,10 @@ foo (void)
   _BitInt(5) unsigned d = (unsigned _BitInt(5)) 4;
   _BitInt(32) e = (_BitInt(32)) 5;
   _BitInt(32) unsigned f = (unsigned _BitInt(32)) 6;
+  constexpr int g = 43;
+  enum E { F = 44 };
+  _BitInt(g) h;
+  unsigned _BitInt(F) i;
   static_assert (expr_has_type (a, signed _BitInt(42)), "");
   static_assert (expr_has_type (a, _BitInt(42)), "");
   static_assert (!expr_has_type (a, unsigned _BitInt(42)), "");
@@ -66,6 +70,8 @@ foo (void)
   static_assert (expr_has_type (-1UWB, unsigned _BitInt(1)), "");
   static_assert (expr_has_type (1uWB, unsigned _BitInt(1)), "");
   static_assert (expr_has_type (2Uwb, unsigned _BitInt(2)), "");
+  static_assert (expr_has_type (h, signed _BitInt(43)), "");
+  static_assert (expr_has_type (i, unsigned _BitInt(44)), "");
   static_assert (0wb == 0, "");
   static_assert (-1wb == -1, "");
   static_assert (0xwb == 4294967295wb, "");
--- gcc/testsuite/gcc.dg/bitint-31.c.jj 2023-09-06 10:57:48.799535349 +0200
+++ gcc/testsuite/gcc.dg/bitint-31.c2023-09-06 11:52:57.675594550 +0200
@@ -255,7 +255,7 @@ main ()
   check_round (testfltu_192 (340282356779733661637539395458142568448uwb), 
__builtin_inff (), 0xffp+104f, __builtin_inff (), 0xffp+104f);
   check_round (testfltu_192 
(627710173538668076383578942320766641610235564034512895uwb), __builtin_inff 
(), 0xffp+104f, __builtin_inff (), 0xffp+104f);
 #endif
-#if 0 && __BITINT_MAXWIDTH__ >= 575
+#if __BITINT_MAXWIDTH__ >= 575
   check_round (testflt_575 (10633823015541376812058405359715352575wb), 
0xfep+99f, 0xfep+99f, 0xffp+99f, 0xfep+99f);
   check_round (testflt_575 (10633823015541376812058405359715352576wb), 
0xfep+99f, 0xfep+99f, 0xffp+99f, 0xfep+99f);
   check_round (testflt_575 (10633823015541376812058405359715352577wb), 
0xffp+99f, 0xfep+99f, 0xffp+99f, 0xfep+99f);
--- gcc/testsuite/gcc.dg/bitint-32.c.jj 2023-09-06 11:57:24.391907466 +0200
+++ gcc/testsuite/gcc.dg/bitint-32.c2023-09-06 12:00:04.885688154 +0200

Re: [PATCH v2 1/2] riscv: Add support for strlen inline expansion

2023-09-06 Thread Palmer Dabbelt

On Wed, 06 Sep 2023 09:07:33 PDT (-0700), christoph.muell...@vrull.eu wrote:

From: Christoph Müllner 

This patch implements the expansion of the strlen builtin for RV32/RV64
for xlen-aligned aligned strings if Zbb or XTheadBb instructions are available.
The inserted sequences are:

rv32gc_zbb (RV64 is similar):
  add a3,a0,4
  li  a4,-1
.L1:  lw  a5,0(a0)
  add a0,a0,4
  orc.b   a5,a5
  beq a5,a4,.L1
  not a5,a5
  ctz a5,a5
  srl a5,a5,0x3
  add a0,a0,a5
  sub a0,a0,a3

rv64gc_xtheadbb (RV32 is similar):
  add   a4,a0,8
.L2:  lda5,0(a0)
  add   a0,a0,8
  th.tstnbz a5,a5
  beqz  a5,.L2
  th.reva5,a5
  th.ff1a5,a5
  srl   a5,a5,0x3
  add   a0,a0,a5
  sub   a0,a0,a4

This allows to inline calls to strlen(), with optimized code for
xlen-aligned strings, resulting in the following benefits over
a call to libc:
* no call/ret instructions
* no stack frame allocation
* no register saving/restoring
* no alignment test

The inlining mechanism is gated by a new switch ('-minline-strlen')
and by the variable 'optimize_size'.


Maybe this is more of a Jeff question, but this looks to me like 
something that should be target-agnostic -- maybe we need some backend 
work to actually emit the special instruction, but IIRC this is a 
somewhat common flavor of instruction and is in other ISAs as well.  It 
looks like there's already a strlen insn, so I guess the core issue is 
why we need that unspec?


Sorry if I'm just missing something, though...


Tested using the glibc string tests.

Signed-off-by: Christoph Müllner 

gcc/ChangeLog:

* config.gcc: Add new object riscv-string.o.
riscv-string.cc.
* config/riscv/riscv-protos.h (riscv_expand_strlen):
New function.
* config/riscv/riscv.md (strlen): New expand INSN.
* config/riscv/riscv.opt: New flag 'minline-strlen'.
* config/riscv/t-riscv: Add new object riscv-string.o.
* config/riscv/thead.md (th_rev2): Export INSN name.
(th_rev2): Likewise.
(th_tstnbz2): New INSN.
* doc/invoke.texi: Document '-minline-strlen'.
* emit-rtl.cc (emit_likely_jump_insn): New helper function.
(emit_unlikely_jump_insn): Likewise.
* rtl.h (emit_likely_jump_insn): New prototype.
(emit_unlikely_jump_insn): Likewise.
* config/riscv/riscv-string.cc: New file.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/xtheadbb-strlen-unaligned.c: New test.
* gcc.target/riscv/xtheadbb-strlen.c: New test.
* gcc.target/riscv/zbb-strlen-disabled-2.c: New test.
* gcc.target/riscv/zbb-strlen-disabled.c: New test.
* gcc.target/riscv/zbb-strlen-unaligned.c: New test.
* gcc.target/riscv/zbb-strlen.c: New test.
---
 gcc/config.gcc|   3 +-
 gcc/config/riscv/riscv-protos.h   |   3 +
 gcc/config/riscv/riscv-string.cc  | 183 ++
 gcc/config/riscv/riscv.md |  28 +++
 gcc/config/riscv/riscv.opt|   4 +
 gcc/config/riscv/t-riscv  |   6 +
 gcc/config/riscv/thead.md |   9 +-
 gcc/doc/invoke.texi   |  11 +-
 gcc/emit-rtl.cc   |  24 +++
 gcc/rtl.h |   2 +
 .../riscv/xtheadbb-strlen-unaligned.c |  14 ++
 .../gcc.target/riscv/xtheadbb-strlen.c|  19 ++
 .../gcc.target/riscv/zbb-strlen-disabled-2.c  |  15 ++
 .../gcc.target/riscv/zbb-strlen-disabled.c|  15 ++
 .../gcc.target/riscv/zbb-strlen-unaligned.c   |  14 ++
 gcc/testsuite/gcc.target/riscv/zbb-strlen.c   |  19 ++
 16 files changed, 366 insertions(+), 3 deletions(-)
 create mode 100644 gcc/config/riscv/riscv-string.cc
 create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strlen-unaligned.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/xtheadbb-strlen.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-disabled-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-disabled.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen-unaligned.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/zbb-strlen.c

diff --git a/gcc/config.gcc b/gcc/config.gcc
index b2fe7c7ceef..aff6b6a5601 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -530,7 +530,8 @@ pru-*-*)
;;
 riscv*)
cpu_type=riscv
-   extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o riscv-shorten-memrefs.o 
riscv-selftests.o riscv-v.o riscv-vsetvl.o riscv-vector-costs.o"
+   extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o riscv-shorten-memrefs.o 
riscv-selftests.o riscv-string.o"
+   extra_objs="${extra_objs} riscv-v.o riscv-vsetvl.o riscv-vector-costs.o"
extra_objs="${extra_objs} riscv-vector-builtins.o 
riscv-vector-builtins-shapes.o riscv-vector-builtins-bases.o"
   

Re: [PATCH v2 1/2] riscv: Add support for strlen inline expansion

2023-09-06 Thread Jeff Law via Gcc-patches




On 9/6/23 10:22, Palmer Dabbelt wrote:
On Wed, 06 Sep 2023 09:07:33 PDT (-0700), christoph.muell...@vrull.eu 
wrote:

From: Christoph Müllner 

This patch implements the expansion of the strlen builtin for RV32/RV64
for xlen-aligned aligned strings if Zbb or XTheadBb instructions are 
available.

The inserted sequences are:

rv32gc_zbb (RV64 is similar):
  add a3,a0,4
  li  a4,-1
.L1:  lw  a5,0(a0)
  add a0,a0,4
  orc.b   a5,a5
  beq a5,a4,.L1
  not a5,a5
  ctz a5,a5
  srl a5,a5,0x3
  add a0,a0,a5
  sub a0,a0,a3

rv64gc_xtheadbb (RV32 is similar):
  add   a4,a0,8
.L2:  ld    a5,0(a0)
  add   a0,a0,8
  th.tstnbz a5,a5
  beqz  a5,.L2
  th.rev    a5,a5
  th.ff1    a5,a5
  srl   a5,a5,0x3
  add   a0,a0,a5
  sub   a0,a0,a4

This allows to inline calls to strlen(), with optimized code for
xlen-aligned strings, resulting in the following benefits over
a call to libc:
* no call/ret instructions
* no stack frame allocation
* no register saving/restoring
* no alignment test

The inlining mechanism is gated by a new switch ('-minline-strlen')
and by the variable 'optimize_size'.


Maybe this is more of a Jeff question, but this looks to me like 
something that should be target-agnostic -- maybe we need some backend 
work to actually emit the special instruction, but IIRC this is a 
somewhat common flavor of instruction and is in other ISAs as well.  It 
looks like there's already a strlen insn, so I guess the core issue is 
why we need that unspec?


Sorry if I'm just missing something, though...


The generic strlen expansion in GCC doesn't really expand a strlen loop. 
 It really just calls into the target code and forces the target to 
handle everything.



We could have generic strlen expansion code that kicks in if the target 
expander fails.  And we could probably create the necessary opcodes to 
express the optimized end-of-string comparison instructions that exist 
on various architectures.  I'm not not sure it's worth that much effort 
given targets are already doing their own strlen expansions.


jeff


[PATCH 0/5] RISC-V: Add Types to Untyped Instructions

2023-09-06 Thread Edwin Lu
This series adds types to the remaining untyped instructions.

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

Also enables assert which checks to make sure every instruction has a type

All patches were tested with rv32/rv64 linux/newlib multilib
Additional extensions tested:
gcv
gc_zba_zbb_zbc_zbs

Edwin Lu (5):
  RISC-V: Update Types for Vector Instructions
  RISC-V: Add Types for Un-Typed zc Instructions
  RISC-V: Add Types to Un-Typed Zicond Instructions
  RISC-V: Add Types to Un-Typed Zicond Instructions
  RISC-V: Remove Assert Protecting Types

 gcc/config/riscv/autovec-opt.md |  42 -
 gcc/config/riscv/autovec.md |  28 ++---
 gcc/config/riscv/riscv.cc   |   2 -
 gcc/config/riscv/riscv.md   |   9 ++-
 gcc/config/riscv/zc.md  | 102 
 gcc/config/riscv/zicond.md  |   8 +--
 6 files changed, 110 insertions(+), 81 deletions(-)

-- 
2.34.1



[PATCH 1/5] RISC-V: Update Types for Vector Instructions

2023-09-06 Thread Edwin Lu
This patch adds types to vector instructions that were added after or were
missed by the original patch 
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628594.html

gcc/ChangeLog:

* config/riscv/autovec-opt.md: Update types
* config/riscv/autovec.md: likewise

Signed-off-by: Edwin Lu 
---
 gcc/config/riscv/autovec-opt.md | 42 ++---
 gcc/config/riscv/autovec.md | 28 +++---
 2 files changed, 47 insertions(+), 23 deletions(-)

diff --git a/gcc/config/riscv/autovec-opt.md b/gcc/config/riscv/autovec-opt.md
index 1ca5ce97193..6cc1a01629c 100644
--- a/gcc/config/riscv/autovec-opt.md
+++ b/gcc/config/riscv/autovec-opt.md
@@ -728,7 +728,8 @@ (define_insn_and_split "*cond_abs"
 gen_int_mode (GET_MODE_NUNITS 
(mode), Pmode),
 const0_rtx));
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine vlmax neg and UNSPEC_VCOPYSIGN
 (define_insn_and_split "*copysign_neg"
@@ -746,7 +747,8 @@ (define_insn_and_split "*copysign_neg"
   riscv_vector::emit_vlmax_insn (code_for_pred_ncopysign (mode),
   riscv_vector::BINARY_OP, operands);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine sign_extend/zero_extend(vf2) and vcond_mask
 (define_insn_and_split "*cond_"
@@ -765,7 +767,8 @@ (define_insn_and_split "*cond_"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine sign_extend/zero_extend(vf4) and vcond_mask
 (define_insn_and_split "*cond_"
@@ -784,7 +787,8 @@ (define_insn_and_split "*cond_"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine sign_extend/zero_extend(vf8) and vcond_mask
 (define_insn_and_split "*cond_"
@@ -803,7 +807,8 @@ (define_insn_and_split "*cond_"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine trunc(vf2) + vcond_mask
 (define_insn_and_split "*cond_trunc"
@@ -823,7 +828,8 @@ (define_insn_and_split "*cond_trunc"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine FP sign_extend/zero_extend(vf2) and vcond_mask
 (define_insn_and_split "*cond_extend"
@@ -842,7 +848,8 @@ (define_insn_and_split "*cond_extend"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine FP trunc(vf2) + vcond_mask
 (define_insn_and_split "*cond_trunc"
@@ -862,7 +869,8 @@ (define_insn_and_split "*cond_trunc"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine convert(FP->INT) + vcond_mask
 (define_insn_and_split "*cond_"
@@ -882,7 +890,8 @@ (define_insn_and_split "*cond_"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine convert(INT->FP) + vcond_mask
 (define_insn_and_split "*cond_"
@@ -902,7 +911,8 @@ (define_insn_and_split "*cond_"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine convert(FP->2xINT) + vcond_mask
 (define_insn_and_split "*cond_"
@@ -922,7 +932,8 @@ (define_insn_and_split "*cond_"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine convert(INT->2xFP) + vcond_mask
 (define_insn_and_split "*cond_"
@@ -942,7 +953,8 @@ (define_insn_and_split "*cond_"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine convert(2xFP->INT) + vcond_mask
 (define_insn_and_split "*cond_"
@@ -962,7 +974,8 @@ (define_insn_and_split "*cond_"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
 
 ;; Combine convert(2xINT->FP) + vcond_mask
 (define_insn_and_split "*cond_2"
@@ -982,4 +995,5 @@ (define_insn_and_split "*cond_2"
gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
   riscv_vector::expand_cond_len_unop (icode, ops);
   DONE;
-})
+}
+[(set_attr "type" "vector")])
diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index 0f9d1fe2c8e..047a66b238f 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/conf

[PATCH 2/5] RISC-V: Add Types for Un-Typed zc Instructions

2023-09-06 Thread Edwin Lu
This patch adds types to the untyped zc instructions. Creates a new
type "csr" for these instructions for now.

gcc/ChangeLog:

* config/riscv/riscv.md: Add "csr" type
* config/riscv/zc.md: Update types

Signed-off-by: Edwin Lu 
---
 gcc/config/riscv/riscv.md |   3 +-
 gcc/config/riscv/zc.md| 102 +++---
 2 files changed, 54 insertions(+), 51 deletions(-)

diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index d80b6938f84..6684ad89cff 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -312,6 +312,7 @@ (define_attr "ext_enabled" "no,yes"
 ;; condmoveconditional moves
 ;; cbocache block instructions
 ;; crypto cryptography instructions
+;; csrcode size reduction instructions
 ;; Classification of RVV instructions which will be added to each RVV .md 
pattern and used by scheduler.
 ;; rdvlenb vector byte length vlenb csrr read
 ;; rdvlvector length vl csrr read
@@ -421,7 +422,7 @@ (define_attr "type"
mtc,mfc,const,arith,logical,shift,slt,imul,idiv,move,fmove,fadd,fmul,
fmadd,fdiv,fcmp,fcvt,fsqrt,multi,auipc,sfb_alu,nop,trap,ghost,bitmanip,
rotate,clmul,min,max,minu,maxu,clz,ctz,cpop,
-   atomic,condmove,cbo,crypto,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl,
+   atomic,condmove,cbo,crypto,csr,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl,
vlde,vste,vldm,vstm,vlds,vsts,
vldux,vldox,vstux,vstox,vldff,vldr,vstr,

vlsegde,vssegte,vlsegds,vssegts,vlsegdux,vlsegdox,vssegtux,vssegtox,vlsegdff,
diff --git a/gcc/config/riscv/zc.md b/gcc/config/riscv/zc.md
index 77b28adde95..86f1afd66cb 100644
--- a/gcc/config/riscv/zc.md
+++ b/gcc/config/riscv/zc.md
@@ -27,7 +27,7 @@ (define_insn "@gpr_multi_pop_up_to_ra_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s0_"
   [(set (reg:X SP_REGNUM)
@@ -41,7 +41,7 @@ (define_insn "@gpr_multi_pop_up_to_s0_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s1_"
   [(set (reg:X SP_REGNUM)
@@ -58,7 +58,7 @@ (define_insn "@gpr_multi_pop_up_to_s1_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s1}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s2_"
   [(set (reg:X SP_REGNUM)
@@ -78,7 +78,7 @@ (define_insn "@gpr_multi_pop_up_to_s2_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s2}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s3_"
   [(set (reg:X SP_REGNUM)
@@ -101,7 +101,7 @@ (define_insn "@gpr_multi_pop_up_to_s3_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s3}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s4_"
   [(set (reg:X SP_REGNUM)
@@ -127,7 +127,7 @@ (define_insn "@gpr_multi_pop_up_to_s4_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s4}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s5_"
   [(set (reg:X SP_REGNUM)
@@ -156,7 +156,7 @@ (define_insn "@gpr_multi_pop_up_to_s5_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s5}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s6_"
   [(set (reg:X SP_REGNUM)
@@ -188,7 +188,7 @@ (define_insn "@gpr_multi_pop_up_to_s6_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s6}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s7_"
   [(set (reg:X SP_REGNUM)
@@ -223,7 +223,7 @@ (define_insn "@gpr_multi_pop_up_to_s7_"
   (const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s7}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s8_"
   [(set (reg:X SP_REGNUM)
@@ -261,7 +261,7 @@ (define_insn "@gpr_multi_pop_up_to_s8_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s8}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s9_"
   [(set (reg:X SP_REGNUM)
@@ -302,7 +302,7 @@ (define_insn "@gpr_multi_pop_up_to_s9_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s9}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_pop_up_to_s11_"
   [(set (reg:X SP_REGNUM)
@@ -349,7 +349,7 @@ (define_insn "@gpr_multi_pop_up_to_s11_"
(const_int ]
   "TARGET_ZCMP"
   "cm.pop  {ra, s0-s11}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_popret_up_to_ra_"
   [(set (reg:X SP_REGNUM)
@@ -362,7 +362,7 @@ (define_insn "@gpr_multi_popret_up_to_ra_"
(use (reg:SI RETURN_ADDR_REGNUM))]
   "TARGET_ZCMP"
   "cm.popret   {ra}, %0"
-)
+[(set_attr "type" "csr")])
 
 (define_insn "@gpr_multi_popret_up_to_s0_"
   [(set (reg:X SP_REGNUM)
@@ -378,7 +378,7 @@ (define_insn "@gpr_multi_po

[PATCH 4/5] RISC-V: Update Types for RISC-V Instructions

2023-09-06 Thread Edwin Lu
This patch adds types to riscv instructions that were added or were
missed by the original patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628996.html

gcc/ChangeLog:

* config/riscv/riscv.md: Update types

Signed-off-by: Edwin Lu 
---
 gcc/config/riscv/riscv.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index c329f55db43..c1cecd27815 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -2223,6 +2223,7 @@ (define_insn "movsidf2_low_rv32"
   "TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA"
   "fmv.x.w\t%0,%1"
   [(set_attr "move_type" "fmove")
+   (set_attr "type" "fmove")
(set_attr "mode" "DF")])
 
 
@@ -2235,6 +2236,7 @@ (define_insn "movsidf2_high_rv32"
   "TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA"
   "fmvh.x.d\t%0,%1"
   [(set_attr "move_type" "fmove")
+   (set_attr "type" "fmove")
(set_attr "mode" "DF")])
 
 (define_insn "movdfsisi3_rv32"
@@ -2247,6 +2249,7 @@ (define_insn "movdfsisi3_rv32"
   "TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA"
   "fmvp.d.x\t%0,%2,%1"
   [(set_attr "move_type" "fmove")
+   (set_attr "type" "fmove")
(set_attr "mode" "DF")])
 
 (define_split
-- 
2.34.1



[PATCH 3/5] RISC-V: Add Types to Un-Typed Zicond Instructions

2023-09-06 Thread Edwin Lu
This patch creates a new "zicond" type and updates all zicond instructions
with that type.

gcc/ChangeLog:

* config/riscv/riscv.md: Add "zicond" type
* config/riscv/zicond.md: Update types

Signed-off-by: Edwin Lu 
---
 gcc/config/riscv/riscv.md  | 5 +++--
 gcc/config/riscv/zicond.md | 8 
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index 6684ad89cff..c329f55db43 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -313,6 +313,7 @@ (define_attr "ext_enabled" "no,yes"
 ;; cbocache block instructions
 ;; crypto cryptography instructions
 ;; csrcode size reduction instructions
+;; zicondzicond instructions
 ;; Classification of RVV instructions which will be added to each RVV .md 
pattern and used by scheduler.
 ;; rdvlenb vector byte length vlenb csrr read
 ;; rdvlvector length vl csrr read
@@ -422,8 +423,8 @@ (define_attr "type"
mtc,mfc,const,arith,logical,shift,slt,imul,idiv,move,fmove,fadd,fmul,
fmadd,fdiv,fcmp,fcvt,fsqrt,multi,auipc,sfb_alu,nop,trap,ghost,bitmanip,
rotate,clmul,min,max,minu,maxu,clz,ctz,cpop,
-   atomic,condmove,cbo,crypto,csr,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl,
-   vlde,vste,vldm,vstm,vlds,vsts,
+   atomic,condmove,cbo,crypto,csr,zicond,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,
+   vsetvl, vlde,vste,vldm,vstm,vlds,vsts,
vldux,vldox,vstux,vstox,vldff,vldr,vstr,

vlsegde,vssegte,vlsegds,vssegts,vlsegdux,vlsegdox,vssegtux,vssegtox,vlsegdff,
vialu,viwalu,vext,vicalu,vshift,vnshift,vicmp,viminmax,
diff --git a/gcc/config/riscv/zicond.md b/gcc/config/riscv/zicond.md
index 1721e1011ea..0269bd14399 100644
--- a/gcc/config/riscv/zicond.md
+++ b/gcc/config/riscv/zicond.md
@@ -30,7 +30,7 @@ (define_insn "*czero.."
   (const_int 0)))]
   "TARGET_ZICOND"
   "czero.\t%0,%2,%1"
-)
+[(set_attr "type" "zicond")])
 
 (define_insn "*czero.."
   [(set (match_operand:GPR 0 "register_operand" "=r")
@@ -40,7 +40,7 @@ (define_insn "*czero.."
   (match_operand:GPR 2 "register_operand"   "r")))]
   "TARGET_ZICOND"
   "czero.\t%0,%2,%1"
-)
+[(set_attr "type" "zicond")])
 
 ;; Special optimization under eq/ne in primitive semantics
 (define_insn "*czero.eqz..opt1"
@@ -51,7 +51,7 @@ (define_insn "*czero.eqz..opt1"
   (match_operand:GPR 3 "register_operand" "r")))]
   "TARGET_ZICOND && rtx_equal_p (operands[1], operands[2])"
   "czero.eqz\t%0,%3,%1"
-)
+[(set_attr "type" "zicond")])
 
 (define_insn "*czero.nez..opt2"
   [(set (match_operand:GPR 0 "register_operand"   "=r")
@@ -61,7 +61,7 @@ (define_insn "*czero.nez..opt2"
   (match_operand:GPR 3 "register_operand" "1")))]
   "TARGET_ZICOND && rtx_equal_p (operands[1], operands[3])"
   "czero.eqz\t%0,%2,%1"
-)
+[(set_attr "type" "zicond")])
 
 ;; Combine creates this form in some cases (particularly the coremark
 ;; CRC loop.
-- 
2.34.1



[PATCH 5/5] RISC-V: Remove Assert Protecting Types

2023-09-06 Thread Edwin Lu
This patch turns on the assert which ensures every instruction has type
that is not TYPE_UNKNOWN.

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_sched_variable_issue): Remove assert

Signed-off-by: Edwin Lu 
---
 gcc/config/riscv/riscv.cc | 2 --
 1 file changed, 2 deletions(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index ef63079de8e..f0576351cda 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -7330,11 +7330,9 @@ riscv_sched_variable_issue (FILE *, int, rtx_insn *insn, 
int more)
   if (get_attr_type (insn) == TYPE_GHOST)
 return 0;
 
-#if 0
   /* If we ever encounter an insn with an unknown type, trip
  an assert so we can find and fix this problem.  */
   gcc_assert (get_attr_type (insn) != TYPE_UNKNOWN);
-#endif
 
   return more - 1;
 }
-- 
2.34.1



libgo patch committed: permit $AR to include options

2023-09-06 Thread Ian Lance Taylor via Gcc-patches
This libgo patch changes the go tool to permit the AR environment
variable to include options.  This mirrors the way it already handles
the CC environment variable.

This ports https://go.dev/cl/526275 to the gofrontend repo.

This is needed for gccgo testing because the top-level GCC Makefile
now passes a --plugin option to ar if it supports one.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
dab7163feedc99bd94549ee490031f86f8d0a6ca
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 83ab3e2d64c..30710e856cb 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-d04b024021bb7dbaa434a6d902bd12beb08e315f
+53cdfab53ce79d8dfc1df01a696d4ffc43f17c3d
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/go/cmd/go/internal/work/gccgo.go 
b/libgo/go/cmd/go/internal/work/gccgo.go
index c1026c71e01..3e07f8791eb 100644
--- a/libgo/go/cmd/go/internal/work/gccgo.go
+++ b/libgo/go/cmd/go/internal/work/gccgo.go
@@ -45,12 +45,8 @@ func (gccgoToolchain) linker() string {
return GccgoBin
 }
 
-func (gccgoToolchain) ar() string {
-   ar := cfg.Getenv("AR")
-   if ar == "" {
-   ar = "ar"
-   }
-   return ar
+func (gccgoToolchain) ar() []string {
+   return envList("AR", "ar")
 }
 
 func checkGccgoBin() {


Re: [PATCH v2 1/2] riscv: Add support for strlen inline expansion

2023-09-06 Thread Palmer Dabbelt

On Wed, 06 Sep 2023 09:47:05 PDT (-0700), jeffreya...@gmail.com wrote:



On 9/6/23 10:22, Palmer Dabbelt wrote:

On Wed, 06 Sep 2023 09:07:33 PDT (-0700), christoph.muell...@vrull.eu
wrote:

From: Christoph Müllner 

This patch implements the expansion of the strlen builtin for RV32/RV64
for xlen-aligned aligned strings if Zbb or XTheadBb instructions are
available.
The inserted sequences are:

rv32gc_zbb (RV64 is similar):
  add a3,a0,4
  li  a4,-1
.L1:  lw  a5,0(a0)
  add a0,a0,4
  orc.b   a5,a5
  beq a5,a4,.L1
  not a5,a5
  ctz a5,a5
  srl a5,a5,0x3
  add a0,a0,a5
  sub a0,a0,a3

rv64gc_xtheadbb (RV32 is similar):
  add   a4,a0,8
.L2:  ld    a5,0(a0)
  add   a0,a0,8
  th.tstnbz a5,a5
  beqz  a5,.L2
  th.rev    a5,a5
  th.ff1    a5,a5
  srl   a5,a5,0x3
  add   a0,a0,a5
  sub   a0,a0,a4

This allows to inline calls to strlen(), with optimized code for
xlen-aligned strings, resulting in the following benefits over
a call to libc:
* no call/ret instructions
* no stack frame allocation
* no register saving/restoring
* no alignment test

The inlining mechanism is gated by a new switch ('-minline-strlen')
and by the variable 'optimize_size'.


Maybe this is more of a Jeff question, but this looks to me like
something that should be target-agnostic -- maybe we need some backend
work to actually emit the special instruction, but IIRC this is a
somewhat common flavor of instruction and is in other ISAs as well.  It
looks like there's already a strlen insn, so I guess the core issue is
why we need that unspec?

Sorry if I'm just missing something, though...


The generic strlen expansion in GCC doesn't really expand a strlen loop.
  It really just calls into the target code and forces the target to
handle everything.


OK, that explains it.


We could have generic strlen expansion code that kicks in if the target
expander fails.  And we could probably create the necessary opcodes to
express the optimized end-of-string comparison instructions that exist
on various architectures.  I'm not not sure it's worth that much effort
given targets are already doing their own strlen expansions.



If everyone does it this way then I don't think we need to worry about 
it.




jeff


[PATCH v2] analyzer: Call off a superseding when diagnostics are unrelated [PR110830]

2023-09-06 Thread Benjamin Priour via Gcc-patches
From: benjamin priour 

Hi,

Second version of this patch after David's suggestions.
Thanks David for pointing out how I could implement it using sedges.
I hadn't thought of them being independent of the exploded path taken,
and unique for a conditional block's outcome. I had mistaken them with
eedges, those that we see in the *exploded*-graph, therefore since the
two saved_diagnostics can have arbitrary different paths I had to
use a nested loop.

It is much more efficient this way.

Regstrapped off trunk a7d052b3200c7928d903a0242b8cfd75d131e374 on
x86_64-linux-gnu.

Is it ready for trunk ?

Thanks,
Benjamin.

Patch below.
---

Before this patch, a saved_diagnostic would supersede another at
the same statement if and only its vfunc supercedes_p returned true
for the other diagnostic's kind.
That both warning were unrelated - i.e. resolving one would not fix
the other - was not considered in making the above choice.

This patch makes it so that two saved_diagnostics taking a different
outcome of at least one common conditional branching cannot supersede
each other.

Signed-off-by: benjamin priour 
Co-authored-by: david malcolm 

gcc/analyzer/ChangeLog:

PR analyzer/110830
* diagnostic-manager.cc
(compatible_epaths_p): New function.
(saved_diagnostic::supercedes_p): Now calls the above
to determine if the diagnostics do overlap and the superseding
may proceed.

gcc/testsuite/ChangeLog:

PR analyzer/110830
* c-c++-common/analyzer/pr110830.c: New test.
---
 gcc/analyzer/diagnostic-manager.cc|  90 +-
 .../c-c++-common/analyzer/pr110830.c  | 111 ++
 2 files changed, 200 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/c-c++-common/analyzer/pr110830.c

diff --git a/gcc/analyzer/diagnostic-manager.cc 
b/gcc/analyzer/diagnostic-manager.cc
index 10fea486b8c..90c56a350e7 100644
--- a/gcc/analyzer/diagnostic-manager.cc
+++ b/gcc/analyzer/diagnostic-manager.cc
@@ -887,6 +887,88 @@ saved_diagnostic::add_duplicate (saved_diagnostic *other)
   m_duplicates.safe_push (other);
 }
 
+/* Walk up the sedges of each of the two paths.
+   If the two sequences of sedges do not perfectly correspond,
+   then paths are incompatible.
+   If there is at least one sedge that either cannot be paired up
+   or its counterpart is not equal, then the paths are incompatible
+   and this function returns FALSE.
+   Otherwise return TRUE.
+
+   Incompatible paths:
+
+   
+   /  \
+  /\
+true  false
+ |  |
+......
+ |  |
+...   stmt x
+ |
+   stmt x
+
+   Both LHS_PATH and RHS_PATH final enodes should be
+   over the same gimple statement.  */
+
+static bool
+compatible_epath_p (const exploded_path *lhs_path,
+   const exploded_path *rhs_path)
+{
+  gcc_assert (lhs_path);
+  gcc_assert (rhs_path);
+  gcc_assert (rhs_path->length () > 0);
+  gcc_assert (rhs_path->length () > 0);
+  int lhs_eedge_idx = lhs_path->length () -1;
+  int rhs_eedge_idx = rhs_path->length () -1;
+  const exploded_edge *lhs_eedge;
+  const exploded_edge *rhs_eedge;
+
+  while (lhs_eedge_idx >= 0 && rhs_eedge_idx >= 0)
+{
+  while (lhs_eedge_idx >= 0)
+   {
+ /* Find LHS_PATH's next superedge.  */
+ lhs_eedge = lhs_path->m_edges[lhs_eedge_idx];
+ if (lhs_eedge->m_sedge)
+   break;
+ else
+   lhs_eedge_idx--;
+   }
+  while (rhs_eedge_idx >= 0)
+   {
+ /* Find RHS_PATH's next superedge.  */
+ rhs_eedge = rhs_path->m_edges[rhs_eedge_idx];
+ if (rhs_eedge->m_sedge)
+   break;
+ else
+   rhs_eedge_idx--;
+   }
+
+  if (lhs_eedge->m_sedge && rhs_eedge->m_sedge)
+   {
+ if (lhs_eedge->m_sedge != rhs_eedge->m_sedge)
+   /* Both superedges do not match.
+  Superedges are not dependent on the exploded path, so even
+  different epaths will have similar sedges if they follow
+  the same outcome of a conditional node.  */
+   return false;
+
+ lhs_eedge_idx--;
+ rhs_eedge_idx--;
+ continue;
+   }
+  else if (lhs_eedge->m_sedge == nullptr && rhs_eedge->m_sedge == nullptr)
+   /* Both paths were drained up entirely.
+  No discriminant was found.  */
+   return true;
+
+  /* A superedge was found for only one of the two paths.  */
+  return false;
+}
+}
+
+
 /* Return true if this diagnostic supercedes OTHER, and that OTHER should
therefore not be emitted.  */
 
@@ -896,7 +978,13 @@ saved_diagnostic::supercedes_p (const saved_diagnostic 
&other) const
   /* They should be at the same stmt.  */
   if (m_stmt != other.m_stmt)
 return false;
-  return m_d->supercedes_p (*other.m_d);
+  /* return early if OTHER won't be superseded anyway.  */
+  if (!m_d->supercedes_p (*other.m_d))
+return false;
+
+  /* If th

Re: [PATCH 01/13] [APX EGPR] middle-end: Add insn argument to base_reg_class

2023-09-06 Thread Vladimir Makarov via Gcc-patches



On 9/1/23 05:07, Hongyu Wang wrote:

Uros Bizjak via Gcc-patches  于2023年8月31日周四 18:16写道:

On Thu, Aug 31, 2023 at 10:20 AM Hongyu Wang  wrote:

From: Kong Lingling 

Current reload infrastructure does not support selective base_reg_class
for backend insn. Add insn argument to base_reg_class for
lra/reload usage.

I don't think this is the correct approach. Ideally, a memory
constraint should somehow encode its BASE/INDEX register class.
Instead of passing "insn", simply a different constraint could be used
in the constraint string of the relevant insn.

We tried constraint only at the beginning, but then we found the
reload infrastructure
does not work like that.

The BASE/INDEX reg classes are determined before choosing alternatives, in
process_address under curr_insn_transform. Process_address creates the mem
operand according to the BASE/INDEX reg class. Then, the memory operand
constraint check will evaluate the mem op with targetm.legitimate_address_p.

If we want to make use of EGPR in base/index we need to either extend BASE/INDEX
reg class in the backend, or, for specific insns, add a target hook to
tell reload
that the extended reg class with EGPR can be used to construct memory operand.

CC'd Vladimir as git send-mail failed to add recipient.



I think the approach proposed by Intel developers is better.  In some way
we already use such approach when we pass memory mode to get the base
reg class.  Although we could use different memory constraints for
different modes when the possible base reg differs for some memory
modes.

Using special memory constraints probably can be implemented too (I
understand attractiveness of such approach for readability of the
machine description).  But in my opinion it will require much bigger
work in IRA/LRA/reload.  It also significantly slow down RA as we need
to process insn constraints for processing each memory in many places
(e.g. for calculation of reg classes and costs in IRA).  Still I think
there will be a few cases for this approach resulting in a bigger
probability of assigning hard reg out of specific base reg class and
this will result in additional reloads.

So the approach proposed by Intel is ok for me.  Although if x86 maintainers
are strongly against this approach and the changes in x86 machine
dependent code and Intel developers implement Uros approach, I am
ready to review this.  But still I prefer the current Intel developers
approach for reasons I mentioned above.



Re: [PATCH] analyzer: Move gcc.dg/analyzer tests to c-c++-common (2) [PR96395]

2023-09-06 Thread David Malcolm via Gcc-patches
On Wed, 2023-09-06 at 15:50 +0200, Benjamin Priour wrote:
> Hi David,
> Thanks for the review.
> 
> 
> 
> On Tue, Sep 5, 2023 at 1:53 PM David Malcolm 
> wrote:
> 
> > On Mon, 2023-09-04 at 20:00 +0200, priour...@gmail.com wrote:
> > 
> > 
> [...snip...]
> 
> 
> > All of these "new" tests (apart from the "-noexcept" ones) look
> > like
> > they're meant to be existing tests that were moved, but where the
> > copy
> > of the test in gcc.dg/analyzer didn't get deleted, so they show up
> > as a
> > duplicate.  See the details below.
> > 
> 
> > >   * c-c++-common/analyzer/file-pr58237-noexcept.c: New test.
> > 
> > When duplicating a test like this, the test isn't entirely "new",
> > so
> > please say something like this in the ChangeLog entry, to make it
> > clear
> > where it came from:
> > 
> > 
> I actually wasn't sure about these -noexcept tests. They were part
> of gcc.dg/analyzer, thus only gcc was running them. Exceptions
> were not disabled *explicitly*, but since it was C, they weren't
> enabled
> either.
> 
> Therefore, the -noexcept tests are basically a copy, but with an
> explicit
> -fno-exceptions specification.
> When I duplicated them in that way I was thinking about making it
> clear
> that these tests fail in C++ with exceptions enabled, so that we
> would
> already
> have easy-to-spot failing tests to challenge a future exception
> support.

Ah, OK; let's go with your approach.

> 
> Though perhaps *not* duplicating the tests but rather simply specify
> -fno-exceptions,
> with a comment "Fails with exceptions" may be better.

[...snip...]

> > > @@ -45,7 +45,7 @@ void test(int n)
> > >    struct iter *it = iter_new (0, n, 1);
> > >    while (!iter_done_p (it))
> > >  {
> > > -  __analyzer_eval (it->val < n); /* { dg-warning "TRUE"
> > > "true" {
> > xfail *-*-* } } */
> > > +  __analyzer_eval (it->val < n); /* { dg-warning "TRUE"
> > > "true" } */
> > >    /* { dg-bogus "UNKNOWN" "unknown" { xfail *-*-* } .-1 } */
> > >    /* TODO(xfail^^^): ideally we ought to figure out i > 0
> > > after 1st
> > iteration.  */
> > > 
> > 
> > Presumably due to the change to
> > region_model::add_constraints_from_binop, right?
> > Looking at that dg-bogus "UNKNOWN", do we still get an UNKNOWN
> > here, or
> > can that line be removed?
> > If so, then the 3rd comment can presumably become:
> > 
> > 
> The bogus here still make sense - without it there is an excess error
> -.
> I had checked for it because I too thought it could be removed.
> If I remember it correctly, we get UNKNOWN during the widening pass.

(nods)

> 
> 
> > >    /* TODO: ideally we ought to figure out i > 0 after 1st
> > iteration.  */
> > 
> > [...snip...]
> > 
> > 
> > 
> [...snip...]
> 
> Thanks for spotting the files I forgot to remove from gcc.dg.
> Sorry about them, I had messed up my test folder when checking for
> arm-eabi,
> and I apparently missed some duplicates when retrieving my save.
> 
> As for the files the likes of inlining-*.c, i.e. noted as Moved
> to/...here.
> at the end of the ChangeLog, some tests checking for multiline
> outputs
> are so heavily rewritten than git marks them as Removed/New test
> instead of moved. I've manually edited that, but perhaps I shouldn't
> ?
> 
> I have successfully regstrapped the improvements you suggested.

Thanks.  Did you want me to doublecheck the updated patch?  Otherwise
feel free to push it to trunk.


> Part 3 of this serie of patches I hope will be regstrapped for
> Friday.

Thanks; I'm impressed at how much progress you've made on this problem.

Dave



Re: [PATCH v2] analyzer: Call off a superseding when diagnostics are unrelated [PR110830]

2023-09-06 Thread David Malcolm via Gcc-patches
On Wed, 2023-09-06 at 21:16 +0200, priour...@gmail.com wrote:

[...snip...]

> Signed-off-by: benjamin priour 
> Co-authored-by: david malcolm 

Please also add:

  Signed-off-by: David Malcolm 

[...snip...]

> 
> +static bool
> +compatible_epath_p (const exploded_path *lhs_path,
> +   const exploded_path *rhs_path)
> +{
> +  gcc_assert (lhs_path);
> +  gcc_assert (rhs_path);
> +  gcc_assert (rhs_path->length () > 0);
> +  gcc_assert (rhs_path->length () > 0);
> +  int lhs_eedge_idx = lhs_path->length () -1;
> +  int rhs_eedge_idx = rhs_path->length () -1;

Minor formatting nit: there should be a space between the '-' and the
'1' in the above lines, hence:

  int lhs_eedge_idx = lhs_path->length () - 1;
  int rhs_eedge_idx = rhs_path->length () - 1;

[...snip...]

OK for trunk with those changes

Thanks
Dave



Re: [PATCH] fwprop: Allow UNARY_P and check register pressure.

2023-09-06 Thread Richard Sandiford via Gcc-patches
Robin Dapp  writes:
> Hi Richard,
>
> I did some testing with the attached v2 that does not restrict to UNARY
> anymore.  As feared ;) there is some more fallout that I'm detailing below.
>
> On Power there is one guality fail (pr43051-1.c) that I would take
> the liberty of ignoring for now.
>
> On x86 there are four fails:
>
>  - cond_op_addsubmuldiv__Float16-2.c: assembler error
>unsupported masking for `vmovsh'.  I guess that's a latent backend
>problem.
>
>  - ifcvt-3.c, pr49095.c: Here we propagate into a compare.  Before, we had
>(cmp (reg/CC) 0) and now we have (cmp (plus (reg1 reg2) 0).
>That looks like a costing problem and can hopefully solveable by making
>the second compare more expensive, preventing the propagation.
>i386 costing (or every costing?) is brittle so that could well break other
>things. 
>
>  - pr88873.c: This is interesting because even before this patch we
>propagated with different register classes (V2DF vs DI).  With the patch
>we check the register pressure, find the class NO_REGS for V2DF and
>abort (because the patch assumes NO_REGS = high pressure).  I'm thinking
>of keeping the old behavior for reg-reg propagations and only checking
>the pressure for more complex operations.
>
> aarch64 has the most fails:
>
>  - One guality fail (same as Power).
>  - shrn-combine-[123].c as before.
>
>  - A class of (hopefully, I only checked some) similar cases where we
>propagate an unspec_whilelo into an unspec_ptest.  Before we would only
>set a REG_EQUALS note.
>Before we managed to create a while_ultsivnx16bi_cc whereas now we have
>while_ultsivnx16bi and while_ultsivnx16bi_ptest that won't be combined.
>We create redundant whilelos and I'm not sure how to improve that. I
>guess a peephole is out of the question :)
>
>  - pred-combine-and.c: Here the new propagation appears useful at first.
>We propagate a "vector mask and" into a while_ultsivnx4bi_ptest and the
>individual and registers remain live up to the propagation site (while
>being dead before the patch).
>With the registers dead, combine could create a single fcmgt before.
>Now it only manages a 2->2 combination because we still need the registers
>and end up with two fcmgts.
>The code is worse but this seems more bad luck than anything.
>
>  - Addressing fails from before:  I looked into these and suspect all of
>them are a similar.
>What happens is that we have a poly_int offset that we shift, negate
>and then add to x0.  The result is used as load address.
>Before, we would pull (combine) the (plus x0 reg) into the load keeping
>the neg and shift.
>Now we propagate everything into a single (set (minus x0 offset)).
>The propagation itself seems worthwhile because we save one insn.
>However as we got rid of the base/offset split by lumping everything
>together, combine cannot pull the (plus) into the address load and
>we require an aarch64_split_add_offset.  This will emit the longer
>sequence of ashiftl and subtract.  The "base" address is x0 here so
>we cannot convert (minus x0 ...)) into neg.
>I didn't go through all of aarch64_split_add_offset.  I suppose we
>could re-add the separation of base/offset there but that might be
>a loss when the result is not used as an address. 
>
> Again, all in all no fatal problems but pretty annoying :)  It's not much
> but just gradually worse than with just UNARY.  Any idea on how/whether to
> continue?

Thanks for giving it a go.  Can you post the latest version of the
regpressure patch too?  The previous on-list version I could find
seems to be too old.

Thanks,
Richard

> Regards
>  Robin
>
> gcc/ChangeLog:
>
>   * fwprop.cc (fwprop_propagation::profitable_p): Add unary
>   handling.
>   (fwprop_propagation::update_register_pressure): New function.
>   (fwprop_propagation::register_pressure_high_p): New function
>   (reg_single_def_for_src_p): Look through unary expressions.
>   (try_fwprop_subst_pattern): Check register pressure.
>   (forward_propagate_into): Call new function.
>   (fwprop_init): Init register pressure.
>   (fwprop_done): Clean up register pressure.
>   (fwprop_insn): Add comment.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/riscv/rvv/autovec/binop/vadd-vx-fwprop.c: New test.
> ---
>  gcc/fwprop.cc | 359 +-
>  .../riscv/rvv/autovec/binop/vadd-vx-fwprop.c  |  64 
>  2 files changed, 419 insertions(+), 4 deletions(-)
>  create mode 100644 
> gcc/testsuite/gcc.target/riscv/rvv/autovec/binop/vadd-vx-fwprop.c
>
> diff --git a/gcc/fwprop.cc b/gcc/fwprop.cc
> index 0707a234726..ce6f5a74b00 100644
> --- a/gcc/fwprop.cc
> +++ b/gcc/fwprop.cc
> @@ -36,6 +36,10 @@ along with GCC; see the file COPYING3.  If not see
>  #include "tree-pass.h"
>  #include "rtl-iter.h"
>  #include "target.h"
> +#include "dominance.h"

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

2023-09-06 Thread Joseph Myers
On Sat, 26 Aug 2023, Martin Uecker via Gcc-patches wrote:

> -static int
> +static bool
>  comp_target_types (location_t location, tree ttl, tree ttr)

The comment above this function should be updated to refer to returning 
true, not to returning 1.  And other comments on common_pointer_type and 
inside that function should be updated to refer to comp_target_types 
returning true, not nonzero.

> @@ -1395,17 +1382,13 @@ free_all_tagged_tu_seen_up_to (const struct 
> tagged_tu_seen_cache *tu_til)
>  
>  /* Return 1 if two 'struct', 'union', or 'enum' types T1 and T2 are
> compatible.  If the two types are not the same (which has been
> -   checked earlier), this can only happen when multiple translation
> -   units are being compiled.  See C99 6.2.7 paragraph 1 for the exact
> -   rules.  ENUM_AND_INT_P and DIFFERENT_TYPES_P are as in
> -   comptypes_internal.  */
> +   checked earlier).  */
>  
> -static int
> +static bool
>  tagged_types_tu_compatible_p (const_tree t1, const_tree t2,
> -   bool *enum_and_int_p, bool *different_types_p)
> +   struct comptypes_data* data)

Similarly, this comment should be updated for the new return type.  Also 
the GNU style is "struct comptypes_data *data" with space before not after 
'*'.

> @@ -1631,9 +1603,9 @@ tagged_types_tu_compatible_p (const_tree t1, const_tree 
> t2,
> Otherwise, the argument types must match.
> ENUM_AND_INT_P and DIFFERENT_TYPES_P are as in comptypes_internal.  */
>  
> -static int
> +static bool
>  function_types_compatible_p (const_tree f1, const_tree f2,
> -  bool *enum_and_int_p, bool *different_types_p)
> +  struct comptypes_data *data)

Another comment to update for a changed return type.

>  /* Check two lists of types for compatibility, returning 0 for
> -   incompatible, 1 for compatible, or 2 for compatible with
> -   warning.  ENUM_AND_INT_P and DIFFERENT_TYPES_P are as in
> -   comptypes_internal.  */
> +   incompatible, 1 for compatible.  ENUM_AND_INT_P and
> +   DIFFERENT_TYPES_P are as in comptypes_internal.  */
>  
> -static int
> +static bool
>  type_lists_compatible_p (const_tree args1, const_tree args2,
> -  bool *enum_and_int_p, bool *different_types_p)
> +  struct comptypes_data *data)

This one also needs updating to remove references to parameters that no 
longer exist.

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


Re: [PATCH] c++: refine CWG 2369 satisfaction vs non-dep convs [PR99599]

2023-09-06 Thread Patrick Palka via Gcc-patches



On Mon, 28 Aug 2023, Jason Merrill wrote:

> On 8/24/23 09:31, Patrick Palka wrote:
> > On Wed, 23 Aug 2023, Jason Merrill wrote:
> > 
> > > On 8/21/23 21:51, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like
> > > > a reasonable approach?  I didn't observe any compile time/memory impact
> > > > of this change.
> > > > 
> > > > -- >8 --
> > > > 
> > > > As described in detail in the PR, CWG 2369 has the surprising
> > > > consequence of introducing constraint recursion in seemingly valid and
> > > > innocent code.
> > > > 
> > > > This patch attempts to fix this surpising behavior for the majority
> > > > of problematic use cases.  Rather than checking satisfaction before
> > > > _all_ non-dependent conversions, as specified by the CWG issue,
> > > > this patch makes us first check "safe" non-dependent conversions,
> > > > then satisfaction, then followed by "unsafe" non-dependent conversions.
> > > > In this case, a conversion is "safe" if computing it is guaranteed
> > > > to not induce template instantiation.  This patch heuristically
> > > > determines "safety" by checking for a constructor template or conversion
> > > > function template in the (class) parm or arg types respectively.
> > > > If neither type has such a member, then computing the conversion
> > > > should not induce instantiation (modulo satisfaction checking of
> > > > non-template constructor and conversion functions I suppose).
> > > > 
> > > > + /* We're checking only non-instantiating conversions.
> > > > +A conversion may instantiate only if it's to/from a
> > > > +class type that has a constructor template/conversion
> > > > +function template.  */
> > > > + tree parm_nonref = non_reference (parm);
> > > > + tree type_nonref = non_reference (type);
> > > > +
> > > > + if (CLASS_TYPE_P (parm_nonref))
> > > > +   {
> > > > + if (!COMPLETE_TYPE_P (parm_nonref)
> > > > + && CLASSTYPE_TEMPLATE_INSTANTIATION (parm_nonref))
> > > > +   return unify_success (explain_p);
> > > > +
> > > > + tree ctors = get_class_binding (parm_nonref,
> > > > + complete_ctor_identifier);
> > > > + for (tree ctor : lkp_range (ctors))
> > > > +   if (TREE_CODE (ctor) == TEMPLATE_DECL)
> > > > + return unify_success (explain_p);
> > > 
> > > Today we discussed maybe checking CLASSTYPE_NON_AGGREGATE?
> > 
> > Done; all dups of this PR seem to use tag types that are aggregates, so this
> > seems like a good simplification.  I also made us punt if the arg type has a
> > constrained non-template conversion function.
> > 
> > > 
> > > Also, instantiation can also happen when checking for conversion to a
> > > pointer
> > > or reference to base class.
> > 
> > Oops, I suppose we just need to strip pointer types upfront as well.  The
> > !COMPLETE_TYPE_P && CLASSTYPE_TEMPLATE_INSTANTIATION tests will then make
> > sure we deem a potential derived-to-base conversion unsafe if appropriate
> > IIUC.
> > 
> > How does the following look?
> > 
> > -- >8 --
> > 
> > Subject: [PATCH] c++: refine CWG 2369 satisfaction vs non-dep convs
> > [PR99599]
> > 
> > PR c++/99599
> > 
> > gcc/cp/ChangeLog:
> > 
> > * config-lang.in (gtfiles): Add search.cc.
> > * pt.cc (check_non_deducible_conversions): Add bool parameter
> > passed down to check_non_deducible_conversion.
> > (fn_type_unification): Call check_non_deducible_conversions
> > an extra time before satisfaction with noninst_only_p=true.
> > (check_non_deducible_conversion): Add bool parameter controlling
> > whether to compute only conversions that are guaranteed to
> > not induce template instantiation.
> > * search.cc (conversions_cache): Define.
> > (lookup_conversions): Use it to cache the lookup.  Improve cache
> > rate by considering TYPE_MAIN_VARIANT of the type.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/cpp2a/concepts-nondep4.C: New test.
> > ---
> >   gcc/cp/config-lang.in |  1 +
> >   gcc/cp/pt.cc  | 81 +--
> >   gcc/cp/search.cc  | 14 +++-
> >   gcc/testsuite/g++.dg/cpp2a/concepts-nondep4.C | 21 +
> >   4 files changed, 110 insertions(+), 7 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-nondep4.C
> > 
> > @@ -22921,6 +22933,65 @@ check_non_deducible_conversion (tree parm, tree
> > arg, unification_kind_t strict,
> >   {
> > bool ok = false;
> > tree conv_arg = TYPE_P (arg) ? NULL_TREE : arg;
> > +  if (conv_p && *conv_p)
> > +   {
> > + /* This conversion was already computed earlier (when
> > +computing only non-instantiating conversions).  */
> > + gcc_checking_assert (!noninst_only_p);
> > + return unify_success (ex

[PATCH] c++: cache conversion function lookup

2023-09-06 Thread Patrick Palka via Gcc-patches
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?  This cache apparently has a 98% hit rate for TYPE_HAS_CONVERSION
types on some test files.

-- >8 --

gcc/cp/ChangeLog:

* config-lang.in (gtfiles): Add search.cc.
* search.cc (lookup_conversions_cache): Define.
(lookup_conversions): Use it to cache he lookup.
Improve cache rate by considering TYPE_MAIN_VARIANT
of the type.
---
 gcc/cp/config-lang.in |  1 +
 gcc/cp/search.cc  | 11 +++
 2 files changed, 12 insertions(+)

diff --git a/gcc/cp/config-lang.in b/gcc/cp/config-lang.in
index a6c7883cc24..e34c392d208 100644
--- a/gcc/cp/config-lang.in
+++ b/gcc/cp/config-lang.in
@@ -52,6 +52,7 @@ gtfiles="\
 \$(srcdir)/cp/name-lookup.cc \
 \$(srcdir)/cp/parser.cc \$(srcdir)/cp/pt.cc \
 \$(srcdir)/cp/rtti.cc \
+\$(srcdir)/cp/search.cc \
 \$(srcdir)/cp/semantics.cc \
 \$(srcdir)/cp/tree.cc \$(srcdir)/cp/typeck2.cc \
 \$(srcdir)/cp/vtable-class-hierarchy.cc \
diff --git a/gcc/cp/search.cc b/gcc/cp/search.cc
index cd80f285ac9..d5a2c57f59c 100644
--- a/gcc/cp/search.cc
+++ b/gcc/cp/search.cc
@@ -2582,6 +2582,10 @@ lookup_conversions_r (tree binfo, int virtual_depth, int 
virtualness,
   return my_virtualness;
 }
 
+/* A cache of the result of lookup_conversions.  */
+
+static GTY((cache)) type_tree_cache_map *lookup_conversions_cache;
+
 /* Return a TREE_LIST containing all the non-hidden user-defined
conversion functions for TYPE (and its base-classes).  The
TREE_VALUE of each node is the FUNCTION_DECL of the conversion
@@ -2596,10 +2600,14 @@ lookup_conversions (tree type)
 {
   tree convs;
 
+  type = TYPE_MAIN_VARIANT (type);
   complete_type (type);
   if (!CLASS_TYPE_P (type) || !TYPE_BINFO (type))
 return NULL_TREE;
 
+  if (tree *c = hash_map_safe_get (lookup_conversions_cache, type))
+return *c;
+
   lookup_conversions_r (TYPE_BINFO (type), 0, 0, NULL_TREE, NULL_TREE, &convs);
 
   tree list = NULL_TREE;
@@ -2618,6 +2626,7 @@ lookup_conversions (tree type)
}
 }
 
+  hash_map_safe_put (lookup_conversions_cache, type, list);
   return list;
 }
 
@@ -2798,3 +2807,5 @@ any_dependent_bases_p (tree type)
 
   return false;
 }
+
+#include "gt-cp-search.h"
-- 
2.42.0.122.g1fc548b2d6



Re: [PATCH] c++: refine CWG 2369 satisfaction vs non-dep convs [PR99599]

2023-09-06 Thread Patrick Palka via Gcc-patches
On Mon, 28 Aug 2023, Jason Merrill wrote:

> On 8/24/23 09:31, Patrick Palka wrote:
> > On Wed, 23 Aug 2023, Jason Merrill wrote:
> > 
> > > On 8/21/23 21:51, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like
> > > > a reasonable approach?  I didn't observe any compile time/memory impact
> > > > of this change.
> > > > 
> > > > -- >8 --
> > > > 
> > > > As described in detail in the PR, CWG 2369 has the surprising
> > > > consequence of introducing constraint recursion in seemingly valid and
> > > > innocent code.
> > > > 
> > > > This patch attempts to fix this surpising behavior for the majority
> > > > of problematic use cases.  Rather than checking satisfaction before
> > > > _all_ non-dependent conversions, as specified by the CWG issue,
> > > > this patch makes us first check "safe" non-dependent conversions,
> > > > then satisfaction, then followed by "unsafe" non-dependent conversions.
> > > > In this case, a conversion is "safe" if computing it is guaranteed
> > > > to not induce template instantiation.  This patch heuristically
> > > > determines "safety" by checking for a constructor template or conversion
> > > > function template in the (class) parm or arg types respectively.
> > > > If neither type has such a member, then computing the conversion
> > > > should not induce instantiation (modulo satisfaction checking of
> > > > non-template constructor and conversion functions I suppose).
> > > > 
> > > > + /* We're checking only non-instantiating conversions.
> > > > +A conversion may instantiate only if it's to/from a
> > > > +class type that has a constructor template/conversion
> > > > +function template.  */
> > > > + tree parm_nonref = non_reference (parm);
> > > > + tree type_nonref = non_reference (type);
> > > > +
> > > > + if (CLASS_TYPE_P (parm_nonref))
> > > > +   {
> > > > + if (!COMPLETE_TYPE_P (parm_nonref)
> > > > + && CLASSTYPE_TEMPLATE_INSTANTIATION (parm_nonref))
> > > > +   return unify_success (explain_p);
> > > > +
> > > > + tree ctors = get_class_binding (parm_nonref,
> > > > + complete_ctor_identifier);
> > > > + for (tree ctor : lkp_range (ctors))
> > > > +   if (TREE_CODE (ctor) == TEMPLATE_DECL)
> > > > + return unify_success (explain_p);
> > > 
> > > Today we discussed maybe checking CLASSTYPE_NON_AGGREGATE?
> > 
> > Done; all dups of this PR seem to use tag types that are aggregates, so this
> > seems like a good simplification.  I also made us punt if the arg type has a
> > constrained non-template conversion function.
> > 
> > > 
> > > Also, instantiation can also happen when checking for conversion to a
> > > pointer
> > > or reference to base class.
> > 
> > Oops, I suppose we just need to strip pointer types upfront as well.  The
> > !COMPLETE_TYPE_P && CLASSTYPE_TEMPLATE_INSTANTIATION tests will then make
> > sure we deem a potential derived-to-base conversion unsafe if appropriate
> > IIUC.
> > 
> > How does the following look?
> > 
> > -- >8 --
> > 
> > Subject: [PATCH] c++: refine CWG 2369 satisfaction vs non-dep convs
> > [PR99599]
> > 
> > PR c++/99599
> > 
> > gcc/cp/ChangeLog:
> > 
> > * config-lang.in (gtfiles): Add search.cc.
> > * pt.cc (check_non_deducible_conversions): Add bool parameter
> > passed down to check_non_deducible_conversion.
> > (fn_type_unification): Call check_non_deducible_conversions
> > an extra time before satisfaction with noninst_only_p=true.
> > (check_non_deducible_conversion): Add bool parameter controlling
> > whether to compute only conversions that are guaranteed to
> > not induce template instantiation.
> > * search.cc (conversions_cache): Define.
> > (lookup_conversions): Use it to cache the lookup.  Improve cache
> > rate by considering TYPE_MAIN_VARIANT of the type.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/cpp2a/concepts-nondep4.C: New test.
> > ---
> >   gcc/cp/config-lang.in |  1 +
> >   gcc/cp/pt.cc  | 81 +--
> >   gcc/cp/search.cc  | 14 +++-
> >   gcc/testsuite/g++.dg/cpp2a/concepts-nondep4.C | 21 +
> >   4 files changed, 110 insertions(+), 7 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-nondep4.C
> > 
> > @@ -22921,6 +22933,65 @@ check_non_deducible_conversion (tree parm, tree
> > arg, unification_kind_t strict,
> >   {
> > bool ok = false;
> > tree conv_arg = TYPE_P (arg) ? NULL_TREE : arg;
> > +  if (conv_p && *conv_p)
> > +   {
> > + /* This conversion was already computed earlier (when
> > +computing only non-instantiating conversions).  */
> > + gcc_checking_assert (!noninst_only_p);
> > + return unify_success (expla

[committed] libstdc++: Disable support by default for freestanding

2023-09-06 Thread Jonathan Wakely via Gcc-patches
Tested x86_64-linux and x86_64-elf. Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Disable by default
for freestanding.
* configure: Regenerate.
---
 libstdc++-v3/acinclude.m4 | 2 +-
 libstdc++-v3/configure| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 50c808c6b2d..b7210e09d89 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -5481,7 +5481,7 @@ BACKTRACE_CPPFLAGS="$BACKTRACE_CPPFLAGS 
-DBACKTRACE_ELF_SIZE=$elfsize"
 
   AC_MSG_CHECKING([whether to build libbacktrace support])
   if test "$enable_libstdcxx_backtrace" = "auto"; then
-enable_libstdcxx_backtrace=yes
+enable_libstdcxx_backtrace="$is_hosted"
   fi
   AC_MSG_RESULT($enable_libstdcxx_backtrace)
   if test "$enable_libstdcxx_backtrace" = "yes"; then
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index db1932300c0..dcb9fd6158c 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -73156,7 +73156,7 @@ BACKTRACE_CPPFLAGS="$BACKTRACE_CPPFLAGS 
-DBACKTRACE_ELF_SIZE=$elfsize"
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether to build 
libbacktrace support" >&5
 $as_echo_n "checking whether to build libbacktrace support... " >&6; }
   if test "$enable_libstdcxx_backtrace" = "auto"; then
-enable_libstdcxx_backtrace=yes
+enable_libstdcxx_backtrace="$is_hosted"
   fi
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: 
$enable_libstdcxx_backtrace" >&5
 $as_echo "$enable_libstdcxx_backtrace" >&6; }
-- 
2.41.0



Re: [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes

2023-09-06 Thread Jonathan Wakely via Gcc-patches
On Mon, 4 Sept 2023 at 17:49, Jonathan Wakely  wrote:
>
> On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++
>  wrote:
> >
> > > Date: Fri, 1 Sep 2023 12:16:40 +0100
> > > Reply-To: Jonathan Wakely 
> > >
> > > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
> > >  wrote:
> > > >
> > > > Any objections to this? It's a C++23 feture, so should be enabled by
> > > > default.
> > >
> > > I've pushed this to trunk, so let's see what breaks!
> > >
> > >
> > > >
> > > > -- >8 --
> > > >
> > > > This causes libstdc++_libbacktrace.a to be built by default. This might
> > > > fail on some targets, in which case we can make the 'auto' choice expand
> > > > to either 'yes' or 'no' depending on the target.
> > > >
> > > > libstdc++-v3/ChangeLog:
> > > >
> > > > * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes.
> > > > * configure: Regenerate.
> >
> > Incidentally, should check_effective_target_stacktrace in
> > libstdc++.exp also be adjusted to match; removing the
> > _GLIBCXX_HOSTED condition?
>
> No, it should still depend on is_hosted. The acinclude.m4 macro should
> check that.

Done in r14-3761-g6de5f5a4fe85bd



godump.cc patch committed: Handle _BitInt

2023-09-06 Thread Ian Lance Taylor via Gcc-patches
This patch to godump.cc adds support for BITINT_TYPE.  Bootstrapped
and ran godump and Go tests on x86_64-pc-linux-gnu.  Committed to
mainline.

Ian

gcc/
PR go/111310
* godump.cc (go_format_type): Handle BITINT_TYPE.

gcc/testsuite/
PR go/111310
   * gcc.misc-tests/godump-1.c: Add _BitInt test cases.
diff --git a/gcc/godump.cc b/gcc/godump.cc
index 0893d5fbc97..bdd2d108d76 100644
--- a/gcc/godump.cc
+++ b/gcc/godump.cc
@@ -760,6 +760,25 @@ go_format_type (class godump_container *container, tree 
type,
   }
   break;
 
+case BITINT_TYPE:
+  {
+   const char *s;
+   char buf[100];
+
+   s = go_get_uinttype_for_precision (TYPE_PRECISION (type),
+  TYPE_UNSIGNED (type));
+   if (s == NULL)
+ {
+   snprintf (buf, sizeof buf, "INVALID-bitint-%u%s",
+ TYPE_PRECISION (type),
+ TYPE_UNSIGNED (type) ? "u" : "");
+   s = buf;
+   ret = false;
+ }
+   obstack_grow (ob, s, strlen(s));
+  }
+  break;
+
 case REAL_TYPE:
   {
const char *s;
diff --git a/gcc/testsuite/gcc.misc-tests/godump-1.c 
b/gcc/testsuite/gcc.misc-tests/godump-1.c
index 95dabdc0e4c..f359a657827 100644
--- a/gcc/testsuite/gcc.misc-tests/godump-1.c
+++ b/gcc/testsuite/gcc.misc-tests/godump-1.c
@@ -234,6 +234,17 @@ const char cc_v1;
 cc_t cc_v2;
 /* { dg-final { scan-file godump-1.out "(?n)^var _cc_v2 _cc_t$" } } */
 
+_BitInt(32) b32_v;
+/* { dg-final { scan-file godump-1.out "(?n)^var _b32_v int32$" } } */
+
+_BitInt(64) b64_v;
+/* { dg-final { scan-file godump-1.out "(?n)^var _b64_v int64$" } } */
+
+unsigned _BitInt(32) b32u_v;
+/* { dg-final { scan-file godump-1.out "(?n)^var _b32u_v uint32$" } } */
+
+_BitInt(33) b33_v;
+/* { dg-final { scan-file godump-1.out "(?n)^// var _b33_v INVALID-bitint-33$" 
} } */
 
 /*** pointer and array types ***/
 typedef void *vp_t;


Re: [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes

2023-09-06 Thread Hans-Peter Nilsson via Gcc-patches
> From: Jonathan Wakely 
> Date: Wed, 6 Sep 2023 23:30:08 +0100

> On Mon, 4 Sept 2023 at 17:49, Jonathan Wakely  wrote:
> >
> > On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++
> >  wrote:
> > >
> > > > Date: Fri, 1 Sep 2023 12:16:40 +0100
> > > > Reply-To: Jonathan Wakely 
> > > >
> > > > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
> > > >  wrote:
> > > > >
> > > > > Any objections to this? It's a C++23 feture, so should be enabled by
> > > > > default.
> > > >
> > > > I've pushed this to trunk, so let's see what breaks!
> > > >
> > > >
> > > > >
> > > > > -- >8 --
> > > > >
> > > > > This causes libstdc++_libbacktrace.a to be built by default. This 
> > > > > might
> > > > > fail on some targets, in which case we can make the 'auto' choice 
> > > > > expand
> > > > > to either 'yes' or 'no' depending on the target.
> > > > >
> > > > > libstdc++-v3/ChangeLog:
> > > > >
> > > > > * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes.
> > > > > * configure: Regenerate.
> > >
> > > Incidentally, should check_effective_target_stacktrace in
> > > libstdc++.exp also be adjusted to match; removing the
> > > _GLIBCXX_HOSTED condition?
> >
> > No, it should still depend on is_hosted. The acinclude.m4 macro should
> > check that.
> 
> Done in r14-3761-g6de5f5a4fe85bd

Aha, that's what you meant.  I thought you meant that just
check_effective_target_stacktrace should be gated on
$is_hosted.

Yeah, it makes sense not to have backtrace enabled by
default for ! $is_hosted.  On the other hand, bare-iron
targets like cris-elf apparently *are* hosted, according to
"#if __STDC_HOSTED__".  I guess I'll have to dig into what
the definition of "hosted" is, because I don't agree by the
layman obvious definition.  Maybe there's a bug to fix.
There sure are many yaks to shave these days.

brgds, H-P


Re: [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes

2023-09-06 Thread Jonathan Wakely via Gcc-patches
On Thu, 7 Sept 2023 at 00:09, Hans-Peter Nilsson  wrote:
>
> > From: Jonathan Wakely 
> > Date: Wed, 6 Sep 2023 23:30:08 +0100
>
> > On Mon, 4 Sept 2023 at 17:49, Jonathan Wakely  wrote:
> > >
> > > On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++
> > >  wrote:
> > > >
> > > > > Date: Fri, 1 Sep 2023 12:16:40 +0100
> > > > > Reply-To: Jonathan Wakely 
> > > > >
> > > > > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
> > > > >  wrote:
> > > > > >
> > > > > > Any objections to this? It's a C++23 feture, so should be enabled by
> > > > > > default.
> > > > >
> > > > > I've pushed this to trunk, so let's see what breaks!
> > > > >
> > > > >
> > > > > >
> > > > > > -- >8 --
> > > > > >
> > > > > > This causes libstdc++_libbacktrace.a to be built by default. This 
> > > > > > might
> > > > > > fail on some targets, in which case we can make the 'auto' choice 
> > > > > > expand
> > > > > > to either 'yes' or 'no' depending on the target.
> > > > > >
> > > > > > libstdc++-v3/ChangeLog:
> > > > > >
> > > > > > * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes.
> > > > > > * configure: Regenerate.
> > > >
> > > > Incidentally, should check_effective_target_stacktrace in
> > > > libstdc++.exp also be adjusted to match; removing the
> > > > _GLIBCXX_HOSTED condition?
> > >
> > > No, it should still depend on is_hosted. The acinclude.m4 macro should
> > > check that.
> >
> > Done in r14-3761-g6de5f5a4fe85bd
>
> Aha, that's what you meant.  I thought you meant that just
> check_effective_target_stacktrace should be gated on
> $is_hosted.
>
> Yeah, it makes sense not to have backtrace enabled by
> default for ! $is_hosted.  On the other hand, bare-iron
> targets like cris-elf apparently *are* hosted, according to
> "#if __STDC_HOSTED__".  I guess I'll have to dig into what
> the definition of "hosted" is, because I don't agree by the
> layman obvious definition.  Maybe there's a bug to fix.

I don't think there's a bug. $is_hosted is true for
--enable-hosted-libstdcxx which is on by default.


> There sure are many yaks to shave these days.
>
> brgds, H-P
>



Re: [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes

2023-09-06 Thread Jonathan Wakely via Gcc-patches
On Thu, 7 Sept 2023 at 00:10, Jonathan Wakely  wrote:
>
> On Thu, 7 Sept 2023 at 00:09, Hans-Peter Nilsson  wrote:
> >
> > > From: Jonathan Wakely 
> > > Date: Wed, 6 Sep 2023 23:30:08 +0100
> >
> > > On Mon, 4 Sept 2023 at 17:49, Jonathan Wakely  
> > > wrote:
> > > >
> > > > On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++
> > > >  wrote:
> > > > >
> > > > > > Date: Fri, 1 Sep 2023 12:16:40 +0100
> > > > > > Reply-To: Jonathan Wakely 
> > > > > >
> > > > > > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
> > > > > >  wrote:
> > > > > > >
> > > > > > > Any objections to this? It's a C++23 feture, so should be enabled 
> > > > > > > by
> > > > > > > default.
> > > > > >
> > > > > > I've pushed this to trunk, so let's see what breaks!
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > -- >8 --
> > > > > > >
> > > > > > > This causes libstdc++_libbacktrace.a to be built by default. This 
> > > > > > > might
> > > > > > > fail on some targets, in which case we can make the 'auto' choice 
> > > > > > > expand
> > > > > > > to either 'yes' or 'no' depending on the target.
> > > > > > >
> > > > > > > libstdc++-v3/ChangeLog:
> > > > > > >
> > > > > > > * acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Default to yes.
> > > > > > > * configure: Regenerate.
> > > > >
> > > > > Incidentally, should check_effective_target_stacktrace in
> > > > > libstdc++.exp also be adjusted to match; removing the
> > > > > _GLIBCXX_HOSTED condition?
> > > >
> > > > No, it should still depend on is_hosted. The acinclude.m4 macro should
> > > > check that.
> > >
> > > Done in r14-3761-g6de5f5a4fe85bd
> >
> > Aha, that's what you meant.  I thought you meant that just
> > check_effective_target_stacktrace should be gated on
> > $is_hosted.
> >
> > Yeah, it makes sense not to have backtrace enabled by
> > default for ! $is_hosted.  On the other hand, bare-iron
> > targets like cris-elf apparently *are* hosted, according to
> > "#if __STDC_HOSTED__".  I guess I'll have to dig into what
> > the definition of "hosted" is, because I don't agree by the
> > layman obvious definition.  Maybe there's a bug to fix.
>
> I don't think there's a bug. $is_hosted is true for
> --enable-hosted-libstdcxx which is on by default.

And IIRC __STDC_HOSTED__ is defined unless you compile with -ffreestanding.


>
> > There sure are many yaks to shave these days.
> >
> > brgds, H-P
> >



Re: [PATCH 3/5] RISC-V: Add Types to Un-Typed Zicond Instructions

2023-09-06 Thread Kito Cheng via Gcc-patches
LGTM

Edwin Lu  於 2023年9月7日 週四 01:53 寫道:

> This patch creates a new "zicond" type and updates all zicond instructions
> with that type.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.md: Add "zicond" type
> * config/riscv/zicond.md: Update types
>
> Signed-off-by: Edwin Lu 
> ---
>  gcc/config/riscv/riscv.md  | 5 +++--
>  gcc/config/riscv/zicond.md | 8 
>  2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> index 6684ad89cff..c329f55db43 100644
> --- a/gcc/config/riscv/riscv.md
> +++ b/gcc/config/riscv/riscv.md
> @@ -313,6 +313,7 @@ (define_attr "ext_enabled" "no,yes"
>  ;; cbocache block instructions
>  ;; crypto cryptography instructions
>  ;; csrcode size reduction instructions
> +;; zicondzicond instructions
>  ;; Classification of RVV instructions which will be added to each RVV .md
> pattern and used by scheduler.
>  ;; rdvlenb vector byte length vlenb csrr read
>  ;; rdvlvector length vl csrr read
> @@ -422,8 +423,8 @@ (define_attr "type"
> mtc,mfc,const,arith,logical,shift,slt,imul,idiv,move,fmove,fadd,fmul,
> fmadd,fdiv,fcmp,fcvt,fsqrt,multi,auipc,sfb_alu,nop,trap,ghost,bitmanip,
> rotate,clmul,min,max,minu,maxu,clz,ctz,cpop,
> -   atomic,condmove,cbo,crypto,csr,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl,
> -   vlde,vste,vldm,vstm,vlds,vsts,
> +   atomic,condmove,cbo,crypto,csr,zicond,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,
> +   vsetvl, vlde,vste,vldm,vstm,vlds,vsts,
> vldux,vldox,vstux,vstox,vldff,vldr,vstr,
>
> vlsegde,vssegte,vlsegds,vssegts,vlsegdux,vlsegdox,vssegtux,vssegtox,vlsegdff,
> vialu,viwalu,vext,vicalu,vshift,vnshift,vicmp,viminmax,
> diff --git a/gcc/config/riscv/zicond.md b/gcc/config/riscv/zicond.md
> index 1721e1011ea..0269bd14399 100644
> --- a/gcc/config/riscv/zicond.md
> +++ b/gcc/config/riscv/zicond.md
> @@ -30,7 +30,7 @@ (define_insn "*czero.."
>(const_int 0)))]
>"TARGET_ZICOND"
>"czero.\t%0,%2,%1"
> -)
> +[(set_attr "type" "zicond")])
>
>  (define_insn "*czero.."
>[(set (match_operand:GPR 0 "register_operand" "=r")
> @@ -40,7 +40,7 @@ (define_insn "*czero.."
>(match_operand:GPR 2 "register_operand"
>  "r")))]
>"TARGET_ZICOND"
>"czero.\t%0,%2,%1"
> -)
> +[(set_attr "type" "zicond")])
>
>  ;; Special optimization under eq/ne in primitive semantics
>  (define_insn "*czero.eqz..opt1"
> @@ -51,7 +51,7 @@ (define_insn "*czero.eqz..opt1"
>(match_operand:GPR 3 "register_operand" "r")))]
>"TARGET_ZICOND && rtx_equal_p (operands[1], operands[2])"
>"czero.eqz\t%0,%3,%1"
> -)
> +[(set_attr "type" "zicond")])
>
>  (define_insn "*czero.nez..opt2"
>[(set (match_operand:GPR 0 "register_operand"   "=r")
> @@ -61,7 +61,7 @@ (define_insn "*czero.nez..opt2"
>(match_operand:GPR 3 "register_operand" "1")))]
>"TARGET_ZICOND && rtx_equal_p (operands[1], operands[3])"
>"czero.eqz\t%0,%2,%1"
> -)
> +[(set_attr "type" "zicond")])
>
>  ;; Combine creates this form in some cases (particularly the coremark
>  ;; CRC loop.
> --
> 2.34.1
>
>


Re: [PATCH 4/5] RISC-V: Update Types for RISC-V Instructions

2023-09-06 Thread Kito Cheng via Gcc-patches
LGTM

Edwin Lu  於 2023年9月7日 週四 01:52 寫道:

> This patch adds types to riscv instructions that were added or were
> missed by the original patch
> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628996.html
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.md: Update types
>
> Signed-off-by: Edwin Lu 
> ---
>  gcc/config/riscv/riscv.md | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> index c329f55db43..c1cecd27815 100644
> --- a/gcc/config/riscv/riscv.md
> +++ b/gcc/config/riscv/riscv.md
> @@ -2223,6 +2223,7 @@ (define_insn "movsidf2_low_rv32"
>"TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA"
>"fmv.x.w\t%0,%1"
>[(set_attr "move_type" "fmove")
> +   (set_attr "type" "fmove")
> (set_attr "mode" "DF")])
>
>
> @@ -2235,6 +2236,7 @@ (define_insn "movsidf2_high_rv32"
>"TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA"
>"fmvh.x.d\t%0,%1"
>[(set_attr "move_type" "fmove")
> +   (set_attr "type" "fmove")
> (set_attr "mode" "DF")])
>
>  (define_insn "movdfsisi3_rv32"
> @@ -2247,6 +2249,7 @@ (define_insn "movdfsisi3_rv32"
>"TARGET_HARD_FLOAT && !TARGET_64BIT && TARGET_ZFA"
>"fmvp.d.x\t%0,%2,%1"
>[(set_attr "move_type" "fmove")
> +   (set_attr "type" "fmove")
> (set_attr "mode" "DF")])
>
>  (define_split
> --
> 2.34.1
>
>


Re: [PATCH 1/5] RISC-V: Update Types for Vector Instructions

2023-09-06 Thread Kito Cheng via Gcc-patches
LGTM

Edwin Lu  於 2023年9月7日 週四 01:51 寫道:

> This patch adds types to vector instructions that were added after or were
> missed by the original patch
> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628594.html
>
> gcc/ChangeLog:
>
> * config/riscv/autovec-opt.md: Update types
> * config/riscv/autovec.md: likewise
>
> Signed-off-by: Edwin Lu 
> ---
>  gcc/config/riscv/autovec-opt.md | 42 ++---
>  gcc/config/riscv/autovec.md | 28 +++---
>  2 files changed, 47 insertions(+), 23 deletions(-)
>
> diff --git a/gcc/config/riscv/autovec-opt.md
> b/gcc/config/riscv/autovec-opt.md
> index 1ca5ce97193..6cc1a01629c 100644
> --- a/gcc/config/riscv/autovec-opt.md
> +++ b/gcc/config/riscv/autovec-opt.md
> @@ -728,7 +728,8 @@ (define_insn_and_split "*cond_abs"
>  gen_int_mode (GET_MODE_NUNITS
> (mode), Pmode),
>  const0_rtx));
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine vlmax neg and UNSPEC_VCOPYSIGN
>  (define_insn_and_split "*copysign_neg"
> @@ -746,7 +747,8 @@ (define_insn_and_split "*copysign_neg"
>riscv_vector::emit_vlmax_insn (code_for_pred_ncopysign (mode),
>riscv_vector::BINARY_OP, operands);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine sign_extend/zero_extend(vf2) and vcond_mask
>  (define_insn_and_split "*cond_"
> @@ -765,7 +767,8 @@ (define_insn_and_split
> "*cond_"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine sign_extend/zero_extend(vf4) and vcond_mask
>  (define_insn_and_split "*cond_"
> @@ -784,7 +787,8 @@ (define_insn_and_split
> "*cond_"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine sign_extend/zero_extend(vf8) and vcond_mask
>  (define_insn_and_split "*cond_"
> @@ -803,7 +807,8 @@ (define_insn_and_split
> "*cond_"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine trunc(vf2) + vcond_mask
>  (define_insn_and_split "*cond_trunc"
> @@ -823,7 +828,8 @@ (define_insn_and_split
> "*cond_trunc"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine FP sign_extend/zero_extend(vf2) and vcond_mask
>  (define_insn_and_split "*cond_extend"
> @@ -842,7 +848,8 @@ (define_insn_and_split
> "*cond_extend"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine FP trunc(vf2) + vcond_mask
>  (define_insn_and_split "*cond_trunc"
> @@ -862,7 +869,8 @@ (define_insn_and_split
> "*cond_trunc"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine convert(FP->INT) + vcond_mask
>  (define_insn_and_split "*cond_"
> @@ -882,7 +890,8 @@ (define_insn_and_split "*cond_"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine convert(INT->FP) + vcond_mask
>  (define_insn_and_split "*cond_"
> @@ -902,7 +911,8 @@ (define_insn_and_split
> "*cond_"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine convert(FP->2xINT) + vcond_mask
>  (define_insn_and_split "*cond_"
> @@ -922,7 +932,8 @@ (define_insn_and_split "*cond_"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine convert(INT->2xFP) + vcond_mask
>  (define_insn_and_split "*cond_"
> @@ -942,7 +953,8 @@ (define_insn_and_split
> "*cond_"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine convert(2xFP->INT) + vcond_mask
>  (define_insn_and_split "*cond_"
> @@ -962,7 +974,8 @@ (define_insn_and_split "*cond_"
> gen_int_mode (GET_MODE_NUNITS (mode), Pmode)};
>riscv_vector::expand_cond_len_unop (icode, ops);
>DONE;
> -})
> +}
> +[(set_attr "type" "vector")])
>
>  ;; Combine convert(2xINT->FP) + vcond_mask
>  (define_insn_and_split "*cond_2"
> @@ -982,4 +995,5 @@ (define_insn_and_split

Re: [PATCH 2/5] RISC-V: Add Types for Un-Typed zc Instructions

2023-09-06 Thread Kito Cheng via Gcc-patches
csr is kind of confusing, I would suggest something like `pushpop` and
`mvpair`.

Edwin Lu  於 2023年9月7日 週四 01:51 寫道:

> This patch adds types to the untyped zc instructions. Creates a new
> type "csr" for these instructions for now.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.md: Add "csr" type
> * config/riscv/zc.md: Update types
>
> Signed-off-by: Edwin Lu 
> ---
>  gcc/config/riscv/riscv.md |   3 +-
>  gcc/config/riscv/zc.md| 102 +++---
>  2 files changed, 54 insertions(+), 51 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> index d80b6938f84..6684ad89cff 100644
> --- a/gcc/config/riscv/riscv.md
> +++ b/gcc/config/riscv/riscv.md
> @@ -312,6 +312,7 @@ (define_attr "ext_enabled" "no,yes"
>  ;; condmoveconditional moves
>  ;; cbocache block instructions
>  ;; crypto cryptography instructions
> +;; csrcode size reduction instructions
>  ;; Classification of RVV instructions which will be added to each RVV .md
> pattern and used by scheduler.
>  ;; rdvlenb vector byte length vlenb csrr read
>  ;; rdvlvector length vl csrr read
> @@ -421,7 +422,7 @@ (define_attr "type"
> mtc,mfc,const,arith,logical,shift,slt,imul,idiv,move,fmove,fadd,fmul,
> fmadd,fdiv,fcmp,fcvt,fsqrt,multi,auipc,sfb_alu,nop,trap,ghost,bitmanip,
> rotate,clmul,min,max,minu,maxu,clz,ctz,cpop,
> -   atomic,condmove,cbo,crypto,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl,
> +   atomic,condmove,cbo,crypto,csr,rdvlenb,rdvl,wrvxrm,wrfrm,rdfrm,vsetvl,
> vlde,vste,vldm,vstm,vlds,vsts,
> vldux,vldox,vstux,vstox,vldff,vldr,vstr,
>
> vlsegde,vssegte,vlsegds,vssegts,vlsegdux,vlsegdox,vssegtux,vssegtox,vlsegdff,
> diff --git a/gcc/config/riscv/zc.md b/gcc/config/riscv/zc.md
> index 77b28adde95..86f1afd66cb 100644
> --- a/gcc/config/riscv/zc.md
> +++ b/gcc/config/riscv/zc.md
> @@ -27,7 +27,7 @@ (define_insn "@gpr_multi_pop_up_to_ra_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s0_"
>[(set (reg:X SP_REGNUM)
> @@ -41,7 +41,7 @@ (define_insn "@gpr_multi_pop_up_to_s0_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s1_"
>[(set (reg:X SP_REGNUM)
> @@ -58,7 +58,7 @@ (define_insn "@gpr_multi_pop_up_to_s1_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s1}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s2_"
>[(set (reg:X SP_REGNUM)
> @@ -78,7 +78,7 @@ (define_insn "@gpr_multi_pop_up_to_s2_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s2}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s3_"
>[(set (reg:X SP_REGNUM)
> @@ -101,7 +101,7 @@ (define_insn "@gpr_multi_pop_up_to_s3_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s3}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s4_"
>[(set (reg:X SP_REGNUM)
> @@ -127,7 +127,7 @@ (define_insn "@gpr_multi_pop_up_to_s4_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s4}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s5_"
>[(set (reg:X SP_REGNUM)
> @@ -156,7 +156,7 @@ (define_insn "@gpr_multi_pop_up_to_s5_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s5}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s6_"
>[(set (reg:X SP_REGNUM)
> @@ -188,7 +188,7 @@ (define_insn "@gpr_multi_pop_up_to_s6_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s6}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s7_"
>[(set (reg:X SP_REGNUM)
> @@ -223,7 +223,7 @@ (define_insn "@gpr_multi_pop_up_to_s7_"
>(const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s7}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s8_"
>[(set (reg:X SP_REGNUM)
> @@ -261,7 +261,7 @@ (define_insn "@gpr_multi_pop_up_to_s8_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s8}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s9_"
>[(set (reg:X SP_REGNUM)
> @@ -302,7 +302,7 @@ (define_insn "@gpr_multi_pop_up_to_s9_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s9}, %0"
> -)
> +[(set_attr "type" "csr")])
>
>  (define_insn "@gpr_multi_pop_up_to_s11_"
>[(set (reg:X SP_REGNUM)
> @@ -349,7 +349,7 @@ (define_insn "@gpr_multi_pop_up_to_s11_"
> (const_int ]
>"TARGET_ZCMP"
>"cm.pop  {ra, s0-s11}, %0"
> -)
> +[(set_attr "type" 

  1   2   >