This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [libstdc++/65033] Give alignment info to libatomic
- From: Richard Henderson <rth at redhat dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, Andrew MacLeod <amacleod at redhat dot com>
- Date: Tue, 31 Mar 2015 08:13:44 -0700
- Subject: Re: [libstdc++/65033] Give alignment info to libatomic
- Authentication-results: sourceware.org; auth=none
- References: <54DD19B7 dot 6060401 at redhat dot com> <20150218121512 dot GI3360 at redhat dot com> <20150325162244 dot GF9755 at redhat dot com> <5513003D dot 3040107 at redhat dot com> <20150325184913 dot GH9755 at redhat dot com> <551306C1 dot 6060702 at redhat dot com> <20150326132147 dot GL9755 at redhat dot com> <20150331134136 dot GS9755 at redhat dot com> <551AB523 dot 5040203 at redhat dot com> <20150331150329 dot GT9755 at redhat dot com>
On 03/31/2015 08:03 AM, Jonathan Wakely wrote:
> On 31/03/15 07:54 -0700, Richard Henderson wrote:
>> On 03/31/2015 06:41 AM, Jonathan Wakely wrote:
>>> This is the best I've come up with, does anyone have any better ideas
>>> than the #else branch to hardcode alignment of 16-byte types to 16?
>>
>> If there's no 16 byte type, are we convinced this matters? I mean, there isn't
>> a 16-byte atomic instruction for 32-bit x86 (or any other 32-bit cpu of which I
>> am aware). So we're forced to use a locking path anyway.
>
> The C front end gives struct S { char s[16]; } 16 byte alignment...
Um, I'm pretty sure it doesn't.
struct S { char s[16]; };
int x = __alignof(struct S);
.type x, @object
.size x, 4
x:
.long 1
What you're interpreting as alignment for that struct is probably optional
*additional* alignment from LOCAL_ALIGNMENT or LOCAL_DECL_ALIGNMENT or something.
> And it matters most for the integral types, not arbitrary structs.
>
>> And if we do want the alignment, do we stop pretending with all the sizeof's
>> and alignof's and just use power-of-two size alignment for all of them, e.g.
>>
>> min_align = ((size & (size - 1)) || size > 16 ? 0 : size)
>
> Yeah, I wondered about that too. Joseph indicated there are targets
> where C gives alignof(_Atomic X) != sizeof(X), which is why the target
> hook exists, but maybe we can just not worry about those targets for
> now.
Those targets have alignof < sizeof. So in a way we'd probably be doing them a
favor. I know for instance that CRIS is in this category, where most data is
all byte aligned, but atomics must be naturally aligned.
And, as you note, just so long as we do the same thing for _Atomic once we
get that merged.
r~