similar to: [LLVMdev] cvs opt broken?

PR1317 says that it is resolved. Looking at the details of the report, it says that a fix had been committed for the "instant case." Am I right that means a fix has been submitted that makes LLVMHello work with opt, but that the general problem has not been resolved and is reported in PR1318? Reid Spencer wrote: > Hi Ryan, > > On Tue, 2007-04-10 at 00:12 -0500, Ryan M.

Hi Ryan, On Tue, 2007-04-10 at 00:12 -0500, Ryan M. Lefever 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 transform libraries fine, but it complains: > > opt: Unknown command

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 Tue, 2007-04-10 at 01:27 -0500, Ryan M. Lefever wrote: > PR1317 says that it is resolved. Looking at the details of the report, > it says that a fix had been committed for the "instant case." Am I > right that means a fix has been submitted that makes LLVMHello work with > opt, but that the general problem has not been resolved and is reported > in PR1318? Yes,

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

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 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

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

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 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"

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]

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

On Tue, Jun 24, 2008 at 2:03 AM, Ryan M. Lefever <lefever at crhc.uiuc.edu> wrote: > My problem is that if I use the -g option in lines 1 and 2, then when I > run llvm-ld in line 5, it complains that there are undefined references > to .LlableX. -g + optimization is unsupported at the moment. Off the top of my head, I know that global DCE and inlining break debug info; probably

Hi, I apologize if this is a duplicate question; I didn't see it previously on the list. I'm using llvm 1.6 and my setup is as follows. LLVM is installed at /usr/software/llvm and the cfrontend is installed at /usr/software/cfrontend. If I cd to /usr/software/llvm/lib/Transforms/Hello and compile the Hello transform I have no problems. However, if I copy the Hello directory to my

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

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

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 >

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

This certainly doesn't occur in gcc mainline. In fact, I improved the error message, and added a error test to gcc just yesterday. On 8/9/07, Chris Lattner <sabre at nondot.org> wrote: > On Wed, 8 Aug 2007, Nikhil A. Patil wrote: > > I think I found a bug. I don't know if it's in upstream gcc or llvm-gcc4. > > Looks like a bug, please file a bugzilla entry. >

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