Launchpad has imported 15 comments from the remote bug at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43551.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://documentation.ubuntu.com/launchpad/user/reference/bugs/multi-project-bugs/about-multi-project-bugs/#bugs-in-external-trackers. ------------------------------------------------------------------------ On 2010-03-27T19:34:09+00:00 Burnus-gcc wrote: Quantum Espresso (http://www.quantum-espresso.org/download.php) is miscompiled, cf. http://www.democritos.it/pipermail/pw_forum/2010-March/016356.html Fetch code, configure with F77=gfortran F90=gfortran and compile. Run the example02 and compare the output for "ph.x < si.dynG" with the reference, with an other compiler or with gfortran 4.3. Compare e.g. the "Dielectric constant" matrix. The error is about 10%; for the "Effective charges" it is even larger. I am currently hunting the regression and then will try to reduce the code. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/562597/comments/0 ------------------------------------------------------------------------ On 2010-03-27T19:41:19+00:00 Rguenth wrote: This is very little information. What target, what set of optimization options? Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/562597/comments/1 ------------------------------------------------------------------------ On 2010-03-27T19:52:11+00:00 Burnus-gcc wrote: Working: 2009-04-05-r145558 Failing: 2009-04-06-r145580 Changelog shows a couple of I/O patches - and indeed if one uses the working version with the current 4.4.4 libgfortran the bug is also present. Now, I need to find a minimal example. The I/O patch I suspect is: PR fortran/38654 http://gcc.gnu.org/viewcvs?view=rev&revision=145571 Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/562597/comments/2 ------------------------------------------------------------------------ On 2010-03-27T20:56:28+00:00 Burnus-gcc wrote: No success so far; I will try it tomorrow. To reproduce: Fetch, as written in comment 0, the source code and untar it. ./configure F77=gfortran F90=gfortran FFLAGS_NOOPT='-O0 -g' BLAS_LIBS=-lblas LAPACK_LIBS=-llapack FFLAGS='-O1 -g' && make pwall cd ../espresso-4.1.1; ln -s ../espresso-4.1.2/bin . cd examples/example02; ./run_example # abort while: "running the phonon calculation at Gamma for Si..." You now need and should have: a) results/si.phG.in b) $HOME/tmp/si.wfc and $HOME/tmp/si.save (You can delete all other files under $HOME/tmp/ and under results.) Those files are identical with failing and working libgfortran. Run now: ../../../bin/ph.x < si.phG.in The wrong output is in ./si.dynG, stdout and in $HOME/tmp/_phsi.phsave/data-file.xml* Wrong output can for instance be found in *.xml.1 for item "<DIELECTRIC_CONSTANT ...". The first value should be around 1.380642769884322E+001 and wrong is around 1.283252593899003E+001. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/562597/comments/3 ------------------------------------------------------------------------ On 2010-03-27T21:43:47+00:00 Burnus-gcc wrote: Just another data point: I have disabled the format caching (format_cache_ok = false in io/format.c), but it did not seem to help (on the trunk). Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/562597/comments/4 ------------------------------------------------------------------------ On 2010-03-27T21:55:48+00:00 Rguenth wrote: Fortran. P4. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/562597/comments/5 ------------------------------------------------------------------------ On 2010-03-27T22:22:34+00:00 Burnus-gcc wrote: The XML reading seems to be OK - at least I have added some write statements to iotk_dat.spp (at the "dat =" lines; then "make update" before clean & build) and the output is the same for the 2009-04-05 and the trunk libgfortran. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/562597/comments/6 ------------------------------------------------------------------------ On 2010-03-28T03:02:47+00:00 Jvdelisle2 wrote: I am not able to help here until probably Monday night. Turning off format caching is very easy for debugging purposes. I will keep an eye on this until I can get to a workstation I can use. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/562597/comments/7 ------------------------------------------------------------------------ On 2010-03-28T08:19:15+00:00 Burnus-gcc wrote: (In reply to comment #7) > Turning off format caching is very easy for debugging purposes. I tried this (see comment 4), but it did not seem to help. I now added a printf for "*(GFC_REAL_8 *)dest, buffer" in read_f, but "dest" is the same with libgfortran 4.3.x and 4.5. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/562597/comments/8 ------------------------------------------------------------------------ On 2010-03-28T08:52:04+00:00 Burnus-gcc wrote: The issue seems to be the buffering. If one uses GFORTRAN_UNBUFFERED_ALL=1 the result is correct, without it is not. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/562597/comments/9 ------------------------------------------------------------------------ On 2010-03-28T11:56:10+00:00 Burnus-gcc wrote: And the culprit is unit 30 ("$HOME/tmp/_phsi.ebar" alias unit=iuebar), which is a binary file (672000 bytes), which is automatically deleted (PH/close_phq.f90). The file is opened with: form='unformatted', access='direct', recl=22400 (= 2800 * DIRECT_IO_FACTOR w/ DIRECT_IO_FACTOR = 8 for real(8).) * * * ! Test case: implicit none integer, parameter :: size = 2800 ! << needs to be large enough real(8) :: vec1(size,30), dummy(size) integer i CALL RANDOM_NUMBER(vec1) open(99, file='test.dat', form='unformatted', access='direct', recl=size*8) do i = 1, 10 write(99,rec=i) vec1(:,i) write(99,rec=i+10) vec1(:,i+10) write(99,rec=i+20) vec1(:,i+20) end do do i = 1, 10 read(99,rec=i) dummy if (any (dummy /= vec1(:,i))) call abort() read(99,rec=i+10) dummy if (any (dummy /= vec1(:,i+10))) call abort() read(99,rec=i+20) dummy if (any (dummy /= vec1(:,i+20))) call abort() ! << aborts here for rec = 21 end do close(99, status='delete') end * * * Closer examination shows that reading rec = 1, rec = 11, rec = 21 returns the record 1, 11, 30. That is: The third read returns the *last* record instead of the 21th! Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/562597/comments/10 ------------------------------------------------------------------------ On 2010-03-28T17:12:33+00:00 Burnus-gcc wrote: Mine. I have a patch: http://gcc.gnu.org/ml/fortran/2010-03/msg00190.html Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/562597/comments/11 ------------------------------------------------------------------------ On 2010-03-29T06:17:32+00:00 Burnus-gcc wrote: Subject: Bug 43551 Author: burnus Date: Mon Mar 29 06:17:19 2010 New Revision: 157792 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157792 Log: 2010-03-29 Tobias Burnus <[email protected]> PR fortran/43551 * io/unix.c (buf_write): Set physical_offset after lseek. 2010-03-29 Tobias Burnus <[email protected]> PR fortran/43551 * gfortran.dg/direct_io_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/direct_io_12.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/unix.c Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/562597/comments/12 ------------------------------------------------------------------------ On 2010-03-29T06:18:25+00:00 Burnus-gcc wrote: Subject: Bug 43551 Author: burnus Date: Mon Mar 29 06:18:16 2010 New Revision: 157793 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157793 Log: 2010-03-29 Tobias Burnus <[email protected]> PR fortran/43551 * io/unix.c (buf_write): Set physical_offset after lseek. 2010-03-29 Tobias Burnus <[email protected]> PR fortran/43551 * gfortran.dg/direct_io_12.f90: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/direct_io_12.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/libgfortran/ChangeLog branches/gcc-4_4-branch/libgfortran/io/unix.c Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/562597/comments/13 ------------------------------------------------------------------------ On 2010-03-29T06:20:22+00:00 Burnus-gcc wrote: FIXED. Reminder: If one has an older version than today's, the work around is to set the environment variable GFORTRAN_UNBUFFERED_ALL=1 Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/562597/comments/14 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/562597 Title: in gfortran, buffered direct I/O reads wrong record To manage notifications about this bug go to: https://bugs.launchpad.net/gcc/+bug/562597/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
