similar to: [LLVMdev] malloc(), free(), and alloca() with zero size

On Oct 6, 2007, at 9:14 AM, Jon Sargeant wrote: > If <NumElements> is zero, what is the behavior of malloc() and > alloca()? > Can I call free() using the pointer that malloc() returns? alloca is not standard. The behavior of malloc is covered in 7.20.3p1: If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or

Dale Johannesen wrote: > On Oct 6, 2007, at 9:14 AM, Jon Sargeant wrote: > >> If <NumElements> is zero, what is the behavior of malloc() and >> alloca()? >> Can I call free() using the pointer that malloc() returns? > > alloca is not standard. > The behavior of malloc is covered in 7.20.3p1: > > If the size of the space requested is zero, the

Chris Lattner wrote: > On Apr 19, 2008, at 3:27 PM, Jon Sargeant wrote: >>>> Regarding malloc and alloca, I realized that the size is unsigned, >>>> so a >>>> negative value for NumElements is impossible. I suggest replacing >>>> "it >>>> is the number of elements allocated" with "it is the UNSIGNED number

Thanks for your reply. Chris Lattner wrote: >> Regarding free, I also think your wording isn't clear enough: "If the >> pointer is null, the result is undefined." The free result is void. >> Consider rewording as "If the pointer is null, the operation is valid >> but does not free the pointer." > > It isn't though. free(NULL) could

Chris Lattner wrote: > On Mon, 31 Mar 2008, Jon Sargeant wrote: >> I'm attaching another round of changes. Please verify that they are correct. > > Applied with edits: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080331/060556.html > > I figured out what your patches don't apply. Something (your web browser, > editor, etc) is stripping

On Apr 19, 2008, at 3:27 PM, Jon Sargeant wrote: >>> Regarding malloc and alloca, I realized that the size is unsigned, >>> so a >>> negative value for NumElements is impossible. I suggest replacing >>> "it >>> is the number of elements allocated" with "it is the UNSIGNED number >>> of >>> elements allocated".

Jon Sargeant wrote: > Chris Lattner wrote: >> On Mon, 31 Mar 2008, Jon Sargeant wrote: >>> I'm attaching another round of changes. Please verify that they are correct. >> Applied with edits: >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080331/060556.html >> >> I figured out what your patches don't apply. Something (your web

Joachim Durchholz wrote: > Am Samstag, den 19.04.2008, 16:24 -0700 schrieb Jon Sargeant: >> First, I can assign -1 to >> the count to indicate an invalid or unknown value. > > This is a C-ism. In a language that supports discriminated unions well, > you'd do something like > type AllocaCount = Invalid | Unknown | Known int > (where Invalid, Unknown and Known

On Apr 1, 2008, at 6:41 PM, Jon Sargeant wrote: > Chris Lattner wrote: >> On Mon, 31 Mar 2008, Jon Sargeant wrote: >>> I'm attaching another round of changes. Please verify that they >>> are correct. >> >> Applied with edits: >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080331/060556.html >> > Hmm, I realized that the

Hi all, Quoting <http://llvm.org/docs/LangRef.html#i_malloc>: The 'malloc' instruction allocates sizeof(<type>)*NumElements bytes of memory from the operating system and returns a pointer of the appropriate type to the program. If "NumElements" is specified, it is the number of elements allocated. Obviously this does not say that the default for NumElements

Hi, This is quite a simple question so hopefully it's easy to answer. I was looking at the documentation for the alloca instruction ( http://llvm.org/docs/LangRef.html#alloca-instruction ) and something is unclear to me. The given syntax is... <result> = alloca <type>[, <ty> <NumElements>][, align <alignment>] ; yields {type*}:result And the documentation

The fptrunc instruction states "If the value cannot fit within the destination type, ty2, then the results are undefined." This is fine, but what about other floating-point operations that can overflow? For example, does 'mul double 1.0e300, 1.0e300' produce +infinity or is it undefined? I think LLVM should treat floating-point overflows consistently. On a similar note,

On Mon, 31 Mar 2008, Jon Sargeant wrote: > I'm attaching another round of changes. Please verify that they are correct. Applied with edits: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080331/060556.html I figured out what your patches don't apply. Something (your web browser, editor, etc) is stripping trailing whitespace. -Chris -- http://nondot.org/sabre/

Am Samstag, den 19.04.2008, 16:24 -0700 schrieb Jon Sargeant: > First, I can assign -1 to > the count to indicate an invalid or unknown value. This is a C-ism. In a language that supports discriminated unions well, you'd do something like type AllocaCount = Invalid | Unknown | Known int (where Invalid, Unknown and Known are the constants that do the distinction between union

Thanks for the reply. Please see my inline responses. On 15/08/13 12:58, Tim Northover wrote: > Hi Dan, > >> It is not stated how the "<ty>" type is used as we are told the >> type of result is type* and sizeof(<type>)*NumElements is the >> amount of memory so from my perspective it looks like <ty> is >> never used which would seem to

In alloca, is it required that NumElements be a literal integer, or can it be a computed result? The real question is whether the current IR can support a one-stack implementation of Ada's dynamically sized stack frames. shap

Am Sonntag, den 20.04.2008, 09:34 -0700 schrieb Jon Sargeant: > Joachim Durchholz wrote: > > Am Samstag, den 19.04.2008, 16:24 -0700 schrieb Jon Sargeant: > >> First, I can assign -1 to > >> the count to indicate an invalid or unknown value. > > > > This is a C-ism. In a language that supports discriminated unions well, > > you'd do something like

Currently, the alloca instruction always allocates in the generic address space (0). This proposal is to extend the semantics of alloca instruction to allow allocation in any specified address space. Proposed Syntax <result> = alloca [inalloca] <type> [, <ty> <NumElements>] [, align <alignment>] [, addrspace <num>] ; yields type addrspace(num)*:result

Please see inline. From: Chandler Carruth [mailto:chandlerc at google.com] Sent: Wednesday, August 26, 2015 7:03 PM To: Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>; llvm-dev <llvm-dev at lists.llvm.org>; Philip Reames <listmail at philipreames.com>; Sanjoy Das <sanjoy at playingwithpointers.com> Subject: Re: [llvm-dev] RFC: alloca -- specify address space for

Hello, I found saw some strange behavior (to me) when converting constant arrays to strings. Consider the following example: std::string Text = "HelloWorld"; unsigned TextLengthBefore = Text.length(); ConstantArray *pArray = dyn_cast<ConstantArray>(llvm::ConstantArray::get(pModule->getContext(), Text, true)); unsigned NumElements = pArray->getNumOperands(); Text =