search for: maxbsiz

Displaying 5 results from an estimated 5 matches for "maxbsiz".

Did you mean: maxdsiz
2008 Nov 20
1
[LLVMdev] Problem in CodeExtractor::severSplitPHINodes()
...inator." So, the terminator of the newBB is exactly the same as the terminator of the oldBB. IF the oldBB has multiple successors, then newBB will have multiple successors. Actually there is an example for this (in "wc", the word count program): for (gotsp = 1; len = read(fd, buf, MAXBSIZE);){ if (len == -1) { perror(file); exit(1); } // do other stuff } Compiled with llvm-gcc -O1, the loop header has three successors: one to inside the loop, one to outside the loop, and the third to a block that contains exit(1). ExtractLoop() has problem with this this example. Th...
2008 Nov 20
0
[LLVMdev] Problem in CodeExtractor::severSplitPHINodes()
On Nov 19, 2008, at 7:41 AM, Jack Tzu-Han Hung wrote: > Hi, > > I found a problem in CodeExtractor::severSplitPHINodes() > <CodeExtractor.cpp>. > > The algorithm first separates the header block into two, one > containing only PHI nodes and the other containing the remaining non- > PHI nodes. The variable NewBB holds the pointer to the latter half > block.
2008 Nov 19
2
[LLVMdev] Problem in CodeExtractor::severSplitPHINodes()
Hi, I found a problem in CodeExtractor::severSplitPHINodes() <CodeExtractor.cpp>. The algorithm first separates the header block into two, one containing only PHI nodes and the other containing the remaining non-PHI nodes. The variable NewBB holds the pointer to the latter half block. Later, it tries to update DT information. if (DT) DT->splitBlock(NewBB); In splitBlock, it checks
2006 Nov 17
1
gjournal on 6.x wont build
Hi all, I was intending on trying out gjournal on a new disk i've added in my desktop. I had a look to see what the most recent patch provided by Pawel and found http://people.freebsd.org/~pjd/patches/gjournal6_20061024.patch I created the directories as per Pawel's original post (http://lists.freebsd.org/pipermail/freebsd-fs/2006-June/001962.html) and the patch succeeded with no failed
2013 Jul 24
1
NFS deadlock on 9.2-Beta1
Two machines (NFS Server: running ZFS / Client: disk-less), both are running FreeBSD r253506. The NFS client starts to deadlock processes within a few hours. It usually gets worse from there on. The processes stay in "D" state. I haven't been able to reproduce it when I want it to happen. I only have to wait a few hours until the deadlocks occur when traffic to the client machine