Help save net neutrality! Learn more.
Close

#657 error: FATAL Compiler Internal Error in file 'SDCCicode.c'

closed-fixed
5
2013-05-25
2003-12-10
Evan Jones
No

When I compile the attached .c file with the following
command, I get the following errors:

sdcc --model-small --xram-loc 0x0ABC --data-loc 0x150 -c
ledtest.c
ledtest.c:329: error: FATAL Compiler Internal Error in file
'SDCCicode.c' line number '2612' : code generator internal
error
Contact Author with source code
Internal error: validateLink failed in DCL_TYPE(ptr) @
SDCCicode.c:2560: expected DECLARATOR, got SPECIFIER

I am using the latest daily build for Mac OS X on PowerPC:

SDCC : mcs51/gbz80/z80/avr/ds390/pic14/pic16/
TININative/xa51/ds400/hc08 2.3.6 (12/08/03) (UNIX)

The errors are on lines that look like this:

IN0BUF[0] = ((xdata char *)(&OUT1CS))[2*(tmp-1)];

If I remove the cast, it compiles fine.

Thank you for the great software, and for any assistance
you can provide.

Discussion

  • Evan Jones

    Evan Jones - 2003-12-10

    .c file that causes fatal error

     
  • Erik Petrich

    Erik Petrich - 2003-12-11

    Logged In: YES
    user_id=635249

    Could you upload your regezusb.h, or at least give the
    declaration for OUT1CS? If I use an include file that I
    wrote for EZ-USB FX, which has the declaration

    xdata at 0x7FC6 volatile unsigned char OUT1CS;

    it does not crash.

    Thanks

     
  • Evan Jones

    Evan Jones - 2003-12-11

    EZ-USB AN2131SC header file

     
  • Evan Jones

    Evan Jones - 2003-12-11

    Logged In: YES
    user_id=539295

    Oops! Sorry, I'm stupid. I can't believe I forgot the header
    file. Attached.

     
  • Frieder Ferlemann

    Logged In: YES
    user_id=589052

    > ... --data-loc 0x150 ...
    are you sure you want data addresses >0x7f here?

    Frieder

     
  • Evan Jones

    Evan Jones - 2003-12-11

    Logged In: YES
    user_id=539295

    Umm... No, I'm not sure. However, this is just taken from a
    project that I found on the Internet that was, at one time,
    compiled with SDCC. You can find the webpage about it here:

    http://people.omnigroup.com/wiml/soft/pic/keyspan.html

    So that command line option is from the original source.
    However, the AN2131SC chip has 4K RAM starting at 0x0000, so
    is there any problem with using 0x150 as the data addresses?

    At any rate, the file should either compile or give a
    reasonable error message, not crash.

     
  • Frieder Ferlemann

    Logged In: YES
    user_id=589052

    > However, the AN2131SC chip has 4K RAM starting at
    0x0000, so
    > is there any problem with using 0x150 as the data
    addresses?

    In 8051 notation the 4k RAM are referred to as "xdata",
    whereas "data" denote a small (completely separate)
    area from 0x00 to 0x7f.
    Some parts of the "data" memory are doubly used
    (register bank, bitvariables, idata, stack...).
    It takes a while to become familiar with the memory
    layout of the 8051, so it's perhaps easier to not specify
    --data-loc and let SDCC do it.

    >At any rate, the file should either compile or give a
    reasonable error message, not crash.
    Ack.

    Frieder

     
  • Erik Petrich

    Erik Petrich - 2003-12-13

    Logged In: YES
    user_id=635249

    I believe this should be fiixed by src/SDCCicode.c 1.177 and
    src/SDCCast.c 1.201; these changes should make it into a
    binary snapshot in the next day or two. This bug was
    specific only to big endian architectures (such as Power-PC).

    I took a lookl at the project web page. With respect to the
    --data-loc 0x150, it appears that the original author is
    taking advantage of undocumented linker behaviour to go with
    the custom startup code in main.asm. So I would leave this
    option set to this strange address and it should work as
    intended, at least until someone fixes the linker to better
    validate its options.

    Also, the compiler gives some warnings about "conditional
    flow changed by optimizer". They are being caused by some
    switch cases falling through to the default case without
    doing anything; the optimizer eliminated them in favor of
    directly using the default case and is just letting you know
    about this change.

     
  • Erik Petrich

    Erik Petrich - 2003-12-13
    • milestone: --> fixed
    • assigned_to: nobody --> epetrich
    • status: open --> closed-fixed
     

Log in to post a comment.