https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #29 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
Author: vmakarov
Date: Mon Nov 10 21:33:06 2014
New Revision: 217320
URL: https://gcc.gnu.org/viewcvs?rev=217320root=gccview=rev
Log:
2014-11-10 Vladimir Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #30 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Nov 10 23:29:59 2014
New Revision: 217325
URL: https://gcc.gnu.org/viewcvs?rev=217325root=gccview=rev
Log:
2014-11-11 Uros Bizjak ubiz...@gmail.com
Revert:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #27 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
Author: vmakarov
Date: Sun Nov 9 16:45:15 2014
New Revision: 217265
URL: https://gcc.gnu.org/viewcvs?rev=217265root=gccview=rev
Log:
2014-11-09 Vladimir Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #28 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Vladimir Makarov from comment #27)
Author: vmakarov
Date: Sun Nov 9 16:45:15 2014
New Revision: 217265
Unfortunately, the patch does not fix the Reproducer for linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #26 from Uroš Bizjak ubizjak at gmail dot com ---
PR 63527 is probably related to this issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #19 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Vladimir Makarov from comment #18)
(In reply to Jeffrey A. Law from comment #17)
So would it work (and I realize this is a horrid hack) to have a way for the
backend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
CC||dominiq at lps dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #21 from Jeffrey A. Law law at redhat dot com ---
Uros,
Any objection to installing that patch to work around these problems while Vlad
works on things from the rematerialization side?
Perhaps put that condition in a function which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #22 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Jeffrey A. Law from comment #21)
Any objection to installing that patch to work around these problems while
Vlad works on things from the rematerialization side?
No, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #23 from Jeffrey A. Law law at redhat dot com ---
The inline XXX comment approach is fine with me, let's go with that.
I'll let you do the honors ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #24 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Oct 31 19:47:36 2014
New Revision: 216987
URL: https://gcc.gnu.org/viewcvs?rev=216987root=gccview=rev
Log:
PR target/63620
* config/i386/i386.md (*pushtf): Allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #25 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Oct 31 21:52:22 2014
New Revision: 216990
URL: https://gcc.gnu.org/viewcvs?rev=216990root=gccview=rev
Log:
PR target/63620
* config/i386/i386-protos.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Vladimir Makarov vmakarov at gcc dot gnu.org changed:
What|Removed |Added
CC||vmakarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #16 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
(In reply to Vladimir Makarov from comment #15)
I am starting to work on this. I have very few time before the end of the
current stage and it makes me reconsider my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #17 from Jeffrey A. Law law at redhat dot com ---
So would it work (and I realize this is a horrid hack) to have a way for the
backend to set the pic-pseudo as live at the key points during IRA? It'll be
overly conservative, but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #18 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #17)
So would it work (and I realize this is a horrid hack) to have a way for the
backend to set the pic-pseudo as live at the key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Ilya Enkovich enkovich.gnu at gmail dot com changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |vmakarov at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Igor Zamyatin izamyatin at gmail dot com changed:
What|Removed |Added
CC||izamyatin at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #6 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Igor Zamyatin from comment #5)
Confirmed. This will affect all SSE targets.
Have you managed to reproduce the issue on i686?
No, only with a crosscompiler to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #7 from Uroš Bizjak ubizjak at gmail dot com ---
The difference si that the call to f128_p3 does not expand with use (reg:SI
bx) tag in the Darwin case. Probably ix86_expand_call should be fixed for
TARGET_MACHO.
However, even if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #8 from Stupachenko Evgeny evstupac at gmail dot com ---
(In reply to Uroš Bizjak from comment #7)
The difference si that the call to f128_p3 does not expand with use (reg:SI
bx) tag in the Darwin case. Probably ix86_expand_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #9 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Stupachenko Evgeny from comment #8)
(In reply to Uroš Bizjak from comment #7)
The difference si that the call to f128_p3 does not expand with use (reg:SI
bx) tag in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #10 from Stupachenko Evgeny evstupac at gmail dot com ---
(In reply to Uroš Bizjak from comment #9)
(In reply to Stupachenko Evgeny from comment #8)
(In reply to Uroš Bizjak from comment #7)
The difference si that the call to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #11 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Stupachenko Evgeny from comment #10)
Anyway, if call is not EBX dependent (say local call in Linux) the issue is
not reproduced (like in example from PR63618).
So the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #12 from Jeffrey A. Law law at redhat dot com ---
The more I watch the %ebx PIC problems, the more this reminds me of secondary
reloads and I wonder if we defined those properly if the right things would
happen.
This kind of thing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Keywords||ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #4 from Uroš Bizjak ubizjak at gmail dot com ---
Please note that:
(define_insn *pushtf
[(set (match_operand:TF 0 push_operand =,)
(match_operand:TF 1 general_no_elim_operand x,*roF))]
TARGET_64BIT || TARGET_SSE
{
/* This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #1 from Stupachenko Evgeny evstupac at gmail dot com ---
The issue reproduced only if patch from PR63618 is applied.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #2 from Stupachenko Evgeny evstupac at gmail dot com ---
Created attachment 33784
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33784action=edit
patch making the test and darwin bootstrap pass
31 matches
Mail list logo
