On 7/31/13 8:35 PM, Jens Mehler wrote:
> After testing around I came up with a much easier example to reproduce my error:
>
> static unsigned char sbox[256];
>
> void
> test(void)
> {
> int n;
> for (n = 0; n < 256; n++)
> sbox[n] = (unsigned char) n;
> }
>
> This results in the same error massage:
> test3.c: In function 'test':
> test3.c:4:1: internal compiler error: in gen_lowpart_general, at rtlhooks.c:59
>
> Via GDB I was able to print the RTX in question:
> As you can see the code is SYMBOL_REF and therefore the error.
> I am not really sure how to track that any futher.
>
> With best regards
> Jens
> -----
>
> Breakpoint 2, gen_lowpart_general (mode=QImode, x=0x140fd2f80) at ../../gcc-4.5.3/gcc/rtlhooks.c:41
> 41 {
> (gdb) p *x
> $4 = {
> code = SYMBOL_REF,
> mode = SImode,
[...]
> }
> }
>
Hi, Jens,
You can use "call debug_rtx(x)" to display readable rtx information.
According to your investigation, the assertion failure is caused by
unexpected rtx in gen_lowpart_general. Your next step is to figure
out how come such rtx is produced and passed into gen_lowpart_general.
I also suggest using -fdump-rtl-all to assist you tracing which phases
and what backend rtl patterns create the unexpected rtx.
>> On Wed, Jul 24, 2013 at 6:38 PM, Jens Mehler <jens.mehler@xxxxxxxxxx> wrote:
>>> I have ported the GCC (v4.5.3) to a new target (32-bit RISC processor).
>>> So far everything went fine. I wrote my own little C-Lib with basic input
>>> output and tested it worked.
The GCC 4.5.3 is no longer maintained.
I think you can also try your port on 4.7, 4.8, or current trunk.
If it is indeed a bug in GCC, that would be nice to file a bug
on GCC bugzilla or provide a patch on gcc-patches mailing list.
Best regards,
jasonwucj
