[llvm-bugs] [Bug 31864] New: 4.0/trunk regression: after r291477, incorrect _GCC_ATOMIC_LLONG_LOCK_FREE values on i386-freebsd

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=31864

            Bug ID: 31864
           Summary: 4.0/trunk regression: after r291477, incorrect
                    _GCC_ATOMIC_LLONG_LOCK_FREE values on i386-freebsd
           Product: new-bugs
           Version: 4.0
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: dimitry at andric.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

In r291477, some long-standing inconsistencies with
__GCC_ATOMIC_LLONG_LOCK_FREE were fixed, solving bug 19355
(__GCC_ATOMIC_LLONG_LOCK_FREE only set to 1 on X86) and bug 30581 (Inconsistent
value of ATOMIC_LLONG_LOCK_FREE vs __atomic_always_lock_free(sizeof(long long),
0) on 32-bit x86).

However, this fix has the unfortunate side effect of making the value of
__GCC_ATOMIC_LLONG_LOCK_FREE incorrect on 32-bit FreeBSD, e.g. the
i386-unknown-freebsd target.  This is because 32-bit FreeBSD defaults to
targeting i486, not i686 like most Linuxes:

  $ uname -srm
  FreeBSD 12.0-CURRENT i386

  $ gcc -dM -E -x c /dev/null | grep LLONG_LOCK
  #define __GCC_ATOMIC_LLONG_LOCK_FREE 1

  $ clang-3.9.1 -dM -E -x c /dev/null | grep LLONG_LOCK
  #define __GCC_ATOMIC_LLONG_LOCK_FREE 1

  $ clang-4.0.0 -dM -E -x c /dev/null | grep LLONG_LOCK
  #define __GCC_ATOMIC_LLONG_LOCK_FREE 2

As I mentioned in https://reviews.llvm.org/D28213, the value of
__GCC_ATOMIC_LLONG_LOCK_FREE is now still incorrect, even on Linux, if you
target i486:

  $ uname -srm
  Linux 3.16.0-4-686-pae i686

  $ gcc -dM -E -x c /dev/null | grep LLONG_LOCK
  #define __GCC_ATOMIC_LLONG_LOCK_FREE 2

  $ gcc -march=i486 -dM -E -x c /dev/null | grep LLONG_LOCK
  #define __GCC_ATOMIC_LLONG_LOCK_FREE 1

It turns out that this has been broken since quite some time (r142002, to be
exact), as tools/clang/lib/Basic/Targets.cpp has this comment:

  X86_32TargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
      : X86TargetInfo(Triple, Opts) {
    [...]
    // x86-32 has atomics up to 8 bytes
    // FIXME: Check that we actually have cmpxchg8b before setting
    // MaxAtomicInlineWidth. (cmpxchg8b is an i586 instruction.)
    MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 64;

We need to either fix this constructor to assign the correct max atomic inline
width for the target (either via the triple or via -march=), or r291477 must be
reverted.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170204/a753bb7d/attachment.html>