#3803 segfault on pointer to struct

[Philipp Klaus Krause]

Trying to compile the following makes SDCC from trunk segfault for me on my Debian GNU/Linux testing on amd64 system. I can reproduce the issue using the stm8, f8 and z80 ports, but neither hc08 nor pdk14.

struct largeoddstruct
{
    unsigned char c0;
    unsigned _BitInt(56) bi;
    unsigned char c1;
};

struct largeoddstruct f2(struct largeoddstruct *p)
{
    return (*p);
}

[Janko Stamenović]

Even simpler code does SIGSEGV (tried a recent Windows build from the snapshot)

struct S {
    unsigned char c;
};

struct S f(struct S *p) {
    return *p;
}

// sdcc -mz80 -c t.c

and also (so it's not about the input parameters)

struct S {
    unsigned char c;
};

struct S *p;

struct S f( void ) {
    return *p;
}

[Philipp Klaus Krause]

At first sight, the iCode looks wrong already at dumpraw1, but not dumpraw0. Looks like return (*p) gets messed up in the frontend if p points to a struct or union. Then in the backend, the mismatch between the return type of the function and the type of what the iCode tries to return triggers the segfault (and as of [r15145], an assertion).

[Philipp Klaus Krause]

While technically the types only become wrong in dumpraw1 (due to aggrToPtr conversion in replaceRegEqv), I wonder if the underlying problem is the creation of an iTemp of struct type in the first place.
Hmm. I see two possible ways forward here:
1) Have a special RETURN_VALUE_AT_ADDRESS iCode (like the exisiting PUSH_VALUE_AT_ADDRESS for struct parameters) to handle struct return.
2) Have special handling in the AST for struct return of temporary objects (like we have for struct assignment).

1) Would allow more efficient code, but requires work in all backends.

[Maarten Brock]

For clarity I vote for 1)