search for: sargeant

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

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 &g...

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

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,

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

...have to do this many, many times and each run will involve up to several thousand records, so you can see my problem. I should think that others must surely have encountered and overcome this challenge. If anyone can kindly point me in a productive direction, I will be most grateful. ----- Glen Sargeant Research Wildlife Biologist -- View this message in context: http://r.789695.n4.nabble.com/Bivariate-kernel-density-bandwidth-selection-tp3080753p3080753.html Sent from the R help mailing list archive at Nabble.com.

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

...18 21 09/20/06 20:00:00 (09/20/06 20:00:00) 20 22 09/20/06 21:00:00 (09/20/06 21:00:00) 21 23 09/20/06 22:00:00 (09/20/06 22:00:00) 21 24 09/20/06 23:00:00 (09/20/06 23:00:00) 23 This behavior is problematic if one wants to extract hours and use them to group data. Regards, Glen Sargeant

Here is a patch containing all but one of the changes. I realized that the remainder/modulo discussion does indeed belongs to the srem instruction. The semantics of urem are obvious and need no further clarification. Best Regards, Jon 1572,1573c1572,1575 < notation (see below). Floating point constants must have a <a < href="#t_floating">floating point</a>

I'm designing a language that supports array slicing. Does LLVM allows conversions between array pointers? For example, can I cast a pointer-to-array-of-5-ints to a pointer-to-array-of-3-ints? Can I get the address of the third element of an array-of-5-ints and convert it to a pointer-to-array-of-3-ints? Then again, I suppose a pointer-to-int would work just as well since LLVM

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

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

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

On Mon, 31 Mar 2008, Jon Sargeant wrote: > 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'...

Chris Lattner wrote: > On Apr 1, 2008, at 6:41 PM, Jon Sargeant 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 pointe...

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

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

On Mar 31, 2008, at 5:07 PM, Jon Sargeant wrote: > Gordon Henriksen wrote: >> Hi Jon, >> Please you'll want to submit patches as unified diffs and as >> attachments. >> I notice you're using Thunderbird, so I refer you to this tip: >> http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-January/01199...

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

Gordon Henriksen wrote: > Hi Jon, > > Please you'll want to submit patches as unified diffs and as > attachments. > > I notice you're using Thunderbird, so I refer you to this tip: > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-January/011992.html > > Although this note doesn't apply to how you included your original > patch (looks like you