Null pointer check elimination

Joe Buck Joe.Buck@synopsys.COM
Mon Nov 14 17:31:00 GMT 2005


On Sun, Nov 13, 2005 at 04:29:26AM -0500, Robert Dewar wrote:
> Richard Guenther wrote:
>> >And this is why there seemed to be consensus to merge the two in the
> >middle-end and preserve debug-info somehow differently. Like with
> >a "frontend type-id" on the decl. That would allow lowering of f.i.
> >integral types to their modes at some point, too.
>> It seems a clear mistake to me to tie debug information so closely
> to the actual gcc type information, and this is another example
> of it causing unnecessary trouble.

It seems that there are two separate attributes that distinguish reference
types from pointer types ...
1) auto-dereferencing: debuggers interpret a.field, where a is a
 reference, as dereference(a).field. This is a feature that both
 C++ and Fortran want.
2) in C++, references are assumed never to be null. My Fortran is very
 rusty (I wrote vast amounts of Fortran in the 80s, but those brain
 cells are mostly gone), but I had naively assumed that the same was
 true in Fortran-land, however there appear to be some cases where it
 is not true. But even in Fortran, it seems there are many cases where
 we know that references cannot be null.
(There may be other implicit attributes as well).
Maybe the middle end should only have one pointer type, but with at
least two attributes, one to tell the debugger to auto-dereference,
one to mark those pointers that cannot point to null. This might enable
more optimization.


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /