Re: Bug building target libiberty for mips64vrel-elf toolchain

2007-03-29 Thread 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 [EMAIL PROTECTED]

Richard

Re: Bug building target libiberty for mips64vrel-elf toolchain

2007-03-29 Thread 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 [EMAIL PROTECTED]


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


Cheers
  Nick

Bug building target libiberty for mips64vrel-elf toolchain

2007-03-28 Thread 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