Re: PATCH committed: 64-bit Apple Objective-C runtime support
Jack,
thanks for testing this out. You can xfail these. Iain sent me this
morning an additional patch that xfails these; he must have forgotten
to include it in the original one.
I'll attach it. I can't commit now; if Mike or you have time, please do.
I understand that the patch is pre-approved by Mike.
Else, I'll commit it myself tonight (GMT). Apologies for the temporary
noise on the m64 testsuite on Darwin.
Thanks
-Original Message-
From: "Jack Howarth"
Sent: Friday, 18 February, 2011 14:10
To: "Mike Stump"
Cc: gcc-patc...@gnu.org, "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 chipping in and helping out. I'm excited at having a Objective-C
> compiler that works again on darwin.
>
> That said, if people have any Objective-C codes, feel free to beat on them
> and let us know what you find. We're interested in regressions first and
> foremost, after that functionality on 64-bit darwin. We know about PCH not
> working well in some situations, so, be prepared to turn that off.
Did Iain see these failures in his testing at -m64?
FAIL: objc/execute/exceptions/foward-1.m execution, -O0 -fnext-runtime
FAIL: objc/execute/exceptions/foward-1.m execution, -O1 -fnext-runtime
FAIL: objc/execute/exceptions/foward-1.m execution, -O2 -fnext-runtime
FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -fomit-frame-pointer
-fnext-runtime
FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -fomit-frame-pointer
-funroll-loops -fnext-runtime
FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions -fnext-runtime
FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -g -fnext-runtime
FAIL: objc/execute/exceptions/foward-1.m execution, -Os -fnext-runtime
I am seeing those on x86_64-apple-darwin10.
Jack
Index: gcc/testsuite/objc/execute/exceptions/foward-1.x
===
--- gcc/testsuite/objc/execute/exceptions/foward-1.x(revision 0)
+++ gcc/testsuite/objc/execute/exceptions/foward-1.x(revision 0)
@@ -0,0 +1,11 @@
+# XFAIL the run for m64 Darwin NeXT (seems to be a system runtime lib problem).
+if { [istarget *-*-darwin*] && [check_effective_target_lp64] } {
+set torture_eval_before_execute {
+global compiler_conditional_xfail_data
+set compiler_conditional_xfail_data {
+ "Target fails for fnext-runtime" "*-*-*" { "-fnext-runtime" } { "" }
+}
+}
+}
+# carry on...
+return false
Re: Second GCC 4.6.0 release candidate is now available
> 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 ObjC failures FAIL: objc.dg-struct-layout-encoding-1/t025_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t027_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t028_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t029_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t030_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t031_main.m execution test are not worrying. These fail on many platforms (where they are marked as xfails). But, in http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02391.html a number of ObjC PCH failures are reported; but then lots of PCH tests in the same report fail for C too, so it doesn't seem to be anything specific to ObjC. So, as far as I can see, ObjC/ObjC++ looks good. :-) Thanks
Re: GCC Optimisation, Part 0: Introduction
>> 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 have significant uncommitted changes in this area (I haven't looked at the symtab though, only at htab). I should be able to polish and benchmark my changes into a presentable state in the next month or so. Benchmarking takes a huge amount of time, but without it there's no point in making changes. Thanks
Re: [PATCH] fix -Wsign-compare error in objc-act.c (PR objc/50743)
> (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 assignment form, but if you plan on contributing more, it would make sense to sign one. :-) Thanks
Re: libobjc: Remove Traditional Objective-C runtime API
> 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 to LLVM. In Cc: there is Richard, the maintainer of gnustep-base, and I would be very surprised if he wasn't supporting GCC 4.7 and advising to switch to LLVM for this reason. As far as I know gnustep-base has the goal of supporting all compilers and runtimes. Most likely this is due to a small error in the configure script or in a file includes in gnustep-base. > Do you understand what is going on? Will LLVM keep the Traditional > Objective-C runtime API? Or maybe GNUstep will update their software? > This is very perplexing. I'm fairly sure that GNUstep will update their software. ;-) Thanks
permissions to resolve bugs
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 this is not the right place to ask. Thanks
Re: permissions to resolve bugs
> 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...@emailmachine" to set it up correctly. Ah! That worked like a charm. Thanks a lot! :-) > PS I noticed you forgot to send the patches to gcc-patc...@. Even > patches which are committed and written by maintainers should be sent > there. Ok - will do - I didn't know that. It sounds like a good idea. :-) I'll post them right now. Thanks
Merging Apple's Objective-C 2.0 compiler changes
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 modifications in that we'd merge the Apple/NeXT runtime support as well. :-) They don't have to do any work. Thanks
Re: Merging Apple's Objective-C 2.0 compiler changes
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 copyright notices on all files mention the "Free Software Foundation Inc." as the copyright holder. I guess that means the changes have already been assigned to the FSF and we're free to merge ? :-) Thanks
Re: Merging Apple's Objective-C 2.0 compiler changes
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 branch, and it contains most of the functionality (so it's very useful) but unfortunately it's quite old (eg. it's still using c-parse.in to parse). Why don't you upload one of the recent Apple GCC tarballs in a branch on the FSF server ? It won't change/cost anything for Apple (the code is already distributed to the world under GPL v2+) but it means changes could be merged back into the FSF GCC which could have much better support for Apple platforms. More choice of compilers for Apple users is surely good for Apple. :-) You don't have to do it, but contributing changes back to the original project seems to be the right, honourable thing to do, particularly when it doesn't cost anything. And most/all improvements you make to GCC are for Apple machines, so certainly you want these improvements back into the FSF GCC to get more software work on Apple machines and sell more of them. :-) Thanks
Re: Merging Apple's Objective-C 2.0 compiler changes
>> 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 and for runtime libraries. So is it Ok to import testcases (in this case, from Apple's own GCC) without a copyright assignment ? :-) If we're merging from a very old branch, with all the updates and changes required (and also, the changes required to support the GNU runtime), it would be helpful if we can test the final result against the same testcases used in Apple's GCC to make sure the resulting compiler (which will undoubtely have different internals) is at least not diverging too much in terms of behaviour. Thanks
Clarification on who can approve Objective-C/Objective-C++ parser patches
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 the Objective-C front-end, and the Objective-C/Objective-C++ maintainers are in charge of approving it. Once they approve it, I can commit. Is that correct ? Do I need to wait for approval from the C/C++ frontend maintainers as well even if the execution path is only ever used when parsing Objective-C/Objective-C++ ? Thanks PS: Obviously I'm very happy to address any concerns anyone may have with any patch, and I won't commit any patch where there is any objection (certainly not from a C/C++ frontend maintainer), but my question is mostly about what I am supposed to do if the Objective-C/Objective-C++ maintainer approves my patch and nobody else says anything.
Re: Clarification on who can approve Objective-C/Objective-C++ parser patches
>> 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 approve it, I can commit. >> >> Is that correct ? > Yes. I generally expect ObjC maintainers to review changes to those parts > of c-parser.c. Thanks Joseph that clarifies it. :-) Thanks
Re: Clarification on who can approve Objective-C/Objective-C++ parser patches
Thanks Joseph Is it confirmed that this is the opinion of the C++ FE maintainers as well ? Can we get that clarified ? Do they want to review Objective-C++ patches ? (I'm still personally of the opinion the Objective-C++ maintainer should approve Objective-C++ patches, but Mike tells me 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...@gnu.org" Subject: Re: Clarification on who can approve Objective-C/Objective-C++ parser patches On Thu, 23 Sep 2010, Nicola Pero wrote: > 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 approve it, I can commit. > > Is that correct ? Yes. I generally expect ObjC maintainers to review changes to those parts of c-parser.c. -- Joseph S. Myers jos...@codesourcery.com
Re: Range-based for in c++98
>> 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 accept the ':' or split it in two. Both options
> are well beyond my intentions.
I just implemented "fast enumeration" (ie, "for (object in array) { ... }")
for Objective-C, and I was now planning on doing it for Objective-C++ too. ;-)
If you're doing range-based for-loops for C++, we may as well share ideas ;-)
What I've done for Objective-C fast enumeration (and what Apple did before me
as well)
is implemented your idea of modifying the declaration parsing to accept ':'
(well, 'in'
in the ObjC case) to terminate a declaration in that context:
* when you start parsing the 'for', a flag is turned on in the parser that
means that
we are "maybe in a fast enumeration"
* then, you go on parsing your usual C for loop, but the code that parses
expressions/declarations
has a special case for when it's "maybe in a fast enumeration", in which case
it accepts
"in" as terminating the expression/declaration (as well as ";"), and moreover
if it finds "in" in
there, it will save the declaration specially and make sure to communicate back
to the for
parsing code that we are "really" in a fast enumeration
* when the initial expression/declaration has been parsed, the for parsing
code turns off the
"maybe in a fast enumeration" flag; it now knows whether it's a normal for loop
or a fast enumeration
one and everything is easy from there on
It sounds like the same could apply to C++ range-based for-loops ? Except you
use ':' instead
of 'in' ? We could almost share the code - ie, set a single flag in the
C++/ObjC++ parser to say we are
at the beginning of a 'for' loop, and have that flag turn on recognizing ':'
(for range-based loops)
and 'in' (only if (dialect_objc()), for fast ObjC++ enumeration) as terminating
declarations.
The main disadvantage of doing things this way is making sure you won't
misunderstand a ':' (or 'in')
as meaning a range-based for-loop (or fast enumeration loop) when it isn't.
The best defense IMO is to
make sure ":" is only recognized in this way at the end of a declaration (where
normally a ';' would be)
(this is harder in Objective-C, but should be easier in Objective-C++).
It's worth trying to think of valid cases where you'd use a ":" inside a C for
loop though.
Anyway, let me know if this makes any sense or if I missed everything. Am I
right that the beginning
of a C++ range-based for-loop is identical to a standard C for loop up until
the ':' ? If not, obviously
this technique won't work. ;-)
Thanks
Re: Merging Apple's Objective-C 2.0 compiler changes
It'll be very happy to do that; I like writing documentation. But yesterday night I was playing with testcases for @property from the Apple llvm-gcc compiler and realized a number of problems in our implementation. I want to fix these first as some of them are major bugs and I want to fix 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: g...@gnu.org, "Mike Stump" , develo...@sandoe-acoustics.co.uk Subject: Re: Merging Apple's Objective-C 2.0 compiler changes Nicola, Iain, Mike, It would be great if you all could update http://gcc.gnu.org/gcc-4.6/cxx0x_status.html and related with all the great work that has gone into Objective-C++ recently. Those of us hoping to play with the new Objective-C want to know. ;-) Thank you, Ed
RE: __ghtread_recursive_mutex_destroy missing
> 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.h, so we can't properly > cleanup recursive mutexes in libstdc++ > > Any objections if I prepare a patch to add > __gthread_recursive_mutex_destroy to each gthr header? It makes sense. libobjc could use these as well; all mutexes in libobjc are recursive mutexes. At the moment libobjc uses __gthread_objc_mutex_xxx and similar, but it should probably move to use __gthread_recursive_mutex_xxx. Thanks
