[Bug fortran/43320] New: [4.5 Regression] 200.sixtrack fails setup

[Bug fortran/43320] New: [4.5 Regression] 200.sixtrack fails setup

[rguenth at gcc dot gnu dot org]

-----------------------------------
  Running 200.sixtrack ref base default-linux default
Commands to run: 
    -u /gcc/spec/cpu2000/benchspec/CFP2000/200.sixtrack/run/00000003
    -i inp.in -o inp.out -e inp.err ../00000003/sixtrack_base.default-linux
Specinvoke: /gcc/spec/cpu2000/bin/specinvoke -d
/gcc/spec/cpu2000/benchspec/CFP2000/200.sixtrack/run/00000003 -e speccmds.err
-o speccmds.out -f speccmds.cmd
user 0 finished @ Wed Mar 10 02:39:46 2010.  Total elapsed time: 0.416101
comparing files in
'/gcc/spec/cpu2000/benchspec/CFP2000/200.sixtrack/run/00000003'
comparing 'inp.out' with cw='', abstol='0.0005',
reltol='0.0005',obiwan='',skiptol=''
Specinvoke: /gcc/spec/cpu2000/bin/specinvoke -E -d
/gcc/spec/cpu2000/benchspec/CFP2000/200.sixtrack/run/00000003 -c 1 -e
compare.err -o compare.out -f compare.cmd
*** Miscompare of inp.out, see
/gcc/spec/cpu2000/benchspec/CFP2000/200.sixtrack/run/00000003/inp.out.mis
1904:           From file fort.8 : 0  values read in.
                ++++++++++++++++++++++++
       ^
1905: 
-----------------------------------------------------------------------------------------------------------------------------------
                +++++ERROR DETECTED+++++
       ^
1906:                                            *** RING PARAMETERS ***
                ++++++++++++++++++++++++
       ^
1907:                               SINGLE ELEMENTS:
                RUN TERMINATED ABNORMALLY !!!
       ^
1910:    NO   NAME  TYP       1/RHO          STRENGTH          LENGTH          
X-POS          X-RMS            Z-PO          Z-RMS
                PROBLEM READING EXTERNAL MISALIGNMENTS
       ^
'inp.out' short


-- 
           Summary: [4.5 Regression] 200.sixtrack fails setup
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: x86-64-*-*, ia64-*-*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2010-03-10 12:35 -------
Last known good rev. 157294, first known bad rev. 157328 (x86_64).
Last known good rev. 157304, first known bad rev. 157331 (ia64).

Points at:

Index: libgfortran/ChangeLog
===================================================================
--- libgfortran/ChangeLog       (revision 157304)
+++ libgfortran/ChangeLog       (revision 157328)
@@ -1,3 +1,14 @@
+2010-03-09  Jerry DeLisle  <jvdelisle@gcc.gnu.org>
+
+       PR libfortran/43265
+       * io/read.c: Include fbuf.h and unix.h to enable lower level I/O for
+       read_x. (read_x): Replace the use of read_sf with equivalent lower
level
+       I/O, eliminating unneeded code and handling EOF and EOR conditions.
+       * io/io.h: Revise prototype for read_sf.
+       * io/transfer.c (read_sf): Delete no_error parameter and all uses of
it.
+       (read_block_form): Likewise.
+       (next_record_r): Delete wrong code call to hit_eof.
+


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu dot
                   |                            |org
          Component|fortran                     |libfortran
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2010-03-10 12:40 -------
Richard, how new is this regression? That is: Which check-ins could have causes
this?

Assuming that CPU SPEC is run every day, I assume that it is the patch for PR
43265; namely commit http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157310

Can you confirm this? If so, it must be some issue related to reading a file.
Thus, the line of the input file which fails and the corresponding format of
the READ statement are of interest.

Paul, I think you are the only gfortraner, which has access to SPEC CPU 2000.
Can you have a look?


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[paul dot richard dot thomas at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 549 bytes --]



------- Comment #3 from paul dot richard dot thomas at gmail dot com  2010-03-10 13:20 -------
Subject: Re:  [4.5 Regression] 200.sixtrack fails setup

Dear All,

>
> Paul, I think you are the only gfortraner, which has access to SPEC CPU 2000.
> Can you have a look?
>

I am still recuperating from the operation in the UK.  I do not have
SPEC on the laptop that I have with me.  I´ll be back in Barcelona on
Sunday night, however, and could look at it sometime next week.

Sorry

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl dot tools at gmail dot
                   |                            |com
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-03-10 14:01:39
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[burnus at gcc dot gnu dot org]

------- Comment #4 from burnus at gcc dot gnu dot org  2010-03-10 14:31 -------
The SixTrack souce code can be found at
http://lhc-collimation-project.web.cern.ch/lhc-collimation-project/code-tracking.htm
 Namely:
http://lhc-collimation-project.web.cern.ch/lhc-collimation-project/SixPack.zip

Regarding "1904:           From file fort.8 : 0  values read in."

That matches the file:
sixve.f:      open(8,file='fort.8',form='formatted',status='unknown')

And I see two reads for sixve.f (in "subroutine daten"):
        read(8,10020,end=1581)
                read(8,10020,end=1550,iostat=ierro) ch

which seemingly uses:
  10020 format(a80)
which looks harmless.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2010-03-10 14:39 -------
Reproduce using:
1. Grab SixTrack.zip (see comment 4)
2. Change in track.f, line 4411 in "(i,1x,..."  the "i" into an "i0"
3. Grab the input file
 http://lhc-collimation-project.web.cern.ch/lhc-collimation-project/InjPack.zip
   and unzip in the same directory
4. Compile by running: gfortran *.f

a) Run with the trunk's libgfortran. The result will be:
           Multipole errors read in from external file
[...]
         ++++++++++++++++++++++++
         +++++ERROR DETECTED+++++
         ++++++++++++++++++++++++
         RUN TERMINATED ABNORMALLY !!!

b) Run with an older libgfortran, e.g. the one from GCC 4.4. Result is
[...]
           Multipole errors read in from external file

         From file fort.16 :           0  values read in.

           Alignment errors read in from external file

         From file fort.8 :           0  values read in.
[...]


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[burnus at gcc dot gnu dot org]

------- Comment #6 from burnus at gcc dot gnu dot org  2010-03-10 14:52 -------
Reduced test case: Reading from a completely empty line should produce an EOF
status. As soon as there is a "\n" or " " or "0", ifort, NAG f95 and gfortran
4.3/4.5 also succeed (i.e. have no EOF error.)

That's kind of the opposite to the remaining problem of PR 43265, where reading
from an incomplete but non-empty line produces an error while it shouldn't.


      open(8,status='scratch',form='formatted')  ! Create empty file
      read(8,'(a80)', end=123)  ! Reading from an empty file should be an error
      stop 'error'
123   continue
      end


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2010-03-10 16:31 -------
Even though this is Fortran being able to build & run SPEC is release critical.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[jvdelisle at gcc dot gnu dot org]

------- Comment #8 from jvdelisle at gcc dot gnu dot org  2010-03-10 19:44 -------
I will get on this tonight.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2010-03-10 14:01:39         |2010-03-10 19:44:37
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[jvdelisle at gcc dot gnu dot org]

------- Comment #9 from jvdelisle at gcc dot gnu dot org  2010-03-10 20:21 -------
I am fairly sure its the hit_eof I removed from next_record_r in transfer.c. 
When I get to my work machine I will fix either by reverting or otherwise.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[jvdelisle at gcc dot gnu dot org]

------- Comment #10 from jvdelisle at gcc dot gnu dot org  2010-03-11 01:56 -------
I plan to commit the following as a compromise.  We have had several PRs here
that contradict.  Not surprising really.  The compromise is to use item_count
to decide whether to hit_eof or not.  We could also do this with a compiler
flag.  This patch allows the test case in comment 6 to hit the eof if we have
not read any data items.  At the other end of this is PR26661 and PR26880.

All of these involve missing EOR at the end of a file.  Some want the EOF to be
interpreted as the EOR and some don't.  As a follow-up patch I am wondering if
we should treat the missing EOR at EOF as an EOR with -std=legacy and default
to giving an EOF otherwise.  In the meantime, this patch keeps things running
and really is not too unreasonable, though it seems hackish.  At least we know
where to make the tweaks if we choose to do so.

Index: transfer.c
===================================================================
--- transfer.c  (revision 157310)
+++ transfer.c  (working copy)
@@ -2810,6 +2810,8 @@
                {
                   if (errno != 0)
                     generate_error (&dtp->common, LIBERROR_OS, NULL);
+                 else if (dtp->u.p.item_count == 1)
+                   hit_eof (dtp);
                  break;
                 }



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[jvdelisle at gcc dot gnu dot org]

------- Comment #11 from jvdelisle at gcc dot gnu dot org  2010-03-11 02:15 -------
Subject: Bug 43320

Author: jvdelisle
Date: Thu Mar 11 02:15:33 2010
New Revision: 157377

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157377
Log:
2010-03-10  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR libfortran/43320
        * io/transfer.c (next_record_r): Add hit_eof based on item_count
        condition.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/transfer.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[jvdelisle at gcc dot gnu dot org]

------- Comment #12 from jvdelisle at gcc dot gnu dot org  2010-03-11 02:26 -------
Subject: Bug 43320

Author: jvdelisle
Date: Thu Mar 11 02:26:36 2010
New Revision: 157378

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157378
Log:
2010-03-10  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR libfortran/43320
        PR libfortran/43265
        * gfortran.dg/read_eof_6.f: New test
        * gfortran.dg/read_x_eof.f90: Update test.
        * gfortran.dg/read_x_past.f: Update test.

Added:
    trunk/gcc/testsuite/gfortran.dg/read_eof_6.f
    trunk/gcc/testsuite/gfortran.dg/read_x_eof.f90
Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/read_x_past.f


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[burnus at gcc dot gnu dot org]

------- Comment #13 from burnus at gcc dot gnu dot org  2010-03-11 11:08 -------
(In reply to comment #10)
> I plan to commit the following as a compromise.  We have had several PRs here
> that contradict.

I am not sure whether the PRs really contradict as they just ask "do what the
other compilers do", which is arguably not well defined but non-contradicting
so far - the standard is (on purpose) not very explicit, unfortunately.
(Fortunately, ifort, openf95, NAG f95 give the same result so far - and only
for few special cases, gfortran does not.)

> All of these involve missing EOR at the end of a file.  Some want the EOF to
> be interpreted as the EOR and some don't. As a follow-up patch I am wondering
> if we should treat the missing EOR at EOF as an EOR with -std=legacy and
> default to giving an EOF otherwise.

I am extremely unhappy about different run-time behaviour depending on some
compile-time flags as it causes differences, which are extremely difficult to
pin point - both for the users and for us during bug reports.

The common notion seems to be: If there is any character read before <eof>,
that's a normal record and reading e.g. "(a80)" or "(100x)" or "(i20)"  is
allowed. If there is no character, not even a "\n", reading anything implies
EOF.

 * * *

Can this PR now be closed?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[jvdelisle at gcc dot gnu dot org]

------- Comment #14 from jvdelisle at gcc dot gnu dot org  2010-03-11 14:20 -------
If someone confirms SPEC is cleared, please close.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[hjl dot tools at gmail dot com]

------- Comment #15 from hjl dot tools at gmail dot com  2010-03-11 14:24 -------
You can find my SPEC CPU pass/fail results at

http://gcc.gnu.org/ml/gcc-testresults/

The last one is

http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg00855.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[jvdelisle at gcc dot gnu dot org]

------- Comment #16 from jvdelisle at gcc dot gnu dot org  2010-03-11 14:35 -------
Closing.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320

[Bug libfortran/43320] [4.5 Regression] 200.sixtrack fails setup

[jvdelisle at gcc dot gnu dot org]

------- Comment #17 from jvdelisle at gcc dot gnu dot org  2010-03-12 14:36 -------
Subject: Bug 43320

Author: jvdelisle
Date: Fri Mar 12 14:36:16 2010
New Revision: 157405

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157405
Log:
2010-03-12  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR libfortran/43320
        PR libfortran/43265
        * gfortran.dg/read_eof_6.f: New test
        * gfortran.dg/read_x_eof.f90: New test.
        * gfortran.dg/read_x_past.f: Update test.

Added:
    branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/read_eof_6.f
    branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/read_x_eof.f90
Modified:
    branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/read_x_past.f


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43320