Re: PR 28416 (was: Re: ICE on PR20541 - allocatable components of derived types (TR15581))

[Paul Thomas <paulthomas2 at wanadoo dot fr>]

Salvatore,

> May I ask one dumb question? 
> You are certainly working to solve the case where TR15581 is available,
> and the compiler should accept the code. 
> Hovewer, suppose the user requests strict F95 compliance, the compiler
> should reject the code without going into ICE. 
> Shouldn't the fix be dependent on the standard level to be enforced? 
>
>  
Try to pass allocatable arguments or return allocatable results with 
-std=f95.  Thanks to a miracle of electric computers, you get

 integer, allocatable :: v_out(:)
                             1
Error: In the selected standard, ALLOCATABLE attribute conflicts with 
DUMMY attribute at (1)

That's for free - it was already checked in gfortran-3.5.  Once that 
error is emitted, the compiler does not try to go any further and so the 
ICE does not occur.

Paul

PS It's not a dumb question.  If any of these F95+ features get past 
-std=f95, that will be a bug.  A call to MOVE_ALLOC, for example, 
generates an unrequited reference to a subroutine of that name.

PPS Yes, my pre-vacation version of the TR15581 patch has been posted on 
PR20541.  As well as the allocatable component stuff, there are fixes 
for your two problems, a resolution of the cleanup deallocating 
components of pointers and ulimate pointer components and a reasonably 
well sorted version of MOVE_ALLOC.  The latter isn't in the right place 
in its final resting place in the library but it works just fine.   I 
have not looked up the standard on it but I have excluded all but 
variables form the 'FROM' argument.  In principle, function results 
would be OK but it doesn't make much sense.