On 07/04/15 06:51 -0400, Hans-Peter Nilsson wrote:
On Tue, 7 Apr 2015, Jonathan Wakely wrote:
On 05/04/15 21:07 -0400, Hans-Peter Nilsson wrote:
> On Fri, 3 Apr 2015, Jonathan Wakely wrote:
>
> > On 03/04/15 05:24 -0400, Hans-Peter Nilsson wrote:
> > > On Thu, 2 Apr 2015, Hans-Peter Nilsson wrote:
> > > > Why then use __alignof(_M_i) (the object-alignment)
> > > > instead of _S_alignment (the deduced alas insufficiently
> > > > increased type-alignment)?
> >
> > Isn't the object aligned to _S_alignment?
>
> We did specify that with the alignas. Is the alignof always
> exactly the same as an alignas, if one is specified? (And will
> that not change in a future amendment, standard and/or
> implementation?) Either way, is there a test-case to guard all
> this?
The language guarantees that's what alignas() does, if the argument is
a valid alignment (which it must be if we derive it from some other
type's alignment).
I'm more worried about alignof reporting a higher value for a
specific object than alignas to be wrong.
That shouldn't be possible because the C++ standard says it's an error
to use alignas with a less strict alignment than would be used if it
was omitted, i.e. an error to use alignas with a value less than the
result alignof would give. However, G++ doesn't reject it (PR65685).
It still won't be possible here, because the alignas value we use is
not less than alignof(_Tp).
Your question quoted just below seems to indicate a similar
worry.
I was thinking about cases like this:
struct __attribute__((packed)) Bad {
char c;
std::atomic<long long> a;
};
But G++ ignores the packed attribute here, which is good (Clang
doesn't seem to ignore it, and mis-aligns the atomic).
> > Or is it different if a std::atomic<T> is included in some other
> > struct and the user forces a different alignment on it? I don't think
> > we really need to support that, users shouldn't be doing that.
>
> Why do we even need to ask those questions, when the patch takes
> care of the per-type business without doubt?
Well if we know the object is guaranteed to be correctly aligned we
might not even need a fake, minimally aligned pointer. We could go
back to passing &_M_i or just a null pointer to __atomic_is_lock_free.
The target has a say in __atomic_is_lock_free and could impose
some crazy pointer-value-specific condition like "only in the
first half of a page" (anything can happen to work around chip
errata) so I suggest staying with an alignment-generated
pointer. No, I only dreamt that up, shoot it down if we only
care for current targets.
The whole point of alignas() is to fix the alignment to a known value.
And alignof and __alignof to report *exactly* that, I hope?
Yes, alignas sets the alignment requirement, alignof gets it.
