Make NEXTREC specifier for INQUIRE work for large record numbers

This is accomplished by making the NEXTREC specifier be a 8 byte
integer where supported.

I wasn't able to come up with a testcase that does not create a large
file that could be added to the testsuite, but here's one which
creates a 2 GB file:

program nextrec
  implicit none
  integer(8) :: ii, n
  open(10, file="foo.dat", recl=1, access="direct", form="unformatted", status="replace")
  do ii = 1, huge(1) + 2_8
     write(10, rec=ii) 'a'
  end do
  inquire(10, nextrec=n)
  if (n /= huge(1) + 2_8) then
     call abort()
  end if
  close(10, status="delete")
end program nextrec

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

gcc/fortran/ChangeLog:

2017-11-18  Janne Blomqvist  <jb@gcc.gnu.org>

	PR fortran/83036
	* ioparm.def (IOPARM): Make nextrec a pintio.

libgfortran/ChangeLog:

2017-11-18  Janne Blomqvist  <jb@gcc.gnu.org>

	PR fortran/83036
	* io/io.h: Make nextrec a GFC_IO_INT*.
---
 gcc/fortran/ioparm.def | 2 +-
 libgfortran/io/io.h    | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

On Sat, Nov 18, 2017 at 12:34 PM, Janne Blomqvist
<blomqvist.janne@gmail.com> wrote:
> This is accomplished by making the NEXTREC specifier be a 8 byte
> integer where supported.
>
> I wasn't able to come up with a testcase that does not create a large
> file that could be added to the testsuite, but here's one which
> creates a 2 GB file:
>
> program nextrec
>   implicit none
>   integer(8) :: ii, n
>   open(10, file="foo.dat", recl=1, access="direct", form="unformatted", status="replace")
>   do ii = 1, huge(1) + 2_8
>      write(10, rec=ii) 'a'
>   end do
>   inquire(10, nextrec=n)
>   if (n /= huge(1) + 2_8) then

This statement should of course be

if (n /= huge(1) + 3_8) then

Hi Janne,

> This is accomplished by making the NEXTREC specifier be a 8 byte
> integer where supported.
> 
> I wasn't able to come up with a testcase that does not create a large
> file that could be added to the testsuite, but here's one which
> creates a 2 GB file:
I think the patch is OK (even obvious), also without a test case,
but maybe you could wait for a couple of days before committing to
give others a chance to chime in.

Regards

	Thomas

On Sat, Nov 18, 2017 at 6:00 PM, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Hi Janne,
>
>> This is accomplished by making the NEXTREC specifier be a 8 byte
>> integer where supported.
>>
>> I wasn't able to come up with a testcase that does not create a large
>> file that could be added to the testsuite, but here's one which
>> creates a 2 GB file:
>
> I think the patch is OK (even obvious), also without a test case,
> but maybe you could wait for a couple of days before committing to
> give others a chance to chime in.

Thanks, committed as r254916. Since this changes the libgfortran ABI,
I wanted to get this in at the same time as the PR 44292 patch, so
people have to rebuild everything only once (yes, this is trunk, but
still). If somebody comes up with a way to test this without a huge
file, we can add such a testcase later.

On 11/18/2017 08:59 AM, Janne Blomqvist wrote:
> On Sat, Nov 18, 2017 at 6:00 PM, Thomas Koenig <tkoenig@netcologne.de> wrote:
>> Hi Janne,
>>
>>> This is accomplished by making the NEXTREC specifier be a 8 byte
>>> integer where supported.
>>>
>>> I wasn't able to come up with a testcase that does not create a large
>>> file that could be added to the testsuite, but here's one which
>>> creates a 2 GB file:
>>
>> I think the patch is OK (even obvious), also without a test case,
>> but maybe you could wait for a couple of days before committing to
>> give others a chance to chime in.
> 
> Thanks, committed as r254916. Since this changes the libgfortran ABI,
> I wanted to get this in at the same time as the PR 44292 patch, so
> people have to rebuild everything only once (yes, this is trunk, but
> still). If somebody comes up with a way to test this without a huge
> file, we can add such a testcase later.
> 
> 

Yes OK.

We could consider setting up an automatic testing machine somewhere that not
only does the usual test-suite, but also tests the unusual things like this. For
example, I had a test case which died when launched with more than 32 threads
for example. Not every machine or architecture could do that so I do not have a
test case for it.

Another example is the NIST tests which we run manually via a script.

Regardless, this machine could also issue an email to the gfortran list when
ever a new failure is discovered. We could do it so it does not repeat the email
every day, just a report of new and a report of problem went away.

Just a thought.

Jerry

> We could consider setting up an automatic testing machine somewhere that not
> only does the usual test-suite, but also tests the unusual things like this. For
> example, I had a test case which died when launched with more than 32 threads
> for example. Not every machine or architecture could do that so I do not have a
> test case for it.

One of the big machines from the compile farm could do this, such as
gcc110 (a POWER7 that I use a lot for development) or gcc112 (a 160 core
machine).

Regards

	Thomas