https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #438 from Oleg Endo ---
Could be relevant
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673346.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672694.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-Janua
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=60919
Oleg Endo changed:
What|Removed |Added
Target|arm |arm sh*-*-*
--- Comment #5 from Oleg Endo -
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=111814
--- Comment #7 from Oleg Endo ---
(In reply to Jiaxun Yang from comment #6)
> (In reply to Andrew Pinski from comment #4)
> > Note it might need to be under the check of -mieee too
>
> I'm preparing patch for this issue
Thanks!
> and IM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111814
Oleg Endo changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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=78804
Oleg Endo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113948
--- Comment #2 from Oleg Endo ---
-mlra option has been around on RX for a while. I've using GCC 8 as production
compiler on a larger firmware.
Adding -mlra to the build will make the thing get stuck during linking (using
LTO) somewhere, looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117908
Oleg Endo changed:
What|Removed |Added
Last reconfirmed||2024-12-04
Ever confirmed|0
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Support for RXv2 and RXv3 ISAs has been added to bintuilts long time ago but
the compiler still lacks any support.
A patch to add RXv2 to the compiler has been posted quite a while ago
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 #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=107704
--- Comment #10 from Oleg Endo ---
(In reply to Richard Sandiford from comment #9)
> I think the .md pattern either has to treat both appearances of the T
> register as operands or hard-code both of them.
Do you mean to make it a multi-set pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117591
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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 #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 #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 #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 #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 #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 #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=117182
--- Comment #6 from Oleg Endo ---
Thanks! I've added the patch to the stash
https://github.com/olegendo/gcc/tree/devel/sh-lra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117182
Oleg Endo changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117182
--- Comment #1 from Oleg Endo ---
Maybe related PR 115948 ??
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=117111
--- Comment #6 from Oleg Endo ---
(In reply to Jeffrey A. Law from comment #5)
> reorg splits insns because doing so gives more opportunities to fill delay
> slot, particularly when the asm-output step would generate multiple
> instructions for
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=113533
--- Comment #21 from Oleg Endo ---
The core issue should be fixed now, but I'd like to keep this one open, as
there were some things mentioned which I wanted to look into later (insn cost
target hook etc).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64036
Oleg Endo changed:
What|Removed |Added
Last reconfirmed||2024-10-14
Status|UNCONFIRMED
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=117111
--- Comment #4 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #3)
> Created attachment 59330 [details]
> a trial patch
>
> This patch disables the above splitter after machine reorg pass so to hide
> it from dbr_schedule. I thoug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117111
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70989
Oleg Endo changed:
What|Removed |Added
Last reconfirmed||2024-10-11
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116932
Oleg Endo changed:
What|Removed |Added
Last reconfirmed||2024-10-11
Status|UNCONFIRMED
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,
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Currently the compiler will convert std::sin, std::cos, 1/std::sqrt into fsca
and fsrra instruction when e.g. --fast-math is enabled.
However, there are cases where
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 #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 #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 #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 #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 #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 #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
Oleg Endo changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
While working on PR 55212, I've noticed that some of the atomic insns from the
pr64661 tests do not use GBR addressing, while some do use it.
__Z9test_36_1v:
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 #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 #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 #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=116894
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
The following simple C++ program:
-
#include
int main (void)
{
std::cout << test moon c++" << std::endl;
re
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 #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 #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 #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=116713
--- Comment #9 from Oleg Endo ---
(In reply to Andrew Pinski from comment #8)
> See
> https://gcc.gnu.org/legacy-ml/gcc-patches/2009-05/msg01233.html
> and
> https://gcc.gnu.org/legacy-ml/gcc-patches/2009-09/msg00130.html
Nice find!
Yeah, same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116713
--- Comment #6 from Oleg Endo ---
(In reply to pietro from comment #5)
> Created attachment 59210 [details]
> Add a blockage instruction before the prefetch
>
> I did a few tests on sh4-elf and adding a blockage before the prefetch keeps
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56592
--- Comment #5 from Oleg Endo ---
(In reply to Oleg Endo from comment #0)
> In order to
> minimize mode switches the function signature can be taken into account when
> deciding the default FPU precision for a particular function. E.g. when a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116713
--- Comment #4 from Oleg Endo ---
(In reply to pietro from comment #3)
> It looks like it's a more general GCC issue. The prefetch gets moved on both
> x86_64 and aarch64 on GCC, but not on clang: https://godbolt.org/z/Ycjr7Tq8b
>
> > It looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29845
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70989
Oleg Endo changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
|1
CC||olegendo at gcc dot gnu.org
Last reconfirmed||2024-09-26
--- Comment #1 from Oleg Endo ---
I've tried it on latest GCC-15 and can confirm the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69765
--- Comment #1 from Oleg Endo ---
Tried this case on GCC-15 branch
https://github.com/olegendo/gcc/tree/devel/sh-lra and it seems to be not a
problem anymore, regardless of LRA or no LRA usage. Should be added as a test
case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83464
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67732
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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=116709
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116849
Oleg Endo changed:
What|Removed |Added
Target||sh*-*-*
Status|UNCONFIRMED
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
The following example, when compiled as C (not as C++) on sh-elf with -O2
-m4-single
---
typedef _Complex float tuplef_t;
static inline tuplef_t
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 #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
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Currently the FPU mode-switching does not take into account inline-asm blocks.
As a result it's difficult to make sure that the FPU
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=115949
--- Comment #6 from Oleg Endo ---
I've tried this on the devel/sh-lra branch with
sh-elf-gcc -c -O3 -m4-single -mfsrra -mfsca -ffast-math
The issue still persists.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113193
--- Comment #2 from Oleg Endo ---
I've tried compiling this case with
sh-elf-gcc -m4-single -O3 -std=c++20 -c -mfsca -funsafe-math-optimizations
on devel/sh-lra branch -- the issue still persists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112116
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112115
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
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 #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 #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=55295
--- Comment #18 from Oleg Endo ---
A rather recent case and request to add a __builtin_fipr function, when trying
to optimize quaternion multiplication. This one includes hand-written inline
asm and register pre-allocation.
https://godbolt.org/
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 #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 #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=116713
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426
--- Comment #17 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #16)
> It does. However, I'm currently having unreleated problems with CMake which
> means I cannot build the whole project at the moment. I need to debug tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426
--- Comment #15 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #14)
> This particular bug is resolved when building with an LRA-enabled gcc-15.
>
> See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
That's great! I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #264 from Oleg Endo ---
(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
> match_scratch. Also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148
--- Comment #19 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #18)
> This particular bug is resolved when building with an LRA-enabled gcc-15.
>
> See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
Thanks for chec
1 - 100 of 1959 matches
Mail list logo
