This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, Fortran, OOP] PR 52552: ICE when trying to allocate non-allocatable object giving a dynamic type
On Fri, Jun 08, 2012 at 07:10:02PM +0200, Janus Weil wrote:
> >> [Side note: The piece of code which I'm moving contains a FIXME
> >> comment, which I don't quite understand, so I'm not sure whether it is
> >> still valid. It was added by Steve in
> >> http://gcc.gnu.org/viewcvs?view=revision&revision=145331. Does anyone
> >> have an opinion on this?]
> >>
> >
> > It's been too long! ?I believe Tobias is
> > right that the FIXME had to do allocatable
> > components and a walking one or more
> > link list.
>
> Thanks for the comment, Steve. If your FIXME is supposed to mean what
> I think it is, then this is being taken care of already by the part
> labeled 'b1': For more complicated expressions (involving components
> and/or array elements), the check is deferred to
> 'resolve_allocate_expr'.
>
> Of course it would be nice to unify both checks, but I guess at
> parsing stage not everything can be checked, and if we only do it at
> resolution stage, then the ICE from the present PR becomes a problem
> again, so maybe we just leave the two checks for now.
>
> Attached is a third version of the patch, which I will commit soon. It
> adds at least the relevant standard reference to the resolution-stage
> check, too, and fixes the regressions resulting from the changed error
> message.
I suppose the FIXME comment needs to be updated to
explain why the b1, b2, and b3 checks are done. But,
it has been too long ago when I last played with
allocate(), and the code has gotten much more
complicated.
> > ? allocate(a(1)%z(1)%x(42)) ? ! a(1)%z(1) not allocated, no error
>
> Detecting this would require some run-time checking, which could
> become quite involved, I guess.
Runtime checking might be possible. But, for a code that
hits a bus error, one can run it under valgrind to find
the problem.
--
Steve