This is the mail archive of the
mailing list for the GCC project.
Re: Adjust omp-low test for alignment
- From: "Andreas Krebbel" <krebbel at linux dot vnet dot ibm dot com>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: jakub at redhat dot com, hp at bitrange dot com, gcc-patches at gcc dot gnu dot org
- Date: Wed, 1 Feb 2012 09:22:54 +0100
- Subject: Re: Adjust omp-low test for alignment
- References: <4ED17EB4.email@example.com>
On Sat, Nov 26, 2011 at 04:05:08PM -0800, Richard Henderson wrote:
> The m68k-linux failure for the various omp atomic tests
> is due to the fact that BIGGEST_ALIGNMENT is 16 bits on
> that platform. I think it's pretty reasonable to assume
> that if something is aligned to BIGGEST_ALIGNEMENT, then
> it can be considered "aligned".
> Tested on x86_64-linux and m68k-linux cross.
> * omp-low.c (expand_omp_atomic): Assume anything aligned to
> BIGGEST_ALIGNMENT is aligned.
That broke the atomic-2.c libgomp testcase on s390x. We have
BIGGEST_ALIGNMENT of 64. A 128 bit long double does not need to be
aligned better than 64 bit in memory. However, the 128bit compare and
swap instruction we have requires the operands to be naturally
aligned. In the testcase a compare and swap double instruction is used
on a long double value which is only 8 byte aligned in memory.
This seem to have caused problems on CRIS as well. The proposed
solution was to force the alignment of the types using that aligned
attribute. While this is a good idea anyway in order to get the proper
hardware instructions, I think omp-low should be able to pick a
fallback solution if necessary. Otherwise, we will silently insert
bugs which are difficult to find. The atomic-2 testcase for example
succeeds very often since the long double happens to be naturally
aligned in a lot of cases. So to my understanding the change above is