[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8kKok5EuXoRBdNANvEum3R5aSr8e2HNidhfJ9qW9nxwKQ@mail.gmail.com>
Date: Sun, 15 Dec 2019 13:06:29 -0500
From: Jeffrey Walton <noloader@...il.com>
To: musl@...ts.openwall.com
Subject: Re: max_align_t mess on i386
On Sat, Dec 14, 2019 at 10:19 AM Rich Felker <dalias@...c.org> wrote:
>
> In reserching how much memory could be saved, and how practical it
> would be, for the new malloc to align only to 8-byte boundaries
> instead of 16-byte on archs where alignof(max_align_t) is 8 (pretty
> much all 32-bit archs), I discovered that GCC quietly changed its
> idead of i386 max_align_t to 16-byte alignment in GCC 7, to better
> accommodate the new _Float128 access via SSE. Presumably (I haven't
> checked) the change is reflected with changes in the psABI document to
> make it "official".
Be careful with policy changes like this. The malloc (3) man page says:
The malloc() and calloc() functions return a pointer to the
allocated memory that is suitably aligned for any kind of variable.
I expect to be able to use a pointer returned by malloc (and friends)
in MMX, SSE and AVX functions.
Jeff
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
