[PATCH] Objective-C: fix protocol list count type (pertinent to non-LP64)
Mon Nov 8 13:41:39 GMT 2021
> On 7 Nov 2021, at 22:50, Matt Jacobson <email@example.com> wrote:
>> On Oct 25, 2021, at 5:43 AM, Iain Sandoe <firstname.lastname@example.org> wrote:
>> 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]
> Looked into this. It’s happening because obj-c++.dg/dg.exp has:
> set DEFAULT_OBJCXXFLAGS " -ansi -pedantic-errors -Wno-long-long"
> Specifically, the `-pedantic-errors` argument prohibits initialization of a
> flexible array member. Notably, this flag does *not* appear in objc/dg.exp.
I think -pedantic-errors might be applied at a higher level - if it is not, then perhaps that is an omission to rectify.
> Admittedly I didn’t know that initialization of a FAM was prohibited by the
> standard. It’s allowed by GCC, though, as documented here:
> Is it OK to use a GCC extension this way in the Objective-C frontend?
Well, I had two thoughts so far;
1/ allow the extension and suppress the warning on the relevant trees.
2/ maybe create a new type “ on the fly “ for each protocol list with a correct length [initialising this would not be an error] (since the type is only used once it can be local to the use).
— but I haven’t had time to implement either ….
>> 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).
> The output is different only for targets where
> sizeof (long) != sizeof (void *).
> Do we have the ability to run “cross”
> torture tests?
For most platforms, the answer is pretty much “no” - GCC is built for a single target (unless you have a mutlilib with the necessary difference - which seems unlikely in this case).
For Darwin platforms, we can (in most cases) choose a different -mmacosx-version-min= from the current host) - but that doesn’t allow us really any more and the 32b multilibs have sizeof (long) == sizeof (ptr) so no help there.
> Could such a test verify the emitted assembly (like LLVM’s
> FileCheck tests do)?
We have a similar set of possibilities to LLVM/clang (the tree check could be the right one here)
* we can verify at some appproriate IR stage [-fdump-tree-xxxxx] (check that the right trees are emitted)
* we can verify the expected assembler is emitted (scan-asm in dg-tests)
> Or would it need to execute something?
An execute test can be a good way for checking that code-gen is working properly (providing, of course, that a wrong codegen would in some way make the execute fail - the question is can one construct such a test for this)
sorry this is not an answer - just a list of possible ways forward.
More information about the Gcc-patches