> From: Janne Blomqvist <blomqvist.ja...@gmail.com> > Date: Thu, 23 May 2019 23:43:23 +0300
> On Thu, May 23, 2019 at 5:21 AM Hans-Peter Nilsson > <hans-peter.nils...@axis.com> wrote: > > > > There was a regression for gfortran.dg/fmt_en.f90 for cris-elf > > that on inspection was due to it having acquired a truncation > > call through the runtime. I updated that and the new tests that > > had "Fortran runtime error: required ftruncate or chsize support > > not present" messages in gfortran.log, ran past cris-elf and > > committed as obvious. > Do you know which commit caused this? Was it something recent? Based > on a quick look, at least for fmt_en this shouldn't happen.. For fmt_en.f90, it was quite long ago, in 2015, and luckily just two commits since the previous run. It's either r223857 or r223858, but it can't be r223857, being on a branch elsewhere than trunk. I'm not completely sure how r223858 could have changed matters either, but I have a theory: While fmt_en.f90 *was* touched by that commit, it was about changing how dump files etc was cleaned up in the test-suite. The test outputs to a file "fmt_en.res" and is run multiple times for various optimization options. I guess that before that commit, that file was wiped out by the test-machinery between iterations and afterwards, there's a fmt_en.res from a previous run, and the fortran runtime library "empties" an existing output-file by truncating it. ...Right, the first (-O0) iteration succeeded. I thought that was because gfortran arranged to output things differently depending on optimization options! So, that "should/should not happen" depends on whether the test should cover handling an existing fmt_en.res. I guess it should, so all tests outputting to a file are affected, as long as libgfortran empties files by ftruncate or chsize. The other tests have failed since their introduction. > Since this seems to happen semi-regularly, would it be possible to do > something at the dejagnu level, e.g. to fail a test that uses > ftruncate/chsize even though it's not marked with target fd_truncate. Sorry, I don't know, I don't understand what's suggested. But, it's not that the semi-regular frequency is disturbingly high (cycle-time half a year to 11 years). > Hard to see how that could be verified without running testcases under > strace or something like that. brgds, H-P
