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

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

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.

Hello, I'm trying to develop a way to reliably clean the LLVMContext in order to make it possible to use it multiple times. LLVMContext itself is an almost empty object delegating almost all its content to LLVMContextImpl. This makes it very clean ideally, because clearing the LLVMContext would be as easy as deleting the LLVMContextImpl and creating a new one. The problem is that for some

Hello, i want to work with these types v32f32, v32f64.... in llvm which are undefined in the backend? But v32i32, v32i64 are already defined so i am able to use these. but for other types such as v32f32, v32f64 although i have defined them appropriately in all the files like machinevaluetype.h, valuetypes.cpp etc. i have checked it many times but still getting the following error when build in

Hi, So, we currently have gc.result.int, gc.result.float. gc.result.ptr, gc.relocate, and gc.statepoint. gc.statepoint's signature is fine with a iPTRAny as the first argument. gc.result is in trouble, because none of the signatures admit even a simple array of integers, and there's no aAny. And certainly no vectors. So we can get a gc.result.vector to add to this mess, and admit [1] to

I've patched valuetypes.td/h to add data types that my backend needs to support. There seems to be a lot of assumptions made in other spots of the code that limit the number of data types to 32. I need to add a few more types, but once I go over this limit llvm starts acting wonky. I found all the items that are hard coded to 32 and a section that isn't, but I cannot figure out how to

Thank you so much. it run fine. Can you please resolve following issue; I now have support for v2048i32 but my backend supports v64i32 so ultimately v2048i32 needs to be split into 32 v64i32 instructions. the only difference between 2 is if its orginally v2048i32 i want my registers assignment from REG_A set. if its v64i32 originally, then i want registers from set REG_B. How to accomplish

On Aug 9, 2009, at 8:37 AM, Chris Lattner wrote: > I really do think that bitcast is the right way to go here. I ran > into a couple of similar problems when bringing up the altivec port. > For example, at one time we'd get "all zero vectors" of different > MVTs, which would not be CSEd. > > The fix for this was to be really disciplined about what types to make

I am working on an implementation that needs to add a couple of overloaded intrinsics (based on pointer to different address spaces). I am creating a new myintrinsics.td file and using the iPTRAny for the argument type. The current interface (i.e. getName() and getTyp() in Intrinsics.h) seems to require the caller to know which arguments are used for overloading, so to set Tys and numTys. This

Hi, On Tuesday, June 24, 2014 15:18:51 Marcello Maggioni wrote: > I'm trying to develop a way to reliably clean the LLVMContext in order to > make it possible to use it multiple times. > > LLVMContext itself is an almost empty object delegating almost all its > content to LLVMContextImpl. > This makes it very clean ideally, because clearing the LLVMContext would be > as

I would be very grateful if you specify whether there is some way to allocate registers (different order) / from different register sets to the same instruction based on the vector width/ no of iterations. I have tried several alternatives but could not succeed. Also I have asked this question many times but no one responds. Is there something wrong with this?? Kindly guide me. Thank You On

Hi Bob, An alternative would be to model the operations as regular shuffle, load, and store operators, combined to describe the actual instructions. This would make them easier for target-independent code to understand. Dan On Aug 8, 2009, at 11:47 PM, Bob Wilson <bob.wilson at apple.com> wrote: > The ARM Neon load, store and shuffle operations that I've been >

On Aug 8, 2009, at 11:47 PM, Bob Wilson wrote: > The ARM Neon load, store and shuffle operations that I've been > implementing recently with LLVM intrinsics do not care about the > distinction between vectors with i32 and f32 elements -- only the size > matters. But, because we have only MVT::fAny and MVT::iAny types, > I've been having to define separate intrinsics for

On Aug 9, 2009, at 6:29 AM, Dan Gohman wrote: > Hi Bob, > > An alternative would be to model the operations as regular shuffle, > load, and store operators, combined to describe the actual > instructions. This would make them easier for target-independent code > to understand. Yes, I have tried to do that as much as possible. There are still a number of operations where

The ARM Neon load, store and shuffle operations that I've been implementing recently with LLVM intrinsics do not care about the distinction between vectors with i32 and f32 elements -- only the size matters. But, because we have only MVT::fAny and MVT::iAny types, I've been having to define separate intrinsics for the operations with floating-point vector elements. It

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, I'm running an 8E1 setup to an SS7 carrier. The setup works but when we start hitting the 80 active calls mark the link became unstable. I found a lot of the following messages afecting my d channel Jun 25 15:49:55 ostional kernel: [385661.368857] dahdi: HDLC Receiver overrun on channel TE4/0/1/31 (master=TE4/0/1/31) Im using TE410P dahdi-linux-2.4.1.2.tar.gz dahdi-tools-2.4.1.tar.gz

We recently upgraded our NT4 Domain to Win2k. We use Samba 2.0.7 running on Solaris 2.6 servers. We are getting buffer overuns in the log files when running 'domain_client_validate' which appears to be due to extensive group membership (SID History is not being used). Are there any patches/fixes available to get round this problem? Thankyou in anticipation. Regards, Rich Sprigg

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ========================================================== == == Subject: Stack buffer overflow in nmbd's logon == request processing. == == CVE ID#: CVE-2007-4572 == == Versions: Samba 3.0.0 - 3.0.26a (inclusive) == == Summary: Processing of specially crafted GETDC == mailslot requests can result in a