From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24597 invoked by alias); 26 Aug 2016 21:30:35 -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 23292 invoked by uid 89); 26 Aug 2016 21:30:32 -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=max_align_t, __i386__, itanium, sk:__SIZEO 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; Fri, 26 Aug 2016 21:30:22 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1bdOhf-0005Gy-11 from joseph_myers@mentor.com ; Fri, 26 Aug 2016 14:30:19 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Fri, 26 Aug 2016 22:30:17 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.86_2) (envelope-from ) id 1bdOhc-0002ga-CS; Fri, 26 Aug 2016 21:30:16 +0000 Date: Fri, 26 Aug 2016 21:30:00 -0000 From: Joseph Myers To: CC: , Subject: Re: Make max_align_t respect _Float128 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2016-08/txt/msg01901.txt.bz2 On Fri, 26 Aug 2016, Marc Glisse wrote: > On Fri, 26 Aug 2016, Joseph Myers wrote: > > > And since __float128 is architecture-specific, there > > isn't a preprocessor conditional that means "__float128 is available" > > That's what __SIZEOF_FLOAT128__ was supposed to be for. I didn't add it to > itanium because zombies, and it looks like powerpc didn't add the macro when > they later gained __float128 support, but that would be easy to fix. Well, the patch could use __SIZEOF_FLOAT128__ just as well as __i386__ (the effect would be an extra union member that does nothing in the x86_64 case) without the macro needing defining on other architectures. What would be trickier is if a new architecture gets support for _Float128 (as a type increasing the alignment requirement) without the old __float128 name, and then for C++ compatibility the header needs to use float __attribute__ ((__mode__ (__TF__))) as the type name on that architecture (but on powerpc, TFmode may not be the mode for this type). Anyway, we need review of the principle of increasing the alignment, and given that can consider what the best choice of macro is. -- Joseph S. Myers joseph@codesourcery.com