On Thu, May 5, 2011 at 00:52, Hans-Peter Nilsson <hans-peter.nils...@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
