[Bug fortran/80741] New: incorrect behaviour of rewind with namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80741 Bug ID: 80741 Summary: incorrect behaviour of rewind with namelist Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: james.s.spencer at gmail dot com Target Milestone: --- Created attachment 41353 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41353&action=edit test case Rewind does not appear to work correctly if end of file has been reached and the file contains a namelist. With the attached file I get with gfortran 7.1.0: &TEST X= 10, Y= 10, / done eof &TEST X= 0, Y= 0, / X= gfortran 6.3.0 I get the behaviour I expect (namelist set on both passes and after reading the namelist, the next record is the line after the namelist): &TEST X= 10, Y= 10, / done eof &TEST X= 10, Y= 10, / done
[Bug fortran/82869] New: c_associated does not always give false for null pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82869 Bug ID: 82869 Summary: c_associated does not always give false for null pointers Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: james.s.spencer at gmail dot com Target Milestone: --- I think if a pointer, p, is C_NULL_PTR then c_associated(p) should always return false. However, I do not see this with gfortran 7.2.0with -fsanitize=address or when the pointer is initialised when declared. $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp Thread model: posix gcc version 7.2.0 (GCC) $ cat test.f90 use, intrinsic :: iso_c_binding type(c_ptr) :: p p = c_null_ptr print *, '(Expect F) ', c_associated(p) end $ gfortran test.f90 && ./a.out (Expect F) F $ gfortran -fsanitize=address && ./a.out (Expect F) T Using -fsanitize=address changes the result. I only see this under (arch) linux, the behaviour on my mac laptop running macOS 10.13 with gfortran 7.2.0 is the expected case in both invocations. The behaviour under -fsanitize=address is not consistent though: $ cat test2.f90 use, intrinsic :: iso_c_binding type(c_ptr) :: p p = c_null_ptr print *, '(Expect F F) ', c_associated(p), c_associated(c_null_ptr) end $ gfortran test2.f90 && ./a.out (Expect F F) F F $ gfortran -fsanitize=address test2.f90 && ./a.out (Expect F F) F T Finally a case which I can reproduce on both linux and macOS 10.13 and doesn't involve -fsanitize=address: $ cat test3.f90 use, intrinsic :: iso_c_binding type(c_ptr) :: p = c_null_ptr print *, '(Expect F F) ', c_associated(p), c_associated(c_null_ptr) end $ gfortran test3.f90 && ./a.out (Expect F F) T T gfortran 6.3.0 (running on a Debian 9 machine) gives the expected result in all three cases.
[Bug sanitizer/82869] c_associated does not always give false for null pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82869 --- Comment #2 from james.s.spencer at gmail dot com --- (In reply to kargl from comment #1) > (In reply to james.s.spencer from comment #0) > > I think if a pointer, p, is C_NULL_PTR then c_associated(p) should always > > return false. However, I do not see this with gfortran 7.2.0with > > -fsanitize=address or when the pointer is initialised when declared. > > > > Not a gfortran problem. Re-assigning to sanitizer The third example occurs without the sanitizer enabled.
[Bug sanitizer/82869] c_associated does not always give false for null pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82869 --- Comment #11 from james.s.spencer at gmail dot com --- (In reply to Janne Blomqvist from comment #10) > Fixed now on the gcc-7 branch as well. Thanks James for reporting, and > Martin for bisecting! Thanks for the quick fix!
[Bug fortran/59781] New: Incorrect initialisation of derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59781
Bug ID: 59781
Summary: Incorrect initialisation of derived type
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: james.s.spencer at gmail dot com
Created attachment 31818
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31818&action=edit
Tarball containing example code, tree produced by gfortran 4.8.2 and Makefile.
(Complete modules and a makefile is attached. Also confirmed against 4.6.3)
With the definition
type dSFMT_t
private
type(c_ptr) :: dSFMT_state = c_null_ptr
real(c_double), allocatable :: random_store(:)
end type dSFMT_t
the dSFMT_t objects in the following module should both be initialised with a
null pointer for the dSFMT_state component:
module hilbert_space
implicit none
contains
subroutine test_rng()
use dSFMT_interface
type(dSFMT_t) :: rng
call dSFMT_init(7, 5, rng)
end subroutine test_rng
subroutine estimate_hilbert_space()
use dSFMT_interface
type(dSFMT_t) :: rng
call dSFMT_init(7, 5, rng)
end subroutine estimate_hilbert_space
end module hilbert_space
Instead only the rng object in estimate_hilbert_space is correctly initialised.
The relevant parts of the tree are:
estimate_hilbert_space ()
{
struct dsfmt_t rng;
try
{
{
struct dsfmt_t dsfmt_t.0;
dsfmt_t.0.dsfmt_state = 0B;
dsfmt_t.0.random_store.data = 0B;
rng = dsfmt_t.0;
}
[...]
}
}
test_rng ()
{
struct dsfmt_t rng;
try
{
rng.random_store.data = 0B;
[...]
}
}
This bug is tricky to observe---small changes to the code (e.g. making rng a
pointer, code reorganisation, having additional or fewer procedures in the same
file, removing the random_store allocatable component etc. can lead to the
dSFMT_t objects being correctly initialised. I had the above code (with
additions) in a large code base for several months until an innocuous
refactoring revealed it.
See also discussion at
https://groups.google.com/forum/#!topic/comp.lang.fortran/WogpvhUny4c, where
Janus posted a smaller example which breaks under gfortran trunk.
