[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Created attachment 34632
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34632&action=edit
compressed preprocessed file

See also https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03581.html.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-31
     Ever confirmed|0                           |1

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
See also pr64885.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #3)
> This looks like a bug in darwin's system headers which should be using
> __noreturn__ not noreturn and __deprecated__ not deprecate, but I'll change
> the test to avoid it.

hmm .. so cdefs.h does indeed use __attribute__((no return)) and
__attribute__((deprecated)).

(although both are still valid by GCC documentation)

What about a fixincludes? (not familiar with what level of stuff is feasible
there).

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #4)
> hmm .. so cdefs.h does indeed use __attribute__((no return)) and
> __attribute__((deprecated)).
> 
> (although both are still valid by GCC documentation)

It's valid but the point is that "noreturn" is not a reserved name in any C or
POSIX standard, nor in any C++ standard before C++11, so users can reasonably
expect to be able to define a macro with that name and not get problems. In
order to support such valid usr code system headers should avoid using that
name, and should use the __noreturn__ form that is not a valid macro name for
users to define.

The point of the new test is to ensure libstdc++ itself doesn't contain this
kind of bug ... but it fails because darwin has the bug, even though the
libstdc++ headers no longer have it.

> What about a fixincludes? (not familiar with what level of stuff is feasible
> there).

I think this could be solved with fixincludes, but that seems like something
for stage 1. For now I might just adjust the test to stop it failing.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Perhaps unconditionally or conditionally for Darwin only include some C header
or headers before defining those macros, then include the STL headers?

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Iain Sandoe from comment #4)
> > hmm .. so cdefs.h does indeed use __attribute__((no return)) and
> > __attribute__((deprecated)).
> > 
> > (although both are still valid by GCC documentation)
> 
> It's valid but the point is that "noreturn" is not a reserved name in any C
> or POSIX standard, nor in any C++ standard before C++11, so users can
> reasonably expect to be able to define a macro with that name and not get
> problems. In order to support such valid usr code system headers should
> avoid using that name, and should use the __noreturn__ form that is not a
> valid macro name for users to define.
> 
> The point of the new test is to ensure libstdc++ itself doesn't contain this
> kind of bug ... but it fails because darwin has the bug, even though the
> libstdc++ headers no longer have it.

OK, thanks for clarifying.
Perhaps, 

(a) given that the __attribute__((xyzzy)) etc. versions are in pretty wide use
"in the wild".

(b) Section 6.33  of the current GCC manual doesn't really mention the __xxxx__
versions and the examples throughout the section use undecorated versions (the
only example with __xxxx__ seems to be __target__). This section specifically
states the attributes may be identifiers or reserved words.

... we might implement some compatibility warning (again in the future) - or
perhaps at least add a note to the manual.

As far as Darwin's system headers, I guess someone needs to file a radar
against the current edition (but that doesn't solve things for the systems
already out there).

> > What about a fixincludes? (not familiar with what level of stuff is feasible
> > there).
> 
> I think this could be solved with fixincludes, but that seems like something
> for stage 1. For now I might just adjust the test to stop it failing.

for my part, I'm happy with whatever solution you think is reasonable for
stage4 - and we can re-visit this in stage #1.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[howarth at bromo dot med.uc.edu]

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

--- Comment #8 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #7)

Certainly getting the current GCC manual in sync with this new restriction and
emitting a clear warning in the gcc 5.0 release compiler would get the issue
more traction with upstream developers.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #7)
> (a) given that the __attribute__((xyzzy)) etc. versions are in pretty wide
> use "in the wild".
> 
> (b) Section 6.33  of the current GCC manual doesn't really mention the
> __xxxx__ versions and the examples throughout the section use undecorated
> versions (the only example with __xxxx__ seems to be __target__). This
> section specifically states the attributes may be identifiers or reserved
> words.

Right, I think it's only mentioned at
https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

> ... we might implement some compatibility warning (again in the future) - or
> perhaps at least add a note to the manual.

I'm not sure a waning is appropriate. Users are welcome to use the non-uglified
attributes, it's their responsibility to ensure their own attributes don't
clash with their own macros. 


(In reply to howarth from comment #8)
> Certainly getting the current GCC manual in sync with this new restriction
> and emitting a clear warning in the gcc 5.0 release compiler would get the
> issue more traction with upstream developers.

There is no new restriction. 

The failing test is only intended to check that libstdc++ is consistent about
using the uglified attributes. Anything outside libstdc++ can do whatever it
wants. IMHO the C standard library headers should use the reserved names, but
the GCC manual is not the right place to document how to implement the C
standard library.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
> Perhaps unconditionally or conditionally for Darwin only include some C
> header or headers before defining those macros, then include the STL headers?

Yes, something like this:

--- a/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
@@ -18,6 +18,19 @@
 // { dg-options "-std=gnu++98" }
 // { dg-do compile }

+#ifdef __APPLE__
+// darwin headers use noreturn and deprecated, PR 64883
+#include <assert.h>
+#include <math.h>
+#include <setjmp.h>
+#include <stdlib.h>
+#include <stdio.h>
+#include <unistd.h>
+#endif
+
+// gthr-single.h uses unused, PR 64885
+#include <bits/gthr.h>
+
 // Ensure the library only uses the __name__ form for attributes.
 // Don't test 'const' because it is reserved anyway.
 #define abi_tag 1


But it's a bit fragile, as the list of C headers might vary between darwin
versions. This would be more reliable, and we still test that libstdc++ doesn't
use those names on all other targets:

--- a/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
@@ -18,12 +18,18 @@
 // { dg-options "-std=gnu++98" }
 // { dg-do compile }

+// gthr-single.h uses unused, see PR 64885
+#include <bits/gthr.h>
+
 // Ensure the library only uses the __name__ form for attributes.
 // Don't test 'const' because it is reserved anyway.
 #define abi_tag 1
 #define always_inline 1
-#define deprecated 1
-#define noreturn 1
+#ifndef __APPLE__
+// darwin headers use these, see PR 64883
+# define deprecated 1
+# define noreturn 1
+#endif
 #define packed 1
 #define pure 1
 #define unused 1

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[howarth at bromo dot med.uc.edu]

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

--- Comment #11 from howarth at bromo dot med.uc.edu ---
What is so dangerous about just using...

Index: fixincludes/inclhack.def
===================================================================
--- fixincludes/inclhack.def    (revision 220306)
+++ fixincludes/inclhack.def    (working copy)
@@ -1266,6 +1266,18 @@ fix = {
 };

 /*
+ * sys/cdef.sh on Darwin should use reserved name __noreturn__
+ * rather than noreturn.
+ */
+fix = {
+  hackname  = darwin_noreturn;
+  mach      = "*-*-darwin*";
+  files     = sys/cdefs.h;
+  sed       = "s/__attribute__((noreturn))/__attribute__((__noreturn__))/g";
+  test_text = "__attribute__((noreturn))";
+};
+
+/*
  *  __private_extern__ doesn't exist in FSF GCC.  Even if it did,
  *  why would you ever put it in a system header file?
  */

...instead? It seems a whole lot simpler.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[howarth at bromo dot med.uc.edu]

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

--- Comment #12 from howarth at bromo dot med.uc.edu ---
(In reply to howarth from comment #11)

A fixincludes doesn't solve the problem as the libstdc++ test suite doesn't
seem to use those fixed headers.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[iains at gcc dot gnu.org]

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

--- Comment #13 from Iain Sandoe <iains at gcc dot gnu.org> ---
FWIW I noticed:
$ grep --exclude \*.svn\* -rH \(\(deprecated\)\) libstdc++-v3 
libstdc++-v3/include/c_global/cstdio:extern "C" char* gets (char* __s)
__attribute__((deprecated));
libstdc++-v3/include/c_std/cstdio:extern "C" char* gets (char* __s)
__attribute__((deprecated));

Which will only fire for non-glibc targets.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[iains at gcc dot gnu.org]

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

--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to howarth from comment #12)
> (In reply to howarth from comment #11)
> 
> A fixincludes doesn't solve the problem as the libstdc++ test suite doesn't
> seem to use those fixed headers.

if you refer to the patch at comment #11 - that would not be expected to be
anywhere near sufficient.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[iains at gcc dot gnu.org]

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

--- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 34640
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34640&action=edit
fixincludes to eliminate tested undecorated attributes on Darwin12.

OK, so this is a sufficient patch (on x86_64-darwin12).

I agree with Jonathan, this is not stage #4 material - unless Jack can come up
with some more comprehensive testing than the GCC testsuite.

a) I don't claim it's all *necessary*.
b) We need to check across the whole of the darwin set to make sure we've
caught all the files needed.

c) FWIW, a quick scan of /use/include on Ubuntu 10.04 and Ubuntu 14.04 shows
that there are a lot of cases in Linux where the "undecorated" attributes are
used (esp. "packed") so there might need to be some tweaking there too.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[iains at gcc dot gnu.org]

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

--- Comment #16 from Iain Sandoe <iains at gcc dot gnu.org> ---
yeah, the header list I've used is excessive.

I made test for obj-c++ recently that includes all the headers mentioned in
n4296 Section 17.6.1.1

the following:
$ g++ /GCC/gcc-trunk/gcc/testsuite/obj-c++.dg/standard-headers.mm -H 2>&1 |
grep usr/include |sed s,^\[\.\]\*\ ,, |sort -u

should be enough to identify all system headers included directly or indirectly
by that list.  I suppose we need only to apply fixincludes to them.

Perhaps there's a better check ..
(and my fixincludes-fu is ~0, so some review would be needed there).

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Author: redi
Date: Sun Feb  1 15:11:08 2015
New Revision: 220318

URL: https://gcc.gnu.org/viewcvs?rev=220318&root=gcc&view=rev
Log:
    PR libstdc++/64883
    * include/c_global/cstdio (gets): Use __deprecated__ attribute instead
    of deprecated.
    * include/c_std/cstdio (gets): Likewise.
    * testsuite/17_intro/headers/c++1998/all_attributes.cc: Avoid clashing
    with attributes used in darwin headers.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/c_global/cstdio
    trunk/libstdc++-v3/include/c_std/cstdio
    trunk/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.0

--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The test should pass on darwin now, please let me know if not.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[iains at gcc dot gnu.org]

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

--- Comment #19 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #18)
> The test should pass on darwin now, please let me know if not.

I think we need (at least):
diff --git a/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
b/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
index 76a935e..6fc362a 100644
--- a/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc
@@ -26,11 +26,11 @@
 // darwin headers use these, see PR 64883
 # define deprecated 1
 # define noreturn 1
+# define visibility 1
 #endif
 #define packed 1
 #define pure 1
 #define unused 1
-#define visibility 1

 #include <bits/stdc++.h> // TODO: this is missing from <bits/extc++.h>
 #include <bits/extc++.h>
diff --git a/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_attributes.cc
b/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_attributes.cc
index c7ec27a..0726e3f 100644
--- a/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_attributes.cc
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_attributes.cc
@@ -22,11 +22,14 @@
 // Don't test 'const' and 'noreturn' because they are reserved anyway.
 #define abi_tag 1
 #define always_inline 1
-#define deprecated 1
+#ifndef __APPLE__
+// darwin headers use these, see PR 64883
+# define visibility 1
+# define deprecated 1
+#endif
 #define packed 1
 #define pure 1
 #define unused 1
-#define visibility 1

 #include <bits/stdc++.h> // TODO: this is missing from <bits/extc++.h>
 #include <codecvt>       // TODO: this is missing from <bits/stdc++.h>
diff --git a/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc
b/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc
index 533a6f1..06bcb8e 100644
--- a/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc
@@ -22,11 +22,14 @@
 // Don't test 'const' and 'noreturn' because they are reserved anyway.
 #define abi_tag 1
 #define always_inline 1
-#define deprecated 1
+#ifndef __APPLE__
+// darwin headers use these, see PR 64883
+# define deprecated 1
+# define visibility 1
+#endif
 #define packed 1
 #define pure 1
 #define unused 1
-#define visibility 1

 #include <bits/stdc++.h> // TODO: this is missing from <bits/extc++.h>
 #include <shared_mutex>  // TODO: this is missing from <bits/stdc++.h>

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #34640|0                           |1
        is obsolete|                            |

--- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 34641
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34641&action=edit
minimum fixincludes to avoid errors on Darwin12.

So, here's the minimum patch (for Darwin12) accounting only for system headers
that are used by the c++ headers noted with the recipe above.

.. prob. still stage#1 material.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[dominiq at lps dot ens.fr]

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

--- Comment #21 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
In 17_intro/headers/c++*/all_attributes.cc, c++* stands for c++1998, c++200x,
and c++2014. The first instance is "fixed" now, the two other ones are still
failing.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[iains at gcc dot gnu.org]

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

--- Comment #22 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #21)
> In 17_intro/headers/c++*/all_attributes.cc, c++* stands for c++1998,
> c++200x, and c++2014. The first instance is "fixed" now, the two other ones
> are still failing.

does my incremental patch fix that on Darwin14 - I can send it to you if cut &
paste mangled.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[dominiq at lps dot ens.fr]

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

--- Comment #23 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> does my incremental patch fix that on Darwin14 - I can send it to you if
> cut & paste mangled.

If you mean the patch in comment 19, yes it does (I only applied it for c++200x
and c++2014).

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[howarth at bromo dot med.uc.edu]

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

--- Comment #24 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #19)
Confirmed that this patch eliminates the regressions for...

make -k check
RUNTESTFLAGS="conformance.exp=17_intro/headers/c++*/all_attributes.cc 
--target_board=unix'{-m32,-m64}'"

on x86_64-apple-darwin14

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[howarth at bromo dot med.uc.edu]

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

--- Comment #25 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #19)

Are we going with this fix? If so. please post it to gcc-patches with a
ChangeLog.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[iains at gcc dot gnu.org]

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

--- Comment #26 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to howarth from comment #25)
> (In reply to Iain Sandoe from comment #19)
> 
> Are we going with this fix? If so. please post it to gcc-patches with a
> ChangeLog.

was posted 3rd Feb
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00122.html

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[howarth at bromo dot med.uc.edu]

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

--- Comment #27 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #26)
> (In reply to howarth from comment #25)
> > (In reply to Iain Sandoe from comment #19)
> > 
> > Are we going with this fix? If so. please post it to gcc-patches with a
> > ChangeLog.
> 
> was posted 3rd Feb
> https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00122.html

Pinged but probably would had better exposure if posted as its a new thread for
your own patch proposal.

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[dominiq at lps dot ens.fr]

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

--- Comment #28 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Note that r220318 does not fix c++1998/all_attributes.cc for
x86_64-apple-darwin10 (see
https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01455.html) nor for
powerpc-apple-darwin9 (see
https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01454.html).

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[dominiq at lps dot ens.fr]

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

--- Comment #31 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> I've committed Iain's patch, any further changes can wait for stage 1.

Revision r221160 does not fix the failures on x86_64-apple-darwin10: see
https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg00670.html.

/opt/gcc/_clean/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:24:23:
error: expected ')' before numeric constant
 #define always_inline 1
                       ^

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org

--- Comment #32 from Jonathan Wakely <redi at gcc dot gnu.org> ---
ok ...

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|FAIL:                       |FAIL:
                   |17_intro/headers/c++*/all_a |17_intro/headers/c++*/all_a
                   |ttributes.cc (test for      |ttributes.cc (test for
                   |excess errors) on           |excess errors) on
                   |x86_64-apple-darwin14       |x86_64-apple-darwin10

--- Comment #33 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Changed the summary to x86_64-apple-darwin10 (this probably affects
powerpc-apple-darwin9 also).

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin10

[iains at gcc dot gnu.org]

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

--- Comment #34 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #33)
> Changed the summary to x86_64-apple-darwin10 (this probably affects
> powerpc-apple-darwin9 also).

correct; there is one additional needed for ppc-darwin9 and x86-darwin{9,10}

I have a suitable patch, and as discussed on irc with Jonathan had intended to
apply that version; unfortunately between investigating ipa-icf issues and
being out of the office in the US, haven't had a chance so far (thanks to
Jonathan for applying the interim one).

.. will apply an incremental change for earlier darwin as "obvious" at the
first available opportunity (unless anyone has an objection) … (about to
re-sync trunk and test).
>From gcc-bugs-return-479589-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 06 16:57:31 2015
Return-Path: <gcc-bugs-return-479589-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 113583 invoked by alias); 6 Mar 2015 16:57:31 -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 113524 invoked by uid 48); 6 Mar 2015 16:57:27 -0000
From: "boger at us dot ibm.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/64999] s390x libgo test failure in TestMemoryProfiler
Date: Fri, 06 Mar 2015 16:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: go
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: boger at us dot ibm.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ian at airs dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64999-4-lgoUY2Vz2c@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64999-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64999-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: 2015-03/txt/msg00733.txt.bz2
Content-length: 907

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

--- Comment #36 from boger at us dot ibm.com ---
I'd like to take a step back and clarify what the functions in question,
runtime_callers, runtime.Caller, and runtime.Callers should be returning:  the
pc values for the call instruction, or the pc values from the instruction
following the call?

The golang documentation for runtime.Callers says it is the pc for the
instruction after the call so I will assume that is what we want for that one.

For runtime.Caller I believe it is supposed to return the call instruction
itself but I'm not 100% sure on that.

Since runtime.Callers calls runtime_callers, I assume runtime_callers should be
providing the instruction after the call.  That means all callers of
runtime_callers should be decrementing pc values to the previous instruction if
the call instruction is what they want.

Does this sound right?

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin10

[redi at gcc dot gnu.org]

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

--- Comment #35 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #34)
> .. will apply an incremental change for earlier darwin as "obvious" at the
> first available opportunity (unless anyone has an objection) … (about to
> re-sync trunk and test).

No objection here, please go ahead, thanks.
>From gcc-bugs-return-479591-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 06 17:05:58 2015
Return-Path: <gcc-bugs-return-479591-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15707 invoked by alias); 6 Mar 2015 17:05:58 -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 15649 invoked by uid 48); 6 Mar 2015 17:05:51 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/65159] Linker forgets definition of type_info::__is_pointer_p
Date: Fri, 06 Mar 2015 17:05: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:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi 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: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cf_gcctarget bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-65159-4-NcouVXXTNP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65159-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65159-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: 2015-03/txt/msg00735.txt.bz2
Content-length: 553

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|x86_64-apple-darwin*        |x86_64-apple-darwin14.3.0
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-03-06
     Ever confirmed|0                           |1

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Confirmed

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin10

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
           Assignee|redi at gcc dot gnu.org            |unassigned at gcc dot gnu.org

--- Comment #36 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think my work here is done.

Leaving open in case anyone wants to do anything further, if not please close
it.