VOIDmode in ZERO_EXTEND crashed

VOIDmode in ZERO_EXTEND crashed

[daniel tian]

hi, everyone:
     I have ported the gcc to new RISC chip. But when I build the
newlib with it, the gcc crashed in simplify-rtx.c.
     error message is like this:

     ../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c: In
function _tzset_r?
     ../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c:195:
internal compiler error: in simplify_const_unary_operation, at
simplify-rtx.c:1108

     And the code there is simplify-rtx.c 1108:

     case ZERO_EXTEND:
	  /* When zero-extending a CONST_INT, we need to know its
             original mode.  */
	  gcc_assert (op_mode != VOIDmode);

     I tracked the gcc, It caused by the RTX   (const_int 60). As I
know the CONST_INT is alway being VOIDmode.
     I dumped the rtl tzset_r.c.161r.dce, and I think it caused by the
following rtx(because the there is const_int 60 in this rtx and the
register used is exactly what I saw in rtx which causes the gcc
crash):

      (insn 229 228 230 21
../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c:78 (set
(reg:SI 181)
        (mult:SI (zero_extend:SI (reg:HI 182 [ mm ]))
            (zero_extend:SI (const_int 60 [0x3c])))) 63
{rice_umulhisi3} (expr_list:REG_DEAD (reg:HI 182 [ mm ])
        (nil)))

    And the problem is I don't know why it lead crashing.
    PS: Does gcc have a function which could dump the specified rtx? I
wanna dump the rtx when the crash happening.

    Can somebody give me some advice?
    Any suggestion is appreciated.

    Thanks.

                  daniel.

RE: VOIDmode in ZERO_EXTEND crashed

[Jon Beniston]

> PS: Does gcc have a function which could dump the specified rtx? 
> I wanna dump the rtx when the crash happening.

debug_rtx(x);

You can also call this from within GDB, by typing:

call debug_rtx(x)

Cheers,
Jon

Re: VOIDmode in ZERO_EXTEND crashed

[daniel tian]

2009/10/12 Jon Beniston <jon@beniston.com>:
>> PS: Does gcc have a function which could dump the specified rtx?
>> I wanna dump the rtx when the crash happening.
>
> debug_rtx(x);
>
> You can also call this from within GDB, by typing:
>
> call debug_rtx(x)
>
> Cheers,
> Jon
>
Thanks.

I dump the context. Here it is:

(mult:SI (zero_extend:SI (mem/c/i:HI (plus:SI (reg/f:SI 14 R14)
                (const_int 46 [0x2e])) [8 mm+0 S2 A16]))
		    (zero_extend:SI (const_int 60 [0x3c])))


 (zero_extend:SI (const_int 60 [0x3c])) makes the gcc crash. It is
exactly the rtx mentioned in first email:

(insn 228 227 229 21
../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c:78 (set
(reg:HI 182 [ mm ])
        (mem/c/i:HI (plus:SI (reg/f:SI 14 R14)
                (const_int 46 [0x2e])) [8 mm+0 S2 A16])) 10 {load_hi} (nil))

(insn 229 228 230 21
../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c:78 (set
(reg:SI 181)
        (mult:SI (zero_extend:SI (reg:HI 182 [ mm ]))
            (zero_extend:SI (const_int 60 [0x3c])))) 63
{rice_umulhisi3} (expr_list:REG_DEAD (reg:HI 182 [ mm ])
        (nil)))

You can see gcc just merged the two insn.
But problem is HOW I could avoid this error.

Thanks.

                                                 daniel

Re: VOIDmode in ZERO_EXTEND crashed

[Joern Rennecke]

Quoting daniel tian <daniel.xntian@gmail.com>:

> hi, everyone:
>      I have ported the gcc to new RISC chip. But when I build the
> newlib with it, the gcc crashed in simplify-rtx.c.
>      error message is like this:
>
>      ../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c: In
> function _tzset_r?
>      ../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c:195:
> internal compiler error: in simplify_const_unary_operation, at
> simplify-rtx.c:1108
>
>      And the code there is simplify-rtx.c 1108:
>
>      case ZERO_EXTEND:
> 	  /* When zero-extending a CONST_INT, we need to know its
>              original mode.  */
> 	  gcc_assert (op_mode != VOIDmode);
>
>      I tracked the gcc, It caused by the RTX   (const_int 60). As I
> know the CONST_INT is alway being VOIDmode.

That exactly is the problem.  You can't have a CONST_INT inside a
ZERO_EXTEND.  That is not valid.
You'll need a separate pattern to recognize the CONST_INT without a
ZERO_EXTEND around it.  Unfortunately, this will not give reload
the freedom it should have.

Re: VOIDmode in ZERO_EXTEND crashed

[daniel tian]

2009/10/12 Joern Rennecke <joern.rennecke@embecosm.com>:
> Quoting daniel tian <daniel.xntian@gmail.com>:
>
>> hi, everyone:
>>     I have ported the gcc to new RISC chip. But when I build the
>> newlib with it, the gcc crashed in simplify-rtx.c.
>>     error message is like this:
>>
>>     ../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c: In
>> function _tzset_r?
>>     ../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c:195:
>> internal compiler error: in simplify_const_unary_operation, at
>> simplify-rtx.c:1108
>>
>>     And the code there is simplify-rtx.c 1108:
>>
>>     case ZERO_EXTEND:
>>          /* When zero-extending a CONST_INT, we need to know its
>>             original mode.  */
>>          gcc_assert (op_mode != VOIDmode);
>>
>>     I tracked the gcc, It caused by the RTX   (const_int 60). As I
>> know the CONST_INT is alway being VOIDmode.
>
> That exactly is the problem.  You can't have a CONST_INT inside a
> ZERO_EXTEND.  That is not valid.
> You'll need a separate pattern to recognize the CONST_INT without a
> ZERO_EXTEND around it.  Unfortunately, this will not give reload
> the freedom it should have.
>


You mean I should remove the const_int (by predicator) in umulhisi3 pattern?
I mean if I remove it,  how to deal with the "reg = const_int * reg"
in umulhisi3 pattern.

Thank you very much.
                                                                     daniel.

Re: VOIDmode in ZERO_EXTEND crashed

[Paolo Bonzini]

>> That exactly is the problem.  You can't have a CONST_INT inside a
>> ZERO_EXTEND.  That is not valid.
>> You'll need a separate pattern to recognize the CONST_INT without a
>> ZERO_EXTEND around it.  Unfortunately, this will not give reload
>> the freedom it should have.
>>
>
>
> You mean I should remove the const_int (by predicator) in umulhisi3 pattern?
> I mean if I remove it,  how to deal with the "reg = const_int * reg"
> in umulhisi3 pattern.

You follow these steps:

1) rename the existing pattern to something else than umulhisi3, and 
make it only accept register_operands

2) create another insn that matches (mult (zero_extend (match_operand 
"register_operand") (const_int))

3) create a define_expand that checks for a CONST_INT and does not wrap 
it (but wraps REGs and SUBREGs and if applicable MEMs).

This is in general how you deal with too-forgiving predicates during 
expansion.

Paolo

Re: VOIDmode in ZERO_EXTEND crashed

[daniel tian]

2009/10/12 Paolo Bonzini <bonzini@gnu.org>:
>
>>> That exactly is the problem.  You can't have a CONST_INT inside a
>>> ZERO_EXTEND.  That is not valid.
>>> You'll need a separate pattern to recognize the CONST_INT without a
>>> ZERO_EXTEND around it.  Unfortunately, this will not give reload
>>> the freedom it should have.
>>>
>>
>>
>> You mean I should remove the const_int (by predicator) in umulhisi3
>> pattern?
>> I mean if I remove it,  how to deal with the "reg = const_int * reg"
>> in umulhisi3 pattern.
>
> You follow these steps:
>
> 1) rename the existing pattern to something else than umulhisi3, and make it
> only accept register_operands
>
> 2) create another insn that matches (mult (zero_extend (match_operand
> "register_operand") (const_int))
>
> 3) create a define_expand that checks for a CONST_INT and does not wrap it
> (but wraps REGs and SUBREGs and if applicable MEMs).
>
> This is in general how you deal with too-forgiving predicates during
> expansion.
>
> Paolo
>

It sounds good point. I will try it first
I  would like to accepted only register and force all const_int
operand into register first.
Obviously, this may generate low efficiency code compared with your solution.

I still can't get a clear mind with step3. I may need take a while to
think about it.
I am a newcomer. :)

Thanks for your guys advice.
Best wishes.
                                                                    daniel.