https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
Oleg Endo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #27 from Oleg Endo ---
Author: olegendo
Date: Sat Feb 13 08:48:50 2016
New Revision: 233402
URL: https://gcc.gnu.org/viewcvs?rev=233402&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2016-02-13 Oleg Endo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #26 from Oleg Endo ---
Author: olegendo
Date: Sat Feb 13 08:46:49 2016
New Revision: 233401
URL: https://gcc.gnu.org/viewcvs?rev=233401&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2016-02-13 Oleg Endo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #25 from Oleg Endo ---
Author: olegendo
Date: Sat Feb 13 08:43:15 2016
New Revision: 233400
URL: https://gcc.gnu.org/viewcvs?rev=233400&root=gcc&view=rev
Log:
gcc/testsuite/
PR target/67260
* gcc.target/sh/torture/pr6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #24 from Oleg Endo ---
(In reply to Rich Felker from comment #18)
> I thought I fixed at least one occurrence of this when I forward-ported the
> FDPIC patch, but in any case, if it changed since that patch was first
> written then th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #23 from Oleg Endo ---
Author: olegendo
Date: Sat Feb 13 08:03:44 2016
New Revision: 233399
URL: https://gcc.gnu.org/viewcvs?rev=233399&root=gcc&view=rev
Log:
gcc/
PR target/67260
* config/sh/sh.md (sibcall_value_pcre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #22 from Oleg Endo ---
(In reply to Oleg Endo from comment #21)
>
> It seems the patch is not good. I see new failures when testing on sh-elf.
> I will try to see what's going on there.
False alarm. Those were other unrelated cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #21 from Oleg Endo ---
(In reply to Oleg Endo from comment #17)
>
>
> I guess because the recently added "sibcall_value_pcrel_fdpic" pattern also
> uses "=k" as the clobber constraint, it might run into the same problem. To
> play
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #20 from Rich Felker ---
The (second) patch in comment 17 seems to have fixed the build failure for
musl's complex math functions where I first encountered the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #19 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #17)
> Kaz, what do you think?
LGTM and looks like we have no choice for 5/4.9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #18 from Rich Felker ---
I thought I fixed at least one occurrence of this when I forward-ported the
FDPIC patch, but in any case, if it changed since that patch was first written
then there's almost surely a log entry and hopefully a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #17 from Oleg Endo ---
I have tried this:
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 233324)
+++ gcc/config/sh/sh.md (working copy)
@@ -10481,7 +10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #16 from Kazumoto Kojima ---
(In reply to Rich Felker from comment #15)
Maybe. There are other cases of address computations which could be
shared or simplified, as you know. Again very restrictive branches
and loads will make thin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #15 from Rich Felker ---
Is it related to the fact that the relative address load is tied to a specific
call site and that the call can't be cloned without producing a new relative
address load to go with the clone?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #14 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #13)
> Good question indeed. Kaz, maybe you remember anything?
With my vague recollection, they were already there when I had looked
into them for the first time.
I g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #13 from Oleg Endo ---
(In reply to Alexander Monakov from comment #12)
>
> I mostly wonder why does sh.md change RTL representation of a sibcall that
> way, instead of simply generating the required relative address load
> upfront,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #12 from Alexander Monakov ---
> Do you have anything in particular in mind?
I mostly wonder why does sh.md change RTL representation of a sibcall that way,
instead of simply generating the required relative address load upfront, dur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #11 from Oleg Endo ---
(In reply to Alexander Monakov from comment #10)
> If always using r0 is not an issue, I think it's possible to just use
> operands[0] (casting it to the right size with subreg:SI, if needed) to
> avoid using a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #10 from Alexander Monakov ---
If always using r0 is not an issue, I think it's possible to just use
operands[0] (casting it to the right size with subreg:SI, if needed) to avoid
using a potentially-reserved hardreg. This would allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #8 from Alexander Monakov ---
Hm, if GCC won't accept clobbering a hardreg that overlaps the output hardregs
holding the return value (operands[0]), then it's less obvious. r0 is always
suitable then and does not require mentioning in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #7 from Alexander Monakov ---
Oleg, Rich, there's some confusion in comments 4-6. Please unwind all the way
back to comment #1, and let me explain the issue once again. I now see that my
phrasing back then was insufficiently detaile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #6 from Oleg Endo ---
(In reply to Rich Felker from comment #5)
>
> 1. that the "k" constraint that's currently used is not working to
> automatically assign a scratch register because r4-r7 are all live as
> argument registers and r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #5 from Rich Felker ---
Oleg, thanks for the tip. I think what Alexander is saying about r0-r3 is:
1. that the "k" constraint that's currently used is not working to
automatically assign a scratch register because r4-r7 are all live
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #4 from Oleg Endo ---
(In reply to Alexander Monakov from comment #1)
>
> So it wants to pick a scratch register in SIBCALL_REGS ("k", r0-r7), but in
> the circumstances r4-r7 are already used for argument passing, and r0-r3 are
> us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
Oleg Endo changed:
What|Removed |Added
Target||sh*-*-*
--- Comment #3 from Oleg Endo ---
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #2 from Alexander Monakov ---
(added SH maintainers, Oleg Endo and Kaz Kojima to Cc)
In response to the last sentence in my analysis, on IRC Rich pointed out that
using r1/r2/r3 should be better that r0 because some instruction can o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
28 matches
Mail list logo
