svn commit: r307756 - in head: include sys/sys

[Dimitry Andric]

On 22 Oct 2016, at 16:00, Dimitry Andric <dim at FreeBSD.org> wrote:
> 
> On 22 Oct 2016, at 02:00, Brooks Davis <brooks at freebsd.org> wrote:
...
>> Ideally I'd add a void * as well since that will support systems like
>> CHERI where pointers are the largest type.
> 
> Is void * larger than a struct with long long and long double?  I'd
> think this would be at least 128 bits on almost all architectures?
> 
> In any case, if you want to change this definition, it is probably best
> to first check it with upstream gcc, otherwise you'll end up with an
> incompatibility.

For some more historic context, see this LLVM commit:

http://llvm.org/viewvc/llvm-project?view=revision&revision=201729
------------------------------------------------------------------------
r201729 | chandlerc | 2014-02-19 23:35:01 +0100 (Wed, 19 Feb 2014) | 20 lines

Teach Clang to provide ::max_align_t in C11 and C++11 modes.

This definition is not chosen idly. There is an unfortunate reality with
max_align_t -- the specific nature of its definition leaks into the ABI
almost immediately. Because it is part of C11 and C++11 it becomes
essential for it to match with other systems on that ABI. There is an
effort to discourage any further use of this construct as a consequence
-- using max_align_t introduces an immediate ABI problem. We can never
update it to have larger alignment even as the microarchitecture changes
to necessitate higher alignment. =/

The particular definition here exactly matches the ABI of GCC's chosen
::max_align_t definition, for better or worse. This was written with the
help of Richard Smith who was decoding the exact ABI implications of the
selected definition in GCC. Notably, in-register arguments are impacted
by the particular definition chosen. =/

No one is under the illusion that this is a "good" or "useful"
definition of max_align_t, and we are working with the standards
committee to specify a more useful interface to address this need.
------------------------------------------------------------------------

E.g., it is likely better to avoid using max_align_t altogether.

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20161022/d54aa54d/attachment.sig>