VOIDmode in ZERO_EXTEND crashed

View: New views
5 Messages — Rating Filter:   Alert me  

VOIDmode in ZERO_EXTEND crashed

by daniel tian :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

by Jon Beniston-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> 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

by daniel tian :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

2009/10/12 Jon Beniston <jon@...>:

>> 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

by Joern Rennecke-5 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

> 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

by daniel tian :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

2009/10/12 Joern Rennecke <joern.rennecke@...>:

> Quoting daniel tian <daniel.xntian@...>:
>
>> 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.