This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
RE: Internal Compiler Error in gen_rtx_SUBREG,at emit-rtl.c:776 in CR16
- From: Sumanth Gundapaneni <Sumanth dot Gundapaneni at kpitcummins dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>, "rth at redhat dot com" <rth at redhat dot com>, "Jayant R. Sonar" <Jayant dot Sonar at kpitcummins dot com>
- Date: Tue, 1 Feb 2011 14:38:33 +0530
- Subject: RE: Internal Compiler Error in gen_rtx_SUBREG,at emit-rtl.c:776 in CR16
- References: <371569CBCFB2E745B891DBB88B2DFDDD19FA64F721@KCINPUNHJCMS01.kpit.com> <mcrlj20khji.fsf@google.com>
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