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 #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 #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=117182
--- Comment #5 from Kazumoto Kojima ---
Created attachment 59367
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59367&action=edit
a trial patch
Add cannot_substitute_const_equiv_p target hook so to avoid unsafe substitution
for machines w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117182
--- Comment #4 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #3)
PR 115948 might complicate issues even more. Good thing it didn't happen at
the same time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117182
--- Comment #2 from Kazumoto Kojima ---
Created attachment 59366
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59366&action=edit
a reduced test case (-m4 -mlra -O2 -ftrace)
qemu-sh4-static failed with
Unhandled trap: 0x1a0
pc=0x004004f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117182
Bug ID: 117182
Summary: [SH] fldi0/1 generated in the wrong fp mode
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: ra, wrong-code
Severity: normal
Pr
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=117111
--- Comment #3 from Kazumoto Kojima ---
Created attachment 59330
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59330&action=edit
a trial patch
This patch disables the above splitter after machine reorg pass so to hide it
from dbr_schedul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117111
--- Comment #2 from Kazumoto Kojima ---
dbr_schedule is trying to fill the delay slot of
(jump_insn 17 16 42 (set (pc)
(if_then_else (eq (reg:SI 147 t)
(const_int 0 [0]))
(label_ref:SI 94)
(pc)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117111
Bug ID: 117111
Summary: [SH] delay slot is filled with wrong instruction
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: minor
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116932
--- Comment #2 from Kazumoto Kojima ---
Created attachment 59316
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59316&action=edit
an experimental patch
gcc/ChangeLog:
* config/sh/sync.md
(atomic_fetch__soft_tcb+1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116932
Kazumoto Kojima changed:
What|Removed |Added
CC||kkojima at gcc dot gnu.org
--- Commen
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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #269 from Kazumoto Kojima ---
(In reply to Kazumoto Kojima from comment #267)
> (In reply to Oleg Endo from comment #264)
> > Very nice! So it seems indeed, splitting up the "mega move patterns" into
> > simpler ones where predicates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #268 from Kazumoto Kojima ---
(In reply to Kazumoto Kojima from comment #265)
> Created attachment 59133 [details]
> a revised patch of 58883
>
> I noticed that I accidentally pushed unintended changes to the patch 58883
> and 59000.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #267 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #264)
> Very nice! So it seems indeed, splitting up the "mega move patterns" into
> simpler ones where predicates are more closer to the actual constraints give
> bett
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #266 from Kazumoto Kojima ---
Created attachment 59134
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59134&action=edit
a revised patch of 59000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #265 from Kazumoto Kojima ---
Created attachment 59133
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59133&action=edit
a revised patch of 58883
I noticed that I accidentally pushed unintended changes to the patch 58883 and
590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #263 from Kazumoto Kojima ---
Created attachment 59132
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59132&action=edit
a patch rewriting movsh_ie_ra
This patch splits movsf_ie_ra into several new patterns to remove
match_scrat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #262 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #261)
> I'm a little concerned because of PR 115949. It shows that there are some
> fundamental issues with move patterns like `movsi_ie`. It seems real-world
> code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #259 from Kazumoto Kojima ---
I totally agree with Oleg. We are still close to the starting point.
The experiment with 58895/59000 shows that there might be some issue with the
SH sfunc when LRA is enabled. It only paper over the rea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #251 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #249)
> Very nice. Can you please add it as a test case under
> gcc/testsuite/gcc.target/sh/torture on your github repo?
I've just add it as testsuite/gcc.target/sh/p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #248 from Kazumoto Kojima ---
Created attachment 59102
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59102&action=edit
a reduced C test case for the wrong code problem c#192
typedef struct { int c[64]; } obj;
extern void bar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #244 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #243)
> Is that with qemu-user or qemu-system? I tried multiple times and I always
> got a stack overflow with 59000. Trying without now.
qemu-user. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #242 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #241)
> (In reply to Kazumoto Kojima from comment #240)
> Did that include patch 59000?
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #240 from Kazumoto Kojima ---
My trial of the 3-stage bootstrap of gcc with enabling c,c++,lto,ada on qemu
has been done successfully with "-g -O2 -m4 -mlra" flags. I'm using the gcc
master commit 592a335de563a3a9e36d362c5b9f3fb0a990
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #233 from Kazumoto Kojima ---
Created attachment 59062
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59062&action=edit
a patch to fix other ICEs during libada build
The second one is the ICE in split2 pass during building liba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #232 from Kazumoto Kojima ---
Created attachment 59061
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59061&action=edit
a trial patch to fix ICE in c#229
I could get multiple ICEs with the cross libada build.
The first one look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #226 from Kazumoto Kojima ---
Created attachment 59044
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59044&action=edit
a patch to fix patch 59034
Looks the use of the raw R0 pattern in 59034 confuses the def-use analysis and
R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #224 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #223)
>
> I had run into some issues with my build environment, so my results are a
> little delayed. Apologies.
No problem.
After further testing, i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #221 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #220)
> Ah, OK, understandable. No problem. How about github instead?
I forked https://github.com/gcc-mirror/gcc and have just added the sh-lra
branch to https://gi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #219 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #217)
> (In reply to Kazumoto Kojima from comment #216)
> Kaz, can you please create a branch devel/sh-lra and add the patches there?
> I think it would make it easie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #216 from Kazumoto Kojima ---
Created attachment 59034
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59034&action=edit
a patch augments 58905
In the problematic case c#214, the subreg pass requires to recognize the insn
(insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #214 from Kazumoto Kojima ---
(In reply to Kazumoto Kojima from comment #213)
Sorry I missed the use of -jN in your build. Perhaps the failed go compilation
command would be
/srv/glaubitz/gcc/build/./gcc/gccgo -B/srv/glaubitz/gcc/b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #213 from Kazumoto Kojima ---
I have no experience debugging gcc go or ada compilers and don't know how to
make a handy testcase like .i files in c/c++ cases. It seems that the GNAT BUG
message in c#207 says about something about tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #210 from Kazumoto Kojima ---
It seems that go build fails in the subreg3 optimization and ada build fails in
the subreg1 optimization. Since the subreg1 optimization is done before
IRA/LRA, it could mean that there is another wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #203 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #201)
> Created attachment 59006 [details]
> Diff for bootstrap comparison failure of gcc/gimple-lower-bitint.c
I tried to build the stage3 gcc on qemu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #199 from Kazumoto Kojima ---
Created attachment 59000
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59000&action=edit
a patch for an experiment
I added explicit register clobbers after all s-function calls as an experiment,
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #194 from Kazumoto Kojima ---
Created attachment 58995
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58995&action=edit
simply a trial patch, not a real fix
With this explicit emit_clobber, all the segfaults I reported are gone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #193 from Kazumoto Kojima ---
(In reply to Kazumoto Kojima from comment #192)
Related parts of RTL dumps.
[.ira dump]
(insn 1747 1745 1748 125 (set (reg/f:SI 2854)
(plus:SI (reg/f:SI 153 sfp)
(const_int -136 [0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #192 from Kazumoto Kojima ---
Created attachment 58994
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58994&action=edit
a testcase for a wrong code issue which is preprocessed gcc/pointer-query.cc
I identified a wrong code with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #190 from Kazumoto Kojima ---
Another two segfaults are observed when building libstdc++v3.
Compiling Segfault in
libsupc++/dyncast.cctree-ssa-reassoc.cc
src/c++11/locale-inst.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #189 from Kazumoto Kojima ---
There is another segfault during compiling libgcc/fp-bit.c.
In that case, the 2nd visit to tree-ssa-sccvn.cc:3567 in vn_reference_lookup_3
FOR_EACH_VEC_ELT (rhs, j, vro)
vr->operands[i + 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #188 from Kazumoto Kojima ---
(In reply to Kazumoto Kojima from comment #187)
Looking at the RTL dumps in -mlra case, there is an instruction to set r4 in
the postreload dump:
(insn 579 573 580 49 (set (reg:SI 4 r4)
(reg/f:S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #187 from Kazumoto Kojima ---
Created attachment 58989
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58989&action=edit
a testcase for wrong code which is pre-processed gcc/gimple-fold.cc
One other segfault is seen when compili
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #185 from Kazumoto Kojima ---
Unfortunately, nothing new showed up in running gcc/g++ testsuite for
sh-elf+sim with -mlra.
OTOH, the segfault can be reproduced on qemu with the patched stage2 compiler
built with -g -O2 -mlra -m4. gd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #180 from Kazumoto Kojima ---
(In reply to Kazumoto Kojima from comment #174)
> > FAIL: gcc.c-torture/execute/struct-ret-1.c -O2 execution test
> > FAIL: gcc.c-torture/execute/struct-ret-1.c -O3 -g execution test
> > FAIL: gcc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #175 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #172)
> ../../../src/libgcc/libgcc2.c:538:1: internal compiler error: Illegal
> instruction
> root@tirpitz:..sh4-linux-gnu/libgcc>
>
> Could this be ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #174 from Kazumoto Kojima ---
(In reply to Kazumoto Kojima from comment #169)
> I'll try running gcc testsuite with the sh-elf cross compiler on old sh-sim.
> There may not be much chance, but it might catch the wrong code bug.
The r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #169 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #168)
> I am getting a segmentation fault when building libgcc2.c now:
>
> /<>/build/./gcc/xgcc -B/<>/build/./gcc/
> -B/usr/sh4-linux-gnu/bin/ -B/usr/s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #165 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #163)
> (In reply to Kazumoto Kojima from comment #130)
> > Created attachment 58831 [details]
> > a trial patch for c#129
> >
> > A quick fix may be:
> >
> > * confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #164 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #162)
> (In reply to Kazumoto Kojima from comment #153)
> > Created attachment 58886 [details]
> > a revised patch for c#135 and c#139
> >
> > (In reply to Oleg Endo f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #161 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #159)
It looks the issue described in c#148. Could you confirm that patch 58883 in
c#149 has been applied? The testcase in c#160 is compiled successf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #157 from Kazumoto Kojima ---
Created attachment 58905
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58905&action=edit
a revised patch for c#135, c#139 and c#154
1 - 100 of 116 matches
Mail list logo
