https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798
--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 27 Jan 2015, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64798 > > --- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > __BIGGEST_ALIGNMENT__ has nothing to do with alignment of malloc returned > memory. > The union I've mentioned is a reasonable guess (something actually mandated by > the standard), glibc right now guarantees 2 * sizeof (void *) (which is wrong > for ppc32). For malloc alignment, we've added an attribute for that, but > glibc > maintainers haven't added it to their headers :( and obviously other libcs > neither. I can drop __BIGGEST_ALIGNMENT__ and use alignof (allocated_entry::data) which is aligned via __attribute__((aligned)) by the patch (same trick that badalloc1.C uses). That attribute trick is documented as "Alternatively, you can leave out the alignment factor and just ask the compiler to align a variable or field to the default alignment for the target architecture you are compiling for. The default alignment is sufficient for all scalar types, but may not be enough for all vector types on a target that supports vector operations. The default alignment is fixed for a particular target ABI." but then "GCC also provides a target specific macro @code{__BIGGEST_ALIGNMENT__}, which is the largest alignment ever used for any data type on the target machine you are compiling for." and the following example suggests that the first doesn't necessarily matches the second. Though testing on x86_64 reveals that __attribute__((aligned)) aligns to 16 bytes as well.
