ping Re: [patch, libgfortran] PR105361 Incorrect end-of-file condition for derived-type I/O
On 7/22/24 8:13 AM, Jerry D wrote:
Hi all,
The attached patch fixes this by avoiding looking for and avoiding the
EOF condition in the parent READ after returning from the child IO process.
I could not think of a simple test case yet since the problem occurred
only when redirecting the input to the test program via a pipe. If I
have some more time today I will try to come up with something.
OK for mainline?
Jerry
commit e6fa9d84cf126630c9ea744aabec6d7715087310 (HEAD -> master)
Author: Jerry DeLisle
Date: Sun Jul 21 19:19:00 2024 -0700
Fortran: Suppress wrong End Of File error with user defined IO.
libgfortran/ChangeLog:
PR libfortran/105361
* io/list_read.c (finish_list_read): Add a condition check for
a user defined derived type IO operation to avoid calling the
EOF error.
I failed to mention that this patch regression tests OK on x86_64.
I also developed the attached test case. This does reproduce the error.
I will update the log entry to reflect this test case.
OK for mainline?! { dg-do run }
module x
implicit none
type foo
real :: r
end type foo
interface read(formatted)
module procedure read_formatted
end interface read(formatted)
contains
subroutine read_formatted (dtv, unit, iotype, vlist, iostat, iomsg)
class (foo), intent(inout) :: dtv
integer, intent(in) :: unit
character (len=*), intent(in) :: iotype
integer, intent(in) :: vlist(:)
integer, intent(out) :: iostat
character (len=*), intent(inout) :: iomsg
read (unit,*,iostat=iostat,iomsg=iomsg) dtv%r
!print *,dtv%r
end subroutine read_formatted
end module x
program main
use x
implicit none
type(foo) :: a, b
real :: c, d
open(10, access="stream")
write(10) "1 2" ! // NEW_LINE('A')
close(10)
open(10)
read(10,*) c, d
if ((c /= 1.0) .or. (d /= 2.0)) stop 1
rewind(10)
!print *, c,d
read (10,*) a, b
close(10, status="delete")
if ((a%r /= 1.0) .or. (b%r /= 2.0)) stop 2
!print *, a,b
end program main
Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic
Bumping the topic. Since this patch exclusively affects powerpc-darwin, and I think we agree that it does not add regressions with tests (no tests which passed without it fail with it), perhaps it can be merged? It would be great to have it in gcc 15 when it is released, otherwise we will need to wait for the next major version. Once we have the initial support for this, it can be improved further on. P. S. If someone else could run tests also, that would be great. On Sun, Jul 7, 2024 at 12:15 AM Sergey Fedorov wrote: > > On Sat, Jul 6, 2024 at 6:07 AM FX Coudert wrote: > >> > This part of the patch is quite old, but from the remaining log it >> looks I got an error here: >> > Now on a second thought, this did not require a fix perhaps. We can >> drop it. >> >> I have addressed this: >> https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656484.html >> The test should now be run on all targets, regardless of the >> issignaling() macro availability. >> > > Awesome, thank you. I have updated my patch, dropping the change to the > test now. > > >> > By the way, do we have some point of comparison from other ppc32 >> platforms, Linux or BSD (for the recent gcc master)? >> >> You can have a look at testresults here: >> https://gcc.gnu.org/pipermail/gcc-testresults/ >> > > I checked submissions for several months, but did not find non-Darwin > ppc32 ones. Too old ones won't be of much utility for the sake of > comparison. > Someone on OpenBSD ppc list helped me with running the tests on ppc32, but > with gcc11, since building from master did not work. I am not sure whether > gcc11 results are comparable. FWIW, on OpenBSD there were 185 unexpected > failures, 9 unresolved and 473 unsupported. > > Sergey >
Re: ping Re: [patch, libgfortran] PR105361 Incorrect end-of-file condition for derived-type I/O
Hi Jerry, I also developed the attached test case. This does reproduce the error. I will update the log entry to reflect this test case. OK for mainline? OK, and thanks for the patch! Best regards Thomas
