It is 627.cam4_s or 527.cam4_r? I can help to reproduce this from k1 board.
Pan -----Original Message----- From: Vineet Gupta <vine...@rivosinc.com> Sent: Friday, January 17, 2025 10:23 AM To: Li, Pan2 <pan2...@intel.com> Cc: Jeff Law <jeffreya...@gmail.com>; Palmer Dabbelt <pal...@rivosinc.com>; gnu-toolchain <gnu-toolch...@rivosinc.com>; Robin Dapp <rdapp....@gmail.com>; juzhe.zh...@rivai.ai; GCC Patches <gcc-patches@gcc.gnu.org> Subject: Re: gcc mode switching issue (was Re: RISC-V round_away () handling of non canonical rounding modes) On 1/16/25 18:02, Li, Pan2 wrote: > Hi Vineet, > > Is there any more information about the issue description here? Like steps > for reproducing, as well as expect behavior but actual result.. etc. > It is not easy to start the investigation with blow mail thread. Thanks a lot. At a high level SPEC2017 cam4 aborts at runtime with upstream gcc :-) Sorry this started as a potential glibc issue but as I dug it is turning out to be a gcc issue. I looped in gcc folks to get the glibc folks off the hook and solicit some brain waves from gcc folks :-) Understand your frustration that this doesn't help chase the problem down. I'm running reducer - will update in proper gcc channels. Thx, -Vineet > > Pan > > -----Original Message----- > From: Vineet Gupta <vine...@rivosinc.com> > Sent: Friday, January 17, 2025 9:28 AM > To: Andrew Waterman <and...@sifive.com> > Cc: Joseph Myers <josmy...@redhat.com>; GNU C Library > <libc-al...@sourceware.org>; Jeff Law <jeffreya...@gmail.com>; Palmer Dabbelt > <pal...@rivosinc.com>; gnu-toolchain <gnu-toolch...@rivosinc.com>; Robin Dapp > <rdapp....@gmail.com>; juzhe.zh...@rivai.ai; GCC Patches > <gcc-patches@gcc.gnu.org> > Subject: gcc mode switching issue (was Re: RISC-V round_away () handling of > non canonical rounding modes) > > On 1/16/25 15:07, Vineet Gupta wrote: >> +CC Juzhe, Robin, gcc patches mailing list >> >> On 1/16/25 14:49, Andrew Waterman wrote: >>> On Thu, Jan 16, 2025 at 11:43 AM Vineet Gupta <vine...@rivosinc.com> wrote: >>>> On 1/16/25 11:14, Joseph Myers wrote: >>>>> The simple thing to do is to change sysdeps/riscv/rvf/get-rounding-mode.h >>>>> so it only returns a supported value (so making code using >>>>> get_rounding_mode treat FE_TONEARESTFROMZERO the same as FE_TONEAREST, >>>>> effectively). That doesn't give you actual support for this rounding >>>>> mode, but should at least avoid aborts if it's set, in the absence of the >>>>> larger changes discussed above to implement full FE_TONEARESTFROMZERO >>>>> support. >>>> The simple approach feels simpler 😉 >>>> We can certainly fudge get_round_mode() to return FE_TONEARESTFROMZERO as >>>> FE_TONEAREST. >>>> But is that correct semantically as in the machine itself is in a different >>>> rounding mode than what glibc thinks it in and could compute values >>>> numerically >>>> differently than is expected. >>>> >>>> I wonder if gcc should even be generating insns with such rounding mode >>>> for the >>>> general (not explicit) cases. >>> I was wondering the same thing. On the scalar side, the FP ops have >>> the static rounding mode field, so there isn't a reason to change the >>> dynamic rounding mode if the compiler wants to use directed rounding >>> for a specific scalar instruction. The vector instructions mostly do >>> not have static rounding modes, so maybe this is the result of >>> autovectorization of e.g. a loop that invokes `lround`? >> Either autovec or just vec >> >> I notice the following pattern in generated code >> >> 90610: 00225073 fsrmi zero,4 >> 90614: 0d707057 vsetvli zero,zero,e32,mf2,ta,ma >> 90618: 4a1890d7 vfncvt.x.f.w v1,v1 >> >> I have a feeling it is generated by following >> >> (define_insn "@pred_narrow_fcvt_x<v_su>_f<mode>" >> [(set (match_operand:<VNCONVERT> 0 "register_operand" "=vd, vd, vr, >> vr, &vr, &vr") >> (if_then_else:<VNCONVERT> >> (unspec:<VM> >> [(match_operand:<VM> 1 "vector_mask_operand" " vm, >> vm,Wc1,Wc1,vmWc1,vmWc1") >> (match_operand 4 "vector_length_operand" " rK, rK, rK, rK, >> >> rK, rK") >> (match_operand 5 "const_int_operand" " i, i, i, i, >> >> i, i") >> (match_operand 6 "const_int_operand" " i, i, i, i, >> >> i, i") >> (match_operand 7 "const_int_operand" " i, i, i, i, >> >> i, i") >> (match_operand 8 "const_int_operand" " i, i, i, i, >> >> i, i") >> (reg:SI VL_REGNUM) >> (reg:SI VTYPE_REGNUM) >> (reg:SI FRM_REGNUM)] UNSPEC_VPREDICATE) >> (unspec:<VNCONVERT> >> [(match_operand:V_VLSF 3 "register_operand" " 0, 0, 0, 0, >> >> vr, vr")] VFCVTS) >> (match_operand:<VNCONVERT> 2 "vector_merge_operand" " vu, 0, vu, 0, >> >> vu, 0")))] >> "TARGET_VECTOR" >> "vfncvt.x<v_su>.f.w\t%0,%3%p1" >> [(set_attr "type" "vfncvtftoi") >> (set_attr "mode" "<VNCONVERT>") >> (set (attr "frm_mode") >> (symbol_ref "riscv_vector::get_frm_mode (operands[8])")) >> (set_attr "spec_restriction" "none,none,thv,thv,none,none")]) >> >> >> Although I'm not sure how exactly this generates the FSRM (assuming I'm >> looking >> at right thing) >> >> FWIW all the testsuite tests for narrowing conversion from float2int seem to >> be >> checking rtz variant. >> Will have to reduce Fortran - oh well ! > Nope it is not the vfncvt stuff, rather some issue in gcc RISC-V mode > switching. > We don't need any glibc changes. > > -Vineet
