Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   David Laight <David.Laight@ACULAB.COM>
To:     'YingChi Long' <me@inclyc.cn>
CC:     "bp@alien8.de" <bp@alien8.de>,
        "chang.seok.bae@intel.com" <chang.seok.bae@intel.com>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "hpa@zytor.com" <hpa@zytor.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "ndesaulniers@google.com" <ndesaulniers@google.com>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "x86@kernel.org" <x86@kernel.org>
Subject: RE: [PATCH v2] x86/fpu: use _Alignof to avoid UB in TYPE_ALIGN
Thread-Topic: [PATCH v2] x86/fpu: use _Alignof to avoid UB in TYPE_ALIGN
Thread-Index: AQHY0oauCPu6lqkmBkuKoE4b1f9eoq3zbbUQ///9N4CAARHtMA==
Date:   Wed, 28 Sep 2022 08:09:01 +0000
Message-ID: <fc12d0d4c1064832955543217d0dbe4a@AcuMS.aculab.com>
References: <38114d1b752c497eba1640360daf5b9e@AcuMS.aculab.com>
 <20220927164411.99297-1-me@inclyc.cn>
In-Reply-To: <20220927164411.99297-1-me@inclyc.cn>
Accept-Language: en-GB, en-US
MIME-Version: 1.0
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Precedence: bulk

From: YingChi Long
> Sent: 27 September 2022 17:44
> 
> > Interesting - what justification do they give?
> > Linux kernel requires that the compiler add no unnecessary padding
> > so that structure definitions are well defined.
> 
> Yes, that's a clarification given in 2019.
> 
> > So using a type definition inside offsetof() won't give a
> > useful value - but it still isn't really UB.
> 
> WG14 may worry about commas and the scope of new definitions. So they provide
> new words into the standard and said:
> 
> > If the specified type defines a new type or if the specified member is a
> > bit-field, the behavior is undefined.
> 
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm

Except that the kernel requires it to be defined.

Did they clarify the clause that required offsetof() to return
a compile-time constant?
That stops you doing offsetof(struct x, member->array[expression]).
(Oh and the compiler for a common OS disallows any version of that
even when expression in an integer constant!)

> 
> I've provided this link in the patch.
> 
> > Has that ever worked?
> > Given:
> > 	struct foo {
> > 		int a;
> > 		char b;
> > 		char c;
> > 	};
> 
> TYPE_ALIGN(struct foo) evaluates to 4 in the previous approach (based on
> offsetof). _Align(struct foo) evaluates to the same value.
> 
> See https://godbolt.org/z/sqebhEnsq
> 
> > I think CHECK_MEMBER_AT_END_OF_TYPE(struct foo, b) is true.
> 
> Hmm, both the previous version and after this patch the macro gives me
> false. (See the godbolt link).

See https://godbolt.org/z/95shMx44j

It return 1 for a and 0 for b and c (and char d,e following b).
NFI what it is trying to do!

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)