public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug objc/102537] Objective-C: can't use >= USE_FIXUP_BEFORE paths on non-Darwin Date: Thu, 30 Sep 2021 11:49:12 +0000 [thread overview] Message-ID: <bug-102537-4-dGjM76li7s@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-102537-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102537 Iain Sandoe <iains at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |12.0 Ever confirmed|0 |1 Severity|normal |enhancement Last reconfirmed| |2021-09-30 Status|UNCONFIRMED |NEW --- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Matt Jacobson from comment #0) > I am working on a NeXTv2-ABI-compatible Objective-C runtime for a non-Darwin > platform (AVR micros). I'd like my Objective-C code to make use of the most > modern ABI features, namely those guarded in the code by `flag_next_runtime > >= USE_FIXUP_BEFORE`. > > However, there appears to be no way to control `flag_next_runtime` (short of > modifying the compiler source). I can set it to zero with `-fgnu-runtime` > or one with `-fnext-runtime`, but `USE_FIXUP_BEFORE` is an encoded Mac OS X > version (namely 100600, referring to Snow Leopard). by current design, there are enough bits in the value so that ne can have N MSBs representing the platform and N representing the version. > There is Darwin-specific option parsing code (`darwin_override_options()`) > that appears to set `flag_next_runtime` based on `-mmacosx-version-min`, but > obviously that doesn't run for non-Darwin targets. Most targets have an equivalent "override options" section where they could make a similar selection. A simplistic case would be to say any value >990000 is not Darwin (i.e we make the Darwin platform part of the runtime value == 0 and then any other platform that wants to take an encoding takes a value higher; this would default to the next runtime just using "latest and greatest" - but that might not be what you want in say 2 years time... ... however, it would be better to use bit boundaries rather than arbitrary decimal. maybe ... 0xff000000 masks the platform 0x00ffffff masks the version selector and Darwin is platform 0 for this purpose. so as a quick fix you could just say AVR is platform 1 and set it to 0x01000000 in your platform flags override ... > I could imagine a few approaches to fixing this: > > 1. Parse `-mmacosx-version-min` even when the target is not Darwin, whenever > we're compiling Objective-C. On non-Darwin, this would be interpreted as > requesting Objective-C codegen compatible with the Objective-C ABI of the > specified release of Mac OS X. I do not think that is going to fly ;) > 2. Allow an argument to `-fnext-runtime`, with the meaning approximately the > same as in #1. > > 3. Instead of using `flag_next_runtime` as a version number, switch it back > to being zero or one, and use a separate flag (perhaps the existing > `-fobjc-abi-version`?) to differentiate ABIs. 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. thoughts?
next prev parent reply other threads:[~2021-09-30 11:49 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-30 4:15 [Bug objc/102537] New: Objective-C: can't use >= USE_FIXUP_BEFORE paths for non-Darwin mhjacobson at me dot com 2021-09-30 11:49 ` iains at gcc dot gnu.org [this message] 2021-10-18 16:48 ` [Bug objc/102537] Objective-C: can't use >= USE_FIXUP_BEFORE paths on non-Darwin mhjacobson at me dot com 2022-05-06 8:31 ` jakub at gcc dot gnu.org 2022-05-07 13:44 ` egallager at gcc dot gnu.org 2023-05-08 12:22 ` rguenth at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-102537-4-dGjM76li7s@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).