On 02/07/2012 12:12 AM, Andreas Krebbel wrote: > Hi, > > I would like to get rid of the atomic-2 failure on s390x. What do you think > about my > comments on the BIGGEST_ALIGNMENT check in omp-low.c? > > http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00009.html
I've reverted the patch in question, on 4.7 and mainline. This solves the incorrect code generation problem for s390x and re-introduces a testsuite failure on m68k. The later is not afaik a wrong-code problem, since in the m68k case we do wrap the atomic operation in a lock. The testsuite is not expecting that, however. One possible fix for the testsuite is to add -malign-int to the options for those tests. It is, arguably, an ABI problem for m68k to switch from using a lock in gcc 4.6 to a CAS insn in gcc 4.7. I had briefly looked into using another target hook before I stumbled across this issue. The better part of valour says leave it alone... r~
PR tree-opt/52242 Revert: 2011-11-26 Richard Henderson <r...@redhat.com> * omp-low.c (expand_omp_atomic): Assume anything aligned to BIGGEST_ALIGNMENT is aligned. diff --git a/gcc/omp-low.c b/gcc/omp-low.c index db71594..82ca4fd 100644 --- a/gcc/omp-low.c +++ b/gcc/omp-low.c @@ -5504,9 +5504,7 @@ expand_omp_atomic (struct omp_region *region) unsigned int align = TYPE_ALIGN_UNIT (type); /* __sync builtins require strict data alignment. */ - /* ??? Assume BIGGEST_ALIGNMENT *is* aligned. */ - if (exact_log2 (align) >= index - || align * BITS_PER_UNIT >= BIGGEST_ALIGNMENT) + if (exact_log2 (align) >= index) { /* Atomic load. */ if (loaded_val == stored_val