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

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.

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

[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

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,

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

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

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

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

[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