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

2010-08-02 Thread 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



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

2010-08-01 Thread 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

2010-08-01 Thread 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

2010-07-31 Thread 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

2010-07-31 Thread 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 
 #include "io.h"
 #include "unix.h"
+#include 


 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

2010-07-30 Thread 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

2010-07-30 Thread 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

2010-07-30 Thread 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|-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

2010-07-29 Thread 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

2010-07-29 Thread 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 *, "
> 

[...@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

[...@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
[...@gnu-1 gfortran]$ ./a.out 
   1
Aborted
[...@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