Bug building target libiberty for mips64vrel-elf toolchain

Bug building target libiberty for mips64vrel-elf toolchain

[Nick Clifton]

Hi Eric, Hi Richard,

  We recently ran across an ICE building a target libiberty for one of
  the multilibs of the mips64vrel-elf toolchain:

    .../libiberty/regex.c: In function 'byte_re_match_2_internal':
    .../libiberty/regex.c:7481: error: insn does not satisfy its constraints:
   (insn 5211 1697 1699 173 .../libiberty/regex.c:6589
   (set (reg:SI 5 $5)
        (lo_sum:SI (reg/f:SI 1104)
                   (symbol_ref:SI ("byte_reg_unset_dummy") [flags 0x6] <var_decl 0x2a9860bc60 byte_reg_unset_dummy>))) 204 {*lowsi_mips16} (nil)
        (expr_list:REG_EQUAL (symbol_ref:SI ("byte_reg_unset_dummy") [flags 0x6] <var_decl 0x2a9860bc60 byte_reg_unset_dummy>)
        (nil)))
    .../libiberty/regex.c:7481: internal compiler error: in reload_cse_simplify_operands, at postreload.c:393
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <URL:http://gcc.gnu.org/bugs.html> for instructions.
    make[3]: *** [regex.o] Error 1
    make[3]: Leaving directory `.../mips64vrel-elf/mips64vrel-elf/mips16/libiberty'

    
  This problem does not appear to affect other mips toolchains, but
  that may just be a multilib issue.  I found a simple workaround for
  the problem:

Index: gcc/config/mips/mips.c
===================================================================
--- gcc/config/mips/mips.c	(revision 123322)
+++ gcc/config/mips/mips.c	(working copy)
@@ -2269,8 +2269,11 @@ mips_legitimize_const_move (enum machine
   /* Split moves of symbolic constants into high/low pairs.  */
   if (splittable_symbolic_operand (src, mode))
     {
-      emit_insn (gen_rtx_SET (VOIDmode, dest, mips_split_symbol (dest, src)));
-      return;
+      if (! TARGET_MIPS16)
+	{
+	  emit_insn (gen_rtx_SET (VOIDmode, dest, mips_split_symbol (dest, src)));
+	  return;
+	}
     }
 
   if (mips_tls_operand_p (src))


  But I am pretty sure that this is the wrong solution.  Since I am
  not a MIPS expert however I am punting this problem to you guys. :-)

Cheers
  Nick

Re: Bug building target libiberty for mips64vrel-elf toolchain

[Richard Sandiford]

> Hi Eric, Hi Richard,
>
>   We recently ran across an ICE building a target libiberty for one of
>   the multilibs of the mips64vrel-elf toolchain:
>
>     .../libiberty/regex.c: In function 'byte_re_match_2_internal':
>     .../libiberty/regex.c:7481: error: insn does not satisfy its constraints:
>    (insn 5211 1697 1699 173 .../libiberty/regex.c:6589
>    (set (reg:SI 5 $5)
>         (lo_sum:SI (reg/f:SI 1104)
>                    (symbol_ref:SI ("byte_reg_unset_dummy") [flags 0x6] <var_decl 0x2a9860bc60 byte_reg_unset_dummy>))) 204 {*lowsi_mips16} (nil)
>         (expr_list:REG_EQUAL (symbol_ref:SI ("byte_reg_unset_dummy") [flags 0x6] <var_decl 0x2a9860bc60 byte_reg_unset_dummy>)
>         (nil)))
>     .../libiberty/regex.c:7481: internal compiler error: in reload_cse_simplify_operands, at postreload.c:393
>     Please submit a full bug report,
>     with preprocessed source if appropriate.
>     See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>     make[3]: *** [regex.o] Error 1
>     make[3]: Leaving directory `.../mips64vrel-elf/mips64vrel-elf/mips16/libiberty'
>
>     
>   This problem does not appear to affect other mips toolchains, but
>   that may just be a multilib issue.  I found a simple workaround for
>   the problem:
>
> Index: gcc/config/mips/mips.c
> ===================================================================
> --- gcc/config/mips/mips.c	(revision 123322)
> +++ gcc/config/mips/mips.c	(working copy)
> @@ -2269,8 +2269,11 @@ mips_legitimize_const_move (enum machine
>    /* Split moves of symbolic constants into high/low pairs.  */
>    if (splittable_symbolic_operand (src, mode))
>      {
> -      emit_insn (gen_rtx_SET (VOIDmode, dest, mips_split_symbol (dest, src)));
> -      return;
> +      if (! TARGET_MIPS16)
> +	{
> +	  emit_insn (gen_rtx_SET (VOIDmode, dest, mips_split_symbol (dest, src)));
> +	  return;
> +	}
>      }
>  
>    if (mips_tls_operand_p (src))
>
>
>   But I am pretty sure that this is the wrong solution.  Since I am
>   not a MIPS expert however I am punting this problem to you guys. :-)

Yeah, I'm afraid it's the wrong solution. ;)  It basically disables
small-data load-address operations on MIPS16.

I gather from the insn above that a use of the GP pseudo
register has been introduced during reload.  At first blush,
I think the fix is to make mips_split_symbol move
(const (unspec [(const_int 0)] UNSPEC_GP)) into "temp"
when no_new_pseudos.  I think the cleanest way to do that
would be to add a new define_expand to generate the move,
and adjust mips16_gp_pseudo_reg accordingly.

I might have time to try a fix this weekend.  Please feel free
to file a bug report and assign it to rsandifo@gcc.gnu.org.

Richard

Re: Bug building target libiberty for mips64vrel-elf toolchain

[Nick Clifton]

Hi Richard,


>>   But I am pretty sure that this is the wrong solution.  Since I am
>>   not a MIPS expert however I am punting this problem to you guys. :-)
> 
> Yeah, I'm afraid it's the wrong solution. ;)

Thought so :-)

> I gather from the insn above that a use of the GP pseudo
> register has been introduced during reload.  At first blush,
> I think the fix is to make mips_split_symbol move
> (const (unspec [(const_int 0)] UNSPEC_GP)) into "temp"
> when no_new_pseudos.

I tried doing this but I could not find a way to make it work. :-(  But 
then I am not as clued up on this stuff as you guys.

> I might have time to try a fix this weekend.  Please feel free
> to file a bug report and assign it to rsandifo@gcc.gnu.org.

I have created a PR (31388) but I do not have the authority to assign it 
you.

Cheers
   Nick