Hi Matt, > On 23 Oct 2021, at 09:46, Iain Sandoe via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > >> On 20 Oct 2021, at 04:51, Matt Jacobson via Gcc-patches >> <gcc-patches@gcc.gnu.org> wrote: >> >> >>> On Sep 26, 2021, at 11:45 PM, Matt Jacobson <mhjacob...@me.com> wrote: >>> >>> Fix protocol list layout for non-LP64. clang and objc4 both give the >>> `count` >>> field as `long`, not `intptr_t`. Those are the same on LP64, but not >>> everywhere. For non-LP64, this fixes binary compatibility with clang-built >>> classes. >>> >>> This was more complicated than I anticipated, because the relevant frontend >>> code in fact had no AST type for `protocol_list_t`, instead emitting >>> protocol >>> lists as `protocol_t[]`, with the zeroth element actually being the integer >>> count. That made it nontrivial to change the count to `long`. With this >>> change, there is now a true `protocol_list_t` type in the AST. >>> >>> Tested multiple ways. On x86_64/Darwin, I confirmed with a test program >>> that >>> protocol conformances by classes, categories, and protocols works.
see ** below … >>> On AVR, I >>> manually inspected the generated assembly to confirm that protocol lists >>> gain >>> an extra two bytes of `count`, matching clang. Did you test objective-c++ on Darwin? I see a lot of fails of the form: Excess errors: <built-in>: error: initialization of a flexible array member [-Wpedantic] >>> Thank you for your time. >>> >>> <https://github.com/mhjacobson/gcc/commit/5ebc95dc726f0745ebdf003093f1b8d7720ce32f> >> >> Friendly ping. Please let me know if there’s anything I can clarify. > > The patch is in my queue (it will not get lost), the rationale seems > reasonable, For a patch that changes code-gen we should have a test that it produces what’s expected (in general, a ‘torture' test would be preferrable so that we can be sure the output is as expected for different optimisation levels). ** If you have a test program that could be the basis for this - but it needs to be integrated into the testsuite with scans for the required output. Have to give some thought to how to solve the obj-c++ issue. Iain
