#3028 FATAL Compiler Internal Error on using function pointer without *

[Gabriel Ravier]

void f(int (p)(void))
{
  p();
}

When compiled with sdcc test.c, this results in test.c:3: error 9: FATAL Compiler Internal Error in file 'gen.c' line number '1805' : aopPut got unsupported aop->type. Tested on commit 11647.

[Philipp Klaus Krause]

The bug still exists in current SDCC, for mcs51 only.

P.S.: This looks a bit weird. We have this in dumpraw0:

test.c(l1:s0:k0:d0:s0:b3)    _entry($2) :
test.c(l1:s0:k1:d0:s0:b3)       proc _f [k1 lr0:0 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{void function ( int function ( void ) auto) fixed}
test.c(l1:s0:k2:d0:s0:b3)   _p [k2 lr0:0 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{int function ( void ) auto} = recv _f [k1 lr0:0 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{void function ( int function ( void ) auto) fixed}
test.c(l3:s0:k3:d0:s0:b3)       iTemp1 [k4 lr0:0 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{int fixed} = call _p [k2 lr0:0 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{int function ( void ) auto}

That assignment to p stays there for mcs51 until the end (so codegen will try to copy the parameter into a function p), but for other ports, the iCode looks fine from dumpraw1 onwards.

P.P.S.: Apparently, for mcs51 only, OP_REQV (op) is 0 when that p is meant to be replaced in replaceRegEqvOperand in src/SDCCOpt.c.

P.P.P.S.: In geniCodeReceive in src/SDCCicode.c, we get into this if for mcs51 only:

if ((IN_FARSPACE (SPEC_OCLS (sym->etype)) && !TARGET_HC08_LIKE && !TARGET_MOS6502_LIKE) &&
                  options.stackAuto == 0 && (!(options.model == MODEL_FLAT24)))

The condition here looks like it will only be true for mcs51 only: hc08, s08 and mos6502 are explicitly excluded, ds390 always uses the flat24 model, pdk doesn't have register parameters, and the other ports have options.stackAuto == 1.

[Maarten Brock]

I'm kinda surprised that this is valid C:
void f(int (p)(void))
Doesn't p require a * before it here?

[Philipp Klaus Krause]

A sentence in section 6.7.6.3 of the C2X standard (AFAIK, the same wording as in earlier standards): 'A declaration of a parameter as "function returning type" shall be adjusted to "pointer to function returning type", as in 6.3.2.1.'

[Benedikt Freisen]

[bugs:#3358] and this one are probably closely related.