From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: emacs-26 9e59de9: Use GCALIGNED properly for GCC Date: Fri, 10 Nov 2017 12:45:15 -0800 Organization: UCLA Computer Science Department Message-ID: <37a4a9fa-52f8-8441-d64f-40c5d74124be@cs.ucla.edu> References: <20171109031206.7056.28312@vcs0.savannah.gnu.org> <20171109031208.D2CAF2033E@vcs0.savannah.gnu.org> <5A0550FE.2030703@gmx.at> <83zi7upnfo.fsf@gnu.org> <4ee60712-789e-f160-52a9-4e24a9733a11@cs.ucla.edu> <83shdmpiah.fsf@gnu.org> <8d9c169a-5f58-6958-9fca-4c68fa547ba3@cs.ucla.edu> <96b1c7b9-e461-a878-02d5-d095ad246e0c@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1510346726 16210 195.159.176.226 (10 Nov 2017 20:45:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 10 Nov 2017 20:45:26 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 Cc: Philipp Stephani , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 10 21:45:22 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eDGB0-0003zq-CC for ged-emacs-devel@m.gmane.org; Fri, 10 Nov 2017 21:45:22 +0100 Original-Received: from localhost ([::1]:43451 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDGB7-0002mf-K7 for ged-emacs-devel@m.gmane.org; Fri, 10 Nov 2017 15:45:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eDGB0-0002mO-Oz for emacs-devel@gnu.org; Fri, 10 Nov 2017 15:45:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eDGAv-0001Cm-QO for emacs-devel@gnu.org; Fri, 10 Nov 2017 15:45:22 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:38628) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eDGAv-0001CW-Hj for emacs-devel@gnu.org; Fri, 10 Nov 2017 15:45:17 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2E4AF1610C4; Fri, 10 Nov 2017 12:45:16 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id uLoWJbiwUrMU; Fri, 10 Nov 2017 12:45:15 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 76DFC1610CA; Fri, 10 Nov 2017 12:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aVTIiO6ImVrM; Fri, 10 Nov 2017 12:45:15 -0800 (PST) Original-Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 5373B1610C4; Fri, 10 Nov 2017 12:45:15 -0800 (PST) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:220037 Archived-At: Stefan Monnier wrote: > Then I don't understand what you meant by "that does not work either". I was confused (:-). I suppose I was worried about the admittedly unlikel= y=20 possibility of a platform where alignof (int64_t) exceeds 8. This worry s= temmed=20 from an earlier iteration of this fix, where we ran into such a type on=20 MS-Windows. Although perhaps I'm worrying too much, the point remains tha= t=20 because int64_t's alignment is not always a multiple of 8, using int64_t = for=20 alignment would not suffice for platforms where alignas does not work. Also, there's at least one type (struct vectorlike_header) where alignmen= t is=20 convenient, and where the type's size is smaller than int64_t on some pla= tforms,=20 so using int64_t for alignment there would cause objects of this type (an= d of=20 its containing types) to grow unnecessarily.