similar to: Question about compiler-rt builtins targets

On 4/15/16, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Fri, Apr 15, 2016 at 02:31:59PM +0200, ardi via llvm-dev wrote: >> On Fri, Apr 15, 2016 at 1:02 PM, Joerg Sonnenberger via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > On Fri, Apr 15, 2016 at 10:45:03AM +0200, ardi via llvm-dev wrote: >> >> What I found is

On Fri, Apr 15, 2016 at 1:02 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Fri, Apr 15, 2016 at 10:45:03AM +0200, ardi via llvm-dev wrote: >> What I found is that the build system is really complex, performs many >> checks, and quite often takes wrong decisions (example: a fatal error >> if the OS X version is older than 10.7, instead of

Hi, I don't know if there's a wishlist for future LLVM releases but, in case there is one, maybe you'd like to consider my experience (as a multiplatform application developer who discovered clang just because Apple started to include it in Xcode since 10.8 Mountain Lion IIRC, and really liked it, specially for how warnings are issued, which really helps to improve your app code

> On Nov 2, 2015, at 11:41 AM, Vasileios Kalintiris <Vasileios.Kalintiris at imgtec.com> wrote: > >> The problem comes when bootstrapping a cross-compiler toolchain. In order to >> have a cross-compiling toolchain that can build a “hello world” application you >> need four basic components: >> >> (1) clang >> (2) ld >> (3) libclang_rt

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

In the effort to flesh out the CMake build system a problematic issue has come up, and I’d like some feedback on how to best handle it. For reference this issue has been reported by a few users, one proposed patches that don’t really address the underlying problem here: http://reviews.llvm.org/D13131 The problem comes when bootstrapping a cross-compiler toolchain. In order to have a

> > I will not be stripping out any of the existing CMake. If we go down this > path what I’m going to do is refactor the CMake to produce to logically > separated projects so that the builtins can be built with or without the > runtime libraries. It will all still be CMake-based. Sorry. s/stripping/seperating/g I was still thinking about the stripping of the IOS build from the OSX

> On Nov 2, 2015, at 12:01 PM, Steve King <steve at metrokings.com> wrote: > > Hi Chris - Many thanks for airing all this. I'm now hopeful for an > end to my own hacks and false starts trying to fix these same > problems. My response is coming from the perspective of an > out-of-tree target without binutils or libgcc support. > > On Mon, Nov 2, 2015 at 9:10

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.

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

Hi, compiler-rt builtins currently doesn't build on MSVC 2019, I the problem is that compiler-rt\lib\builtins\int_math.h includes the header ymath.h. according to eg. https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/finite-finitef?view=vs-2019 the header to include is float.h also the ymath.h file contains the comment /* ymath.h internal header */ so probably shall not be

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 @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

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

Hello all, I’m unsure of how the tests located in compiler-rt/test/builtins/Unit are run. They’re not attached to the cmake check-all target, as mentioned in compiler-rt/test/CMakeLists.txt:10, and they have no lit test suite associated with them. There is a shell script called “test” in test/builtins/Unit, but it hasn’t been touched since 2010, and make reference to no longer existing

I am attempting to port an operating system project to use Clang/LLVM instead of GCC, but I'm having issues with Compiler-RT. Right now, the OS is being cross-compiled on an x86_64 host targeting ARMv7a. I built the LLVM toolchain according to the instructions, though I limited the supported targets to arm, x86, and x86_64 to reduce compilation time. I'm finding that compilation proceeds

"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

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

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.

Hi, There are several places in compiler-rt which refer to __aeabi_idiv0. For example, in lib/builtins/arm/udivsi3.S: #ifdef __ARM_EABI__ b __aeabi_idiv0 #else JMP(lr) #endif At the same time there is no definition of it. It looks as if it was done intentionally so that third-party could provide custom handler for division by zero. IMHO It's not very consistent and looks odd as