GCC fails with -O2 for own Target

Jens Mehler jens.mehler@mni.thm.de
Mon Jul 29 14:53:00 GMT 2013


After debugging and doing some research I got the following result:
The RTX code is CONST therefore the assertion failure.
On the other hand:
After turning of function inlining it worked like a charm.
At this point I can't explain why and how that all works together.
Do you see any relation to the inlining and how it is affected by the 
targets backend?

For the time beeing I will disable function inlining in my target ;)

Jens


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