Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Travis Vitek <Travis.Vitek@roguewave.com>
To: "dev@stdcxx.apache.org" <dev@stdcxx.apache.org>
Date: Fri, 28 Sep 2012 09:32:14 -0600
Subject: RE: STDCXX-1072 SPARC V8 mutex alignment requirements
Thread-Topic: STDCXX-1072 SPARC V8 mutex alignment requirements
Thread-Index: Ac2ddXXoMT+oW6CETgqPvikIG7oXIwAFsclw
Message-ID: 
 <53D52D02E87FA04A948D9A74A7AE617C12E8A1E9CD@Eagle.Blue.Roguewave.Com>
References: <50659828.9070409@hates.ms>
In-Reply-To: <50659828.9070409@hates.ms>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


> -----Original Message-----
> From: Liviu Nicoara
> Sent: Friday, September 28, 2012 5:29 AM
>=20

>=20
> In short, my reading about this issue is that the kernel patch changed
> the alignment of the userland mutex objects from a machine word to a
> double-word boundary. No changes are required of the users who use such
> objects in their programs unless users create mutex objects in buffers
> which may not be aligned on a proper boundary.

Your reading of this is consistent with my previous understanding of the pr=
oblem, so that is good.

>=20
> I still don't have access to a SPARC machine. Any feed-back and/or
> SPARC build results are more than welcome!
>=20

I can provide build results for SPARCV9 if we want them, but I thought that=
 the problem only came up on 32-bit SPARCV8 builds.

The patch assumes the type `long double' exists on every platform. While I =
do believe that it is available everywhere, we have lots of conditional cod=
e guarding its use in the library now. If we are going to use `long double'=
 in this context, we should guard it with _RWSTD_NO_LONG_DOUBLE. I think an=
 even cleaner solution is to switch to using __rw_aligned_buffer instead. I=
t gives us a single point of failure for alignment issues like this, and it=
 makes the code self-documenting and easier to read.

As for your concerns about binary compatibility, I think that everything sh=
ould be okay. We aren't changing the size of anything that is being passed =
around, we're just changing its alignment. I could be wrong, but I'm pretty=
 sure that we're safe.