similar to: [LLVMdev] Imprecise description of malloc instruction

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

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

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

If <NumElements> is zero, what is the behavior of malloc() and alloca()? Can I call free() using the pointer that malloc() returns? Also, I'm assuming that free()ing a null pointer is a legal NOP? Regards, Jon

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

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

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".

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

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

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 =

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

Hi, I haven't seen a response and I'm curious if I should submit a patch for this. Thanks, Javier From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Martinez, Javier E Sent: Friday, July 16, 2010 3:20 PM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] Strange behavior when converting arrays to strings Hello, I found saw some strange behavior (to

Now I believe that I am getting the same error as I was getting last time I tried to build llvm-gcc. It may possibly be my Cygwin instillation but am not sure. makeinfo --split-size=5000000 -I ../../../src/llvm-gcc/gcc/doc -I ../../../src/ llvm-gcc/gcc/doc/include \ -o ../../../src/llvm-gcc/gcc/doc/cpp.info ../../../src/llvm-gcc/gcc/doc/cpp.texi ' in

Seeing a problem with a certain user causing dovecot to crash when copying mail to a folder. This looks similar to a bug someone on the mailing list posted recently. Since the backtrace mentions the index, I tried deleting all of the index files for the user (including subfolders) but it had no effect. Seems that the bug still happens when creating the index for the first time.

Hi Javier, > 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)); from

Hi Aaron, have you got any help on this? Henrik >From: "Aaron Gray" Date: Sat, 14 May 2005 18:26:01 +0100 > >Now I believe that I am getting the same error as I was getting last time I >tried to build llvm-gcc. >It may possibly be my Cygwin instillation but am not sure. > > >makeinfo --split-size=5000000 -I ../../../src/llvm-gcc/gcc/doc -I >../../../src/

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

>Hi Aaron, >have you got any help on this? Henrik, No. This is where I was stuck some months ago. I do not know makeinfo so was not able to proceed any thurther than verifying the makeinfo statement did the same thing when done on the command line. Basically I am stuck. I do not know whether it was my Cygwin configuration or something I have done or not done or whether it is a valid