uot;GCC Development"
Subject: Re: PATCH committed: 64-bit Apple Objective-C runtime support
On Thu, Feb 17, 2011 at 06:21:17PM -0800, Mike Stump wrote:
> On Feb 17, 2011, at 4:09 PM, Nicola Pero wrote:
> > This patch is not me - it's by Iain Sandoe. :-)
>
> Thanks for
> Hi Michael,
>
> Thanks for running these. I spent some time this morning looking
> through the results, they largely look ok though I don't have much
> perspective on the the objc/ obj-c++ failures.
I had a quick look at the test results for 4.6.0 under Michael's
name on the mailing list.
The
>> Here are some areas I'll look closer to, as shown by some early profiling
>> I performed:
>> * hash tables (both htab and symtab)
>
> There is probably a lot of tuning possible around GCC hash tables.
Yes. I'd like to mention that I have been working on this myself during the
past weeks and
> (I don't have svn write access so I'll need someone else to commit it if
> it's approved.)
I can apply it for you. But ... do you have a copyright assignment in place
for contributions to GCC ? The patch looks small and trivial enough that
I think I can apply it without a signed copyright assi
> This patch completes the removal of the public part of the
> Traditional Objective-C runtime API from libobjc.
>
> From now on, the only supported API is the "Modern" API. :-)
> Nicola, this is causing trouble for Fedora. The Fedora maintainer has
> been advised by GNUstep upstream to switch
Apologies for the trivial question - I haven't worked on GCC for a while.
I fixed PR libobjc/19850. I guess I'm supposed to resolve the bug now but I
don't seem to have
the permissions to do it in bugzilla (my email is
nicola.p...@meta-innovation.com).
Can that be enabled ? :-)
Apologies it
> You should be able to use your @gcc.gnu.org account which has full
> permissions to close bugs. Just use the forgot password on your
> @gcc.gnu.org account. If that does not work, is the email that your
> @gcc account is being forward to correct. Use "ssh gcc.gnu.org email
> emailaddr...@emai
Can we (legally) merge Apple's Objective-C / Objective-C++
modifications to GCC into FSF GCC trunk ?
Any legal obstacles ?
If we start producing patches to the current FSF GCC trunk that merge
these modifications, would they be accepted ?
I think Apple would benefit from merging of their mo
Can we (legally) merge Apple's Objective-C / Objective-C++
modifications to GCC into FSF GCC trunk ?
Any legal obstacles ?
I assume Apple had signed a copyright assignment to the FSF for all
changes to GCC, moreover I checked
the modified GCC source code that Apple distributes and all the
Chris
thanks a lot for your answer. That makes sense - I had not realized that most
of the Apple GCC Objective-C / Objective-C++ changes
were already sitting on the FSF servers in an Apple branch :-) Can someone
from the FSF confirm that it's OK to merge code from there ?
I did look at the b
>> Btw, we do seem to have code in GCC that is not copyrighted by the FSF.
>> For example I don't think the FSF owns copyright on the ACATS
>> testsuite, and libffi mentions (c) by RedHat.
>
> That code is not part of the compiler proper. The policy has always
> been different for the test suites
Most of the Objective-C/Objective-C++ parser code is in files shared with the
C/C++ frontend,
hence I'm confused about who approves what.
For example, if I post a patch that changes a piece of code in gcc/c-parser.c
which is only
ever used if (c_dialect_objc ()), then I assume that it is part of
>> For example, if I post a patch that changes a piece of code in
>> gcc/c-parser.c which is only ever used if (c_dialect_objc ()), then I
>> assume that it is part of the Objective-C front-end, and the
>> Objective-C/Objective-C++ maintainers are in charge of approving it.
>> Once they appro
he's been told he can't approve any changes inside
gcc/cp, not even
if they are Objective-C++-only, so I'm asking again)
Thanks!
-Original Message-
From: "Joseph S. Myers"
Sent: Thursday, 23 September, 2010 17:05
To: "Nicola Pero"
Cc: "g...@gn
>> Ah, yes. So we should share the parsing of the decl-specifier-seq with the
>> C-style for loop, which allows us to avoid the tentative parsing.
>
> That was my original idea, but the C-style loop calls
> cp_parser_simple_declaration(), that shouts at the ':'. So we should
> either modify it to
them early
in the bug-fixing phase. It will take me a few days.
Then I'll come back and work on the release notes. :-)
Thanks
-Original Message-
From: "Ed Smith-Rowland" <3dw...@verizon.net>
Sent: Tuesday, 2 November, 2010 16:13
To: "Nicola Pero"
Cc:
> The gthreads portability layer is missing a function for destroying a
> __ghtread_recursive_mutex object.
>
> For pthreads-based models the recursive mutex type is the same as the
> normal mutex type so __gthread_mutex_destroy handles both, but they're
> distinct types for (at least) gthr-win32.
17 matches
Mail list logo
