similar to: [LLVMdev] trouble finding symbols

On Fri, May 9, 2008 at 5:35 PM, Ryan M. Lefever <lefever at crhc.uiuc.edu> wrote: > I am trying to upgrade to the latest version of LLVM from svn. My > transformations compile correctly, but when I go to run them I get a > symbol lookup error. In particular, I have 2 libraries that I compile > for use with opt called libaux.so and libmyxform.so. libaux.so > implements

I am trying to upgrade my code to use the latest version of llvm from svn. Whenever I include "llvm/ADT/HashExtras.h", I get error messages like the following. Does anyone know what is going on? Thanks for any help. llvm[1]: Compiling Aux.cpp for Debug build (PIC) In file included from /home/lefever/work/memrep/src/compiler/include/Aux.h:4, from Aux.cpp:1:

So, after digging around in the old llvm/ADT/hash_map, I think I discovered the problem. Now, if you want to include llvm/ADT/HashExtras.h, you have to include the hash_map h file from your system (ext/hash_map in my case) and define HASH_NAMESPACE, before you include llvm/ADT/HashExtras. It might be good to include some documentation about that for those using HashExtras. Regards, Ryan

I have a bitcode file x.bc. When I run llmv-nm on x.bc, it shows that a function f(), that I've written, is defined as a global function (text) object, i.e., llvm-nm shows it marked with a 'T'. I have converted x.bc to an executable with the following command: llvm-ld -native -o x.exe x.bc When I run nm on x.exe, it shows that f is now a local function (text) object, i.e., nm

As a follow up, if I first convert x.bc to a c file using llc -march=c -o x.c x.bc, and then I use normal gcc to convert x.c to an executable, f() remains a global symbol. Is llvm-nm incorrectly converting the global symbols to local symbols? Ryan M. Lefever wrote: > I have a bitcode file x.bc. When I run llmv-nm on x.bc, it shows that a > function f(), that I've written, is

I don't mean to be a pain, but I was thinking about this a bit more. Does gcc ignore the const keyword? If not, why has LLVM chosen to deviate from gcc with respect to the const keyword? If so, then why do we bother using const in LLVM API code? I'm just curious and wanted to understand the thinking behind not preserving const. Thanks, Ryan Chris Lattner wrote: > This property

Does llvm-gcc support the -fPIC option? I am using LLVM on both 32 bit linux and 64 bit linux, if that matters. Regards, Ryan -- Ryan M. Lefever [http://www.crhc.uiuc.edu/~lefever/index.html]

I don't follow what you mean - gcc doesn't ignore const and llvm doesn't deviate from gcc nor from the relevant language standards. Note that if you declare a global as const that we do capture this in the ir - what specifically do you want? Please provide an example. -Chris http://nondot.org/sabre http://llvm.org On Aug 14, 2007, at 11:58 PM, "Ryan M. Lefever"

Forgot to hit "Reply All." -- John T. -------------- next part -------------- An embedded message was scrubbed... From: John Criswell <criswell at cs.uiuc.edu> Subject: Re: using dsa Date: Tue, 06 Mar 2007 09:53:43 -0600 Size: 3103 URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070306/ef7c2f29/attachment.mht>

I checked out llvm from cvs & llvm-gcc from svn last night and again tonight. Each time they compiled and installed fine. After installing them, I recompiled compiler transforms I had written for opt. opt seems to load the my transform libraries fine, but it complains: opt: Unknown command line argument '-mytransform' whenever I try to specify one of my transforms on the opt

This property isn't preserved on the llvm ir, because const can always be cast away. If you want mod information, then I suggest using the aliasanalysis interface to get mod ref info for a call. -Chris http://nondot.org/sabre http://llvm.org On Aug 8, 2007, at 12:07 AM, "Ryan M. Lefever" <lefever at crhc.uiuc.edu> wrote: > How is c's const keyword translated

How is c's const keyword translated when compiling c into llvm bytecode. I'm specifically interested in const pointer function arguments. Consider a function declared as follows in c: void f(const int* arg); When I examine f in llvm bytecode, how can I tell that arg is a pointer, whose contents can only be read, not written. Regards, Ryan

This has been reported. http://llvm.org/bugs/show_bug.cgi?id=1317 On 4/10/07, Ryan M. Lefever <lefever at crhc.uiuc.edu> wrote: > > I checked out llvm from cvs & llvm-gcc from svn last night and again > tonight. Each time they compiled and installed fine. After installing > them, I recompiled compiler transforms I had written for opt. opt seems > to load the my

On Wed, 22 Aug 2007, Ryan M. Lefever wrote: > I checked llvm-gcc 4.0 out from svn yesterday and am compiling it on 3 > different machines. I was able to compile it on 2 of the machines, but > the compilation failed on the third machine with the errors below. The > machine that the compilation failed on is running Fedora Core 4. The > processor is a AMD Athlon(tm) 64 Processor

I checked llvm-gcc 4.0 out from svn yesterday and am compiling it on 3 different machines. I was able to compile it on 2 of the machines, but the compilation failed on the third machine with the errors below. The machine that the compilation failed on is running Fedora Core 4. The processor is a AMD Athlon(tm) 64 Processor 3700+. The version of gcc I have on the machine is 4.0.2. I tried

I have been working on a compilation process that involves steps such as passing an application through transforms that I've written and combining the application with support code that I've written. When I compile an application using my compilation process without debugging, (i.e., "llvm-gcc -g"), everything works fine. However, when I compile an application using my

I think I misread the doxygen. verifyFunction & verifyModule return false if no errors are detected. However, my question now becomes why does the code produced by my transform pass verification, but it causes an assertion failure in the byte reader when it (the code produced by my transform) is passed to another invocation of opt? Ryan M. Lefever wrote: > I also tried iterating

Hi, I think I found a bug. I don't know if it's in upstream gcc or llvm-gcc4. int func() { const int *arr; arr[0] = 1; } $ llvm-gcc main.c -c; echo $? 0 $ gcc main.c -c main.c: In function 'func': main.c:4: error: assignment of read-only location The difference disappears when arr[0] is replaced by *arr. (I tried the above with gcc 4.1.2, 3.4.6, 4.0.3. (I don't

Yup! -bw On Nov 3, 2008, at 7:39 PM, Ryan M. Lefever wrote: > Does llvm-gcc support the -fPIC option? I am using LLVM on both 32 > bit > linux and 64 bit linux, if that matters. > > Regards, > Ryan > > -- > Ryan M. Lefever [http://www.crhc.uiuc.edu/~lefever/index.html] > _______________________________________________ > LLVM Developers mailing list >

Can I specify passes that I want run directly to llvm-gcc? I don't want all of -O3, for example. I tried llvm-gcc -raiseallocs ..., but that didn't work. I also tried running cc1 directly and it didn't take -raiseallocs as a parameter either. Duncan Sands wrote: > On Tuesday 28 April 2009 04:02:47 am Ryan M. Lefever wrote: >> I assume that when -O3 (or O2 or O1) is