similar to: [LLVMdev] fPIC

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

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 >

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

It appears that llvm-ld can handle bitcode files but llvm-gcc complains that when I pass bitcode files to it. I assume that means that llvm-gcc does not use llvm-ld by default. Is there a way to force it to use llvm-ld? Bill Wendling wrote: > You do it by using the -flto flag. But you will need a linker that's able to handle the bitcode files. The Apple linker can and so can the

You do it by using the -flto flag. But you will need a linker that's able to handle the bitcode files. The Apple linker can and so can the "gold" linker. -bw On Oct 3, 2010, at 7:47 PM, Ryan M. Lefever wrote: > The reason I was linking via llvm-ld is because I didn't know how to > pass bitcode files to llvm-gcc. How can I do that? > > Anton Korobeynikov wrote:

The reason I was linking via llvm-ld is because I didn't know how to pass bitcode files to llvm-gcc. How can I do that? Anton Korobeynikov wrote: >> Is fPIC broken on x86_64 in LLVM 2.6? > No, it works w/o any problems > >> ------------------- >> > llvm-gcc -Iinclude -emit-llvm -fPIC -O3 -c -o file.opt.bc file.c >> > llvm-ld -native -Xlinker=-shared

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

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

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

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

Is fPIC broken on x86_64 in LLVM 2.6? I looked through the release notes but did not see anything mentioned. When I try: ------------------- > llvm-gcc -Iinclude -emit-llvm -fPIC -O3 -c -o file.opt.bc file.c > llvm-ld -native -Xlinker=-shared -Xlinker=-Wl,-soname,libtest.so -o file.so file.opt.bc ------------------- on an x86 machine it works fine. When I try it on x86_64, the

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 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. -Chris > 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:

On Thu, 9 Aug 2007, Daniel Berlin wrote: > This certainly doesn't occur in gcc mainline. > In fact, I improved the error message, and added a error test to gcc > just yesterday. Yep, clang reports: t.c:4:12: error: read-only variable is not assignable arr[0] = 1; ~~~~~~ ^ 1 diagnostic generated. so this is specific to llvm-gcc somehow. -Chris > On 8/9/07, Chris

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

Chris, I'm a little confused. I am experiencing a crash when compiling the llvm-gcc frontend. According to the bugpoint documentation, bugpoint is used to debug "optimizer crashes, miscompilations by optimizers, or bad native code generation," which seems like it implies that the frontend compiles. Also, the http://llvm.org/docs/HowToSubmitABug.html documentation seems to

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