Message ID | 1511001250-27383-1-git-send-email-blomqvist.janne@gmail.com |
---|---|
State | New |
Headers | show |
Series | Make NEXTREC specifier for INQUIRE work for large record numbers | expand |
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
diff --git a/gcc/fortran/ioparm.def b/gcc/fortran/ioparm.def index ca5631b..920934a 100644 --- a/gcc/fortran/ioparm.def +++ b/gcc/fortran/ioparm.def @@ -62,7 +62,7 @@ IOPARM (inquire, exist, 1 << 7, pint4) IOPARM (inquire, opened, 1 << 8, pint4) IOPARM (inquire, number, 1 << 9, pint4) IOPARM (inquire, named, 1 << 10, pint4) -IOPARM (inquire, nextrec, 1 << 11, pint4) +IOPARM (inquire, nextrec, 1 << 11, pintio) IOPARM (inquire, recl_out, 1 << 12, pint4) IOPARM (inquire, strm_pos_out, 1 << 13, pintio) IOPARM (inquire, file, 1 << 14, char1) diff --git a/libgfortran/io/io.h b/libgfortran/io/io.h index df49157..483ee93 100644 --- a/libgfortran/io/io.h +++ b/libgfortran/io/io.h @@ -388,7 +388,8 @@ typedef struct { st_parameter_common common; GFC_INTEGER_4 *exist, *opened, *number, *named; - GFC_INTEGER_4 *nextrec, *recl_out; + GFC_IO_INT *nextrec; + GFC_INTEGER_4 *recl_out; GFC_IO_INT *strm_pos_out; CHARACTER1 (file); CHARACTER2 (access);