similar to: [LLVMdev] Instruction::getOpcodeName()

First, thanks for testing this! > Here's the results for GNU/Linux, 2.6.18-1.2200.fc5smp (Fedora Core 5) > > HIGH LEVEL COMMENTS > * The llvm-1.9.tar.gz file unpacks to a dir named "llvm". Shouldn't > that be llvm-1.9? We have always labeled the dir just llvm which is fine. If you build llvm it will know its version 1.9. > * LLVM was built in Release mode

Tanya, Here's the results for GNU/Linux, 2.6.18-1.2200.fc5smp (Fedora Core 5) HIGH LEVEL COMMENTS * The llvm-1.9.tar.gz file unpacks to a dir named "llvm". Shouldn't that be llvm-1.9? * LLVM was built in Release mode in all cases * I don't think this is ready for release. In particular the llvm-gcc4 binary seg faults on FC 5 for most of llvm-test programs. *

Hi Tanya, Here's my second attempt on Fedora Core 5. The changes this time are: 1. Using GCC 4.0.3 as the compiler 2. Building everything from source (no pre-built binaries used) BUILD LLVM WITH GCC 4.0.3 * No issues, just the usual warnings. BUILD LLVM-GCC WITH GCC 4.0.3 * No issues RUN LLVM-TEST WITH GCC 4.0.3 * The following failures were encountered. Some of them are

Can anyone help with these crazy linking errors?? /home/kgibbs/CS321/CVS/llvm/lib/Debug/vmcore.o(.gnu.linkonce.t._ZN4llvm12Lea kDetector16addGarbageObjectEPKNS_5ValueE+0xd): In function `llvm::LeakDetector::addGarbageObject(llvm::Value const*)': /usr/include/c++/3.2.1/bits/stl_pair.h:148: undefined reference to `llvm::LeakDetector::addGarbageObjectImpl(llvm::Value const*)'

LLVMers, The LLVM 1.9 Prerelease is available for testing: http://llvm.org/prereleases/1.9/ If anyone can spare some time, please download the appropriate tarballs for your platform and test the release (at least with make check). I'd also appreciate any documentation reviews. Please note that llvm-gcc3 on x86 may not have a clean dejagnu run. You should see one XPASS for

You'll need to include the "support" library to resolve these LeakDetector symbols. You can do this by either placing the path to "support.o" or -lsupport on your link line (in your Makefile). Note that if you use the -l option, you'll likely need to use -L<path> as well to tell the linker where to find "libsupport.a" (file included by the

Hi, don't know if this is the right list. Please post a better place, otherwise. I'm currently writing a LLVM ModulePass and ran into strange segfaults or endless loops within LLVM. My main question is, if this is a programming error or API misuse from me or a LLVM bug? Here is some minimal code, that triggers the bug: ---------------- class DebugPass : public ModulePass { public:

I'm iterating over MCInsts and I'd like to examine particular instructions. For example, I'd like to look at all x86 CALL64m instructions. I may be missing something, but it seems like my only option is to use MCInstPrinter::getOpcodeName and compare strings. (Of course, I could iterate through the opcodes and build up a table of the ones I'm interested in to avoid string

The various intrinsic assert/crashes should all be fixed on mainline CVS (they are PR733, which I just fixed). The only ones that I'm wary of are: XPASS: /proj/llvm/build/../llvm/test/Regression/CFrontend/2004-02-20- StaticRedeclare.c.tr FAIL: /proj/llvm/build/../llvm/test/Regression/CFrontend/2005-12-04- DeclarationLineNumbers.c: In the former case, I would guess that the test isn't

I just updated again (both llvm and llvm-gcc). The only thing that changed was: P test/Regression/CFrontend/2005-12-04-DeclarationLineNumbers.c The regression test below was done *with* your llvm-gcc changes to llvm- expand.c. I don't know what the failures are all about, but I will try it again. If its the same, I'll let you know. Reid. On Thu, 2006-04-13 at 16:20 -0500, Chris Lattner

Ok that works but why on earth would I get a runtime error of: Type.cpp:132: const llvm::Type* llvm::Type::getForwardedTypeInternal() const: Assertion `ForwardType && "This type is not being forwarded to another type!"' failed. Aborted For the line of code: MyModule = new Module( std::string("IDontWork")); > -----Original Message----- > From: llvmdev-admin

Hi, Looking into LLVM for a database query engine project... After downloading the latest source from CVS, it's my first time trying to build LLVM. Following the "Getting Started" instructions, all went well until gmake reported this error while trying to link llc: In function `(anonymous namespace)::BreakCriticalEdges::getAnalysisUsage(llvm::AnalysisUsage&) const':

The problem I'm experiencing with Stacker has to do with linkage types (again!). What I'm trying to do is create a "global appending" array. In compilation units that don't include "main", I generate it with: TheStack = new GlobalVariable( /*type=*/ stack_type, /*isConstant=*/ false, /*Linkage=*/

Here's what's left on Linux (GCC 4.1.0), after all updates that went into the branch: Running /proj/llvm/build/../llvm/test/Regression/CFrontend/dg.exp ... FAIL: /proj/llvm/build/../llvm/test/Regression/CFrontend/2004-02-12- LargeAggregateCopy.c.tr: gccas: /proj/llvm/build/../llvm/lib/VMCore/Function.cpp:266: unsigned int llvm::Function::getIntrinsicID() const: Assertion `0 &&

I am trying to build llvm-2.7 using non-system gcc/binutils. My gcc version is 4.1.2, and binutils is 2.17.50.0.15. I get the following errors `.L2438' referenced in section `.gnu.linkonce.r._ZNK4llvm16DAGTypeLegalizer13getTypeActionENS_3EVTE' of /build/toolchain/src/llvm-2.7/objdir/Release/lib/libLLVMSelectionDAG.a(LegalizeTypes.o): defined in discarded section

On Oct 28, 2013, at 2:02 PM, Tyler Hardin <tghardin1 at catamount.wcu.edu> wrote: > See the source here: https://github.com/earl/llvm-mirror/blob/master/lib/Target/X86/InstPrinter/X86IntelInstPrinter.cpp. It looks like getRegisterName might do what you want, but I don't know where it's coming from. (Whether it's a function or a member of a super class. Hopefully, if it's

See the source here: https://github.com/earl/llvm-mirror/blob/master/lib/Target/X86/InstPrinter/X86IntelInstPrinter.cpp. It looks like getRegisterName might do what you want, but I don't know where it's coming from. (Whether it's a function or a member of a super class. Hopefully, if it's a member, it's public.) PS Sorry for the duplicate, Stephen. I forgot to CC the list. On

On Thu, May 13, 2010 at 12:28 PM, john blair <mailtome200420032002 at yahoo.com> wrote: > I am trying to build llvm-2.7 using non-system gcc/binutils. My gcc version is 4.1.2, and binutils is 2.17.50.0.15. I get the following errors That version of gcc is known to have issues building LLVM; see http://llvm.org/docs/GettingStarted.html#brokengcc . Try upgrading your gcc version. -Eli

Hi, I am trying to build and install LLVM onto a current Debian Linux system using gcc4 frontend binaries for Red Hat Enterprise Linux4/x86 . Using the commands below the Build finishes, ignoring an error that comes up again when I try to make install. See the messages below. I have no good feeling about the "-i -k" options. Is it OK? Thank you in advance for any advice and best

On Mon, 12 Feb 2007, Carsten Reuter wrote: > I am trying to build and install LLVM onto a current Debian Linux system > using gcc4 frontend binaries for Red Hat Enterprise Linux4/x86 . > Using the commands below the Build finishes, ignoring an error that > comes up again when I try to make install. > See the messages below. I have no good feeling about the "-i -k" options.