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