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.
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
Assuming my analysis is right, could you please try the attached (yet untested) patch? Thanks. Rainer
Created attachment 25709 [details] proposed patch
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.
> --- 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
> Paolo's suggestion probably was not well thought through. Yes, it assumed that the patch would be tested by maintainers... The patch looks good.
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
> --- 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
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".
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.
> --- 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
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.
Created attachment 25713 [details] AIX include-fixed sys/types.h
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.
> --- 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
Created attachment 25715 [details] Pre-processed atomic.cc
Created attachment 25717 [details] 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?
The first atomic.ii is from the failing revision 180821. The second one is from the successful revision 180770 before the libgcc changes.
> 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
Created attachment 25722 [details] rev 180821 atomic.ii from save-temps
Created attachment 25723 [details] rev 180770 atomic.ii from save-temps
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
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.
(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;
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
(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.
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
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)
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.
Created attachment 25727 [details] rev 180821 atomic.ii from save-temps after patch from comment 24
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
(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.
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’
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
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.
(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.
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.
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?!
I am not aware of any AIX-specific rules.
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
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
This should be fixed now, could you test again? Thanks
Jonathan, Your patch works, but Rainer still has not checked in his original patch fixing gthr headers, AFAIK. Thanks, David
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
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
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
> --- 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
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
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.
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
Created attachment 26325 [details] 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.
I rebuilt with the libstdc++-v3 testsuite patch, but the 30_thread tests did not run.
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.
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
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)