RFA: testsuite fix for 4.8 (was Re: [patch, libgfortran] PR60128 Wrong ouput using en edit descriptor)

On Sat, 12 Apr 2014, Dominique Dhumieres wrote:

> > This test, after the update on 4.8 in r209070 when the test-case was
> > modified substantially (not really covered by the ChangeLog entry) to be
> > identical to that on trunk, apparently takes a different route in the
> > fortran run-time library on 4.8 compared to trunk.  For 4.8, it requires
> > more run-time support on the target system, trigging the tell-tale error
> > message found in gfortran.log: "Fortran runtime error: required ftruncate
> > or chsize support not present" on some targets, then aborting and flagged
> > as a regression as it passed before that commit.  Committed to 4.8 as
> > obvious.  Again, this is not required on trunk.
>
> IMO this the change is far from obvious and defeats the purpose the changes
> in the test case which was to run the test on ALL targets.
>
> I need to know what are the affected targets,
> ...

That seemed to be aiming for a far more intrusive change than
the situation requires, i.e. not obvious.  (But...)

In r209070 on 4.8, you did not just "Skip unsupported rounding
tests. XFAIL for i?86-*-solaris2.9* and hppa*-*-hpux*" from
trunk revision r208979, which by itself did not introduce any
change in the test-method, but also imported r208780 "Update
test. XFAIL for i?86-*-solaris2.9*".  The "update test" part of
that change was actually a rewrite, changing the test-method to
use other means of output.  As mentioned, I presumed the fortran
run-time was different on trunk than on 4.8 such that test there
requires truncation of some sort.

Some background to why I thought this was obvious seems in
order.  Years ago, the fd_truncate effective target was
introduced to be able to filter-out tests for those
runtime-limited systems (like many simulator targets and
bare-iron based on newlib) that don't support changing the size
of a file.  For the background, see
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35293>.  Since
then, I do as in
<http://gcc.gnu.org/ml/fortran/2009-07/msg00095.html> when this
happens.  The difference here from that time was apparently that
the test-case was changed rather than the run-time, and I saw
no need for further analysis.

But, that wasn't the whole story this time.  Sorry!

> what part of the test
> triggers the failure, and if it exists a work-around.

I started looking at what parts of the test was responsible for
the truncation, but noticed that it was "only" due to the
presence of the output file "fmt_en.res" containing the single
line " All kinds rounded to nearest".  This file is output when
the test is run for 4.8 *as well as on trunk* (fully intended as
obvious from the last lines of the test), and when present
apparently causes the fortran runtime to truncate it (empty it)
such that the first run (when it's absent) succeeds but
subsequent runs fail as mentioned.  The key difference between
trunk and 4.8 is actually that the .res file is removed by the
test-harness on trunk through the cleanup-saved-temps call after
the test, but not for 4.8.  So, a better change is IMHO to
import that for 4.8 instead, as follows.

I did import *all* changes to this function, as that seemed
better than just adding ".res" as seen in the first hunk.  I
believe this follows best practice for regarding imports of
testsuite framework to branches, but perhaps that's a matter of
taste.

Since this (besides the revert) is less than obvious, ok for 4.8?
Tested by noticing the intended change happens for fmt_en.f90.

4.8 gcc/testsuite:

	* gfortran.dg/fmt_en.f90: Revert previous change.
	* lib/gcc-dg.exp (cleanup-saved-temps): Update from trunk.


brgds, H-P