Re: [patch, fortran] Compile-time check for change in DO variable in contained procedures

2020-08-05 Thread Thomas Koenig via Gcc-patches
Hi Paul, I must say that I was thinking rather more of the INTENT(IN) case to make sure that it is accepted. Ah, I misunderstood that. You're right - also check legal code :-) I've committed the attached test case as obvious (after verifying that it passes. It checks against functions and su

Re: [patch, fortran] Compile-time check for change in DO variable in contained procedures

2020-08-05 Thread Paul Richard Thomas via Gcc-patches
I must say that I was thinking rather more of the INTENT(IN) case to make sure that it is accepted. Paul On Wed, 5 Aug 2020 at 17:41, Thomas Koenig wrote: > Hi Paul, > > > This is OK by me. > > Committed (or should I say "pushed"?), thanks! > > > Is it worth testing the INTENT variants? > > I

Re: [patch, fortran] Compile-time check for change in DO variable in contained procedures

2020-08-05 Thread Thomas Koenig via Gcc-patches
Hi Paul, This is OK by me. Committed (or should I say "pushed"?), thanks! Is it worth testing the INTENT variants? I added a test for INTENT(INOUT), here's the version of the test case that was committed. Best regards Thomas program main implicit none integer :: i1, i2, i3, i

Re: [patch, fortran] Compile-time check for change in DO variable in contained procedures

2020-08-05 Thread Paul Richard Thomas via Gcc-patches
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 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 >

[patch, fortran] Compile-time check for change in DO variable in contained procedures

2020-08-04 Thread Thomas Koenig via Gcc-patches
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