Thanks for the rapid responses Martin, Steve. I'll quickly take this
off blackdown due to its non-Linux relevance. I thought I would point
out the following though:
If you insert an actual executable hunk of code into the if block,
things work properly. Eg, consider
class foo
{
void bar (Object o)
{
if (o.getClass() == Object.class)
{
Integer p // = new Integer(5)
;
}
}
}
As written, this generates the internal compiler error, since the simple
allocation
of reference p doesn't require runtime execution. However, uncomment the
initializer ( = new Integer(5)), and the internal compiler error
disappears.
The act of invoking new() seems to force the compiler to follow a
clean path, as opposed to a dirty one.
Looking at this, my guess is that the problem is caused by some
optimization
dealing with parameters on the stack. When the optimization is forcibly
turned
off, the problem goes away.
OK, I'll stop annoying you all. I guess I was just intrigued think about
what kind of internal optimization path could possibly account for these
unlikely stimuli turning on or off the behaviour.
Ron
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
