similar to: [LLVMdev] weird analysis group behavior

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 my 32 bit linux box, things seam to work find, but on my 64 bit linux box I am getting problems. I have the following c file (lib.c): -------------------------------- #include <stdio.h> void libmethod(){ printf("libmethod()\n"); } ------------------------------- I tried to get a shared library using the following commands: llvm-gcc -emit-llvm -Wall -fPIC -c -o lib.opt.bc

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"

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

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

After looking through the README for the llvm gcc frontend, it says: ----------------------------------------------------------------------- X86-64/AMD-64/EM64-T for any OS other than Darwin/Mac OS X: When targeting non-darwin X86-64/AMD-64/EM64-T, configure with --disable-shared. The LLVM X86-64 backend doesn't support PIC codegen on non-darwin systems yet. If you get a build error, try

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

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 guess Bill Wendling cleared it up a little more for me. Neither llvm nor gcc ignore const. The type checking in each of their frontends makes sure that const is not violated. The reason I was asking about const is as follows. I was under the impression that const was part of c to aid the compiler with optimization and not just for type checking purposes. As you previously pointed out,

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 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 functions that are used by libmyxform.so. When I run: ------- /llvm/bin/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

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 >

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 assume that when -O3 (or O2 or O1) is passed to llvm-gcc, then it utilizes opt. How do I determine what passes opt runs? How do I determine what external tools (and arguments) llvm-gcc is invoking? Regards, Ryan

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

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

Hi! I'm trying to run llvm-test (current CVS head) with the following command: $LLVMOBJDIR/projects/llvm-test$ make TEST=llc report I run into the following error: make[5]: Entering directory `$LLVMOBJDIR/projects/llvm-test/SingleSource/UnitTests/Vector/SSE' make[5]: *** No rule to make target `Output/sse.expandfft.linked.rbc', needed by `Output/sse.expandfft.linked.bc'. Stop.

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

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