Hello, can anyone say if this is an sdcc compiler bug or another case 
where gcc follows a different "standard" than sdcc?

The internal error occurs do to:

extern uint8_t * const uip_buf;


If I take away the "const"  the issue goes away.

Anthony Asterisk wrote:
> The issue seems to be with the declaration "uint8_t * const uip_buf"
>
> Anthony Asterisk wrote:
>> I narrowed it down to a testcase.
>>
>> This problem occurs when using the #5718 Feb 26 2010 release of 
>> sdcc.  It does not occur with #4818 (Jan 18 2008).
>> I have not tested more recent versions.
>>
>> #include <string.h>
>> #include <stdint.h>
>> #define UIP_LLH_LEN 0
>> #define UIP_IP_BUF                          ((struct uip_ip_hdr 
>> *)&uip_buf[UIP_LLH_LEN])
>> #define UIP_BUFSIZE 126
>> extern uint8_t * const uip_buf;
>> static uint32_t uip_buf32[(UIP_BUFSIZE + 3) / 4];
>> uint8_t * const uip_buf = (uint8_t * const) uip_buf32;
>> typedef union uip_ip6addr_t {
>>   uint8_t  u8[16];
>>   uint16_t u16[8];
>> } uip_ip6addr_t;
>> struct uip_ip_hdr {
>>   /* IPV6 header */
>>   uint8_t vtc;
>>   uint8_t tcflow;
>>   uint16_t flow;
>>   uint8_t len[2];
>>   uint8_t proto, ttl;
>>   uip_ip6addr_t srcipaddr, destipaddr;
>> };
>> void
>> uip_process(uint8_t flag)
>> {
>>   UIP_IP_BUF->flow = 0x00;
>>   return;
>> }
>>  main (void)
>> {
>>   uip_process(0);
>>   return 0;
>> }
>>
>>
>>
>> ~/sdcc_bug5$ sdcc -v
>> SDCC : mcs51 2.9.7 #5718 (Feb 26 2010) (UNIX)
>> ~/sdcc_bug5$ sdcc  main.c
>> main.c:26: error 9: FATAL Compiler Internal Error in file 'gen.c' 
>> line number '11208' : genPointerSet: illegal pointer type
>> Contact Author with source code
>> main.c:26: warning 85: in function uip_process unreferenced function 
>> argument : 'flag'
>>
>>
>>
>> Anthony Asterisk wrote:
>>> I got a new error I haven't seen before:
>>>
>>> ../../core/net/uip6.c:2202: error 9: FATAL Compiler Internal Error 
>>> in file 'gen.c' line number '11208' : genPointerSet: illegal pointer 
>>> type
>>> Contact Author with source code
>>>
>>> I want to prepare a testcase, however the line mentioned is the last 
>>> line in a 1400 line procedure.  Since its rather large I'm wondering 
>>> if there is anyway to narrow down the type of problem I am looking for.
>>>
>>> Any advice?
>>>
>>> a* 


------------------------------------------------------------------------------

_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Reply via email to