This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, fortran] PR29284 - [4.1/4.2 Regression] ICE for optional subroutine argument
- From: Paul Thomas <paulthomas2 at wanadoo dot fr>
- To: FX Coudert <fxcoudert at gmail dot com>
- Cc: "'fortran at gcc dot gnu dot org'" <fortran at gcc dot gnu dot org>, patch <gcc-patches at gcc dot gnu dot org>, rakuen_himawari at yahoo dot co dot jp
- Date: Sun, 01 Oct 2006 16:39:49 +0200
- Subject: Re: [Patch, fortran] PR29284 - [4.1/4.2 Regression] ICE for optional subroutine argument
- References: <451FC5F8.email@example.com> <2EEDE911-8D55-42D2-A57C-A0DD4CF9B3B8@gmail.com>
Oh yes, you are right. I'll have a look at each of these conditions.
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 ==
tmp = gfc_trans_assignment (e, fsym->value);
gfc_add_expr_to_block (&se->pre, tmp);
I think the following code exhibit this behaviour:
INTEGER :: I = 1
END TYPE T
TYPE(T),PARAMETER :: TT = T(1)
TYPE(T), OPTIONAL, INTENT(OUT) :: a
WRITE(*,*) 'foo bar'
END SUBROUTINE 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