https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #35 from Michael Meissner ---
Author: meissner
Date: Thu Feb 18 19:59:03 2016
New Revision: 233535
URL: https://gcc.gnu.org/viewcvs?rev=233535=gcc=rev
Log:
Merge in fix for PR 68404
Modified:
branches/ibm/power9/ (props
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
Michael Meissner changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #33 from Michael Meissner ---
Author: meissner
Date: Thu Feb 18 19:36:39 2016
New Revision: 233532
URL: https://gcc.gnu.org/viewcvs?rev=233532=gcc=rev
Log:
[gcc]
2016-02-18 Michael Meissner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #32 from Michael Meissner ---
On Thu, Feb 11, 2016 at 05:53:35PM +, meissner at linux dot vnet.ibm.com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
>
> --- Comment #31 from Michael Meissner ---
> On Thu, Feb 11,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #31 from Michael Meissner ---
On Thu, Feb 11, 2016 at 02:32:13AM +, bernds at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
>
> --- Comment #30 from Bernd Schmidt ---
> Something like this maybe? I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
David Edelsohn changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #29 from Bernd Schmidt ---
Mike, this isn't about addresses. It's about an earlyclobber output overlapping
an input. Maybe there's an invalid peephole creating such a pattern, or maybe
the output need not be marked earlyclobber -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #28 from Michael Meissner ---
I agree the 'fix' was a work around. I think the real fix is to make the
addresses into normal addresses but I need some way of marking the address to
say this is ok as a fused address, but not as a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #30 from Bernd Schmidt ---
Something like this maybe? I don't know much about the machine and can't say
whether the earlyclobber is justified, but looking at my dumps this appears to
prevent the problematic peephole from triggering.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #21 from Jakub Jelinek ---
*** Bug 69727 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #22 from Martin Sebor ---
After applying the patch from comment #19 my profiledbootstrap also just
completed on the big-endian powerpc64-redhat-linux-gnu (it failed before due to
the duplicate bug 69727).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
Michael Meissner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #23 from Michael Meissner ---
Author: meissner
Date: Tue Feb 9 22:31:31 2016
New Revision: 233255
URL: https://gcc.gnu.org/viewcvs?rev=233255=gcc=rev
Log:
[gcc]
2016-02-09 Michael Meissner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #25 from Bernd Schmidt ---
(In reply to Bill Schmidt from comment #9)
> Finally got back to this for a bit. I've tracked the problem down to the
> register renaming pass. I suspect it's having trouble with the
> fusion_gpr_load_di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #20 from Markus Trippelsdorf ---
Your patch fixes the problem for me. Thanks.
I've also successfully build Firefox and run the Boost testsuite with it.
(the Boost testsuite hit the PR68973 ICE once with -mlra.
I will reduce a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
Michael Meissner changed:
What|Removed |Added
Attachment #37634|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
Michael Meissner changed:
What|Removed |Added
Assignee|wschmidt at gcc dot gnu.org|meissner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #14 from Michael Meissner ---
Created attachment 37634
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37634=edit
Proposed patch to fix the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #15 from Michael Meissner ---
Markus Trippelsdorf: Could you try the patch that I attached to the bug? I get
past the point that was failing before, but I get new errors (lto type not the
same in the decnumber library), so I suspect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #16 from Markus Trippelsdorf ---
(In reply to Michael Meissner from comment #15)
> Markus Trippelsdorf: Could you try the patch that I attached to the bug? I
> get past the point that was failing before, but I get new errors (lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #17 from Markus Trippelsdorf ---
And the "lto type not the same in decnumber" issue should go away with
--disable-werror.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #13 from rsandifo at gcc dot gnu.org
---
(In reply to Bill Schmidt from comment #10)
> Looking at scan_rtx_address () in regrename.c, it indeed looks like a PLUS
> nested inside a PLUS isn't handled. I'm not sure if this is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #9 from Bill Schmidt ---
Finally got back to this for a bit. I've tracked the problem down to the
register renaming pass. I suspect it's having trouble with the
fusion_gpr_load_di pattern:
(insn 452 236 243 19 (set (reg:DI 9 9)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
Bill Schmidt changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #10 from Bill Schmidt ---
Looking at scan_rtx_address () in regrename.c, it indeed looks like a PLUS
nested inside a PLUS isn't handled. I'm not sure if this is a deficiency in
regrename.c, or whether the definition of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #12 from Michael Meissner ---
On Fri, Feb 05, 2016 at 11:57:05PM +, wschmidt at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
>
> Bill Schmidt changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #8 from Bill Schmidt ---
LTO is creating a clone of reg_save_code, specialized on a particular value of
parameter reg. The compiled code contains a badly formed address expression,
causing the segfault. Continuing to look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #7 from Markus Trippelsdorf ---
(In reply to Bill Schmidt from comment #6)
> Backtrace from gdb:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x10cfcf74 in reg_save_code(int, machine_mode) [clone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #6 from Bill Schmidt ---
Backtrace from gdb:
Program received signal SIGSEGV, Segmentation fault.
0x10cfcf74 in reg_save_code(int, machine_mode) [clone .lto_priv.8969]
()
(gdb) bt
#0 0x10cfcf74 in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
Bill Schmidt changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
Markus Trippelsdorf changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
Markus Trippelsdorf changed:
What|Removed |Added
Keywords||wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #2 from Markus Trippelsdorf ---
While bisecting I also observed gcc spinning when building libgcc during
phase-profile-feedback.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
36 matches
Mail list logo