From owner-svn-src-head@freebsd.org Sat Oct 22 14:16:22 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1EC0C1C329; Sat, 22 Oct 2016 14:16:22 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E7953A7; Sat, 22 Oct 2016 14:16:22 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::f9cd:eb1b:c961:7062] (unknown [IPv6:2001:7b8:3a7:0:f9cd:eb1b:c961:7062]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E58E91360B; Sat, 22 Oct 2016 16:16:19 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_28DABD1C-67B4-437C-BECC-29ABA83694D3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r307756 - in head: include sys/sys From: Dimitry Andric In-Reply-To: <0C5786D6-EB91-4762-9FAB-4C447EAB0AF8@FreeBSD.org> Date: Sat, 22 Oct 2016 16:16:10 +0200 Cc: John Baldwin , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Message-Id: <6A32024C-BEAC-43FE-8581-CBCCCB1D1F34@FreeBSD.org> References: <201610212350.u9LNo2PT031675@repo.freebsd.org> <20161022000056.GC95989@spindle.one-eyed-alien.net> <0C5786D6-EB91-4762-9FAB-4C447EAB0AF8@FreeBSD.org> To: Brooks Davis X-Mailer: Apple Mail (2.3124) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2016 14:16:22 -0000 --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 wrote: > > On 22 Oct 2016, at 02:00, Brooks Davis 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--