similar to: [LLVMdev] Problem building TOT

On 12/23/2011 08:16 AM, Richard Pennington wrote: > Hi, > > I'm having a problem building TOT. > llvm-config --libs all-targets > doesn't include hexagon so I get a link error. > > I'm trying to figure out what magic causes the all-targets list to get defined. > No luck so far. Any thoughts? I've been running "rm Makefile.llvmbuild" and

----- Original Message ----- > From: "Hal Finkel via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Richard Pennington" <rich at pennware.com> > Cc: llvm-dev at lists.llvm.org > Sent: Wednesday, September 7, 2016 7:37:50 AM > Subject: Re: [llvm-dev] [PowerPC] Recent branch too far breakage > > Hi Rich, > > It is hard to tell, but there

Hey all, Quick query on out of tree target support - at present I can drop a folder Foo into <llvm>/lib/Target/Foo and use the CMake option LLVM_EXPERIMENTAL_TARGETS_TO_BUILD to pick up my target. The issue is that I still need to patch the one LLVMBuild.txt file in <llvm>/lib/Target with; |iff --git a/lib/Target/LLVMBuild.txt b/lib/Target/LLVMBuild.txt index 4112046..6e42cbe

I believe we'd need LLVMBuild.txt even in autoconf build - for bunch of autogenerated stuff, e.g. list of all asmprinters / asmparsers / InitializeAllTargetInfos, etc., since targets are not autoregistered anymore. On Mon, Mar 9, 2015 at 7:20 PM, Eric Christopher <echristo at gmail.com> wrote: > Hi Neil, > > Weird, I'd think the cmake build should probably do something

I'm using a recent revision of TOT (280704) to build clang/LLVM for PowerPC64 little endian. I'm getting an assembler error when building PPCInstPrinter.cpp: The error is: /tmp/PPCInstPrinter-84c835.s: Assembler messages: /tmp/PPCInstPrinter-84c835.s:7671: Error: operand out of range (0x0000000000008004 is not between 0xffffffffffff8000 and 0x0000000000007ffc) The offending line is

The raspberry Pi2 is an armv7a chip (Cortex-A7), the first stage builds fine with the native g++ (if not a little slowly at 10+ hours), but it crashes at some point with this command line: Program arguments: /home/ben/development/llvm/3.6.0/rc2/Phase2/Release/llvmCore-3.6.0-rc2.install/bin/clang -cc1 -triple armv7-unknown-linux-gnueabihf -emit-obj -disable-free -disable-llvm-verifier

I hate to say it (because I already made the changes), but keeping compatibility with 2.5 is a good thing. -Rich Owen Anderson wrote: > So, as you all probably noticed, the APIs for creating constants have > been moved (or in a specific cases, are about to be moved) from static > methods on Constant to instance methods on LLVMContext. > > However, as was recently pointed out

*System:* Debian Linux Sid/Unstable amd64 *LLVM/Clang:* Trunk *Scenario:* In the past couple of days I've been compiling against trunk I get two separate and spurious hang ups with CMake. *Note:* I build against more than just X86 follow along the progress of other platforms, though just building for X86 produces the same results below. *Assumption:* Configure cmake with prior built

Hi, :If I compile this file with debugging enabled (clang/LLVM TOT) int main() { } I get the error Error: inconsistent uses of .cfi_sections From the 2.27 binutils assemblers. It seems that 2.27 doesn't like the .cfi_sections .debug_frame directive following previous .cfi directives. The assemblers seem to be happy if the .cfi_sections directive precedes any other .cfi directive. Is

Hi, I've recently been updating my stuff with LLVM TOT with the context changes, etc. I'm up to date as of yesterday. In my environment I do most of the translation in memory: 1. Parse the source file(s). 2. lower to LLVM module(s) 3. bc optimize module(s) 4. bc link module(s) 5. generate a .s file and assemble it 6. link .o's and libraries. This was working very well until a

Hi, I was compiling libc++ with a recent TOT (248571) and when I got to the ARMv6, I got a code generation error in memory.cpp: fatal error: error in backend: Cannot select: intrinsic %llvm.arm.clrex ecc: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 3.8.0 (trunk) It looks as if the newly added emitAtomicCmpXchgNoStoreLLBalance() function is

The buildbots are unhappy again. :-( Specifically, the "llvm-gcc-i386-darwin9" buildbot here at Apple last compiled TOT successfully yesterday morning (31aug); that was revision 80586. By revision 80589, the bootstrap failed due to a miscompare, and by revision 80610, it's aborting while compiling little pieces of libgcc. 80586 built O.K. (about 8AM, Pacific Standard

So, as you all probably noticed, the APIs for creating constants have been moved (or in a specific cases, are about to be moved) from static methods on Constant to instance methods on LLVMContext. However, as was recently pointed out on llvm-commits and on IRC, this is no longer strictly necessary. Because types have contexts, all of the constant subclasses could be friended to

Hello everybody, I have been puzzling over how to uninstall the SVN Head release of LLVM for compatibility with llvm-gcc 4.2-2.6. Our project is based on 2.6 of LLVM but I needed to install TOT to check if a bug was ours or had been fixed in the latest LLVM. Now that the bug is fixed, I need to go back to LLVM 2.6. I used CMake to build TOT on MacOSX 10.5.x and there is no "make

I'm getting a lot of these from TOT make: /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h: In instantiation of 'llvm::LoopInfoBase<llvm::BasicBlock>': /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h:886: instantiated from here /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h:573: warning: 'class

Chris, > On Nov 29, 2012, at 2:13 PM, Tom Stellard <tom at stellard.net> wrote: >> Hi Dimitri, >> >> Thanks for taking a look at the code. >> >> I went ahead and made all of these changes, and I reviewed the doxygen section >> of the Coding Standards document and updated the comments as well. >> I also fixed the issue mentioned by Ben with

Hi Will, On Fri, May 13, 2011 at 7:30 PM, Will Dietz <willdtz at gmail.com> wrote: > Hi all, > > I'm interested in using VMKit rather extensively in a project of mine. > > Great! > I was hoping to get feedback on a few vmkit-related questions from > those more familiar: > > --Is there a 'best' version to use? I'd be inclined to use the 2.9 >

On Fri, Sep 25, 2015 at 2:17 PM, JF Bastien <jfb at google.com> wrote: > Looks like this was caused by r248294. Author CC'ed. > > On Fri, Sep 25, 2015 at 1:46 PM, Richard Pennington via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> I was compiling libc++ with a recent TOT (248571) and when I got to the >> ARMv6, I got a

Hi, I've been working on combining LLVM, clang, the NetBSD standard C library, compiler-rt, QEMU, GDB, and GNU binutils as a cross compilation environment. My goal is to target small embedded systems, but I think that what I'm working on may be of interest to other LLVM/clang developers as I have been able to use the environment to fix several code generation issues in LLVM. As of

In r198030 the last in tree backend was converted to use MCInst for printing assembly. I removed support for the old printer in r198959. Out of tree targets have to lower MachineInstr to MCInst to use the new printer. Cheers, Rafael