Hi Thomas, This is OK by me.
Is it worth testing the INTENT variants? Cheers Paul On Tue, 4 Aug 2020 at 20:03, Thomas Koenig via Fortran <fort...@gcc.gnu.org> wrote: > Hello world, > > the attached patch issues an error for something that I am sure most > people did at least once (I know I did), something like > > do i=1,10 > call foo > end do > ... > contains > subroutine foo > do i=1,5 > ... > end do > > which is, of course, illegal, but the programmer's fault. We issue an > error with -fcheck=all, but a compile-time is better, of course. > > As you can see from the modification of do_check_4.f90, you have to go > to some lengths to fool the compiler with this patch. > > As an aside, I could really have used three places for the error > message here. As is, I settled for the place of the call from > the DO loop checked, and the place where it is modified. With > the name of the variable, the user should be able to figure out > what's wrong. > > Regression-tested. OK for trunk? > > Best regards > > Thomas > > Static analysis for definition of DO index variables in contained > procedures. > > When encountering a procedure call in a DO loop, this patch checks if > the call is to a contained procedure, and if it is, check for > changes in the index variable. > > gcc/fortran/ChangeLog: > > PR fortran/96469 > * frontend-passes.c (doloop_contained_function_call): New > function. > (doloop_contained_procedure_code): New function. > (CHECK_INQ): Macro for inquire checks. > (doloop_code): Invoke doloop_contained_procedure_code and > doloop_contained_function_call if appropriate. > (do_intent): Likewise. > > gcc/testsuite/ChangeLog: > > PR fortran/96469 > * gfortran.dg/do_check_4.f90: Hide change in index variable > from compile-time analysis. > * gfortran.dg/do_check_4.f90: New test. > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
