similar to: [LLVMdev] Darwin option processing

On May 7, 2009, at 6:24 PM, Mike Stump wrote: > I'm toying with building with -mdynamic-no-pic, but for this to work, > the shared library bits in llvm can't be built with that flag. Hi Mike, If you're doing this for Clang's benefit, I think the best thing to do is to compile LLVM PIC (the default) and then build the clang front- end pieces with -mdynamic-no-pic. Does

On May 8, 2009, at 11:49 AM, Chris Lattner wrote: > On May 7, 2009, at 6:24 PM, Mike Stump wrote: >> I'm toying with building with -mdynamic-no-pic, but for this to work, >> the shared library bits in llvm can't be built with that flag. > > Hi Mike, > > If you're doing this for Clang's benefit, No, not really, I'm doing it for the general benefit of

On May 8, 2009, at 12:58 PM, Mike Stump wrote: >> I think the best thing to do >> is to compile LLVM PIC (the default) and then build the clang front- >> end pieces with -mdynamic-no-pic. Does this work for you? > > The proposed patch is more general that that. It avoids the flag, > when it is known it can't work, and leaves it in otherwise. This > allows the

On Tue, 01 May 2012 15:10:56 -0500 Peter Bergner <bergner at vnet.ibm.com> wrote: > On Sat, 2012-04-28 at 15:51 -0500, Hal Finkel wrote: > > > > - There is no support for generating position-independent code > > > > on PPC32. (PIC on PPC64 now works well). Nevertheless, I have > > > > sometimes run into linking errors when compiling shared > >

On Tue, 2012-05-01 at 16:06 -0500, Hal Finkel wrote: > LLVM/clang now will build in the normal way (./configure; make install) > on PPC (you'll need at least the 3.1 release candidate (or trunk)). I > generally build on my PPC64 hosts with: > make ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION=-O2 EXTRA_OPTIONS=-mminimal-toc Ok, it built fine, but what is the llvm equivalent of gcc's -m32

On May 8, 2009, at 1:02 PM, Chris Lattner wrote: > This goes against our general direction for llvm libraries: they > should generally all be built pic. After reviewing yet more of the Makefile,rules file, I believe ENABLE_PIC is the right thing to check. Currently ENABLE_PIC has to be set to get shared bits built, if the user wants them. Given that, we can use that to control

Anton, >> Can I ask what platform ABI's are documented other than Itanium ? > I'd bet all platform ABI are more or less documented. Right. Maybe we should collect references and do some LLVM PIC documentation and put it on LLVM website ? >> I need to get to understand PIC on x86, x86_64 and PowerPC for the COFF >> and MachO backends. > ABI is normally induced

On May 8, 2009, at 1:49 PM, Mike Stump wrote: > On May 8, 2009, at 1:02 PM, Chris Lattner wrote: >> This goes against our general direction for llvm libraries: they >> should generally all be built pic. > > After reviewing yet more of the Makefile,rules file, I believe > ENABLE_PIC is the right thing to check. Index: clang/Makefile.rules

>> 2. ABI docs for Darwin (x86, x86_64, ppc, ppc64) you might find >> somewhere @apple.com. There you can have all 3 types of PIC code: >> static (no pic at all), DynamicNoPIC and full PIC. > > Okay. We need documentation, what is the difference between > DynamicNoPIC and > full PIC ? The best way to figure this out is to run a small program through and look at

On Tue, 01 May 2012 17:23:07 -0500 Peter Bergner <bergner at vnet.ibm.com> wrote: > On Tue, 2012-05-01 at 16:06 -0500, Hal Finkel wrote: > > LLVM/clang now will build in the normal way (./configure; make > > install) on PPC (you'll need at least the 3.1 release candidate (or > > trunk)). I generally build on my PPC64 hosts with: > > make ENABLE_OPTIMIZED=1

When compiling trunk using gcc 4.1.2 on linux/ppc64, I now see a warning that I don't remember seeing previously: llvm[2]: Compiling InlineSpiller.cpp for Release+Asserts build /src/llvm-trunk-dev/include/llvm/ADT/PointerIntPair.h: In member function ‘const PointerTy* llvm::PointerIntPair<PointerTy, IntBits, IntType, PtrTraits>::getAddrOfPointer() const [with PointerTy = void*, unsigned

Hi Bill, this might be a latent bug related to PPC. I have no such machine to access atm., but I shall be able to reproduce the problem when back at home. (In about 4 hours). I keep you informed. Cheers, Gabor On Mar 4, 7:57 pm, Bill Wendling <wendl... at apple.com> wrote: > Something last night broke the build on Darwin PPC. Possible Gabor's   > check-in? > > -bw

Something last night broke the build on Darwin PPC. Possible Gabor's check-in? -bw Begin forwarded message: > From: admin at spang.apple.com (admin) > Date: March 4, 2009 3:56:10 AM PST > To: wendling at apple.com > Subject: PPC Nightly Build Result > > /Volumes/SandBox/NightlyTest/llvmgcc42.roots/llvmgcc42~obj/obj- > powerpc-powerpc/./prev-gcc/xgcc

While attempting to build llvm-gcc-4.2 from llvm-2.7 release branch, I am finding that the build fails at... c++ -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -mdynamic-no-pic -DHAVE_CONFIG_H -o f951 \ fortran/arith.o

Anton, Sorry I have not replied earlier. Can I ask what platform ABI's are documented other than Itanium ? I need to get to understand PIC on x86, x86_64 and PowerPC for the COFF and MachO backends. Thanks, Aaron 2009/6/15 Anton Korobeynikov <anton at korobeynikov.info> > Hello, Aaron > > > Is there any overview or detailed socumentation on LLVM PIC ? > Did you

Hello, Aaron > Can I ask what platform ABI's are documented other than Itanium ? I'd bet all platform ABI are more or less documented. > I need to get to understand PIC on x86, x86_64 and PowerPC for the COFF and MachO backends. ABI is normally induced by platform, not by architecture or object file format (however they can influence on it). 1. Windows is PIC by design. Google for

The curent llvm svn (r54623) is unable to link the gfortran compiler in llvm-gcc-4.2 svn. I am getting the error... c++ -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -mdynamic-no-pic -DHAVE_CONFIG_H -o f951 \

Dear All, I'm getting the following error on Mac OS X when compiling C++ code in the LLVM test suite: g++ Output/minisat.llc.s -o Output/minisat.llc -lm -m64 -fomit-frame-pointer -mdynamic-no-pic -lstdc++ -lm Output/minisat.llc.s:5:Unknown pseudo-op: .cfi_startproc Output/minisat.llc.s:8:Unknown pseudo-op: .cfi_def_cfa_offset Output/minisat.llc.s:8:Rest of line ignored. 1st junk

Thought a bit more. There's also -mdynamic-no-pic. Not typically used these days, but is still there AFAIK. -Jim On Oct 21, 2011, at 4:05 PM, Eric Christopher wrote: > IIRC the kernel uses relocation model as static. > > -eric > > On Oct 21, 2011, at 3:57 PM, David Meyer wrote: > >> Eli, >> >> Hm. There's a test in (CodeGen/X86/call-imm.ll) which

To build 64-bit libraries (i.e. 'file <library>' shows x86_64) try 'make EXTRA_OPTIONS=-m64" Either 32-bit or 64-bit libraries are able to generate code for either 32-bit or 64-bit, try -m32 or -m64 at runtime On Feb 9, 2009, at 4:16 PMPST, Jan Rehders wrote: > Hi, > > how do I compile LLVM for 64-bit on OS X? I want to get 64-bit > libraries which