https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #437 from Oleg Endo ---
Could be relevant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118067
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673817.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #435 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #434)
> Any suggestion on how to proceed here? Oleg, do you maybe want to rebase
> your tree against master? I can re-run all tests and verify whether the
> p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #436 from Oleg Endo ---
Could be relevant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118017
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673130.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #434 from John Paul Adrian Glaubitz ---
Any suggestion on how to proceed here? Oleg, do you maybe want to rebase your
tree against master? I can re-run all tests and verify whether the patches
59432 and 59550 are still necessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
Oleg Endo changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
Oleg Endo changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #431 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #430)
>
> If you could merge 59432 and 59550 into your tree and rebase, I can test now
> that a fix for PR 117770 has landed.
I don't think there is anythin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #430 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #429)
> Could be related https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117770
You mean comment #419?
If you could merge 59432 and 59550 into your tree and re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #429 from Oleg Endo ---
Could be related https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117770
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #428 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #427)
> (In reply to John Paul Adrian Glaubitz from comment #426)
> > Oleg, could you merge the patches 59432 and 59550 into your tree, please?
>
> Yes, I wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #427 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #426)
> Oleg, could you merge the patches 59432 and 59550 into your tree, please?
Yes, I will do it when I have time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #426 from John Paul Adrian Glaubitz ---
Oleg, could you merge the patches 59432 and 59550 into your tree, please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #425 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #422)
> Created attachment 59550 [details]
> a trial patch for c#419
>
> Looks a similar issue with c#404 but for the constant float load. Tested
> de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #424 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #423)
>
> If I may ask one last question, could you give advise on this glibc bug that
> affects SH?
>
> > https://sourceware.org/bugzilla/show_bug.cgi?id=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #423 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #422)
> Created attachment 59550 [details]
> a trial patch for c#419
>
> Looks a similar issue with c#404 but for the constant float load. Tested
> de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #422 from Kazumoto Kojima ---
Created attachment 59550
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59550&action=edit
a trial patch for c#419
Looks a similar issue with c#404 but for the constant float load. Tested
devel/sh-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #421 from Kazumoto Kojima ---
Created attachment 59549
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59549&action=edit
a reduced test case for c#419
with "-m4 -mlra -O2 -std=c17 -fPIC -fno-math-errno -fno-signed-zeros
-fno-tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #420 from John Paul Adrian Glaubitz ---
Created attachment 59532
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59532&action=edit
Preprocessed source from from comment #419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #419 from John Paul Adrian Glaubitz ---
In the meantime, I found another regression when building ffmpeg:
gcc -I. -Isrc/ -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
-Wdate-time -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE -D_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #418 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #417)
> I haven't been able to find any regressions. Thus, my suggestion would be to
> clean the patches up now and get them merged if that's okay.
>
> This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #417 from John Paul Adrian Glaubitz ---
I haven't been able to find any regressions. Thus, my suggestion would be to
clean the patches up now and get them merged if that's okay.
This would expose the patches to a larger audience and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #416 from John Paul Adrian Glaubitz ---
Currently tracking testing the LRA-enabled backend here:
https://people.debian.org/~glaubitz/gcc-15-sh-lra.txt
Will regularly update the list once new results come in.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #415 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #414)
> I've merged this patch into commit "SH: Try to workaround fp-reg related
> move insns pt.2" and added the reduced test case from comment #413.
>
> It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #414 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #410)
> Created attachment 59432 [details]
> a trial patch for c#404
>
> It's difficult to see what is going on, because the test case is too huge.
> Looking at the p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #413 from Oleg Endo ---
Created attachment 59442
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59442&action=edit
Reduced test case for comment #405
(In reply to John Paul Adrian Glaubitz from comment #405)
> File too large to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #412 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #410)
> Created attachment 59432 [details]
> a trial patch for c#404
>
> It's difficult to see what is going on, because the test case is too huge.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #411 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #409)
> (In reply to Oleg Endo from comment #407)
> > (In reply to John Paul Adrian Glaubitz from comment #406)
> > > (In reply to John Paul Adrian Glaubitz f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #410 from Kazumoto Kojima ---
Created attachment 59432
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59432&action=edit
a trial patch for c#404
It's difficult to see what is going on, because the test case is too huge.
Looking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #409 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #407)
> (In reply to John Paul Adrian Glaubitz from comment #406)
> > (In reply to John Paul Adrian Glaubitz from comment #405)
> > > File too large to be att
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #408 from Oleg Endo ---
Maybe it would be good to override TARGET_DIFFERENT_ADDR_DISPLACEMENT_P on SH,
too?
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/666155.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #407 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #406)
> (In reply to John Paul Adrian Glaubitz from comment #405)
> > File too large to be attached, so uploading it here:
> >
> > https://people.debian.org/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #406 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #405)
> File too large to be attached, so uploading it here:
>
> https://people.debian.org/~glaubitz/pr-55212-404.tgz
Ping.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #405 from John Paul Adrian Glaubitz ---
File too large to be attached, so uploading it here:
https://people.debian.org/~glaubitz/pr-55212-404.tgz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #404 from John Paul Adrian Glaubitz ---
I have run into another ICE with WebKit when using Oleg's tree:
/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
-DBUILDING_WebCore -DGETTEXT_PACKAGE=\"WebKitGTK-4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #403 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #402)
> I've opened PR 117182 for a wrong fldi0/1 issue. Looks target + RA issue.
>
> FYI, with the patches in PR 116932, PR 117111 and PR 117182 on top of
> devel/sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #402 from Kazumoto Kojima ---
I've opened PR 117182 for a wrong fldi0/1 issue. Looks target + RA issue.
FYI, with the patches in PR 116932, PR 117111 and PR 117182 on top of
devel/sh-lra, c/c++ testsuite shows only one regression ag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #401 from Oleg Endo ---
It seems there is a silent wrong-code bug somewhere when building some
Dreamcast projects with LRA and LTO enabled. It results in wrong graphics
being output. So far could not isolate the wrong-code though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #400 from Oleg Endo ---
There was a latent issue that popped up as PR 113533 -- the cost estimation of
sh_rtx_costs for mem loads/stores were a bit distorted.
I've rebased the LRA devel branch
https://github.com/olegendo/gcc/tree/de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #399 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #398)
>
> Just to confirm: Oleg's tree currently bootstraps fine for me for all tested
> languages (didn't test D and Rust).
Thanks for checking.
>
> I ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #398 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #395)
> There was a recent commit in PR 116650, which looks related.
> I've updated (rebased) https://github.com/olegendo/gcc/tree/devel/sh-lra
Just to confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #397 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #379)
> sh-sim/-m2a/-mb:
> FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c execution, -O2
> FAIL: gcc.c-torture/execute/ieee/fp-cmp-5.c execution, -O2 -flto
> -fno-use-l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #396 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #392)
> Created attachment 59309 [details]
> a patch to fix pr55212-c384.C on devel/sh-lra
I can confirm that this patch fixes the bootstrap issue with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #395 from Oleg Endo ---
There was a recent commit in PR 116650, which looks related.
I've updated (rebased) https://github.com/olegendo/gcc/tree/devel/sh-lra
Maybe these commits can be somehow modified/reduced
"SH: Try to workaround
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #394 from Oleg Endo ---
The patch https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665033.html
for PR 116550 might be relevant here, too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #393 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #392)
> Created attachment 59309 [details]
> a patch to fix pr55212-c384.C on devel/sh-lra
Thanks so much for looking into it.
Yes, insn matching order is important,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #392 from Kazumoto Kojima ---
Created attachment 59309
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59309&action=edit
a patch to fix pr55212-c384.C on devel/sh-lra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #391 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #388)
> (In reply to Oleg Endo from comment #387)
> > > Currently, I'm using the sh-lra-take3 branch with the patches 59216, 59219
> > > and 59286 which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #390 from Kazumoto Kojima ---
(In reply to Richard Sandiford from comment #389)
> (In reply to Oleg Endo from comment #304)
> > (define_insn "block_lump_real"
> > [(set (mem:BLK (match_operand:SI 2 "sfunc_arg0_reg" "=r,r"))
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #389 from Richard Sandiford ---
(In reply to Oleg Endo from comment #304)
> (define_insn "block_lump_real"
> [(set (mem:BLK (match_operand:SI 2 "sfunc_arg0_reg" "=r,r"))
> (mem:BLK (match_operand:SI 3 "sfunc_arg1_reg" "=r,r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #388 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #387)
> > Currently, I'm using the sh-lra-take3 branch with the patches 59216, 59219
> > and 59286 which works best so far for all my tests, including WebKit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #387 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #386)
> (In reply to Kazumoto Kojima from comment #374)
> > Created attachment 59286 [details]
> > a patch for c#367
> >
> > We use movsf_ie as a fall-back f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #386 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #374)
> Created attachment 59286 [details]
> a patch for c#367
>
> We use movsf_ie as a fall-back for for moving fp-reg from/to multiword
> subreg in 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #385 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #383)
> (In reply to Oleg Endo from comment #382)
> > Instead of ...
> >
> > && REG_P (operands[1]) && REGNO (operands[1]) == R0_REG"
> >
> > ... could we also write
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #384 from Kazumoto Kojima ---
Created attachment 59289
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59289&action=edit
a reduced test case for c#378 (with -O2 -fpic)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #383 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #382)
> Instead of ...
>
> && REG_P (operands[1]) && REGNO (operands[1]) == R0_REG"
>
> ... could we also write it as...
>
> (define_predicate "hard_reg_r0"
> (an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #382 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #381)
> (In reply to John Paul Adrian Glaubitz from comment #378)
> > I just tried a full bootstrap using that tree with all languages but Rust
> > and Go enabled and i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #381 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #378)
> I just tried a full bootstrap using that tree with all languages but Rust
> and Go enabled and it fails with:
>
> during RTL pass: subreg3
> ..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #380 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #378)
> Will test Kaz's patch seprately applied to sh-lra-take3.
This bootstraps fine (tested without Go and Rust). So, it's an issue with
Ol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #379 from Oleg Endo ---
(In reply to Oleg Endo from comment #375)
>
> I've updated my branch https://github.com/olegendo/gcc/commits/devel/sh-lra/
>
> Testsuite results pending.
Comparing latest commit 90d5d797 (LRA enabled) vs. "S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #378 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #375)
> (In reply to Kazumoto Kojima from comment #374)
> > Created attachment 59286 [details]
> > a patch for c#367
> >
> > We use movsf_ie as a fall-back f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #377 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #376)
> Alternative #2 above is the same as alternative #13 of the "movsf_ie"
> pattern, isn't it?
> .. which is also the same as "movsf_ie_y" and that dangling 'define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #376 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #374)
> Created attachment 59286 [details]
> a patch for c#367
>
> We use movsf_ie as a fall-back for for moving fp-reg from/to multiword
> subreg in 59190. Looks thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #375 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #374)
> Created attachment 59286 [details]
> a patch for c#367
>
> We use movsf_ie as a fall-back for for moving fp-reg from/to multiword
> subreg in 59190. Looks thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #374 from Kazumoto Kojima ---
Created attachment 59286
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59286&action=edit
a patch for c#367
We use movsf_ie as a fall-back for for moving fp-reg from/to multiword subreg
in 59190.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #373 from Kazumoto Kojima ---
Created attachment 59285
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59285&action=edit
a reduced test case for c#367
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #372 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #370)
> I can also confirm that Kaz' sh-lra-take3 branch fixes the build of Python
> 3.13 which fails to build with the usual register starving problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #371 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #370)
> I can also confirm that Kaz' sh-lra-take3 branch fixes the build of Python
> 3.13 which fails to build with the usual register starving problem from
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #370 from John Paul Adrian Glaubitz ---
I can also confirm that Kaz' sh-lra-take3 branch fixes the build of Python 3.13
which fails to build with the usual register starving problem from PR81426:
> https://buildd.debian.org/status/fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #369 from Oleg Endo ---
(In reply to Oleg Endo from comment #346)
>
> ... I've noticed that this is the same as the existing
> MAYBE_BASE_REGISTER_RTX_P.
>
> I've inserted a patch into the stash to tighten all the existing memory
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #368 from John Paul Adrian Glaubitz ---
Created attachment 59264
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59264&action=edit
Preprocessed source from from comment #367
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #367 from John Paul Adrian Glaubitz ---
I just tried building a slightly older version of WebKit and ran into a new ICE
with Kaz' sh-lra-take3 branch:
/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
-DB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
Oleg Endo changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #365 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #364)
> Notice that it already has the hard-reg GBR assigned. Yet for some reason I
> don't understand, the following LRA pass then pulls that out and replaces
> GBR w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #364 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #345)
> (In reply to Oleg Endo from comment #341)
> > Do you have any idea how that might work? The only thing I can think of
> > right now is to remove R0 from list o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #363 from John Paul Adrian Glaubitz ---
I'm currently unable to continue with WebKit because GCC runs out of memory
trying to compile one of the larger source files. I am therefore going to pause
here.
Since there have been several b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #362 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #361)
> Do you know if there's any particular reason why sfunc on SH can't be done
> via regular call insn path? I can imagine it was originally done to
> optimize the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #361 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #360)
>
> I think that it's an issue for call insns not for normal insns. As reported
> in c#276, LRA handles call insns specially, and it seems to be an argument
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #360 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #354)
> Kaz, I just spotted one LRA related thing on the ML
>
> https://gcc.gnu.org/pipermail/gcc-regression/2024-August/080509.html
> https://github.com/gcc-mirror/gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #359 from Andrew Pinski ---
(In reply to John Paul Adrian Glaubitz from comment #358)
> (In reply to Andrew Pinski from comment #357)
> > (In reply to Andrew Pinski from comment #356)
> > > Can you file a seperate bug for this since I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #358 from John Paul Adrian Glaubitz ---
(In reply to Andrew Pinski from comment #357)
> (In reply to Andrew Pinski from comment #356)
> > Can you file a seperate bug for this since I think it is a generic IPA issue
> > ratehr than spe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #357 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #356)
> Can you file a seperate bug for this since I think it is a generic IPA issue
> ratehr than specific to sh?
I will file it seperately since I can reproduce it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #356 from Andrew Pinski ---
(In reply to John Paul Adrian Glaubitz from comment #355)
> (In reply to John Paul Adrian Glaubitz from comment #352)
> > I will try to figured out what optimization flag triggered the ICE. Also, I
> > will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #355 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #352)
> I will try to figured out what optimization flag triggered the ICE. Also, I
> will provide the preprocessed source in the next comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #354 from Oleg Endo ---
Kaz, I just spotted one LRA related thing on the ML
https://gcc.gnu.org/pipermail/gcc-regression/2024-August/080509.html
https://github.com/gcc-mirror/gcc/commit/3c67a0fa1dd39a3378deb854a7fef0ff7fe38004
Could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #353 from John Paul Adrian Glaubitz ---
Created attachment 59235
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59235&action=edit
Preprocessed source from from comment #352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #352 from John Paul Adrian Glaubitz ---
Since I'm unable to build WebKit with -O2 due to memory constraints, I'm
building with -O1 now. This unfortunately triggered another ICE which does not
show with -O2:
/usr/bin/g++-15 -DBUILDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #351 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #344)
> Created attachment 59219 [details]
> a patch for c#339
>
> This adds checks if the address register of the memory displacement is
> general or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #350 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #348)
> (In reply to Oleg Endo from comment #346)
> >
> > Anyway, it seems after tightening the memory predicates and constraints,
> > some of the previously added thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #349 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #345)
> (In reply to Oleg Endo from comment #341)
> > Do you have any idea how that might work? The only thing I can think of
> > right now is to remove R0 from list o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #348 from Oleg Endo ---
(In reply to Oleg Endo from comment #346)
>
> Anyway, it seems after tightening the memory predicates and constraints,
> some of the previously added things become redundant. See follow up patch
>
> https://
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #347 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #346)
> Right ... all the memory constraints have not been checking for the actual
> registers. Perhaps with LRA the address modifications are going through a
> differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #346 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #343)
>
> Yes. The wrong instruction
>
> mov.b @(5,fpul),r0! 517 [c=2 l=2] *movqi/8
>
> is generated with *movqi insn which is defined by
>
> (define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #345 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #341)
> Do you have any idea how that might work? The only thing I can think of
> right now is to remove R0 from list of allocatable registers and add an RTL
> pass be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #344 from Kazumoto Kojima ---
Created attachment 59219
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59219&action=edit
a patch for c#339
This adds checks if the address register of the memory displacement is general
or pseudo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #343 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #342)
> (In reply to John Paul Adrian Glaubitz from comment #339)
> > /home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3/
> > JavaScriptCore/DerivedSou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #342 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #339)
> /home/glaubitz/webkit2gtk-sh4-new-new/webkit2gtk-2.46.0/build-soup3/
> JavaScriptCore/DerivedSources/unified-sources/UnifiedSource-f2e18ffc-36.cpp
> (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #341 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #338)
> (In reply to Oleg Endo from comment #337)
> > (In reply to Kazumoto Kojima from comment #334)
> > > Created attachment 59216 [details]
> > > a patch to fix ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #340 from John Paul Adrian Glaubitz ---
The compressed preprocessed source is larger than usual and the complete
archive exceeds the maximum file limit for Bugzilla, so I have uploaded the
preprocessed source for comment #339 here:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #339 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #335)
> (In reply to Kazumoto Kojima from comment #334)
> > Created attachment 59216 [details]
> > a patch to fix ICE in c#331
> >
> > The pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #338 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #337)
> (In reply to Kazumoto Kojima from comment #334)
> > Created attachment 59216 [details]
> > a patch to fix ICE in c#331
> >
> > The patch preallocates R0 for th
1 - 100 of 383 matches
Mail list logo
