There were two aspects of this behavior that were considered undesirable:
- Although the safe inlining is in general desirable it should only be enabled if asked for it - like any other optimization.
- The option name -Os implies that it is a safe option, the potentially unsafe inlining should have a more explicit name.
So now:
- The option -Os enables the safe inlining.
- The new option --eagerly-inline-funcs enables the potentially unsafe inlining (including the safe inlining).
Additionally was added:
- The option --inline-stdfuncs that does like -Os enable the safe inlining but doesn't enable optimizations.
- The pragma inline-stdfuncs that works identical to --inline-stdfuncs.
- The pragma allow-eager-inline that enables the potentially unsafe inlining but doesn't include the safe inlining. That means that by itself it only marks code as safe for potentially unsafe inlining but doesn't actually enable any inlining.
If cc65 is installed and used as designed there's no need whatsoever for CC65_HOME (both on *IX and Windows) from the perspective of the cc65 binaries. If the user however has to access files from the 'target' directory thenhe ends up with some assumption on the cc65 installation path nevertheless :-(
In order to avoid this I added the --print-target-path option. It "exports" the logic used by the cc65 binaries to locate their files to the user thus allowing him to leverage the same logic to locate the target files in his build scripts / Makefiles.
predefined macro. Instead there is now a command line option --standard that
allows to set c89, c99 or cc65 as language standard. The compiler defines a
macro __CC65_STD__ that is one of __CC65_STD_C89__, __CC65_STD_C99__ or
__CC65_STD_CC65__ depending on the command line option. Default is cc65 (all
extensions) as before.
git-svn-id: svn://svn.cc65.org/cc65/trunk@3133 b7a2c559-68d2-44c3-8de9-860c34a00d81
