This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, Fortran] PR fortran/45776: More variable definition checks
- From: Mikael Morin <mikael dot morin at sfr dot fr>
- To: fortran at gcc dot gnu dot org
- Cc: Jerry DeLisle <jvdelisle at frontier dot com>, Daniel Kraft <d at domob dot eu>, "gcc-patches" <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 24 Sep 2010 21:40:51 +0200
- Subject: Re: [Patch, Fortran] PR fortran/45776: More variable definition checks
- References: <4C9CD37E.2020602@domob.eu> <4C9CF5B5.2040203@frontier.com>
On Friday 24 September 2010 21:02:13 Jerry DeLisle wrote:
> On 09/24/2010 09:36 AM, Daniel Kraft wrote:
> > Hi,
> >
> > the attached patch implements the missing IO related variable definition
> > checks (which is now PR 45776). Except the LOCK/UNLOCK cases which can
> > not yet be implemented because locks are not yet in gfortran, the full
> > list of variable definition contexts of F2008, 16.6.7 should be
> > implemented with that.
> >
> > It fixes some accepts-invalid cases that my last patch created, but also
> > adds some checks that were missing before it. As a bonus, it adds a
> > F2008 check when using NEWUNIT (which was missing before).
> >
> > As I'm not really familiar with the IO related data-structures, I left
> > two XXX comments in the patch asking for possible better solutions (when
> > they exist), please take a look at them.
>
> The io_kind is set explicitly at higher level in the matchers.
Are you sure it is?
io.c:3671 has:
/* Save the iokind and locus for later use in resolution. */
dt->extra_comma = gfc_get_iokind_expr (&gfc_current_locus, k);
According to the comment, it is non-trivial to get the io kind at resolution
stage.
>
> match
> gfc_match_read (void)
> {
> return match_io (M_READ);
> }
>
>
> match
> gfc_match_write (void)
> {
> return match_io (M_WRITE);
> }
It seems io_kind (M_READ or M_WRITE) is not saved by match_io in the io
structures.
By the way, grepping for io_kind reveals that there is a io_kind member in the
gfc_expr struct only. Having one in gfc_dt (or one of the io structs) instead
makes more sense.
This is just my (not so humble) opinion.
Mikael