GCC fails with -O2 for own Target

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


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,
   jump = 0,
   call = 0,
   unchanging = 0,
   volatil = 0,
   in_struct = 0,
   used = 0,
   frame_related = 0,
   return_val = 0,
   u = {
     fld = {{
         rt_int = 1089498632,
         rt_uint = 1089498632,
         rt_str = 0x140f06e08 "sbox",
         rt_rtx = 0x140f06e08,
         rt_rtvec = 0x140f06e08,
         rt_type = 1089498632,
         rt_addr_diff_vec_flags = {
           min_align = 8,
           base_after_vec = 0,
           min_after_vec = 1,
           max_after_vec = 1,
           min_after_base = 1,
           max_after_base = 0,
           offset_unsigned = 1,
           scale = 240
         },
         rt_cselib = 0x140f06e08,
         rt_bit = 0x140f06e08,
         rt_tree = 0x140f06e08,
         rt_bb = 0x140f06e08,
         rt_mem = 0x140f06e08,
         rt_reg = 0x140f06e08,
         rt_constant = 0x140f06e08
       }},
     hwint = {5384465928},
     block_sym = {
       fld = {{
           rt_int = 1089498632,
           rt_uint = 1089498632,
           rt_str = 0x140f06e08 "sbox",
           rt_rtx = 0x140f06e08,
           rt_rtvec = 0x140f06e08,
           rt_type = 1089498632,
           rt_addr_diff_vec_flags = {
             min_align = 8,
             base_after_vec = 0,
             min_after_vec = 1,
             max_after_vec = 1,
             min_after_base = 1,
             max_after_base = 0,
             offset_unsigned = 1,
             scale = 240
           },
           rt_cselib = 0x140f06e08,
           rt_bit = 0x140f06e08,
           rt_tree = 0x140f06e08,
           rt_bb = 0x140f06e08,
           rt_mem = 0x140f06e08,
           rt_reg = 0x140f06e08,
           rt_constant = 0x140f06e08
         }, {
           rt_int = 2,
           rt_uint = 2,
           rt_str = 0x2 <Address 0x2 out of bounds>,
           rt_rtx = 0x2,
           rt_rtvec = 0x2,
           rt_type = CCmode,
           rt_addr_diff_vec_flags = {
             min_align = 2,
             base_after_vec = 0,
             min_after_vec = 0,
             max_after_vec = 0,
             min_after_base = 0,
             max_after_base = 0,
             offset_unsigned = 0,
             scale = 0
           },
           rt_cselib = 0x2,
           rt_bit = 0x2,
           rt_tree = 0x2,
           rt_bb = 0x2,
           rt_mem = 0x2,
           rt_reg = 0x2,
           rt_constant = 0x2
         }, {
           rt_int = 1090375680,
           rt_uint = 1090375680,
           rt_str = 0x140fdd000 " ",
           rt_rtx = 0x140fdd000,
           rt_rtvec = 0x140fdd000,
           rt_type = 1090375680,
           rt_addr_diff_vec_flags = {
             min_align = 0,
             base_after_vec = 0,
             min_after_vec = 0,
             max_after_vec = 0,
             min_after_base = 0,
             max_after_base = 1,
             offset_unsigned = 0,
             scale = 253
           },
           rt_cselib = 0x140fdd000,
           rt_bit = 0x140fdd000,
           rt_tree = 0x140fdd000,
           rt_bb = 0x140fdd000,
           rt_mem = 0x140fdd000,
           rt_reg = 0x140fdd000,
           rt_constant = 0x140fdd000
         }},
       block = 0x40025,
       offset = 81
     },
     rv = {
       cl = 0,
       decimal = 0,
       sign = 1,
       signalling = 0,
       canonical = 0,
       uexp = 17023416,
       sig = {2, 5385342976, 262181}
     },
     fv = {
       data = {
         low = 5384465928,
         high = 2
       },
       mode = 1090375680
     }
   }
}

Am 25.07.13 06:11, schrieb Ian Lance Taylor:
> 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.
>> Until today I never actually tried optimization passes (maybe that was the
>> mistake that lead to this)
>> Anyway:
>> During porting and building Newlib I ran into an error that I tracked down
>> to the following code:
>>
>> unsigned char hexdig[256];
>>
>> static void htinit ( unsigned char *h , unsigned char *s , int inc)
>> {
>>      int i, j;
>>      for(i = 0; (j = s[i]) !=0; i++)
>>          h[j] = i + inc;
>> }
>>
>> void
>> hexdig_init ()
>> {
>>      htinit(hexdig, (unsigned char *) "0123456789", 0x10);
>>      htinit(hexdig, (unsigned char *) "abcdef", 0x10 + 10);
>>      htinit(hexdig, (unsigned char *) "ABCDEF", 0x10 + 10);
>> }
>>
>> Compiling this code without optimization works like a charm, however
>> compiling it with -O2 leads to the following error:
>> test1.c: In function 'hexdig_init':
>> test1.c:11:1: internal compiler error: in gen_lowpart_general, at
>> rtlhooks.c:59
>>
>> Tried with:
>> eco32-gcc -O2 -S test1.c
>>
>> My question in short is:
>> Could this be a targe- backend-error or just some configuration I have
>> missed while building GCC?
> It is most likely an error in your backend.  The first step is to
> break out the debugger and find out why that function is being called
> with something that is not a MEM.  You may want to look at
> http://gcc.gnu.org/wiki/DebuggingGCC .
>
> Ian



More information about the Gcc-help mailing list