https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #44 from JuzheZhong ---
(In reply to Patrick O'Neill from comment #43)
> (In reply to Patrick O'Neill from comment #42)
> > I kicked off a run roughly 10 hours ago with your memory-hog fix patch
> > applied to a1b2953924c451ce90a3fdc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #43 from Patrick O'Neill ---
(In reply to Patrick O'Neill from comment #42)
> I kicked off a run roughly 10 hours ago with your memory-hog fix patch
> applied to a1b2953924c451ce90a3fdce6841b63bf05f335f. I'll post the results
> here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #42 from Patrick O'Neill ---
(In reply to JuzheZhong from comment #41)
> Hi, Patrick.
>
> Could you trigger test again base on latest trunk GCC?
>
> We have recent memory-hog fix patch:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #41 from JuzheZhong ---
Hi, Patrick.
Could you trigger test again base on latest trunk GCC?
We have recent memory-hog fix patch:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3132d2d36b4705bb762e61b1c8ca4da7c78a8321
I want to make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #40 from Patrick O'Neill ---
(In reply to Patrick O'Neill from comment #39)
> FYI I ran spec2017 last night and got:
>
> zvl128b:
> no fails!
>
> zvl256b:
> 549.fotonik3d (runtime) - pr113570
GCC hash:
a1b2953924c451ce90a3fdce6841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #39 from Patrick O'Neill ---
FYI I ran spec2017 last night and got:
zvl128b:
no fails!
zvl256b:
549.fotonik3d (runtime) - pr113570
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #38 from Robin Dapp ---
deepsjeng also looks ok here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #37 from Robin Dapp ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206#c9
> Using 4a0a8dc1b88408222b88e10278017189f6144602, the spec run failed on:
> zvl128b (All runtime fails):
> 527.cam4 (Runtime)
> 531.deepsjeng (Runtime)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #36 from JuzheZhong ---
Hi, Patrick.
I just fixed a bug that will cause VSETVL PASS and AVL prop PASS bug.
Could you trigger a full run of SPEC with -O3 -ftrapping-math again ?
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #35 from JuzheZhong ---
(In reply to Vineet Gupta from comment #33)
> cam4 failure is a bug in vsetvl pass which I'm debugging atm.
> An erroneous vsetvl insn is getting generated, clobbering a live register
> used subsequently in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #34 from JuzheZhong ---
(In reply to Patrick O'Neill from comment #32)
> (In reply to JuzheZhong from comment #31)
> > You are using -Ofast which will have precision issue on floating-point.
> >
> > You can reference it:
> >
> > ht
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=113087
--- Comment #32 from Patrick O'Neill ---
(In reply to JuzheZhong from comment #31)
> You are using -Ofast which will have precision issue on floating-point.
>
> You can reference it:
>
> https://godbolt.org/z/zzG8xbx95
>
> O3 result: 50002896
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #31 from JuzheZhong ---
(In reply to Patrick O'Neill from comment #30)
> (In reply to Li Pan from comment #29)
> > Thanks a lot for the summary. Could you please help to share some more
> > information about the spec2017 for above da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #30 from Patrick O'Neill ---
(In reply to Li Pan from comment #29)
> Thanks a lot for the summary. Could you please help to share some more
> information about the spec2017 for above data? Like data set (test, train,
> or ref), the e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #29 from Li Pan ---
(In reply to Patrick O'Neill from comment #27)
> Linking the discussion/plan here since more interested people are CCd here.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206#c9
> Using 4a0a8dc1b88408222b88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #28 from JuzheZhong ---
(In reply to Patrick O'Neill from comment #27)
> Linking the discussion/plan here since more interested people are CCd here.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206#c9
> Using 4a0a8dc1b8840822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #27 from Patrick O'Neill ---
Linking the discussion/plan here since more interested people are CCd here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206#c9
Using 4a0a8dc1b88408222b88e10278017189f6144602, the spec run failed on:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #26 from JuzheZhong ---
CC Li Pan who may also reproduce the bugs for me.
Plz give us more details how to reproduce the bugs since we don't see any bugs
when build and run SPEC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #25 from jiawei ---
I had run SPEC2017-v1.1.9 with rv64gcv_zvl256b, it passed the compile and run
on base and validate cases, used qemu 8.1.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #24 from JuzheZhong ---
CC jiawei who run SPEC for me. Maybe you can help him to reproduce such issue
then I can debug it from his feedback.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #23 from JuzheZhong ---
(In reply to palmer from comment #22)
> (In reply to JuzheZhong from comment #19)
> > (In reply to Vineet Gupta from comment #18)
> > > (In reply to JuzheZhong from comment #17)
> > > > PLCT told me they passe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
palmer at gcc dot gnu.org changed:
What|Removed |Added
CC||palmer at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #21 from JuzheZhong ---
Btw, I saw there are 2 more FAILs:
FAIL: gcc.dg/vect/tsvc/vect-tsvc-s1115.c -flto -ffat-lto-objects execution test
FAIL: gcc.dg/vect/tsvc/vect-tsvc-s1115.c execution test
FAIL: gcc.dg/vect/tsvc/vect-tsvc-s114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #20 from JuzheZhong ---
I am not able to build and test SPEC since I don't have QEMU and SPEC
environment.
I should ask my colleague to do that but they are quite busy with company's
things and frankly I can't pull more resource on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #19 from JuzheZhong ---
(In reply to Vineet Gupta from comment #18)
> (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
>
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #17 from JuzheZhong ---
PLCT told me they passed with zvl256b.
I always run SPEC with FIXED-VLMAX since we always care about peak performance
on our board.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #16 from Vineet Gupta ---
(In reply to JuzheZhong from comment #15)
> Currently, we don't have much run FAIL and ICE left in full coverage testing.
>
> I suspect it is very corner case in SPEC.
>
> You don't have to debug it. Just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #15 from JuzheZhong ---
Currently, we don't have much run FAIL and ICE left in full coverage testing.
I suspect it is very corner case in SPEC.
You don't have to debug it. Just need to give me a preprocessed source file.
Like this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #14 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #13)
> (In reply to JuzheZhong from comment #12)
> > (In reply to Patrick O'Neill from comment #11)
> > > (In reply to Patrick O'Neill from comment #10)
> > > > I've ki
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=113087
--- Comment #12 from JuzheZhong ---
(In reply to Patrick O'Neill from comment #11)
> (In reply to Patrick O'Neill from comment #10)
> > I've kicked off 2 spec runs (zvl 128 and 256) using r14-6765-g4d9e0f3f211.
> > I'll let you know the results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #11 from Patrick O'Neill ---
(In reply to Patrick O'Neill from comment #10)
> I've kicked off 2 spec runs (zvl 128 and 256) using r14-6765-g4d9e0f3f211.
> I'll let you know the results when they finish.
My terminal crashed - so thes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
Patrick O'Neill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #9 from JuzheZhong ---
It's fixed on the trunk.
I wonder whether it can fix the issues that you (RIVOS) fail to run SPEC 527
and. 549
We have fixed several issues recently, could you use the latest trunk GCC to
run SPEC today ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #8 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:008b80e42eb7cb55c6a2ef55728241b8733dfd17
commit r14-6761-g008b80e42eb7cb55c6a2ef55728241b8733dfd17
Author: Juzhe-Zhong
Date: Wed Dec 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #7 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:d82bb518fa372cc30cc3352e0a124d0bd6deb36f
commit r14-6760-gd82bb518fa372cc30cc3352e0a124d0bd6deb36f
Author: Juzhe-Zhong
Date: Wed Dec 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #6 from Patrick O'Neill ---
(In reply to JuzheZhong from comment #5)
> ...
> I confirmed it is vsetvl bugs. But I wonder whether you have open source the
> random generator ?
>
> If yes, may be we can dedicate some resources to run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #5 from JuzheZhong ---
(In reply to Patrick O'Neill from comment #4)
> I can attempt to reduce them however running an iteration of 549 takes
> multiple hours so it might be challenging using my current setup (creduce).
> Hopefully t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #4 from Patrick O'Neill ---
I can attempt to reduce them however running an iteration of 549 takes multiple
hours so it might be challenging using my current setup (creduce).
Hopefully the random generator stumbles across the same is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #3 from JuzheZhong ---
(In reply to Patrick O'Neill from comment #2)
> No, this is from a random generator but the 527/549 issues could be related?
> I haven't reduced spec fails.
I can't reproduce spec fails. We have tested it on b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #2 from Patrick O'Neill ---
No, this is from a random generator but the 527/549 issues could be related?
I haven't reduced spec fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #1 from JuzheZhong ---
Is this coming from SPEC 527 or 549 ?
44 matches
Mail list logo
