[Bug fortran/47583] New: Inquire affected by previous read

[Bug fortran/47583] New: Inquire affected by previous read

[harald at klimachs dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583

           Summary: Inquire affected by previous read
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: harald@klimachs.de


Created attachment 23205
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23205
Minimal example

The use of inquire seems to be affected by a previous read, in the same file,
even if in a totally different scope. Attached is a minimal module illustrating
this.

There is a subroutine, reading some data unformatted, followed by another one
which inquires the IO length of an array with intent(in).

Compilation results in the following output:

gfortran-mp-4.6 -v -save-temps -c testinquire.f90 
Using built-in specs.
COLLECT_GCC=gfortran-mp-4.6
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.6-20110108/configure --prefix=/opt/local
--build=x86_64-apple-darwin10 --libdir=/opt/local/lib/gcc46
--includedir=/opt/local/include/gcc46 --infodir=/opt/local/share/info
--mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.6
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-4.6 --with-gxx-include-dir=/opt/local/include/gcc46/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local
--enable-stage1-checking --disable-multilib --enable-fully-dynamic-string
--enable-languages=c,c++,objc,obj-c++,fortran
Thread model: posix
gcc version 4.6.0 20110108 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.6' '-v' '-save-temps' '-c'
'-mtune=core2'
 /opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/f951 testinquire.f90 -fPIC
-quiet -dumpbase testinquire.f90 -mmacosx-version-min=10.6.6 -mtune=core2
-auxbase testinquire -version -fintrinsic-modules-path
/opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/4.6.0/finclude -o testinquire.s
GNU Fortran (GCC) version 4.6.0 20110108 (experimental) (x86_64-apple-darwin10)
    compiled by GNU C version 4.6.0 20110108 (experimental), GMP version 5.0.1,
MPFR version 3.0.0-p8, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.6.0 20110108 (experimental) (x86_64-apple-darwin10)
    compiled by GNU C version 4.6.0 20110108 (experimental), GMP version 5.0.1,
MPFR version 3.0.0-p8, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
testinquire.f90:20.25:

     inquire(iolength=rl) sizedat
                         1
Error: Dummy argument 'sizedat' with INTENT(IN) in variable definition context
(item in READ) at (1)


If the order of the subroutines is changed, that is, if the read appears after
the inquire statement, the code is compiled as expected.

At least in gfortran 4.4 this issue was not present.

[Bug fortran/47583] Inquire affected by previous read

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
      Known to work|                            |4.3.6, 4.4.6, 4.5.3

--- Comment #1 from kargl at gcc dot gnu.org 2011-02-01 22:16:52 UTC ---
Slightly reduced test case.

subroutine input(indat)
   real indat(:)
   read(*,*) indat
end subroutine input

subroutine abc(sizedat)
   real, intent(in) :: sizedat(:)
   integer :: rl
   inquire(iolength=rl) sizedat
   write(*,*) rl
end subroutine abc

[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot
                   |                            |gnu.org
   Target Milestone|---                         |4.6.0
            Summary|Inquire affected by         |[4.6 Regression] Inquire
                   |previous read               |affected by previous read

--- Comment #2 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-02-02 03:09:28 UTC ---
Confirmed, the code compiles with 4.5, making this a regression.

[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read

[harald at klimachs dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583

--- Comment #3 from Harald Klimach <harald at klimachs dot de> 2011-02-02 06:04:07 UTC ---
The problem also exists with scalars and integers instead of reals.

[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read

[harald at klimachs dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583

--- Comment #4 from Harald Klimach <harald at klimachs dot de> 2011-02-02 06:14:58 UTC ---
Further reduced test case:


subroutine input()
   read(*,*)
end subroutine input

subroutine abc(sizedat)
   integer, intent(in) :: sizedat
   integer :: rl
   inquire(iolength=rl) sizedat
end subroutine abc

(now tested with gcc version 4.6.0 20110201 (experimental) [trunk revision
169504] (GCC) on Linux)

[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read

[jpr at csc dot fi]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583

jpr at csc dot fi changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jpr at csc dot fi

--- Comment #5 from jpr at csc dot fi 2011-02-02 07:12:16 UTC ---

Possible (untested) fix. The ext.dt field in io/match_inquire()'s code
variable is a leftover from previous io matching (set in match_io_element()).
This triggers the bug in resolve_transfer(). There is even a comment there, 
that indicates that this field should be null for INQUIRE (iolength), thus:


Index: io.c
===================================================================
--- io.c        (revision 169506)
+++ io.c        (working copy)
@@ -3933,6 +3933,7 @@

       new_st.block = gfc_get_code ();
       new_st.block->op = EXEC_IOLENGTH;
+      code->ext.dt = NULL;
       terminate_io (code);
       new_st.block->next = code;
       return MATCH_YES;

[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read

[harald at klimachs dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583

--- Comment #6 from Harald Klimach <harald at klimachs dot de> 2011-02-02 08:04:30 UTC ---
(In reply to comment #5)
Thanks a lot, at least for me this patch seems to solve the problem.

[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
                 CC|                            |jakub at gcc dot gnu.org

[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read

[jpr at csc dot fi]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583

--- Comment #7 from jpr at csc dot fi 2011-02-02 12:48:37 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> Thanks a lot, at least for me this patch seems to solve the problem.

Well, that patch did break the direct_io_1.f90 test case however,
as the ext.dt member setting overwrote the ext.iterator member (when
there was implied do loop in the inquire(iolength=) statement). 

This might be better:

Index: io.c
===================================================================
--- io.c        (revision 169506)
+++ io.c        (working copy)
@@ -3091,7 +3091,8 @@
   cp = gfc_get_code ();
   cp->op = EXEC_TRANSFER;
   cp->expr1 = expr;
-  cp->ext.dt = current_dt;
+  if (k != M_INQUIRE)
+    cp->ext.dt = current_dt;

   *cpp = cp;
   return MATCH_YES;

[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.02.03 05:36:04
                 CC|                            |pault at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #8 from Paul Thomas <pault at gcc dot gnu.org> 2011-02-03 05:36:04 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > Thanks a lot, at least for me this patch seems to solve the problem.
> 
> Well, that patch did break the direct_io_1.f90 test case however,
> as the ext.dt member setting overwrote the ext.iterator member (when
> there was implied do loop in the inquire(iolength=) statement). 
> 
> This might be better:

It's nice to see a fresh email address! Do you have commit rights or should one
of Jerry or I do the honours for you?  I would feel more comfortable if it was
Jerry, so that he can cast an expert eye over this.  I do not think that I have
visited io.c for about 5 years :-(

Thanks

Paul

[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583

--- Comment #9 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-02-09 05:17:51 UTC ---
I will test and commit the patch.  Thanks.

[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583

--- Comment #10 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-02-09 06:07:18 UTC ---
Author: jvdelisle
Date: Wed Feb  9 06:07:14 2011
New Revision: 169962

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169962
Log:
2011-02-08  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

    PR fortran/47583
    * gfortran.dg/inquire_14.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/inquire_14.f90
Modified:
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #11 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-02-09 06:11:39 UTC ---
Fixed, thanks for bug report.

[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read

[harald at klimachs dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583

--- Comment #12 from Harald Klimach <harald at klimachs dot de> 2011-02-09 06:37:02 UTC ---
(In reply to comment #11)

Thanks a lot for taking the time to properly incorporate the fix!

[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583

--- Comment #13 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-02-09 15:47:26 UTC ---
There is some debate whether or not I did this properly.  I was rushing last
night, cobbled the PR number in the email subject, omitted the patch to the
mailing list, left the pr number off the Changlog entry ... I hope I did not
break the build and I apologize for any inconveniance I caused.  I posted this
here because I do not have regular email at my work location which is quite
remote at the moment.

Cheers everyone and I will do better next time.  ;)

(The service is free, as in free beer)