https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102537
--- Comment #2 from Matt Jacobson <mhjacobson at me dot com> ---
I certainly haven't spent as much time thinking about this as you, but I think
my personal preference would be to add new values to the `flag_objc_abi`
argument. It's already the case that "objc-next-runtime-abi-01.c" supports
both 0 and 1 values; I think it would be reasonable to have
`objc-next-runtime-abi-02.c` support multiple values too. I'd imagine
something like:
2 -- "modern" runtime ABI, pre-SnowLeopard (fixup messages, etc.)
3 -- "modern" runtime ABI, SnowLeopard and later (no fixup messages, weak
protocol metadata
Then the Darwin-target code could (absent an explicit override in the
arguments) select the value for `flag_objc_abi` based on
`-mmacosx-version-min`. And non-Darwin targets could simply default to the
newest ABI (absent an explicit override).
Other versions could be added in the future as support for newer
runtime-ABI-dependent features (e.g., `objc_autoreleasePoolPush()`,
`objc_opt_self()`, `objc_loadWeak()`) is added.
Under this scheme, I think it would make sense to switch `flag_next_runtime` to
being a simple boolean.
===
I think I like this better than using the high byte of `flag_next_runtime`,
which could be cumbersome to build conditionals for. For example, taking your
example of using 0x01000000 as the "AVR" platform, a check of whether to use
non-fixup messaging might end up look like:
#define PLATFORM(r) (((r) >> 24) & 0xFF)
#define VERSION(r) ((r) & 0xFFFFFF)
if ((PLATFORM(flag_next_runtime) == DARWIN && VERSION(flag_next_runtime) >=
USE_FIXUP_BEFORE)
|| PLATFORM(flag_next_runtime) == AVR)
{ ... }
Yeah, the existing `flag_next_runtime >= USE_FIXUP_BEFORE` would technically
work, but you could imagine other platforms with ID > 0 that want the
pre-USE_FIXUP_BEFORE behavior.
===
> These two were both thoughts during the development but I suspect that the
> mapping to values is a build-time decision and ought to be done in the flags
> override code.
I'd like to understand better what you mean here. Is it that, under the
`flag_objc_abi` scheme I described, the x86_64-Darwin target may want different
logic to select `flag_objc_abi` than the AVR target (for example)? If so then
I agree -- shouldn't that be similar to how the `flag_next_runtime` override is
currently target-dependent? Apologies if I've completely misread that.
