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 21:39:19

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?
I personally would leave the "escape" part in, because - as I already
wrote in the PR discussion - I think every definition in suffix.hpp
should have an escape. But I'll of course do whatever you think is best.

> Note also that BOOST_ALIGNMENT can (and is) also used as a type attribute.
> Does your compiler support that?

I'm not sure, I'll have to write a test to confirm that. (It parses it
without warning, but then again it also parses it without warning at the
beginning of variable definitions -- it just also ignores it there
*sigh*)

> I'm not sure BOOST_PP_COMMA would work.

I'm ~90% sure it should work, but it's so ugly, and since you suggested
two IMO superior alternatives I guess the point is moot.

> (...) we could introduce a new
> macro, e.g.
> BOOST_TYPE_ALIGNMENT(n), that would be usable in that context, but not
> in the context of a variable declaration. It can be accompanied with
> BOOST_NO_TYPE_ALIGNMENT, similar to BOOST_NO_ALIGNMENT.

I like that! I'm not sure if one exotic compiler warrants it though.
If you think it does, I'd be happy to prepare a PR for that too.

The nice thing about that solution is that, assuming the z compiler
handles it correctly, it would catch (almost?) all current usages of
BOOST_ALIGNMENT in Boost that are more than an optimization.

The two usages for variables that I could find in 1.63 are in atomic,
which could probably be extended to use the new type macro on the buffer
struct as well as BOOST_ALIGNMENT on the member, and one usage in
libs/log/src/timestamp.cpp which seems to be just an optimization
(probably to avoid cache line sharing with other global variables).

BTW: Does anyone know of any other compilers that don't support
BOOST_ALIGNMENT-style specifications for variables, but do support
BOOST_ALIGNMENT-style alignment specifications for types?
Because then it wouldn't be just one exotic compiler anymore :)

> If it doesn't work with types, then you could just sacrifice 128-bit
> atomic ops in Boost.Atomic. No changes to Boost.Atomic should be needed
> for that because the lesser types should already get the necessary
> alignment naturally, and 128-bit storage will be disabled by the current
> preprocessor checks.

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.

----
Peter Dimov wrote:
>>> The obvious fourth option is to just #ifdef here for z/OS.
>>
>> BOOST_ALIGNMENT is used in quite a few places, including outside
>> Boost.Atomic. Adding preprocessor checks everywhere would be messy.
>
> Sure, but that's only going to be a problem if we want those places to
> compile on z/OS as well.
Right. As stated above I'm not sure one exotic compiler warrants a
change/extension to the general BOOST_ALIGNMENT mechanism. But if you/we
decide for it, the BOOST_TYPE_ALIGNMENT(n) thing would be my favorite
solution so far.
And if the decision is against it, I'm not sure that one exotic compiler
warrants #ifdef-ing the Boost.Atomic storage type implementation.
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