[Bug middle-end/45131] New: [4.6 regression] New test failures configured with --with-cpu=atom

[Bug middle-end/45131] New: [4.6 regression] New test failures configured with --with-cpu=atom

[hjl dot tools at gmail dot com]

On Linux/x86-64, when configured with

--with-cpu=atom --enable-clocale=gnu --with-system-zlib --enable-shared
--with-demangler-in-ld -with-plugin-ld=ld.gold --enable-gold --with-fpmath=sse 

revision 162667 gave

FAIL: gfortran.dg/inquire_size.f90  -O0  execution test
FAIL: gfortran.dg/inquire_size.f90  -O1  execution test
FAIL: gfortran.dg/inquire_size.f90  -O2  execution test
FAIL: gfortran.dg/inquire_size.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/inquire_size.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/inquire_size.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/inquire_size.f90  -O3 -g  execution test
FAIL: gfortran.dg/inquire_size.f90  -Os  execution test
FAIL: gfortran.dg/streamio_10.f90  -O0  execution test
FAIL: gfortran.dg/streamio_10.f90  -O1  execution test
FAIL: gfortran.dg/streamio_10.f90  -O2  execution test
FAIL: gfortran.dg/streamio_10.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/streamio_10.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/streamio_10.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/streamio_10.f90  -O3 -g  execution test
FAIL: gfortran.dg/streamio_10.f90  -Os  execution test
FAIL: gfortran.dg/streamio_15.f90  -O0  execution test
FAIL: gfortran.dg/streamio_15.f90  -O1  execution test
FAIL: gfortran.dg/streamio_15.f90  -O2  execution test
FAIL: gfortran.dg/streamio_15.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/streamio_15.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/streamio_15.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/streamio_15.f90  -O3 -g  execution test
FAIL: gfortran.dg/streamio_15.f90  -Os  execution test
FAIL: gfortran.dg/streamio_16.f90  -O0  execution test
FAIL: gfortran.dg/streamio_16.f90  -O1  execution test
FAIL: gfortran.dg/streamio_16.f90  -O2  execution test
FAIL: gfortran.dg/streamio_16.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/streamio_16.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/streamio_16.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/streamio_16.f90  -O3 -g  execution test
FAIL: gfortran.dg/streamio_16.f90  -Os  execution test
FAIL: gfortran.dg/streamio_8.f90  -O0  execution test
FAIL: gfortran.dg/streamio_8.f90  -O1  execution test
FAIL: gfortran.dg/streamio_8.f90  -O2  execution test
FAIL: gfortran.dg/streamio_8.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/streamio_8.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/streamio_8.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/streamio_8.f90  -O3 -g  execution test
FAIL: gfortran.dg/streamio_8.f90  -Os  execution test
FAIL: gfortran.fortran-torture/execute/inquire_3.f90 execution,  -O0
FAIL: gfortran.fortran-torture/execute/inquire_3.f90 execution,  -O1
FAIL: gfortran.fortran-torture/execute/inquire_3.f90 execution,  -O2
FAIL: gfortran.fortran-torture/execute/inquire_3.f90 execution,  -O2
-fbounds-check
FAIL: gfortran.fortran-torture/execute/inquire_3.f90 execution,  -O2
-fomit-frame-pointer -finline-functions
FAIL: gfortran.fortran-torture/execute/inquire_3.f90 execution,  -O2
-fomit-frame-pointer -finline-functions -funroll-loops
FAIL: gfortran.fortran-torture/execute/inquire_3.f90 execution,  -O3 -g
FAIL: gfortran.fortran-torture/execute/inquire_3.f90 execution,  -Os
FAIL: gfortran.fortran-torture/execute/inquire_3.f90 execution, -O2
-ftree-vectorize -msse2
FAIL: gfortran.fortran-torture/execute/inquire_4.f90 execution,  -O0
FAIL: gfortran.fortran-torture/execute/inquire_4.f90 execution,  -O1
FAIL: gfortran.fortran-torture/execute/inquire_4.f90 execution,  -O2
FAIL: gfortran.fortran-torture/execute/inquire_4.f90 execution,  -O2
-fbounds-check
FAIL: gfortran.fortran-torture/execute/inquire_4.f90 execution,  -O2
-fomit-frame-pointer -finline-functions
FAIL: gfortran.fortran-torture/execute/inquire_4.f90 execution,  -O2
-fomit-frame-pointer -finline-functions -funroll-loops
FAIL: gfortran.fortran-torture/execute/inquire_4.f90 execution,  -O3 -g
FAIL: gfortran.fortran-torture/execute/inquire_4.f90 execution,  -Os
FAIL: gfortran.fortran-torture/execute/inquire_4.f90 execution, -O2
-ftree-vectorize -msse2

Revision 162619 is OK.


-- 
           Summary: [4.6 regression] New test failures configured with --
                    with-cpu=atom
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl dot tools at gmail dot com


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

[Bug middle-end/45131] [4.6 regression] New test failures configured with --with-cpu=atom

[hjl dot tools at gmail dot com]

------- Comment #1 from hjl dot tools at gmail dot com  2010-07-29 14:12 -------
It may be caused by revision 162653:

http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg01007.html


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davidxl at gcc dot gnu dot
                   |                            |org
   Target Milestone|---                         |4.6.0


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

[Bug middle-end/45131] [4.6 regression] New test failures configured with --with-cpu=atom

[hjl dot tools at gmail dot com]

------- Comment #2 from hjl dot tools at gmail dot com  2010-07-29 14:16 -------
It happened between revision 162661 and revision 162667.


-- 

hjl dot tools at gmail dot com changed:

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


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

[Bug middle-end/45131] [4.6 regression] New test failures configured with --with-cpu=atom

[hjl dot tools at gmail dot com]

------- Comment #3 from hjl dot tools at gmail dot com  2010-07-29 14:19 -------
It is caused by revision 162667:

http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg01021.html


-- 

hjl dot tools at gmail dot com changed:

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


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

[Bug middle-end/45131] [4.6 regression] New test failures configured with --with-cpu=atom

[burnus at gcc dot gnu dot org]

------- Comment #4 from burnus at gcc dot gnu dot org  2010-07-29 14:55 -------
HJ, as it works on most systems, can you do some debugging?

a) Does the system has HAVE_TTYNAME defined for libgfortran/ ?

b) If it fails in the library, how? Otherwise: Which of the asserts fails in
the test case? Can you replace for the failing line the "call abort()" by
"print *, <variable name>"

I assume, all the failures have the same cause thus it should be sufficient to
only analyze one.


-- 


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

[Bug fortran/45131] [4.6 regression] New Fortran test failures

[hjl dot tools at gmail dot com]

------- Comment #5 from hjl dot tools at gmail dot com  2010-07-29 15:47 -------
(In reply to comment #4)
> HJ, as it works on most systems, can you do some debugging?

Trunk was broken since yesterday and was fixed a while ago.

> a) Does the system has HAVE_TTYNAME defined for libgfortran/ ?

Yes.

> b) If it fails in the library, how? Otherwise: Which of the asserts fails in
> the test case? Can you replace for the failing line the "call abort()" by
> "print *, <variable name>"
> 

[hjl@gnu-1 gfortran]$ cat inquire_3.f90
! pr14836
       OPEN(UNIT=9, ACCESS='DIRECT', RECL=80, FORM='UNFORMATTED')
       INQUIRE(UNIT=9,NEXTREC=NREC)
       WRITE(UNIT=9,REC=5) 1
       INQUIRE(UNIT=9,NEXTREC=NREC)
       PRINT*,NREC
       IF (NREC.NE.6) CALL ABORT
       READ(UNIT=9,REC=1) MVI
       INQUIRE(UNIT=9,NEXTREC=NREC)
       PRINT*,NREC
       IF (NREC.NE.2) CALL ABORT
       CLOSE(UNIT=9,STATUS='DELETE')
       END

[hjl@gnu-1 gfortran]$
/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/gfortran/../../gfortran
-B/export/gnu/import/svn/gcc-test/bld/gcc/testsuite/gfortran/../../
inquire_3.f90  -w  -O0  
-B/export/gnu/import/svn/gcc-test/bld/i686-linux/./libgfortran/.libs
-L/export/gnu/import/svn/gcc-test/bld/i686-linux/./libgfortran/.libs
-L/export/gnu/import/svn/gcc-test/bld/i686-linux/./libgfortran/.libs
-L/export/gnu/import/svn/gcc-test/bld/i686-linux/./libiberty  -lm -static
[hjl@gnu-1 gfortran]$ ./a.out 
           1
Aborted
[hjl@gnu-1 gfortran]$ 


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.6 regression] New test   |[4.6 regression] New Fortran
                   |failures configured with -- |test failures
                   |with-cpu=atom               |


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

[Bug fortran/45131] [4.6 regression] New Fortran test failures

[jvdelisle at gcc dot gnu dot org]

------- Comment #6 from jvdelisle at gcc dot gnu dot org  2010-07-30 01:49 -------
This is really odd because the patch does not touch these parts of the library,
at least for inquire_3.f90. I wonder if there is something latent here.


-- 


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

[Bug fortran/45131] [4.6 regression] New Fortran test failures

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2010-07-30 09:32 -------
I see the same with -m32 on x86_64.  Interestingly I see it with -O0
and libgfortran from 4.5 as well, so it looks like a frontend problem, not
a library problem to me.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-07-30 09:32:24
               date|                            |


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

[Bug fortran/45131] [4.6 regression] New Fortran test failures

[jvdelisle at gcc dot gnu dot org]

------- Comment #8 from jvdelisle at gcc dot gnu dot org  2010-07-30 14:06 -------
#7 confirms my suspicions. I will try to have a look into this in the next few
days.  If anyone else has time, please do.


-- 


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

[Bug fortran/45131] [4.6 regression] New Fortran test failures

[burnus at gcc dot gnu dot org]

------- Comment #9 from burnus at gcc dot gnu dot org  2010-07-30 15:11 -------
I can also reproduce it with -m32 and x86-64. The dump looks OK; if one uses a
debugger, one sees that in inquire_via_unit:
   u->last_record == 0 - instead of the expect "5".
but u->flags.access == ACCESS_DIRECT as expected.

I wonder whether the information somehow gets lost due to the new "fn spec"
settings for trans-io.c (..._with_spec) - though using ".w" looks ok -
additionally, I do not see how the FE could modify the libraries' unit data in
such a way.

Side question: Why is st_inquire actually listed as returning an integer if it
is void?
 362   parm_type = build_pointer_type
(st_parameter[IOPARM_ptype_inquire].type);
 363   iocall[IOCALL_INQUIRE] = gfc_build_library_function_decl_with_spec (
 364         get_identifier (PREFIX("st_inquire")), ".w",
 365         gfc_int4_type_node, 1, parm_type);


Ditto for st_iolength_done, st_flush, st_endfile, st_backspace, st_rewind, and
st_wait


-- 

burnus at gcc dot gnu dot org changed:

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


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

[Bug fortran/45131] [4.6 regression] New Fortran test failures

[jvdelisle at gcc dot gnu dot org]

------- Comment #10 from jvdelisle at gcc dot gnu dot org  2010-07-31 16:28 -------
I can see one here on a 32 bit machine. Moving string.h down in the file as
noted by David Edelsohn fixes it.  I also changed the return type to void in
trans-io.c.

Index: inquire.c
===================================================================
--- inquire.c   (revision 162724)
+++ inquire.c   (working copy)
@@ -26,9 +26,9 @@

 /* Implement the non-IOLENGTH variant of the INQUIRY statement */

-#include <string.h>
 #include "io.h"
 #include "unix.h"
+#include <string.h>


 static const char undefined[] = "UNDEFINED";


-- 

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-07-30 09:32:24         |2010-07-31 16:28:49
               date|                            |


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

[Bug fortran/45131] [4.6 regression] New Fortran test failures

[jvdelisle at gcc dot gnu dot org]

------- Comment #11 from jvdelisle at gcc dot gnu dot org  2010-07-31 17:04 -------
I see the problem with 4.4.3 as well. I think the patch in #10 is only masking
it.


-- 


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

[Bug fortran/45131] [4.6 regression] New Fortran test failures

[jvdelisle at gcc dot gnu dot org]

------- Comment #12 from jvdelisle at gcc dot gnu dot org  2010-08-01 17:28 -------
This appears to be fixed now from the commit of patch in #10.  The related
failures showing in gcc test results are no longer there.


-- 


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

[Bug fortran/45131] [4.6 regression] New Fortran test failures

[burnus at gcc dot gnu dot org]

------- Comment #13 from burnus at gcc dot gnu dot org  2010-08-01 19:38 -------
(In reply to comment #12)
> This appears to be fixed now from the commit of patch in #10.

Which is the commit:

Date: Sat Jul 31 21:37:25 2010
New Revision: 162788

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162788
Log:
* io/inquire.c: Include io.h before string.h.

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


-- 


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

[Bug fortran/45131] [4.6 regression] New Fortran test failures

[jvdelisle at gcc dot gnu dot org]

------- Comment #14 from jvdelisle at gcc dot gnu dot org  2010-08-02 13:19 -------
Closing as fixed.  Regarding comment #7.  I do not see the problem on 4.5.  I
reran tests here on my machine that failed with 4.6 and there were no failures
on 4.5


-- 

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=45131