Le 21/11/2022 à 19:46, Steve Kargl a écrit :
On Mon, Nov 21, 2022 at 11:34:07AM +0100, Mikael Morin wrote:
Le 21/11/2022 à 00:31, Steve Kargl via Fortran a écrit :
Unfortunately, gfortran does not define a namespace for an implied-do
index and uses a kludge by adding the attr.implied_index attribute to
the symbol. Unfortunately**2, gfortran uses gfc_match_iterator for
all places that 'i = start, stop [,step]' and there is no way to know
if what is being parsed. With the introduction of an optional typespec,
there is no easy way to deal with it in a clean way. Things get messy
quickly when trying to deal with implicit typing and explicitly typed
symbols. So, if the implied-do index has previously been typed such as
integer(8) i
print *, (i, integer(2) i=1, 3)
the integer(2) is ignored. That's this part of the gfc_match_iterator
diff
+ if (seen_ts && var->ts.type == BT_UNKNOWN)
+ {
+ var->ts.type = ts.type;
+ var->ts.kind = ts.kind;
+ var->symtree->n.sym->ts.type = ts.type;
+ var->symtree->n.sym->ts.kind = ts.kind;
+ }
Perhaps, a better way would be to simply create a shadow symbol
if a typespec appears in an iterator
print *, (i, integer i=1,3)
would become
print *, (_i, integer _i=1,3)
The issue is then that implied-do object list needs to be walked
and all occurrence of i must be replaced with _i.
Or maybe a namespace could be created if seen_ts is true?
Yes, I thought about creating a new namespace, but I don't
have too much experience on how to deal with them. Even
with a new namespace, we have to deal with an implied-do
loop in an initialization expression. At the moment,
gfc_reduce_init_expr() does recognize some (all?) implied-do
loops.
This is legal code, which uses implicit typing. Here,
I get an integer type, but gfc_reduce_init_expr() rejects
the construct.
program foo
use iso_fortran_env, only : k => real_kinds
integer, parameter :: n = size(k)
integer, parameter ::p(n) = [(digits(real(1.,k(i))),i = 1,n)]
print '(*(I0,X))', p
end program foo
% gfortran -o z a.f90
a.f90:6:30:
6 | & p(n) = [(digits(real(1.,k(i))), i = 1, n)]
| 1
Error: Invalid kind for REAL at (1)
I have looked at it, it is a tricky bug.
The first step of gfc_check_init_expr, way before trying to expand the
array constructor, is to resolve it. Resolution of the array
constructor needs resolution of the ac-value expression, which needs
resolution of the real(...) expression. Resolution of that expression
calls gfc_check_real, which checks that the KIND argument is a valid
kind, which means among other things being constant, and being able to
extract its value to check it against the list of defined kinds for the
platform. And we can't extract its value before the expansion of the
array constructor, so the error is emitted, which prevents array
constructor expansion later on.
So it's a kind of chicken and egg problem.
Right now, I don't see any solution (except simply removing the error).
