The latest version r243504 still build fail.
The version r241773 can build successfully.

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?

(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 were added to the farm relatively recently. gcc24 is not accepting my login currently though to gcc22 or gcc23 are usable. They will not be fast though as they are modified routers. They are 32-bit but with 64-bit multilibs I suspect that is good enough to reproduce. I won't find time to look at this until the new year at least, any help is appreciated.

Operating system are currently configured as follows:
* gcc22 - kernel 3.14.10 (EB), Debian 7.10 (Wheezy), gcc 4.6.3
* gcc23 - kernel 4.1.4 (EL), Debian 8.4 (Jessie), gcc 4.9.2
* gcc24 - kernel 4.1.4 (EL), Debian 8.4 (Jessie), gcc 4.9.2 (EB = big endian, EL = little endian)

The r243817 still build failure.

------------------------------------------------------------------------
configure:3460: /home/xuchenghua/GCC/test/gcc-r243817_obj/./gcc/xgcc -B/home/xuchenghua/GCC/test/gcc-r243817_obj/./gcc/ -B/home/xuchenghua/toolchain/gcc-trunk-r243817/mips64el-unknown-linux/bin/ -B/home/xuchenghua/toolchain/gcc-trunk-r243817/mips64el-unknown-linux/lib/ -isystem /home/xuchenghua/toolchain/gcc-trunk-r243817/mips64el-unknown-linux/include -isystem /home/xuchenghua/toolchain/gcc-trunk-r243817/mips64el-unknown-linux/sys-include    -o conftest -g -O2 -minterlink-mips16   conftest.c  >&5
conftest.c: In function 'main':
conftest.c:11:1: error: unrecognizable insn:
 main ()
 ^~~~
(insn 2 0 0 (set (reg:TI 64 lo) 
        (const_int 0 [0])) "conftest.c":12 -1
     (nil))
conftest.c:11:1: internal compiler error: in internal_dfa_insn_code, at config/mips/mips.md:764
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
configure:3463: $? = 1 
configure:3651: checking for suffix of object files
configure:3673: /home/xuchenghua/GCC/test/gcc-r243817_obj/./gcc/xgcc -B/home/xuchenghua/GCC/test/gcc-r243817_obj/./gcc/ -B/home/xuchenghua/toolchain/gcc-trunk-r243817/mips64el-unknown-linux/bin/ -B/home/xuchenghua/toolchain/gcc-trunk-r243817/mips64el-unknown-linux/lib/ -isystem /home/xuchenghua/toolchain/gcc-trunk-r243817/mips64el-unknown-linux/include -isystem /home/xuchenghua/toolchain/gcc-trunk-r243817/mips64el-unknown-linux/sys-include    -c -g -O2 -minterlink-mips16  conftest.c >&5
conftest.c: In function 'main':
conftest.c:11:1: error: unrecognizable insn:
 main ()
 ^~~~
(insn 2 0 0 (set (reg:TI 64 lo)
        (const_int 0 [0])) "conftest.c":12 -1
     (nil))
conftest.c:11:1: internal compiler error: in internal_dfa_insn_code, at config/mips/mips.md:764
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
configure:3677: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/"
| /* end confdefs.h.  */
|
| int  
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3691: error: in `/home/xuchenghua/GCC/test/gcc-r243817_obj/mips64el-unknown-linux/libgcc':
configure:3694: error: cannot compute suffix of object files: cannot compile
-----------------------------------------------------------------------------

Maybe the r242326 cause the bug, the r242324 build success.

(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 should patched the r242522.

With revert some change, with patch:

Index: gcc-7-7-20161217/src/gcc/combine.c
===================================================================
--- gcc-7-7-20161217.orig/src/gcc/combine.c
+++ gcc-7-7-20161217/src/gcc/combine.c
@@ -9972,13 +9972,13 @@ reg_nonzero_bits_for_combine (const_rtx
                  (DF_LR_IN (ENTRY_BLOCK_PTR_FOR_FN (cfun)->next_bb),
                   REGNO (x)))))
     {
-      /* Note that, even if the precision of last_set_mode is lower than that
-        of mode, record_value_for_reg invoked nonzero_bits on the register
-        with nonzero_bits_mode (because last_set_mode is necessarily integral
-        and HWI_COMPUTABLE_MODE_P in this case) so bits in nonzero_bits_mode
-        are all valid, hence in mode too since nonzero_bits_mode is defined
-        to the largest HWI_COMPUTABLE_MODE_P mode.  */
-      *nonzero &= rsp->last_set_nonzero_bits;
+      unsigned HOST_WIDE_INT mask = rsp->last_set_nonzero_bits;
+
+      if (GET_MODE_PRECISION (rsp->last_set_mode) < GET_MODE_PRECISION (mode))
+       /* We don't know anything about the upper bits.  */
+       mask |= GET_MODE_MASK (mode) ^ GET_MODE_MASK (rsp->last_set_mode);
+
+      *nonzero &= mask;
       return NULL;
     }

(In reply to YunQiang Su from comment #6)
> With revert some change, with patch:
> 
> Index: gcc-7-7-20161217/src/gcc/combine.c
> ===================================================================
> --- gcc-7-7-20161217.orig/src/gcc/combine.c
> +++ gcc-7-7-20161217/src/gcc/combine.c
> @@ -9972,13 +9972,13 @@ reg_nonzero_bits_for_combine (const_rtx
>                   (DF_LR_IN (ENTRY_BLOCK_PTR_FOR_FN (cfun)->next_bb),
>                    REGNO (x)))))
>      {
> -      /* Note that, even if the precision of last_set_mode is lower than
> that
> -        of mode, record_value_for_reg invoked nonzero_bits on the register
> -        with nonzero_bits_mode (because last_set_mode is necessarily
> integral
> -        and HWI_COMPUTABLE_MODE_P in this case) so bits in nonzero_bits_mode
> -        are all valid, hence in mode too since nonzero_bits_mode is defined
> -        to the largest HWI_COMPUTABLE_MODE_P mode.  */
> -      *nonzero &= rsp->last_set_nonzero_bits;
> +      unsigned HOST_WIDE_INT mask = rsp->last_set_nonzero_bits;
> +
> +      if (GET_MODE_PRECISION (rsp->last_set_mode) < GET_MODE_PRECISION
> (mode))
> +       /* We don't know anything about the upper bits.  */
> +       mask |= GET_MODE_MASK (mode) ^ GET_MODE_MASK (rsp->last_set_mode);
> +
> +      *nonzero &= mask;
>        return NULL;
>      }

This can make it buildable now.

Created attachment 40518 [details]
testcase

I have narrowed this bug down to a mis-compilation of gcc/c/c-decl.c where there are a few code differences after applying yunqiang's partial revert. A reduced and pre-processed c-decl.c file is attached.

mips64el-linux-gnu-g++ -fno-PIE -c  -DIN_GCC_FRONTEND  -O2 -DIN_GCC     -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -o c-decl.me.o c-decl.me.c

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 leads to reg 316 being spilled to the stack where it is allocated a 64-bit slot but this spill only writes 32-bits whereas consumers read 64-bit and even if the value will only ever be operated on as 32-bit or less then logical and branch operations on the reloaded value will go wrong and normal 32-bit operations will be (strictly) undefined.

(insn 56 55 57 3 (set (reg:SI 470)
        (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)))
(insn 57 56 58 3 (set (reg:QI 468)
        (subreg:QI (reg:SI 470) 0)) "/althome/mips/v6/src/gcc/gcc/c/c-decl.me.c":915 360 {*movqi_internal}
     (expr_list:REG_DEAD (reg:SI 470)
        (nil)))
(insn 58 57 59 3 (set (reg:DI 316 [ iftmp.3_114 ])
        (zero_extend:DI (reg:QI 468))) "/althome/mips/v6/src/gcc/gcc/c/c-decl.me.c":915 214 {*zero_extendqidi2}
     (expr_list:REG_DEAD (reg:QI 468)
        (nil)))

combines to...

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

The relevant fragment of combine is:

Trying 57 -> 58:
Successfully matched this instruction:
(set (reg:DI 316 [ iftmp.3_114 ])
    (subreg:DI (reg:SI 470) 0))
allowing combination of insns 57 and 58
original costs 4 + 4 = 8
replacement cost 4
deferring deletion of insn with uid = 57.
modifying insn i3    58: r316:DI=r470:SI#0
      REG_DEAD r470:SI
deferring rescan insn with uid = 58.

Trying 56 -> 58:
Successfully matched this instruction:
(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])))
allowing combination of insns 56 and 58
original costs 4 + 4 = 8
replacement cost 4
deferring deletion of insn with uid = 56.
modifying insn i3    58: r316:DI#0=r469:DI!=0
      REG_DEAD r469:DI
deferring rescan insn with uid = 58.

I've not started investigating why exactly this decision is made.

@eric: adding you following our discussion on PR rtl-optimization/59461

I have added my findings so far on this ticket.

While mips64el-unknown-linux is not a specific primary platform I see no reason why this bug would not show on mipsisa64-elf. Bumping to P2.

> 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 leads to reg 316 being
> spilled to the stack where it is allocated a 64-bit slot but this spill only
> writes 32-bits whereas consumers read 64-bit and even if the value will only
> ever be operated on as 32-bit or less then logical and branch operations on
> the reloaded value will go wrong and normal 32-bit operations will be
> (strictly) undefined.

But MIPS defines LOAD_EXTEND_OP so the 32 upper bits are defined, aren't they?
Maybe the load sign-extends instead of zero-extending as specified initially.

> 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?

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

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

Then either the MIPS port is not correctly parameterized, because LOAD_EXTEND_OP says that the upper 32 bits are *not* junk (see also comment 11) or...

> I don't believe that is an LRA bug as it is doing exactly what is described by
> the subreg.

...it's a LRA bug if it spills 32 bits but reloads 64 bits; Old Reload knows that it cannot do that if WORD_REGISTER_OPERATIONS is 1.

So does LRA generate a full 64-bit load or an extended 32-to-64-bit load?

> 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 ] [230])
            (const_int 0 [0]))) "/althome/mips/v6/src/gcc/gcc/c/c-decl.c":5551 505 {*sne_zero_disi}
     (nil))

(insn 8356 218 220 2 (set (mem/c:SI (plus:DI (reg/f:DI 29 $sp)
                (const_int 208 [0xd0])) [680 %sfp+208 S4 A64])
        (reg:SI 4 $4 [2479])) "/althome/mips/v6/src/gcc/gcc/c/c-decl.c":5551 312 {*movsi_internal}
     (nil))

[...]

(insn 8609 4185 4186 635 (set (reg/v:DI 2 $2 [orig:279 threadp ] [279])
        (mem/c:DI (plus:DI (reg/f:DI 29 $sp)
                (const_int 208 [0xd0])) [680 %sfp+208 S8 A64])) "/althome/mips/v6/src/gcc/gcc/c/c-decl.c":6618 310 {*movdi_64bit}
     (nil))

That's incorrect, see what reload1.c:eliminate_regs_1 says about it:

	  if (MEM_P (new_rtx)
	      && ((x_size < new_size
		   /* On RISC machines, combine can create rtl of the form
		      (set (subreg:m1 (reg:m2 R) 0) ...)
		      where m1 < m2, and expects something interesting to
		      happen to the entire word.  Moreover, it will use the
		      (reg:m2 R) later, expecting all bits to be preserved.
		      So if the number of words is the same, preserve the
		      subreg so that push_reload can see it.  */
		   && !(WORD_REGISTER_OPERATIONS
			&& (x_size - 1) / UNITS_PER_WORD
			   == (new_size -1 ) / UNITS_PER_WORD))
		  || x_size == new_size)
	      )
	    return adjust_address_nv (new_rtx, GET_MODE (x), SUBREG_BYTE (x));
	  else
	    return gen_rtx_SUBREG (GET_MODE (x), new_rtx, SUBREG_BYTE (x));

(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
> 		   /* On RISC machines, combine can create rtl of the form
> 		      (set (subreg:m1 (reg:m2 R) 0) ...)
> 		      where m1 < m2, and expects something interesting to
> 		      happen to the entire word.  Moreover, it will use the
> 		      (reg:m2 R) later, expecting all bits to be preserved.
> 		      So if the number of words is the same, preserve the
> 		      subreg so that push_reload can see it.  */
> 		   && !(WORD_REGISTER_OPERATIONS
> 			&& (x_size - 1) / UNITS_PER_WORD
> 			   == (new_size -1 ) / UNITS_PER_WORD))
> 		  || x_size == new_size)
> 	      )
> 	    return adjust_address_nv (new_rtx, GET_MODE (x), SUBREG_BYTE (x));
> 	  else
> 	    return gen_rtx_SUBREG (GET_MODE (x), new_rtx, SUBREG_BYTE (x));

I was just contemplating your comments on LRA and coming to the conclusion it must be LRA in the end. The implications of the subreg with WORD_REGISTER_OPERATIONS are quite a brain teaser.

I'll move on to LRA instead.

I forgot to say that while reviewing this issue I saw that your original patch in combine removed a decent amount of zero extensions from MIPS. Thanks!

Author: mpf
Date: Mon Feb 20 12:06:56 2017
New Revision: 245598

URL: https://gcc.gnu.org/viewcvs?rev=245598&root=gcc&view=rev
Log:
Handle WORD_REGISTER_OPERATIONS when reloading (subreg (reg))

gcc/
	PR target/78660
	* lra-constraints.c (curr_insn_transform): Handle
	WORD_REGISTER_OPERATIONS requirements when reloading SUBREGs.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lra-constraints.c

Author: mpf
Date: Mon Feb 20 12:07:06 2017
New Revision: 245599

URL: https://gcc.gnu.org/viewcvs?rev=245599&root=gcc&view=rev
Log:
Tighten condition for converting SUBREG reloads from OP_OUT to OP_INOUT

gcc/
	PR target/78660
	* lra-constraints.c (curr_insn_transform): Tighten condition
	for converting SUBREG reloads from OP_OUT to OP_INOUT.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lra-constraints.c

Author: mpf
Date: Tue Feb 21 13:29:07 2017
New Revision: 245626

URL: https://gcc.gnu.org/viewcvs?rev=245626&root=gcc&view=rev
Log:
Revert r245598

gcc/
	PR target/78660
	Revert:
	2017-02-20  Matthew Fortune  <matthew.fortune@imgtec.com>

	* lra-constraints.c (curr_insn_transform): Handle
	WORD_REGISTER_OPERATIONS requirements when reloading SUBREGs.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lra-constraints.c

Author: mpf
Date: Wed Feb 22 17:20:14 2017
New Revision: 245655

URL: https://gcc.gnu.org/viewcvs?rev=245655&root=gcc&view=rev
Log:
Support WORD_REGISTER_OPERATIONS requirements in simplify_operand_subreg

gcc/
	PR target/78660
	* lra-constraints.c (simplify_operand_subreg): Handle
	WORD_REGISTER_OPERATIONS targets.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lra-constraints.c

Bootstrap now succeeds.