Fixed breaks&replace dependency and some unit test fixes
suokkos at gmail.com
Sat Nov 5 12:31:50 UTC 2016
On Sat, Nov 5, 2016 at 11:33 AM, Sylvestre Ledru <sylvestre at mozilla.com> wrote:
> Le 03/11/2016 à 23:23, Pauli a écrit :
>> Attached patches fix some libc++ unit tests and dependency an issue.
> Impressive work, bravo!
>> I added versioned build dependency to clang. Versioned dependency is
>> only required for i386 packages. i386 version of package should be
>> build with two attached clang patches to generate code correctly for
>> i686 instead of clang's default pentium4 for 32 bit x86.
> I am concerned about this change, I think it is going to have side
> I guess libc++ will still ftbfs on i386 until I apply this patch, right?
I suspect that builder is running a newer processor than pentium4.
That means builder would like manage to build and run all tests but
libc++ package would be still unusable if running in a processor build
Side effects from the clang changes are default CPU feature target
matching gcc. That means clang won't generate SSE/SSE2 code by default
like it does now. It is easy override with
-march=pentium4/-march=native switches like with gcc. You can check
the difference between gcc and clang with simple preprocessor feature
gcc -m32 -dM -E - < /dev/null | egrep "__i|tune|pentiu|SSE"
clang -m32 -dM -E - < /dev/null | egrep "__i|tune|pentiu|SSE"
That means clang defaults to generating SSE2 code but i386 packages
should run on processors without simd instructions. (same issues as
Fix for maximum atomic width detection has effect only on processors
without cmpxchg8 instruction. You can check that with
$ clang++-3.9 test.cc -m32 -march=i386 -std=c++1z -stdlib=libc++ -latomic
broken behavior $ ./a.out
Lock free long long: yes
Always lock free LL: yes
correct behavior (on Broadwell, i386 would print no for first too) $ ./a.out
Lock free long long: yes
Always lock free LL: no
$ cat test.cc
std::atomic<long long> ll;
bool lock_free = ll.is_lock_free();
std::cout << "Lock free long long: " << (lock_free ? "yes" : "no") << "\n";
lock_free = std::atomic<long long>::is_always_lock_free;
std::cout << "Always lock free LL: " << (lock_free ? "yes" : "no") << "\n";
Broken behavior means clang inlined instructions that can't run with
older hardware. Correct behavior means clang generated calls to
libatomic that selects lock free instructions or mutex in runtime.
More information about the Pkg-llvm-team