Date: Sat, 22 Oct 2016 16:16:10 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Brooks Davis <brooks@freebsd.org> Cc: John Baldwin <jhb@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r307756 - in head: include sys/sys Message-ID: <6A32024C-BEAC-43FE-8581-CBCCCB1D1F34@FreeBSD.org> In-Reply-To: <0C5786D6-EB91-4762-9FAB-4C447EAB0AF8@FreeBSD.org> References: <201610212350.u9LNo2PT031675@repo.freebsd.org> <20161022000056.GC95989@spindle.one-eyed-alien.net> <0C5786D6-EB91-4762-9FAB-4C447EAB0AF8@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_28DABD1C-67B4-437C-BECC-29ABA83694D3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 22 Oct 2016, at 16:00, Dimitry Andric <dim@FreeBSD.org> wrote: > > On 22 Oct 2016, at 02:00, Brooks Davis <brooks@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 --Apple-Mail=_28DABD1C-67B4-437C-BECC-29ABA83694D3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAlgLdLMACgkQsF6jCi4glqNbJwCdGNzIy5gP+W9jYFwmfdkYAfcF 2YEAn1hoQhtsgK4ak27sffE/LmOzG21h =RPfZ -----END PGP SIGNATURE----- --Apple-Mail=_28DABD1C-67B4-437C-BECC-29ABA83694D3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6A32024C-BEAC-43FE-8581-CBCCCB1D1F34>