[Bug bootstrap/50982] New: gthr reorganization breakage

[Bug bootstrap/50982] New: gthr reorganization breakage

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

             Bug #: 50982
           Summary: gthr reorganization breakage
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dje@gcc.gnu.org


The reorganization of gthr files into libgcc breaks bootstrap because some
header files include other files, but look in the wrong directory.

libgcc/config/rs6000/gthr-aix.h
#include "config/gthr-posix.h"

libgcc/config/gthr-vxworks.h
#include "config/gthr-posix.h"

libgcc/config/gthr-lynx.h
#include "config/gthr-posix.h"

However, gthr-posix.h is installed in the same directory as gthr-default.h. 
The header files were edited to include other headers based on the new source
tree hierarchy, but that is not where the files are installed.

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-11-03
                 CC|                            |ro at CeBiTec dot
                   |                            |Uni-Bielefeld.DE
     Ever Confirmed|0                           |1

[Bug bootstrap/50982] gthr reorganization breakage

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bonzini at gnu dot org, ro
                   |                            |at gcc dot gnu.org

--- Comment #1 from Rainer Orth <ro at gcc dot gnu.org> 2011-11-03 15:10:00 UTC ---
Could you please provide details how exactly the bootstrap fails?  With
the exception of the libstdc++ include/<target>/bits directory, the
gthr* files aren't supposed to be installed at all.

I suppose that e.g. on AIX gthr-default.h's (really, gthr-aix.h's)
#include "config/gthr-posix.h" fails to find the latter?  In that case,
gthr-posix.h should be moved up to libgcc itself, as my original patch
had it, before Paolo objected.

Thanks.
        Rainer

[Bug bootstrap/50982] gthr reorganization breakage

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #3 from Rainer Orth <ro at gcc dot gnu.org> 2011-11-03 17:25:59 UTC ---
Created attachment 25709
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25709
proposed patch

[Bug bootstrap/50982] gthr reorganization breakage

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|ro at CeBiTec dot           |
                   |Uni-Bielefeld.DE            |
         AssignedTo|unassigned at gcc dot       |ro at gcc dot gnu.org
                   |gnu.org                     |
   Target Milestone|---                         |4.7.0

--- Comment #2 from Rainer Orth <ro at gcc dot gnu.org> 2011-11-03 17:24:53 UTC ---
Assuming my analysis is right, could you please try the attached (yet untested)
patch?

Thanks.
  Rainer

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #4 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-03 18:11:40 UTC ---
The failure is config/gthr-posix.h is not found in the search path when
building libstdc++ during bootstrap.

Paolo's suggestion probably was not well thought through.

I tried editing gthr-aix.h to remove config/, but that was not sufficient and
failed in another way.  I will try with the other parts of your patch.

[Bug bootstrap/50982] gthr reorganization breakage

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-11-03 18:22:16 UTC ---
> --- Comment #4 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-03 18:11:40 UTC ---
> The failure is config/gthr-posix.h is not found in the search path when
> building libstdc++ during bootstrap.
>
> Paolo's suggestion probably was not well thought through.
>
> I tried editing gthr-aix.h to remove config/, but that was not sufficient and
> failed in another way.  I will try with the other parts of your patch.

You will also need the the libstdc++-v3/include/Makefile.{am, in} part.
git GNU patch can apply git-style patches, but there's no release yet.
I think svn 1.7 can, too.  This makes it much easier than dealing with
such patches manually.

    Rainer

[Bug bootstrap/50982] gthr reorganization breakage

[bonzini at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #6 from Paolo Bonzini <bonzini at gnu dot org> 2011-11-03 18:27:23 UTC ---
> Paolo's suggestion probably was not well thought through.

Yes, it assumed that the patch would be tested by maintainers...

The patch looks good.

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #7 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-03 19:28:16 UTC ---
It's better.  It now finds gthr-posix.h.  But now it fails with a C++ failure:

In file included from /farm/dje/src/src/libstdc++-v3/src/atomic.cc:28:0:
/tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex: In
cons
tructor 'constexpr std::once_flag::once_flag()':
/tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:767:65: 
error: no matching function for call to
'pthread_once_t::pthread_once_t(<brace-e
nclosed initializer list>)'
/tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:767:65: 
note: candidates are:
In file included from
/tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/
include/gstdint.h:6:0,
                 from /farm/dje/src/src/libstdc++-v3/src/atomic.cc:26:
/tmp/20111103/./gcc/include-fixed/sys/types.h:451:1: note:
pthread_once_t::pthre
ad_once_t()
/tmp/20111103/./gcc/include-fixed/sys/types.h:451:1: note:   candidate expects
0
 arguments, 1 provided
/tmp/20111103/./gcc/include-fixed/sys/types.h:451:1: note: constexpr
pthread_onc
e_t::pthread_once_t(const pthread_once_t&)
/tmp/20111103/./gcc/include-fixed/sys/types.h:451:1: note:   no known
conversion
 for argument 1 from '<brace-enclosed initializer list>' to 'const
pthread_once_
t&'
/tmp/20111103/./gcc/include-fixed/sys/types.h:451:1: note: constexpr
pthread_onc
e_t::pthread_once_t(pthread_once_t&&)
/tmp/20111103/./gcc/include-fixed/sys/types.h:451:1: note:   no known
conversion
 for argument 1 from '<brace-enclosed initializer list>' to 'pthread_once_t&&'
In file included from /farm/dje/src/src/libstdc++-v3/src/atomic.cc:28:0:
/tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:767:69: 
error: uninitialized member 'std::once_flag::_M_once' in 'constexpr'
constructor
/tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex: In
func
tion 'void std::call_once(std::once_flag&, _Callable&&, _Args&& ...)':
/tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:818:64: 
error: invalid conversion from 'void (*)(...)' to 'void (*)()' [-fpermissive]
make[9]: *** [atomic.lo] Error 1

[Bug bootstrap/50982] gthr reorganization breakage

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-11-03 19:40:31 UTC ---
> --- Comment #7 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-03 19:28:16 UTC ---
> It's better.  It now finds gthr-posix.h.  But now it fails with a C++ failure:

Fine.  I'm running Solaris and Linux/x64 bootstraps with that patch now.

> In file included from /farm/dje/src/src/libstdc++-v3/src/atomic.cc:28:0:
> /tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex: In
> cons
> tructor 'constexpr std::once_flag::once_flag()':
> /tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:767:65: 
> error: no matching function for call to
> 'pthread_once_t::pthread_once_t(<brace-e
> nclosed initializer list>)'
> /tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:767:65: 
> note: candidates are:
> In file included from
> /tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/
> include/gstdint.h:6:0,
>                  from /farm/dje/src/src/libstdc++-v3/src/atomic.cc:26:
> /tmp/20111103/./gcc/include-fixed/sys/types.h:451:1: note:
> pthread_once_t::pthre
> ad_once_t()
> /tmp/20111103/./gcc/include-fixed/sys/types.h:451:1: note:   candidate expects
> 0
>  arguments, 1 provided
> /tmp/20111103/./gcc/include-fixed/sys/types.h:451:1: note: constexpr
> pthread_onc
> e_t::pthread_once_t(const pthread_once_t&)
> /tmp/20111103/./gcc/include-fixed/sys/types.h:451:1: note:   no known
> conversion
>  for argument 1 from '<brace-enclosed initializer list>' to 'const
> pthread_once_
> t&'
> /tmp/20111103/./gcc/include-fixed/sys/types.h:451:1: note: constexpr
> pthread_onc
> e_t::pthread_once_t(pthread_once_t&&)
> /tmp/20111103/./gcc/include-fixed/sys/types.h:451:1: note:   no known
> conversion
>  for argument 1 from '<brace-enclosed initializer list>' to 'pthread_once_t&&'
> In file included from /farm/dje/src/src/libstdc++-v3/src/atomic.cc:28:0:
> /tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:767:69: 
> error: uninitialized member 'std::once_flag::_M_once' in 'constexpr'
> constructor
> /tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex: In
> func
> tion 'void std::call_once(std::once_flag&, _Callable&&, _Args&& ...)':
> /tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:818:64: 
> error: invalid conversion from 'void (*)(...)' to 'void (*)()' [-fpermissive]
> make[9]: *** [atomic.lo] Error 1

This doesn't ring a bell for me.  Could you please try a bootstrap at
rev 180765 (i.e. immediately before my libgcc patches) to make sure this
isn't a different issue.

Thanks.
        Rainer

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #9 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-03 20:36:28 UTC ---
Okay, I will try.  I think that something about the reorganization is causing a
C header file to be interpreted as a C++ header.  Something missing extern "C".

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #10 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-03 20:49:52 UTC ---
Actually, my previous successful bootstrap was for rev 180770.  I happened to
catch you in the middle of your checkins, but before the libgcc changes.

http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00246.html

That was successful, so it either must be do to your patch or a later change.

Is there some logic about which include directories implicitly are C++ vs C
header files?  It now is finding gthr.h, gthr-default.h and gthr-posix.h in
libstdc++ include/bits.

[Bug bootstrap/50982] gthr reorganization breakage

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-11-04 13:56:30 UTC ---
> --- Comment #10 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-03 20:49:52 UTC ---
> Actually, my previous successful bootstrap was for rev 180770.  I happened to
> catch you in the middle of your checkins, but before the libgcc changes.
>
> http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00246.html
>
> That was successful, so it either must be do to your patch or a later change.

The following changes seem innocent to me, so this makes it highly
probably that my gthr patch is the culprit, too.  Which rev was the
first one to fail bootstrap for you?

> Is there some logic about which include directories implicitly are C++ vs C
> header files?  It now is finding gthr.h, gthr-default.h and gthr-posix.h in
> libstdc++ include/bits.

libstdc++ needs the ones in include/<target>/bits, for they are slighly
mangled copies of the libgcc ones.

The C files live either below $srcdir/libgcc, and those runtime libs
that need them were modified to add appropriate -I flags, or in
$objdir/<target>/libgcc (for gthr-default.h).

I think we need to start from the beginning:

* include/<target>/bits/gthr-default.h should be a modified copy of
  gthr-aix.h, right?

* What's the exact command line for the failing atomic.cc compile?  In
  particular, is -pthread included?  That would lead to gthr-default.h
  including gthr-posix.h, which again includes <pthread.h>.

* Perhaps repeat the command with -g3 -save-temps and check for a
  pthread_once declaration.

* If I were to debug this myself, the quickest way (given enough CPU
  power) is usually to have a succeeding and failing build in parallel
  and compare command lines and -g3 -save-temps output.

    Rainer

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #12 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-04 14:26:58 UTC ---
Bootstrap broke with trunk revision 180821.

* include/<target>/bits/gthr-default.h should be a modified copy of
  gthr-aix.h, right?

Yes, gthr-default.h is gthr-aix.h.

* What's the exact command line for the failing atomic.cc compile?  In
  particular, is -pthread included?  That would lead to gthr-default.h
  including gthr-posix.h, which again includes <pthread.h>.

Yes, this is a pthread multilib.

libtool: compile:  /tmp/20111103/./gcc/xgcc -shared-libgcc
-B/tmp/20111103/./gcc
 -nostdinc++ -L/tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/src
-L/
tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/src/.libs
-B/farm/dje/i
nstall/powerpc-ibm-aix5.3.0.0-20111103/powerpc-ibm-aix5.3.0.0/bin/
-B/farm/dje/i
nstall/powerpc-ibm-aix5.3.0.0-20111103/powerpc-ibm-aix5.3.0.0/lib/ -isystem
/far
m/dje/install/powerpc-ibm-aix5.3.0.0-20111103/powerpc-ibm-aix5.3.0.0/include
-is
ystem
/farm/dje/install/powerpc-ibm-aix5.3.0.0-20111103/powerpc-ibm-aix5.3.0.0/s
ys-include -pthread
-I/tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/
include/powerpc-ibm-aix5.3.0.0
-I/tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/li
bstdc++-v3/include -I/farm/dje/src/src/libstdc++-v3/libsupc++
-fno-implicit-temp
lates -Wall -Wextra -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once
 -ffunction-sections -fdata-sections -frandom-seed=atomic.lo -g -O2 -pthread
-st
d=gnu++0x -c /farm/dje/src/src/libstdc++-v3/src/atomic.cc  -DPIC -o
.libs/atomic
.o

* Perhaps repeat the command with -g3 -save-temps and check for a
  pthread_once declaration.

AIX /usr/include/pthread.h

extern int
pthread_once __((pthread_once_t *,
                 void (*)(void)));

This header file is surrounded by 

#ifdef __cplusplus
extern "C" {
#endif

This is why the error implies that something about the libgcc change is causing
the header file to be treated as C++ instead of extern "C".

* If I were to debug this myself, the quickest way (given enough CPU
  power) is usually to have a succeeding and failing build in parallel
  and compare command lines and -g3 -save-temps output.

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #13 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-04 14:59:13 UTC ---
Created attachment 25713
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25713
AIX include-fixed sys/types.h

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #14 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-04 14:59:50 UTC ---
AIX /usr/include/sys/types.h refers to pthread_once_t

typedef struct
{
#ifdef __64BIT__
        long    __on_word[9];
#else
        int     __on_word[28];
#endif /* __64BIT__ */
}
pthread_once_t;

also with extern "C" wrapper.

[Bug bootstrap/50982] gthr reorganization breakage

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-11-04 15:10:06 UTC ---
> --- Comment #14 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-04 14:59:50 UTC ---
> AIX /usr/include/sys/types.h refers to pthread_once_t
>
> typedef struct
> {
> #ifdef __64BIT__
>         long    __on_word[9];
> #else
>         int     __on_word[28];
> #endif /* __64BIT__ */
> }
> pthread_once_t;
>
> also with extern "C" wrapper.

I fear looking at sources leads us nowhere: we need to look at the
preprocessed atomic.cc (with -g3), best before and after the patch.
This way, the machine does most of the work for us, otherwise we
theoretize for hours what could be wrong, instead of just comparing what
what changed.

Sorry this is so tedious, but I have no access to an AIX machine anywhere.

    Rainer

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #16 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-04 15:12:52 UTC ---
Created attachment 25715
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25715
Pre-processed atomic.cc

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #17 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-04 16:10:22 UTC ---
Created attachment 25717
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25717
Pre-processed atomic.cc that compiles

The incorrect version of atomic.ii includes more code, but nothing specific to
pthread_once_t.  I still am trying to understand the nesting, but is an extern
"C++" statement resetting the mode that was not occurring before?

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #18 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-04 16:12:27 UTC ---
The first atomic.ii is from the failing revision 180821.  The second one is
from the successful revision 180770 before the libgcc changes.

[Bug bootstrap/50982] gthr reorganization breakage

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-11-04 16:30:57 UTC ---
> The incorrect version of atomic.ii includes more code, but nothing specific to
> pthread_once_t.  I still am trying to understand the nesting, but is an extern
> "C++" statement resetting the mode that was not occurring before?

I think it does: it has the once_flag() initialization that fails to
compile.  This is from libstdc++-v3/include/std/mutex, controlled by 

#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1)

How are those macros defined in <target>/libstdc++-v3/config.h before
and after my patches?

That's why I regularly ask for -g3 -save-temps output; this way, the
macro definitions are kept in the preprocessed output and you can see
this for yourself.

    Rainer

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #20 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-04 17:29:20 UTC ---
Created attachment 25722
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25722
rev 180821 atomic.ii from save-temps

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #21 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-04 17:33:35 UTC ---
Created attachment 25723
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25723
rev 180770 atomic.ii from save-temps

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #22 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-04 17:36:52 UTC ---
diff -u atomic.ii.save-temps.old atomic.ii.save-temps.new

-#define __VERSION__ "4.7.0 20111102 (experimental) [trunk revision 180770]"
+#define __VERSION__ "4.7.0 20111103 (experimental) [trunk revision 180821]"

-
-#define _GLIBCXX_HAVE_GTHR_DEFAULT 1
-
-

-
+#define _GLIBCXX_HAS_GTHREADS 1

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #23 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-05 06:36:06 UTC ---
I suspect that libstdc++ is having problems because pthread_once_t is a struct
in AIX.  libstdc++ should not be written to assume it is a scalar.

[Bug bootstrap/50982] gthr reorganization breakage

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #24 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-05 12:23:45 UTC ---
(In reply to comment #23)
> I suspect that libstdc++ is having problems because pthread_once_t is a struct
> in AIX.  libstdc++ should not be written to assume it is a scalar.

Ah, that's easily fixed, std::once_flag should use a non-static data member
initializer, does this patch help:

Index: include/std/mutex
===================================================================
--- include/std/mutex   (revision 180447)
+++ include/std/mutex   (working copy)
@@ -760,11 +760,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
   private:
     typedef __gthread_once_t __native_type;
-    __native_type  _M_once;
+    __native_type  _M_once = __GTHREAD_ONCE_INIT;

   public:
     /// Constructor
-    constexpr once_flag() noexcept : _M_once(__GTHREAD_ONCE_INIT) { }
+    constexpr once_flag() noexcept = default;

     /// Deleted copy constructor
     once_flag(const once_flag&) = delete;

[Bug bootstrap/50982] gthr reorganization breakage

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

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

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

--- Comment #25 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-05 12:29:50 UTC ---
I'm going to apply that patch anyway, I should have done it as part of PR 49894
- if it solves this problem that's an added bonus

[Bug bootstrap/50982] gthr reorganization breakage

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #26 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-05 12:52:51 UTC ---
(In reply to comment #7)
> /tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex: In
> func
> tion 'void std::call_once(std::once_flag&, _Callable&&, _Args&& ...)':
> /tmp/20111103/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:818:64: 
> error: invalid conversion from 'void (*)(...)' to 'void (*)()' [-fpermissive]
> make[9]: *** [atomic.lo] Error 1

I'm not sure what is happening here, the relevant lines are:

  extern "C" void __once_proxy();

  int __e = __gthread_once(&(__once._M_once), &__once_proxy);

The function pointer is of type void(*)() so I don't know why the error
mentions a varargs function.

[Bug bootstrap/50982] gthr reorganization breakage

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #27 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-05 13:33:38 UTC ---
Author: redi
Date: Sat Nov  5 13:33:29 2011
New Revision: 181013

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181013
Log:
    PR libstdc++/49894
    PR bootstrap/50982
    * include/std/mutex (once_flag): Use NSDMI.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/std/mutex

[Bug bootstrap/50982] gthr reorganization breakage

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #28 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-05 13:56:43 UTC ---
Just to be clear, as this bug report is quite misleading: once the initial
problem was fixed the change is that _GLIBCXX_HAS_GTHREADS is being set now
when it wasn't previously (for why that happens you'll need to look in the
libstdc++-v3/config.log)

That causes code to be included on AIX that was previously not used, the
failures in include/mutex are not new or caused by Rainer's changes, that code
was (apparently) never compiled on AIX previously. Everything from comment 7
onwards is due to the inclusion of code which has never been used on AIX
before.

Either the cause of the change to _GLIBCXX_HAS_GTHREADS should be reverted so
that AIX doesn't use the C++ mutex code, making the compilation errors in that
code disappear, or (I think this is the correct approach) the bug should be
recategorised as libstdc++ and assigned to me to fix the libstdc++ code so it
works on AIX.

The latter option should mean AIX will get a working C++11 threading
implementation, which presumably it previously didn't (which will mean we
should adjust the relevant parts of the testsuite to use any required flags to
run on AIX)

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #29 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-05 14:11:35 UTC ---
The patch in comment 24 solves some of the problem.  Thanks!

The error now is:

In file included from /farm/dje/src/src/libstdc++-v3/src/atomic.cc:28:0:
/tmp/20111104/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:763:30:
error: array must be initialized with a brace-enclosed initializer
/tmp/20111104/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:763:30:
error: too many initializers for 'std::once_flag::__native_type {aka
pthread_once_t}'
/tmp/20111104/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex: In
function 'void std::call_once(std::once_flag&, _Callable&&, _Args&& ...)':
/tmp/20111104/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:818:64:
error: invalid conversion from 'void (*)(...)' to 'void (*)()' [-fpermissive]

On AIX pthread_once_t is a struct containing an array:

typedef struct
{
#ifdef __64BIT__
        long    __on_word[9];
#else
        int     __on_word[28];
#endif /* __64BIT__ */
}
pthread_once_t;

and the initializer is an array:

#ifdef __64BIT__
#define PTHREAD_ONCE_INIT \
{ \
        0, \
        0, \
        0, \
        0, \
        0, \
        _PTH_FLAGS_INIT64, \
        0 \
}
#else
#define PTHREAD_ONCE_INIT \
{ \
        0, \
        0, \
        0, \
        0, \
        0, \
        0, \
        0, \
        2, \
        0 \
}
#endif /* __64BIT__ */

The initializer has few words than the array because the rest are zero, but
matching the size does not solve the problem.

I also do not understand the conversion error:

extern int
pthread_once (pthread_once_t *, void (*)(void))
                   ;

static inline int
__gthread_once (__gthread_once_t *__once, void (*__func) (void))
{
  if (__gthread_active_p ())
    return pthread_once (__once, __func);
  else
    return -1;
}

      int __e = __gthread_once(&(__once._M_once), &__once_proxy);


I will upload the new atomic.ii

Thanks for your help.

[Bug bootstrap/50982] gthr reorganization breakage

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #25715|0                           |1
        is obsolete|                            |
  Attachment #25717|0                           |1
        is obsolete|                            |
  Attachment #25722|0                           |1
        is obsolete|                            |

--- Comment #30 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-05 14:14:36 UTC ---
Created attachment 25727
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25727
rev 180821 atomic.ii from save-temps after patch from comment 24

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|bootstrap                   |libstdc++
         AssignedTo|ro at gcc dot gnu.org       |redi at gcc dot gnu.org
            Summary|gthr reorganization         |AIX libstdc++ GTHREADS
                   |breakage                    |incompatibility

--- Comment #31 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-05 14:19:48 UTC ---
Jonathan,

I agree with your recommendation in comment 28.  I have revised the description
of the bug and uploaded the current pre-processed atomic.cc after your earlier
patch.  Rainer was able to reproduce the earlier errors using the pre-processed
file on a non-AIX system; let me know if you cannot.  Let me know if you need
more information, but I think that everything should be self-contained in
atomic.ii.

Thanks, David

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #32 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-05 14:29:11 UTC ---
(In reply to comment #29)
> On AIX pthread_once_t is a struct containing an array:
> 
> typedef struct
> {
> #ifdef __64BIT__
>         long    __on_word[9];
> #else
>         int     __on_word[28];
> #endif /* __64BIT__ */
> }
> pthread_once_t;
> 
> and the initializer is an array:
> 
> #ifdef __64BIT__
> #define PTHREAD_ONCE_INIT \
> { \
>         0, \
>         0, \
>         0, \
>         0, \
>         0, \
>         _PTH_FLAGS_INIT64, \
>         0 \
> }
> #else
> #define PTHREAD_ONCE_INIT \
> { \
>         0, \
>         0, \
>         0, \
>         0, \
>         0, \
>         0, \
>         0, \
>         2, \
>         0 \
> }
> #endif /* __64BIT__ */
> 
> The initializer has few words than the array because the rest are zero, but
> matching the size does not solve the problem.

The initializer is missing a set of braces.

That could be fixed by changing mutex like so:

Index: include/std/mutex
===================================================================
--- include/std/mutex   (revision 181013)
+++ include/std/mutex   (working copy)
@@ -760,7 +760,7 @@
   {
   private:
     typedef __gthread_once_t __native_type;
-    __native_type  _M_once = __GTHREAD_ONCE_INIT;
+    __native_type  _M_once = { __GTHREAD_ONCE_INIT };

   public:
     /// Constructor

But that would be wrong for other platforms - I'll have to look into this bit,
but you could apply the patch locally for now to get past this problem.

Maybe we need to fixinclude the INIT macro to add extra braces on AIX.

> I also do not understand the conversion error:
> 
> extern int
> pthread_once (pthread_once_t *, void (*)(void))
>                    ;
> 
> static inline int
> __gthread_once (__gthread_once_t *__once, void (*__func) (void))
> {
>   if (__gthread_active_p ())
>     return pthread_once (__once, __func);
>   else
>     return -1;
> }
> 
>       int __e = __gthread_once(&(__once._M_once), &__once_proxy);

I don't understand that either.

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

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

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

--- Comment #33 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-05 15:39:09 UTC ---
Jason, is the compiler right to reject the NSDMI below, and can you suggest any
workaround except using fixincludes to add the missing braces around the
PTHREAD_ONCE_INIT macro for AIX?


The problematic code can be reduced to:

  typedef struct
  {
        int __on_word[28];
  }
  pthread_once_t;

  #define PTHREAD_ONCE_INIT { 0, 0, 0, 0, 0, 0, 0, 2, 0 }

  pthread_once_t once = PTHREAD_ONCE_INIT;

  struct once_flag
  {
  private:
    pthread_once_t _M_once = PTHREAD_ONCE_INIT;

  public:

    constexpr once_flag() noexcept = default;
  };

  once_flag o;

The declaration of "once" at namespace scope only gives warning:

at.cc:9:25: warning: missing braces around initializer for ‘int [28]’
[-Wmissing-braces]

but the same construct used as a NSDMI in once_flag gives an error:

at.cc:14:30: error: array must be initialized with a brace-enclosed initializer
at.cc:14:30: error: too many initializers for ‘pthread_once_t’

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #34 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-05 15:51:54 UTC ---
I am trying to bootstrap with --disable-multilib to at least be able to build
GCC while we try to fix this.

Adding the braces removes the first error, but 

In file included from /farm/dje/src/src/libstdc++-v3/src/atomic.cc:28:0:
/tmp/20111104/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex: In
function 'void std::call_once(std::once_flag&, _Callable&&, _Args&& ...)':
/tmp/20111104/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:818:64:
error: invalid conversion from 'void (*)(...)' to 'void (*)()' [-fpermissive]

remains.

Thanks! David

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #35 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-05 15:54:45 UTC ---
And the single set of braces appears to be an AIX header bug.  But it is not
fixed in any later AIX releases through AIX 7.1.  I suspect this will require
fixincludes magic.

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #36 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-05 16:09:42 UTC ---
(In reply to comment #31)
> Adding the braces removes the first error, but 
> 
> In file included from /farm/dje/src/src/libstdc++-v3/src/atomic.cc:28:0:
> /tmp/20111104/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex: In
> function 'void std::call_once(std::once_flag&, _Callable&&, _Args&& ...)':
> /tmp/20111104/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex:818:64:
> error: invalid conversion from 'void (*)(...)' to 'void (*)()' [-fpermissive]
> 
> remains.

I can't reproduce that error.

Does this patch make any difference?

Index: include/std/mutex
===================================================================
--- include/std/mutex   (revision 181013)
+++ include/std/mutex   (working copy)
@@ -796,7 +796,7 @@
   __get_once_mutex();
 #endif

-  extern "C" void __once_proxy();
+  extern "C" void __once_proxy(void);

   /// call_once
   template<typename _Callable, typename... _Args>


It really *shouldn't* make a difference, but it's all I can think of.

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #37 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-05 16:18:24 UTC ---
Yes, the patch in comment 36 appears to fix the second errorr. Thanks!  I
really appreciate the help.

I guess I need to work on fixincludes for the AIX header.

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #38 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-05 16:31:36 UTC ---
Well that's *really* strange.  The declaration is a C++ function in C++ code,
the extern "C" doesn't alter that, and void f() is identical to void f(void) in
C++ (except that the latter has rightly been described as "an abomination" by
Doug McIlroy and Dennis Ritchie)

Does AIX have special rules in the C++ front end that cause an empty function
parameter list to be considered a varargs function?!

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #39 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-05 16:58:29 UTC ---
I am not aware of any AIX-specific rules.

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #40 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-07 07:34:05 UTC ---
I've tracked this behaviour down to cp_parser_parameter_declaration_clause in
cp/parser.c which has a special case for 

  else if (token->type == CPP_CLOSE_PAREN)
    /* There are no parameters.  */
    {
#ifndef NO_IMPLICIT_EXTERN_C
      if (in_system_header && current_class_type == NULL
          && current_lang_name == lang_name_c)
        return NULL_TREE;
      else
#endif
        return void_list_node;
    }


That macro is defined on platforms that are not known to have C++-compatible
system headers

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #41 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-07 07:54:12 UTC ---
Author: redi
Date: Mon Nov  7 07:54:06 2011
New Revision: 181072

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181072
Log:
    PR libstdc++/50982
    * include/std/mutex (__once_proxy): Use void parameter list to
    work on implicit extern "C" systems.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/std/mutex

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #42 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-07 07:55:36 UTC ---
This should be fixed now, could you test again?  Thanks

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #43 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-07 15:04:30 UTC ---
Jonathan,

Your patch works, but Rainer still has not checked in his original patch fixing
gthr headers, AFAIK.

Thanks, David

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #44 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-07 15:12:26 UTC ---
Great, thanks - we can leave it open for now until it's fully resolved.

As I said in comment 28, we might need to adjust the libstdc++ testsuite now
that some new threading features are enabled

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #45 from Rainer Orth <ro at gcc dot gnu.org> 2011-11-07 16:34:37 UTC ---
Author: ro
Date: Mon Nov  7 16:34:31 2011
New Revision: 181095

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181095
Log:
Return gthr-posix.h to libgcc (PR bootstrap/50982)

    libgcc:
    PR bootstrap/50982
    * config/gthr-posix.h: Move ...
    * gthr-posix.h: ... here.
    * config/gthr-lynx.h: Reflect this.
    * config/gthr-vxworks.h: Likewise.
    * config/rs6000/gthr-aix.h: Likewise.
    * configure.ac (target_thread_file): Likewise.
    * configure: Regenerate.

    libstdc++-v3:
    PR bootstrap/50982
    * include/Makefile.am (${host_builddir}/gthr-posix.h): Reflect
    gthr-posix.h move.
    * include/Makefile.in: Regenerate.

Added:
    trunk/libgcc/gthr-posix.h
      - copied, changed from r181094, trunk/libgcc/config/gthr-posix.h
Removed:
    trunk/libgcc/config/gthr-posix.h
Modified:
    trunk/libgcc/ChangeLog
    trunk/libgcc/config/gthr-lynx.h
    trunk/libgcc/config/gthr-vxworks.h
    trunk/libgcc/config/rs6000/gthr-aix.h
    trunk/libgcc/configure
    trunk/libgcc/configure.ac
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/Makefile.am
    trunk/libstdc++-v3/include/Makefile.in

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #46 from Rainer Orth <ro at gcc dot gnu.org> 2011-11-07 16:43:35 UTC ---
David,

I had been waiting to see if the remaining AIX gthread issues were releated to
my patch.  Since that's not the case and my own testing had completed
successfully,
I've now checked in my patch.

  Rainer

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #47 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-11-07 16:45:36 UTC ---
> --- Comment #44 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-11-07 15:12:26 UTC ---
> Great, thanks - we can leave it open for now until it's fully resolved.
>
> As I said in comment 28, we might need to adjust the libstdc++ testsuite now
> that some new threading features are enabled

I had long meant to fix the many copies of hardcoded lists of targets
supporting pthreads, but haven't yet gotten around to it.

    Rainer

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #48 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-22 02:20:43 UTC ---
what's the status of the 30_threads tests now on AIX?

do these results include the threads tests?
http://gcc.gnu.org/ml/gcc-testresults/2011-12/msg01863.html

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #49 from David Edelsohn <dje at gcc dot gnu.org> 2011-12-22 18:46:20 UTC ---
libstdc++ testsuite does not appear to run 30_ thread tests on AIX.  What
controls this?  The testsuite probably assumes that it is testing
"single-threaded" multilib.

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #50 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-22 19:03:02 UTC ---
Those tests have a target selector, which doesn't include AIX:

{ target *-*-freebsd* *-*-netbsd* *-*-linux* *-*-solaris* *-*-cygwin
*-*-darwin* alpha*-*-osf* mips-sgi-irix6* }

So I should have realised they wouldn't run.

Ideally we'd add AIX to all those files but I imagine not all of them will
pass, so it would have to be removed again for the ones that fail, if the
failure isn't something easily fixable

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #51 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-14 18:12:25 UTC ---
Created attachment 26325
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26325
enable <mutex> tests on aix

David, would you be able to apply this patch and let me know the results of
running the libstdc++ testsuite?
(Just "make check RUNTESTFLAGS=conformance.exp=30_threads/*" in the
libstdc++-v3 build dir, if you don't want to wait for the whole testsuite to
finish.)

It enables a subset of the 30_threads test for AIX, if these pass we can try
enabling some more, if they fail then I'll try to find out why.

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #52 from David Edelsohn <dje at gcc dot gnu.org> 2012-01-15 14:29:28 UTC ---
I rebuilt with the libstdc++-v3 testsuite patch, but the 30_thread tests did
not run.

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #53 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-15 14:54:16 UTC ---
Then I'm confused - the tests should depend on availability of the same
features as the code, and the code is now compiled on AIX (as we know because
it was failing to build previously.)

If you email me the testsuite/libstdc++.log output I can look at that and have
another go at enabling the tests.

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

--- Comment #54 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-21 21:27:57 UTC ---
Author: redi
Date: Sat Jan 21 21:27:49 2012
New Revision: 183376

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183376
Log:
    PR libstdc++/50982
    * testsuite/30_threads/*: Add powerpc-ibm-aix* to target selectors.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/testsuite/30_threads/async/42819.cc
    trunk/libstdc++-v3/testsuite/30_threads/async/49668.cc
    trunk/libstdc++-v3/testsuite/30_threads/async/any.cc
    trunk/libstdc++-v3/testsuite/30_threads/async/async.cc
    trunk/libstdc++-v3/testsuite/30_threads/async/launch.cc
    trunk/libstdc++-v3/testsuite/30_threads/async/sync.cc
    trunk/libstdc++-v3/testsuite/30_threads/call_once/39909.cc
    trunk/libstdc++-v3/testsuite/30_threads/call_once/49668.cc
    trunk/libstdc++-v3/testsuite/30_threads/call_once/call_once1.cc
    trunk/libstdc++-v3/testsuite/30_threads/condition_variable/cons/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/condition_variable/members/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/condition_variable/members/2.cc
   
trunk/libstdc++-v3/testsuite/30_threads/condition_variable/native_handle/typesizes.cc
    trunk/libstdc++-v3/testsuite/30_threads/condition_variable_any/50862.cc
    trunk/libstdc++-v3/testsuite/30_threads/condition_variable_any/cons/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/condition_variable_any/members/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/condition_variable_any/members/2.cc
    trunk/libstdc++-v3/testsuite/30_threads/future/cons/move.cc
    trunk/libstdc++-v3/testsuite/30_threads/future/members/45133.cc
    trunk/libstdc++-v3/testsuite/30_threads/future/members/get.cc
    trunk/libstdc++-v3/testsuite/30_threads/future/members/get2.cc
    trunk/libstdc++-v3/testsuite/30_threads/future/members/share.cc
    trunk/libstdc++-v3/testsuite/30_threads/future/members/valid.cc
    trunk/libstdc++-v3/testsuite/30_threads/future/members/wait.cc
    trunk/libstdc++-v3/testsuite/30_threads/future/members/wait_for.cc
    trunk/libstdc++-v3/testsuite/30_threads/future/members/wait_until.cc
    trunk/libstdc++-v3/testsuite/30_threads/lock/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/lock/2.cc
    trunk/libstdc++-v3/testsuite/30_threads/lock/3.cc
    trunk/libstdc++-v3/testsuite/30_threads/lock/4.cc
    trunk/libstdc++-v3/testsuite/30_threads/lock_guard/cons/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/mutex/cons/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/mutex/dest/destructor_locked.cc
    trunk/libstdc++-v3/testsuite/30_threads/mutex/lock/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/mutex/native_handle/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/mutex/native_handle/typesizes.cc
    trunk/libstdc++-v3/testsuite/30_threads/mutex/try_lock/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/mutex/try_lock/2.cc
    trunk/libstdc++-v3/testsuite/30_threads/mutex/unlock/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/packaged_task/49668.cc
    trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/2.cc
    trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/3.cc
    trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/alloc.cc
    trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/move.cc
    trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/move_assign.cc
    trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/get_future.cc
   
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/get_future2.cc
    trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/invoke.cc
    trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/invoke2.cc
    trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/invoke3.cc
    trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/invoke4.cc
    trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/invoke5.cc
    trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/reset.cc
    trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/reset2.cc
    trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/swap.cc
    trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/valid.cc
    trunk/libstdc++-v3/testsuite/30_threads/promise/cons/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/promise/cons/alloc.cc
    trunk/libstdc++-v3/testsuite/30_threads/promise/cons/move.cc
    trunk/libstdc++-v3/testsuite/30_threads/promise/cons/move_assign.cc
    trunk/libstdc++-v3/testsuite/30_threads/promise/members/get_future.cc
    trunk/libstdc++-v3/testsuite/30_threads/promise/members/get_future2.cc
    trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_exception.cc
    trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_exception2.cc
    trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_value.cc
    trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_value2.cc
    trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_value3.cc
    trunk/libstdc++-v3/testsuite/30_threads/promise/members/swap.cc
    trunk/libstdc++-v3/testsuite/30_threads/recursive_mutex/cons/1.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_mutex/dest/destructor_locked.cc
    trunk/libstdc++-v3/testsuite/30_threads/recursive_mutex/lock/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/recursive_mutex/native_handle/1.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_mutex/native_handle/typesizes.cc
    trunk/libstdc++-v3/testsuite/30_threads/recursive_mutex/try_lock/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/recursive_mutex/try_lock/2.cc
    trunk/libstdc++-v3/testsuite/30_threads/recursive_mutex/unlock/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/cons/1.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/dest/destructor_locked.cc
    trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/lock/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/lock/2.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/native_handle/1.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/native_handle/typesizes.cc
    trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock/2.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_for/1.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_for/2.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_for/3.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_until/1.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_until/2.cc
    trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/unlock/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/shared_future/cons/move.cc
    trunk/libstdc++-v3/testsuite/30_threads/shared_future/members/45133.cc
    trunk/libstdc++-v3/testsuite/30_threads/shared_future/members/get.cc
    trunk/libstdc++-v3/testsuite/30_threads/shared_future/members/get2.cc
    trunk/libstdc++-v3/testsuite/30_threads/shared_future/members/valid.cc
    trunk/libstdc++-v3/testsuite/30_threads/shared_future/members/wait.cc
    trunk/libstdc++-v3/testsuite/30_threads/shared_future/members/wait_for.cc
    trunk/libstdc++-v3/testsuite/30_threads/shared_future/members/wait_until.cc
    trunk/libstdc++-v3/testsuite/30_threads/this_thread/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/this_thread/2.cc
    trunk/libstdc++-v3/testsuite/30_threads/this_thread/3.cc
    trunk/libstdc++-v3/testsuite/30_threads/this_thread/4.cc
    trunk/libstdc++-v3/testsuite/30_threads/thread/cons/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/thread/cons/2.cc
    trunk/libstdc++-v3/testsuite/30_threads/thread/cons/3.cc
    trunk/libstdc++-v3/testsuite/30_threads/thread/cons/4.cc
    trunk/libstdc++-v3/testsuite/30_threads/thread/cons/49668.cc
    trunk/libstdc++-v3/testsuite/30_threads/thread/cons/5.cc
    trunk/libstdc++-v3/testsuite/30_threads/thread/cons/6.cc
    trunk/libstdc++-v3/testsuite/30_threads/thread/cons/7.cc
    trunk/libstdc++-v3/testsuite/30_threads/thread/cons/8.cc
    trunk/libstdc++-v3/testsuite/30_threads/thread/cons/9.cc
    trunk/libstdc++-v3/testsuite/30_threads/thread/cons/moveable.cc
    trunk/libstdc++-v3/testsuite/30_threads/thread/members/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/thread/members/2.cc
    trunk/libstdc++-v3/testsuite/30_threads/thread/members/3.cc
    trunk/libstdc++-v3/testsuite/30_threads/thread/members/4.cc
    trunk/libstdc++-v3/testsuite/30_threads/thread/members/5.cc
   
trunk/libstdc++-v3/testsuite/30_threads/thread/members/hardware_concurrency.cc
    trunk/libstdc++-v3/testsuite/30_threads/thread/native_handle/typesizes.cc
    trunk/libstdc++-v3/testsuite/30_threads/thread/swap/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/cons/1.cc
   
trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/dest/destructor_locked.cc
    trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/lock/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/native_handle/1.cc
   
trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/native_handle/typesizes.cc
    trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock/2.cc
    trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock_for/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock_for/2.cc
    trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock_for/3.cc
    trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock_until/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock_until/2.cc
    trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/unlock/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/try_lock/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/try_lock/2.cc
    trunk/libstdc++-v3/testsuite/30_threads/try_lock/3.cc
    trunk/libstdc++-v3/testsuite/30_threads/try_lock/4.cc
    trunk/libstdc++-v3/testsuite/30_threads/unique_lock/cons/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/unique_lock/cons/2.cc
    trunk/libstdc++-v3/testsuite/30_threads/unique_lock/cons/3.cc
    trunk/libstdc++-v3/testsuite/30_threads/unique_lock/cons/4.cc
    trunk/libstdc++-v3/testsuite/30_threads/unique_lock/cons/5.cc
    trunk/libstdc++-v3/testsuite/30_threads/unique_lock/cons/6.cc
    trunk/libstdc++-v3/testsuite/30_threads/unique_lock/locking/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/unique_lock/locking/2.cc
    trunk/libstdc++-v3/testsuite/30_threads/unique_lock/locking/3.cc
    trunk/libstdc++-v3/testsuite/30_threads/unique_lock/locking/4.cc
    trunk/libstdc++-v3/testsuite/30_threads/unique_lock/modifiers/1.cc
    trunk/libstdc++-v3/testsuite/30_threads/unique_lock/modifiers/2.cc

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #55 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-21 22:50:42 UTC ---
Closing, as all the libstdc++-v3/testsuite/30_threads pass now, except the ones
which require sched_yield which are UNSUPPORTED (which like GNU/Linux might
only run when GCC is configured with --enable-libstdcxx-time=rt)