#3916 Syntax error if a function type name is the operand of typeof

[Christopher Bazley]

Function type names cannot be used as the operand of the typeof operator.
Clang and LLVM permit it: https://godbolt.org/z/Txo3Ez3K9
I would expect SDCC to permit it too.
If this is not addressed then this method of declaring pointers to optional-qualified function types will be unavailable to SDCC users, e.g. _Optional typeof (int (int)) *opf;

1. Sample code that reproduces the problem:

int foo(int);
typeof (int (int)) foo; // syntax error
typeof (int (int)) *pfoo; // syntax error
typeof (int (*)(int)) pfoo; // OK

1. Exact command used to run SDCC on this sample code:
   sdcc bug.c

2. SDCC version tested:
   SDCC : mcs51/z80/z180/r2k/r2ka/r3ka/r4k/r5k/r6k/sm83/tlcs90/ez80/z80n/r800/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15/mos6502/mos65c02/f8/f8l TD- 4.5.15 #15966 (Linux)
   published under GNU General Public License (GPL)

Also tested version 4.5.0 at Compiler Explorer.

1. Copy of the error message or incorrect output:
   bug.c:2: error 1: Syntax error, declaration ignored at ')'
   bug.c:2: warning 278: return type of function omitted, assuming int
   Internal error: validateLink failed in SPEC_SCLS(sym->etype) @ SDCCmem.c:420: expected SPECIFIER, got null-link

[Christopher Bazley]

I retested this with a newer build of SDCC and it still reports a syntax error, but the warning about a missing return type appears to have been fixed:

~/optional-ts/examples $ sdcc -c --std=c23 3916.c
3916.c:2: error 1: Syntax error, declaration ignored at ')'
Internal error: validateLink failed in SPEC_NOUN(p) @ SDCCsymt.c:706: expected SPECIFIER, got null-link
~/optional-ts/examples $ sdcc -c --std=c23 --stack-auto 3916.c
3916.c:2: error 1: Syntax error, declaration ignored at ')'
Internal error: validateLink failed in SPEC_NOUN(p) @ SDCCsymt.c:706: expected SPECIFIER, got null-link
~/optional-ts/examples $ sdcc -v
SDCC : mcs51/z80/z180/r2k/r2ka/r3ka/r4k/r5k/r6k/sm83/tlcs90/ez80/z80n/r800/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15/mos6502/mos65c02/f8/f8l TD- 4.5.24 #16456 (Mac OS X ppc)
published under GNU General Public License (GPL)

(I'm not sure what the validateLink error is about.)

[Christopher Bazley]

I am attaching a proposed combined bugfix for this issue and issue [#3917], created with assistance from Codex in ChatGPT Work. I hope that it will prove acceptable when reviewed by SDCC's maintainers.

During development of the regression tests for this issue, I found what appears to be an unrelated bug, which I have reported as [bugs:#4073]
I suggest that bug [#4073] should be fixed separately from and after [#3916]/[#3917], because the two topics are really unrelated.

I did the following testing of the proposed patch:

• complete diagnostic-validation results (support/valdiag) for the default targets.
• complete runtime regression (support/regression) results for ucz80.

i.e.
make -j2
make -C support/regression clean-results
make -C support/regression -j2 test-ucz80
make -C support/valdiag clean
make -C support/valdiag -j2

Summary for 'ucz80': 0 failures, 36747 tests, 6407 test cases, 7347989 bytes, 1613643851 ticks
Summary for 'mcs51': 0 failures, 653 tests, 364 test cases, 0 bytes, 0 ticks
Summary for 'mcs51-large': 0 failures, 651 tests, 364 test cases, 0 bytes, 0 ticks
Summary for 'mcs51-stack-auto': 0 failures, 652 tests, 364 test cases, 0 bytes, 0 ticks
Summary for 'ds390': 0 failures, 639 tests, 364 test cases, 0 bytes, 0 ticks
Summary for 'z80': 0 failures, 642 tests, 364 test cases, 0 bytes, 0 ticks
Summary for 'z180': 0 failures, 641 tests, 364 test cases, 0 bytes, 0 ticks
Summary for 'r2k': 0 failures, 641 tests, 364 test cases, 0 bytes, 0 ticks
Summary for 'r4k': 0 failures, 641 tests, 364 test cases, 0 bytes, 0 ticks
Summary for 'sm83': 0 failures, 641 tests, 364 test cases, 0 bytes, 0 ticks
Summary for 'tlcs90': 0 failures, 641 tests, 364 test cases, 0 bytes, 0 ticks
Summary for 'hc08': 0 failures, 640 tests, 364 test cases, 0 bytes, 0 ticks
Summary for 's08': 0 failures, 640 tests, 364 test cases, 0 bytes, 0 ticks
Summary for 'mos6502': 0 failures, 640 tests, 364 test cases, 0 bytes, 0 ticks
Summary for 'stm8': 0 failures, 643 tests, 364 test cases, 0 bytes, 0 ticks
Summary for 'f8': 0 failures, 639 tests, 364 test cases, 0 bytes, 0 ticks
Summary for 'pdk13': 0 failures, 642 tests, 364 test cases, 0 bytes, 0 ticks
Summary for 'pdk14': 0 failures, 640 tests, 364 test cases, 0 bytes, 0 ticks
Summary for 'pdk15': 0 failures, 638 tests, 364 test cases, 0 bytes, 0 ticks

[Philipp Klaus Krause]

I think the approach looks good. However, I do see some test failures:

1) support/regression/tests/typeof.c fails for test-pdk14
2) support/regression/tests/bug-716242.c fails for test-s08 and test-mcs51-small

1) is apparently just about reentrancy in new tests: for some SDCC targets using the stack is quite expensive, so by default local variables and parameters are treated as if they were static (standard-compliant reentrancy can be requestes per-function via __reentrant, per-file via --stack-auto, or for part of a translation unit via #pragma stackauto). However, for function pointers, all parameters must be in registers or on the stack, thus there is a per-port limit on the parameters for pointers to non-reentrant functions. We usually just make most tests for function pointers use reentrant functions.

[Christopher Bazley]

Hi Philipp, thanks for looking into this.

I think the candidate patch might have introduced a broken parameter list order in src/SDCC.y. I think maybe FUNC_ARGS ($$) = reverseVal ($3) is required instead of assigning $3 directly. I'll test that change.