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

Paul Thomas paulthomas2@wanadoo.fr
Mon Oct 2 22:42:00 GMT 2006


FX,

I believe that the attached answers all the concerns.

It regtests on FC5/Athlon - OK for trunk and 4.1?

Paul

2006-10-03  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/29284
    * trans-expr.c (gfc_conv_function_call): Check the expression
    and the formal symbol are present when testing the actual
    argument.

2006-10-03  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/29284
    * gfortran.dg/optional_assumed_charlen_1.f90: New test.

    PR fortran/29321
    PR fortran/29322
    * gfortran.dg/missing_optional_dummy_2.f90: New test.


>> 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
>>
>>
>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr29284.diff
Type: text/x-patch
Size: 5546 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20061002/3a97e850/attachment.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Change.Logs
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20061002/3a97e850/attachment.ksh>


More information about the Fortran mailing list