Return-Path: 
 <dev-return-8780-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org>
X-Original-To: apmail-stdcxx-dev-archive@www.apache.org
Delivered-To: apmail-stdcxx-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 141A7DC8A
	for <apmail-stdcxx-dev-archive@www.apache.org>;
 Sun, 23 Sep 2012 22:20:08 +0000 (UTC)
Received: (qmail 29302 invoked by uid 500); 23 Sep 2012 22:20:08 -0000
Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org
Received: (qmail 29261 invoked by uid 500); 23 Sep 2012 22:20:07 -0000
Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@stdcxx.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@stdcxx.apache.org>
List-Post: <mailto:dev@stdcxx.apache.org>
List-Id: <dev.stdcxx.apache.org>
Reply-To: dev@stdcxx.apache.org
Delivered-To: mailing list dev@stdcxx.apache.org
Received: (qmail 29253 invoked by uid 99); 23 Sep 2012 22:20:07 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 23 Sep 2012 22:20:07 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy)
Received: from [64.34.174.152] (HELO hates.ms) (64.34.174.152)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 23 Sep 2012 22:20:01 +0000
Received: from [2.128.155.14] (unknown [206.197.31.227])
	by hates.ms (Postfix) with ESMTPSA id E2A0B45C1A8
	for <dev@stdcxx.apache.org>; Sun, 23 Sep 2012 22:19:39 +0000 (UTC)
Message-ID: <505F8AFB.2060306@hates.ms>
Date: Sun, 23 Sep 2012 18:19:39 -0400
From: Liviu Nicoara <nikkoara@hates.ms>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: STDCXX-1066 [was: Re: STDCXX forks]
References: <5054B4B1.8040502@hates.ms>
 <CALdE9OCKkiTRCjWZsTdGWFyFyeRAym5gXvwwLt4MY5_O128vGA@mail.gmail.com>
 <5054EBD1.2010802@hates.ms>
 <CALdE9OCSfwMJ13FH0LKLYr6d+2QmsX0FzQCaRHVzZOvGp11m+g@mail.gmail.com>
 <5054F77C.9030406@hates.ms>
 <CALdE9OC+UmjfgPNuuSaopYbJ56K=r4Um589JeYFrvS+utz9PsA@mail.gmail.com>
 <505F1E4F.1030300@hates.ms>
 <CALdE9OBg8eZ1v-BwzUxQRAP615UPKrPGLKydA4dTG3esN+FYOA@mail.gmail.com>
 <505F7802.7010405@hates.ms>
 <CALdE9OCZHG8+FsWOQJE5wSS+HRacM3Gk3Otc2XDJ6PQ6sZUmrA@mail.gmail.com>
 <CALdE9OCT2hzPsKR-G4hhvpfX=DnnvaWPgT7OeG=MrcqW+Fpazg@mail.gmail.com>
In-Reply-To: 
 <CALdE9OCT2hzPsKR-G4hhvpfX=DnnvaWPgT7OeG=MrcqW+Fpazg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 9/23/12 5:50 PM, Stefan Teleman wrote:
> On Sun, Sep 23, 2012 at 5:23 PM, Stefan Teleman
> <stefan.teleman@gmail.com> wrote:
>
>> The second URL says this:
>>
>> <QUOTE>
>> Due to a change in the implementation of the userland mutexes
>> introduced by CR 6296770 in KU 137111-01, objects of type mutex_t and
>> pthread_mutex_t must start at 8-byte aligned addresses. If this
>> requirement is not satisfied, all non-compliant applications on
>> Solaris/SPARC may fail with the signal SEGV with a callstack similar
>> to the following one or with similar callstacks containing the
>> function mutex_trylock_process.
>>
>>    \*_atomic_cas_64(0x141f2c, 0x0, 0xff000000, 0x1651, 0xff000000, 0x466d90)
>>    set_lock_byte64(0x0, 0x1651, 0xff000000, 0x0, 0xfec82a00, 0x0)
>>    fast_process_lock(0x141f24, 0x0, 0x1, 0x1, 0x0, 0xfeae5780)
>>
>> </QUOTE>
>
> Here's a link to an official datatype alignment table for SPARCV8:
>
> http://docs.oracle.com/cd/E19205-01/819-5267/bkbkl/index.html
>
> The interesting table is:
>
> Table B–2 Storage Sizes and Default Alignments in Bytes

I see nothing really outstanding here. What is it that I should pay attention to?

Thanks,
Liviu