Committed: fd_truncate test-cases updated for recent libgfortran changes

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.


brgds, H-P

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.

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.