r240248 - in /trunk/gcc: ChangeLog c-family/Cha...

[jsm28 at gcc dot gnu dot org]

Author: jsm28
Date: Mon Sep 19 21:51:56 2016
New Revision: 240248

URL: https://gcc.gnu.org/viewcvs?rev=240248&root=gcc&view=rev
Log:
Make max_align_t respect _Float128.

The _FloatN, _FloatNx, _DecimalN and _DecimalNx types are specified in
such a way that they are basic types, meaning that max_align_t must be
at least as aligned as those types.

On 32-bit x86, max_align_t is currently 8-byte aligned, but
_Decimal128 and _Float128 are 16-byte aligned, so the alignment of
max_align_t needs to increase to meet the standard requirements for
these types.

This patch implements such an increase.  Because max_align_t needs to
be usable for C++ as well as for C, <stddef.h> can't actually refer to
_Float128, but needs to use __float128 (or some other notation for the
type) instead.  And since __float128 is architecture-specific, there
isn't a preprocessor conditional that means "__float128 is available"
(whereas one could test __FLT128_MANT_DIG__ to see if _Float128 is
available; __SIZEOF_FLOAT128__ is available on x86 only).  But I
believe the only case that actually has an alignment problem here is
32-bit x86, and <stddef.h> already has lots of conditional specific to
particular architectures or OSes, so this patch uses a conditional on
__i386__; that also is the minimal change that ensures neither size
nor alignment of max_align_t is changed in any case other than where
it is necessary.  If any other architectures turn out to have such an
issue, it will show up as failures of one of the testcases added by
this patch.

Such an increase is of course an ABI change, but a reasonably safe
one, in that max_align_t doesn't tend to appear in library interfaces
(rather, it's something to use when writing allocators and similar
code; most matches found on codesearch.debian.net look like copies of
the gnulib stddef.h module rather than anything actually using
max_align_t at all).

max_align_t_align has a corresponding change (adding _Float128 to the
types considered).

(I think glibc malloc alignment should also increase to 16-byte on
32-bit x86 so it works for allocating objects of these types, which is
now straightforward given the fix made for 32-bit powerpc.)

Bootstrapped with no regressions on x86_64-pc-linux-gnu, and
spot-tested with -m32 that the new float128-align.c test now compiles
where previously it didn't.

gcc:
	* ginclude/stddef.h (max_align_t) [__i386__]: Add __float128
	element.

gcc/c-family:
	* c-common.c (max_align_t_align): Also consider alignment of
	float128_type_node.

gcc/testsuite:
	* gcc.dg/float128-align.c, gcc.dg/float128x-align.c,
	gcc.dg/float16-align.c, gcc.dg/float32-align.c,
	gcc.dg/float32x-align.c, gcc.dg/float64-align.c,
	gcc.dg/float64x-align.c, gcc.dg/floatn-align.h: New tests.

Added:
    trunk/gcc/testsuite/gcc.dg/float128-align.c
    trunk/gcc/testsuite/gcc.dg/float128x-align.c
    trunk/gcc/testsuite/gcc.dg/float16-align.c
    trunk/gcc/testsuite/gcc.dg/float32-align.c
    trunk/gcc/testsuite/gcc.dg/float32x-align.c
    trunk/gcc/testsuite/gcc.dg/float64-align.c
    trunk/gcc/testsuite/gcc.dg/float64x-align.c
    trunk/gcc/testsuite/gcc.dg/floatn-align.h
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-common.c
    trunk/gcc/ginclude/stddef.h
    trunk/gcc/testsuite/ChangeLog