[PATCH] gdb: Check for not allocated/associated values during array slicing

[Andrew Burgess]

* Tom Tromey <tom@tromey.com> [2019-06-07 15:23:56 -0600]:

> >>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:
> 
> Andrew> When extracting an array slice we should give up if the array is
> Andrew> not-allocated or not-associated.  For Fortran, at least in gfortran
> Andrew> compiled code, the upper and lower bounds are undefined if the array
> Andrew> is not allocated or not associated, in which case performing checks
> Andrew> against these bounds will result in undefined behaviour.
> 
> Andrew> Better then to throw an error if we try to slice such an array.  This
> Andrew> changes the error message that the user will receive in these
> Andrew> cases (if they got an error message before).  Previously they may have
> Andrew> gotten "slice out of range" now they'll get "array not allocated" or
> Andrew> "array not associated".
> 
> I don't know Fortran, so I hesitated to comment on this patch.  But,
> maybe you are waiting for some feedback?  I don't have an objection to
> it, though that isn't super comforting considering that I don't know
> what an associated type is.

Pointer types are in an associated state when they are pointing at
something.  Being not associated is similar to being a nullptr.

Pointers can also be allocated, this means its had some space
dynamically allocated to it.  When a pointer is allocated it is also
associated with the space that was allocated.

Arrays declared as deferred shape (where the dimensions are given
simply as ':' rather than actual upper and lower bounds) can also be
allocated and/or associated, which is where this patch fits in.

In theory I think we could get away with only checking for associated,
as an allocated array will be associated with the space that was
allocated, however, it seemed more informative to check for the
allocated status first.

I'll go ahead and push this for now, if there's follow up feedback
then I'm happy to make adjustments later.

Thanks,
Andrew