This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/77330] __float128 segfaults on 32-bit x86 due to 8-byte malloc alignment
- From: "joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 23 Aug 2016 16:00:55 +0000
- Subject: [Bug target/77330] __float128 segfaults on 32-bit x86 due to 8-byte malloc alignment
- Auto-submitted: auto-generated
- References: <bug-77330-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
When there isn't whole-implementation, including library, support for the
types as "basic types" (see the resolution to DR#445), you need to
consider them as some other kind of type, analogous to vector types, for
which you need to use aligned_alloc (or posix_memalign etc.) just as with
vector types (if you'd used __m512 in place of __float128, for example).
But I say that unlike vector types, _Decimal128 and _Float128 *should* be
considered basic types, and so glibc, supporting being used together with
libdfp, *should* have the malloc alignment increased accordingly and this
should be considered a glibc bug (which is no longer hard to fix thanks to
the work done to fix malloc alignment on powerpc32).
It's always the case that however you construct a pointer to a type, it's
your responsibility to ensure that it's appropriately aligned for that
type, which means 16-byte-aligned for a structure containing __float128;
it's not GCC's responsibility to second-guess whether your code really
ensures that. If there are 16-byte-aligned basic types, malloc is an
appropriate means of ensuring that and it's a malloc bug not to provide
such alignment. When 16-byte-alignment is not a fundamental alignment
requirement, malloc is not an appropriate means and using malloc there is
a bug in the program using malloc for such an allocation.