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

2017-03-07 Thread mpf at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660

mpf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #21 from mpf at gcc dot gnu.org ---
Bootstrap now succeeds.

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

2017-02-22 Thread mpf at gcc dot gnu.org 
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

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

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

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

2017-02-21 Thread mpf at gcc dot gnu.org 
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:
2017-02-20  Matthew Fortune  

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

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

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

2017-02-20 Thread mpf at gcc dot gnu.org 
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/
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

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

2017-02-20 Thread mpf at gcc dot gnu.org 
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

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

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

2017-01-16 Thread mpf at gcc dot gnu.org 
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
>  /* 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!

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

2017-01-16 Thread ebotcazou at gcc dot gnu.org 
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 ] [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));

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

2017-01-16 Thread ebotcazou at gcc dot gnu.org 
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 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?

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

2017-01-16 Thread mpf at gcc dot gnu.org 
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.)

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

2017-01-16 Thread ebotcazou at gcc dot gnu.org 
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)
(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?

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

2017-01-14 Thread ebotcazou at gcc dot gnu.org 
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 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.

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

2017-01-13 Thread mpf at gcc dot gnu.org 
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 |ASSIGNED
 CC||mpf at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpf at gcc dot gnu.org
   Severity|normal  |major

--- Comment #10 from mpf at gcc dot gnu.org ---
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.

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

2017-01-13 Thread matthew.fortune at imgtec dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660

Matthew Fortune  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #9 from Matthew Fortune  ---
@eric: adding you following our discussion on PR rtl-optimization/59461

I have added my findings so far on this ticket.

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

2017-01-13 Thread matthew.fortune at imgtec dot com 
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 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 i358: 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 i358: 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.

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

2016-12-22 Thread syq at debian dot org 
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
> ===
> --- 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.

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

2016-12-22 Thread syq at debian dot org 
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 YunQiang Su  ---
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;
 }

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

2016-12-20 Thread paul.hua.gm at gmail dot com 
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 should patched the r242522.

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

2016-12-20 Thread paul.hua.gm at gmail dot com 
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
-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  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  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.

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

2016-12-20 Thread matthew.fortune at imgtec dot com 
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 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)

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

2016-12-20 Thread aldyh at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-12-20
 Ever confirmed|0   |1

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

2016-12-20 Thread aldyh at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||clm at codesourcery dot com,
   ||matthew.fortune at imgtec dot 
com

--- Comment #2 from Aldy Hernandez  ---
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?

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

2016-12-11 Thread paul.hua.gm at gmail dot com 
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.

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

2016-12-11 Thread pinskia at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build, wrong-code
 Target||mips64el-unkown-linux
  Component|bootstrap   |target
   Target Milestone|--- |7.0
Summary|7.0 bootstrap fail on   |[7 Regression] 7.0
   |mips64el-unknow-linux:  |bootstrap fail on
   |configure-stage2-target-lib |mips64el-unknow-linux:
   |gcc' failed |configure-stage2-target-lib
   ||gcc' failed