search for: lastsimplevaluetype

...de/llvm/CodeGen/ValueTypes.h (working copy) @@ -21,6 +21,8 @@ #include "llvm/Support/DataTypes.h" #include "llvm/Support/MathExtras.h" +static const uintptr_t minus_one = -1; + namespace llvm { class Type; @@ -92,7 +94,10 @@ iPTR = 255, // LastSimpleValueType - The greatest valid SimpleValueTypevalue. - LastSimpleValueType = 255 + LastSimpleValueType = 255, + + // force the size of the enum to be sizeof(uintptr_t) + _BigValue = minus_one }; private:

...function '@_ZL6createP6node_tii3v_tS1_d' The problem appears to be gcc 4.4 optimizing away comparisons of one plus the last item in the SimpleValueType enum, like this: bool operator==(const EVT VT) const { if (V.SimpleTy == VT.V.SimpleTy) { if (V.SimpleTy == MVT::LastSimpleValueType+1) return LLVMTy == VT.LLVMTy; return true; } return false; } I confirmed this by adding a dummy value to the enum that equals LastSimpleValueType+1, and both the warning and the failures in "make check" go away. Is this the right thing to do,...

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

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

Hello, The attached patch is to add an assert to getValueTypeList() to verify that for simple value types their value is NOT between MAX_ALLOWED_VALUETYPE and LastSimpleValueType (inclusive) as this causes a buffer overrun. Thanks, Javier -----Original Message----- From: Duncan Sands [mailto:baldrick at free.fr] Sent: Tuesday, April 27, 2010 5:07 AM To: Martinez, Javier E Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] Bufer overrun in getValueTypeList() Hi Javi...

Hi, I am beginning the porting process for Linux on System z (aka IBM Mainframe). I thought I¹d build LLVM first with the c and cpp backends so that tools like TableGen would be created that I¹d then use to process the .td files that I¹ll be creating. So I used svn to grab the code from the repository and ran configure and make. However, the build breaks at this point: llvm[1]: Building

...i3v_tS1_d' > > > The problem appears to be gcc 4.4 optimizing away comparisons of one > plus the last item in the SimpleValueType enum, like this: > > bool operator==(const EVT VT) const { > if (V.SimpleTy == VT.V.SimpleTy) { > if (V.SimpleTy == MVT::LastSimpleValueType+1) > return LLVMTy == VT.LLVMTy; > return true; > } > return false; > } ValueTypes.h was particularly heavily impacted by the recent API changes, and it looks like it's a bit disheveled at the moment. > > I confirmed this by adding a...

...llvm/CodeGen/ValueTypes.h (working copy) @@ -21,6 +21,8 @@ #include "llvm/Support/DataTypes.h" #include "llvm/Support/MathExtras.h" +static const uintptr_t minus_one = -1; + namespace llvm { class Type; @@ -92,7 +94,10 @@ iPTR = 255, // LastSimpleValueType - The greatest valid SimpleValueTypevalue. - LastSimpleValueType = 255 + LastSimpleValueType = 255, + + // force the size of the enum to be sizeof(uintptr_t) + _BigValue = minus_one }; private: I added this code but, apart from generating warnings about a negative va...

...List() is sometimes called with type MVT::iPTR. There is a discrepancy between the size of the array VTs and the use in getTypeValueList(). The array is allocated with space for elements up to LAST_VALUE_TYPE and iPTR is defined after it. The enumerator value of iPTR is between LAST_VALUE_TYPE and LastSimpleValueType. For this reason the check VT.isExtended() fails and the value is looked up in VTs triggering an out of bounds access. In the version of LLVM we're using getValueTypeList even tries to write to that array element causing a memory corruption. Should iPTR handled with the extended types, simple...

Hi Duncan, I've modified my backend such that the function isn't called anymore with iPTR. I still think that if iPTR is an invalid input to getValueTypeList() that the function should have at least an assert checking that. Thanks, Javier Hi Javier, > I've observed in some tests that getValueTypeList() is sometimes called > with type MVT::iPTR. I think this is a bug,

Hi Javier, > I’ve modified my backend such that the function isn’t called anymore > with iPTR. I still think that if iPTR is an invalid input to > getValueTypeList() that the function should have at least an assert > checking that. I agree - please post a patch adding one. Ciao, Duncan.

LLVMers, The 2.5 pre-release is available for testing: http://llvm.org/prereleases/2.5/ If you have time, I'd appreciate anyone who can help test the release. Please do the following: 1) Download/compile llvm source, and either compile llvm-gcc source or use llvm-gcc binary (please compile llvm-gcc with fortran if you can). 2) Run make check, send me the testrun.log 3) Run "make