https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120203
--- Comment #1 from Vineet Gupta ---
Fix posted here
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683159.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119164
--- Comment #4 from Vineet Gupta ---
Fix posted here
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683159.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120203
Bug ID: 120203
Summary: RISC-V: Frm restore missing after call insn
(float-point-dynamic-frm-74.c)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: wro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119533
Vineet Gupta changed:
What|Removed |Added
Status|NEW |ASSIGNED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119533
--- Comment #11 from Vineet Gupta ---
Debug log for the smaller test [1]
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680355.html
It hits the same ABNORMAL_EDGE assert.
- bb 17 has V insns, needing vsetvl - which LCM tries to "bubble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119533
--- Comment #10 from Vineet Gupta ---
Created attachment 61035
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61035&action=edit
simpler test
A slightly simpler test (thx Mark Ryan @ rivos) which also exhibits the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119533
--- Comment #9 from Vineet Gupta ---
(In reply to Andrew Pinski from comment #3)
> I suspect if you run the testsuite with -fnon-call-exceptions you might find
> a reduced C (or C++) testcae for the same issue.
No joy.
With the toggle forced,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119533
--- Comment #5 from Vineet Gupta ---
Proposed fix
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679657.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119533
--- Comment #4 from Vineet Gupta ---
Debug log:
`
Phase 4: Insert, modify and remove vsetvl insns.
### loop for missed vsetvl
Insert missed vsetvl info at edge(bb 31 -> bb 32): VALID (insn 663, bb 31)
Insert vsetvl insn 753:
Insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119533
Bug ID: 119533
Summary: RISC-V: libgo build failures (ICE) with Vector enabled
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118734
Vineet Gupta changed:
What|Removed |Added
CC||gkm at rivosinc dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119224
Vineet Gupta changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119224
--- Comment #6 from Vineet Gupta ---
(In reply to Robin Dapp from comment #2)
> I'm afraid that's due to scheduling (and not RA spilling). Of course there
> shouldn't be any vector stores in this loop and with -fno-schedule-insns
> there aren't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119224
--- Comment #5 from Vineet Gupta ---
(In reply to Robin Dapp from comment #4)
> Ah, sorry, I always specify -mno-vector-strict-align by default. It's
> always that option that allows us to unroll, otherwise unrolling will lead
> to misaligned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117722
--- Comment #20 from Vineet Gupta ---
It seems this was about abd/sad expander which was added to trunk in gcc-15
cycle. Can this be closed now ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119224
--- Comment #3 from Vineet Gupta ---
(In reply to Robin Dapp from comment #2)
> BTW I'm not seeing a loop with -mtune=rocket but also spills.
Weird. I see it on today's trunk too
cc1 -quiet -O3 -ffast-math -march=rv64gcv_zvl256b -mtune=rocket
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119224
--- Comment #1 from Vineet Gupta ---
b755c151fde4ad736405bb2e13a7de0420161179 is the first bad commit
commit b755c151fde4ad736405bb2e13a7de0420161179
Author: Vineet Gupta
Date: Tue Jan 7 14:28:25 2025 -0800
RISC-V: vector absolute differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119224
Bug ID: 119224
Summary: RISC-V: sad 16x16 spilling since
r15-6673-gb755c151fde4ad
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119164
--- Comment #3 from Vineet Gupta ---
However the first part of prev fix alone can't pass a glibc build - hitting
bunch of ICE.
Following reduced test (w/ my patch applied) actually segfaults
build: -O2 -c -march=rv64gcv_zvl256b_zba_zbb_zbs_zi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119164
--- Comment #2 from Vineet Gupta ---
I tried to address the first issue by changing the helper called to identify
call as end of insn (in the presence of the label) - I hope that is the right
direction.
Anyways per IRC chat, someone suggested f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119164
--- Comment #1 from Vineet Gupta ---
The RISC-V mode switching state machine tracks transitions into call insn and
out of call insn, going from MODE_DYN to MODE_CALL and back to MODE_DYN.
However when the call happens to be last insn of BB (not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119164
Bug ID: 119164
Summary: RISC-V: Extra FRM read/writes around call insns
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
--- Comment #7 from Vineet Gupta ---
I can confirm that it is happening due to following hunk from
r15-5943-gdc0dea98c96e02
bool
ssa_is_replaceable_p (gimple *stmt)
{
if (!is_gimple_assign (stmt))
#if 0
&& (!(call = dyn_cast (stmt))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
Vineet Gupta changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
--- Comment #10 from Vineet Gupta ---
(In reply to JuzheZhong from comment #9)
>
> I think we should consider many more different situation and consider it
> carefully. Like:
>
> vsetvli ... e8,mf8 ta ma (demand ratio)
> ...
> vservli zero zer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
--- Comment #4 from Vineet Gupta ---
Also slightly better test so avoid cpp/installed headers and use bare cc1
void func(const float *a, const float *b, float *c)
{
for (long i = 0; i < 1024; ++i) {
float a_l = __builtin_lround(a[i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
--- Comment #3 from Vineet Gupta ---
Bisected this to ...
dc0dea98c96e02c6b24060170bc88da8d4931bc2 is the first bad commit
commit dc0dea98c96e02c6b24060170bc88da8d4931bc2
Author: Richard Biener
Date: Wed Nov 27 13:36:19 2024 +0100
middl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
--- Comment #4 from Vineet Gupta ---
The following hack does prevent the fusion
+ inline bool tail_policy_eq2_p (const vsetvl_info &prev,
+const vsetvl_info &next)
+ {
+return (((prev.get_policy_demand () =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
--- Comment #3 from Vineet Gupta ---
(In reply to JuzheZhong from comment #2)
> I have thought about this long time ago while I am working on supporting RVV
> on upstream GCC.
>
> https://github.com/riscv-non-isa/riscv-toolchain-conventions/iss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
--- Comment #1 from Vineet Gupta ---
Looking at the VSETVL dumps:
Splitting with gen_split_2313 (vector.md:1777)
scanning new insn with uid = 70. # New VSETVL for vector load
deleting insn with uid = 16. # or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
Bug ID: 118945
Summary: RISC-V: VSETL pass: Don't promote Vectors ops from
Tail agnostic to Tail Undisturbed
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118687
--- Comment #5 from Vineet Gupta ---
(In reply to Andrew Pinski from comment #2)
> Basically what I am saying this should be filed in gas rather than in GCC.
Yeah understood but is this really the right thing to do - to re-implement all
the con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118687
Bug ID: 118687
Summary: RISC-V extensions for inline asm code (vs. llvm)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118103
--- Comment #15 from Vineet Gupta ---
(In reply to Li Pan from comment #12)
>
> Hi Vineet,
>
> Could you please help to double check if below can help to resolve the cam4
> issue? Thanks and feel free to let me know if any help is required.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118646
Vineet Gupta changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118103
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118646
--- Comment #4 from Vineet Gupta ---
I posted a potential fix for this
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674498.html
Confirmed that it also fixes PR/118103.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118646
--- Comment #2 from Vineet Gupta ---
Reproducer f90 test:
-Ofast -march=rv646cv_zcl256b_zba_zbb_zbs_zicond -ftree-vectorize
-mrvv-vector-bits=zvl
module a
contains
subroutine b(f)
real d(4)
integer e(4)
integer f(4)
real hmax(4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118646
Bug ID: 118646
Summary: RISC-V: Needed FSRM getting eliminated - SPEC2017
527.cam4 failures
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019
--- Comment #14 from Vineet Gupta ---
(In reply to Robin Dapp from comment #7)
> > The problem is GCC-15 has performance regression compare to GCC-14 on both
> > strict align and we should fix it, we can't specify use no strict align in
> > GCC-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117990
--- Comment #11 from Vineet Gupta ---
FWIW cam4 is still failing with similar symptoms. So perhaps it is something
else.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118019
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #8 from Vineet Gupta ---
(In reply to JuzheZhong from comment #7)
> I think Phase 3 early fusion should handle this scenario.
It is handling this, except that it fusing the 2nd into 1st which happens to be
before the BEQ, hence this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117990
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117722
--- Comment #16 from Vineet Gupta ---
(In reply to Robin Dapp from comment #15)
> (In reply to Vineet Gupta from comment #14)
> > @Robin, it seems the current codegen generates 2 widening ops, which might
> > not be as efficient. We have done s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #6 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #5)
> What's starting to rattle around in my brain is the for a loop, if the count
> is unknown, then we probably don't want to unroll as that's much more likely
> to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #4 from Vineet Gupta ---
(In reply to JuzheZhong from comment #2)
> We need to split all insns since some of them are not the ultimate RVV
> instruction pattern that depend on VL/VTYPE.
> And I don't think the vsetvli should be keep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117722
--- Comment #14 from Vineet Gupta ---
(In reply to Li Pan from comment #7)
> Created attachment 59661 [details]
> with usad pattern
Can you please post the patch, lest we duplicate your effort.
It would be nice to test it on real hardware.
@Ro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
--- Comment #1 from Vineet Gupta ---
So the way things seem to work here are in cprop_hardreg (just before vsetvl)
we have following:
(insn 44 18 47 4 (set (reg:DI 15 a5 [orig:139 _31 ] [139])
(unspec:DI [
(reg:DI 11 a1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117974
Bug ID: 117974
Summary: RISC-V: VSETVL hoisting across branch
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117733
--- Comment #3 from Vineet Gupta ---
"C" reproducer...
void bar(double);
void foo(double q[][5], int nx)
{
int i, l;
double dqnorm = 0.0;
for (i=0; i < nx; i++) {
for (l=0; l<5; l++) {
dqnorm = dqnorm + q[i][l]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #13 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #12)
> Two years hence and we are a little wiser.
>
> The root-cause of spills is sched1
> [PR/114729](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729).
With abov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117733
--- Comment #1 from Vineet Gupta ---
Tree vec pass is introducing the following MASK_LEN_LOAD and COND_LEN_ADD
constructs.
vect__31.15_91 = .MASK_LEN_LOAD (vectp_q.13_99, 64B, { -1, -1, -1, -1 },
_92(D), loop_len_97, 0);
vectp_q.13_90 = vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117733
Bug ID: 117733
Summary: RISC-V SPEC2017 503.bwaves Inefficient fortran
multi-dimensional array access
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
--- Comment #9 from Vineet Gupta ---
Or the other option is to prevent these patterns from kicking in during reload
by adjust the costs (there's a TODO there already)
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 3ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
--- Comment #8 from Vineet Gupta ---
We could potentially use a scratch in splitter.
(clobber (match_scratch:DI 3 "=&r"))]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
--- Comment #7 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #6)
> So my approach would be to note the insn number, then set a conditional
> breakpoint in make_insn_raw (after it initializes INSN_UID in the new
> insn). The co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
--- Comment #4 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #3)
> That doesn't make sense. The can_create_pseudo_p() check should have
> prevented this from matching once reload has started.
>
> Does the insn exist in the .i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
--- Comment #2 from Vineet Gupta ---
For other benign instances of the pattern lshrv8qi3, typically it goes through
a splitter in autovec.md which converts it into the canonical RVV form with all
the VL info.
(define_insn_and_split "3"
[(set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
Bug ID: 117353
Summary: RISC-V: ICE when building libcrypt
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
Vineet Gupta changed:
What|Removed |Added
CC||ewlu at rivosinc dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #21 from Vineet Gupta ---
The code is currently pushed to
https://github.com/vineetgarc/gcc/commits/topic-sched1/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #20 from Vineet Gupta ---
The model schedule change (at tweak9) seems stable and showing very promising
result.
The hottest basic block's reg pressure drops down significantly
;; Pressure summary (bb 206): GR_REGS:313 FP_REGS:946
;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #19 from Vineet Gupta ---
For last several weeks I've been working on various tweaks to address the model
schedule issue. It seems conceptually really simple, something along the lines
of following:
for (;;)
{
FOR_EACH_DE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #18 from Vineet Gupta ---
Next macro issue is in different sub-algorithm of scheduler.
module schedule is a simplistic algorithm run ahead of list schedular to get
max pressure which is subsequently used for bounding the list sched
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
Vineet Gupta changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #17 from Vineet Gup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #16 from Vineet Gupta ---
After ECC hack, the issue persists.
Toggles (for cc1plus): -O2 -march=rv64gc_zfa -mabi=lp64d
%sfp is the spill because
-fno-schedule-insns | -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #14 from Vineet Gupta ---
Interim update:
Per discussions [1] [2] with Richard Sandiford, some of the behavior is
fundamental to the "model" heuristics of -fsched-pressure, specially for
in-order cores which benefit from little more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #13 from Vineet Gupta ---
So after many months on and off on the issue, I think I understand what's going
on.
There are 3 insns involved in the issue which sched1 current generates in
following order:
insn 46(1) srliw a0,a5,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115687
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115450
--- Comment #4 from Vineet Gupta ---
-Ofast -flto=auto -march=rv64gcv_zvl256b_zba_zbb_zbs_zicond_zfa
-ftree-vectorize -mrvv-vector-bits=zvl
For RISC-V issue only happens in a LTO build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115450
Vineet Gupta changed:
What|Removed |Added
CC||jeffreyalaw at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #12 from Vineet Gupta ---
Interim update as I unpack sched1.
There's the "main" scheduling algorithm which involves 4 queues and an FSM but
can be ignored for this update.
There's "model" schedule which is the pressure sensitive su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 106265, which changed state.
Bug 106265 Summary: RISC-V SPEC2017 507.cactu code bloat due to address
generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
Vineet Gupta changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115264
Bug ID: 115264
Summary: RISC-V: yet another instance of poor codegen related
to stack (glibc tmpnam.c)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105733
Vineet Gupta changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111501
--- Comment #4 from Vineet Gupta ---
Awesome !
The trunk is open and new stuff, RISC-V certainly, is already landing, so no
harm in sending it now ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #10 from Vineet Gupta ---
Debug update -fsched-verbose=99 dumps (they are reay verbose)
For the insn/regs under consideration, the canonical pre-scheduled sequence
with ideal live-range (but non-ideal load-to-use delay) is f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
Vineet Gupta changed:
What|Removed |Added
Last reconfirmed|2024-04-15 00:00:00 |2024-4-16
--- Comment #9 from Vineet Gup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #4 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #3)
> Vineet, do we have this isolated enough that we know what function is most
> affected and presumably the most impacted blocks? If so we can probably
> start to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #2 from Vineet Gupta ---
FWIW -fsched-pressure is already default enabled for RISC-V.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
Bug ID: 114729
Summary: RISC-V SPEC2017 507.cactu excessive spillls with
-fschedule-insns
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
--- Comment #15 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #14)
> 2. implement gcc toggle -mrvv-vector-bits=zvl which essentially copies the
> xxx from -march string
Done:
commit 0a01d1232ff0a8b094270fbf45c9fd0ea46df19f
Autho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
Vineet Gupta changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113570
--- Comment #1 from Vineet Gupta ---
This one is a headache as we don't know where the problem is. And that it takes
~7hr for a QEMU run to finish.
Good this is there is a comparison point as VLA build works fine.
(1). bloat-o-meter (from Linu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113570
Bug ID: 113570
Summary: RISC-V: SPEC2017 549 fotonik3d miscompilation in
autovec VLS 256 build
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 113429, which changed state.
Bug 113429 Summary: RISC-V: SPEC2017 527 cam4 miscompilation in autovec VLA
build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
Vineet Gupta changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
--- Comment #8 from Vineet Gupta ---
Thx for the quick fix. I'll validate and commit !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
--- Comment #6 from Vineet Gupta ---
Created attachment 57111
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57111&action=edit
additional modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
--- Comment #3 from Vineet Gupta ---
The toggles used to build are
riscv64-unknown-linux-gnu-gfortran -c -o cam4red.o -I. -Iinclude
-Inetcdf/include -Ofast -fno-lto -static -march=rv64gcv_zba_zbb_zbs_zicond
-ftree-vectorize --param=riscv-autove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
--- Comment #2 from Vineet Gupta ---
Here's my analysis as to whats going on in vsetvl pass.
Reduced Test with annotated BBs.
.globl __a_MOD_f
.type __a_MOD_f, @function
__a_MOD_f:
...
ble s1,zero,.L49
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
--- Comment #1 from Vineet Gupta ---
Created attachment 57107
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57107&action=edit
Reduced cam4 test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113429
Bug ID: 113429
Summary: RISC-V: SPEC2017 527 cam4 miscompilation in autovec
VLA build
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
--- Comment #13 from Vineet Gupta ---
Yeah Greg from Rivos started working on it. He'll update here as he makes
progress.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112817
--- Comment #9 from Vineet Gupta ---
(In reply to JuzheZhong from comment #5)
> Support VLS codegen with -mrvv-vector-bits and attribute is reasonable to be
> landed on GCC-14.
>
> Could you first implement -mrvv-vector-bits feature ?
>
> I ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #18 from Vineet Gupta ---
(In reply to JuzheZhong from comment #17)
> PLCT told me they passed with zvl256b.
>
> I always run SPEC with FIXED-VLMAX since we always care about peak
> performance
> on our board.
Sure we all have our
1 - 100 of 158 matches
Mail list logo
