[Patch, fortran] PR29284 - [4.1/4.2 Regression] ICE for optional subroutine argument

[Paul Thomas]

Salut FX,

Oh yes, you are right. I'll have a look at each of these conditions.

Paul

> Hi Paul,
>
>> In testing for an actual argument that is an assumed character length 
>> procedure, I did not test if the expression for the argument is NULL. 
>> This, of course, happens if an optional argument is not present and 
>> an ICE ensues for not doing the check. The testcase is that provided 
>> by the author.
>
>
> Doesn't the same problem happen with the block of code above the one 
> you fixed, ie
>
> /* If an INTENT(OUT) dummy of derived type has a default
> initializer, it must be (re)initialized here. */
> if (fsym && fsym->attr.intent == INTENT_OUT && fsym->ts.type == 
> BT_DERIVED
> && fsym->value)
> {
> gcc_assert (!fsym->attr.allocatable);
> tmp = gfc_trans_assignment (e, fsym->value);
> gfc_add_expr_to_block (&se->pre, tmp);
> }
>
> I think the following code exhibit this behaviour:
>
> MODULE foo
> TYPE T
> INTEGER :: I = 1
> END TYPE T
>
> TYPE(T),PARAMETER :: TT = T(1)
> CONTAINS
> SUBROUTINE sub1(a)
> TYPE(T), OPTIONAL, INTENT(OUT) :: a
> WRITE(*,*) 'foo bar'
> END SUBROUTINE sub1
> SUBROUTINE sub2
> CALL sub1()
> END SUBROUTINE sub2
> END MODULE foo
>
>
> Due to my limited knowledge of these matters (derived types), I'm not 
> sure this is allowed, although I think it is. Could you comment on 
> this? If this code is indeed legal, I think simply changing the 
> condition into "if (e && ...)" would also be correct there. I'm in no 
> position to regtest this last change right now, because my tree is in 
> an awful mess as I'm finalizing my patch for intrinsics as actual 
> arguments.
>
> Thanks,
> FX
>
>