>>>>> "Richard" == Richard Guenther <[EMAIL PROTECTED]> writes:
Richard> On 6/4/05, Bryce McKinlay <[EMAIL PROTECTED]> wrote: >> I've just done an x86_64 build of HEAD and didn't see this error. Richard> Hm, ok - it seems changing java/parse.y:build_if_else_statement Richard> to not construct a COND_EXPR with NULL_TREE type, but Richard> void_type_node causes this. Any idea why? Do you really get a valid build if you do this? It seems like it would short-circuit patching the COND_EXPR, which would show up as crashes later on. The way gcj's .java parsing/analysis code works in general is that it has two passes. When parsing (the first pass), it constructs trees whose TREE_TYPE is NULL_TREE. Then later there is an analysis pass where it goes back and fills in all the types. Some other modifications are made as well. Your original failure was odd in that it doesn't make sense to see an IDENTIFIER_NODE during the definite assignment analysis (this is what check-init.c is doing). More context might help. Like, go up a frame or two and see why check_init is being passed an IDENTIFIER_NODE. Tom
