similar to: Question about xen and the RT patch

On 10 December 2014 at 16:06, Renato Golin <renato.golin at linaro.org> wrote: > Hi Sumanth, > > Christophe (cc'd) is seeing the same problems on his build. It seems > that r181130 (by Tim) has something to do with it, but I'm not sure. > > I remember trying to build compiler-rt on AArch64 natively in > February, and even running the test-suite with it, so

On 16 December 2014 at 21:12, Gundapaneni, Sumanth <sgundapa at quicinc.com> wrote: > The point here is, if you are not building for Android. > You will hit this patch with cmake configuration -DCOMPILER_RT_TEST_TRIPLE=aarch64-linux-gnu > > + elseif("${COMPILER_RT_TEST_TARGET_ARCH}" MATCHES "aarch64") > + test_target_arch(aarch64

The point here is, if you are not building for Android. You will hit this patch with cmake configuration -DCOMPILER_RT_TEST_TRIPLE=aarch64-linux-gnu + elseif("${COMPILER_RT_TEST_TARGET_ARCH}" MATCHES "aarch64") + test_target_arch(aarch64 "-march=aarch64") I don't see "-march=aarch64" is a valid flag on either LLVM or GCC. Should we replace this

Hi, Right. I'm aware of that. But to Clang, "armv8-a" as an architecture is ARMv8/AArch32. Unless Clang has recently got a lot cleverer than it has been in the past. James On Thu Dec 18 2014 at 9:06:04 AM Christophe Lyon <christophe.lyon at linaro.org> wrote: > On 18 December 2014 at 09:07, James Molloy <james at jamesmolloy.co.uk> > wrote: > > Hi Renato,

Hi Renato, Are you sure? Armv8-a is aarch32, not aarch64. Something smells fishy there. Cheers, James On Thu, 18 Dec 2014 at 08:03, Renato Golin <renato.golin at linaro.org> wrote: > On 16 December 2014 at 20:29, Christophe Lyon > <christophe.lyon at linaro.org> wrote: > >> I don't see "-march=aarch64" is a valid flag on either LLVM or GCC. >

Hi, I wonder if this is a valid flag in either clang/gcc. The flag in question is "-march=aarch64". I verified with latest tip and neither clang nor gcc fail to recognize this flag. This piece of code is in cmake/config-ix.cmake in compiler-rt repo. + elseif("${COMPILER_RT_TEST_TARGET_ARCH}" MATCHES "aarch64") + test_target_arch(aarch64

I'm running into a compile problem with commit 131656 of compiler-rt. I'm compiling llvm with: $ CXX='g++ -m32' CC='gcc -m32' CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32 ./configure --disable-bindings --{build,host,target}=i686-apple-darwin --enable-targets=x86,x86_64,cbe --enable-optimized $ make $ make install It will eventually error out with:

Hi, Short version: Is it possible to enable *all* builtins architectures? How? Longer explanation: I don't quite understand how compiler-rt targets are decided to be built while invoking cmake from the LLVM tree. I tend to believe that builtins and sanitizers (the two big parts in compiler-rt) are quite different monsters, but however they share the same build decisions and (if I'm not

On Thu, Jan 23, 2014 at 2:40 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote: > On 17/01/14 02:23, Ilia Mirkin wrote: >> This is needed since commit 9baa45f78b (st/mesa: bind NULL colorbuffers >> as specified by glDrawBuffers). >> >> This implementation is highly based on a larger commit by >> Christoph Bumiller <e0425955 at student.tuwien.ac.at>

Hello there! I made Debian, Xen 2.0 and CLUSTER/GFS work together :). I wrote this little tutorial to help you setup yours. Any feedback is welcome, except comments about W3C validation of my code :p Note that I am talking about compiling CLUSTER with your XEN kernel, I don''t explain how to setup a working cluster. You can find how to setup those in official RedHat docs. You will see,

Lei, The issues that you’re reporting here are on my mind. I have a patch out for review now (http://reviews.llvm.org/D19742 <http://reviews.llvm.org/D19742>) that allows building builtins without a full toolchain. One of the next steps after this is to support alternate sysroots for different targets, and to identify builtins that need target headers so that they can be excluded in cases

Hi @ll, compiler-rt implements (for example) the MSVC (really Windows) specific routines compiler-rt/lib/builtins/i386/chkstk.S and compiler-rt/lib/builtins/x86_64/chkstk.S as __chkstk_ms() See <http://msdn.microsoft.com/en-us/library/ms648426.aspx> Is there any special reason why compiler-rt doesn't implement other MSVC specific functions (alias builtins or "compiler

"Friedman, Eli" <efriedma at codeaurora.org> wrote: > On 11/30/2018 8:31 AM, Stefan Kanthak via llvm-dev wrote: >> Hi @ll, >> >> compiler-rt implements (for example) the MSVC (really Windows) >> specific routines compiler-rt/lib/builtins/i386/chkstk.S and >> compiler-rt/lib/builtins/x86_64/chkstk.S as __chkstk_ms() >> See

Hi, I'm building compiler-rt in a ppc64le machine and it is generating the sanitizers fine but it is not generating the builtin library. I tried to compile it in a x86_64 machine and I got the builtin library generated (libclang_rt.builtins-x86_64.a). Taking a look in a cmake config file from compiler-rt, I saw that ppc64 is not in the supported architecture list to generate the builtin

I’m trying to figure out how to build compiler-rt 3.5.0 with Visual Studio 2013. In an autotools build or cmake on Linux, I believe putting the compiler-rt sources under llvm/projects is enough to build them automatically. Do I need to do anything specific to get the same with MSVC? I've tried setting -DLLVM_BUILD_EXTERNAL_COMPILER_RT either ON or OFF, but can't find any evidence of

I'm using Clang, with arm-none-linux-gnueabi-g++ as a linker. Although compiler-rt replaced libgcc, we still need other libs such as libc, libm, etc. It seems libc is calling these missing functions. > > On Nov 15, 2012, at 9:33 PM, liangh at codeaurora.org wrote: >> I'm trying to link my objs with compiler-rt built runtime lib for arm. >> According to the compiler-rt

On Nov 15, 2012, at 9:33 PM, liangh at codeaurora.org wrote: > I'm trying to link my objs with compiler-rt built runtime lib for arm. > According to the compiler-rt doc, it should be able to replace libgcc. > However, if I replace "-lgcc" with "compiler-rt.a" for a static linking, > gcc linker complains about undefined functions. Using "nm -g", I

Hi, It seems that r327904 / 5c4cd77db3a08587c6ac82a8e2c92cd4be0bc200 broke master on FreeBSD: A direct revert fixes the issue. I'd also be happy with an ifdef though it seems unnecessary. $uname -rms FreeBSD 12.0-CURRENT amd64 $ninja ... /srv/src/llvm/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:504:25: error: no member named 'environ' in the global namespace;

Hi guys, Thanks for all the info. Then, if, besides compiler-rt, I also need some other libs, such as libm, how do I link? Here is an example of missing functions in compiler-rt when linking: "-lstdc++ -lm --start-group -lcompiler-rt-armv7 -lgcc_eh -lc --end-group" vs. "-lstdc++ -lm --start-group -lgcc -lgcc_eh -lc --end-group" ...

Hi Dean, I have fixed the build failure in r329832. In general, do you think it would be possible to perform the task using higher-level functions available from AddCompilerRT.cmake? They were written exactly to avoid such errors. Regards, George > On Apr 11, 2018, at 10:50 AM, George Karpenkov <ekarpenkov at apple.com> wrote: > > Hi Dean, > > For me the build is still