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: Bernhard Fischer <rep dot nop at aon dot at>
- To: Paul Thomas <paulthomas2 at wanadoo dot fr>
- Cc: FX Coudert <fxcoudert at gmail dot com>, "'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, Rob <lahaye at skku dot edu>
- Date: Sun, 1 Oct 2006 17:36:42 +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> <451FD335.firstname.lastname@example.org>
On Sun, Oct 01, 2006 at 04:39:49PM +0200, Paul Thomas wrote:
>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]
Why isn't this part of gfc_conv_function_call() coded to check for fsym
and only then have the additional checks?
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).
>>>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