[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191215054746.GD20973@voyager>
Date: Sun, 15 Dec 2019 06:47:46 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: max_align_t mess on i386
On Sat, Dec 14, 2019 at 10:19:32AM -0500, Rich Felker wrote:
> The disadvantage of leaving max_align_t alone is that we have to
> (continue to) consider _Float128 an unsupported extension type whose
> use would be outside the scope of any guarantees we make, and that
> would need memalign to use. This is largely viable at present because
> it's a fringe thing, but we don't know if that will continue to be
> true far in the future.
>
It wouldn't just be that. Any application making use of SSE vector types
would have to use *memalign(). Apparently, there are libraries out there
that expect to get a 16byte alignment out of malloc(), or at least
that's what the author of dietlibc is alleging here:
https://blog.fefe.de/?ts=bac7bb06
Yes, it's German, but Google Translate exists. More importantly though,
it is from 2006, and he says he's "hacking about with" a bignum library,
and I don't know if he means his own or a public one. In any case,
though, the mere existance of SSE was cause enough for that man to
change the allocator to return a higher alignment on x86. Maybe one more
factor leaning towards the ABI change, right?
> Rich
Ciao,
Markus
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.
