similar to: How can I fix/exclude some failing tests when building with BUILD_SHARED_LIBS=ON

Hi, For lllvm 3.7 and before BUILD_SHARED_LIBS=ON would produce versioned shared libs like libLLVMLTO.so (symlink) libLLVMLTO.so.3.7 (symlink) libLLVMLTO.so.3.7.0 (real file) now it just builds an unversioned libLLVMLTO.so file which I believe is a problem because when a program links to llvm it generates a runtime dependency on libLLVMLTO.so instead of libLLVMLTO.so.3.7.0 which will break

Hi, On Tue, Jan 19, 2016 at 7:18 PM, Chris Bieneman <beanz at apple.com> wrote: > The LLVM libraries are not API stable (especially not the ones you generate with BUILD_SHARED_LIBS). Those libraries are really not intended to ship. I know that's why I need them versioned. Currently we (openSUSE) ship libLLVM package which will install libLLVMFooBar.so.3.7 files and llvm-devel

On Wed, Jan 27, 2016 at 3:18 AM, Ismail Donmez via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, > > On Tue, Jan 26, 2016 at 6:57 PM, ChrisBieneman <beanz at apple.com> wrote: >> Yes, I'm aware of the change that caused this. It was when I stopped setting SOVERSION as a target property on all shared libraries. That change was deliberate in order to match

Hi, On Tue, Jan 19, 2016 at 8:09 PM, Chris Bieneman <beanz at apple.com> wrote: > I think the right solution here is to fix LLVM_BUILD_LLVM_DYLIB and LLVM_LINK_LLVM_DYLIB (which should work) rather than fixing BUILD_SHARED_LIBS which was never intended to work for this use case. > > Either way, patches welcome. This seems to be due to your commit http://reviews.llvm.org/D13841 ,

Hi Yin, I second David's words. I use shared libs myself on debug builds, but static builds with gold on a local disk is pretty feasible. Before I used gold, I had to have 16GB of RAM on my laptop, now I need less than 8GB for static builds. On 28 January 2016 at 23:58, Yin Ma via cfe-dev <cfe-dev at lists.llvm.org> wrote: > It is O.K. I just hope BUILD_SHARED_LIBS=ON is tested

Hi David, I assume you have a powerful machine. Our drive space is on network mounted machined by IT department. The machine is default Ubuntu setup with 8 cores. Shared build is showing huge advantage due to size reduction. I will try those two debug options to see how it works. Thanks, Yin From: David Blaikie [mailto:dblaikie at gmail.com] Sent: Thursday, January 28, 2016

Hi, On Tue, Jan 26, 2016 at 6:57 PM, ChrisBieneman <beanz at apple.com> wrote: > Yes, I'm aware of the change that caused this. It was when I stopped setting SOVERSION as a target property on all shared libraries. That change was deliberate in order to match functionality between CMake and the autoconf build. > > In the autoconf build we didn't actually set the SOVERSION on

Hello, I understand shared linked is currently a lot slower than static linked. However, for debug build, where speed is not required. Shared link has A lot of advantage. Static linked clang/llvm on linux is 17G, shared build is only 1.5G. On a mainstream linux host machine with 12G memory, only -j1 can be used to finish final linking step. With -j8 the linux will link the

On Thu, Jan 28, 2016 at 3:06 PM, Jonathan Roelofs <jonathan at codesourcery.com > wrote: > > > On 1/28/16 4:00 PM, Yin Ma via cfe-dev wrote: > >> Hi David, >> >> I assume you have a powerful machine. Our drive space is on network >> mounted >> >> machined by IT department. The machine is default Ubuntu setup with 8 >> cores. >>

On Thu, Apr 4, 2019 at 7:10 PM Craig Topper <craig.topper at gmail.com> wrote: > Agreed that the new isa_or_null style is better. Just wanted mention the > other style so we know we should migrate those to the new one. > I have a checker under review that could be enhanced to do that -- though it currently replaces `X->foo() && isa<Y>(X->foo())` with

Hi Don, On 25 September 2017 at 22:37, Don Hinton <hintonda at gmail.com> wrote: > It'll work in release builds -- just rebuild llvm with LLVM_ENABLE_DUMP > enabled. > That assumes one has control over the LLVM build options. > On Mon, Sep 25, 2017 at 2:35 PM, Dibyendu Majumdar <mobile at majumdar.org.uk> > wrote: >> >> On 25 September 2017 at 22:29,

Dear all, while trying to build llvm with shared libraries using GCC (tested both in Ubuntu 14.04 and Ubuntu 16.04) as in cmake -G Ninja -DBUILD_SHARED_LIBS=ON I run into the following link error lib/Transforms/IPO/CMakeFiles/LLVMipo.dir/PartialInlining.cpp.o: In function `llvm::ForwardDominanceFrontierBase<llvm::BasicBlock>::ForwardDominanceFrontierBase()':

On 13 October 2015 at 22:28, don hinton <hintonda at gmail.com> wrote: > However, the build that failed thought it needed to do 106 steps. It hung > on the 83 that didn't exist. Interesting... > Could this be a cmake/ninja issue? It could. Those bots are not cleaning between builds (or it would take hours). If that's what's happening, I'll have to re-think my

Is there a way to do this with llvm-lit, i.e., use the equivalent of backticks? foo takes a single argument, but doesn't read from stdin. // RUN foo some_arg > %t; FileCheck %s < %t // RUN foo `cat %t` | FileCheck --check-prefix=INVERSE // CHECK: {{^[0-9]+$}} // INVERSE: some_arg thanks... don -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Thu, Apr 4, 2019 at 6:29 PM Craig Topper <craig.topper at gmail.com> wrote: > There are a handful of places in LLVM that dosomething like if > (dyn_cast_or_null<UndefValue>(P->hasConstantValue())) > Yes, I've seen those, but while working on a new checker, I was advised that replacing `X && isa<Y>(X)` with `dyn_cast_or_null<Y>(X)` was

Hi, I'm getting: Unhandled exception at 0x00C211F0 in ConsoleApplication830.exe: 0xC00001A5: An invalid exception handler routine has been detected (parameters: 0x00000001). With some fairly simple SEH enabled routine: define i32 @__elements_entry_point_main(%._gt2a_RemObjects_d_Elements_d_System_d_Array_t_1s*) #0 personality i8* bitcast (i32 ()* @_elements_exception_handler to i8*) !dbg

Or, instead of lobbying for llvm to always define dump(), you could lobby for it to enabled by default. On Mon, Sep 25, 2017 at 2:41 PM, Dibyendu Majumdar <mobile at majumdar.org.uk> wrote: > Hi Don, > > On 25 September 2017 at 22:37, Don Hinton <hintonda at gmail.com> wrote: > > It'll work in release builds -- just rebuild llvm with LLVM_ENABLE_DUMP > >

Hi Don, On 25 September 2017 at 22:29, Don Hinton <hintonda at gmail.com> wrote: > Thanks for reporting this. > > Looks like this one was missed -- the declaration should have been #ifdef'd > away along with the definition. A quick grep indicates there are a number > of them that need to be fixed. > > Here's the original commit: > > commit

Just posted this fix on ninja's github page, but figured I'd share it with a larger audience. Every time I run cmake && ninja in a new build directory, ninja will rerun cmake because the entry for build.ninja in .ninja_log is older than the timestamp on CMakeCache.txt, even if the timestamps on the actual file isn't older. The following patch fixes the problem, i.e.,

It'll work in release builds -- just rebuild llvm with LLVM_ENABLE_DUMP enabled. On Mon, Sep 25, 2017 at 2:35 PM, Dibyendu Majumdar <mobile at majumdar.org.uk> wrote: > Hi Don, > > On 25 September 2017 at 22:29, Don Hinton <hintonda at gmail.com> wrote: > > Thanks for reporting this. > > > > Looks like this one was missed -- the declaration should have