On 09/08/16 11:35, Florian Weimer wrote: > On 09/07/2016 08:32 PM, Bernd Edlinger wrote: >> 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. > > Recent GCC versions rely on struct pointer alignment for struct member > access, older versions did less so. >
Yes. Bugs get fixed, better vector-optimizations happen. And new Intel processor have sse, avx etc. instructions that take advantage of the alignedness of memory references, but other than previous architectures simply trap when the address is not aligned. > For example, this tcsh bug flew under the radar for about two years: > > <https://bugzilla.redhat.com/show_bug.cgi?id=1303323> > > (glibc added 16-byte alignment to struct __dirstream as a side effect of > a change to help sparc in 2013, and this did not cause any trouble with > tcsh before.) Yeah, that's really unfortunate. A 16-Byte aligned structure like that is of course an invitation for the vectorizer. Especially when the intent was to have an 8-byte aligned structure. In the case of the __dirstream the __alignof__ (long double) does not really do what the comment above says (64-bit alignment on sparc-32). I am not sure if it would be better to explicitly use __attribute__((__aligned__ (8))) here. I have no experience with sparc, but from reading the gcc/config/sparc.h I would guess that __alignof__(long double) = sizeof(long double) = 8 on sparc-32 and __alignof__(long double) = sizeof(long double) = 16 on sparc-64 However on i386 it will be __alignof__(long double) = 4 and sizeof(long double)=16 on -m32 and __alignof__(long double) = 16 and sizeof(long double)=16 on -m64 Bernd.
