Re: [jira] [Closed] (STDCXX-1066) SPARCV8 requires pthread_mutex_t and pthread_cond_t to be aligned on an 8-byte boundary
2012/9/26 Liviu Nicoara nikko...@hates.ms: On 09/26/12 05:49, Pavel Heimlich, a.k.a. hajma wrote: 2012/9/26 Liviu Nicoara nikko...@hates.ms: On 9/25/12 7:56 PM, Stefan Teleman (JIRA) wrote: [ https://issues.apache.org/jira/browse/STDCXX-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anybody around here, except Stefan, who has access to a SPARC V8 machine updated to the specified kernel update or later, and who is willing to run a simple test program? It's a 5 minute job at most. Please point me to the test program. Hi Pavel, I attached it. IIRC Solaris had both Solaris threads API and a POSIX threads API on top of it. Could you please give it a run with MUTEX defined to both mutex_t and pthread_mutex_t? Might need to tweak the includes. Here it is, the define seems to make no difference. BTW I'm not sure about the bug description, was Solaris 10 ever supported on a sparcv8? I ran it on the crappiest machine I could find, but all that is sparcv9. Sun Blade 1000 - UltraSPARC-III+(sparcv9), running Solaris 10u9 bash-3.00# /opt/SUNWspro/bin/CC a.cpp bash-3.00# ./a.out 24 ffbffcd8 ffbffcf0 ffbffd08 ffbffd20 ffbffd38 ffbffd50 ffbffd68 ffbffd80 ffbffbe0 ffbffc00 ffbffc20 ffbffc40 ffbffc60 ffbffc80 ffbffca0 ffbffcc0 bash-3.00# /opt/SUNWspro/bin/CC -xarch=v8 ./a.cpp bash-3.00# ./a.out 24 ffbffcd8 ffbffcf0 ffbffd08 ffbffd20 ffbffd38 ffbffd50 ffbffd68 ffbffd80 ffbffbe0 ffbffc00 ffbffc20 ffbffc40 ffbffc60 ffbffc80 ffbffca0 ffbffcc0 bash-3.00# vi a.cpp (--- pthread_mutex_t) bash-3.00# /opt/SUNWspro/bin/CC a.cpp bash-3.00# ./a.out 24 ffbffcd8 ffbffcf0 ffbffd08 ffbffd20 ffbffd38 ffbffd50 ffbffd68 ffbffd80 ffbffbe0 ffbffc00 ffbffc20 ffbffc40 ffbffc60 ffbffc80 ffbffca0 ffbffcc0 bash-3.00# /opt/SUNWspro/bin/CC -xarch=v8 ./a.cpp bash-3.00# ./a.out 24 ffbffcd8 ffbffcf0 ffbffd08 ffbffd20 ffbffd38 ffbffd50 ffbffd68 ffbffd80 ffbffbe0 ffbffc00 ffbffc20 ffbffc40 ffbffc60 ffbffc80 ffbffca0 ffbffcc0 HTH P. Thanks a bunch! Liviu
Re: [jira] [Closed] (STDCXX-1066) SPARCV8 requires pthread_mutex_t and pthread_cond_t to be aligned on an 8-byte boundary
On 09/27/12 07:15, Pavel Heimlich, a.k.a. hajma wrote: 2012/9/26 Liviu Nicoara nikko...@hates.ms: On 09/26/12 05:49, Pavel Heimlich, a.k.a. hajma wrote: 2012/9/26 Liviu Nicoara nikko...@hates.ms: On 9/25/12 7:56 PM, Stefan Teleman (JIRA) wrote: [ https://issues.apache.org/jira/browse/STDCXX-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anybody around here, except Stefan, who has access to a SPARC V8 machine updated to the specified kernel update or later, and who is willing to run a simple test program? It's a 5 minute job at most. Please point me to the test program. Hi Pavel, I attached it. IIRC Solaris had both Solaris threads API and a POSIX threads API on top of it. Could you please give it a run with MUTEX defined to both mutex_t and pthread_mutex_t? Might need to tweak the includes. Here it is, the define seems to make no difference. BTW I'm not sure about the bug description, was Solaris 10 ever supported on a sparcv8? I ran it on the crappiest machine I could find, but all that is sparcv9. Sun Blade 1000 - UltraSPARC-III+(sparcv9), running Solaris 10u9 bash-3.00# /opt/SUNWspro/bin/CC a.cpp bash-3.00# ./a.out 24 ffbffcd8 ffbffcf0 ffbffd08 ffbffd20 ffbffd38 ffbffd50 ffbffd68 ffbffd80 ffbffbe0 ffbffc00 ffbffc20 ffbffc40 ffbffc60 ffbffc80 ffbffca0 ffbffcc0 bash-3.00# /opt/SUNWspro/bin/CC -xarch=v8 ./a.cpp bash-3.00# ./a.out 24 ffbffcd8 ffbffcf0 ffbffd08 ffbffd20 ffbffd38 ffbffd50 ffbffd68 ffbffd80 ffbffbe0 ffbffc00 ffbffc20 ffbffc40 ffbffc60 ffbffc80 ffbffca0 ffbffcc0 bash-3.00# vi a.cpp (--- pthread_mutex_t) bash-3.00# /opt/SUNWspro/bin/CC a.cpp bash-3.00# ./a.out 24 ffbffcd8 ffbffcf0 ffbffd08 ffbffd20 ffbffd38 ffbffd50 ffbffd68 ffbffd80 ffbffbe0 ffbffc00 ffbffc20 ffbffc40 ffbffc60 ffbffc80 ffbffca0 ffbffcc0 bash-3.00# /opt/SUNWspro/bin/CC -xarch=v8 ./a.cpp bash-3.00# ./a.out 24 ffbffcd8 ffbffcf0 ffbffd08 ffbffd20 ffbffd38 ffbffd50 ffbffd68 ffbffd80 ffbffbe0 ffbffc00 ffbffc20 ffbffc40 ffbffc60 ffbffc80 ffbffca0 ffbffcc0 HTH Very much appreciated. Liviu
Re: [PATCH] STDCXX-1069 [was: Re: SUNPro 5.12 compilation failure in optimized Linux builds]
On 09/23/12 12:15, Liviu Nicoara wrote: On 09/22/12 00:51, Liviu Nicoara wrote: Optimized (but not debug) builds fail to compile setlocale.cpp with the error: A patch and a comment have been attached to the issue. I am posting it here to save a trip to the JIRA issue. Any feed-back is appreciated. The issue can be tracked down to the interaction between the definition of _XOPEN_SOURCE in src/setlocale.cpp and util/path.cpp, the system headers, and Solaris Studio C . It seems that the original purpose for the definitions has been lost because both S_IFDIR and symlink are defined and declared, respectively, on modern Linux (edit: by default). Moreover, it seems that the original definition of _XOPEN_SOURCE was incorrect, without a value. I propose we remove the two blocks – see the patch. Thanks, Liviu Index: src/setlocale.cpp === --- src/setlocale.cpp (revision 1388733) +++ src/setlocale.cpp (working copy) @@ -33,11 +33,6 @@ #include rw/_defs.h -#if defined (__linux__) !defined (_XOPEN_SOURCE) - // need S_IFDIR on Linux -# define _XOPEN_SOURCE -#endif // __linux__ !_XOPEN_SOURCE - #include locale.h // for setlocale() #include stdlib.h // for getenv() #include string.h // for memcpy(), strcmp() Index: util/path.cpp === --- util/path.cpp (revision 1388733) +++ util/path.cpp (working copy) @@ -27,16 +27,6 @@ **/ #ifndef _WIN32 -# ifdef __linux__ - // for symlink() -#ifndef _XOPEN_SOURCE -# define _XOPEN_SOURCE -#endif -#ifndef _XOPEN_SOURCE_EXTENDED -# define _XOPEN_SOURCE_EXTENDED -#endif -# endif // __linux__ - # include unistd.h // for getcwd() # include sys/stat.h// for struct stat, stat() #else
Re: STDCXX-1068 and alignment
On 09/22/12 16:22, Stefan Teleman wrote: On Sat, Sep 22, 2012 at 4:07 PM, Liviu Nicoara nikko...@hates.ms wrote: Stefan, could you please elaborate on the misaligned reads/writes that you observed on those platforms? What was failing? Several tests from the test harness were failing because of it, and for no other reason. I'll have to go through my stuff at work and look at the test reports from the Compiler Guys, we were testing these back in March 2011, and right now I can't remember exactly which tests were failing. I'll have the details in a few days. Any news on this one? Thanks, Liviu
Re: STDCXX-1071 numpunct facet defect
On 09/26/12 20:12, Liviu Nicoara wrote:
I have created STDCXX-1071 and linked to STDCXX-1056. [...]
I am open to all questions, the more the better. Most of my opinions have been
expressed earlier, but please ask if you want to know more.
I am attaching here the proposed (4.3.x) patch and the timings results (after
re-verifying the correctness of the timing program and the results). The 4.2.x
patch, the 4.3.x patch, the test program and the results file are also attached
to the incident.
Thanks,
Liviu
Index: include/loc/_numpunct.h
===
--- include/loc/_numpunct.h (revision 1388733)
+++ include/loc/_numpunct.h (working copy)
@@ -61,7 +61,7 @@ struct numpunct: _RW::__rw_facet
string_type;
_EXPLICIT numpunct (_RWSTD_SIZE_T __ref = 0)
-: _RW::__rw_facet (__ref), _C_flags (0) { }
+: _RW::__rw_facet (__ref) { }
virtual ~numpunct () _RWSTD_ATTRIBUTE_NOTHROW;
@@ -109,15 +109,6 @@ protected:
virtual string_type do_falsename () const {
return _RW::__rw_get_punct (this, _RW::__rw_fn, char_type ());
}
-
-private:
-
-int _C_flags; // bitmap of cached data valid flags
-string _C_grouping;// cached results of virtual members
-string_type _C_truename;
-string_type _C_falsename;
-char_type _C_decimal_point;
-char_type _C_thousands_sep;
};
@@ -139,17 +130,7 @@ template class _CharT
inline _TYPENAME numpunct_CharT::char_type
numpunct_CharT::decimal_point () const
{
-if (!(_C_flags _RW::__rw_dp)) {
-
-numpunct* const __self = _RWSTD_CONST_CAST (numpunct*, this);
-
-// [try to] get the decimal point first (may throw)
-// then set a flag to avoid future initializations
-__self-_C_decimal_point = do_decimal_point ();
-__self-_C_flags |= _RW::__rw_dp;
-}
-
-return _C_decimal_point;
+return do_decimal_point ();
}
@@ -157,34 +138,14 @@ template class _CharT
inline _TYPENAME numpunct_CharT::char_type
numpunct_CharT::thousands_sep () const
{
-if (!(_C_flags _RW::__rw_ts)) {
-
-numpunct* const __self = _RWSTD_CONST_CAST (numpunct*, this);
-
-// [try to] get the thousands_sep first (may throw)
-// then set a flag to avoid future initializations
-__self-_C_thousands_sep = do_thousands_sep ();
-__self-_C_flags |= _RW::__rw_ts;
-}
-
-return _C_thousands_sep;
+return do_thousands_sep ();
}
template class _CharT
inline string numpunct_CharT::grouping () const
{
-if (!(_C_flags _RW::__rw_gr)) {
-
-numpunct* const __self = _RWSTD_CONST_CAST (numpunct*, this);
-
-// [try to] get the grouping first (may throw)
-// then set a flag to avoid future initializations
-__self-_C_grouping = do_grouping ();
-__self-_C_flags|= _RW::__rw_gr;
-}
-
-return _C_grouping;
+return do_grouping ();
}
@@ -192,17 +153,7 @@ template class _CharT
inline _TYPENAME numpunct_CharT::string_type
numpunct_CharT::truename () const
{
-if (!(_C_flags _RW::__rw_tn)) {
-
-numpunct* const __self = _RWSTD_CONST_CAST (numpunct*, this);
-
-// [try to] get the true name first (may throw)
-// then set a flag to avoid future initializations
-__self-_C_truename = do_truename ();
-__self-_C_flags|= _RW::__rw_tn;
-}
-
-return _C_truename;
+return do_truename ();
}
@@ -210,17 +161,7 @@ template class _CharT
inline _TYPENAME numpunct_CharT::string_type
numpunct_CharT::falsename () const
{
-if (!(_C_flags _RW::__rw_fn)) {
-
-numpunct* const __self = _RWSTD_CONST_CAST (numpunct*, this);
-
-// [try to] get the false name first (may throw)
-// then set a flag to avoid future initializations
-__self-_C_falsename = do_falsename ();
-__self-_C_flags |= _RW::__rw_fn;
-}
-
-return _C_falsename;
+return do_falsename ();
}
// #endif _RWSTD_NO_EXT_NUMPUNCT_PRIMARY
-*- mode: org -*-
* Machines:
** iMac, Intel, 4 cores:
$ uname -a; gcc -v
Darwin imax 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012;
root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64
gcc version 4.7.1 (GCC)
** Linux Slackware, AMD, 16 cores:
$ uname -a; gcc -v
Linux behemoth 2.6.37.6 #3 SMP Sat Apr 9 22:49:32 CDT 2011 x86_64 AMD
Opteron(tm) Processor 6134 AuthenticAMD GNU/Linux
gcc version 4.5.2 (GCC)
* Method
** Library
Apply the patch. Build an optimized library (I used 12S in all runs). Build the
library, rwtest, and locale database:
$ nice make -Clib
$ nice make -Cbin locales
$ nice make -Crwtest
Properly export the necessary envar if running against STDCXX locale
database or unset, otherwise:
$ export RWSTD_LOCALE_ROOT=/path/to/.../nls
** Test program
Place the multi-threaded program source file, t.cpp, in
srcdir/tests/localization and run make in the
Re: STDCXX-1071 numpunct facet defect
On 09/27/2012 06:41 AM, Liviu Nicoara wrote: On 09/26/12 20:12, Liviu Nicoara wrote: I have created STDCXX-1071 and linked to STDCXX-1056. [...] I am open to all questions, the more the better. Most of my opinions have been expressed earlier, but please ask if you want to know more. I am attaching here the proposed (4.3.x) patch and the timings results (after re-verifying the correctness of the timing program and the results). The 4.2.x patch, the 4.3.x patch, the test program and the results file are also attached to the incident. The patch isn't binary compatible. We can't remove data members in a minor release. We could only do it in a major release. I'm still curious about the performance, though. It doesn't make sense to me that a call to a virtual function is faster than one to an almost trivial inline function. Let me see if I can build the library on Solaris and put together some numbers. I hope to have some time this weekend. Martin Thanks, Liviu
Re: [PATCH] STDCXX-1069 [was: Re: SUNPro 5.12 compilation failure in optimized Linux builds]
On 09/27/2012 06:15 AM, Liviu Nicoara wrote: On 09/23/12 12:15, Liviu Nicoara wrote: On 09/22/12 00:51, Liviu Nicoara wrote: Optimized (but not debug) builds fail to compile setlocale.cpp with the error: A patch and a comment have been attached to the issue. I am posting it here to save a trip to the JIRA issue. Any feed-back is appreciated. The issue can be tracked down to the interaction between the definition of _XOPEN_SOURCE in src/setlocale.cpp and util/path.cpp, the system headers, and Solaris Studio C . It seems that the original purpose for the definitions has been lost because both S_IFDIR and symlink are defined and declared, respectively, on modern Linux (edit: by default). Moreover, it seems that the original definition of _XOPEN_SOURCE was incorrect, without a value. I propose we remove the two blocks – see the patch. I successfully tested the patch with GCC 3.4.6 on RHEL 4.8, with GLIBC 2.3.4, the oldest Linux distribution I could get my hands on. That said, by my reading of POSIX, to get the definition of S_IFDIR (marked as an XSI extension), a conforming application is supposed to define the _XOPEN_SOURCE macro (to 500 or 600 depending on the version of POSIX) in order to get the former macro defined. POSIX also says that every conforming application should define _POSIX_C_SOURCE before including any header. We don't try to do that (on Linux, GCC defines _GNU_SOURCE which I think takes care of it, but I'm not sure we can count on it with all other compilers on all other UNIX systems). In any case, I think the patch is fine. Martin Thanks, Liviu Index: src/setlocale.cpp === --- src/setlocale.cpp(revision 1388733) +++ src/setlocale.cpp(working copy) @@ -33,11 +33,6 @@ #include rw/_defs.h -#if defined (__linux__) !defined (_XOPEN_SOURCE) - // need S_IFDIR on Linux -# define _XOPEN_SOURCE -#endif // __linux__ !_XOPEN_SOURCE - #include locale.h // for setlocale() #include stdlib.h // for getenv() #include string.h // for memcpy(), strcmp() Index: util/path.cpp === --- util/path.cpp(revision 1388733) +++ util/path.cpp(working copy) @@ -27,16 +27,6 @@ **/ #ifndef _WIN32 -# ifdef __linux__ - // for symlink() -#ifndef _XOPEN_SOURCE -# define _XOPEN_SOURCE -#endif -#ifndef _XOPEN_SOURCE_EXTENDED -# define _XOPEN_SOURCE_EXTENDED -#endif -# endif // __linux__ - # include unistd.h // for getcwd() # include sys/stat.h// for struct stat, stat() #else
