This is the mail archive of the mailing list for the GNU Fortran 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

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


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