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

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

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> 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 <fxcoudert at gcc dot gnu.org> ---
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.
>From gcc-bugs-return-465538-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 01 13:27:55 2014
Return-Path: <gcc-bugs-return-465538-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24528 invoked by alias); 1 Nov 2014 13:27:54 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 24511 invoked by uid 48); 1 Nov 2014 13:27:50 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63705] function template specialization outside namespace rejected with C++11
Date: Sat, 01 Nov 2014 13:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-63705-4-lKh4WG0oGO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63705-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63705-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00010.txt.bz2
Content-length: 1290

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc705

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-11-01
     Ever confirmed|0                           |1

--- Comment #3 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Possible (untested) fix:

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 2cf10f4..1171b5d 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -780,15 +780,15 @@ check_specialization_namespace (tree tmpl)
       error ("specialization of %qD must appear at namespace scope", tmpl);
       return false;
     }
-  if (is_associated_namespace (current_namespace, tpl_ns))
-    /* Same or super-using namespace.  */
-    return true;
-  else
+  if (!is_associated_namespace (current_namespace, tpl_ns) &&
+      (cxx_dialect < cxx11))
     {
       permerror (input_location, "specialization of %qD in different
namespace", tmpl);
       permerror (input_location, "  from definition of %q+#D", tmpl);
       return false;
     }
+
+  return true;
 }

 /* SPEC is an explicit instantiation.  Check that it is valid to

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

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #2 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(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

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
(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

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #4 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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

[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

[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

[egall at gwmail dot gwu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

Eric Gallager <egall at gwmail dot gwu.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egall at gwmail dot gwu.edu

--- Comment #8 from Eric Gallager <egall at gwmail dot gwu.edu> ---
(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

[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

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
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 passes        3151
# of unexpected failures    2
# of expected failures        2
# of unsupported tests        68

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 passes        3090
# of unexpected failures    4
# of expected failures        19
# of unsupported tests        74

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

# of expected passes        6241
# of unexpected failures    6
# of expected failures        21
# of unsupported tests        142
/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 passes        6124
# of unexpected failures    6
# of expected failures        6
# of unresolved testcases    2
# of unsupported tests        85

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 passes        5957
# of unexpected failures    17
# of expected failures        6
# of unresolved testcases    2
# of unsupported tests        91

        === objc Summary ===

# of expected passes        12081
# of unexpected failures    23
# of expected failures        12
# of unresolved testcases    4
# of unsupported tests        176
/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-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

with -m64. The errors for are of the kind

objc[1436]: -[Forwarder display]: unrecognized selector sent to instance
0x7f9ce9d04f30 (no message forward handler is installed)

Is there a canonical way to force obj(c|-c++) to use the include files in
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/
instead of the native files in /usr and /System?

Note that some remaining errors will go away if the same is used for
/System/Library/Frameworks/Foundation.framework/Headers/NSArray.h.

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

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> 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

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #12 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #13 from Iain Sandoe <iains at gcc dot gnu.org> ---
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.
>From gcc-bugs-return-471462-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Dec 20 17:37:07 2014
Return-Path: <gcc-bugs-return-471462-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24621 invoked by alias); 20 Dec 2014 17:37:06 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 24562 invoked by uid 48); 20 Dec 2014 17:37:01 -0000
From: "howarth at bromo dot med.uc.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/64368] [5 Regression] Several libstdc++ test failures on darwin after r218964.
Date: Sat, 20 Dec 2014 17:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: howarth at bromo dot med.uc.edu
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64368-4-UxydexLGVv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64368-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64368-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-12/txt/msg02469.txt.bz2
Content-length: 905

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd368

--- Comment #5 from howarth at bromo dot med.uc.edu ---
(In reply to Francois-Xavier Coudert from comment #3)
> Appeared between 218883 (works) and 218985 (fails) [I'm glad my nightly
> tester is useful!]
>
> Culprits are:
>
> r218984 | redi | 2014-12-20 01:19:40 +0100 (Sat, 20 Dec 2014) | 4 lines
>
> Fix duplicate symbol errors in Darwin bootstrap.
>
>         * src/c++98/locale-inst.cc (__add_grouping, __pad, __int_to_char):
>         Only compile for old ABI.
>
> r218964 | redi | 2014-12-19 19:16:39 +0100 (Fri, 19 Dec 2014) | 183 lines
>
> New std::string implementation.

The r218964 commit can't be at fault as I have posted testing at r218877...

https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg02450.html

and the libstdc++ results are pristine. The commit at r218984 seems bizarre as
it has no associated PR for the supposed bug.

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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> ---
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

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #15 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
With the patch in comment 14, I get

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

# of expected passes        3073
# of unexpected failures    13
# of expected failures        19
# of unresolved testcases    8
# of unsupported tests        74

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

# of expected passes        6207
# of unexpected failures    24
# of expected failures        21
# of unresolved testcases    16
# of unsupported tests        142

and

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

# of expected passes        5939
# of unexpected failures    27
# of expected failures        6
# of unresolved testcases    10
# of unsupported tests        91

        === objc Summary ===

# of expected passes        12045
# of unexpected failures    43
# of expected failures        12
# of unresolved testcases    20
# of unsupported tests        176

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

[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 <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

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651

--- Comment #17 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to mrs@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) ..