llvm dev - May 2013 - [LLVMdev] Keeping Clang from changing function calls to IR operations: cmpxchg

I'm working on getting the LLVM/projects/Test-Suite/UnitTest to compile for
a target that I am developing.

There is an example: AtomicOps, that uses calls to:

__sync_fetch_and_add
__sync_val_compare_and_swap
__sync_lock_test_and_set

These get converted into llvm IR operations like:

atomicrmw
cmpxchg

Is there any way to keep these as function calls, as they are easier to map
to the target's eventual functional then having to deal with atomicrmw and
cmpxchg
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130514/b6871e5a/attachment.html>

I'm not sure if this will do everything that you want, but it controls at
least some of these expansions at the Clang level:
  tools/clang/lib/Basic/Targets.cpp



On Tue, May 14, 2013 at 3:46 PM, Dan <westdac at gmail.com> wrote:
>
> I'm working on getting the LLVM/projects/Test-Suite/UnitTest to compile
> for a target that I am developing.
>
> There is an example: AtomicOps, that uses calls to:
>
> __sync_fetch_and_add
> __sync_val_compare_and_swap
> __sync_lock_test_and_set
>
> These get converted into llvm IR operations like:
>
> atomicrmw
> cmpxchg
>
> Is there any way to keep these as function calls, as they are easier to
> map to the target's eventual functional then having to deal with
atomicrmw
> and cmpxchg
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130514/addc908e/attachment.html>

Hello

It looks like Ubuntu 13.04 has changed the include files directories 
structure
Now we get the following error in many of our programs
that compile fine on Ubuntu 12.04
> clang++ -c -x c++ -emit-llvm 
> ../../libsimsoc/processors/ppc/ppc_llvm_lib.cpp -DNDEBUG 
> -I/home/vania/systemc-2.3.0/include -I/home/vania/tlm2.0/include/tlm 
> -DSC_INCLUDE_DYNAMIC_PROCESSES -I/usr/local/llvm/3.2/include  -DNDEBUG 
> -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
> -D__STDC_LIMIT_MACROS -I../.. -I.. 
>
-DABS_TOP_SRCDIR="\"/home/vania/simsoc/trunk/build/..\""
> -DABS_TOP_BUILDDIR="\"/home/vania/simsoc/trunk/build\""
> -DBINDIR="\"/usr/local/bin\"" -I ../libsimsoc -DNDEBUG
-O3 -o
> ppc_llvm_lib.bc
> In file included from ../../libsimsoc/processors/ppc/ppc_llvm_lib.cpp:7:
> In file included from ../../libsimsoc/bitwise_operator.hpp:11:
> In file included from 
> /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/vector:60:
>
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/bits/stl_algobase.h:60:10:
> fatal error:
>       'bits/c++config.h' file not found
> #include <bits/c++config.h>
>          ^
> 1 error generated.
It happens systematically when including a header file from STL (in this 
case vector)
that includes <bits/c++config.h>
It may be a problem more related to Ubuntu 13, but it seems a general
change in Linux architecture dependent includes.
They have migrated architecture dependent files from

    /usr/include/c++/
to
   /usr/include/$ARCHITECTURE/c++

In my case ARCHITECTURE=x86_64-linux-gnu


Is this something we have to definitely deal with in our configure script
or we can expect a clang++ change ?

--VJ