Fortran Why Won't GFORTRAN Versions Beyond 5.4 Compile with Optimization?

AI Thread Summary
Troubleshooting GFORTRAN versions beyond 5.4 reveals issues with optimization when compiling .f source files. The user notes that individual optimization flags do not yield the same performance as the composite -O1 flag, leading to significant differences in execution speed and behavior across platforms like Windows and MacOS. Profiling is suggested as a method to identify performance discrepancies, as recent file access can affect timing tests. The discussion emphasizes the importance of providing detailed information when reporting bugs, including compile commands, OS versions, and library versions, to facilitate effective troubleshooting. A specific issue with optimization flags has been identified, indicating that using -O in batch compilation introduces problems that affect performance, a concern noted in GFORTRAN versions starting from v6.x.
jelanier
Messages
67
Reaction score
1
TL;DR Summary
compiling with O level parameters individually does not equal O level
I am trying to troubleshoot why GFORTRAN versions beyond 5.4 will not compile with optimization on some of my .f source.
You can request options included in each level by:
Gfortran -Q -O1 --help=optimizers > listO1.txt (as an example)
When I enter the enabled flags individually and compile, they do not equal the -O1 composite. I know this by compiling and running a program using each example. Huge difference. What am I missing? Is this a major bug?

Thanks on advance

Jim
 
Technology news on Phys.org
Do you know how to compile to turn on profiling? You can run gprof for each compiled version.

Why am I suggesting this. Are you opening files - Linux puts recently opened files into memory buffers so version 1 will run more slowly when compared against version 2 (assuming it ran second from the same parent process - e.g., keyboard command line) - because 2 reads from memory. Other OSes do this, too. This is an example of how your timing test is likely to be confounded. Use profiling. And AFAIK the two should be very much the same.

See:: https://docs.oracle.com/cd/E19957-01/805-4940/6j4m1u7q6/index.html
 
jim mcnamara said:
Do you know how to compile to turn on profiling? You can run gprof for each compiled version.

Why am I suggesting this. Are you opening files - Linux puts recently opened files into memory buffers so version 1 will run more slowly when compared against version 2 (assuming it ran second from the same parent process - e.g., keyboard command line) - because 2 reads from memory. Other OSes do this, too. This is an example of how your timing test is likely to be confounded. Use profiling. And AFAIK the two should be very much the same.

See:: https://docs.oracle.com/cd/E19957-01/805-4940/6j4m1u7q6/index.html
That isn't it. I run this on Windows minGW and MacOS. Any compiled executable regardless order of execution has huge difference in speed and behavior. The composite Options -O -O2 -O3 will not work the same as when flags are individually added to compile batch.
 
http://www.mingw.org/Reporting_Bugs

Try reporting, you can search the bug list first. Especially since you have a cross-platform problem - Mac & Windows, they should respond quickly.

Helpful hint:
We would have been here a lot sooner here if you had provided those last bits of information. Testing & platform. You will have to give EXACT, complete information when reporting a bug. Or it will be ignored. That will include your compile command(s) and OS versions (and windows 10 current update), and library versions. Especially if you are linking against things like LAPACK. That broke optimizations a while back.
 
Last edited:
i have since found the culprit and I will report. I took the diff between -Og and -O1 . I then added those flags to -Og to make an equivalent -O1 and it works. So basically calling -O in the batch adds something screwy that kills it. This has been in Gfortran code on all versions starting with v6.x.

Later my friend,

Jim
 
Thread 'Is this public key encryption?'
I've tried to intuit public key encryption but never quite managed. But this seems to wrap it up in a bow. This seems to be a very elegant way of transmitting a message publicly that only the sender and receiver can decipher. Is this how PKE works? No, it cant be. In the above case, the requester knows the target's "secret" key - because they have his ID, and therefore knows his birthdate.
Back
Top