#3954 Mismatch in generic selection when array-to-pointer decay expected

[Christopher Bazley]

1: Sample code that reproduces the problem.

void foo (const char (*pacc)[64])
{
  const char acc[64];
  static_assert (_Generic (acc, const char *: 1, default: 0)); // passes
  static_assert (_Generic (*pacc, const char *: 1, default: 0)); // fails
}

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

sdcc --std=c23 -c /work/bug3.c

3: SDCC version tested (type "sdcc -v" to find it)

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.21 #16327 (Linux)

4: Copy of the error message or incorrect output, or a clear description of the observed versus expected behavior.

In 6.5.2.1 "Generic selection", C23 says:

The type of the
controlling expression is the type of the expression as if it had undergone an lvalue conversion,
array to pointer conversion, or function to pointer conversion

See https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf

When the controlling expression in a generic selection has an array type, the result of array-to-pointer decay is not always the expected type. It seems to depend on the form of the controlling expression; not only its type, as it should.

SDCC produces the following (wrong) diagnostic message, but no diagnostic message about the preceding statement:

/work/bug3.c:5: warning 246: static assertion failed

Neither statement should also result in a "static assertion failed" warning because the type of acc and *pacc should be the same.

[Benedikt Freisen]

Notes:

This variant of the second static_assert apparently works

  static_assert (_Generic (pacc, const char (*)[64]: 1, default: 0));

and so does this one (C2y),

  static_assert (_Generic (typeof (*pacc), const char [64]: 1, default: 0));

but this one fails, too:

  static_assert (_Generic (*pacc, const char [64]: 1, default: 0));

I suspect that something goes wrong either in case '*': in decorateType in SDCCast.c, or in aggregateToPointer in SDCCsymt.c.

[Benedikt Freisen]

With --stack-auto, this one works, too.

Quoting myself:

The observed behavior can potentially be explained with SDCC's default settings:

For historical reasons, the default target -mmcs51 generates non-reeantrant function code, unless --stack-auto is specified. It then compares qualified function types, because it must not ignore (explicit or implicit) address space qualifiers. See also [feature-requests:#948], which addresses this unintuitiveness.

[Christopher Bazley]

With --stack-auto, this one works, too.

Thanks for the tip. I can add that to all of my makefiles and in Compiler Explorer (when I remember). As a user, it's not clear why non-reentrant code should entail any change to the treatment of 'const', 'volatile' or '_Optional' qualifiers though.

I imagine that the machine-specific lowering of a function with signature

void foo (__pdata char (*paqc)[64])

is exactly that same as the machine-specific lowering of a function with signature

void foo (__pdata char *pqc)

Isn't it? If so, I'd expect the type of the expression *paqc to be the same as the type of pqc after undergoing array to pointer decay, even in the presence of address space qualifiers.

[Christopher Bazley]

This one still seems to be an issue with a newer build of SDCC, but only if ---stack-auto is omitted, as previously remarked:

~/optional-ts/examples $ sdcc -c --std=c23 --stack-auto 3954.c
~/optional-ts/examples $ sdcc -c --std=c23 3954.c
3954.c:5: warning 246: static assertion failed
~/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)

[Christopher Bazley]

I attach a candidate combined patch to fix this issue and https://sourceforge.net/p/sdcc/bugs/4071/, which have the same root cause: array-to-pointer decay produces __data char * or __xdata char * instead of generic char *. The bug is in the unary-* branch of decorateType(), which explains why it does not affect the first static assertion in the sample code in the bug report.

The attached patch depends on the candidate fix for https://sourceforge.net/p/sdcc/bugs/4006/ which in turn depends on the candidate fix for https://sourceforge.net/p/sdcc/bugs/4072/. Like those patches, it was created with assistance from Codex.

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, 36740 tests, 6407 test cases, 7348132 bytes, 1609579695 ticks
Summary for 'mcs51': 0 failures, 659 tests, 371 test cases, 0 bytes, 0 ticks
Summary for 'mcs51-large': 0 failures, 657 tests, 371 test cases, 0 bytes, 0 ticks
Summary for 'mcs51-stack-auto': 0 failures, 658 tests, 371 test cases, 0 bytes, 0 ticks
Summary for 'ds390': 0 failures, 645 tests, 371 test cases, 0 bytes, 0 ticks
Summary for 'z80': 0 failures, 648 tests, 371 test cases, 0 bytes, 0 ticks
Summary for 'z180': 0 failures, 647 tests, 371 test cases, 0 bytes, 0 ticks
Summary for 'r2k': 0 failures, 647 tests, 371 test cases, 0 bytes, 0 ticks
Summary for 'r4k': 0 failures, 647 tests, 371 test cases, 0 bytes, 0 ticks
Summary for 'sm83': 0 failures, 647 tests, 371 test cases, 0 bytes, 0 ticks
Summary for 'tlcs90': 0 failures, 647 tests, 371 test cases, 0 bytes, 0 ticks
Summary for 'hc08': 0 failures, 646 tests, 371 test cases, 0 bytes, 0 ticks
Summary for 's08': 0 failures, 646 tests, 371 test cases, 0 bytes, 0 ticks
Summary for 'mos6502': 0 failures, 646 tests, 371 test cases, 0 bytes, 0 ticks
Summary for 'stm8': 0 failures, 649 tests, 371 test cases, 0 bytes, 0 ticks
Summary for 'f8': 0 failures, 645 tests, 371 test cases, 0 bytes, 0 ticks
Summary for 'pdk13': 0 failures, 648 tests, 371 test cases, 0 bytes, 0 ticks
Summary for 'pdk14': 0 failures, 646 tests, 371 test cases, 0 bytes, 0 ticks
Summary for 'pdk15': 0 failures, 644 tests, 371 test cases, 0 bytes, 0 ticks

[Christopher Bazley]

The candidate bug fix patch (attached) has been updated as follows, following reviewer feedback on other changes.

Changes:

• Rebased onto the #4072 -> #4004 -> #4005 -> #4006 stack of candidate bug fixes.
• Moved both new tests from valdiag to support/regression/tests.
• Now uses ASSERT (_Generic (...)) instead of _Static_assert.

Retesting method:

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

regression test results:

Summary for 'ucz80': 0 failures, 36749 tests, 6411 test cases, 7352519 bytes, 1609749405 ticks

valdiag test results:

Summary for 'mcs51': 0 failures, 674 tests, 374 test cases, 0 bytes, 0 ticks
Summary for 'mcs51-large': 0 failures, 672 tests, 374 test cases, 0 bytes, 0 ticks
Summary for 'mcs51-stack-auto': 0 failures, 673 tests, 374 test cases, 0 bytes, 0 ticks
Summary for 'ds390': 0 failures, 660 tests, 374 test cases, 0 bytes, 0 ticks
Summary for 'z80': 0 failures, 663 tests, 374 test cases, 0 bytes, 0 ticks
Summary for 'z180': 0 failures, 662 tests, 374 test cases, 0 bytes, 0 ticks
Summary for 'r2k': 0 failures, 662 tests, 374 test cases, 0 bytes, 0 ticks
Summary for 'r4k': 0 failures, 662 tests, 374 test cases, 0 bytes, 0 ticks
Summary for 'sm83': 0 failures, 662 tests, 374 test cases, 0 bytes, 0 ticks
Summary for 'tlcs90': 0 failures, 662 tests, 374 test cases, 0 bytes, 0 ticks
Summary for 'hc08': 0 failures, 661 tests, 374 test cases, 0 bytes, 0 ticks
Summary for 's08': 0 failures, 661 tests, 374 test cases, 0 bytes, 0 ticks
Summary for 'mos6502': 0 failures, 661 tests, 374 test cases, 0 bytes, 0 ticks
Summary for 'stm8': 0 failures, 664 tests, 374 test cases, 0 bytes, 0 ticks
Summary for 'f8': 0 failures, 660 tests, 374 test cases, 0 bytes, 0 ticks
Summary for 'pdk13': 0 failures, 663 tests, 374 test cases, 0 bytes, 0 ticks
Summary for 'pdk14': 0 failures, 661 tests, 374 test cases, 0 bytes, 0 ticks
Summary for 'pdk15': 0 failures, 659 tests, 374 test cases, 0 bytes, 0 ticks