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

[Salvatore Filippone <salvatore dot filippone at uniroma2 dot it>]

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? 

Regards 
Salvatore

Il mar, 2006-07-18 alle 13:46, THOMAS Paul Richard 169137 ha scritto:
> Salvatore,
> 
> This is quite revealing of the cause:
> 
>  subroutine foo(v_out)
> 
>    integer, allocatable :: v_out(:)
> 
>    interface
>      subroutine bar (arg)
>         integer, allocatable :: arg(:)
>      end subroutine bar
>    end interface
> 
>    call bar(v_out)
>    call foobar(v_out)
> 
>  end subroutine foo
> 
> The ICE only occurs on the second reference to v_out.
> 
> In the presence of a formal symbol, gfortran does the right thing.
> The reason is that in trans-array.c(gfc_conv_array_parameter), the
> case where g77 is set is not correctly handled in the first block
> of code in this function for allocatable arrays that are dummy
> arguments.  The if statement needs to be replaced by:
> 
>       if (sym->attr.allocatable)
>         {
>           if (sym->attr.dummy)
>             se->expr = tmp;
>           else
>             se->expr = gfc_conv_array_data (tmp);
>           return;
>         }
> 
> It produces:
> 
> foo (v_out)
> {
>   bar ((struct array1_int4 *) v_out);
>   foobar (v_out);
> }
> 
> which looks OK.
> 
> I have just now set it to regtest.  However, I am not going to
> be able to submit a patch and work it through the system. Erik,
> could you do the honours, please?
> 
> Paul