This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
fortran-dev issues (cygwin64)
- From: Tim Prince <n8tm at aol dot com>
- To: "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>
- Date: Thu, 12 Jun 2014 13:53:16 -0400
- Subject: fortran-dev issues (cygwin64)
- Authentication-results: sourceware.org; auth=none
- Reply-to: tprince at computer dot org
libgomp appears to build correctly after cleaning out the directory
contents. Apparently, there is no mechanism to remove libgomp/config.*
automatically when updates are required.
In test suite case include_3.f95 the strange path with mixed forward and
back slashes produced the corresponding diagnostic message in place of
the non-existent or missing directory messages anticipated in
dg-warning, as nothing was done to set the environment variable to
suppress the message.
default_format_denormal_1.f90 is set up as expected fail for all cygwin
targets even though it always passes on x86_64-unknown-cygwin. I
suppose it could be related to the windows X64 default setting of abrupt
underflow (FTZ) which differs from win32. I think it's only possible to
change the setting temporarily within an executable (although
-ffast-math may attempt to set it uniformly).
I'm still looking for an answer about why round_4.f90 is made to fail
due to the undefined reference nextafterl(). If this is considered as
a failure of libquadmath, shouldn't libquadmath provide that function
when it isn't in the C library? Otherwise, it seems an expected fail of
libquadmath for any newlib target. A web search hints that it depends
in newlib on _LDBL_EQ_DBL i.e. in effect:
#ifdef _LDBL_EQ_DBL
#define nextafterl(x,y) nextafter(x,y)
#endif
which I doubt would be compatible with libquadmath.
I usually get a couple of random test suite failures due to Windows file
system latency not permitting over-writing of a .exe which was recently
executing, even on my lowest clocked Windows platform. Is there
intended to be a mechanism to attempt to remove a file before attempting
to replace it? If a scan of the logs to remove such incidents from the
report is expected, shouldn't the test_summary script include that?
--
Tim Prince