Benedikt Freisen

Apparently, the Rabbit 4000 port is not handled correctly, here. For the time being, you could try to disable that, too, since that was probably your intention, anyway.

With a bit of luck, I will have ckd_mul and ckd_add for unsigned long long ready for the upcoming release. That would be by far the most elegant way to get rid of the warning.

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.

Maybe it is sufficient to output a warning only when the default behavior directly conflicts with the user's presumed intention, namely when standard compliance has been explicitly requested via e.g. --std-c23. When such a command line switch has been specified, the current default behavior for e.g. MCS-51 (the compiler outputting non-reentrant code by default) becomes particularly unintuitive.

(comment copied from a different bug ticket) Can you retry with sdcc -c --std=c23 --stack-auto or sdcc -c --std=c23 -mz80? 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...

(comment copied from a different bug ticket) Can you retry with sdcc -c --std=c23 --stack-auto or sdcc -c --std=c23 -mz80? 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...

Can you retry with sdcc -c --std=c23 --stack-auto or sdcc -c --std=c23 -mz80? 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.

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.