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

[Bernhard Fischer <rep dot nop at aon dot at>]

On Sun, Oct 01, 2006 at 04:39:49PM +0200, Paul Thomas wrote:
>Salut FX,
>
>Oh yes, you are right. I'll have a look at each of these conditions.

[sorry, i added this question to the PR instead of here]

Just curious..
Why isn't this part of gfc_conv_function_call() coded to check for fsym
once
and only then have the additional checks?

if (fsym)
  {
    CHECKS_NOT_INVOLVING_e_BUT_fsym;
    if (e)
      {
        CHECK_e_STUFF;
      }
   }

It doesn't look like the order of most of these is significant since
very different things are checked, so there should be no risk in
writing this in a sleek manner. The alleged benefit is a potential
size-decrease for the gfortran binary, from my POV.

PS: Rob, this will fix the ICE you were seeing with optional assumed
length arguments (or however they are called).
thanks,
>
>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
>>
>>
>
>