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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #337 from Oleg Endo ---
(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 those Sid memory patterns so as to shorten the
> live range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #336 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #335)
> FWIW, the backend has improved quite a lot over the past weeks. The
> Dreamcast people reported good results as well!
As for the Dreamcast people, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #335 from John Paul Adrian Glaubitz ---
(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 those Sid memory patterns so as to shorten t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #334 from Kazumoto Kojima ---
Created attachment 59216
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59216&action=edit
a patch to fix ICE in c#331
The patch preallocates R0 for those Sid memory patterns so as to shorten the
li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #333 from Kazumoto Kojima ---
Created attachment 59215
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59215&action=edit
a reduced test case for c#331
Looks yet another R0 starvation issue similar to c#133 but this time for SFmo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #332 from John Paul Adrian Glaubitz ---
Created attachment 59212
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59212&action=edit
Preprocessed source from from comment #331
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #331 from John Paul Adrian Glaubitz ---
I found another failure when building webkit2gtk with the branch sh-lra-take3:
/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
-DGETTEXT_PACKAGE=\"WebKitGTK-4.1\"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #330 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #325)
>
> Our movsf logic for LRA doesn't handle these well. If these reg from/to
> subreg of SImode move is splitted with fpul, it will cause some very bad
> code or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #329 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #326)
> Created attachment 59190 [details]
> a quick fix for c#318
>
> This also reverts the change in c#312 and gives another fix for that issue.
> Tested only with t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #328 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #326)
> Created attachment 59190 [details]
> a quick fix for c#318
>
> This also reverts the change in c#312 and gives another fix for that issue.
> Te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #327 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #326)
> Created attachment 59190 [details]
> a quick fix for c#318
>
> This also reverts the change in c#312 and gives another fix for that issue.
> Te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #326 from Kazumoto Kojima ---
Created attachment 59190
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59190&action=edit
a quick fix for c#318
This also reverts the change in c#312 and gives another fix for that issue.
Tested on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #325 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #319)
> Created attachment 59188 [details]
> Preprocessed source from from comment #318
Thanks for the test case and other comments. I can reproduce t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #324 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #322)
> I've also created a branch with your patches here:
> https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/sh-lra
>
> I've retouched the commits a l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #323 from Oleg Endo ---
I've tried getting some code size numbers from CSiBE comparision for
'sh-elf-gcc -m4-single -O2' with the devel/sh-lra branch.
The numbers are code size in bytes with -mno-lra and -mlra
OpenTCP-1.0.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #322 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #316)
> (In reply to Oleg Endo from comment #314)
> > Can you please add the patch to your github branch?
> > I would like to ask some Dreamcast folks to try and test t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #321 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #320)
> Full command line is:
>
> /home/glaubitz/gcc-kaz/build/./gcc/xgcc
> -B/home/glaubitz/gcc-kaz/build/./gcc/
> -B/usr/local/sh4-unknown-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #320 from John Paul Adrian Glaubitz ---
Full command line is:
/home/glaubitz/gcc-kaz/build/./gcc/xgcc -B/home/glaubitz/gcc-kaz/build/./gcc/
-B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/lib/
-isystem /usr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #319 from John Paul Adrian Glaubitz ---
Created attachment 59188
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59188&action=edit
Preprocessed source from from comment #318
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #318 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #317)
> Thanks. I'm going to test this now. It seems that the untested patch from
> comment #312 didn't fix the Ada bootstrap for me.
The iss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #317 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #316)
> (In reply to Oleg Endo from comment #314)
> > Can you please add the patch to your github branch?
> > I would like to ask some Dreamcast folks t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #316 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #314)
> Can you please add the patch to your github branch?
> I would like to ask some Dreamcast folks to try and test the GCC LRA branch
> with some bigger real-world
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #315 from Oleg Endo ---
(In reply to Alexandre Oliva from comment #277)
> Created attachment 59153 [details]
> [lra] take scratch as implicit unused output reloads
>
> > * call_pcrel patterns: match_scratch can cause ICE for the corn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #314 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #312)
> (In reply to John Paul Adrian Glaubitz from comment #298)
> > Here is one ICE I have run into while building webkit2gtk with the latest
> > patches on top of an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #313 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #312)
> (In reply to John Paul Adrian Glaubitz from comment #298)
> > Here is one ICE I have run into while building webkit2gtk with the latest
> > patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #312 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #298)
> Here is one ICE I have run into while building webkit2gtk with the latest
> patches on top of an older GCC snapshot:
Although not tested well,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #311 from Kazumoto Kojima ---
Created attachment 59185
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59185&action=edit
a reduced test case for c#298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #310 from John Paul Adrian Glaubitz ---
Hmm, I just realized I performed the tests without enabling LRA by default. I
just noticed that because with LRA enabled, Ada actually fails with:
/<>/build/./gcc/xgcc -B/<>/build/./gcc/
-B/usr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #309 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #308)
> Thanks for confirming it. In this case, wouldn't it be better to explicitly
> mention the hard reg numbers everywhere, where they are involved? Otherwise
> th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #308 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #305)
> (In reply to Oleg Endo from comment #304)
> > I think this is a bit clearer, thanks! One more question
> >
> > (define_insn "block_lump_real"
> > [(se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #307 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #306)
> (In reply to John Paul Adrian Glaubitz from comment #301)
> > I can confirm that I can successfully perform a full native bootstrap wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #306 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #301)
> I can confirm that I can successfully perform a full native bootstrap with
> the following languages enabled:
>
> - c,c++,fortran,obj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #305 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #304)
> I think this is a bit clearer, thanks! One more question
>
> (define_insn "block_lump_real"
> [(set (mem:BLK (match_operand:SI 2 "sfunc_arg0_reg" "=r,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #304 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #302)
>
> Yes, that's what I suppose. If the operands of that pattern match with
> another registers, the instruction with the operands[2-4] other than r4-r6
> would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #303 from Kazumoto Kojima ---
Created attachment 59174
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59174&action=edit
a patch replacing 59159 for sfunc issue
No explicit clobber + sfunc_arg[012]_reg predicate version. Tested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #302 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #300)
> (In reply to Kazumoto Kojima from comment #297)
> >
> > > > && REG_P (operands[2]) && REGNO (operands[2]) == R4_REG
> > > > && REG_P (operands[3]) && REGNO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #301 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #292)
> (In reply to Kazumoto Kojima from comment #289)
> > I've reconstructed patches as follows:
> >
> > [59157] a revised patch to movsf i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #300 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #297)
>
> > > && REG_P (operands[2]) && REGNO (operands[2]) == R4_REG
> > > && REG_P (operands[3]) && REGNO (operands[3]) == R5_REG
> > > && REG_P (operands[4])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #299 from John Paul Adrian Glaubitz ---
Created attachment 59169
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59169&action=edit
Preprocessed source from from comment #298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #298 from John Paul Adrian Glaubitz ---
Here is one ICE I have run into while building webkit2gtk with the latest
patches on top of an older GCC snapshot:
/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #297 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #296)
> This sounds almost logical and easy to understand.
>
> > Adding explicit emit_clobber R4-R6 looks better than this to me, though.
>
> Having to use the "emit_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #296 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #295)
> (In reply to Kazumoto Kojima from comment #285)
> > (In reply to Oleg Endo from comment #284)
> > > (In reply to Kazumoto Kojima from comment #283)
> > ...
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #295 from Kazumoto Kojima ---
(In reply to Kazumoto Kojima from comment #285)
> (In reply to Oleg Endo from comment #284)
> > (In reply to Kazumoto Kojima from comment #283)
> ...
> > > It turned out that the c#276 version of block_lu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #294 from Kazumoto Kojima ---
(In reply to Andrew Pinski from comment #291)
> One of the explicit parallel issue was fixed with my commit
> g:da33ad53bcb57943fa671c745938a53f4de89a1b
> But there could be more hiding.
Thanks for your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #293 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #292)
> (In reply to Kazumoto Kojima from comment #289)
> > I've reconstructed patches as follows:
> >
> > [59157] a revised patch to movsf issue which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #292 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #289)
> I've reconstructed patches as follows:
>
> [59157] a revised patch to movsf issue which splits movesf_ie_ra
> [59158] a revised patch to QIHI e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #291 from Andrew Pinski ---
(In reply to Kazumoto Kojima from comment #285)
> (In reply to Oleg Endo from comment #284)
> > (In reply to Kazumoto Kojima from comment #283)
> ...
> > > It turned out that the c#276 version of block_lump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #290 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #263)
> Created attachment 59132 [details]
> a patch rewriting movsh_ie_ra
>
> This patch splits movsf_ie_ra into several new patterns to remove
> matc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #289 from Kazumoto Kojima ---
I've reconstructed patches as follows:
[59157] a revised patch to movsf issue which splits movesf_ie_ra
[59158] a revised patch to QIHI extend/move
[59159] a revised workaround sfunc issue
[59153] Alex's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #288 from Kazumoto Kojima ---
Created attachment 59159
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59159&action=edit
a revised workaround sfunc issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #287 from Kazumoto Kojima ---
Created attachment 59158
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59158&action=edit
a revised patch to QIHI extend/move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #286 from Kazumoto Kojima ---
Created attachment 59157
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59157&action=edit
a revised patch to movsf issue which splits movesf_ie_ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #285 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #284)
> (In reply to Kazumoto Kojima from comment #283)
...
> > It turned out that the c#276 version of block_lump_real_i4 works correctly
> > in only the limited cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #284 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #283)
> (In reply to Kazumoto Kojima from comment #276)
> > Current my assumption on the sfunc issue: LRA doesn't handle the clobber
> > hard reg pattern if that hard r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #283 from Kazumoto Kojima ---
(In reply to Kazumoto Kojima from comment #276)
> Current my assumption on the sfunc issue: LRA doesn't handle the clobber
> hard reg pattern if that hard reg is recognized as the input reg. I don't
> kn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #282 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #281)
> (In reply to John Paul Adrian Glaubitz from comment #280)
> > (In reply to Kazumoto Kojima from comment #279)
> > > (In reply to John Paul Adria
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #281 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #280)
> (In reply to Kazumoto Kojima from comment #279)
> > (In reply to John Paul Adrian Glaubitz from comment #275)
> > > Created attachment 59152 [de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #280 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #279)
> (In reply to John Paul Adrian Glaubitz from comment #275)
> > Created attachment 59152 [details]
> > Preprocessed source from from comment #273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #279 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #275)
> Created attachment 59152 [details]
> Preprocessed source from from comment #273
Thanks for test cases. Both .ii are compiled successfully with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #278 from Kazumoto Kojima ---
(In reply to Alexandre Oliva from comment #277)
> Created attachment 59153 [details]
> [lra] take scratch as implicit unused output reloads
>
> > * call_pcrel patterns: match_scratch can cause ICE for th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #277 from Alexandre Oliva ---
Created attachment 59153
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59153&action=edit
[lra] take scratch as implicit unused output reloads
> * call_pcrel patterns: match_scratch can cause ICE f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #276 from Kazumoto Kojima ---
It will take some time to sort out the known issues and there may be unknown
problems. Further testing with gcc-15 sounds like a good idea.
Here is a list of known issues and their status.
* call_pcrel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #275 from John Paul Adrian Glaubitz ---
Created attachment 59152
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59152&action=edit
Preprocessed source from from comment #273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #274 from John Paul Adrian Glaubitz ---
Created attachment 59151
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59151&action=edit
Preprocessed source from from comment #271
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #273 from John Paul Adrian Glaubitz ---
Ran into another one:
/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
-DGETTEXT_PACKAGE=\"WebKitGTK-4.1\" -DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED
-DPAS_BMALLOC=1
1 - 100 of 318 matches
Mail list logo
