GCC fails with -O2 for own Target

Jens Mehler jens.mehler@mni.thm.de
Wed Jul 31 21:17:00 GMT 2013


Hi jasonwucj,

the port to a never Version is highly unlikely because this compiler is 
needed as a dependency in another project.
I have already tested the same source with another port (it works)
And I really doubt that such a simple program would actually cause a bug 
nowadays :)

Thanks for the hint with debug:
(symbol_ref:SI ("sbox") [flags 0x2] <var_decl 0x140fdd000 sbox>)

It's the array like the other dump said still I would like to see the 
complete insn.

With best regards
Jens

Am 31.07.13 16:58, schrieb Chung-Ju Wu:
> 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@mni.thm.de> 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
>
>



More information about the Gcc-help mailing list