This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, fortran] PR23232 - DATA implied DO variables
On Thu, Jan 04, 2007 at 04:42:29PM +0100, Paul Richard Thomas wrote:
> Bother! Please find attached a patch without the modification to
> interface_7.f90
>
> Paul
>
> On 1/4/07, Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:
> >:ADDPATCH fortran:
> >
> >This patch came about as I was tidying up and putting to bed the
> >ongoing work on PRs, for others to follow up. I had written this some
> >months ago but could not get it to handle error conditions without
> >segfaulting. I noticed what this was due to this morning.....
> >blush.....
> >
> > gfc_error ("Beginning of message at %L followed by ",
> > "end of message", &expr->where);
> >
> >I was completely blind to the errant comma and put the patch to one
> >side.... more blushing.... Since it is error_on_valid, I thought it
> >best to submit it myself, since I am up to speed on it.
> >
> >Beyond this, the fix is straight forward. Since the iterators are not
> >available, whilst gfc_match_init_expr and check_init_expr are doing
> >their respective things, the appearance of variable expressions for
> >the iterator start, end or steps causes errors. The way around this
> >is to signal that we are matching a data statement and use this to
> >avoid checking for variable references. In this way, all the other
> >good things happen, like checking for inquiry functions, etc. The
> >expressions then go on to resolve.c, where in looping through the
> >iterators, they are copied and simplified. Since the iterators are on
> >the iterator stack, simplification now works and EXPR_CONSTANTs are
> >produced. The previous check that iterator expressions were constant
> >has now been removed. The testcase is a rejigging of the reporter's;
> >the array is reduced in size so that the correct emplacement of the
> >values can be checked.
> >
> >Regtested on PIV/Cygwin_NT - OK for trunk and, in a week, for 4.2?
> >
Paul, I believe the patch is ok with one comment below.
Do you want me to commit it for you?
> mpz_init (frame.value);
>
> ! start = gfc_copy_expr (var->iter.start);
> ! end = gfc_copy_expr (var->iter.end);
> ! step = gfc_copy_expr (var->iter.step);
>
> ! if (gfc_simplify_expr (start, 1) == FAILURE
> ! || start->expr_type != EXPR_CONSTANT)
> ! {
> ! gfc_error ("iterator start at %L does not simplify",
> ! &start->where);
If we return here, do we need to free start, end, and step? It
seems to me that this could be a memory leak.
> ! return FAILURE;
> ! }
--
Steve