From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115132 invoked by alias); 6 Sep 2016 15:58:41 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 115122 invoked by uid 89); 6 Sep 2016 15:58:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu (HELO zimbra.cs.ucla.edu) (131.179.128.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Sep 2016 15:58:39 +0000 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6DEE316112A; Tue, 6 Sep 2016 08:58:37 -0700 (PDT) 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 ZhWgkcp3RsAb; Tue, 6 Sep 2016 08:58:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A3752161128; Tue, 6 Sep 2016 08:58:36 -0700 (PDT) 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 rVUOZ-eDYUA6; Tue, 6 Sep 2016 08:58:36 -0700 (PDT) Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 89F91161125; Tue, 6 Sep 2016 08:58:36 -0700 (PDT) Subject: Re: Make max_align_t respect _Float128 [version 2] To: Joseph Myers , Florian Weimer References: <3bb7530e-fff4-6030-a87e-1654d55d1e45@redhat.com> Cc: gcc-patches@gcc.gnu.org From: Paul Eggert Message-ID: Date: Tue, 06 Sep 2016 15:59:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-09/txt/msg00318.txt.bz2 On 09/06/2016 08:16 AM, Joseph Myers wrote: > I don't think there's any such requirement in the case of flexible array > members; if you use malloc to allocate a structure with a flexible array > member, you can access as many trailing array elements as would fit within > the allocated size, whether or not that size is a multiple of either the > alignment of the structure, or the alignment of max_align_t. Although I would prefer you to be correct I'm afraid the standard doesn't agree, as C11's wording appears to allow the GCC optimization in question. (At least, draft N1570 does; I don't have the final standard.) C11 section 6.7.2.1 paragraph 18 says: "when a . (or ->) operator has a left operand that is (a pointer to) a structure with a flexible array member and the right operand names that member, it behaves as if that member were replaced with the longest array (with the same element type) that would not make the structure larger than the object being accessed" Suppose 'short' size and alignment is 2, and the following code allocates and uses 7 bytes: struct s { short n; char a[]; } *p = malloc (offsetof (struct s, a) + 5); return &p->a[5]; A strict reading of C11 says this code is supposed to behave as if 'char a[];' were replaced by 'char a[4];'. It is not the 'char a[5]' that one might expect, because using 'char a[5];' would mean the size of struct s (after alignment) would be 8, whereas the size of the object being accessed is only 7. Hence the above return expression has a subscript error. One way to correct the code is to increase malloc's argument up to a multiple of alignof(max_align_t). (One cannot portably use alignof(struct s) due to C11's prohibition of using alignof on incomplete types.) This is why gnulib/lib/fts.c uses max_align_t.