Re: [boost] [config] [atomic] Problem with placement of BOOST_ALIGNMENT - requesting opinions/suggestions

Subject: Re: [boost] [config] [atomic] Problem with placement of BOOST_ALIGNMENT - requesting opinions/suggestions
From: Groke, Paul (paul.groke_at_[hidden])
Date: 2017-02-27 23:45:42

Everybody, I think I need to apologize for "not doing my homework" -
at least not as thoroughly as I probably should have.

I have now written the tests for explicit alignment support of the z/OS
compiler, and they revealed that it doesn't *reliably* support
explicit alignment at all. I'm sorry, I really didn't expect the
compiler to be *that* broken :(

In detail, my tests revealed that while the alignment specs for types
are parsed just fine where BOOST_ALIGNMENT should go, the compiler
"forgets" about them when repeatedly "nesting" the type that carries the
alignment requirement in other types that contain it as a member.
I.e. level 0 (=the type that's "annotated" with __aligned__) works fine,
leve 1 also works fine, but level 2 (e.g. a struct containing a struct
that contains the annotated type) falls back to alignment 8.
Current GCC, Clang and MSVC versions don't seem to have that problem,
they support nesting just fine - at least to a level of 8, which is
where I stopped.

I really thought that with Visual Studio 6.0 withering away in silence,
we wouldn't have to deal with compilers which are that severely broken
anymore.

Andrey Semashev wrote:
> On 02/28/17 00:39, Groke, Paul via Boost wrote:
>> Andrey Semashev wrote:
>>> This makes the compiler incompatible with the current semantics of
>>> BOOST_ALIGNMENT. You probably need to revise the changes made in
>>> the  recent Boost.Config PR[1] regarding BOOST_ALIGNMENT. Please,
>>> prepare  an updating PR for Boost.Config.
>>
>> Yes, I will. Should I undo the "make BOOST_ALIGNMENT definable in the
>> compiler header" part (the "escape") as well, or just the definition
>> of BOOST_ALIGNMENT in the header for the z/OS compiler?
>
> Thanks. I'm ok if the escape is left as is now.

Will do. Tomorrow - it's getting (too) late today.

>> Thanks! IMO that's the best immediate solution. The z compiler indeed
>> has an intrinsic for the z/Arch's "double-width CAS" instruction,
>> which would allow 128 bit atomics in 64 bit mode. But we don't need it.
>> And since there are plenty platforms that don't support double-width
>> CAS in 64 bit mode, not having it on z either should be acceptable.
>
> Ok, that's a good starting point. However, I think DCAS is used in
> Boost.Lockfree, and maybe somewhere else, so you may want to revisit
> this solution later.

Seems this is the only possible solution now, so I guess that's what I'll
do. Thanks for the hint to Boost.Lockfree, I'll check that in time. I don't
think we currently use Boost.Lockfree though. Since the places where
BOOST_ALIGNMENT is used inside Boost itself are limited, I think I'll
have a look at all of them when I find the time.

I don't expect a big problem though, since IIRC not even the Boost.Atomic
implementation for MSVC/x86 supports double width CAS in 64 bit mode.

Sorry again and thanks for all your help!

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4040 Linz, Austria, Freistaedterstrasse 313