This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/77330] __float128 segfaults on 32-bit x86 due to 8-byte malloc alignment


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]