[Patch, fortran] PR29422 and PR29428 - allocatable component wrinkles

[Brooks Moses]

Paul Thomas wrote:
> Richard,
>>Ah, yes. I forgot about that distinction, but you are correct. I  
>>regarded it as an oddity of the TR that the complicated case  
>>(assignment with an allocatable component) was covered, but the  
>>corresponding simpler case (assignment of an allocatable without  
>>components being involved) was omitted. It seems so "obvious" that  
>>one would do the simple case first, but I forgot that we didn't. That  
>>is I forgot until you reminded me.
> 
> I wondered about that whilst we were developing the allocatable 
> component patch. Since I could see no reference to it in TR15581, I 
> assumed that there was some reason for its omission:
> 
> It would be no big deal to add it, as an F2003 extension.  However, it 
> would come at a price: the code to perform the assignment would have to 
> be loaded with the statements to detect whether or not there is memory 
> allocated to the lhs, whether it is sufficient to receive the rhs and to 
> do the dellocation/allocation, if necessary.  I concluded that this was 
> the reason for the omission.

There should be no meaningful price at runtime, I would think, at least 
as far as speed is concerned.  In my opinion, we should already be 
checking at runtime whether the lhs and rhs of an array assignment are 
conformable, and whether the lhs (if an allocatable) is allocated.

(At present, the former is ignored -- potentially causing out-of-bounds 
errors that -fbounds-check doesn't catch (!) -- and the latter gives a 
segfault.)

Now, the only things that are changed by this F2003 extension are what 
happens when those checks fail, and so the only additional costs above 
the checks we need anyway should occur after a failure has been detected.

> I guess that it should be something that 
> happens only if standard -f2k is selected, rather than being disallowed 
> if it is not?

At present, I believe that there's a pretty strict hierarchy of what's 
permitted with the various -std= options, such that legacy is a superset 
of gnu is a superset of f2003 is a superset of f95.  It would be at the 
least rather inconvenient to break this, such that one could only get 
this feature if one turned off gnu extensions.

An alternate solution would be to add a gnu2003 standard option (which 
is a superset of both f2003 and gnu), but I don't really see the point 
in not putting all f2003 extensions into -std=gnu.

- Brooks