Re: [PATCH] Objective-C: don't require redundant -fno-objc-sjlj-exceptions for the NeXT v2 ABI

> On Aug 2, 2021, at 5:09 PM, Eric Gallager wrote: > > On Wed, Jul 28, 2021 at 11:36 PM Matt Jacobson via Gcc-patches > wrote: >> >> As is, an invocation of GCC with -fnext-runtime -fobjc-abi-version=2 crashes, >> unless target-specific code adds an implicit -f

Re: [PATCH] Objective-C: don't require redundant -fno-objc-sjlj-exceptions for the NeXT v2 ABI

> On Aug 3, 2021, at 2:39 PM, Iain Sandoe wrote: > > > >> On 2 Aug 2021, at 22:37, Matt Jacobson via Gcc-patches >> wrote: >> >>> On Aug 2, 2021, at 5:09 PM, Eric Gallager wrote: >>> >>> On Wed, Jul 28, 2021 at 11:36 PM Matt

[PATCH] Objective-C: fix crash with -fobjc-nilcheck

When -fobjc-nilcheck is enabled, messages that result in a struct type should yield a zero-initialized struct when sent to nil. Currently, the frontend crashes when it encounters this situation. This patch fixes the crash by generating the tree for the `{}` initializer. Tested by running the

Re: [PATCH] Objective-C: fix crash with -fobjc-nilcheck

> On Aug 14, 2021, at 5:25 AM, Iain Sandoe wrote: > > 1/ please can you either post using a mailer that doesn’t mangle patches or > put the patch as a plain text attachment > (pushing to a git branch somewhere public also works for me, but maybe not > for all reviewers) > - for small patc

[PATCH] Objective-C: fix class_ro layout for non-LP64

Fix class_ro layout for non-LP64. On LP64, the requisite padding is added at a lower level. For non-LP64, this fixes binary compatibility with clang-built classes/runtimes. Tested by examining the generated assembly for a class_ro in both cases (and in the case of clang), for both x86_64 (64-bi

Re: [PATCH] Objective-C: fix class_ro layout for non-LP64

Hi Iain, Thanks for reviewing. I’m happy to make the suggested changes. One comment inline. > On Sep 22, 2021, at 2:49 PM, Iain Sandoe wrote: > > However, the behaviour is changed - the existing implementation is explicit > about the fields and > clears the reserved ones (and, ISTR, that wa

[PATCH] Objective-C: fix protocol list count type (pertinent to non-LP64)

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 rele

Re: [PATCH] Objective-C: fix protocol list count type (pertinent to non-LP64)

> On Oct 25, 2021, at 5:43 AM, Iain Sandoe wrote: > > Did you test objective-c++ on Darwin? > > I see a lot of fails of the form: > Excess errors: > : error: initialization of a flexible array member [-Wpedantic] Looked into this. It’s happening because obj-c++.dg/dg.exp has: set DEFAUL

[PATCH] build: Implement --with-multilib-list for avr target

The AVR target builds a lot of multilib variants of target libraries by default, and I found myself wanting to use the --with-multilib-list argument to limit what I was building, to shorten build times. This patch implements that option for the AVR target. Tested by configuring and building an AV

Re: [PATCH] Objective-C: fix protocol list count type (pertinent to non-LP64)

> On Sep 26, 2021, at 11:45 PM, Matt Jacobson 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 > class

Re: [PATCH] build: Implement --with-multilib-list for avr target

> On Jun 7, 2021, at 3:30 AM, Matt Jacobson wrote: > > The AVR target builds a lot of multilib variants of target libraries by > default, > and I found myself wanting to use the --with-multilib-list argument to limit > what I was building, to shorten build times. This patch implements that

Re: [PATCH] build: Implement --with-multilib-list for avr target

> On Jul 5, 2021, at 7:09 PM, Matt Jacobson wrote: > >> On Jun 7, 2021, at 3:30 AM, Matt Jacobson wrote: >> >> The AVR target builds a lot of multilib variants of target libraries by >> default, >> and I found myself wanting to use the --with-multilib-list argument to limit >> what I was bu

[PATCH] Objective-C: don't require redundant -fno-objc-sjlj-exceptions for the NeXT v2 ABI

As is, an invocation of GCC with -fnext-runtime -fobjc-abi-version=2 crashes, unless target-specific code adds an implicit -fno-objc-sjlj-exceptions (which Darwin does). This patch makes the general case not crash. I don't have commit access, so if this patch is suitable, I'd need someone else