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