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. > > > r~
> * 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 incorrect. Bye, -Andreas-
