On 28/02/2022 5:37 pm, Jakub Jelinek wrote:
On Mon, Feb 28, 2022 at 06:33:15PM +0100, Mikael Morin wrote:
It is true that the spots I saw in fortran/openmp.cc that test rank look
like:
if (!gfc_resolve_expr (el->expr)
|| el->expr->ts.type != BT_INTEGER || el->expr->rank != 0)
etc., so probably !gfc_resolve_expr call is missing.
As long as the expression is expected to not be a (contained) function call,
I think it should work.
In the general case non-syntaxic errors are preferably checked and reported
later at resolution stage, where contained functions are known.
Oh, I've missed that it is done during parsing and not during resolution.
That !gfc_resolve_expr call and the checking if it is BT_INTEGER etc.
should be certainly moved to resolve_omp_clauses.
Calling gfc_resolve_expr does not work to update the rank when called
from gfc_match_omp_detach:
(gdb) p *e->ref
$3 = {type = REF_ARRAY, u = {ar = {type = AR_ELEMENT, dimen = 0, codimen
= 1, in_allocate = false, team = 0x0, stat = 0x0, where = {nextc =
0x2e532d8, lb = 0x2e53260}, as = 0x2e04110, c_where = {{nextc = 0x0, lb
= 0x0} <repeats 15 times>}, start = {0x0 <repeats 15 times>}, end = {0x0
<repeats 15 times>}, stride = {0x0 <repeats 15 times>}, dimen_type =
{DIMEN_THIS_IMAGE, 0 <repeats 14 times>}}, c = {component = 0x2, sym =
0x1}, ss = {start = 0x2, end = 0x1, length = 0x0}, i = INQUIRY_KIND},
next = 0x0}
In gfc_expression_rank, e->ref is non-NULL, so e->rank is not set from
the symtree. It then iterates through the ref elements - ref->type ==
REF_ARRAY and ref->u.ar.type == AR_ELEMENT, so e->rank remains at 0.
I'll move the check to resolve_omp_clauses and see if it works there.
Thanks
Kwok
