From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69509 invoked by alias); 6 Sep 2016 09:23: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 69498 invoked by uid 89); 6 Sep 2016 09:23:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=diplomatic, relationship X-HELO: mail-wm0-f53.google.com Received: from mail-wm0-f53.google.com (HELO mail-wm0-f53.google.com) (74.125.82.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Sep 2016 09:23:24 +0000 Received: by mail-wm0-f53.google.com with SMTP id b187so53538580wme.1 for ; Tue, 06 Sep 2016 02:23:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=azeo/0FLP2YcR+oqeWwjvpkoa8KRvOJSIYab0rYnA9Q=; b=L1cD1SOfQiJpr8A5i84DmsCzCr+rmagGfn7o0F3Pgr6b4SlGhLCvRSYE0UE0MMPBNo gyoZVdheUGv3ohQLopMP44OvbhOX+eWUQaHGSY4hAgQe+pqfBaP7IMIqPdDgDQpfWIdE JlvyqChjkpKD6fgtp6jP0gLV50OaAdivIW6j/0z1VBPtJVWI+1W0YAxSJc+zkLr8x3Va SiQBIM44bvECjZayl+sr5NdzuQpLzaas9Efca7TpaqZkcHqrgoqLxrPS7ijHbGdN07nG Jx8eAnVQKYutXr24vsYQFahM9im8PeOtrV4RIy+0npFu19VGkDF1a1jvu2qThi3gqp8J V9LA== X-Gm-Message-State: AE9vXwMGE+KJek7DS3jpNFgL8q5cGZrzXULcjJ9VuK57Qo+YydVDPLORtCgCkHq6uCD5BRxYWPCqv92sXzrYiQ== X-Received: by 10.194.24.73 with SMTP id s9mr11609147wjf.74.1473153802283; Tue, 06 Sep 2016 02:23:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.137.202 with HTTP; Tue, 6 Sep 2016 02:23:21 -0700 (PDT) In-Reply-To: References: From: Richard Biener Date: Tue, 06 Sep 2016 09:24:00 -0000 Message-ID: Subject: Re: Make max_align_t respect _Float128 [version 2] To: Florian Weimer Cc: Joseph Myers , GCC Patches , Paul Eggert Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00270.txt.bz2 On Tue, Sep 6, 2016 at 11:11 AM, Florian Weimer wrote: > On 09/05/2016 07:06 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). > > > I've thought some more about this. I'll try to rephrase my reservations = in > a less diplomatic way, hopefully making my thoughts clearer. > > I think this change is only safe because nothing relies on it. max_align_t > is a committee invention with no actual users. As such, you can change it > in any way you see fit and it won't make a difference in any way. > > 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 =E2=80=9Call cont= exts=E2=80=9D > 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? > > 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. > > For object alignment declarations, I think GCC can satisfy most requests, > perhaps subject to binutils/dynamic linker limitations for global variabl= es > on some targets. > > The question then is, how can we make max_align_t more useful? If it is > supposed to reflect a malloc property, it cannot be a compile-time consta= nt > because we don't know at compile time which malloc is going to be used > (malloc has to remain interposable). If there is no relationship to mall= oc, > GCC essentially supports unbounded alignment on many targets. How is it > possible to have a meaningful definition of max_align_t under such > circumstances? I thought max_align_t was to replace uses like union { long long x; double y; ... char buf[N]; }; to get statically allocated "max" aligned memory. That is, you now know _which_ type you need to put into the union. Richard. > Florian