On 02/07/2012 12:12 AM, Andreas Krebbel wrote:
> 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?
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...
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
@@ -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