This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]