similar to: [LLVMdev] Bufer overrun in getValueTypeList()

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.

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

Hello, I've observed in some tests that getValueTypeList() 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

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: > >

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

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

On Wed, Nov 11, 2009 at 11:11 AM, Chris Lattner <clattner at apple.com> wrote: > On Nov 10, 2009, at 4:10 PM, Talin wrote: > > I realize that most users of LLVM aren't affected by this, because most > frontends aren't target-neutral, and thus know in advance how big a pointer > is. At least, that's my impression. > > I believe that. > > >

On 7 April 2013 14:54, Sam Parker <S.Parker3 at lboro.ac.uk> wrote: > Hi Anitha, > > memri is just describing that the address contains two components, an > immediate and a register, and how to handle them in the instruction printer. > The STWU expects a memri operand, and that is what is passed from the Pat. > My confusion is how operands of STWU from "Pat

From: Thorvald Natvig <slicer at users.sourceforge.net> Some optimizing compilers miscompile the current SSE optimizations when full optimizations are enabled. By using output value pointer instead of a return value, we can bypass this misbehaviour. --- libspeex/resample.c | 8 ++++---- libspeex/resample_sse.h | 24 ++++++++---------------- 2 files changed, 12 insertions(+), 20

2013/6/23 David Chisnall <David.Chisnall at cl.cam.ac.uk> > Hi, > > In our version of LLVM, we've added different-sized iPTR* types, so we > have an iPTR256 for our fat pointers. This causes some problems with > constraints, because the way that TableGen resolves constraints is not > expected to handle multiple pointer types. We've added a flag that can be >

On Nov 12, 2009, at 11:29 AM, Talin wrote: > > Well, as far as intp goes (or iptr if you prefer - the naming > convention in LLVM is i<size>) How about "intptr". > here's what I would expect: > General rule #1: If an instruction accepts both i32 and i64, then it > should accept iptr as well. If it only accepts i32, then it can > continue to only

Hi, How do "Pat" operands get matched? I am trying to follow the example given in http://llvm.org/docs/CodeGenerator.html#selectiondag-process In the latest trunk of ppcintrinfo.td following pattern is defined: def : Pat<(pre_store i32:$rS, iPTR:$ptrreg, iaddroff:$ptroff), (STWU $rS, iaddroff:$ptroff, $ptrreg)>; I understand that input operand list i.e. ins of

On 17 Mar 2015, at 13:11, Tyro Software <softwaretyro at gmail.com> wrote: > > As an alternative to fixing the "char == 8 bits" presumption would using non-uniform pointer types have been another possible approach, e.g. keep char as 8 bit but have char* encode both the word address and the byte location within it (i.e. one extra bit in this 16-bit case). Of course this is

On 1/15/2016 2:57 PM, Phil Tomson wrote: > > > I see the following in my SelectCode (in XSTGGenDGISel.inc): > > > /*2235*/ OPC_SwitchOpcode /*2 cases */, 27, > TARGET_VAL(XSTGISD::ADDR_NORMAL),// ->2266 > /*2239*/ OPC_RecordChild0, // #1 = $addr > /*2240*/ OPC_MoveChild, 0, > /*2242*/ OPC_CheckOpcode,

On Fri, 2012-09-14 at 13:10 -0500, Will Schmidt wrote: > Hi all, > > I've been poking at AsmParser support for powerpc64 > (ppc64-elf-linux-abi) and have run into some behavior I don't understand > with the ptr_rc references coming out of the PPC*.td files when > generating the asm-matcher files. > > For instance : > $ ./build/bin/llvm-tblgen

Hi, In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers. This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types. We've added a flag that can be set on a per-backend basis to turn this off. Our problem is perhaps a bit different form yours,

Hi Anitha, memri is just describing that the address contains two components, an immediate and a register, and how to handle them in the instruction printer. The STWU expects a memri operand, and that is what is passed from the Pat. Hope that helps, Sam On 07/04/2013 10:19, Anitha B Gollamudi wrote: > Hi, > > > How do "Pat" operands get matched? I am trying to follow

Hi, I've been hitting my head to wall two days now. This is practically my first contact with InstrInfo.td files. Is there any tutorial how to make this kind of stuff? Or should I just keep on studying Sparc and other backends? So I added new intrinsic to llvm/include/llvm/TCEInstrinsics.td: def int_tce_customop : Intrinsic<[llvm_void_ty, llvm_ptr_ty, llvm_vararg_ty], [],

David, thanks for your immediate response. Since iPTR is a reserved type for tablegen internal use, can you make a further explanation? On the other hand, it can be simply treated as a register class assignment problem during register allocation. Assume both pointer and integet have a 32 bit width. backend handles it just as to i32. When it performs register allocation, it can retrieve from