[Bug fortran/61933] New: Inquire on internal units

[Bug fortran/61933] New: Inquire on internal units

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

            Bug ID: 61933
           Summary: Inquire on internal units
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Joost.VandeVondele at mat dot ethz.ch

It would be nice if the the following code

> cat test.f90
   LOGICAL :: file_exists
   INQUIRE(UNIT=-1,EXIST=file_exists)
   WRITE(6,*) file_exists
END

would error out at runtime, since

F2008:
If le-unit-number identies an internal unit (9.6.4.8.3), an error condition
occurs.

F2003:
The value of file-unit-number shall be nonnegative or equal to one of the named
constants INPUT UNIT,
9 OUTPUT UNIT, or ERROR UNIT of the ISO FORTRAN ENV intrinsic module (13.8.2).

The Cray compiler generates an error in this case:

lib-4017 : UNRECOVERABLE library error
  The INQUIRE statement must not specify an internal file.

[Bug fortran/61933] Inquire on internal units

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-08-28
     Ever confirmed|0                           |1

--- Comment #2 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
The specific case should be caught at compile time like this as well as
runtime.

$ gfc pr61933.f90 
pr61933.f90:7.69:

   INQUIRE(UNIT=-1,EXIST=file_exists, iostat=istat, iomsg=errormess) 
                                                                     1
Error: UNIT in INQUIRE statement at (1) must be positive

[Bug fortran/61933] Inquire on internal units

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

--- Comment #3 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Thu Jan 15 03:51:16 2015
New Revision: 219630

URL: https://gcc.gnu.org/viewcvs?rev=219630&root=gcc&view=rev
Log:
2015-01-14  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

    PR fortran/61933
    * io.c (gfc_match_inquire): Generate error if unit number in
    inquire statement is a constant -1.  All other values allowed.
    * trans-io.c (gfc_trans_inquire): Delete dummy iostat variable.
    (create_dummy_iostat): Delete function no longer used.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/io.c
    trunk/gcc/fortran/trans-io.c

[Bug fortran/61933] Inquire on internal units

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

--- Comment #4 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Thu Jan 15 03:57:29 2015
New Revision: 219631

URL: https://gcc.gnu.org/viewcvs?rev=219631&root=gcc&view=rev
Log:
2015-01-14  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

    PR libgfortran/61933
    * io/inquire.c (inquire_via_unit): Set existing to true if a
    gfc_unit stucture was found for the given unit number.
    * runtime/error.c (translate_error): Add case for
    LIBERROR_INQUIRE_INTERNAL_UNIT.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/inquire.c
    trunk/libgfortran/runtime/error.c

[Bug fortran/61933] Inquire on internal units

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

--- Comment #5 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Thu Jan 15 04:06:02 2015
New Revision: 219632

URL: https://gcc.gnu.org/viewcvs?rev=219632&root=gcc&view=rev
Log:
2015-01-14  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

    PR target/61933
    * gfortran.dg/inquire_internal.f90: New.
    * gfortran.dg/negative_unit_check.f90: New.

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

[Bug fortran/61933] Inquire on internal units

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

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

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

--- Comment #6 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Fixed on trunk.

[Bug fortran/61933] Inquire on internal units

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

--- Comment #7 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
Hi Jerry,

thanks for the fix, but this seems to break code to find a free unit, like
such:

MODULE M
CONTAINS
  FUNCTION get_unit_number(file_name) RESULT(unit_number)

    CHARACTER(LEN=*), INTENT(IN), OPTIONAL   :: file_name
    INTEGER                                  :: unit_number

    INTEGER                                  :: ic, istat, nc
    LOGICAL                                  :: exists, is_open

    ! Get a new unit number
    DO unit_number=10,100
       INQUIRE (UNIT=unit_number,EXIST=exists,OPENED=is_open,IOSTAT=istat)
       IF (exists.AND.(.NOT.is_open).AND.(istat == 0)) RETURN
    END DO

    unit_number = -1

  END FUNCTION get_unit_number
END MODULE

USE M
  write(6,*) "unit to use: ",get_unit_number("foo.dat")
END


This will now always return -1, while it used to return a free unit.

[Bug fortran/61933] Inquire on internal units

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

--- Comment #8 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
You might notice that we redefined existence to be whether or not it is
connected.  Units get connected when opened so your sample code needs only ask:

IF ((.NOT.is_open).AND.(istat == 0)) RETURN

Whether this is what we really want to do of course is open to discussion.

The other definition for existence is .true. for all units except -1 which is
moot because -1 will give an error and the test for existence is always .true.
and not needed.  Also unit existence is processor dependent.

In your opinion, should we change it to the other definition?  Unit existence
is sort of a nebulous situation.  Will your code be more portable without the
test for existence?

[Bug fortran/61933] Inquire on internal units

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

--- Comment #9 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
(In reply to Jerry DeLisle from comment #8)
> You might notice that we redefined existence to be whether or not it is
> connected.  Units get connected when opened so your sample code needs only
> ask:
> 
> IF ((.NOT.is_open).AND.(istat == 0)) RETURN
> 
> Whether this is what we really want to do of course is open to discussion.
> 
> The other definition for existence is .true. for all units except -1 which
> is moot because -1 will give an error and the test for existence is always
> .true. and not needed.  Also unit existence is processor dependent.
> 
> In your opinion, should we change it to the other definition?  Unit
> existence is sort of a nebulous situation.  Will your code be more portable
> without the test for existence?

The code in comment #7 worked on all compilers we had access to (and is part of
our released code since ages), so this change of behaviour would be a problem.

I think unless gfortran has a maximum for the allowed unit numbers, any postive
unit number should exist (i.e. can possibly be used in an open statement). 

Since:
> cat test.f90
open(UNIT=HUGE(1_16))
END
yields:
> ./a.out
At line 1 of file test.f90
Fortran runtime error: Unit number in I/O statement too large
that would be a unit that doesn't exist.

[Bug fortran/61933] Inquire on internal units

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

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

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

--- Comment #10 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
It occurs to me another possible interpretation of what a unit existence might
be.

Behind the scenes when opening a unit with no filename we create a file named
for example fort.10.  That file name is processor dependent and the user should
not know what that filename is. (we know by convention of course)

I wonder now whether we should define unit existence to be whether or not the
corresponding file (or device, or whatever it is....) exists on the system. 
This starts to make some sense when you think about it and could assist a user
from inadvertently overwriting some existing data.

I am going to reopen this for further discussion.  I do agree with your issue.

[Bug fortran/61933] Inquire on internal units

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

--- Comment #11 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
(In reply to Jerry DeLisle from comment #10)
> It occurs to me another possible interpretation of what a unit existence
> might be.
> 
> Behind the scenes when opening a unit with no filename we create a file
> named for example fort.10.  That file name is processor dependent and the
> user should not know what that filename is. (we know by convention of course)
>
> I wonder now whether we should define unit existence to be whether or not
> the corresponding file (or device, or whatever it is....) exists on the
> system.  This starts to make some sense when you think about it and could
> assist a user from inadvertently overwriting some existing data.

I don't think this is the intended behavior. I really think the meaning rather
is, can we in principle open a file on that unit number (like from the good old
days, is a tape drive mechanically connected to it). 

I'm reading the F2008 standard, and the guidance given in 9.5.3 is not much...
However, external files and external units seem to be conceptually quite
different (see also note 9.16)

> 
> I am going to reopen this for further discussion.  I do agree with your
> issue.

thanks also for your efforts in fixing these things!

[Bug fortran/61933] Inquire on internal units

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

--- Comment #12 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to Joost VandeVondele from comment #11)

See patch here:

https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01616.html

[Bug fortran/61933] Inquire on internal units

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

--- Comment #13 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
(In reply to Jerry DeLisle from comment #12)
> (In reply to Joost VandeVondele from comment #11)
> 
> See patch here:
> 
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01616.html

Thanks! One minor nit for the testcase,

inquire (unit=i, exist=l, iostat=i)

I guess this kind of aliasing of i is strictly speaking not OK?

[Bug fortran/61933] [5 Regression] Inquire on internal units

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Inquire on internal units   |[5 Regression] Inquire on
                   |                            |internal units

--- Comment #14 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
I'm adding the regression marker for the problem related to finding existing
units in the current trunk (comment #7), as is appropriate for the current
stage.

[Bug fortran/61933] [5 Regression] Inquire on internal units

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

--- Comment #15 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Fri Jan 23 01:59:23 2015
New Revision: 220023

URL: https://gcc.gnu.org/viewcvs?rev=220023&root=gcc&view=rev
Log:
2015-01-22  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

    PR fortran/61933
    * libgfortran.h:
    * trans-io.c (set_parameter_value): Delete use of has_iostat.
    Redefine to not generate any runtime error check calls.
    (set_parameter_value_chk): Rename of the former
    set_parameter_value with the runtime error checks and fix
    whitespace. (set_parameter_value_inquire): New function that
    builds a runtime conditional block to set the INQUIRE
    common parameter block unit number to -2 when unit numbers
    exceed positive KIND=4 limits. (gfc_trans_open): Whitespace.
    For unit, use the renamed set_parameter_value_chk.
    (gfc_trans_close): Likewise use renamed function.
    (build_filepos): Whitespace and use renamed function.
    (gfc_trans_inquire): Whitespace and for unit use
    set_parameter_value and set_parameter_value_inquire.
    (gfc_trans_wait): Remove p->iostat from call to
    set_parameter_value. Use new set_parameter_value_chk for unit.
    (build_dt): Use the new set_parameter_value without p->iostat
    and fix whitespace. Use set_parameter_value_chk for unit.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/libgfortran.h
    trunk/gcc/fortran/trans-io.c

[Bug fortran/61933] [5 Regression] Inquire on internal units

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

--- Comment #16 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Fri Jan 23 02:01:10 2015
New Revision: 220024

URL: https://gcc.gnu.org/viewcvs?rev=220024&root=gcc&view=rev
Log:
2015-01-22  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

    PR libgfortran/61933
    * io/inquire.c (inquire_via_unit): Set existing to true for
    any negative unit that is currently connected and any positive
    units within range of KIND=4 value.  The unit value for any out
    of range case that may occur if the user is using a KIND=8 will
    have been set to -2 which is reserved and can never be opened,
    and therefore the unit does not exist.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/inquire.c

[Bug fortran/61933] [5 Regression] Inquire on internal units

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

--- Comment #17 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Fri Jan 23 02:06:17 2015
New Revision: 220025

URL: https://gcc.gnu.org/viewcvs?rev=220025&root=gcc&view=rev
Log:
2015-01-22  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

    PR fortran/61933
    * gfortran.dg/negative_unit_int8.f: Update.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/negative_unit_int8.f

[Bug fortran/61933] [5 Regression] Inquire on internal units

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

--- Comment #18 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Fixed on trunk. I am going to add a test case in the testsuite for the example
in Comment #7 before I close this.

[Bug fortran/61933] [5 Regression] Inquire on internal units

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

--- Comment #19 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Fri Jan 23 03:37:30 2015
New Revision: 220026

URL: https://gcc.gnu.org/viewcvs?rev=220026&root=gcc&view=rev
Log:
2015-01-22  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

    PR fortran/61933
    * gfortran.dg/make_unit.f90: New test.

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

[Bug fortran/61933] [5 Regression] Inquire on internal units

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933

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

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

--- Comment #20 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Closing