This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Don't generate NullPointerExceptions for arraylength and arrayload


Ranjit Mathew writes:
 > Andrew Haley wrote:
 > > This removes the special case code that throws a NullPointerException
 > > bease on the type of an arrayref.  This trick no longer works because
 > > in the bytecode front end we now use the same variable decl for every
 > > object.  In ancy case, this optimization just provided a fast path to
 > > throw a NullPointerException.
 > > 
 > > This is a regression from 3.x.
 > 
 > [...]
 > 
 > > -  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?

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

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.

I'm interested to know whether people think we should make these loads
volatile.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]