https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
> > >
> > >
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/Version
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/Fra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
S
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
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
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 runt
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 tes
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 t
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
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 extensio
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.
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/
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 licen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651
Eric Gallager changed:
What|Removed |Added
CC||egall at gwmail dot gwu.edu
--- Comment
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 b
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 b
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
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
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 descripti
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
23 matches
Mail list logo