Internal Compiler Error in gen_rtx_SUBREG,at emit-rtl.c:776 in CR16

Internal Compiler Error in gen_rtx_SUBREG,at emit-rtl.c:776 in CR16

[Sumanth Gundapaneni]

Hi,

I have been working on port with variable register widths.
We have 12 16-bit registers and 4 32-bit registers.
Registers r0 - r11 are 16-b wide and can be paired to form a 32-b register.
Registers r12,r13,r14 and r15 are 32-bit wide and out of which 
r12 - argument pointer register.
r13 - frame pointer register.
r14 - return address register.
r15 - stack pointer register. 

I faced a regression in gcc-torture test case "20070905-1.c"
when I compile the code with -O2 or higher the test case fails
with "internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:776"

After analyzing the rtl dump, I figured out that below mentioned dump is the 
reason for the failure.
(insn 46 14 47 4 20070905-1.c:17 (set (reg:HI 3 r3)
        (subreg:HI (reg/f:SI 13 r13) 0)) 64 {*movhi_short} (nil))

(insn 47 46 18 4 20070905-1.c:17 (set (reg:HI 4 r4 [+2 ])
        (subreg:HI (reg/f:SI 13 r13) 2)) 64 {*movhi_short} (nil))

The insn  47 with subreg byte value of 2 causes the ICE in 
function gen_rtx_SUBREG.
" gcc_assert (validate_subreg (mode, GET_MODE (reg), reg, offset)); "

You can find the current implementation of cr16 at the following link
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00803.html

In addition to the patch I have made couple of changes suggested by 
Richard Henderson. http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01008.html

One among them is :: 
#define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS)       \
  (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO)           \
   ? reg_classes_intersect_p (LONG_REGS, (CLASS))        \
   : 0)
>> LONG_REGS are 32-bit registers

Please let me know if you need further information.
Your help in this regard is highly appreciated.

Thanks and Regards,
Sumanth G

 

Re: Internal Compiler Error in gen_rtx_SUBREG,at emit-rtl.c:776 in CR16

[Ian Lance Taylor]

Sumanth Gundapaneni <Sumanth.Gundapaneni@kpitcummins.com> writes:

> After analyzing the rtl dump, I figured out that below mentioned dump is the 
> reason for the failure.
> (insn 46 14 47 4 20070905-1.c:17 (set (reg:HI 3 r3)
>         (subreg:HI (reg/f:SI 13 r13) 0)) 64 {*movhi_short} (nil))
>
> (insn 47 46 18 4 20070905-1.c:17 (set (reg:HI 4 r4 [+2 ])
>         (subreg:HI (reg/f:SI 13 r13) 2)) 64 {*movhi_short} (nil))

You need to find out what is generating that insn.  It looks like it can
not work on your hardware.  You need to fix whatever is generating it to
do something different.

Ian

RE: Internal Compiler Error in gen_rtx_SUBREG,at emit-rtl.c:776 in CR16

[Sumanth Gundapaneni]

Hi Ian,

>You need to find out what is generating that insn.  It looks like it can
>not work on your hardware.  You need to fix whatever is generating it to
>do something different.

Thanks for the pointer. 
If I compile the test case with "-O2 -fno-inline", there was no ICE related
to subreg. Is "cse_local" phase related to -finline optimization. My initial 
patch has a hack for this at backend files by modifying the standard predicate 
definitions.  

(define_predicate "reg_operand"
 (match_operand 0 "register_operand")
 {
	if(GET_CODE(op) == SUBREG
		&& (REGNO(SUBREG_REG(op)) > 11
		&& REGNO(SUBREG_REG(op)) < FIRST_PSEUDO_REGISTER)
		&& SUBREG_BYTE(op) != 0)
	return 0;    
	return 1;
 }
)     

Though this hack removes the ICEs related to subregs , it effects the output 
of applications compiled with the tool chain in 1 out of 100 test cases.


Thanks and Regards,
Sumanth G

Re: Internal Compiler Error in gen_rtx_SUBREG,at emit-rtl.c:776 in CR16

[Ian Lance Taylor]

Sumanth Gundapaneni <Sumanth.Gundapaneni@kpitcummins.com> writes:

> If I compile the test case with "-O2 -fno-inline", there was no ICE related
> to subreg. Is "cse_local" phase related to -finline optimization.

Any RTL that can be created by inlining can also be created in other
ways, so don't wory about inlining.  You need to find out specifically
what is creating that insn.  I usually find it easiest to set a
breakpoint on make_insn_raw with a breakpoint on cur_insn_uid (which is
a macro, so you have to use the real expression) to find when the insn
with a specific UID was created.

Ian

Re: Internal Compiler Error in gen_rtx_SUBREG,at emit-rtl.c:776 in CR16

[Jeff Law]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/01/11 08:19, Ian Lance Taylor wrote:
> Sumanth Gundapaneni <Sumanth.Gundapaneni@kpitcummins.com> writes:
> 
>> If I compile the test case with "-O2 -fno-inline", there was no ICE related
>> to subreg. Is "cse_local" phase related to -finline optimization.
> 
> Any RTL that can be created by inlining can also be created in other
> ways, so don't wory about inlining.  You need to find out specifically
> what is creating that insn.  I usually find it easiest to set a
> breakpoint on make_insn_raw with a breakpoint on cur_insn_uid (which is
> a macro, so you have to use the real expression) to find when the insn
> with a specific UID was created.
Tip: Place the breakpoint after the assignment:


  INSN_UID (insn) = cur_insn_uid++;

And you don't have to know the "cur_insn_uid" magic...

b <line> if insn.u.fld[0].rt_int == <some #>

Breakpoints on an insn's UID become second nature quickly if you do a
lot of RTL debugging.

jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNSCUxAAoJEBRtltQi2kC7HJ0H/3X671YfS5DYy8ZtXFLJYy01
XiSPJRBHvlNCkIkUmogd/SvxoOyiIuLuH6+D267j+ikIVo/f1O5zE3ExdZIdu6CX
63gArkDInqr2darDtmX8cytVupJ55fkgsMgzZui153QAaXP7O/PzW8z4iyzbjT+u
GVaglb44+AbBz+NszWiExI8IVydub6C+G1OaqwQoQ5tYSvMxrxs7QJO6KmIzMgcG
0s0M7pRncq1HqydLGclLxbmdB7DzYkJmG81xJs5vbqypkjhTvGTYYXUvBblDwOy9
bhG7N0Bx1kOHF2woNSF0GyGGDWr8AD1z1myL38vwsnI6+ToZZAdCHsU68krifBU=
=cpR1
-----END PGP SIGNATURE-----

RE: Internal Compiler Error in gen_rtx_SUBREG,at emit-rtl.c:776 in CR16

[Sumanth Gundapaneni]

Hi Ian & Jeff,

>> Any RTL that can be created by inlining can also be created in other
>> ways, so don't wory about inlining.  You need to find out specifically
>> what is creating that insn.  I usually find it easiest to set a
>> breakpoint on make_insn_raw with a breakpoint on cur_insn_uid (which is
>> a macro, so you have to use the real expression) to find when the insn
>> with a specific UID was created.
>Tip: Place the breakpoint after the assignment:


 
> INSN_UID (insn) = cur_insn_uid++;

>And you don't have to know the "cur_insn_uid" magic...

>b <line> if insn.u.fld[0].rt_int == <some #>

>Breakpoints on an insn's UID become second nature quickly if you do a
>lot of RTL debugging.


		Thanks for sharing the debugging technique. 
I was able to isolate the error with the breakpoint at "make_raw_insn" 
and successfully resolved couple of issues and I believe all the issues 
related to subreg are resolved.

However below mentioned is one of the test case that I was not able to 
resolve.

struct test{
int ia;
char ca;
float fa;
};

int main()
{
        struct test testinst = {23, 'c', 12.34};

        return (int) &testinst;
}

Whenever a function returns a 32-bit address, the compiler crashes with
internal compiler error: in instantiate_virtual_regs_in_insn, at function.c:1600
The rtl dump  for return value "(insn 21 18 0 5 test.c:12 (use (reg/i:HI 0 r0)) -1 (nil))"
which I believe should be SImode.

The related macro definitions are 
#define FUNCTION_VALUE(VALTYPE, FUNC) \
    gen_rtx_REG (TYPE_MODE (VALTYPE), 0)

#define LIBCALL_VALUE(MODE)     gen_rtx_REG (MODE, 0)

#define FUNCTION_VALUE_REGNO_P(N)   ((N) == 0)

#define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS)       \
  ( (GET_MODE_SIZE (TO) < GET_MODE_SIZE (FROM))          \
   ? 1        \
   : 0)

#undef  TARGET_STRUCT_VALUE_RTX
#define TARGET_STRUCT_VALUE_RTX     cr16_struct_value_rt

static rtx
cr16_struct_value_rtx (tree fntype ATTRIBUTE_UNUSED,
                       int incoming ATTRIBUTE_UNUSED)
{
  return gen_rtx_REG (Pmode, 0);
}
 
 
Can you point me where I went wrong ?

Thanks and Regards,
Sumanth G		

Re: Internal Compiler Error in gen_rtx_SUBREG,at emit-rtl.c:776 in CR16

[Ian Lance Taylor]

Sumanth Gundapaneni <Sumanth.Gundapaneni@kpitcummins.com> writes:

> However below mentioned is one of the test case that I was not able to 
> resolve.
>
> struct test{
> int ia;
> char ca;
> float fa;
> };
>
> int main()
> {
>         struct test testinst = {23, 'c', 12.34};
>
>         return (int) &testinst;
> }
>
> Whenever a function returns a 32-bit address, the compiler crashes with
> internal compiler error: in instantiate_virtual_regs_in_insn, at function.c:1600

Line numbers don't help since our sources are not precisely the same as
your sources.  In the future please show us a few lines around the point
you are describing.

> The rtl dump  for return value "(insn 21 18 0 5 test.c:12 (use (reg/i:HI 0 r0)) -1 (nil))"
> which I believe should be SImode.

I don't know what the problem is but I think you should look at
PROMOTE_MODE and TARGET_PROMOTE_PROTOTYPES.

Ian

Re: Internal Compiler Error in gen_rtx_SUBREG,at emit-rtl.c:776 in CR16

[Richard Henderson]

On 02/04/2011 04:47 AM, Sumanth Gundapaneni wrote:
> #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS)       \
>   ( (GET_MODE_SIZE (TO) < GET_MODE_SIZE (FROM))          \
>    ? 1        \
>    : 0)

Cannot change modes for any class is almost certainly wrong.


r~