similar to: [LLVMdev] Missing symbols when loading opt plugins

I needed the following patch to be able to use gprof with profiled build. regards, Benoit --- a/Makefile.rules (revision 37946) +++ b/Makefile.rules (working copy) @@ -212,6 +212,7 @@ CXX.Flags := $(OPTIMIZE_OPTION) -pg -g C.Flags := $(OPTIMIZE_OPTION) -pg -g LD.Flags := $(OPTIMIZE_OPTION) -pg -g + KEEP_SYMBOLS := 1 else ifeq ($(ENABLE_OPTIMIZED),1) BuildMode := Release

Thanks for the warning! I checked and the executables take up about 2/3 of the space (380MB) vs. about 180MB for the libs. Since we are usually only debugging one executable at a time (if any), I modified Makefile.common to strip each executable in tools/Debug by default. You can define KEEP_SYMBOLS in the Makefile of any particular tool in order to avoid stripping that executable. I have

Great! Can you please check in that test case or better still, a reduced version of that test. Thanks -Anshu --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation On 12/11/2012 5:47 AM, Carlos Sánchez de La Lama wrote: > Hi again, > > I can confirm r169783 fixes the problem. My testbench segfaulted in > r169782 but works after your

Hi Anshu, the "test case" I referred to requires the compilation of our whole back-end. It segdaults when using gcc-4.4.3 under Ubuntu 10.04, with other combinations I have tested it still happens (before your patch) but is not noticeable unless using gdb. I have tried making valgrind catch it but no success... so I guess the only way to *see* it is using the debugger. I remember

Hi again, I can confirm r169783 fixes the problem. My testbench segfaulted in r169782 but works after your commit. We can close the issue. Thanks, Carlos 2012/12/11 Carlos Sánchez de La Lama <csanchezdll at gmail.com> > Hi Anshu, > > I got a testbench which fails (and segfaults) consistently with an > environment (gcc + os) conveniently preserved in a virtual machine. I

Hi Anshu, I got a testbench which fails (and segfaults) consistently with an environment (gcc + os) conveniently preserved in a virtual machine. I will confirm that it is gone there and report. Thanks for the fix :) Carlos 2012/12/10 Anshuman Dasgupta <adasgupt at codeaurora.org> > Carlos, > > I committed a fix in r169783. Thanks for catching this. > > However, I could

Hi!! It's me again. I guess that there is a problem in the Makefile of my source code. But I don't know where. Could you please verify it? The Makefile is written like this: # Makefile for Genetic Algorithm Pass CXXFLAGS = -Wall -I/iss/fpga3/nicole/galib247/ LDFLAGS= -L/iss/fpga3/nicole/galib247/ga/ -lga -Wl,-E # Path to top level of LLVM heirarchy LEVEL=../../../ # Name of the

Carlos, AMD's OpenCL implementation(both CPU and GPU) has worked for years with the way SPIR represents locals. If there is problems with the representation then it is an implementation issue. One of the issues with using extra kernel arguments is that it requires extra validation and complexity at the runtime level that is not needed if it is handled internally by the compiler. That being

Check out the bug report at http://llvm.org/bugs/show_bug.cgi?id=13144 and try adding KEEP_SYMBOLS := 1 to tools/opt/Makefile like the OP suggests. Good luck. ----- Original Message ----- From: Raphael Ernani Rodrigues Sent: 02/28/13 05:59 PM To: LLVM Developers Mailing List Subject: Problem linking class to a pass in a loadable module Dear LLVMers, I have a class X that represents a set of

As directed from http://vmkit.llvm.org/get_started.html, I'm getting: checking for ld used by GCC... /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld checking if the linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no checking for shared library run path origin... /bin/sh: ./config.rpath: No such file or directory done checking for iconv... yes

Micah, You're saying it works for you, but Clang doesn't currently anywhere near the range of horrible constantexpr constructs it is possible to create. You can "get by" at the moment with just handling ConstantGEPs, because of the way Clang works. But SPIR isn't restricted to Clang, and the problem is that it is *possible* (although not probable, or nice, but that is

John, The version from the Xcode 4.2 GM package (Apple clang version 3.0 (tags/Apple/clang-211.10.1)) still has the same problem. Which version should I use? Thanks, Akos From: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at graphisoft.com>> Date: Mon, 3 Oct 2011 17:47:06 +0000 To: John McCall <rjmccall at apple.com<mailto:rjmccall at apple.com>> Cc:

On Tue, Nov 22, 2011 at 11:32 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > As directed from http://vmkit.llvm.org/get_started.html, I'm getting: > > checking for ld used by GCC... /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld > checking if the linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no > checking for shared

Thanks for the response. Since X11 is by default installed on OS X when the developer tools are installed. Running autoconf fixed the issue with configure not finding X11, although I did not check why the configure script did not have the correct path (I'm assuming this was the case). Next I'm on to the gtk+ dependencies which I'm going to try to solve with macports if I have to. I

Thanks, Bob! I guess we should be expecting a 4.2.1 update after clang 3.0 has been released, shouldn't we? Best, Akos From: Bob Wilson <bob.wilson at apple.com<mailto:bob.wilson at apple.com>> Date: Thu, 20 Oct 2011 08:46:38 -0700 To: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at graphisoft.com>> Cc: "llvmdev at cs.uiuc.edu<mailto:llvmdev

Here's a code generated with -Os on darwin/x86_64 with clang from the Xcode 4.2 GM toolset on Mac OSX 10.7.2 (Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn), Target: x86_64-apple-darwin11.2.0) 0x000000010277d281 <+2102> lea 0x1d43bd0(%rip),%rax # 0x1044c0e58 <gFloorPlanCutData> 0x000000010277d288 <+2109> movaps 0x80(%rax),%xmm0

This is http://llvm.org/pr10514 Unfortunately the fix did not make it into that version of clang. On Oct 20, 2011, at 7:47 AM, Somorjai, Akos wrote: > Here's a code generated with -Os on darwin/x86_64 with clang from the Xcode 4.2 GM toolset on Mac OSX 10.7.2 (Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn), Target: x86_64-apple-darwin11.2.0) > >

I've tracked down a problem I've been having with llvm code ensconced in shared libraries that priori to r139934, on OS X 10.7.1-10.7.2 worked fine. Since r139934, which involves a configure change (and configure.ac), resulting in the default clang compiler to be used when building clang, and llvm, it seems I can no longer deposit llvm code involving jit, and IR gen functionality into

Hi, > Problem solved. I was building llvm in a separate llvm-build directory. I > built it within the llvm-src directory (which kept all the llvm .so and my > pass' .so in the llvm-src/Release+Asserts/lib directory) to solve the > problem. I do not fully understand what you mean, there should be no difference on building out of source AFAIK. > Can anyone tell me what's

Hi guys, > So it is valid SPIR, as the specification stands, to manipulate __local > variables as Constants in a way that is extremely difficult to undo. That > is, in order to transform SPIR to code that can run on a CPU, the > GlobalVariable (which is a subclass of Constant) must be replaced with a > dynamically calculated Value (which is not a subclass of constant). What about