similar to: C interface for COMDAT and new windows exception instructions?

r257499 On Sun, Jan 10, 2016 at 1:23 PM, Jakob Bornecrantz <wallbraker at gmail.com> wrote: > On Thu, Dec 24, 2015 at 1:28 AM, Jakob Bornecrantz <wallbraker at gmail.com> > wrote: > > On Wed, Dec 23, 2015 at 9:38 PM, Aaron Ballman <aaron at aaronballman.com> > wrote: > >> On Wed, Dec 23, 2015 at 3:28 PM, Reid Kleckner <rnk at google.com> wrote:

On Wed, Dec 23, 2015 at 9:38 PM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Wed, Dec 23, 2015 at 3:28 PM, Reid Kleckner <rnk at google.com> wrote: >> On Wed, Dec 23, 2015 at 11:25 AM, Aaron Ballman via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> >>> On Wed, Dec 23, 2015 at 1:55 PM, Jakob Bornecrantz <wallbraker at

On Wed, Dec 23, 2015 at 11:25 AM, Aaron Ballman via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Wed, Dec 23, 2015 at 1:55 PM, Jakob Bornecrantz <wallbraker at gmail.com> > wrote: > > On Wed, Dec 23, 2015 at 5:49 PM, Aaron Ballman <aaron at aaronballman.com> > wrote: > >> On Wed, Dec 23, 2015 at 11:29 AM, Jakob Bornecrantz via llvm-dev > >>

Thanks for starting! Btw here is my CMD version: cmd /Q /V:ON /c "for /F "tokens=4" %l in ('dir llvm*.lib') do (for /F "tokens=2" %e in ('dumpbin /linkermember:1 %l ^| findstr "_LLVM"') do (set symbolname=%e & echo !symbolname:~1!))" You run it in the directory with all the llvm*.lib (yes the ThinLTO is excluded in this example but can

We already half-have this, the LLVM_BUILD_LLVM_C_DYLIB cmake option builds a shared object which exports the llvm-c interface but it only works on Darwin. tools/llvm-shlib/CMakeLists.txt is where how this is done is defined, and it looks like it does it by: * build LLVM.so * use nm+awk+sed to pick out the symbols starting with LLVM * build LLVM-C.so using a -reexport_library linker option

I am sorry, just noticed i repeated myself :( 2017-07-10 15:20 GMT+02:00 Alexander Benikowski <sebal007 at googlemail.com>: > Thanks for starting! > Btw here is my CMD version: > > cmd /Q /V:ON /c "for /F "tokens=4" %l in ('dir llvm*.lib') do (for /F > "tokens=2" %e in ('dumpbin /linkermember:1 %l ^| findstr "_LLVM"') do

Hello list! So I'm wondering if there is a will to ship a DLL with the C API exported? LLVM currently ships with LTO.dll which has some C api functions exported, made from the export file tools/lto/lto.exports, so it would not be the first DLL LLVM shipped. Currently I (and the users of my project[1]) are building it ourselves using this script[2] derived from the LLVMSharp script[3]. Which

Made a bit of headway here: https://reviews.llvm.org/D35077 Cheers, Jakob. On Thu, Apr 6, 2017 at 2:34 PM, Alexander Benikowski <sebal007 at googlemail.com> wrote: > Maybe someone can use this as a startingpoint to add the windows-specific > commandblock which is triggered instead of the Darwin one together with a > proper setup of targets to have the libs build before. > >

The following is an older commandline i used. Have a more recent one at home. But basically you can write it as batch and trigger it within a target during the build(never got targets into correct order, i am a cmake noob) So for reference, i'll post this one and look for the recent one at home(if that didn't go down with my recent hdd crash): cmd /Q /V:ON /c "for /F

On Wed, Dec 23, 2015 at 5:49 PM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Wed, Dec 23, 2015 at 11:29 AM, Jakob Bornecrantz via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> I'm building on Windows x64 using cmake, Ninja and VS 2013 express on Windows 7. >> >> So I have been using the LLVMSharp method on getting a usable loadable >>

I was looking to write a cross platform utility that worked with ELF/DWARF files. I need the utility to run on OS X, Linux and Windows. I figured I could use clang/llvm to build this tool. I've made good progress on OS X. Before I got too far, though. I decided to verify that I can build the code on Windows. I downloaded the 3.8.0 Windows installer from the llvm downwloads page, ran the

I've been digging into COMDAT with regular LTO, specifically in the context of the LLVM gold plugin. The GCC WHOPR documentation specifies that the linker will resolve all COMDAT groups to the IR-provided definitions, if available. Additionally it specifies that "When the WPA phase produces the definition of the COMDAT symbol in a new object file, that definition should not be in a COMDAT

I'm building on Windows x64 using cmake, Ninja and VS 2013 express on Windows 7. So I have been using the LLVMSharp method on getting a usable loadable LLVM.dll[1][2]. This have worked out of the box before so it is a regression, I tracked it down to commit r250501. That commit breaks this commit, other users have also run into this specific problem[3][4]. I tried looking into the

On Wed, 4 Nov 2009 17:42:26 +0000 Jakob Bornecrantz <jakob at vmware.com> wrote: > Hi Jerome > > On 4 nov 2009, at 15.58, Jerome Glisse wrote: > > > > Note: For reference my issue is with cursor on old radeon hw, > > cursor must be in the next 128M from the crtc scanout buffer. We > > got issue when someone start to resize their screen at which > >

Given the following C++ code: ``` // test.cpp struct Foo { int public_foo(); int outside_foo(); [[gnu::always_inline]] int inline_foo() { int x = outside_foo(); if (x % 17) { x += 1; } return x; } [[gnu::noinline]] int inline_bar1() { int x = inline_foo(); if (x % 23) { x += 2; } return x; } [[gnu::noinline]] int inline_bar2() {

On Nov 9, 2011, at 11:34 AM, Rafael Espíndola wrote: >>> 1) [Requires ABI change] We emit dynamic initialization code for weak globals >>> (even in TUs where static initialization is required to be performed), unless >>> we can prove that every translation unit will use static initialization. We >>> emit the global plus its guard variable as a single object so

On Nov 7, 2011, at 9:47 AM, Richard Smith wrote: >> In cases where the C++ standard requires static initialization, >> introducing a write violates the guarantees of the C++ standard for static >> initialization. Therefore, I'm not sure the whole "make the constant >> writable" approach is actually viable. > > There is another problem which afflicts

>> 1) [Requires ABI change] We emit dynamic initialization code for weak globals >> (even in TUs where static initialization is required to be performed), unless >> we can prove that every translation unit will use static initialization. We >> emit the global plus its guard variable as a single object so the linker can't >> separate them (this is the ABI change).

Hi All, This week I've been focused on removing some of the blockers for people transitioning from ORCv1 to ORCv2. Issue #1 (http://llvm.org/PR40074, http://llvm.org/PR44337): When LLVM codegens floating point constants for COFF we produce named constant pool entries of the form __real@<bitval>. These are stored in COFF COMDAT sections [1] which allow duplicate symbol definitions to

> Unfortunately, making the comdat be for the entire function is not > conformant with the ABI, which says that you either put the variable > and its guard in different comdats or you put them in a single comdat > named for the variable.  It also doesn't actually help unless we disable > inlining. I see. Using two comdats would still cause the same problem for us, no? So the