Re: [PATCH, libfortran] PR 48587 Newunit allocator

2016-10-18 Thread Janne Blomqvist 
On Tue, Oct 18, 2016 at 12:09 PM, Steven Bosscher  wrote:
> On Thu, Oct 13, 2016 at 5:16 PM, Janne Blomqvist wrote:
>> +static bool *newunits;
>
> You could make this a bitmap (like sbitmap). A bit more code but makes
> a potentially quadratic search (when opening many units) less time
> consuming.

I did think about that, yes, but decided that it wasn't worth the
extra complexity since

a) The OS typically limits the number of fd's per process to a
relatively small number (typically 1024 by default).

b) For better or worse, in libgfortran a unit is a quite big
structure, not to mention the 8 kB buffer. So obsessing over wasting
an extra 7 bits per unit seemed pointless.

c) Due to the newunit_lwi, in many scenarios it should be able to skip
scanning over, if not all then at least most of, the in-use units. Of
course, it's possible to design a scenario which defeats the lwi, but,
is that something real software does? And even if it does, due to a)
above I think the effect would be quite modest anyway.



-- 
Janne Blomqvist

Re: [PATCH, libfortran] PR 48587 Newunit allocator

2016-10-18 Thread Steven Bosscher 
On Thu, Oct 13, 2016 at 5:16 PM, Janne Blomqvist wrote:
> +static bool *newunits;

You could make this a bitmap (like sbitmap). A bit more code but makes
a potentially quadratic search (when opening many units) less time
consuming.

Ciao!
Steven

[PATCH, libfortran] PR 48587 Newunit allocator, cleanup

2016-10-16 Thread Janne Blomqvist 
Improve error message, and remove a redundant check, as the same check is
done a bit earlier due to the PR 48587 patch.

2016-10-16  Janne Blomqvist  

PR libfortran/48587
* io/transfer.c (data_transfer_init): Improve error message,
remove redundant check.

Regtested on x86_64-pc-linux-gnu. Committed as obvious.
---
 libgfortran/io/transfer.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 7696cca..2232417 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -2606,7 +2606,8 @@ data_transfer_init (st_parameter_dt *dtp, int read_flag)
   /* This means we tried to access an external unit < 0 without
 having opened it first with NEWUNIT=.  */
   generate_error (>common, LIBERROR_BAD_OPTION,
- "Invalid unit number in statement");
+ "Unit number is negative and unit was not already "
+ "opened with OPEN(NEWUNIT=...)");
   return;
 }
   else if (dtp->u.p.current_unit->s == NULL)
@@ -2614,14 +2615,6 @@ data_transfer_init (st_parameter_dt *dtp, int read_flag)
st_parameter_open opp;
unit_convert conv;
 
-  if (dtp->common.unit < 0 && !is_internal_unit (dtp))
-   {
- close_unit (dtp->u.p.current_unit);
- dtp->u.p.current_unit = NULL;
- generate_error (>common, LIBERROR_BAD_OPTION,
- "Bad unit number in statement");
- return;
-   }
   memset (_flags, '\0', sizeof (u_flags));
   u_flags.access = ACCESS_SEQUENTIAL;
   u_flags.action = ACTION_READWRITE;
-- 
2.7.4

Re: [PATCH, libfortran] PR 48587 Newunit allocator

2016-10-14 Thread Bernhard Reutner-Fischer 
On 14 October 2016 22:41:25 CEST, Janne Blomqvist  
wrote:
>On Fri, Oct 14, 2016 at 8:01 PM, Bernhard Reutner-Fischer
> wrote:
>> On 13 October 2016 22:08:21 CEST, Jerry DeLisle
> wrote:
>>>On 10/13/2016 08:16 AM, Janne Blomqvist wrote:
>>

 Regtested on x86_64-pc-linux-gnu. Ok for trunk?

>>>
>>>Yes, OK, clever! Thanks!
>>
>> Is 32 something a typical program uses?
>
>Probably not. Then again, wasting a puny 32 bytes vs. the time it
>takes to do one or two extra realloc+copy operations when opening that
>many files?

Every reallocated I'm aware of uses pools.

>
>> I'd have started at 8 and had not doubled but += 16 fwiw.
>
>I can certainly start at a smaller value like 8 or 16, but I'd like to

Yes please.

>keep the multiplicative increase in order to get O(log(N))
>reallocs+copys rather than O(N) when increasing the size.

Bike-shedding but if she's going to use that many units O(log(N)) will be 
nothing compared to the expected insn storm to follow. Inc by max(initial 
value, 64, let's say - short of double initial value - is still overestimated 
IMHO.
Thanks for taking care of this either way.
Cheers

[PATCH, libfortran] PR 48587 Newunit allocator

2016-10-14 Thread Janne Blomqvist 
Currently GFortran newer reuses unit numbers allocated with NEWUNIT=,
instead having a simple counter that is decremented each time such a
unit is opened.  For a long running program which repeatedly opens
files with NEWUNIT= and closes them, the counter can wrap around and
cause an abort.  This patch replaces the counter with an allocator
that keeps track of which units numbers are allocated, and can reuse
them once they have been deallocated.  Since operating systems tend to
limit the number of simultaneous open files for a process to a
relatively modest number, a relatively simple approach with a linear
scan through an array suffices.  Though as a small optimization there
is a low water indicator keeping track of the index for which all unit
numbers below are already allocated.  This linear scan also ensures
that we always allocate the smallest available unit number.

2016-10-15  Janne Blomqvist  

PR libfortran/48587
* io/io.h (get_unique_unit_number): Remove prototype.
(newunit_alloc): New prototype.
* io/open.c (st_open): Call newunit_alloc.
* io/unit.c (newunits,newunit_size,newunit_lwi): New static
variables.
(GFC_FIRST_NEWUNIT): Rename to NEWUNIT_START.
(next_available_newunit): Remove variable.
(get_unit): Call newunit_alloc, don't try to create negative
external unit.
(close_unit_1): Call newunit_free.
(close_units): Free newunits array.
(get_unique_number): Remove function.
(newunit_alloc): New function.
(newunit_free): New function.
* io/transfer.c (data_transfer_init): Check for invalid unit
number.

testsuite ChangeLog:

2016-10-15  Janne Blomqvist  

PR libfortran/48587
* gfortran.dg/negative_unit2.f90: New testcase.

Regtested on x86_64-pc-linux-gnu.

Version 2 of the patch. Compared to v1:
* Check for invalid unit number in transfer.c:data_transfer_init and
  unit.c:get_unit.
* Add testcase to check invalid unit number.
* Reduce initial size of newunits array from 32 to 16.
---
 gcc/testsuite/gfortran.dg/negative_unit2.f90 |   9 +++
 libgfortran/io/io.h  |   5 +-
 libgfortran/io/open.c|   2 +-
 libgfortran/io/transfer.c|  10 ++-
 libgfortran/io/unit.c| 108 +--
 5 files changed, 107 insertions(+), 27 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/negative_unit2.f90

diff --git a/gcc/testsuite/gfortran.dg/negative_unit2.f90 
b/gcc/testsuite/gfortran.dg/negative_unit2.f90
new file mode 100644
index 000..e7fb85e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/negative_unit2.f90
@@ -0,0 +1,9 @@
+! { dg-do run }
+! Test case submitted by Dominique d'Humieres
+program negative_unit2
+  integer :: i, j
+  ! i should be <= NEWUNIT_FIRST in libgfortran/io/unit.c
+  i = -100
+  write(unit=i,fmt=*, iostat=j) 10
+  if (j == 0) call abort
+end program negative_unit2
diff --git a/libgfortran/io/io.h b/libgfortran/io/io.h
index ea93fba..aaacc08 100644
--- a/libgfortran/io/io.h
+++ b/libgfortran/io/io.h
@@ -715,8 +715,9 @@ internal_proto (finish_last_advance_record);
 extern int unit_truncate (gfc_unit *, gfc_offset, st_parameter_common *);
 internal_proto (unit_truncate);
 
-extern GFC_INTEGER_4 get_unique_unit_number (st_parameter_common *);
-internal_proto(get_unique_unit_number);
+extern int newunit_alloc (void);
+internal_proto(newunit_alloc);
+
 
 /* open.c */
 
diff --git a/libgfortran/io/open.c b/libgfortran/io/open.c
index d074b02..2e7163d 100644
--- a/libgfortran/io/open.c
+++ b/libgfortran/io/open.c
@@ -812,7 +812,7 @@ st_open (st_parameter_open *opp)
   if ((opp->common.flags & IOPARM_LIBRETURN_MASK) == IOPARM_LIBRETURN_OK)
 {
   if ((opp->common.flags & IOPARM_OPEN_HAS_NEWUNIT))
-   opp->common.unit = get_unique_unit_number(>common);
+   opp->common.unit = newunit_alloc ();
   else if (opp->common.unit < 0)
{
  u = find_unit (opp->common.unit);
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 902c020..7696cca 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -2601,7 +2601,15 @@ data_transfer_init (st_parameter_dt *dtp, int read_flag)
 
   dtp->u.p.current_unit = get_unit (dtp, 1);
 
-  if (dtp->u.p.current_unit->s == NULL)
+  if (dtp->u.p.current_unit == NULL)
+{
+  /* This means we tried to access an external unit < 0 without
+having opened it first with NEWUNIT=.  */
+  generate_error (>common, LIBERROR_BAD_OPTION,
+ "Invalid unit number in statement");
+  return;
+}
+  else if (dtp->u.p.current_unit->s == NULL)
 {  /* Open the unit with some default flags.  */
st_parameter_open opp;
unit_convert conv;
diff --git a/libgfortran/io/unit.c b/libgfortran/io/unit.c
index 274b24b..41cd52f 100644
--- a/libgfortran/io/unit.c
+++

Re: [PATCH, libfortran] PR 48587 Newunit allocator

2016-10-14 Thread Janne Blomqvist 
On Fri, Oct 14, 2016 at 8:01 PM, Bernhard Reutner-Fischer
 wrote:
> On 13 October 2016 22:08:21 CEST, Jerry DeLisle  wrote:
>>On 10/13/2016 08:16 AM, Janne Blomqvist wrote:
>
>>>
>>> Regtested on x86_64-pc-linux-gnu. Ok for trunk?
>>>
>>
>>Yes, OK, clever! Thanks!
>
> Is 32 something a typical program uses?

Probably not. Then again, wasting a puny 32 bytes vs. the time it
takes to do one or two extra realloc+copy operations when opening that
many files?

> I'd have started at 8 and had not doubled but += 16 fwiw.

I can certainly start at a smaller value like 8 or 16, but I'd like to
keep the multiplicative increase in order to get O(log(N))
reallocs+copys rather than O(N) when increasing the size.

-- 
Janne Blomqvist

Re: [PATCH, libfortran] PR 48587 Newunit allocator

2016-10-14 Thread Bernhard Reutner-Fischer 
On 13 October 2016 22:08:21 CEST, Jerry DeLisle  wrote:
>On 10/13/2016 08:16 AM, Janne Blomqvist wrote:

>>
>> Regtested on x86_64-pc-linux-gnu. Ok for trunk?
>>
>
>Yes, OK, clever! Thanks!

Is 32 something a typical program uses?
I'd have started at 8 and had not doubled but += 16 fwiw.

Cheers

Re: [PATCH, libfortran] PR 48587 Newunit allocator

2016-10-13 Thread Dominique d'Humières 
With the patch, the following code

integer :: i, j
i = -10
write(unit=i,fmt=*, iostat=j) 10
print *, j
end

fails at run time with

Assertion failed: (ind >= 0 && ind < newunit_size), function newunit_free, file 
../../../work/libgfortran/io/unit.c, line 966.

Without the patch the output is 5002.

TIA

Dominique

Re: [PATCH, libfortran] PR 48587 Newunit allocator

2016-10-13 Thread Jerry DeLisle 

On 10/13/2016 08:16 AM, Janne Blomqvist wrote:

Currently GFortran newer reuses unit numbers allocated with NEWUNIT=,
instead having a simple counter that is decremented each time such a
unit is opened.  For a long running program which repeatedly opens
files with NEWUNIT= and closes them, the counter can wrap around and
cause an abort.  This patch replaces the counter with an allocator
that keeps track of which units numbers are allocated, and can reuse
them once they have been deallocated.  Since operating systems tend to
limit the number of simultaneous open files for a process to a
relatively modest number, a relatively simple approach with a linear
scan through an array suffices.  Though as a small optimization there
is a low water indicator keeping track of the index for which all unit
numbers below are already allocated.  This linear scan also ensures
that we always allocate the smallest available unit number.

2016-10-13  Janne Blomqvist  

PR libfortran/48587
* io/io.h (get_unique_unit_number): Remove prototype.
(newunit_alloc): New prototype.
* io/open.c (st_open): Call newunit_alloc.
* io/unit.c (newunits,newunit_size,newunit_lwi): New static
variables.
(GFC_FIRST_NEWUNIT): Rename to NEWUNIT_START.
(next_available_newunit): Remove variable.
(get_unit): Call newunit_alloc.
(close_unit_1): Call newunit_free.
(close_units): Free newunits array.
(get_unique_number): Remove function.
(newunit_alloc): New function.
(newunit_free): New function.

Regtested on x86_64-pc-linux-gnu. Ok for trunk?



Yes, OK, clever! Thanks!

Jerry

Re: [PATCH, libfortran] PR 48587 Newunit allocator

2016-10-13 Thread Jerry DeLisle 

On 10/13/2016 08:16 AM, Janne Blomqvist wrote:

Currently GFortran newer reuses unit numbers allocated with NEWUNIT=,
instead having a simple counter that is decremented each time such a
unit is opened.


I am going to have to study this a bit. After I added the newunit stack, the 
units are reused,  Need to see how this plays with internal units, and 
recursive, and dtio.


Jerry

[PATCH, libfortran] PR 48587 Newunit allocator

2016-10-13 Thread Janne Blomqvist 
Currently GFortran newer reuses unit numbers allocated with NEWUNIT=,
instead having a simple counter that is decremented each time such a
unit is opened.  For a long running program which repeatedly opens
files with NEWUNIT= and closes them, the counter can wrap around and
cause an abort.  This patch replaces the counter with an allocator
that keeps track of which units numbers are allocated, and can reuse
them once they have been deallocated.  Since operating systems tend to
limit the number of simultaneous open files for a process to a
relatively modest number, a relatively simple approach with a linear
scan through an array suffices.  Though as a small optimization there
is a low water indicator keeping track of the index for which all unit
numbers below are already allocated.  This linear scan also ensures
that we always allocate the smallest available unit number.

2016-10-13  Janne Blomqvist  

PR libfortran/48587
* io/io.h (get_unique_unit_number): Remove prototype.
(newunit_alloc): New prototype.
* io/open.c (st_open): Call newunit_alloc.
* io/unit.c (newunits,newunit_size,newunit_lwi): New static
variables.
(GFC_FIRST_NEWUNIT): Rename to NEWUNIT_START.
(next_available_newunit): Remove variable.
(get_unit): Call newunit_alloc.
(close_unit_1): Call newunit_free.
(close_units): Free newunits array.
(get_unique_number): Remove function.
(newunit_alloc): New function.
(newunit_free): New function.

Regtested on x86_64-pc-linux-gnu. Ok for trunk?
---
 libgfortran/io/io.h   |   5 ++-
 libgfortran/io/open.c |   2 +-
 libgfortran/io/unit.c | 103 --
 3 files changed, 86 insertions(+), 24 deletions(-)

diff --git a/libgfortran/io/io.h b/libgfortran/io/io.h
index ea93fba..aaacc08 100644
--- a/libgfortran/io/io.h
+++ b/libgfortran/io/io.h
@@ -715,8 +715,9 @@ internal_proto (finish_last_advance_record);
 extern int unit_truncate (gfc_unit *, gfc_offset, st_parameter_common *);
 internal_proto (unit_truncate);
 
-extern GFC_INTEGER_4 get_unique_unit_number (st_parameter_common *);
-internal_proto(get_unique_unit_number);
+extern int newunit_alloc (void);
+internal_proto(newunit_alloc);
+
 
 /* open.c */
 
diff --git a/libgfortran/io/open.c b/libgfortran/io/open.c
index d074b02..2e7163d 100644
--- a/libgfortran/io/open.c
+++ b/libgfortran/io/open.c
@@ -812,7 +812,7 @@ st_open (st_parameter_open *opp)
   if ((opp->common.flags & IOPARM_LIBRETURN_MASK) == IOPARM_LIBRETURN_OK)
 {
   if ((opp->common.flags & IOPARM_OPEN_HAS_NEWUNIT))
-   opp->common.unit = get_unique_unit_number(>common);
+   opp->common.unit = newunit_alloc ();
   else if (opp->common.unit < 0)
{
  u = find_unit (opp->common.unit);
diff --git a/libgfortran/io/unit.c b/libgfortran/io/unit.c
index 274b24b..cc24ca7 100644
--- a/libgfortran/io/unit.c
+++ b/libgfortran/io/unit.c
@@ -29,6 +29,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
 #include "unix.h"
 #include 
 #include 
+#include 
 
 
 /* IO locking rules:
@@ -68,12 +69,34 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
on it.  unlock_unit or close_unit must be always called only with the
private lock held.  */
 
-/* Subroutines related to units */
 
-/* Unit number to be assigned when NEWUNIT is used in an OPEN statement.  */
-#define GFC_FIRST_NEWUNIT -10
+
+/* Table of allocated newunit values.  A simple solution would be to
+   map OS file descriptors (fd's) to unit numbers, e.g. with newunit =
+   -fd - 2, however that doesn't work since Fortran allows an existing
+   unit number to be reassociated with a new file. Thus the simple
+   approach may lead to a situation where we'd try to assign a
+   (negative) unit number which already exists. Hence we must keep
+   track of allocated newunit values ourselves. This is the purpose of
+   the newunits array. The indices map to newunit values as newunit =
+   -index + NEWUNIT_FIRST. E.g. newunits[0] having the value true
+   means that a unit with number NEWUNIT_FIRST exists. Similar to
+   POSIX file descriptors, we always allocate the lowest (in absolute
+   value) available unit number.
+ */
+static bool *newunits;
+static int newunit_size; /* Total number of elements in the newunits array.  */
+/* Low water indicator for the newunits array. Below the LWI all the
+   units are allocated, above and equal to the LWI there may be both
+   allocated and free units. */
+static int newunit_lwi;
+static void newunit_free (int);
+
+/* Unit numbers assigned with NEWUNIT start from here.  */
+#define NEWUNIT_START -10
+
+
 #define NEWUNIT_STACK_SIZE 16
-static GFC_INTEGER_4 next_available_newunit = GFC_FIRST_NEWUNIT;
 
 /* A stack to save previously used newunit-assigned unit numbers to
allow them to be reused without reallocating the gfc_unit structure
@@ -81,6 +104,7 @@