similar to: [LLVMdev] LLVMgold.so in windows LLVM builds

I tried building it on windows with some CMake changes. But unfortunatelym my clang crashes when it tries to access the LLVMgold (not able to open it). I have CCed Rafeal and Nakamura who might know why gold plugin in not supported on Windows platforms. --Sumanth G > Hi, > > On 14 June 2014 00:26, <sgundapa at codeaurora.org> wrote: >> I am trying to build LLVMgold.so on

On Wed, May 20, 2020 at 5:06 PM Tom Stellard <tstellar at redhat.com> wrote: > > On 05/19/2020 09:05 PM, Sedat Dilek wrote: > > Hi Tom, > > > > thanks and congrats for LLVM 10.0.1-rc1 release. > > > > [1] shows 2 assets. > > 10.0.0 RCs had a lot of more assets. > > I am missing the llvm-project-10.0.1rc1.tar.xz tarball. > > > > Will

On Wed, May 20, 2020 at 11:12 PM Tom Stellard <tstellar at redhat.com> wrote: > > On 05/20/2020 09:53 AM, Sedat Dilek wrote: > > On Wed, May 20, 2020 at 5:06 PM Tom Stellard <tstellar at redhat.com> wrote: > >> > >> On 05/19/2020 09:05 PM, Sedat Dilek wrote: > >>> Hi Tom, > >>> > >>> thanks and congrats for LLVM

> On Jul 23, 2016, at 1:53 PM, Sedat Dilek via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On Sat, Jul 23, 2016 at 7:48 PM, Piotr Padlewski <prazek at google.com <mailto:prazek at google.com>> wrote: >> How big is your project? >> LTO eats RAM even faster than chrome. For example linking clang with LTO >>

Hi, I have having hard time to let cmake configuration detect the zlib header in windows with "Visual Studio 12" generator. My cmake configuration goes like >> Set path, include and lib environment variables to point to zlib headers and libraries. Cmake version is 2.8.12.2 cmake -G "Visual Studio 12" -D LLVM_TARGETS_TO_BUILD:STRING=%TARG% -D

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)? >

I noticed the compiler-rt/lib/builtins/CmakeLists.txt is not including the .S files in building clang_rt.builtins-arm.a We need to tell the CMake build system that the .S files are also the source files. Is there any intention behind leaving the .S files not to compile? If not, let me know and I will push a patch. --Sumanth G -------------- next part -------------- An HTML attachment

Hi Tom, thanks and congrats for LLVM 10.0.1-rc1 release. [1] shows 2 assets. 10.0.0 RCs had a lot of more assets. I am missing the llvm-project-10.0.1rc1.tar.xz tarball. Will you provide them later or is there a new development/workflow decision I do not know of? BTW, the source zip and tar.gz tarballs show no sizes. I am using Mobile LTE/UMTS to download stuff from the Internet. For now I

The path to libLTO.so in LLVMgold.so points to the build directory on my machine: % ldd /usr/local/lib/LLVMgold.so linux-vdso.so.1 (0x00007fff3d795000) /var/tmp/build_llvm_clang/Release+Asserts/lib/libLTO.so => not found libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1703983000) ... I have configured clang with: ../llvm/configure --enable-optimized

> Why is clang loading LLVMgold.dll? I thought it's supposed to be loaded by gold. > > I don't think gold even produces COFF. Are you trying to produce ELF on Windows? > Gold is elf only but BFD ld supports the same plugins these days. I have no idea if the plugin infrastructure works on windows or not, but it could be made to work since all it needs is to find a single

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

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

Hi, unfortunately, my build somehow hangs when linking clang binary and my system is in an unusable state. My toolchain is clang-3.8, gold-1.11 and LLVMgold.so from binutils v2.26.1 (both selfmade) and LTO-flag is enabled. My buildsystem uses cmake-3.6.0 and ninja-1.7.1 (both prebuilt). I have 52 last steps left in my 3rd build. My Linux-kernel is v3.13.0-92 from official Ubuntu repositories.

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>

Hi all, I am trying to figure out the best way to deal with non-default TargetMachine options when using ThinLTO with the LLVMgold.so plugin. (I'm adding support for ThinLTO to the LDC D compiler) Things like the target triple, target CPU and target CPU features, some floating point options like unsafe-fp-math, etc., those are (or can be made) explicit in the IR. Is that the way to go? We

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.

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

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: