fortran-dev issues (cygwin64)
Tim Prince
n8tm@aol.com
Thu Jun 12 17:53:00 GMT 2014
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
More information about the Fortran
mailing list