Re: [boost] Boost 1.56 ARM builds broken? (was: Re: [Boost-users] [1.56.0] Beta 1 Available)

Subject: Re: [boost] Boost 1.56 ARM builds broken? (was: Re: [Boost-users] [1.56.0] Beta 1 Available)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-07-21 15:09:45

On Monday 21 July 2014 18:30:28 Niall Douglas wrote:
> 
> I also was surprised how badly broken clang is, so here is how it is
> being called:
> 
>   "clang++" -c -x c++ -O0 -g -fno-inline -Wall -g -pthread -fPIC
> -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_ATOMIC_SOURCE
> -I"." -o
> "bin.v2/libs/atomic/build/clang-linux-3.4/debug/threading-multi/lockpo
> ol.o" "libs/atomic/src/lockpool.cpp"
> 
> /tmp/lockpool-426fb3.s: Assembler messages:
> /tmp/lockpool-426fb3.s:165: Error: selected processor does not
> support ARM mode `ldrexb r1,[r0]'
> /tmp/lockpool-426fb3.s:167: Error: selected processor does not
> support ARM mode `strexb r2,r3,[r0]'
> /tmp/lockpool-426fb3.s:179: Error: selected processor does not
> support ARM mode `ldrexb r1,[r0]'
> /tmp/lockpool-426fb3.s:181: Error: selected processor does not
> support ARM mode `strexb r2,r3,[r0]'
> /tmp/lockpool-426fb3.s:197: Error: selected processor does not
> support ARM mode `ldrexb r1,[r0]'
> /tmp/lockpool-426fb3.s:199: Error: selected processor does not
> support ARM mode `strexb r2,r3,[r0]'
> /tmp/lockpool-426fb3.s:214: Error: selected processor does not
> support ARM mode `ldrexb r1,[r0]'
> /tmp/lockpool-426fb3.s:216: Error: selected processor does not
> support ARM mode `strexb r2,r3,[r0]'
> /tmp/lockpool-426fb3.s:233: Error: selected processor does not
> support ARM mode `ldrexb r1,[r0]'
> /tmp/lockpool-426fb3.s:235: Error: selected processor does not
> support ARM mode `strexb r2,r3,[r0]'
> clang: error: assembler command failed with exit code 1 (use -v to
> see invocation)
> 
> That smells to me like ARM Ubuntu 14.04 has a badly configured clang?
> Thoughts?

Boost.Atomic uses compiler macros to select the backend. Given that assembler-
based ARM backends don't emit strexb/ldrexb, I suspect that the backend based 
on the __atomic* intrinsics is used. If the compiler is not able to compile 
these intrinsics and yet reports them as lock-free then this is a compiler bug 
that should be reported to clang team.