This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/78660] [7 Regression] 7.0 bootstrap fail on mips64el-unknow-linux: configure-stage2-target-libgcc' failed


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.)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]