https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #20 from James Clarke ---
(In reply to Eric Botcazou from comment #19)
> > Ah, great, thanks, that's indeed a nicer way of writing the patterns.
>
> You're welcome. Don't hesitate to ping next time I drop the ball for so
> long.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #19 from Eric Botcazou ---
> Ah, great, thanks, that's indeed a nicer way of writing the patterns.
You're welcome. Don't hesitate to ping next time I drop the ball for so long.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #17 from James Clarke ---
Ah, great, thanks, that's indeed a nicer way of writing the patterns.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #16 from Eric Botcazou ---
Author: ebotcazou
Date: Wed Jan 9 14:41:55 2019
New Revision: 267773
URL: https://gcc.gnu.org/viewcvs?rev=267773&root=gcc&view=rev
Log:
PR target/84010
* config/sparc/sparc.c (sparc_legitim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #15 from Eric Botcazou ---
Author: ebotcazou
Date: Wed Jan 9 14:39:18 2019
New Revision: 267772
URL: https://gcc.gnu.org/viewcvs?rev=267772&root=gcc&view=rev
Log:
PR target/84010
* config/sparc/sparc.c (sparc_legitim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #14 from Eric Botcazou ---
Author: ebotcazou
Date: Wed Jan 9 14:34:20 2019
New Revision: 267771
URL: https://gcc.gnu.org/viewcvs?rev=267771&root=gcc&view=rev
Log:
PR target/84010
* config/sparc/sparc.c (sparc_legitim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #13 from Eric Botcazou ---
> 2. Apply this patch to GCC (assuming it still applies cleanly...).
FYI I'm in the process of rewriting it using mode iterators.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #12 from Eric Botcazou ---
(> So, as far as I see it, we have two choices:
>
> 1. Disable all X -> LE relaxations in the linker. Works, but then gives
> suboptimal performance if some code linked into an executable is built with
> -f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #11 from James Clarke ---
(In reply to Eric Botcazou from comment #9)
> > There are similar problems for other TLS models which can be relaxed, but
> > even worse than this, local dynamic uses a sethi/xor for the offset from the
> > d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #10 from Eric Botcazou ---
> So, if the above formulas are incorrect, relaxation is required in all cases.
...are correct...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #9 from Eric Botcazou ---
> There are similar problems for other TLS models which can be relaxed, but
> even worse than this, local dynamic uses a sethi/xor for the offset from the
> defining module's block to load a signed 32-bit val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |7.5
Summary|[sparc64] Problem
14 matches
Mail list logo
