Re: Don't generate NullPointerExceptions for arraylength and arrayload

[Andrew Haley <aph at redhat dot com>]

Ranjit Mathew writes:
 > >  > > -  if (type == ptr_type_node)
 > >  > > -    return build3 (CALL_EXPR, int_type_node,
 > >  > > -                  build_address_of (soft_nullpointer_node),
 > >  > > -                  NULL_TREE, NULL_TREE);
 > >  > > -
 > >  >
 > >  > Doesn't doing this make "Array_3 -O3 bytecode -> native"
 > >  > fail for you?
 > 
 > Now that you've committed it, it does for me.
 > 
 > > No.  We already discussed this in
 > > http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00465.html.
 > > 
 > > I already answered this question in
 > > http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00746.html
 > 
 > Yes. I'm not that far down the slope of senility yet
 > to have forgotten such a recent discussion. :-)

Ah, good.  I wondered, because it seemed like exactly the same
question...

 > > It's possible that the code I removed in this latest patch was
 > > papering over the real bug, and so Array_3 triggers now where it
 > > didn't before.
 > 
 > "If a tree falls in a forest and no one hears it, does it make a
 > sound?" :-)
 > 
 > In other words, if you access a variable and do not use it, does it
 > not allow an aggressively optimising compiler to remove the access?

There are too many negatives in that sentence for my poor brain.

In general, an aggressively optimising compiler is allowed to remove
such loads, but the JLS doesn't permit it.

 > Is this not similar to removing empty loops?

It is, yes.

 > My personal belief is that a compiler should be allowed to do so
 > and we should put in an "xfail-at-O3" for this testcase and get on
 > with our lives.

Yes, but we can't guarantee that it will always fail, so we would get
spurious XPASSes.  I guess what we need is an "XDONTCARE"  :-)

 > > I'm interested to know whether people think we should make these loads
 > > volatile.
 > 
 > IMHO, no. (Though I haven't read the JLS,
 > JSR-133, etc. carefully for this bit...)

OK, ta.

Andrew.