From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127889 invoked by alias); 26 Aug 2016 21:45:52 -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 127875 invoked by uid 89); 26 Aug 2016 21:45:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=allocators, UD:stddef.h, stddefh, stddef.h X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 26 Aug 2016 21:45:41 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D403F83F3C; Fri, 26 Aug 2016 21:45:38 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-204-37.brq.redhat.com [10.40.204.37]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7QLjZm4020620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Aug 2016 17:45:36 -0400 Subject: Re: Make max_align_t respect _Float128 To: Joseph Myers , gcc-patches@gcc.gnu.org References: Cc: eggert@cs.ucla.edu From: Florian Weimer Message-ID: <6a88ed59-7e52-9df0-13b3-c6f805290fb5@redhat.com> Date: Fri, 26 Aug 2016 21:45: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=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg01902.txt.bz2 On 08/26/2016 10:54 PM, Joseph Myers wrote: > Such an increase is of course an ABI change, but a reasonably safe > one, in that max_align_t doesn't tend to appear in library interfaces > (rather, it's something to use when writing allocators and similar > code; most matches found on codesearch.debian.net look like copies of > the gnulib stddef.h module rather than anything actually using > max_align_t at all). The crucial question is whether GCC will start assuming that pointers returned by malloc (or attribute-malloc functions) have such an alignment. That seems impossible. I'm pretty sure it does not right now because few mallocs have this property (jemalloc, tcmalloc, and until recently glibc's malloc on 32-bit powerpc and MIPS failed this requirement). They only provide 8-byte alignment even though the fundamental alignment is 16. For the dl-minimal malloc in glibc, the glibc consensus was to ignore max_align_t and go with the regular malloc alignment. Depending on what your malloc looks like, it can be very tempting *not* to provide 16-byte alignment for pointers returned from malloc (8) or strdup ("abc"), and practical evidence, gained with non-glibc malloc on x86_64 (where the fundamental alignment is 16), suggests that this is currently feasible. In the end, max_align_t is ignored by allocators, and applications cannot rely on it as a result. Florian