Small Device C Compiler suite

Hi Peter,

> Out of curiosity I tried to use the "--optimize-df" option the other
> day.  It caused sdcc to segfault !

This definitely is supposed to work (should eliminate many dead
instructions). I fixed some segfault for SDCC #1111, maybe you are lucky
and I just found your bug.
Otherwise I would highly appreciate if you could publish/send me your
faulting code. Alternatively a stacktrace (bt) from gdb might help...

Raphael Neider

On Thu, 2005-09-22 at 15:19 +0200, Raphael Neider wrote:
> This definitely is supposed to work (should eliminate many dead
> instructions). I fixed some segfault for SDCC #1111, maybe you are lucky
> and I just found your bug.
> Otherwise I would highly appreciate if you could publish/send me your
> faulting code. Alternatively a stacktrace (bt) from gdb might help...

Thanks Raphael,  I'll give it another try and send you anything I can
find.

Peter

On Thu, 2005-09-22 at 14:48 +0100, Peter Onion wrote:

> Thanks Raphael,  I'll give it another try and send you anything I can
> find.
> 

OK I've tracked down the source code that causes the optimisation to
crash....



#include "stdio.h"
#include "stdlib.h"

#include "malloc.h"

#pragma stack 0x500 255 

/* Memory for malloc and friends */
unsigned char _MALLOC_SPEC heap[MAX_HEAP_SIZE];


struct testStruct
{
    int n;
    struct testStruct *next;
};


void main(void)
{

    struct testStruct *ts;


    ts = (struct testStruct *) malloc(sizeof(struct testStruct));
    ts->next = NULL;    /* <<<<< CRASHES THE OPTIMISER */
}

It seems the problem is assigning a constant to the next field in the
structure.
If for example I change it to "ts->next = ts" then it compiles OK.

I ran sdcc under gdb, but the backtrace complained about a corrupt
stack !

Peter.

Hi Peter,

> OK I've tracked down the source code that causes the optimisation to
> crash....

Great!

> [code snipped]
> 
> It seems the problem is assigning a constant to the next field in the
> structure.
> If for example I change it to "ts->next = ts" then it compiles OK.

The bug was completely de-located: copying an SFR operand just copied
the first half of the pCodeOpReg structure. (Now I feel better: *my*
optimization code did not cause this bug, it just displayed it ;-)).

The fix will be committed this evening.

> I ran sdcc under gdb, but the backtrace complained about a corrupt
> stack !

Worked for me (luckily) -- but as SDCC dereferenced uninitialized
pointers, it could just have overwritten your frame pointer on the
stack. What a really bad luck that is...

BTW: Remember to patch the linker script to provide a 512 byte memory
bank (I missed it and wondered about "no target memory for..." warnings).

Raphael

On Fri, 2005-09-23 at 16:32 +0200, Raphael Neider wrote:
> Hi Peter,

> 
> The bug was completely de-located: copying an SFR operand just copied
> the first half of the pCodeOpReg structure. (Now I feel better: *my*
> optimization code did not cause this bug, it just displayed it ;-)).
> 
> The fix will be committed this evening.

Great !

> BTW: Remember to patch the linker script to provide a 512 byte memory
> bank (I missed it and wondered about "no target memory for..." warnings).

I meant to mention that when I posted the code as I DO use a patched
linker script !

Peter