With recent GCC 3.0 versions, there is the following warning on Solaris 2.6. Linux doesn't have this problem. gcc/SunOS_CVS/include/g++-v3/bits/stl_alloc.h: In instantiation of `std::_STL_mutex_lock std::__default_alloc_template<true, 0>::_S_node_allocator_lock': gcc/SunOS_CVS/include/g++-v3/bits/stl_alloc.h:287: instantiated from `std::__default_alloc_template<threads, inst>::_Lock::_Lock() [with bool threads = true, int inst = 0]' gcc/SunOS_CVS/include/g++-v3/bits/stl_alloc.h:309: instantiated from `static void* std::__default_alloc_template<threads, inst>::allocate(unsigned int) [with bool threads = true, int inst = 0]' gcc/SunOS_CVS/include/g++-v3/bits/stl_alloc.h:553: instantiated from `_Tp* std::allocator<_Alloc>::allocate(unsigned int, const void*) [with _Tp = int]' PR_solaris_warning.C:6: instantiated from here gcc/SunOS_CVS/include/g++-v3/bits/stl_alloc.h:494: warning: aggregate has a partly bracketed initializer gcc/SunOS_CVS/include/g++-v3/bits/stl_alloc.h:494: warning: aggregate has a partly bracketed initializer Release: 3.0 20010614 (prerelease) Environment: System: SunOS electra.inria.fr 5.6 Generic_105181-23 sun4u sparc SUNW,Ultra-5_10 Architecture: sun4 host: sparc-sun-solaris2.6 build: sparc-sun-solaris2.6 target: sparc-sun-solaris2.6 configured with: /u/zosma/0/prisme/spion/gcc/gcc/configure --enable-languages=c++ --prefix=/u/zosma/0/prisme/spion/gcc/SunOS_CVS --with-as=/u/zosma/0/prisme/spion/gcc/Binutils/SunOS/bin/as --with-ld=/u/zosma/0/prisme/spion/gcc/Binutils/SunOS/bin/ld How-To-Repeat: // Preprocessed source code is attached. #include <memory> int main() { std::allocator<int> a; a.allocate(2); return 0; } Unformatted: --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline
Fix: [...removed since analysis done...]
Responsible-Changed-From-To: unassigned->ljrittle Responsible-Changed-Why: Non-fatal issue related to one of my recent patches.
State-Changed-From-To: open->analyzed State-Changed-Why: This issue is not seen on solaris2.7 (the Solaris platform used to test). Here is representative key difference between preprocessed files: solaris2.7: < __gthread_mutex_t __tmp = {{{0}, 0}, {{{0}}}, {0}}; solaris2.6: > __gthread_mutex_t __tmp = {0, 0, 0}; Alex mentioned that older Solaris headers might need a fix up. The solution is to add a pthread.h fixup to inclhack.def similar to solaris27_mutex_init. I will write a proposed fixup and sent it to Sylvain for testing.
Responsible-Changed-From-To: ljrittle->nobody Responsible-Changed-Why: My patch, which followed what I thought was good release engineering practice (to incrementally add a conditional code path verses changing a known good code path), was rejected. I am unwilling to put my name on a more aggressive patch that I have no means to personally test.
State-Changed-From-To: analyzed->suspended State-Changed-Why: This appears to be in limbo: Loren submitted a patch, but it wasn't approved, and nobody with access to an older Solaris 2.6 box has stepped forward. Thoughts?
From: Phil Edwards <phil@jaj.com> To: bkoz@gcc.gnu.org, Sylvain.Pion@sophia.inria.fr, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org Cc: Subject: Re: libstdc++/3195: STL warning on Solaris with GCC 3.0 Date: Thu, 28 Mar 2002 19:06:14 -0500 On Thu, Mar 28, 2002 at 11:44:41PM -0000, bkoz@gcc.gnu.org wrote: > This appears to be in limbo: Loren submitted a patch, but it wasn't > approved, and nobody with access to an older Solaris 2.6 box has stepped > forward. Thoughts? The patch in question: http://gcc.gnu.org/ml/gcc-patches/2001-06/msg01585.html Bruce says the two patches should be merged, but I think the result we need for Solaris 2.6 is different from the result needed for Solaris 7. This would seem to preclude using the same fix for both OSes, but I don't know fixincludes, and I'm not certain that the required results must in fact be different.
State-Changed-From-To: suspended->closed State-Changed-Why: This has recently been fixed with some fixinclude hacks, as far as I know.
State-Changed-From-To: closed->suspended State-Changed-Why: inclhack.def contained the logic for this case, but not the patch I though was in there. Reset to previous state. Sorry.
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu> To: Phil Edwards <phil@jaj.com>, Bruce Korb <bkorb@pacbell.net>, <pfeifer@dbai.tuwien.ac.at> Cc: bangerth@dealii.org, <Sylvain.Pion@sophia.inria.fr>, <gcc-gnats@gcc.gnu.org>, <libstdc++@gcc.gnu.org> Subject: Re: libstdc++/3195: STL warning on Solaris with GCC 3.0 Date: Wed, 6 Nov 2002 16:58:16 -0600 (CST) > > State-Changed-Why: > > This has recently been fixed with some fixinclude hacks, as > > far as I know. > > They were proposed and discussed, but were any of them approved and checked > in? I don't see anything obvious in gcc/ChangeLog. Doh. I was referring to the message Gerald sent here: http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01414.html and even looked into the inclhack.def file and found something on PTHREAD_MUTEX_INITIALIZER there, so was under the impression that they must have fixed it. But you're right, the thing that is in there is older. I'll re-open/re-suspend the report, sorry for the noise (this is not a good day, generating too much noise today :-( ). In any case, Gerald, Bruce, what's the state of the matter? Regards Wolfgang ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ticam.utexas.edu www: http://www.ticam.utexas.edu/~bangerth
From: Phil Edwards <phil@jaj.com> To: bangerth@dealii.org, Sylvain.Pion@sophia.inria.fr, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, libstdc++@gcc.gnu.org Cc: Subject: Re: libstdc++/3195: STL warning on Solaris with GCC 3.0 Date: Wed, 6 Nov 2002 17:38:39 -0500 On Wed, Nov 06, 2002 at 05:20:11PM -0000, bangerth@dealii.org wrote: > Synopsis: STL warning on Solaris with GCC 3.0 > > State-Changed-From-To: suspended->closed > State-Changed-By: bangerth > State-Changed-When: Wed Nov 6 09:20:08 2002 > State-Changed-Why: > This has recently been fixed with some fixinclude hacks, as > far as I know. They were proposed and discussed, but were any of them approved and checked in? I don't see anything obvious in gcc/ChangeLog. Phil -- I would therefore like to posit that computing's central challenge, viz. "How not to make a mess of it," has /not/ been met. - Edsger Dijkstra, 1930-2002
From: Bruce Korb <bkorb@pacbell.net> To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>, GCC-Patches <gcc-patches@gcc.gnu.org> Cc: Phil Edwards <phil@jaj.com>, pfeifer@dbai.tuwien.ac.at, bangerth@dealii.org, Sylvain.Pion@sophia.inria.fr, gcc-gnats@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: libstdc++/3195: STL warning needs fixinc assistance Date: Wed, 06 Nov 2002 21:25:29 -0800 Wolfgang Bangerth wrote: > > > State-Changed-Why: > > > This has recently been fixed with some fixinclude hacks, as > > > far as I know. > > > > They were proposed and discussed, but were any of them approved and checked > > in? I don't see anything obvious in gcc/ChangeLog. > > Doh. I was referring to the message Gerald sent here: > http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01414.html > and even looked into the inclhack.def file and found something on > PTHREAD_MUTEX_INITIALIZER there, so was under the impression that they > must have fixed it. But you're right, the thing that is in there is older. > I'll re-open/re-suspend the report, sorry for the noise (this is not a > good day, generating too much noise today :-( ). > > In any case, Gerald, Bruce, what's the state of the matter? I've looked at the relevant headers in Solaris 2.6, 2.7, 2.8 and 2.9. They're all wrong and they cannot be fixed with a simple fix, a la: > --- /usr/include/pthread.h Sat Apr 6 21:12:32 2002 > +++ ....../3.2.1/include/pthread.h Thu Oct 24 00:17:55 2002 > @@ -81,9 +81,9 @@ > * of the corresponding types in sys/types.h (e.g. PTHREAD_MUTEX_INITIALIZER > * should be consistent with the definition for pthread_mutex_t). > */ > #define PTHREAD_MUTEX_INITIALIZER \ > - {{0, 0, 0, DEFAULT_TYPE, _MUTEX_MAGIC}, {{{0}}}, 0} > + {{0, 0, 0, DEFAULT_TYPE, _MUTEX_MAGIC}, {{{0}}}, {0}} > > #define PTHREAD_COND_INITIALIZER \ > {{{0, 0, 0, 0}, DEFAULT_TYPE, _COND_MAGIC}, 0} The problem is that the field initializer that was changed from ``0'' to ``{0}'' sometimes needs to be the former and sometimes the latter. What is really needed is a #define initializer for the padint64_t that depends on a memory model. Where that initialzer will fit in that structure initializer depends on the version of the pthread_mutex_t *AND* *ALSO* the pthread_cond_t. These are defined in /usr/include/sys/sync.h, not /usr/include/pthread.h. I recommend that some interested party write some C code that inserts a #define of PADINT64_INITIALIZER into pthread.h and then replaces both the mutex initializer and the cond initializer text with a concoction that is dependent on the version of sys/synch.h. See the gcc/fixinc/fixfixes.c file for guidance. Yummy. The fix should compile into a noop for platforms other than Solaris.
I believe I fixed this issue in Sept 2006 in gcc-4.0.4, see: http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01032.html http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01163.html http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01194.html http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01225.html http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01317.html and finally this testcase: http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01233.html and later refinements to it ensure pthread macros work everywhere. Results for solaris that don't contain pthread-init-*.c failures: solaris2.6: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00680.html solaris2.7: http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00420.html solaris2.9: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01482.html solaris2.10: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01551.html solaris2.11: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01835.html I recall there was some issue with solaris8 where the macro definition could get out of sync with the structure definition based on what solaris patches where installed. The macro was defined in a different header than the structure and individual solaris patches updated the two files independently, which made it hard (impossible?) to synchronize. And indeed I see a failure in solaris2.8: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00523.html Other than that, all supported versions of solaris are okay. So I think we can close this 8-year-old PR.
Fixed.