Displaying 5 results from an estimated 5 matches for "maxbsize".
Did you mean:
max_size
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.
Tha...
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