similar to: [LLVMdev] confused about float literals

On Apr 26, 2011, at 2:07 AM, Joe Armstrong wrote: > Compiles (via clang) to: > > ; ModuleID = 'test101.c' > target datalayout = > "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" > target triple = "i386-pc-linux-gnu" > > define i32 @main() nounwind { > %1 =

On Wed, Apr 27, 2011 at 12:51 AM, John McCall <rjmccall at apple.com> wrote: > On Apr 26, 2011, at 2:07 AM, Joe Armstrong wrote: >> Compiles (via clang) to: >> >>  ; ModuleID = 'test101.c' >>  target datalayout = >>

On Apr 27, 2011, at 1:03 AM, Joe Armstrong wrote: > But what is 0x400928F5C0000000? it is NOT the 64 bit representation > with the low order > 32 bits zeroed - it is the 62 bit representation with the low order 28 > bits zeroed. > > Why 28 bits? - 32 bits might be understandable but not 28. I bet the low 29 bits are zeroed. That is the difference between the 52 bit double

Hello, I have been using a very simple rbind approach (simple enough for me to understand) to combine data files within R. It seems to work fine, but then generates warning messages for reasons that I can't begin to understand. The text below shows the issue. testread12=read.table("C:/Files/Test100.txt", head = T) testread11=read.table("C:/Files/Test101.txt", head =

arrows() seems to hang when either x or y scale of the plot is logarithmic and the arrows requested go beyond the plot (by more than a certain amount). I didn't go into C code to find it, but here's a function that exercises the bug a bit ... arrow.bug2 <- function(y0=1,y1=10,log="y") { plot(c(0.1,1),c(1,10),log=log) arrows(x0=0.5, y0=y0, x1=0.5,

I have found a quite strange (to me) behaviour in Sweave. It only occurs in the following situation: 1. define a variable in one chunk 2. use it within a subsequent figure-generating chunk 3. delete it at the end of that same chunk Then the Sweave driver chokes, not finding the variable name when generating the figure Example: % document bug2.Rnw \documentclass{article} \usepackage{Sweave}

Mark and Joel, I found two serious bugs about xattr and inline-data. the first bug: in ocfs2_mknod(), we check and found the ACL or security xattr entry could be set into inode in ocfs2_calc_xattr_init(), then don't reserve block for them. But in ocfs2_mknod_locked(), if we found ocfs2 support inline-data, then set id_count with the max_inline_data. After that, we set acl/security xattr

This code is undefined, meaning that all bets are off, don't do it. I.e. It reads the value of I between two sequence points and uses it for something other than determining the value written. From: Csaba Raduly Sent: Tuesday, April 19, 2011 3:44 AM To: Joe Armstrong Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Is this a bug in clang? Hi Joe On Tue, Apr 19, 2011 at 10:59 AM, Joe

Hello, Is this a bug in clang, or a bug in my thinking? /Joe Armstrong /* When I compile the following program I get different answers in clang and gcc. $ gcc bug2.c $ ./a.out j = 40 $ clang bug2.c $ ./a.out j = 41 I think the correct answer is 41. If my understanding of C is correct (which, or course, it might not be) the incremented value of i++ is first made available

So... Are 40 and 41 the only legal behaviors or are there more? Robby On Tuesday, April 19, 2011, Ahmed Charles <ahmedcharles at gmail.com> wrote: > This code is undefined, meaning that all bets are off, don't do it. > I.e. It reads the value of I between two sequence points and uses it > for something other than determining the value written. From: Csaba > Raduly >

OK, I am just sending it here too as it looks like r-devel at r-project.org is not the right place: =EF=BB=BFOn Fri, 2008-04-25 at 08:48 +0200, Soeren Sonnenburg wrote: > While trying to fix swig & R2.7 I actually discovered that there is a > bug in R 2.7 causing a crash (so R & swig might actually work): >=20 > the bug is in ./src/main/gram.c line 3038: >=20 >

I have a data set for different time intervals. The data has three comment lines before data for each time interval. For each time interval there are 500 data points. I want to change the dataset such that I have the following format: t1 t2 t3 ................ 0.00208 0.00417 0.00625 ................. a1 a2 a3 ...................

Hi, This patch set fixes two bugs of splice_write in the virtio-console driver. [BUG1] Although pipe->nrbufs is empty, the driver tries to do splice_write. => This induces oops in sg_init_table(). [BUG2] No lock for competition of splice_write. => This induces oops in splice_from_pipe_feed() by bug of any user application. These reports are written in each

Hi, This patch set fixes two bugs of splice_write in the virtio-console driver. [BUG1] Although pipe->nrbufs is empty, the driver tries to do splice_write. => This induces oops in sg_init_table(). [BUG2] No lock for competition of splice_write. => This induces oops in splice_from_pipe_feed() by bug of any user application. These reports are written in each

While using Blindtransfer #Extension everything works fine. But how do i activate announced transfer with an Grandstream GPX2000 ? Greets Markus

While trying to fix swig & R2.7 I actually discovered that there is a bug in R 2.7 causing a crash (so R & swig might actually work): the bug is in ./src/main/gram.c line 3038: } else { /* over-long line */ fixthis --> char *LongLine = (char *) malloc(nc); if(!LongLine) error(_("unable to allocate space for source line %d"),

Hi list, are there preparations for upgrading a samba 4.8.5 to 4.9.1 via van-belle-repository to change the backend db? Is there some handwork necessary? Regards, Oliver

On 16/06/2017 2:04 PM, Radford Neal wrote: >> On Wed, 14 Jun 2017, G?bor Cs?rdi wrote: >> >>> I like the idea of string literals, but the C/C++ way clearly does not >>> work. The Python/Julia way might, i.e.: >>> >>> """this is a >>> multi-line >>> lineral""" >> >> luke-tierney at uiowa.edu:

Hi all Currently tablegen parses binary literals such as 0b011 and immediately turns them in to integers internally. Due to this, 0b011 is a 2-bit value because tablegen will happily drop leading zeroes on integers. I propose that we change this, and store binary literals with a size. I think this is much more natural, as when the user writes a value with 3 bits, I think they expect to get a

On Wed, Jun 14, 2017 at 8:48 AM, Simon Urbanek <simon.urbanek at r-project.org> wrote: > As I recall this has been discussed at least a few times (unfortunately I'm traveling so can't check the references), but the justification was never satisfactory. > > Personally, I wouldn't mind string continuation supported since it makes for more readable code (I had one of my