#948 Slowly phase out implicit generation of non-reentrant functions

[Benedikt Freisen]

In my opinion, the compiler's default behavior should be to generate standard-compliant code, perhaps with a few extensions, but without deviations that could surprise a user.
For some targets, SDCC currently implicitly generates non-reentrant functions unless the user explicitly passes the --stack-auto command line switch.

For better standard compliance by default, I suggest to

1. add a warning indicating that the current default behavior is non-compliant
2. add a --no-stack-auto switch to suppress the warning and explicitly request the current default behavior
3. leave it like that for a few stable releases
4. eventually switch to the --stack-auto behavior as new default and perhaps emit a new warning in the first stable release that does it that way

[Philipp Klaus Krause]

I think this would break too much existing code. --stack-auto is really, really expensive on mcs51, ds390, pdk, mos6502, mos65c02 and hc08. To the point that virtually all users will want the non-standard behaviour by default.

[Benedikt Freisen]

Alright. In that case scrap points 3 and 4.
What about points 1 and 2, though?

[Janko Stamenović]

Regarding warnings and warning suppression, AFAIK, if the warning has a number, it could be suppressed with the command line switch--disable-warning <nnnn> or with #pragma disable_warning nnnn. I think that is much more straightforward than adding some special switch just to disable some special warning?

Edit: still, the question is why should a default warning "push" users to a practice that is not beneficial for a given target. SDCC's value is in providing benefits for those using these targets. If the benefits come from not enforcing unnecessary reentrancy, why should the users get suggestions which are "wrong" in the given context?

[Benedikt Freisen]

The idea would not be to "suppress a warning", but to let the compiler know the user's intention, regardless of the default behavior.
If generating ISO C compliant code by default is impractical, as you outlined for the targets in question, I would therefore suggest to give the user a warning if no specific intention was communicated to the compiler.
This could avoid problems such as [support-requests:#199], which was originally filed as a bug report that complained about broken recursive functions on mos6502.

The warning could be something along the lines of:
"warning: For the target 'foo', SDCC generates faster, non-reentrant code by default. If this is the intention, consider making it explicit using --no-stack-auto. Otherwise use --stack-auto to request ISO C compliant reentrant code."

[Benedikt Freisen]

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.