[Q-e-developers] gfortran & Quantum Espresso: Bug & work around

[Paolo Giannozzi]

Dear Tobias

thank you for your message and for the precious info. The manual
will be updated accordingly. It may take some time before the
revised version percolates to the web site, though.

In the past I have submitted problems to the gfortran mailing list,
but it takes time to produce a serious (or even half serious) bug
report. It used to be easy to update to a new gfortran version
(without touching the op.sys) on my Mac, but now my version of
OS-X is no longer supported.

Please note the CC to q-e-developers at qe-forge.org, which will become
the new address for contacting QE developers. Best regards

Paolo

> Hello,
> 
> can you update the gfortran entry in the manual at 
> http://www.quantum-espresso.org/user_guide/node13.html#SECTION00036330000000000000
> 
> 
> a) Using gfortran versions 4.4 (after May 27, 2009) and 4.5 (after May 
> 5, 2009) can produce the wrong results, unless the environment variable 
> GFORTRAN_UNBUFFERED_ALL=1 is set. This bug will be fixed in the next 
> days thus newer 4.4/4.5 than today+few days should be OK.
> 
> Cf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43551
> 
> 
> b) The manual contains: "reading files produced by previous versions of 
> QUANTUM ESPRESSO may not work, apparently due to a gfortran bug"
> 
> That was not really a bug but a feature: gfortran used 64-bit record 
> markers to allow writing of records larger than 2 GB. Before with 32-bit 
> record markers only records <2GB could be written. However, this caused 
> problems with older files and inter-compiler operability. This was 
> solved in GCC 4.2 by using 32-bit record markers but such that one can 
> still store >2GB records (following the implementation of Intel). Thus 
> this issue should be gone. Cf. 4.2 release notes (item "Fortran") at 
> http://gcc.gnu.org/gcc-4.2/changes.html
> 
> 
> In general, it would be helpful if problems were reported to the 
> compiler vendor. Most of them are quite helpful and also throwing a 
> large piece of software at them will make them search for the problem. 
> (At least if accompanied with a good description of the problem and how 
> one can compile and reproduce it.)
> 
> Tobias,
> wearing his gfortran developer's hat - instead of his usual DFT hat.
> (I do not currently use Quantum Espresso but - being in Jülich - I use 
> FLEUR :-)


-- 
Paolo Giannozzi, Democritos and University of Udine, Italy