search for: alloc_sizes

Hi, I'm implementing the alloc_size function attribute in clang. This attribute exists in gcc since version 4.3. The attribute specifies that a function returns a buffer with the size given by the multiplication of the specified arguments. I would like to add new metadata to pass this information to LLVM IR. For example, take the following C code: void* my_calloc(size_t, size_t)

On 5/25/12 2:16 AM, Duncan Sands wrote: > Hi John, > >>>> I'm implementing the alloc_size function attribute in clang. >>> does anyone actually use this attribute? And if they do, can it >>> really buy >>> them anything? How about "implementing" it by ignoring it! >> > ... >> >> Currently, SAFECode has a pass which

Hi John, On 25/05/12 17:22, John Criswell wrote: > On 5/25/12 2:16 AM, Duncan Sands wrote: >> Hi John, >> >>>>> I'm implementing the alloc_size function attribute in clang. >>>> does anyone actually use this attribute? And if they do, can it really buy >>>> them anything? How about "implementing" it by ignoring it! >>>

Hi Nuno, > I'm implementing the alloc_size function attribute in clang. does anyone actually use this attribute? And if they do, can it really buy them anything? How about "implementing" it by ignoring it! Ciao, Duncan. This > attribute exists in gcc since version 4.3. > The attribute specifies that a function returns a buffer with the size > given by the

Hi John, >>> I'm implementing the alloc_size function attribute in clang. >> does anyone actually use this attribute? And if they do, can it really buy >> them anything? How about "implementing" it by ignoring it! > ... > > Currently, SAFECode has a pass which just recognizes certain functions as > allocators and knows how to interpret the arguments

On Fri, 25 May 2012 17:43:52 +0200 Duncan Sands <baldrick at free.fr> wrote: > Hi John, > > On 25/05/12 17:22, John Criswell wrote: > > On 5/25/12 2:16 AM, Duncan Sands wrote: > >> Hi John, > >> > >>>>> I'm implementing the alloc_size function attribute in clang. > >>>> does anyone actually use this attribute? And if

On Jun 4, 2012, at 10:37 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > So here is a new proposal: > > !0 = metadata !{ alloc_siz_fn, offset_fn, parameters* } The parameters are a separate metadata array or the alloc_size metadata is variable length? You'll probably want to write up some docs for the website on how this is supposed to be laid out and work. -eric

On 5/24/12 3:51 AM, Duncan Sands wrote: > Hi Nuno, > >> I'm implementing the alloc_size function attribute in clang. > does anyone actually use this attribute? And if they do, can it really buy > them anything? How about "implementing" it by ignoring it! Tools like ASan and SAFECode *could* use this attribute to determine the size of memory objects created by

>> On 25/05/12 17:22, John Criswell wrote: >> > On 5/25/12 2:16 AM, Duncan Sands wrote: >> >> Hi John, >> >> >> >>>>> I'm implementing the alloc_size function attribute in clang. >> >>>> does anyone actually use this attribute? And if they do, can it >> >>>> really buy them anything? How about

On Wed, 18 Apr 2018, Eric Dumazet wrote: > > > On 04/18/2018 07:34 AM, Mikulas Patocka wrote: > > The patch 74d332c13b21 changes alloc_netdev_mqs to use vzalloc if kzalloc > > fails (later patches change it to kvzalloc). > > > > The problem with this is that if the vzalloc function is actually used, > > virtio_net doesn't work (because it expects

On Wed, 18 Apr 2018, Eric Dumazet wrote: > > > On 04/18/2018 07:34 AM, Mikulas Patocka wrote: > > The patch 74d332c13b21 changes alloc_netdev_mqs to use vzalloc if kzalloc > > fails (later patches change it to kvzalloc). > > > > The problem with this is that if the vzalloc function is actually used, > > virtio_net doesn't work (because it expects

>>>> Currently, SAFECode has a pass which just recognizes certain functions as >>>> allocators and knows how to interpret the arguments to find the >>>> size. If we want >>>> SAFECode to work with another allocator (like a program's custom >>>> allocator, the >>>> Objective-C allocator, the Boehm garbage collector,

Hi, So here is a new proposal: !0 = metadata !{ alloc_siz_fn, offset_fn, parameters* } alloc_size_fn and offset_fn are functions that return either i32/i64 depending on the platform, and they must have the same number of arguments (not necessarily the same as the as allocation function). The parameters are given in the metadata as well. To accommodate the common case, offer_fn can be

Quoting Eric Christopher <echristo at apple.com>: > On Jun 4, 2012, at 10:37 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > >> So here is a new proposal: >> >> !0 = metadata !{ alloc_siz_fn, offset_fn, parameters* } > > The parameters are a separate metadata array or the alloc_size metadata > is variable length? Variable length. I think that's

On Tue, 29 May 2012 17:37:40 +0100 Nuno Lopes <nunoplopes at sapo.pt> wrote: > >> On 25/05/12 17:22, John Criswell wrote: > >> > On 5/25/12 2:16 AM, Duncan Sands wrote: > >> >> Hi John, > >> >> > >> >>>>> I'm implementing the alloc_size function attribute in clang. > >> >>>> does anyone

On Thu, May 24, 2012 at 7:43 PM, John Criswell <criswell at illinois.edu>wrote: > On 5/24/12 3:51 AM, Duncan Sands wrote: > > Hi Nuno, > > > >> I'm implementing the alloc_size function attribute in clang. > > does anyone actually use this attribute? And if they do, can it really > buy > > them anything? How about "implementing" it by

Hi All, I am a newbie to GPU programming. I wonder if anyone can help me with using GPU in .Call in R. Basically, I want to write a function that calcuates the sum of two double type vectors and implement this using GPU. My final goal is to make such an implementation callable from R. (a) First, I wrote a R-C interface handles the R object using .Call (saved as VecAdd_cuda.c

>> Hi, >> >> So here is a new proposal: >> >> !0 = metadata !{ alloc_siz_fn, offset_fn, parameters* } >> >> alloc_size_fn and offset_fn are functions that return either i32/i64 >> depending on the platform, and they must have the same number of >> arguments (not necessarily the same as the as allocation function). >> The parameters are

Hi Nuno, > So here is a new proposal: > > !0 = metadata !{ alloc_siz_fn, offset_fn, parameters* } > > alloc_size_fn and offset_fn are functions that return either i32/i64 > depending on the platform, and they must have the same number of > arguments (not necessarily the same as the as allocation function). > The parameters are given in the metadata as well. > To

>> So here is a new proposal: >> >> !0 = metadata !{ alloc_siz_fn, offset_fn, parameters* } >> >> alloc_size_fn and offset_fn are functions that return either i32/i64 >> depending on the platform, and they must have the same number of >> arguments (not necessarily the same as the as allocation function). >> The parameters are given in the metadata as