On Wed, 7 Sep 2016, Joseph Myers wrote:
> On Wed, 7 Sep 2016, Florian Weimer wrote:
>
> > The existence of such a cut-off constant appears useful, but it's
not clear if
> > it should be tied to the fundamental alignment (especially, as this
discussion
> > shows, the fundamental alignment will be somewhat in flux).
>
> I don't think it's in flux. I think it's very rare for a new basic type
> to be added that has increased alignment requirements compared to the
> existing basic types. _Decimal128 was added in GCC 4.3, which increased
> the requirement on 32-bit x86 (only) (32-bit x86 malloc having been
buggy
> in that regard ever since then); __float128 / _Float128 did not increase
> the requirement relative to that introduced with _Decimal128.
(Obviously
> if CPLEX part 2 defines vector types that might have larger alignment
requirements it must avoid defining them as basic types.)
Hmm...
interesting. I just tried the test case from PR 77330 with _Decimal128.
result: _Decimal128 did *not* trap with gcc4.8.4, but it does trap with
gcc-7.0.0.
include <stdio.h>
#include <stdlib.h>
struct s {
_Decimal128 f1;
};
int main(void)
{
struct s *p = malloc(sizeof(struct s));
printf("%p\n", p);
p->f1 = 1.234;
return 0;
}
gcc -m32 test.c
./a.out
0x9588008
Segmentation fault (core dumped)
So it looks to me, the ABI has changed incompatible recently, and I
believe that we need to proceed more carefully here. While in the
the future most targets will support aligned _Float128, we can
still support 4-byte aligned _Decimal128 on a per-target base.
I think that we need more flexibility in that area than we have
right now, because config/i386/i386.h is doing the ABI,
but it is shared by linux/glibc, windows, vxworks, darwin,
solaris, to name a few. I can't believe that we can just
change that ABI for the whole world at the same time.
See my experiment at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330#c9
which may be a hack, but shows that is no impossibility.
Bernd.
