public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* Bug building target libiberty for mips64vrel-elf toolchain
@ 2007-03-29 6:55 Nick Clifton
2007-03-29 7:05 ` Richard Sandiford
0 siblings, 1 reply; 3+ messages in thread
From: Nick Clifton @ 2007-03-29 6:55 UTC (permalink / raw)
To: echristo, richard; +Cc: gcc-bugs
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Bug building target libiberty for mips64vrel-elf toolchain
2007-03-29 6:55 Bug building target libiberty for mips64vrel-elf toolchain Nick Clifton
@ 2007-03-29 7:05 ` Richard Sandiford
2007-03-29 9:38 ` Nick Clifton
0 siblings, 1 reply; 3+ messages in thread
From: Richard Sandiford @ 2007-03-29 7:05 UTC (permalink / raw)
To: Nick Clifton; +Cc: echristo, gcc-bugs
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Bug building target libiberty for mips64vrel-elf toolchain
2007-03-29 7:05 ` Richard Sandiford
@ 2007-03-29 9:38 ` Nick Clifton
0 siblings, 0 replies; 3+ messages in thread
From: Nick Clifton @ 2007-03-29 9:38 UTC (permalink / raw)
To: Nick Clifton, echristo, gcc-bugs, richard
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-03-29 9:38 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-29 6:55 Bug building target libiberty for mips64vrel-elf toolchain Nick Clifton
2007-03-29 7:05 ` Richard Sandiford
2007-03-29 9:38 ` Nick Clifton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).