#4118 A diagnosed constexpr parameter can still make SDCC crash

[Christopher Bazley]

1: Sample code that reproduces the problem.

int f(constexpr int x) {return x;}

2: Exact command used to run SDCC on this sample code.

sdcc -mz80 --std=c2y --nostdinc -S constexpr-parameter-return.c -o output.asm

3: SDCC version tested.

SDCC : mcs51/z80/z180/r2k/r2ka/r3ka/r4k/r5k/r6k/sm83/tlcs90/ez80/z80n/r800/ds390/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15 TD- 4.6.4 #0 (Linux)
published under GNU General Public License (GPL)

Built from clean official SVN r16981 sources on Linux.

4: Observed and expected behaviour.

SDCC emits error 198, then reports Caught signal 11: SIGSEGV and exits with status 1.

WG14 N3886,
6.7.7.4 paragraph 2, specifies the relevant constraint:

The only storage-class specifier that shall occur in a parameter declaration is register.

Implementations are required to diagnose violation of this constraint, which SDCC does. I guess whatever happens next depends on QoI.

5: Additional checks.

Compiler Explorer: SDCC trunk and GCC 16.2 side by side.
Both panes use the sample above. SDCC uses -mz80 --std=c2y; GCC uses
-std=c2y -pedantic-errors -fsyntax-only. Checked 7 October 2026: GCC 16.2 diagnoses the constraint violation; SDCC issues error 198 and then crashes with SIGSEGV.

GCC 13.3.0 locally (-std=c2x) diagnoses every invalid case and accept every 'control'. Both used -pedantic-errors -fsyntax-only. No Clang or TCC comparison was run.

Case	Expected	SDCC Z80 C2Y
constexpr-parameter-return.c	Invalid	Error 198 then SIGSEGV
constexpr-parameter-comparison.c	Invalid	Error 198 then SIGSEGV
ordinary-parameter-control.c	Valid	Accepted silently
const-parameter-control.c	Valid	Accepted silently

Tested configurations: MCS51 default/large/medium/stack-auto, DS390, Z80, Z180, Rabbit 2000/4000, SM83, TLCS-90, HC08, S08, STM8 default/large, PDK13/14/15, and eZ80. These are translation checks, not runtime tests.

Implementation observation: The invalid parameter is diagnosed but continues into expression processing. The constexpr propagation path assumes that a constexpr expression can supply
a constant value.

[Christopher Bazley]

Please consider the attached candidate bugfix patch.

[Philipp Klaus Krause]

I'll leave this one to @roybaer, he is much more familiar with constexpr support in sdcc.