Committed: fd_truncate test-cases updated for recent libgfortran changes

Committed: fd_truncate test-cases updated for recent libgfortran changes

[Hans-Peter Nilsson]

Once or twice a year some regression results from changed I/O
in libgfortran, such that some existing test-case starts
calling libgfortran/io/unix.c:raw_truncate, which on
limited-I/O-bare-iron targets will emit "required ftruncate or
chsize support not present" and fail.  After a while, I get to
it and commit a patch such as the following, updating the
regressing tests and new ones I spot in gfortran.log with the
self-marked line above.  This time, it happened in 173155:173168.

Usually, there's also a brief question whether all changes were
intended, or perhaps that some of the regressing tests (here:
gfortran.dg/fmt_cache_1.f and gfortran.dg/ftell_3.f90) were not
really supposed to have raw_truncate called.  So, should they?

Two of the test-cases, gfortran.dg/endfile_3.f90 and
gfortran.dg/endfile_4.f90 actually pass, which seems wrong, as
raw_truncate after emitting the error message returns an error
indication (so, the test-program should abort or return an error
AFAICT).  Perhaps due to lack of error handling in the
call-chain to raw_truncate?

Anyway, committed as obvious.  See also
<http://gcc.gnu.org/ml/fortran/2009-07/msg00095.html>.

gcc/testsuite:
	* gfortran.dg/pr47878.f90, gfortran.dg/endfile_3.f90,
	gfortran.dg/endfile_4.f90, gfortran.dg/ftell_3.f90,
	gfortran.dg/fmt_cache_1.f, gfortran.dg/namelist_66.f90:
	Gate test on effective_target fd_truncate.

Index: gfortran.dg/endfile_4.f90
===================================================================
--- gfortran.dg/endfile_4.f90	(revision 173380)
+++ gfortran.dg/endfile_4.f90	(working copy)
@@ -1,4 +1,4 @@
-! { dg-do run }
+! { dg-do run { target fd_truncate } }
 ! pr44477 ENDFILE not allowed after ENDFILE
 !-------------------------------------------
   open(10, form='formatted', &
Index: gfortran.dg/pr47878.f90
===================================================================
--- gfortran.dg/pr47878.f90	(revision 173380)
+++ gfortran.dg/pr47878.f90	(working copy)
@@ -1,5 +1,5 @@
 ! PR fortran/47878
-! { dg-do run }
+! { dg-do run { target fd_truncate } }
   integer :: a(5)
   open (99, recl = 40)
   write (99, '(5i3)') 1, 2, 3
Index: gfortran.dg/namelist_66.f90
===================================================================
--- gfortran.dg/namelist_66.f90	(revision 173380)
+++ gfortran.dg/namelist_66.f90	(working copy)
@@ -1,4 +1,4 @@
-! { dg-do run }
+! { dg-do run { target fd_truncate } }
 ! PR46010 Failure to read these two examples of namelists
 type ptracer
    character(len = 2)  :: sname
Index: gfortran.dg/ftell_3.f90
===================================================================
--- gfortran.dg/ftell_3.f90	(revision 173380)
+++ gfortran.dg/ftell_3.f90	(working copy)
@@ -1,4 +1,4 @@
-! { dg-do run }
+! { dg-do run { target fd_truncate } }
 ! PR43605 FTELL intrinsic returns incorrect position
 ! Contributed by Janne Blomqvist, Manfred Schwarb
 ! and Dominique d'Humieres.
Index: gfortran.dg/endfile_3.f90
===================================================================
--- gfortran.dg/endfile_3.f90	(revision 173380)
+++ gfortran.dg/endfile_3.f90	(working copy)
@@ -1,4 +1,4 @@
-! { dg-do run }
+! { dg-do run { target fd_truncate } }
 ! pr44477 READ/WRITE not allowed after ENDFILE 
 !-------------------------------------------
   open(10, form='formatted', &
Index: gfortran.dg/fmt_cache_1.f
===================================================================
--- gfortran.dg/fmt_cache_1.f	(revision 173380)
+++ gfortran.dg/fmt_cache_1.f	(working copy)
@@ -1,4 +1,4 @@
-! { dg-do run }
+! { dg-do run { target fd_truncate } }
 ! pr40662 segfaults when specific format is invoked twice.
 ! pr40330  incorrect io.
 ! test case derived from pr40662, <jvdelisle@gcc.gnu.org>

brgds, H-P

Re: Committed: fd_truncate test-cases updated for recent libgfortran changes

[Janne Blomqvist]

On Thu, May 5, 2011 at 00:52, Hans-Peter Nilsson
<hans-peter.nilsson@axis.com> wrote:
> Once or twice a year some regression results from changed I/O
> in libgfortran, such that some existing test-case starts
> calling libgfortran/io/unix.c:raw_truncate, which on
> limited-I/O-bare-iron targets will emit "required ftruncate or
> chsize support not present" and fail.  After a while, I get to
> it and commit a patch such as the following, updating the
> regressing tests and new ones I spot in gfortran.log with the
> self-marked line above.  This time, it happened in 173155:173168.
>
> Usually, there's also a brief question whether all changes were
> intended, or perhaps that some of the regressing tests (here:
> gfortran.dg/fmt_cache_1.f and gfortran.dg/ftell_3.f90) were not
> really supposed to have raw_truncate called.  So, should they?

I don't know; If you cared to bisect, that would help. These issues
tend to fly under the radar as most developers have ftruncate()
present. Maybe some script hack running the testsuite under strace()
and cross-checking for the presence of "target fd_truncate" might do
on "normal" targets, but I haven't looked into it.

> Two of the test-cases, gfortran.dg/endfile_3.f90 and
> gfortran.dg/endfile_4.f90 actually pass, which seems wrong, as
> raw_truncate after emitting the error message returns an error
> indication (so, the test-program should abort or return an error
> AFAICT).  Perhaps due to lack of error handling in the
> call-chain to raw_truncate?

This seems strange. AFAICT raw_truncate returns -1 in that case only
to shut the compiler up, because runtime_error() should never return.
However, runtime_error() calls sys_exit() (both in runtime/error.c)
which makes the process kill itself either via

kill(getpid(), SIGQUIT);  /* BTW, why not just raise(SIGQUIT)?? */

or

exit(code);

where in this case code==2. Perhaps this makes the testsuite believe
that the testcase ran successfully? The testsuite uses the process
return value to determine success, right? But which values exactly
constitute success vs. failure?

For comparison, normally testcases fail by calling the ABORT
subroutine, which calls abort() => process return value 134.

For kill/raise(SIGQUIT), return value is 131.

and for exit(2), obviously, the return value is 2.

Anything in the above that looks like a smoking gun?

> Anyway, committed as obvious.

Thanks.



-- 
Janne Blomqvist

Re: Committed: fd_truncate test-cases updated for recent libgfortran changes

[Mike Stump]

On May 5, 2011, at 9:36 AM, Janne Blomqvist wrote:
> The testsuite uses the process return value to determine
> success, right? But which values exactly constitute success
> vs. failure?

0 is success, and != 0 is failure.

Re: Committed: fd_truncate test-cases updated for recent libgfortran changes

[Hans-Peter Nilsson]

> Date: Thu, 5 May 2011 19:36:47 +0300
> From: Janne Blomqvist <blomqvist.janne@gmail.com>

> On Thu, May 5, 2011 at 00:52, Hans-Peter Nilsson
> <hans-peter.nilsson@axis.com> wrote:
> > This time, it happened in 173155:173168.
> >
> > Usually, there's also a brief question whether all changes were
> > intended, or perhaps that some of the regressing tests (here:
> > gfortran.dg/fmt_cache_1.f and gfortran.dg/ftell_3.f90) were not
> > really supposed to have raw_truncate called.  So, should they?
> 
> I don't know; If you cared to bisect, that would help.

There's nothing to bisect, there was just one big libgfortran
change in the range I mentioned, one you should already know
about. :)

> These issues
> tend to fly under the radar as most developers have ftruncate()
> present. Maybe some script hack running the testsuite under strace()
> and cross-checking for the presence of "target fd_truncate" might do
> on "normal" targets, but I haven't looked into it.

I wouldn't say that this needs any priority, but I like the idea
of a portion of an I/O-library checking regression in the number
of syscalls using strace (pruning the startup and finish for
obvious reasons).

> > Two of the test-cases, gfortran.dg/endfile_3.f90 and
> > gfortran.dg/endfile_4.f90 actually pass, which seems wrong, as
> > raw_truncate after emitting the error message returns an error
> > indication (so, the test-program should abort or return an error
> > AFAICT).  Perhaps due to lack of error handling in the
> > call-chain to raw_truncate?

Ignore that, I missed the dg-shouldfail:s.  Or at most note that
dg-shouldfail should be improved to actually look for its
argument in order to distinguish between the expected failure
message and others.  Right now it "accepts" any failure.

brgds, H-P