[Bug libfortran/61173] [4.9/4.10 Regression] Erroneous "end of file" with internal read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61173 --- Comment #7 from Keith Refson --- Is it possible to say which version of gcc will contain the fix? It is not in the "gfortran.com" snapshot dated 20140528. Will this go in to the 4.9.1 release?
[Bug libfortran/61499] New: Internal read of negative integer broken in 4.9.0 on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61499 Bug ID: 61499 Summary: Internal read of negative integer broken in 4.9.0 on Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: krefson at gmail dot com Created attachment 32933 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32933&action=edit Source for testcase The attached file compiles bug gives erroneous results with fortran 4.9.0 and 4.9.1 gfortran -static-libgfortran -o internal2 internal2.f90 /usr/bin/ld: warning: -z ignore ignored. /usr/bin/ld: warning: -z record ignored. [kr@kohn gfortran-4.9.1]$ ./internal2 Error: Bad integer for item 2 in list input [kr@kohn gfortran-4.9.1]$ gfortran --version GNU Fortran (GCC) 4.9.1 20140611 (prerelease) Expected output (4.8.2) ./internal2.4.8.2 1 1 -1 1 -1 1 Note that this is closely related to bug #61173. That bug is fixed in the above version, but internal reads of integer data are still failing as in this case.
[Bug libfortran/61499] [4.9/4.10 Regression] Internal read of negative integer broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61499 --- Comment #9 from Keith Refson --- This fix checks out for the full code in context as well as the boiled-down example. Happy for this to be closed.
[Bug fortran/61927] Optimization bug (regression): Array comparison yields unassigned result at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61927 --- Comment #1 from Keith Refson --- Created attachment 33193 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33193&action=edit Testcase for array comparison optimization bug
[Bug fortran/61927] New: Optimization bug (regression): Array comparison yields unassigned result at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61927 Bug ID: 61927 Summary: Optimization bug (regression): Array comparison yields unassigned result at -O3 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: krefson at gmail dot com The attached code, which tests an allocatable array for nonzero values, works correctly when compiled at -O1 and -O3, but malfunctions at -O3. $ gfortran -O2 arrayop2.f90 $ ./a.out Symm_Nonzero TFFFTFFFT 3 TFFFTFFFT 3 TFFFFTFTF 3 TFFFFTFTF 3 TFFFTFFFT 3 TFFFTFFFT 3 TFFFFTFTF 3 TFFFFTFTF 3 $ ./a.out Symm_Nonzero TFFFTFFFT 3 FFFTTFFTT 4 TTTFTTFFT TFFTFTTFF FFTTFFTTT 5 TTTTTFFTT TTTTFFTTT TTFTTTTTT Running under valgrind reveals that some elements of the result array "symm_nonzero" contain uninitialized data in the -O3 case. This is a regression in 4.9.1. The code works correctly at -O3 under 4.8,2 uname -a Linux gibbs 3.12.21-desktop-2.mga4 #1 SMP Thu Jun 5 21:33:44 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ gfortran --version GNU Fortran (GCC) 4.9.1 20140709 (prerelease) Copyright (C) 2014 Free Software Foundation, Inc.
[Bug fortran/103045] New: False report substring out of bounds with -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103045 Bug ID: 103045 Summary: False report substring out of bounds with -fbounds-check Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: krefson at gmail dot com Target Milestone: --- Created attachment 51723 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51723&action=edit Test program The attached (correct) program generates an incorrect report of a substring bounds error when compiled with -fbounds-check. $ gfortran-10 -g -fbounds-check -fbacktrace debugtest.f90 $ ./a.out Fortran runtime error: Substring out of bounds: lower bound (0) of 'sf_string' is less than one Error termination. Backtrace: #0 0x7f9a46a8a744 in ??? #1 0x7f9a46a8b219 in ??? #2 0x7f9a46a8b82a in ??? #3 0x4009b4 in debugtest at /home/kr/CASTEP/Compiler_BUGS/Gfortran_Debug_False/debugtest.f90:10 #4 0x400c86 in main at /home/kr/CASTEP/Compiler_BUGS/Gfortran_Debug_False/debugtest.f90:14 This occurs with gcc-fortran version 8, 9, 10.
[Bug fortran/119800] New: Use of Fortran TRANSFER intrinsic with argument of derived type containing allocatable causes double-free abort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119800
Bug ID: 119800
Summary: Use of Fortran TRANSFER intrinsic with argument of
derived type containing allocatable causes double-free
abort
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: krefson at gmail dot com
Target Milestone: ---
Created attachment 6
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=6&action=edit
Fortran program source code demonstrating behaviour with TRANSFER intrinsic
Passing a derived type as the first argument to the TRANSFER intrinsic is
arguably a bug in the Fortran standard, but gfortran's handling of it is
sub-optimal. (Compiling without complaint, but causing run-time memory issues).
program transfer_test
type mytype
real, allocatable, dimension(:) :: c
end type mytype
type(mytype) :: a, b
allocate(a%c(8))
b = transfer(a, b)
write(*,*) 'Storage (as integer) of a = ',
storage_size(a)/storage_size('a')
write(*,*) 'Storage (as integer) of b = ',
storage_size(b)/storage_size('a')
print *, 'Allocation status(a,b)=', allocated(a%c),allocated(b%c)
if( allocated(b%c)) deallocate(b%c)
print *, 'Allocation status(a,b)=', allocated(a%c),allocated(b%c)
if( allocated(a%c)) deallocate(a%c)
end program transfer_test
Following the TRANSFER statement the allocatable in the output argument, a,
becomes associated with the same storage as the input argument. A subsequent
DEALLOCATE of both causes a double-free error.
A slightly more comprehensive test program is attached
See also my posting to fortran-lang
Other compilers also show a variety of undefined behaviour. flang for example
manages to deallocate the input variable, but also generates a double-free
error.
I suggest at least issuing a warning to expect undefined run-time behaviour!
[Bug fortran/119800] Use of Fortran TRANSFER intrinsic with argument of derived type containing allocatable causes storage aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119800 --- Comment #3 from Keith Refson --- I think it probably also needs to flag up if MOLD contains an allocatable or pointer component too. Modifying the example to TRANSFER to an integer, followed by a second TRANSFER with SOURCE= as an integer array and MOLD as the type, should warn on both instances.
[Bug fortran/119800] Use of Fortran TRANSFER intrinsic with argument of derived type containing allocatable causes storage aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119800 --- Comment #7 from Keith Refson --- Yes, definitely. Any scalar with an ultimate allocatable component should be warned about.
