https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533
--- Comment #17 from Oleg Endo ---
(In reply to Jeffrey A. Law from comment #16)
> Note that Jakub recently twiddled fwprop to throttle it back a little. As a
> result the regressions seen in this BZ are no longer an issue. I'm going to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111001
Oleg Endo changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
||olegendo at gcc dot gnu.org
Status|NEW |RESOLVED
--- Comment #9 from Oleg Endo ---
Thanks everyone for staying on this and re-testing. It should be fixed now on
the open branches. If you want to use a version older than GCC 11, please
apply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111898
Oleg Endo changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533
--- Comment #15 from Oleg Endo ---
(In reply to Roger Sayle from comment #14)
> My apologies for not keeping folks updated on my thinking. Following Oleg's
> feedback, I've decided to slim down my proposed fix to the bare minimum, and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533
--- Comment #13 from Oleg Endo ---
(In reply to Roger Sayle from comment #12)
> It should be mentioned that the fwprop fix for PR11267 also resolved several
> FAILs in gcc.target/sh/pr59533.c. I mention this as tweaking the cost of
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533
--- Comment #11 from Oleg Endo ---
(In reply to Roger Sayle from comment #10)
> I've found an interesting table of SH cycle counts (for different CPUs) at
> http://www.shared-ptr.com/sh_insns.html
Yeah, I know. I did that ;)
> In my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533
--- Comment #9 from Oleg Endo ---
(In reply to Roger Sayle from comment #8)
> Created attachment 57190 [details]
> proposed patch
>
> Proposed patch to provide a sane/saner set of rtx_costs for SH. There's
> plenty more that could be done,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533
--- Comment #7 from Oleg Endo ---
(In reply to Roger Sayle from comment #6)
> To help diagnose the problem, I came up with this simple patch:
Thanks for looking into it!
> which then helps reveal that on sh3-linux-gnu with -O1 we see:
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533
--- Comment #5 from Oleg Endo ---
(In reply to Andrew Pinski from comment #3)
> That seems to make the cost of a load/store if just an index, the same as the
> cost
> as the index. Which definitely seems wrong. It should be the cost of the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533
--- Comment #2 from Oleg Endo ---
(In reply to Andrew Pinski from comment #1)
> This is most likely a cost model issue on sh3.
You mean this one (sh.cc, sh_rtx_costs)?
/* The cost of a mem access is mainly the cost of the address mode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113193
Oleg Endo changed:
What|Removed |Added
Known to fail||13.2.1
Version|14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #37
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111001
--- Comment #17 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #16)
> Just saw the branch updates, thanks! FWIW, I did observe this issue in
> gcc-13 only but not gcc-11 or gcc-12. But that might be owed to the fact
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111001
--- Comment #15 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #10)
>
> Do we need anything else before the fix can be merged?
No, should be fine. I'll leave this PR open for a while in case anything else
related pops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111001
--- Comment #9 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #8)
>
> I built gcc-13 natively with the patch applied with a full bootstrap
> including stage2 and stage3. Full build log available in [1].
>
> > [1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111001
--- Comment #7 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #5)
>
> I can confirm that this patch fixes the build of e2fsprogs with gcc-13 for
> me.
Great, thanks! Do you have an option to run a compiler bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65250
--- Comment #2 from Oleg Endo ---
Briefly checked this one on GCC-13. It generates the optimal sequence.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111892
--- Comment #5 from Oleg Endo ---
Adrian, can you please give it another go with the patch I've posted in PR
111001 ?
https://gcc.gnu.org/bugzilla/attachment.cgi?id=56164
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111001
--- Comment #4 from Oleg Endo ---
Created attachment 56164
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56164=edit
sh_pr11001_fix.patch
Can you please try this patch? It should solve the problem, but not sure if
there could be any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51708
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111892
Oleg Endo changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Oleg Endo ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101177
--- Comment #13 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #12)
>
> That was super-fast! Thanks a lot!
Not really. ~2 years from patch to commit. Sorry about that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101177
Oleg Endo changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426
--- Comment #12 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #11)
> Created attachment 56123 [details]
> Preprocessed source from building GHC with gcc-13
>
> This is still present in gcc-13, I just ran into it while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #105 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #104)
> I've been thinking about something. I suspect that this patch could take
> work away from other patches. I'm sorry, I don't know how to express myself
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111001
--- Comment #3 from Oleg Endo ---
(In reply to Oleg Endo from comment #2)
> I've briefly tried on a local gcc version 13.1.1 20230714
>
> While it doesn't crash, the sh_treg_combine2 pass seems to be stuck in an
> infinite loop. It produces
|1
CC||olegendo at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #2 from Oleg Endo ---
I've briefly tried on a local gcc version 13.1.1 20230714
While it doesn't crash, the sh_treg_combine2 pass seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #103 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #102)
> Created attachment 55543 [details]
> Arithmetic right shift late expanding v2
>
> Here's the patch. I hope I did not miss anything.
>
Sorry, I've been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107704
--- Comment #5 from Oleg Endo ---
(In reply to Jeffrey A. Law from comment #2)
> ACK. And as I mentioned, the RTL form looks like it ought to be caught by
> the SH specific code to optimize T reg handling. I don't care enough about
> the SH
||olegendo at gcc dot gnu.org
--- Comment #2 from Oleg Endo ---
I think this would be a problem on all targets where DF is forced to be SF,
which I think is not a good thing at all. It's also causing problems with
Fortan.
I'm not sure if it makes sense to add support for DF == SF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469
--- Comment #17 from Oleg Endo ---
(In reply to Rin Okuyama from comment #16)
> The fix has been cherry-picked for NetBSD:
> https://mail-index.netbsd.org/source-changes/2023/07/18/msg146078.html
>
> Let me thank you again, Oleg!
Sure, you're
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469
Oleg Endo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #101 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #100)
> Created attachment 55513 [details]
> Arithmetic right shift late expanding
>
> (In reply to Oleg Endo from comment #99)
> > Meanwhile, here's my iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469
--- Comment #9 from Oleg Endo ---
(In reply to Rin Okuyama from comment #8)
> (In reply to Oleg Endo from comment #7)
>
> Hi Oleg. Thank you very much for your great work!
>
> I've tested your patch with GCC 10.4.0 in this weekend, and it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
Oleg Endo changed:
What|Removed |Added
Attachment #28207|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #97 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #96)
>
> Not really. 'expand_ashiftrt' could emit
>
> mov #imm, r1
> shad r1, r0
>
> and 'mov' instruction would be loop invariant if there's a loop. It looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469
--- Comment #7 from Oleg Endo ---
Created attachment 55498
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55498=edit
also change address register when applying the peephole
The attached patch should fix the issue without removing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469
Oleg Endo changed:
What|Removed |Added
Last reconfirmed||2023-07-07
Ever confirmed|0
||olegendo at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #4 from Oleg Endo ---
I can confirm this on GCC 13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190
--- Comment #12 from Oleg Endo ---
(In reply to Oleg Endo from comment #0)
> The following code:
>
> struct X
> {
> int a, b, c, d, e;
> };
>
> int test (X* x, unsigned int c)
> {
> int s = 0;
> unsigned int i;
> for (i = 0; i < c;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62233
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65162
--- Comment #13 from Oleg Endo ---
(In reply to Oleg Endo from comment #1)
> (In reply to Oleg Endo from comment #0)
> > The following example is taken from libav, which contains quite some uses of
> > this code pattern.
> >
> > typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109874
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #95 from Oleg Endo ---
(In reply to Oleg Endo from comment #93)
> (In reply to Alexander Klepikov from comment #92)
> > I remembered why I used two different insns - first to eliminate infinite
> > loop with help of marking insn with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #93 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #92)
> I remembered why I used two different insns - first to eliminate infinite
> loop with help of marking insn with attribute, and second because I could
> not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #90 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #89)
> Here's what I did
> ...
Can you attach it here as a patch please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #85 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #83)
> Created attachment 55367 [details]
> Collapsed libcall and additional loop move invariants patch v3
Thanks for staying on it! I've looked through the latest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #80 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #79)
>
> I mean that if a user run GCC with -O1 and we don't do SH specific loop move
> invariants pass at -O1, a user could look at binary (or at .S file) and find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #78 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #77)
> > It'd be good if the newly added passes are ran only with -O2 or higher.
>
> This can be confusing to users when they discover that not all invariants
> are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #76 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #75)
> I found that patch incorrectly works when '-O0 -fmove-loop-invariants' flags
> are set. Stock loop optimization passes do not run when '-O0' is specified
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #72 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #71)
>
> > * Do we really need to add that new source file sh_loop.cc with the wrapper
> > classes? Can't we just instantiate the passes that are needed in-place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #70 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #69)
> Created attachment 55284 [details]
> Collapsed libcall and additional loop move invariants patch
Thanks for sharing the patch. I also don't have the GCC SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #67 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #66)
> (In reply to Alexander Klepikov from comment #65)
> > > I'm thinking of something else.
> >
> > During kernel compile I got few internal errors in different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #63 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #62)
>
> My project is small and it compiles in under 1 second on both clean and
> patched GCC. sh.exp test suite mean run time is 117s on clean and 119s on
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #61 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #60)
> > Maybe it's easier to add some shift specific passes.
>
> Well, I couldn't think of anything better and ported the loop optimization
> pass. More precisely,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #59 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #58)
>
> Ouch. That's a real problem. Short loops can become slower on about 10%. But
> is it possible to detect a loop during expand pass? It looks like basic
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517
--- Comment #17 from Oleg Endo ---
(In reply to Andrew Pinski from comment #16)
> Now I am curious if T_REG should be BImode rather than SImode ... Then
> ifcvt.cc would not have to be modified. I Know BImode is newer than when sh
> target was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #57 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #56)
>
> > In that test you can see the unnecessary push/pop of PR. This is because
> > initially it wanted to expand as a library call, but then your patterns
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517
--- Comment #13 from Oleg Endo ---
(In reply to Andrew Pinski from comment #12)
> Created attachment 55239 [details]
> Patch which does work on this
>
> Though, I need to double to make sure it works for other cases still.
> sh is the case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #55 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #54)
> Regarding testsuite. There's execute fails, but this is due to lack of
> multilib. I'll rebuild and retest.
>
> There's also fail in pr64345-1.c, in this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #53 from Oleg Endo ---
(In reply to Segher Boessenkool from comment #52)
>
> There is TARGET_LEGITIMATE_COMBINED_INSN though, which is a workaround for if
> you really do not want the instruction combiner to create particular
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #51 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #50)
>
> Ooh, my bad! You are absolutely right. A function is inlined and division is
> converted to 4 'shar's which at combine pass are catched by 'define_insn
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #49 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #48)
> Let's continue discussion we started here:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
>
> I've found that my patch catches integer division. In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #50 from Oleg Endo ---
Actually, let's take any further discussion of shift patterns to PR 54089.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #49 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #48)
> I made tests (including *.c files from GCC testsuite) and everything looks
> fine for now. But I'm still afraid that pattern for 'ashrsi3_libcall_expand'
> is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #47 from Oleg Endo ---
(In reply to Eric Gallager from comment #46)
> Reminder that patches go to the gcc-patches mailing list
It's OK. We're just throwing around ideas, nothing final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #44 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #43)
>
> Well, not really. Look what's happening during expand pass when 'ashrsi3' is
> expanding. Function 'expand_ashiftrt' is called and what it does at the end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #42 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #41)
>
> Thank you! I have an idea. If it's impossible to defer initial optimization,
> maybe it's possible to emit some intermediate insn and catch it and optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #40 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #39)
>
> I'm sorry, but .md lang is too complicated for me.
Yeah, it looks alien at first sight. But it's where a lot of things happen
w.r.t. instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #38 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #37)
>
> As far as I understand from GCC sources, function I patched
> 'expand_ashiftrt' process only constant values of shift. As you can see
> earlier, I added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #36 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #35)
>
> As I understand, you meant the following (I added new functions at the end
> of file):
>
> $ cat f.c
> #define ADDR 0x
> #define P ((unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #34 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #33)
> Created attachment 55142 [details]
> Disable dynamic shift instructions patch
First of all, thanks for digging into this. This issue has been a can of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55295
--- Comment #17 from Oleg Endo ---
(In reply to Luke Benstead from comment #16)
> OK so perhaps adding __builtin_sh_fipr is a good first step?
Yeah, you can try and see if it produces any useful results for you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55295
--- Comment #15 from Oleg Endo ---
It's been too long since I've looked into it. Maybe some middle-end parts got
more suitable over the time, but it was difficult to make it generate the fipr
instruction automatically due to the reasons stated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469
--- Comment #4 from Oleg Endo ---
(In reply to Rin Okuyama from comment #3)
> Thank you very much for your analysis!
>
> If that peephole is removed, GCC 10.3 generates working codes.
>
> NetBSD/shle built by this compiler works fine as far
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97431
--- Comment #6 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #5)
So the difference seems to be only the -fPIC option? Can you get the
preprocessed .i file with -save-temps ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97431
Oleg Endo changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
Oleg Endo changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
--- Comment #10 from Oleg Endo ---
I can't reproduce the first case with a standalone sh-elf compiler (GCC 9).
The compile flags mention
-specs=/usr/share/dpkg/pie-compile.specs
... what's in that specs file?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #125 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #122)
>
> The build process is. Fixing broken packages isn't.
>
> Everything is around 13.000 source packages.
>
> And, finally, the buildd capacity is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #24 from Oleg Endo ---
Adrian, have you had a chance to apply the test patch in comment #22 and re-run
it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #121 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #120)
>
> That's a huge task which is why I prefer fixing issues on the fly.
I thought this is almost fully automated?
You can apply this patch to GCC to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
--- Comment #6 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #5)
> Hmm, there is one other source code file within webkit2gtk where
> -fno-move-loop-invariants does not help. I can only get that particular
> source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #119 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #118)
> Is there anything that currently speaks against switching to LRA by default
> now?
There were a couple of code quality issues, which I would need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876
--- Comment #6 from Oleg Endo ---
If -mlra helps with this case, then let's close this one as 'WON'T FIX', ok?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876
--- Comment #4 from Oleg Endo ---
the error message is
unable to find a register to spill in class 'R0_REGS'
please try to re-build with -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #23 from Oleg Endo ---
(In reply to Oleg Endo from comment #22)
>
> I see at least one encoder function that
... does not check that p is >= e and blindly starts reading data at p. ... so
I'd like to try to narrow it down a bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #22 from Oleg Endo ---
(In reply to Andrew Pinski from comment #21)
>
> I think it is more by accident.strict-alginment here should not make a
> difference really as it is undefined even on non-strict targets.
> fcross-jumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91913
--- Comment #8 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #6)
> I'm seeing this exact problem SH as well when trying to build webkit2gtk:
>
> internal compiler error: in extract_constrain_insn, at recog.c:2211
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #20 from Oleg Endo ---
(In reply to Andrew Pinski from comment #19)
> t = (const uintptr_t *)(e - (4 -1));
>
> is problemantic though. e is not known to be aligned to uintptr_t.
That's right. But it makes me wonder, why this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #18 from Oleg Endo ---
(In reply to Andrew Pinski from comment #17)
> In the original code we have:
> if ((uintptr_t)p % 4) {
> int l = 4 - (uintptr_t)p % 4;
> p += l;
> switch (l) {
>
> l range should be 0...3
Ha!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #16 from Oleg Endo ---
This seems to be actually valid code?!
switch (e - p)
{
default: __builtin_unreachable();
case 3: if (e[-3]&0x80) return e-3;
case 2: if (e[-2]&0x80) return e-2;
case 1: if (e[-1]&0x80)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #14 from Oleg Endo ---
Created attachment 47879
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47879=edit
reduced case
I've reduced the preprocessed file string.c down to the problematic function
'coderange_scan'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #10 from Oleg Endo ---
I've just tried to compile the preprocessed string.i with the current gcc 9
branch sh-elf cross compiler with the following options:
sh-elf-gcc -c -mieee -g -O2 -fstack-protector-strong -Wformat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #6 from Oleg Endo ---
Thanks, that's good. I can look at the disassembly of string.o and found the
spot.
I suspect the switch statements in the code are turned into jump tables, and
for some reason the jump offset is wrong in some
1 - 100 of 1808 matches
Mail list logo
