[Bug libfortran/78549] New: Very slow formatted internal file output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
Bug ID: 78549
Summary: Very slow formatted internal file output
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mecej4 at operamail dot com
Target Milestone: ---
Created attachment 40163
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40163&action=edit
Program to demonstrate bug
Formatted internal writes to a string variable are very slow in many recent
versions of GFortran, especially the Windows ports. The attached F77 program,
and F95 versions of the same, demonstrate the problem. The heart of the problem
is the slowness of
write (str,'(1P,10E12.3)') x
(where x is a real array of dimension 10), compared to the equivalent call to
sprintf in C. Unlike in some old Gfortran bug reports, there are no issues
related to Windows versus Linux file system and I/O system discrepancies. NO
external FILE I/O is involved.
Here are some timings, in seconds, on two systems.
SYSTEM: Linux, XEON E5-2630, GFortran/GCC 6.1.1/F2C
gfortran -Ofast 6.4
F2C and gcc -Ofast 4.8
gcc -Ofast 1.8
SYSTEM: Windows 10-64 laptop, Haswell i5-4200U CPU
F2C, gcc 6.2 -O2 -march=haswell 7.8
G77 -O2 -march=pentium 12.7
gfortran 5.2 32-bit Cygwin 49.6
gfortran 6.2 Mingw-64, Eq.com 65.6
gcc 6.2 5.2
Ifort 17.0.12.3
Here is the source code of the C program, which I am placing here since I am
allowed only one attachment.
#include
int main(){
char str[121];
float x[10]={ 7.569, 5.556, -1.640, 9.362, 1.057,
-2.385,-9.541, 1.449, -7.885, -1.108};
int i,j;
for(i=0; i<100; i++){
sprintf(str,"%12.3e%12.3e%12.3e%12.3e%12.3e%12.3e%12.3e%12.3e%12.3e%12.3e",
x[0],x[1],x[2],x[3],x[4],x[5],x[6],x[7],x[8],x[9]);
if((i+1)%20 == 0)printf("%8d %s\n",i+1,str);
}
}
[Bug libfortran/78549] Very slow formatted internal file output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549 --- Comment #2 from mecej4 at operamail dot com --- Thanks, Martin. After posting, I found that I could add more add more attachments, but I was a bit worried that, as in other forums, the initial post could not be edited or modified. I presume that you ran your confirmation runs on Linux. Even if the Fortran version is three times slower than the C version, as you found, perhaps one could live with that. However, on Windows(+Cygwin,Mingw,etc.) the performance of the Fortran version is terrible, and I think that this reflects poorly on the otherwise fine Gfortran compiler, which often outperforms expensive commercial Fortran compilers in the quality of the generated code. A collaborator tells me that the problem did not exist in the Windows/MinGW release of Gfortran 4.9.3. I could not test that assertion myself because the installer failed on my Windows 10 system.
[Bug libfortran/78549] Very slow formatted internal file output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549 --- Comment #4 from mecej4 at operamail dot com --- (In reply to Jerry DeLisle from comment #3) > We cannot address the Windows(+Cygwin,Mingw,etc.) issues which have more to > do with the OS related layers I assume. > > I will see what I get on Cygwin and report back in a few days. Fair enough. For what it is worth, here are timings for the same test programs built with Gfortran/GCC 6.2.0 under Windows Subsystem for Linux (Ubuntu 14) on Windows-10: GCC 6.2.0 : 1.984 s GFortran 6.2.0 : 8.438 s
[Bug libfortran/78549] Very slow formatted internal file output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549 --- Comment #6 from mecej4 at operamail dot com --- (In reply to Jerry DeLisle from comment #5) > > Can you explain what "Windows Subsystem for Linux (Ubuntu 14) on Windows-10" > is? Sorry if I created a bad portmanteau phrase. Here is a link to Microsoft's own description of WSL (Windows Subsystem for Linux) : https://msdn.microsoft.com/en-us/commandline/wsl/about . This beta product for Windows 10-x64 provides a Bash shell in which character I/O, user-mode Linux applications can be run (only 64-bit a.out supported). I found it fairly simple to install, and it worked well for the tests that I tried. Once Bash has been installed, one can install Ubuntu-14 packages using Apt-Get; in particular, there is a Gfortran 6.2 package that works. While browsing the sources of LibGfortran, I found the file which seemed to be a candidate for profiling: write_float.def, which I understand you are currently revising.
[Bug fortran/78676] New: Optimizer bug exposed by program with many bit operations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78676 Bug ID: 78676 Summary: Optimizer bug exposed by program with many bit operations. Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mecej4 at operamail dot com Target Milestone: --- Created attachment 40244 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40244&action=edit Test program to demonstrate bug; run with (i) -O and (ii) -O2, and compare the output The attached test program runs and gives correct results when compiled with Gfortran 6.2 without any optimization or with -O. It gives incorrect results when compiled with -O2. Since the program works entirely with integer variables, exact results are to be expected. The bug was encountered when running George Marsaglia's KISS random number generator, see http://mathforum.org/kb/message.jspa?messageID=6914945 . His benchmark program runs a billion iterations, whereas the attached program does only ten iterations. The errors appear to be small but, by increasing the parameter QSIZ to a few millions, it can be seen that the errors grow catastrophically. Again, since no real number arithmetic is involved, there is no expectation of obtaining different results on different platforms. The results given by Gfortran with -O or without any optimization are in agreement with results from other compilers (NAG, Intel).
[Bug fortran/78676] Optimizer bug exposed by program with many bit operations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78676 --- Comment #2 from mecej4 at operamail dot com --- (In reply to Andrew Pinski from comment #1) > This sounds like overflows are happening. Overflow in fortran is undefined. Very much so, but integer overflow happens a lot in random number generation routines, where the algorithms usually employ unsigned integer arithmetic. There is a long tradition of Fortran compilers ignoring integer overflow and this feature is being exploited to implement RNG programs. If the compiler's error trapping capability includes detecting integer overflow, that should be turned off for running the test program (or Marsaglia's RNG software). For example, with the NAG Fortran compiler the -C option makes some checking happen, but integer overflow is not checked. There is a -C=all option that traps overflow, so it should definitely not be used.
[Bug fortran/78676] [5/6/7 Regression] Optimizer bug with -ftree-vrp exposed by program with many bit operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78676 --- Comment #7 from mecej4 at operamail dot com --- (In reply to Andrew Pinski from comment #3) > Try -fwrapv . Thanks! Using that flag with -O2 does make the program give correct results, but I am a little confused about what that flag does and when it should be used. Obviously, it would be safe to use -fwrapv with any bit-twiddling Fortran routine, but it is not obvious which optimizations are impacted by the use of this option. The online documentation at https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Optimize-Options.html#Optimize-Options says "See also the -fwrapv option" as part of the description of -fstrict-overflow, but I cannot find a separate entry that explains -fwrapv, at least not on that page. I did find a description of -fwrapv on a page for an older version of GCC, namely, 3.0, at http://www.cs.fsu.edu/~baker/ada/gnat/html/gcc_3.html#IDX1319 , but it says "This flag enables some optimizations and disables other." and I was not able to find which ones. Anyway, I am doubtful whether the old manual page is applicable to GCC 6.2.
[Bug libfortran/78833] New: Misleading IOMSG after failed WRITE(...,POS=) on unconnected formatted stream file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78833 Bug ID: 78833 Summary: Misleading IOMSG after failed WRITE(...,POS=) on unconnected formatted stream file Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: mecej4 at operamail dot com Target Milestone: --- The program below, when run with Gfortran 6.2, runs correctly the first time, and produces an output file. When the program is run a second time, the output file already exists, so the OPEN(..,STATUS='NEW') fails. Everything fine so far. If, however, the program fails to check if the OPEN succeeded and proceeds to do I/O on the file, the IOMSG issued is misleading, saying "...try OPEN with ACCESS='stream' when that is precisely how the OPEN was attempted (but failed). program TEST implicit none integer :: POS1, IOK character(132) :: msg open(10, file='strm.dat', status='new', form='formatted', & access='stream', iostat=IOK, iomsg=msg) if(iok /= 0)write(*,*) 'IOSTAT after OPEN: ',IOK,' ',trim(msg) write(10,'(A)') 'a' inquire(unit=10, pos=POS1) write(10,*) write(10,'(I10)',pos=POS1, iostat=iok, iomsg=msg) 2 if(iok /= 0)write(6,*) 'IOSTAT after WRITE: ',IOK,' ',trim(msg) close(10) end program TEST --- IOSTAT after OPEN: 17 Cannot open file 'strm.dat': File exists IOSTAT after WRITE: 5002 POS=specifier not allowed, Try OPEN with ACCESS='stream' <<<===
[Bug libfortran/78833] Misleading IOMSG after failed WRITE(...,POS=) on unconnected formatted stream file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78833 --- Comment #1 from mecej4 at operamail dot com --- Created attachment 40349 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40349&action=edit Test program for reproducing bug in IOMSG Same source code as in main message, for your convenience.
[Bug libfortran/78833] Misleading IOMSG after failed WRITE(...,POS=) on unconnected formatted stream file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78833 --- Comment #3 from mecej4 at operamail dot com --- I understand what happens, and this is not a bug per se', but in normal usage the message wording can be confusing. During the second run, the OPEN fails because 'NEW' is specified and the file already exists. If the program does not stop when the OPEN failed and goes on to the WRITE, the unit is not open or connected, so an implicit OPEN is performed to file 'FORT10', with no keyword options in the implicit OPEN. Therefore, the newly created FORT10 is not a stream file. but a simple formatted sequential file, and the WRITE fails because it contains a POS= clause. These details are not immediately evident when one looks at the WRITE statement, hence the possibility of confusion. Wording such as "'POS=' clause in WRITE to sequential formatted file FORT10" would alert the user to what went wrong and how to resolve the problem.
