#4125 Floating-point shift counts are accepted without diagnostics
1: Sample code that reproduces the problem.
int f(int x, float y) { return x << y; }
2: Exact command used to run SDCC on this sample code.
sdcc -mz80 --std=c2y --nostdinc -S shift-zero.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 exits successfully and emits no diagnostic for the sample.
WG14 N3886,
6.5.8 paragraph 2 and 6.5.17.3 paragraph 2, specifies the constraint violated by the example:
Each of the operands shall have integer type.
This also applies to <<= and >>= through the compound-assignment constraints. SDCC accepts literal and variable shift counts of floating point type, for both shift directions and compound assignment.
5: Additional checks.
All invalid cases are silently accepted on 19 C2Y configurations and Z80 in C23 mode. GCC 13.3.0, with -std=c2x -pedantic-errors -fsyntax-only, diagnoses every invalid case and accepts every control. No Clang or TCC comparison was run.
Configurations tested: 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 compiler and diagnostic checks, not runtime tests.
Implementation observation: The LEFT_OP/RIGHT_OP branch of decorateType in src/SDCCast.c tests TYPE(tree) and tree->left->etype. Both refer to the left operand, so the right operand is never checked for integer type.
Please consider the attached candidate bug fix patch.