This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed
- From: "mpf at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 16 Jan 2017 10:12:15 +0000
- Subject: [Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed
- Auto-submitted: auto-generated
- References: <bug-78660-4@http.gcc.gnu.org/bugzilla/>
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 57 59 3 (set (subreg:SI (reg:DI 316 [ iftmp.3_114 ]) 0)
> (ne:SI (reg/f:DI 469 [ current_scope.1_1->bindings ])
> (const_int 0 [0])))
> "/althome/mips/v6/src/gcc/gcc/c/c-decl.me.c":915 501 {*sne_zero_disi}
> (expr_list:REG_DEAD (reg/f:DI 469 [ current_scope.1_1->bindings ])
> (nil)))
>
> can put only 0 or 1 in the SUBREG, can't it?
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 DImode/64-bit. The upper-32 bits are junk.
I don't believe that is an LRA bug as it is doing exactly what is described by
the subreg.
The original zero_extend in insn 58 to DImode is therefore very important here
and cannot be converted to a subreg.
(I haven't got to the specific combine rule yet that is doing this substitution
to see which decision is bad.)