> 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
> 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
>
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
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
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
> 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
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
> 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,
> 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
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
> 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
> 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
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
13 matches
Mail list logo
