similar to: [LLVMdev] [compiler-rt] CMake bug in building ARM builtins library

On Tue, Jul 8, 2014 at 2:44 PM, sgundapa <sgundapa at codeaurora.org> wrote: > No. CMake has different way of treating the .S files > Refer to http://www.cmake.org/Wiki/CMake/Assembler > > I have a patch which will make CMake treat the .S files as source files. > Let me guess, you should just call set_source_file_properties(<arm .S files> PROPERTIES LANGUAGE C)? >

On 8 July 2014 19:47, Alexey Samsonov <vonosmas at gmail.com> wrote: > compiler-rt/lib/builtins/arm/*.S files are listed in arm_SOURCES variable, > and therefore should make it into the builtins static library on ARM. Don't > they? I assume so... But I'm not an expert in CMake.

Is there any specific reason why the clang_rt.builtins-${arch} library is disabled for windows builds? if (NOT WIN32) foreach(arch x86_64 i386 arm) if(CAN_TARGET_${arch}) set_source_files_properties(${${arch}_SOURCES} PROPERTIES LANGUAGE C) add_compiler_rt_runtime(clang_rt.builtins-${arch} ${arch} STATIC SOURCES ${${arch}_SOURCES} CFLAGS

I believe the C source files in builtins directory are generic enough. Why not build a clang_rt.builtins-aarch64 library? --Sumanth G -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140708/969ee15b/attachment.html>

Sure, we can build libclang_rt.builtins-aarch64.a, if there are users for it and, ideally, someone able to setup a buildbot and keep it in a working state. On Tue, Jul 8, 2014 at 11:32 AM, sgundapa <sgundapa at codeaurora.org> wrote: > I believe the C source files in builtins directory are generic enough. > > Why not build a clang_rt.builtins-aarch64 library? > > > >

On 7/16/14, 6:09 PM, sgundapa wrote: > I see a couple of issues here. > > If I include .S files for ARM, the –no-integrated-as path complains about > Assembler errors. > > The integrated-as path works fine though. > These are very likely just differences between the old ARM assembler syntax and the new 'Unified' syntax. Can you use an assembler that accepts UAL

Is UBSAN on android for ARM target known to work? I know ASAN does work. --Sumanth G -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140723/9ea92700/attachment.html>

The following bot is broken: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/4016 because of the following change (SVN r213684): http://reviews.llvm.org/D4614 But it seems to build fine on my machine... I don't know enough about CMake to tell, but that seemed to be a bug/feature in CMake to which needed the work-around. Now, just looks like the work-around is

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

On 20 December 2013 10:43, Alexey Samsonov <samsonov at google.com> wrote: > There are simply no CMake build rules for building compiler-rt > libraries targeting ARM (see compiler-rt/lib/CMakeLists.txt). > Hi Alexey, I've added the ARM files on that CMake file but I got nothing compiled on ARM. Am I missing something? About the sanitizers, is there anyone that is known to

Here is a problem scenario. I want to enable a backend pass at -O2 or above. if (TM->getOptLevel() >= CodeGenOpt::Default) addPass(&xxxxx); This pass will be run at -O1 too since clang is creating the TargetMachine with CodeGenOpt::Default for -O1. --Sumanth G -----Original Message----- From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Friday, January 6, 2017

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, AFAIK, the tools "symbolizer, objdump and nm" need a demangler. I see there is libcxxabi which provides the demangle library. But there is no support to build libcxxabi on windows with MSVC. This left a huge void and my symbolizer cannot work on Windows if built with MSVC. Instead of mucking around OS dependencies, why shouldn't we have a demangle library in LLVM.

I reacted as per my case. You need CFLAGS in order to what linker you might be using. In case of clang, you can use “-fuse-ld” to control the invocation of linker. In my opinion, it is not necessary to carry forward LDFLAGS unless you want to control specific parts of the linker. In my case, I have a cross compiler for ARM and I usually compile the code with Clang

getOptLevel() gets the level from TargetMachine which is created by the Backendutil in clang with either "Default", "None" or "Aggressive". Threre is no correspondence for "Less". This boils down to , if I pass "-O1", the Target Machine is created with CodeGenOpt::Default. I am available on IRC @ sgundapa. -----Original Message----- From:

Hi, I am observing a deadlock with llvm-lit on windows 7. When I attached a debugger, the communicate() call is blocked. In file utils/lit/lit/TestRunner.py > # FIXME: There is probably still deadlock potential here. Yawn. > procData = [None] * len(procs) > procData[-1] = procs[-1].communicate() I am invoking python directly on windows to run the unit tests.

Hi Rafael, I looked at the code which you pushed a while ago to check for the gold linker. Code below: execute_process( COMMAND ${CMAKE_C_COMPILER} -Wl,--version OUTPUT_VARIABLE stdout ERROR_QUIET) if("${stdout}" MATCHES "GNU gold") set(LLVM_LINKER_IS_GOLD ON) endif() I was trying to build runtime libraries (compiler-rt)

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Mehdi > Amini via llvm-dev > Sent: Friday, January 06, 2017 11:10 AM > To: Sumanth Gundapaneni > Cc: LLVM Developers > Subject: Re: [llvm-dev] LLVMTargetMachine with optimization level passed > from clang. > > > > On Jan 6, 2017, at 10:56 AM, Sumanth

Hi, I see there is an inconsistency in LLVM libc calls. For a modulo (reminder) operation, clang -target arm-none-linux-gnueabi generates "__modsi3". clang -target arm-none-eabi generates "__aeabi_idivmod" clang -target arm-linux-androideabi generates "__modsi3" Android bionic libc doesn't provide a __modsi3, instead it provides

Hi @ll, LLVM-7.0.0-win32.exe contains and installs lib\clang\7.0.0\lib\windows\clang_rt.builtins-i386.lib The implementation of (at least) the multiplication and division routines __[u]{div,mod,divmod,mul}[sdt]i[34] shipped with this libraries SUCKS: they are factors SLOWER than even Microsoft's NOTORIOUS POOR implementation of 64-bit division shipped with MSVC and Windows! The reasons: 1.