https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
mpf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #20 from mpf at gcc dot gnu.org ---
Author: mpf
Date: Wed Feb 22 17:20:14 2017
New Revision: 245655
URL: https://gcc.gnu.org/viewcvs?rev=245655=gcc=rev
Log:
Support WORD_REGISTER_OPERATIONS requirements in simplify_operand_subreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #19 from mpf at gcc dot gnu.org ---
Author: mpf
Date: Tue Feb 21 13:29:07 2017
New Revision: 245626
URL: https://gcc.gnu.org/viewcvs?rev=245626=gcc=rev
Log:
Revert r245598
gcc/
PR target/78660
Revert:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #17 from mpf at gcc dot gnu.org ---
Author: mpf
Date: Mon Feb 20 12:06:56 2017
New Revision: 245598
URL: https://gcc.gnu.org/viewcvs?rev=245598=gcc=rev
Log:
Handle WORD_REGISTER_OPERATIONS when reloading (subreg (reg))
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #18 from mpf at gcc dot gnu.org ---
Author: mpf
Date: Mon Feb 20 12:07:06 2017
New Revision: 245599
URL: https://gcc.gnu.org/viewcvs?rev=245599=gcc=rev
Log:
Tighten condition for converting SUBREG reloads from OP_OUT to OP_INOUT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #16 from mpf at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #15)
> That's incorrect, see what reload1.c:eliminate_regs_1 says about it:
>
> if (MEM_P (new_rtx)
> && ((x_size < new_size
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #15 from Eric Botcazou ---
> So does LRA generate a full 64-bit load or an extended 32-to-64-bit load?
The former it seems, I can see:
(insn 218 211 8356 2 (set (reg:SI 4 $4 [2479])
(ne:SI (reg:DI 22 $22 [orig:230 _3 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #14 from Eric Botcazou ---
> Yes, that is true but the upper 32-bits still need to be 'zero'. What
> happens later on is that the (subreg:SI (reg:DI 316)) is spilled, spilling
> only 32-bits to the stack but it gets reloaded as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #13 from mpf at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #12)
> > Maybe the load sign-extends instead of zero-extending as specified
> > initially.
>
> But I'm not sure that this matters here, since:
>
> (insn 58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #12 from Eric Botcazou ---
> Maybe the load sign-extends instead of zero-extending as specified initially.
But I'm not sure that this matters here, since:
(insn 58 57 59 3 (set (subreg:SI (reg:DI 316 [ iftmp.3_114 ]) 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #11 from Eric Botcazou ---
> The key (I think) is that the following sequence of 3 instructions ends up
> being combined into 1 but the resulting instruction leaves the upper 32-bits
> of reg 316 entirely undefined. Eventually this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
mpf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
Matthew Fortune changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #8 from Matthew Fortune ---
Created attachment 40518
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40518=edit
testcase
I have narrowed this bug down to a mis-compilation of gcc/c/c-decl.c where
there are a few code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #7 from YunQiang Su ---
(In reply to YunQiang Su from comment #6)
> With revert some change, with patch:
>
> Index: gcc-7-7-20161217/src/gcc/combine.c
> ===
> ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
YunQiang Su changed:
What|Removed |Added
CC||syq at debian dot org
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #5 from Paul Hua ---
(In reply to Paul Hua from comment #4)
>
> Maybe the r242326 cause the bug, the r242324 build success.
>
The r242326 and r242324 has another bug that r242522 fixed. If use r242326 to
reproduce this bug, you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #4 from Paul Hua ---
The r243817 still build failure.
configure:3460: /home/xuchenghua/GCC/test/gcc-r243817_obj/./gcc/xgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #3 from Matthew Fortune ---
(In reply to Aldy Hernandez from comment #2)
> I can't reproduce on a cross build. Is there a mips64el box on the compile
> farm or somewhere public so someone can look at this?
The following machines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
--- Comment #1 from Paul Hua ---
The latest version r243504 still build fail.
The version r241773 can build successfully.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
Andrew Pinski changed:
What|Removed |Added
Keywords||build, wrong-code
Target|
23 matches
Mail list logo
