This is an archive of the discontinued LLVM Phabricator instance.

Un-XFAIL GCC atomics.align
AbandonedPublic

Authored by jfb on Aug 1 2016, 5:16 PM.

Details

Reviewers
EricWF
Summary

The ABI version flag should fix the error.

Diff Detail

Event Timeline

jfb updated this revision to Diff 66404.Aug 1 2016, 5:16 PM
jfb retitled this revision from to Un-XFAIL GCC atomics.align.
jfb updated this object.
jfb added a reviewer: EricWF.
jfb added a subscriber: cfe-commits.
jfb added a comment.Aug 3 2016, 1:43 PM

@EricWF ran this on configuration cxx_under_test=g++-4.9. It generates the following error:

libcxx/test/libcxx/atomics/atomics.align/align.pass.sh.cpp:32: atomic_test<T>::atomic_test() [with T = std::nullptr_t]: Assertion `alignof(this->__a_) >= sizeof(this->__a_) && "expected natural alignment for lock-free type"' failed.

I think GCC is broken. See the following (semi-relevant) test: https://godbolt.org/g/pFUqVY
That's not quite what I'm testing (this used libstdc++ and looks at std::atomic, not the value contained), but I'd nonetheless expect the std::atomic container to be sufficiently aligned.

WDYT?

Is that only happening for nullptr_t?

I can conditionally disable the nullptr_t test for GCC, and file a bug on GCC.

jfb added a comment.Aug 3 2016, 2:54 PM

I wrote a quick test, and I think this is technically OK for x86 because alignment "Just Works", but I think it's borked on GCC+ARM (I don't have a system to test that here): https://github.com/jfbastien/atomic_nullptr/blob/master/atomic_nullptr.cc

EricWF edited edge metadata.Dec 30 2016, 3:05 AM

Have you filed a bug against GCC regarding its current behavior?

Also it seems like a bad idea to add -fabi-version=6, since it selects an older ABI version and not a newer one. Testing the old behavior is not what we want.

I think the best plan is to simply split the vector_size tests into another file and XFAIL that for GCC. At least then we get some coverage.

jfb added a comment.May 7 2018, 9:57 PM

Have you filed a bug against GCC regarding its current behavior?

Also it seems like a bad idea to add -fabi-version=6, since it selects an older ABI version and not a newer one. Testing the old behavior is not what we want.

I think the best plan is to simply split the vector_size tests into another file and XFAIL that for GCC. At least then we get some coverage.

Reviving this old thread... Do you think this is still the right approach? I can file the GCC bug and split off the test.

OK, here's what I would do:

(1) Split the vector, nullptr, and other weirdly failing tests into their own files.
(2) In each file, use defined(TEST_COMPILER_GCC) && __GXX_ABI_VERSION > 1006 (or w/e version is broken) to define a macro when the test is expected to fail.
(3) Either ifdef out failing tests, or change the assertion to expect failure. The latter is probably preferable as it will allow us to detect if they test ever starts unexpectedly passing.
(4) Add tests for GCC with different fabi-version options. I would make these separate test files which wrap the actual test their targeting. For example:

//
// This file is dual licensed under the MIT and the University of Illinois Open
// Source Licenses. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// REQUIRES: gcc, libatomic
// UNSUPPORTED: libcpp-has-no-threads, c++98, c++03
//
// RUN: %cxx -o %t.one.exe %s %all_flags -latomic -fabi-version=2 && %t.one.exe
// RUN: %cxx -o %t.two.exe %s %all_flags -latomic -fabi-version=6 && %t.two.exe
// RUN: %cxx -o %t.three.exe %s %all_flags -latomic -fabi-version=9 && %t.three.exe

#include "align-vector-types.sh.cpp"

How does that sound?

jfb abandoned this revision.Aug 26 2020, 8:41 AM