I'm not actually sure whether the following code should compile or not (whether
it's valid LLVM assembly), but it certainly shouldn't produce the output it
currently does. I would expect the code to either run through the blocks
A->C->B->C->A->C->...  or for llvm-as to give a syntax error.

Input (test.ll):

int %main() {
A:
    br label %C
B:
    br label %C
C:
    %next = phi label [%B, %A], [%A, %B]
    br label %next
}

Output (llvm-as test.ll):

llvm-as: /home/andrew/misc/llvm/include/Support/Casting.h:194: typename
cast_retty<To, From>::ret_type cast(const Y&) [with X = BasicBlock, Y = Value*]:
Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
Aborted

Workaround (?):

int %main() {
A:
    br label %C
B:
    br label %C
C:
    %next = phi bool [false, %A], [true, %B]
    br bool %next, label %A, label %B
}

That's not valid LLVM code, because label's aren't "first class" types.  In
other words, it not legal to produce values which are of label type.

This is still a bug however, because the llvm assembler should never crash like
that.  I'll fix it to output a happy little error message.  :)

-Chris

Here are the clarifications to the documentation:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20031027/008974.html

Here is the change to the parser:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20031027/008975.html

And here is a bugfix to the "isFirstClassType" predicate that this made obvious:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20031027/008976.html

The testcase now produces:
$ llvm-as test.ll
llvm-as: test.ll:8: PHI node operands must be of first class type!

Thanks for noticing this!

-Chris

Thanks, that was quick. :)

Reading over your documentation update I see one tiny, niggling issue though,

"Only labels be used as the label arguments."
=> "Only labels _may_ be used as the label arguments."

Indeed!
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20031027/008979.html

Thanks!

-Chris