https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=217325&root=gcc&view=rev
Log:
2014-11-11 Uros Bizjak
Revert:
2014-10-31 Uros Bizja
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #29 from Vladimir Makarov ---
Author: vmakarov
Date: Mon Nov 10 21:33:06 2014
New Revision: 217320
URL: https://gcc.gnu.org/viewcvs?rev=217320&root=gcc&view=rev
Log:
2014-11-10 Vladimir Makarov
PR rtl-optimization/63620
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #28 from Uroš Bizjak ---
(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" testcase when
the pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #27 from Vladimir Makarov ---
Author: vmakarov
Date: Sun Nov 9 16:45:15 2014
New Revision: 217265
URL: https://gcc.gnu.org/viewcvs?rev=217265&root=gcc&view=rev
Log:
2014-11-09 Vladimir Makarov
PR rtl-optimization/63620
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #26 from Uroš Bizjak ---
PR 63527 is probably related to this issue.
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=216990&root=gcc&view=rev
Log:
PR target/63620
* config/i386/i386-protos.h (ix86_use_pse
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=216987&root=gcc&view=rev
Log:
PR target/63620
* config/i386/i386.md (*pushtf): Allow on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #23 from Jeffrey A. Law ---
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 #22 from Uroš Bizjak ---
(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 was in fact tempted to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #21 from Jeffrey A. Law ---
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 makes it clear that th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Uroš Bizjak changed:
What|Removed |Added
CC||dominiq at lps dot ens.fr,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #19 from Uroš Bizjak ---
(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 to set the pic-pseud
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #18 from Vladimir Makarov ---
(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 points during IRA? It'll
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #17 from Jeffrey A. Law ---
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 may still be better tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #16 from Vladimir Makarov ---
(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 current work on LRA-remat pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Jeffrey A. Law changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |vmakarov at redhat dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Ilya Enkovich changed:
What|Removed |Added
CC||enkovich.gnu at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #12 from Jeffrey A. Law ---
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 has shown up on other ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #11 from Uroš Bizjak ---
(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 issue looks like Darwi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #10 from Stupachenko Evgeny ---
(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 f128_p3 does not expan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #9 from Uroš Bizjak ---
(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 the Darwin case. Pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #8 from Stupachenko Evgeny ---
(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 should be fixed for
> TAR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #7 from Uroš Bizjak ---
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 this will solve bootstrap,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #6 from Uroš Bizjak ---
(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 x86_64-apple-darwin11. The i6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Igor Zamyatin changed:
What|Removed |Added
CC||izamyatin at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #4 from Uroš Bizjak ---
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 insn should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Uroš Bizjak changed:
What|Removed |Added
Keywords||ra
Target|Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #2 from Stupachenko Evgeny ---
Created attachment 33784
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33784&action=edit
patch making the test and darwin bootstrap pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #1 from Stupachenko Evgeny ---
The issue reproduced only if patch from PR63618 is applied.
31 matches
Mail list logo
