Re: [PATCH] PR fortrsn/101564 - ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169

[Tobias Burnus <tobias@codesourcery.com>]

Hi Harald,

On 22.07.21 21:50, Harald Anlauf wrote:
> I am afraid we're really opening a can of worms here....
which is not too bad if there are only two earthworms in there ;-)
>> Additionally, I wonder whether that will work with:
> I think a "working" testcase for this could be:
>
> program p
>    implicit none
>    integer, target  :: ptr
>    integer, pointer :: A
>    allocate (A, stat=f())
>    print *, ptr
> contains
>    function f()
>      integer, pointer :: f
>      f => ptr
>    end function f
> end
Indeed that I meant.
> This works as expected with Intel and AOCC, but gives a
> syntax error with every gfortran tested because of match.c:
>
> alloc_opt_list:
>        m = gfc_match (" stat = %v", &tmp);

I think we can simply change that one to %e; the definable
check should ensure that any non variable (in the Fortran sense)
is rejected.

And we should update the comment for %v / match_variable to state
that it does not include function references.

In some cases, like with OpenMP, we still do not want to match
functions, hence, changing match_variable is probably not what we
want to do. Additionally, for all %v replaced by %e we need to
ensure that there is a definable check. (Which should be there
already as INTENT(IN) or named constants or ... are also invalid.)

Also affected: Some I/O items, a bunch of other stat=%v and
errmsg=%v.

Talking about errmsg: In the same function, the same check is
done for errmsg as for stat – hence, the patch should update
also errmsg.

>> Additionally, I have to admit that I do not understand the
>> following existing condition, which you did not touch:
>>
>>         if ((stat->ts.type != BT_INTEGER
>>              && !(stat->ref && (stat->ref->type == REF_ARRAY
>>                                 || stat->ref->type == REF_COMPONENT)))
>>             || stat->rank > 0)
>>           gfc_error ("Stat-variable at %L must be a scalar INTEGER "
>>                      "variable", &stat->where);
>>
>> I mean the ts.type != BT_INTEGER and stat->rank != 0 is clear,
>> but what's the reason for the refs?
> Well, that needs to be answered by Steve (see commit 3759634).

(https://gcc.gnu.org/g:3759634f3208cbc1226bec19d22cbff989a287c3 (svn
r145331))

The reason for the ref checks is unclear and seem to be wrong. The added
testcases also only use 'x' (real) and n or i (integer) as input, i.e.
they do not exercise this. I did not look for the patch email for reasoning.

Thanks,

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955