[Bug objc/102537] Objective-C: can't use >= USE_FIXUP_BEFORE paths on non-Darwin

["mhjacobson at me dot com" <gcc-bugzilla@gcc.gnu.org>]

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.