[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2019-06-01 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

Iain Sandoe  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #23 from Iain Sandoe  ---
track the progress to solving this with the meta-bug.

*** This bug has been marked as a duplicate of bug 90709 ***

[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2019-05-07 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #22 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #21)
> (In reply to Eric Gallager from comment #20)
> > (In reply to Dominique d'Humieres from comment #18)
> > > For the record with darwin15 I had to add
> > > 
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/
> > > NSEnumerator.h
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSObject.h
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSValue.h
> > > 
> > > from the 10.9 SDK to
> > > 
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSArray.h
> > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSString.h
> > > /usr/include/objc/NSObject.h
> > 
> > that seems dangerous
> 
> Not so dangerous as it seems.
> 
> Many (most, in fact) of the failures seen from GCC Objective-C are caused by
> missing support for new features that have been introduced into the vendor's
> headers.  Short list: Apple Blocks, Lightweight Generics, Nullability,
> Syntactic sugar on ID.

Blocks support at least is bug 78352; are there bugs open for the other 3? 

> I'm working on a set of replacement test-suite headers that allow us to
> test the things that _do_ work on GCC Objective-C, and expose any real
> regressions.
> 
> Tests on Darwin13 and earlier show that we are not in such bad shape as the
> header fails make it appear.
> 
> I hope to get these test fixes (there's a set of three PRs related to excess
> fails on Yosemite+) in place soon - and to back port them to the open
> branches.

[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2019-02-05 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #21 from Iain Sandoe  ---
(In reply to Eric Gallager from comment #20)
> (In reply to Dominique d'Humieres from comment #18)
> > For the record with darwin15 I had to add
> > 
> > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/
> > NSEnumerator.h
> > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSObject.h
> > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSValue.h
> > 
> > from the 10.9 SDK to
> > 
> > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSArray.h
> > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSString.h
> > /usr/include/objc/NSObject.h
> 
> that seems dangerous

Not so dangerous as it seems.

Many (most, in fact) of the failures seen from GCC Objective-C are caused by
missing support for new features that have been introduced into the vendor's
headers.  Short list: Apple Blocks, Lightweight Generics, Nullability,
Syntactic sugar on ID.  I'm working on a set of replacement test-suite headers
that allow us to test the things that _do_ work on GCC Objective-C, and expose
any real regressions.

Tests on Darwin13 and earlier show that we are not in such bad shape as the
header fails make it appear.

I hope to get these test fixes (there's a set of three PRs related to excess
fails on Yosemite+) in place soon - and to back port them to the open branches.

[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2019-02-04 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #20 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #18)
> For the record with darwin15 I had to add
> 
> /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/
> NSEnumerator.h
> /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSObject.h
> /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSValue.h
> 
> from the 10.9 SDK to
> 
> /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSArray.h
> /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSString.h
> /usr/include/objc/NSObject.h

that seems dangerous

[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2017-11-01 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78352

--- Comment #19 from Eric Gallager  ---
Bug 78352 is related

[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2015-12-12 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #18 from Dominique d'Humieres  ---
For the record with darwin15 I had to add

/System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSEnumerator.h
/System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSObject.h
/System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSValue.h

from the 10.9 SDK to

/System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSArray.h
/System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSString.h
/usr/include/objc/NSObject.h

[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2014-12-22 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #17 from Iain Sandoe  ---
(In reply to m...@gcc.gnu.org from comment #16)
> We can fixincludes NS_BLOCKS_AVAILABLE support back in, this would disappear
> interfaces that cannot be supported.  In the past, this was a safe thing to
> do, and might well be still safe wrt the runtime.
> 
> Deeper language issues would likely need someone to do real work.  No really
> nice fix for that other than someone who wanted to do the work stepping
> forward.  Until then, SDK support for older OSes might be the old way to get
> code compiled on newer systems.
> 
> We should be able to steal code from MIT style runtimes to put into newer
> systems, if we can get FSF approval for incorporating code they don't own. 
> This should be easy enough, we don't vend sell or ship a competing abi
> compatible runtime, so, bundling one I think should be trivial, if we want
> to.

two things here:
(1) making FSF ObjC useful again on Darwin - the only solution there
realistically is to implement blocks [TBH, this applies outside of ObjC too]. 
Likely there are two candidates for that job - mrs and ids .. ;) .. if there
were some way to split the task up..  I believe this is rapidly becoming a
show-stopper for FSF GCC on darwin. :(

(2) Having a non-fragile ObjC library on Linux (and/or other interested *nix
hosts).  My understanding is that David Chisnall's libobjc2 might fit the bill
for this (BSD license) ..


[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2014-12-22 Thread mrs at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #16 from mrs at gcc dot gnu.org  ---
We can fixincludes NS_BLOCKS_AVAILABLE support back in, this would disappear
interfaces that cannot be supported.  In the past, this was a safe thing to do,
and might well be still safe wrt the runtime.

Deeper language issues would likely need someone to do real work.  No really
nice fix for that other than someone who wanted to do the work stepping
forward.  Until then, SDK support for older OSes might be the old way to get
code compiled on newer systems.

We should be able to steal code from MIT style runtimes to put into newer
systems, if we can get FSF approval for incorporating code they don't own. 
This should be easy enough, we don't vend sell or ship a competing abi
compatible runtime, so, bundling one I think should be trivial, if we want to.


[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2014-12-22 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #15 from Dominique d'Humieres  ---
With the patch in comment 14, I get

=== obj-c++ Summary for unix/-m64 ===

# of expected passes3073
# of unexpected failures13
# of expected failures19
# of unresolved testcases8
# of unsupported tests74

=== obj-c++ Summary ===

# of expected passes6207
# of unexpected failures24
# of expected failures21
# of unresolved testcases16
# of unsupported tests142

and

=== objc Summary for unix/-m64 ===

# of expected passes5939
# of unexpected failures27
# of expected failures6
# of unresolved testcases10
# of unsupported tests91

=== objc Summary ===

# of expected passes12045
# of unexpected failures43
# of expected failures12
# of unresolved testcases20
# of unsupported tests176

The additional failures compared to the use of the 10.9 SDK are

FAIL: obj-c++.dg/torture/strings/const-cfstring-1.mm   -O*  -fnext-runtime
(test for excess errors)
FAIL: objc.dg/torture/strings/const-cfstring-1.m   -O*  -fnext-runtime (test
for excess errors)
FAIL: objc.dg/objc-foreach-4.m -fnext-runtime (test for excess errors)
FAIL: objc.dg/objc-foreach-5.m -fnext-runtime (test for excess errors)

Apparently they are related to the fact that NS_BLOCKS_AVAILABLE is no longer
checked.


[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2014-12-22 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #14 from Iain Sandoe  ---
Created attachment 34310
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34310&action=edit
Arrange for the instancetype type to be recognised

This makes "instancetype" a synonym for "id".

So, in round terms it should work as expected - however:

(a) there's nothing to prevent the User from using it in the Wrong Place (i.e.
somewhere other than a return type).

(b) there's none of the additional analysis that instancetype allows to provide
greater type security.

So it's part #1 of N that will be needed to implement this part of the
modernisation.



NOTE that on my tests we still fail to parse the system headers owing to the
use of blocks (but that's a different, and bigger, problem).


[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2014-12-20 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #13 from Iain Sandoe  ---
I agree, kludging around headers is not going to work - we need to find time to
modernise the ObjC implementation.

it's on the TODO…

Supporting ObjC on Darwin is quite important - and we're well behind, but I
doubt anyone other than me (as things stand) is actually going to step up to do
the work.

[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2014-12-20 Thread fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #12 from Francois-Xavier Coudert  ---
Regarding the last few comments: all this comes, AFAICT, from the front-end not
recognizing "instancetype". I don't think we can get out of this by fixing
headers or anything else: it's an extension to Objective C, and if Apple is
going to use it widely, we need to support it in our front-end.

I know it's not very helpful, because I cannot code the changes myself. I've
tried to look at the front-end code to see where "id" is defined, but it's not
very clear.

In any case, what I wanted to say is: I don't think we need more analysis of
this. We need someone who can do the work :)


[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2014-12-20 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #11 from Dominique d'Humieres  ---
> Note that some remaining errors will go away if the same is used for
> /System/Library/Frameworks/Foundation.framework/Headers/NSArray.h.

This fixes the failures of objc.dg/objc-foreach-(4|5).m.


[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2014-12-20 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #10 from Dominique d'Humieres  ---
If I replace the files /usr/include/objc/NSObject.h and
/System/Library/Frameworks/Foundation.framework/Headers/NSString.h with the
corresponding files from
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/
The errors reduce to

=== obj-c++ tests ===


Running target unix/-m32
FAIL: obj-c++.dg/cxx-ivars-3.mm -fnext-runtime execution test
FAIL: obj-c++.dg/gnu-api-2-objc.mm -fnext-runtime execution test

=== obj-c++ Summary for unix/-m32 ===

# of expected passes3151
# of unexpected failures2
# of expected failures2
# of unsupported tests68

Running target unix/-m64
FAIL: obj-c++.dg/gnu-api-2-objc.mm -fnext-runtime execution test
FAIL: obj-c++.dg/isa-field-1.mm -fnext-runtime (test for excess errors)
FAIL: obj-c++.dg/try-catch-2.mm -fnext-runtime execution test
FAIL: obj-c++.dg/try-catch-9.mm -fnext-runtime execution test

=== obj-c++ Summary for unix/-m64 ===

# of expected passes3090
# of unexpected failures4
# of expected failures19
# of unsupported tests74

=== obj-c++ Summary ===

# of expected passes6241
# of unexpected failures6
# of expected failures21
# of unsupported tests142
/opt/gcc/p_build/gcc/testsuite/obj-c++/../../xg++  version 5.0.0 20141219
(experimental) [trunk revision 218883p2] (GCC) 

=== objc tests ===


Running target unix/-m32
FAIL: objc.dg/call-super-2.m -fnext-runtime  (test for warnings, line 104)
FAIL: objc.dg/call-super-2.m -fnext-runtime  (test for warnings, line 74)
FAIL: objc.dg/gnu-api-2-objc.m -fnext-runtime execution test
FAIL: objc.dg/ivar-scope-4.m -fnext-runtime execution test
FAIL: objc.dg/objc-foreach-4.m -fnext-runtime (test for excess errors)
UNRESOLVED: objc.dg/objc-foreach-4.m -fnext-runtime compilation failed to
produce executable
UNRESOLVED: objc.dg/objc-foreach-5.m -fnext-runtime  scan-assembler
_addStuffUp:
FAIL: objc.dg/objc-foreach-5.m -fnext-runtime (test for excess errors)

=== objc Summary for unix/-m32 ===

# of expected passes6124
# of unexpected failures6
# of expected failures6
# of unresolved testcases2
# of unsupported tests85

Running target unix/-m64
FAIL: objc.dg/call-super-2.m -fnext-runtime  (test for warnings, line 104)
FAIL: objc.dg/call-super-2.m -fnext-runtime  (test for warnings, line 74)
FAIL: objc.dg/exceptions-2.m -fnext-runtime execution test
FAIL: objc.dg/gnu-api-2-objc.m -fnext-runtime execution test
FAIL: objc.dg/isa-field-1.m -fnext-runtime (test for excess errors)
FAIL: objc.dg/objc-foreach-4.m -fnext-runtime (test for excess errors)
UNRESOLVED: objc.dg/objc-foreach-4.m -fnext-runtime compilation failed to
produce executable
UNRESOLVED: objc.dg/objc-foreach-5.m -fnext-runtime  scan-assembler
_addStuffUp:
FAIL: objc.dg/objc-foreach-5.m -fnext-runtime (test for excess errors)
FAIL: objc.dg/torture/forward-1.m   -O0  -fnext-runtime execution test
FAIL: objc.dg/torture/forward-1.m   -O1  -fnext-runtime execution test
FAIL: objc.dg/torture/forward-1.m   -O2  -fnext-runtime execution test
FAIL: objc.dg/torture/forward-1.m   -O2 -flto  -fnext-runtime execution test
FAIL: objc.dg/torture/forward-1.m   -O2 -flto -flto-partition=none 
-fnext-runtime execution test
FAIL: objc.dg/torture/forward-1.m   -O3 -fomit-frame-pointer  -fnext-runtime
execution test
FAIL: objc.dg/torture/forward-1.m   -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  -fnext-runtime execution test
FAIL: objc.dg/torture/forward-1.m   -O3 -fomit-frame-pointer -funroll-loops 
-fnext-runtime execution test
FAIL: objc.dg/torture/forward-1.m   -O3 -g  -fnext-runtime execution test
FAIL: objc.dg/torture/forward-1.m   -Os  -fnext-runtime execution test

=== objc Summary for unix/-m64 ===

# of expected passes5957
# of unexpected failures17
# of expected failures6
# of unresolved testcases2
# of unsupported tests91

=== objc Summary ===

# of expected passes12081
# of unexpected failures23
# of expected failures12
# of unresolved testcases4
# of unsupported tests176
/opt/gcc/p_build/gcc/xgcc  version 5.0.0 20141219 (experimental) [trunk
revision 218883p2] (GCC) 

The new failures compared to darwin13 are

FAIL: obj-c++.dg/isa-field-1.mm -fnext-runtime (test for excess errors)

with -m64,

FAIL: objc.dg/objc-foreach-4.m -fnext-runtime (test for excess errors)
UNRESOLVED: objc.dg/objc-foreach-4.m -fnext-runtime compilation failed to
produce executable
UNRESOLVED: objc.dg/objc-foreach-5.m -fnext-runtime  scan-assembler
_addStuffUp:
FAIL: objc.dg/objc-foreach-5.m -fnext-runtime (test for excess errors)

with -m32, and

FAIL: objc.dg/isa-field-1.m -fnext-runtime (test for excess errors)
FAIL: objc.dg/objc-foreach-4.m -fnext-runtime (test for excess errors)
UNRESOLVED: objc.dg/objc-for

[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2014-11-20 Thread howarth at bromo dot med.uc.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #9 from howarth at bromo dot med.uc.edu ---
(In reply to Eric Gallager from comment #8)
> (In reply to howarth from comment #7)
> > 
> > If I remember correctly, the blocks issue is problematic because of the
> > blocks runtime's license, so that whole package would have to be reverse
> > engineered to be under GPLv3, no?
> 
> I just googled the text of the license for the blocks runtime (i.e.
> libclosure), and it looks like it's the MIT license... can't MIT-licensed
> packages be used in GPLed projects? After accounting for the ambiguity of
> the name, the GNU license list seems to say they're compatible:
> 
> https://www.gnu.org/licenses/license-list.html#X11License
> or
> https://www.gnu.org/licenses/license-list.html#Expat
> 
> The libclosure license can be found at the top of:
> http://opensource.apple.com/source/libclosure/libclosure-65/
> BlockImplementation.txt
> or
> http://opensource.apple.com/source/libclosure/libclosure-65/BlockSpec.rtf
> (if anyone wants to verify)

The relevant files are those in compiler-rt/lib/BlocksRuntime. There are only
three files and those all have an Apple license...

 * Copyright 2008-2010 Apple, Inc. Permission is hereby granted, free of
charge,
 * to any person obtaining a copy of this software and associated documentation
 * files (the "Software"), to deal in the Software without restriction,
 * including without limitation the rights to use, copy, modify, merge,
publish,
 * distribute, sublicense, and/or sell copies of the Software, and to permit
 * persons to whom the Software is furnished to do so, subject to the following
 * conditions:
 * 
 * The above copyright notice and this permission notice shall be included in
 * all copies or substantial portions of the Software.
 * 
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
 * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
 * SOFTWARE.


[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2014-11-20 Thread egall at gwmail dot gwu.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #8 from Eric Gallager  ---
(In reply to howarth from comment #7)
> 
> If I remember correctly, the blocks issue is problematic because of the
> blocks runtime's license, so that whole package would have to be reverse
> engineered to be under GPLv3, no?

I just googled the text of the license for the blocks runtime (i.e.
libclosure), and it looks like it's the MIT license... can't MIT-licensed
packages be used in GPLed projects? After accounting for the ambiguity of the
name, the GNU license list seems to say they're compatible:

https://www.gnu.org/licenses/license-list.html#X11License
or
https://www.gnu.org/licenses/license-list.html#Expat

The libclosure license can be found at the top of:
http://opensource.apple.com/source/libclosure/libclosure-65/BlockImplementation.txt
or
http://opensource.apple.com/source/libclosure/libclosure-65/BlockSpec.rtf
(if anyone wants to verify)


[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2014-11-08 Thread howarth at bromo dot med.uc.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #7 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Francois-Xavier Coudert from comment #4)
> > (In reply to Dominique d'Humieres from comment #3)
> > > Does it means that 'id' should be replaced with 'instancetype' in failing
> > > tests? What about the gnu-runtime?
> > 
> > No, we need to make the compiler understand 'instancetype'.
> 
> sadly, we spend almost all our darwin (volunteer) time chasing fall-out from
> other patches and very little remains for working on new features :-(
> 
> I'd love to modernise the ObjC stuff - bearing in mind that the biggest
> killer there is that we don't support blocks in GCC (ObjC is essentially not
> much usable on darwin >= 11, without that).
> 
> on the TODO ..

If I remember correctly, the blocks issue is problematic because of the blocks
runtime's license, so that whole package would have to be reverse engineered to
be under GPLv3, no?


[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2014-11-08 Thread howarth at bromo dot med.uc.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #6 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Francois-Xavier Coudert from comment #4)
> > (In reply to Dominique d'Humieres from comment #3)
> > > Does it means that 'id' should be replaced with 'instancetype' in failing
> > > tests? What about the gnu-runtime?
> > 
> > No, we need to make the compiler understand 'instancetype'.
> 
> sadly, we spend almost all our darwin (volunteer) time chasing fall-out from
> other patches and very little remains for working on new features :-(
> 
> I'd love to modernise the ObjC stuff - bearing in mind that the biggest
> killer there is that we don't support blocks in GCC (ObjC is essentially not
> much usable on darwin >= 11, without that).
> 
> on the TODO ..

   Perhaps Iain can chime in on this. My recollection is that, while all of the
changes out of the Apple gcc branch from prior to the GPLv3 rupture were merged
in a few years ago, only limited attempts were made towards syncing with
further upstream changes. I think those mainly involved adapting to breakage
from system header changes. IMHO, it s pretty much a lost cause unless
resources are committed to attempt to match the feature set of the current
objective c in clang/llvm. I don't even know if Apple still attempts to
distinguish the objective c changes. I think it went from Objective C 2.0 to
Modern Objective C, no?
   Interestingly, if you scan the /usr/include/objc headers in Yosemite for
copyright changes only NSObjCRuntime.h and NSObject.h have 2012 copyrights with
the rest at 2007 or earlier. FYI, I believe this lists the changes in Modern
Objective C...

https://developer.apple.com/library/ios/releasenotes/ObjectiveC/ModernizationObjC/AdoptingModernObjective-C/AdoptingModernObjective-C.html


[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2014-11-08 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #5 from Iain Sandoe  ---
(In reply to Francois-Xavier Coudert from comment #4)
> (In reply to Dominique d'Humieres from comment #3)
> > Does it means that 'id' should be replaced with 'instancetype' in failing
> > tests? What about the gnu-runtime?
> 
> No, we need to make the compiler understand 'instancetype'.

sadly, we spend almost all our darwin (volunteer) time chasing fall-out from
other patches and very little remains for working on new features :-(

I'd love to modernise the ObjC stuff - bearing in mind that the biggest killer
there is that we don't support blocks in GCC (ObjC is essentially not much
usable on darwin >= 11, without that).

on the TODO ..


[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2014-11-08 Thread fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #4 from Francois-Xavier Coudert  ---
(In reply to Dominique d'Humieres from comment #3)
> Does it means that 'id' should be replaced with 'instancetype' in failing
> tests? What about the gnu-runtime?

No, we need to make the compiler understand 'instancetype'.


[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2014-11-08 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #3 from Dominique d'Humieres  ---
(In reply to Francois-Xavier Coudert from comment #2)
> > I suppose as a first approach, we could make it equivalent to id.
>
> Not really, apparently: the answer there gives a quite complete description
> (and quotes the official Apple docs): http://stackoverflow.com/a/14652187

Does it means that 'id' should be replaced with 'instancetype' in failing
tests? What about the gnu-runtime?


[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2014-11-07 Thread fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #2 from Francois-Xavier Coudert  ---
(In reply to Francois-Xavier Coudert from comment #1)
> I suppose as a first approach, we could make it equivalent to id.

Not really, apparently: the answer there gives a quite complete description
(and quotes the official Apple docs): http://stackoverflow.com/a/14652187


[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

2014-11-01 Thread fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-01
 CC||fxcoudert at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Francois-Xavier Coudert  ---
Some NSObject methods that used to return (id) now return (instancetype). Only
NSObject has this, and the list includes: self, retain, autorelease, init, new,
alloc*

The "What's new in OS X Yosemite" document at
https://developer.apple.com/Library/mac/releasenotes/MacOSX/WhatsNewInOSX/WhatsNewInOSX.pdf
says:

"Many frameworks on OS X have adopted small interface changes that take
advantage of modern Objective-C syntax: […] Initialization methods are updated
to have a return value of instancetype instead of id."

It is documented further in Apple docs, or in clang here:
http://clang.llvm.org/docs/LanguageExtensions.html

I suppose as a first approach, we could make it equivalent to id.