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...

        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

Reply via email to