On 07/09/2018 09:10 AM, David Laight wrote: > From: Mark Rutland >> Sent: 09 July 2018 16:49 >> >> On Mon, Jul 09, 2018 at 05:45:21PM +0200, Peter Zijlstra wrote: >>> On Mon, Jul 09, 2018 at 05:34:27PM +0200, Peter Zijlstra wrote: >>>> On Mon, Jul 09, 2018 at 04:29:58PM +0100, Mark Rutland wrote: >>>>> Shouldn't that be 8? AFAICT, __alignof__(unsigned long long) is 8 on >>>>> x86_32: >>>> >>>> Curious, I wonder why we put that align in atomic64_32 then. >>> >>> Shiny, look at this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54188 >>> >> >> Ouch. > > Indeed. > > changing the definition to: > struct ull { > unsigned long long v __attribute__((aligned(__alignof__(long long)))); > }; > > prints 8 for the structure alignment. So this will help force alignment of outer structures triggered by inner members, but only for globals and perhaps those on stack. I'm not sure how this helps aligning such a struct allocated dynamically - we are not passing this extra alignment info the the allocator API here. Surely the size will increase and we end up with extra padding in the end as intended originally and pointed to by Mark, but how does it help with alignment ? What am I missing ? > > Time to audit uses of __alignof__(). > > #define actual_alignof(type) __alignof__(struct { type jsdjdhjdjh; })
