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 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. P. Thanks! Stefan Teleman closed STDCXX-1066. -- Resolution: Won't Fix Bug will not be fixed upstream. It is fixed in the Solaris releases. SPARCV8 requires pthread_mutex_t and pthread_cond_t to be aligned on an 8-byte boundary --- Key: STDCXX-1066 URL: https://issues.apache.org/jira/browse/STDCXX-1066 Project: C++ Standard Library Issue Type: Bug Components: Thread Safety Affects Versions: 4.2.1, 4.2.2, 4.2.x, 4.3.x Environment: Solaris 10 Update 6 or later on SPARCV8 [32-bit] Defect is compiler-independent - in reality it only affects Sun Studio and GCC. Reporter: Stefan Teleman Labels: features, runtime, threads Fix For: 4.2.2, 4.2.x, 4.3.x Attachments: _config-gcc.h.stdcxx-1066.patch, _config-sunpro.h.stdcxx-1066.patch, ctype.cpp.stdcxx-1066.patch, exception.cpp.stdcxx-1066.patch, ios.cpp.stdcxx-1066.patch, iostream.cpp.stdcxx-1066.patch, iostream.stdcxx-1066.patch, locale_body.cpp.stdcxx-1066.patch, locale_classic.cpp.stdcxx-1066.patch, messages.cpp.stdcxx-1066.patch, _mutex.h.stdcxx-1066.patch, time_put.cpp.stdcxx-1066.patch, use_facet.h.stdcxx-1066.patch Starting with Solaris 10 Update 6, on SPARCV8, pthread_mutex_t and pthread_cond_t MUST be aligned on an 8-byte boundary. Misaligned access will result in either SEGV or SIGBUS. There are numerous places in the multi-threaded version of stdcxx where pthread_mutex_t and/or pthread_cond_t types are contained within an union, but with an enforced alignment different than 8. All these instances must be corrected, and #ifdef-guarded for SPARCV8. Patches to follow shortly, this is just opening the issue. Warning: the patchset resolving this issue is very large, and it affects a large number of files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r1389337 - /stdcxx/branches/4.2.x/tests/support/atomic_xchg.cpp
On 09/25/12 23:20, Martin Sebor wrote: On 09/24/2012 06:38 AM, lnico...@apache.org wrote: Author: lnicoara Date: Mon Sep 24 12:38:17 2012 New Revision: 1389337 URL: http://svn.apache.org/viewvc?rev=1389337view=rev Log: 2012-09-24 Liviu Nicoara nikko...@hates.ms * tests/support/atomic_xchg.cpp: (run_test) moved counter volatile qualification to match STDCXX conventions (see r1388733) The stdcxx ChangeLog format follows the GNU Coding Standard: http://www.gnu.org/prep/standards/html_node/Change-Logs.html I.e., this entry should look like this: * tests/support/atomic_xchg.cpp (run_test): Move counter volatile qualification to match STDCXX convention (see r1388733). (The colon follows the parenthesized function name. The text should also end with a period.) The svn propedit command lets you change a comment for an already committed change. Sorry about that. I fixed it. L
Reopen closed incidents
I want to reopen the closed incidents, esp. 1056. On a second thought it might be more useful to open new ones and link the old ones so that we don't mess with ownership, etc. If nobody objects to this I will go forward with the latter. Thanks.
STDCXX-1071 numpunct facet defect
I have created STDCXX-1071 and linked to STDCXX-1056. I have reduced the scope to numpunct because moneypunct is not failing for me. If someone has a moneypunct failure listing I want to see it. I have reduced the library code to a failing test case. I have attached there the reduced program. The program shows the same failures like the library (interestingly enough it does not fail when removing the data caching). I have (re)attached the forwarding patches I created for 1056, one binary compatible, the other not. Martin, my wish is to move this to some completion. Please let me know if there is something else you think I should do to speed this up. 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. Thanks, Liviu
Re: STDCXX-1070
On 09/26/2012 04:55 PM, Liviu Nicoara wrote: On 9/25/12 7:56 PM, Liviu Nicoara wrote: On 9/25/12 7:50 PM, Martin Sebor wrote: On 09/25/2012 02:46 PM, Liviu Nicoara wrote: I filed 1070, failure to build 22.locale.collate.cpp on Linux with gcc 4.7.1. Gcc, Comeau and Clang fail to compile it, Intel and Sun are fine. It looks to me like Intel and Sun compilers are not doing the right thing. A small test case and a patch have been attached. The failing code has been reduced to: I agree that the test case is ill-formed and requires a diagnostic. I haven't looked at the test so just to make sure the test case does reflect the problem there: the well-formedness depends on whether charT is a class type. If so, then the code would be okay because g() would be found via associated namespace lookup. I.e., this would be fine: Right. The test uses builtin types, therefore the argument-dependent lookup does not find g. The patch simply adds the declarations before the function that uses them. Clear to go ahead here? You mean apply the patch attached to STDCXX-1070? It looks good to me. I also checked the test. It's odd that the problem didn't get caught sooner (we did get errors when the function templates were declared static, which is why the static keyword is commented out). But it sure does look like a problem. FWIW, if you want quick input on a patch, I find it easier when it's posted to the list (instead of attaching it to the issue). Attaching it is useful when it's large and/or when you don't have commit permissions. Others may have a different preference. Martin Thanks, Liviu
