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
