#1661 Fatal compiler internal error when using & with *

[David Grayson]

The following code fails to compile for me:

void a(unsigned char * b);
void main()
{
a(&(*(unsigned char *)0));
}

The code above is in a file called test.c (attached below). I invoked sdcc with the command `sdcc -c test.c`.

My sdcc -v is: SDCC : mcs51/gbz80/z80/ds390/pic16/pic14/TININative/ds400/hc08 2.9.7 #5891 (Jul 26 2010) (MINGW32)

I am running Windows Vista 64-bit, Service Pack 1.

The error message I get from SDCC is:

test.c:4: error 9: FATAL Compiler Internal Error in file '/home/sdcc-builder/build/sdcc-build/orig/sdcc/src/SDCCicode.c' line number '1401' : operandOperation invalid operator
Contact Author with source code
Assertion failed: 0, file /home/sdcc-builder/build/sdcc-build/orig/sdcc/src/SDCCicode.c, line 1403

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Caught signal 22: SIGABRT

The only workaround I know of is to remove the unary address (&) and dereference (*) operators.

P.S. Thank you for fixing the last bug I reported, I really appreciate it!

[David Grayson]

Test code that causes SDCC to exhibit the bug.

[Philipp Klaus Krause]

This problem probably lies in one of the earlier stages of sdcc. While we fail in operandOperation, which is called from cse in algebraic optimizations, disabling these optimizations justs results in problem occouring further down:
Internal error:
validateOpType failed in OP_SYMBOL(IC_LEFT (ic)) @ gen.c:7474: expected symbol, got value (for z80)
or
Internal error: validateOpType failed in OP_SYMBOL(IC_LEFT (ic)) @ gen.c:11433: expected symbol, got value (for mcs51)

Philipp

[Philipp Klaus Krause]

Well, it doesn't crash for me in sdcc 3.0.4 #6620.
It even seems to generate sensible code, even though that doesn't matter for your test case.

I suppose this got fixed some time since you last tested. Feel free to reopen this bug report if the bug still occours for you.

Philipp

[Anonymous]

Thank you for your attention to this. I can confirm that it looks like the bug was fixed.

SDCC 3.0.0 #6037 exhibits the bug.
SDCC 3.0.4 #6618 (Jul 9 2011) (MINGW32) does not exhibit the bug.