From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40460 invoked by alias); 6 Sep 2016 11:26:11 -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 40445 invoked by uid 89); 6 Sep 2016 11:26:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=c99, relationship, UD:htm X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Sep 2016 11:26:01 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1bhEVr-0003oF-1D from joseph_myers@mentor.com ; Tue, 06 Sep 2016 04:25:59 -0700 Received: from digraph.polyomino.org.uk (137.202.0.87) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Sep 2016 12:25:55 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.86_2) (envelope-from ) id 1bhEVj-0001YZ-1Y; Tue, 06 Sep 2016 11:25:51 +0000 Date: Tue, 06 Sep 2016 11:40:00 -0000 From: Joseph Myers To: Florian Weimer CC: , Subject: Re: Make max_align_t respect _Float128 [version 2] In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1152306461-746962111-1473161151=:31924" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2016-09/txt/msg00285.txt.bz2 ---1152306461-746962111-1473161151=:31924 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8BIT Content-length: 1470 On Tue, 6 Sep 2016, Florian Weimer wrote: > Why aren't there any users? The standard isn't very clear what the value of > _Alignof (max_align_t) actually means. Does the phrase “all contexts” include > pointers returned malloc? Even if the requested size is smaller than the > fundamental alignment? Did those who wrote the standard expect there to be > *any* relationship between malloc and max_align_t? See my cleanup of the wording in DR#445 , which is intended to reflect the intent and stay compatible with C99. malloc should be usable to allocate memory for any type from the standard library headers, including max_align_t. > The existing situation is that most mallocs to do not provide _Alignof > (max_align_t) alignment unconditionally. But they can provide arbitrarily > large alignment with aligned_alloc/memalign-style interfaces. Well, that's a conformance bug in the implementation as a whole. The nonconforming modes in question are still useful and it's useful for GCC to support such mallocs. > has to remain interposable). If there is no relationship to malloc, GCC > essentially supports unbounded alignment on many targets. How is it possible > to have a meaningful definition of max_align_t under such circumstances? max_align_t only covers fundamental alignments, not necessarily all alignments that are supported. -- Joseph S. Myers joseph@codesourcery.com ---1152306461-746962111-1473161151=:31924--