similar to: [LLVMdev] Porting to System z

Hi, > llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td > tblgen: IntrinsicEmitter.cpp:163: void EmitTypeForValueType(std::ostream&, > llvm::MVT::SimpleValueType): Assertion `false && "Unsupported ValueType!"' > failed. this came up before IIRC, but I don't remember the details - buggy system compiler? Try searching the archives. Also, if you

I searched the archives and found this from last month: I ran into the same problem and fixed it by forcing the MVT::SimpleValueType enum to be 64 bits so that all of the types in the union later in the class are the same size. I tested this on ppc64 and x86_64. Index: include/llvm/CodeGen/ValueTypes.h =================================================================== ---

* Neale Ferguson: > So the SimpleTy variable which is a SimpleTypeValue is behaving strangely. > It's found within a private definition: > > union { > uintptr_t V; > SimpleValueType SimpleTy; > const Type *LLVMTy; > }; > > The comment in the above fix indicates that in this 64-bit system the enum > needs to be 64-bits is correct,

I was running into a problem with compiling llvm with gcc 4.4 on fedora 11 with --enable-optimized. I was seeing this warning dozens of times: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h: In member function ‘llvm::SDNode*<unnamed>::SPUDAGToDAGISel::Select(llvm::SDValue)’: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h:362: warning: comparison always

Yes, that works much better. However, I fear the problem is more to do with trying to force enums to be a different size which appears not to be supported by most compilers. The IBM C++ compiler apparently has a #pragma which can be used to do it and gcc 4.3 seems to be happy with the hack described but as Duncan says trying to force this behavior in a union is probably less than desirable in the

Hi, Were you able to get past this error: make[1]: Entering directory `/builddir/build/BUILD/llvm-2.5/lib/VMCore' llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td tblgen: IntrinsicEmitter.cpp:137: void EmitTypeForValueType(std::ostream&, llvm::MVT::SimpleValueType): Assertion `false && "Unsupported ValueType!"' failed. make[1]: Leaving directory

I'm trying to understand why this assertion is here. LegalizeAction getCondCodeAction(ISD::CondCode CC, EVT VT) const { assert((unsigned)CC < array_lengthof(CondCodeActions) && (unsigned)VT.getSimpleVT().SimpleTy < sizeof(CondCodeActions[0])*4 && "Table isn't big enough!"); LegalizeAction Action = (LegalizeAction)

On Thu, 26 Jul 2012 21:15:35 +0000 "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > Well, I found out the reason why this assert is here, and this is > problematic. > > CondCodeActions only supports up to 32 different value types. Since > we are past 32, what LLVM has is broken. > > Currently the 4 different Legalize states are stored in successive >

Well, I found out the reason why this assert is here, and this is problematic. CondCodeActions only supports up to 32 different value types. Since we are past 32, what LLVM has is broken. Currently the 4 different Legalize states are stored in successive bits and packed into a uin64_t, see TargetLowering.h. /// CondCodeActions - For each condition code (ISD::CondCode) keep a /// LegalizeAction

Yeah just the ordering are the real difference. Also, I use shifts and masks instead of conditionals and modules. My patch is attached. For me either patch is fine, but what LLVM has now is broken. Either patch is fine, just need approval from someone to submit. Micah > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Thursday, July 26, 2012 2:39 PM

On Fri, Feb 6, 2009 at 8:42 PM, Tanya Lattner <tonic at nondot.org> wrote: > LLVMers, > > The 2.5 pre-release is available for testing: > http://llvm.org/prereleases/2.5/ > I'm updating the Fedora packaging of LLVM, and with the 02/20 prerelease it fails to build on ppc64: http://koji.fedoraproject.org/koji/taskinfo?taskID=1148023 make[1]: Entering directory

Michel Salim wrote: > On Fri, Feb 6, 2009 at 8:42 PM, Tanya Lattner <tonic at nondot.org> wrote: >> LLVMers, >> >> The 2.5 pre-release is available for testing: >> http://llvm.org/prereleases/2.5/ >> > I'm updating the Fedora packaging of LLVM, and with the 02/20 > prerelease it fails to build on ppc64: > >

Hi Neale, > Yes, that works much better. However, I fear the problem is more to do with > trying to force enums to be a different size which appears not to be > supported by most compilers. The IBM C++ compiler apparently has a #pragma > which can be used to do it and gcc 4.3 seems to be happy with the hack > described but as Duncan says trying to force this behavior in a union is

I tried adding them in my backend however I run into the assertion assert((unsigned)VT.SimpleTy < sizeof(LoadExtActions[0])*4 && ExtType < array_lengthof(LoadExtActions) && "Table isn't big enough!"); What does the assertion mean ? thanks for all help!! shrey On Wed, Jul 14, 2010 at 6:56 PM, Eli Friedman <eli.friedman at

On Aug 24, 2009, at 1:32 AM, Duncan Sands wrote: > unfortunately, race detectors like helgrind don't like this kind of > thing, and report it as a race. Last time I asked about it I was > told that fixing it would be too hard/expensive. I know, and it's somewhat unfortunate. However, this path is extremely hot in LLC, and was significantly contended using only two threads. I

On Fri, Jul 16, 2010 at 5:14 PM, shreyas krishnan <shreyas76 at gmail.com> wrote: > I tried adding them in my backend however I run into the assertion > >  assert((unsigned)VT.SimpleTy < sizeof(LoadExtActions[0])*4 && >           ExtType < array_lengthof(LoadExtActions) && >           "Table isn't big enough!"); > > What does the

With the TableGen problem circumvented the build proceeds quite well up until: llvm[2]: Linking Debug executable llc /home/neale/LLVM/llvm/tools/llc/Debug/llc.o: In function `ForceCodegenLinking': /home/neale/LLVM/llvm/include/llvm/CodeGen/LinkAllCodegenComponents.h:45: undefined reference to `llvm::createBURRListDAGScheduler(llvm::SelectionDAGISel*, bool)'

I ran with VERBOSE=1 and see: g++ -I/home/neale/LLVM/llvm/include -I/home/neale/LLVM/llvm/tools/llc -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -g -fno-exceptions -fPIC -Woverloaded-virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -Wunused -Wno-unused-parameter -g -Wl,-R -Wl,/home/neale/LLVM/llvm/Debug/bin -Wl,-export-dynamic

Hello, > +static const uintptr_t minus_one = -1; -1 here is of signed int type. What if you will use -1ULL ? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Just got clang from head and getting: ExprConstant.cpp: In function Obool TryEvaluateBuiltinNaN(clang::ASTContext&, clang::QualType, const clang::Expr*, bool, llvm::APFloat&)¹: ExprConstant.cpp:1578: error: no matching function for call to Ollvm::StringRef::getAsInteger(int, llvm::APInt&)¹ /home/neale/LLVM/llvm/include/llvm/ADT/StringRef.h:269: note: candidates are: bool