[Bug fortran/66227] [OOP] EXTENDS_TYPE_OF n returns wrong result for polymorphic variable allocated to extended type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66227 --- Comment #2 from patnel97269-gfortran at yahoo dot fr --- Yes the first and third should be True as i understand.
[Bug fortran/66227] New: [OOP] EXTENDS_TYPE_OF n returns wrong result for polymorphic variable allocated to extended type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66227 Bug ID: 66227 Summary: [OOP] EXTENDS_TYPE_OF n returns wrong result for polymorphic variable allocated to extended type Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: patnel97269-gfortran at yahoo dot fr Target Milestone: --- Hi, The extends_type_of intrisic return the wrong value for the a polymorphic variable allocated to a daughter class. See small code below. Code tested on version 5.1.0 . implicit none type t1 integer :: a end type t1 type, extends(t1):: t11 integer :: b end type t11 type(t1) a1 type(t11) a11 class(t1), allocatable :: b1,bb1 class(t11), allocatable :: b11 allocate(t11::b1) print *, extends_type_of(b1,a11) ! T print *, extends_type_of(b1,a1) ! T deallocate(b1) allocate(b1,source=a11) print *, extends_type_of(b1,a11) ! T print *, extends_type_of(b1,a1) ! T allocate( b11,source=a11) print *, extends_type_of(b11,a11) ! T print *, extends_type_of(b11,a1) ! T allocate( bb1,source=a1) print *, extends_type_of(bb1,a11) ! F print *, extends_type_of(bb1,a1) ! T end
[Bug fortran/58175] [OOP] Incorrect warning message on scalar finalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58175 patnel97269-gfortran at yahoo dot fr changed: What|Removed |Added CC||patnel97269-gfortran@yahoo. ||fr --- Comment #4 from patnel97269-gfortran at yahoo dot fr --- I still have this bug in 4.9.2 . Why not committing the patch ?
[Bug fortran/64397] [OOP] Runtime segfault with parenthesis expression passed to polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397 --- Comment #7 from patnel97269-gfortran at yahoo dot fr --- (In reply to janus from comment #6) > (In reply to patnel97269-gfortran from comment #5) > > I agree that this example still trigger a bug, but I remember in my original > > (more complicated) code, the segfault appears when it tries to access the > > allocatable components of the type in the subroutine > > Are you sure? In my debugging sessions, it always seemed like the segfault > happened after the subroutine call. My bad, can't reproduce that. Appears to be in between the a multiplication call and the assignment call, so at the return.
[Bug fortran/64397] [OOP] Runtime segfault with parenthesis expression passed to polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397 --- Comment #5 from patnel97269-gfortran at yahoo dot fr --- (In reply to janus from comment #3) > Actually one can reduce it even further: > > > program main > > type :: my_integer > real, allocatable :: x(:) > end type > type(my_integer) :: a > > a=my_integer([1]) > write (*,*) "A" > call ass(a) > write (*,*) "B" > call ass((a)) > write (*,*) "C" > > contains > > subroutine ass(b) > class(my_integer), intent(in) :: b > print *,'called ass' > end subroutine > > end > > > This program does not do anything useful any more, but it still shows the > same segfault at/after the call to "ass((a))": > > $ ./a.out > A > called ass > B > called ass > > Program received signal SIGSEGV: Segmentation fault - invalid memory > reference. > > > Making 'b' a TYPE instead of a CLASS makes the error go away. I agree that this example still trigger a bug, but I remember in my original (more complicated) code, the segfault appears when it tries to access the allocatable components of the type in the subroutine before computation and before returning. So the problem might be at entrance and not necessarily after the call. This need to be confirmed.
[Bug fortran/64397] New: memory allocation failed with parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397 Bug ID: 64397 Summary: memory allocation failed with parenthesis Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: patnel97269-gfortran at yahoo dot fr Hi all, I want to report a bug which i describe orignially here, https://gcc.gnu.org/ml/fortran/2014-12/msg00117.html . The expression (a+b) works well, while ((a)+(b)) triggers a memory allocation issue. And its works fine, if there is no allocatable components in the type. Janus Weil worked out a reduce test case below, and can reproduce the segfault with various versions of gfortran (4.7, 4.8, 4.9 and trunk) : module num type :: my_integer real, allocatable :: x(:) contains procedure :: ass generic :: assignment(=) => ass end type contains subroutine ass(a,b) class(my_integer), intent(out) :: a class(my_integer), intent(in) :: b select type (b) type is (my_integer) allocate(a%x(size(b%x))) a%x = b%x end select print *,'called ass' end subroutine end module program main use num type(my_integer) :: a, c a=my_integer([1]) write (*,*) "C: ",c%x c = a write (*,*) "C: ",c%x c = (a) write (*,*) "C: ",c%x end Thanks Pat.
[Bug fortran/63640] move_alloc memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640 patnel97269-gfortran at yahoo dot fr changed: What|Removed |Added Severity|critical|normal
[Bug fortran/63640] move_alloc memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640 --- Comment #2 from patnel97269-gfortran at yahoo dot fr --- Thanks for the tip and the comment. So the standard say that move_alloc deallocate the array "from". Does that mean that the compiler mark the array as not allocated but does not free the memory ?
[Bug fortran/63640] move_alloc memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640 patnel97269-gfortran at yahoo dot fr changed: What|Removed |Added Severity|major |critical
[Bug fortran/63640] New: move_alloc memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640 Bug ID: 63640 Summary: move_alloc memory leak Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: patnel97269-gfortran at yahoo dot fr Hi, The move_alloc intrisic has a memory leak, the object "from" doesn't seems to be deallocated. Here is a small test case with integer, but leaks also for dp. I'm using version 4.9.1 . Thanks. program testmv3 type bar integer, allocatable :: ia(:), ja(:) end type integer, allocatable :: ia(:), ja(:) type(bar), allocatable :: sm,sm2 allocate(sm) allocate(sm2) allocate(sm%ia(100),sm%ja(100)) allocate(sm2%ia(1000),sm2%ja(1000)) allocate(ia(100),ja(1000)) call move_alloc(ja,ia) call move_alloc(sm%ia,sm2%ia) call move_alloc(sm%ja,sm2%ja) end program testmv3 ==5438== HEAP SUMMARY: ==5438== in use at exit: 4,992 bytes in 5 blocks ==5438== total heap usage: 29 allocs, 24 frees, 25,211 bytes allocated ==5438== ==5438== 96 bytes in 1 blocks are definitely lost in loss record 1 of 5 ==5438==at 0x4C29F90: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5438==by 0x40089A: MAIN__ (test_memleak.f90:9) ==5438==by 0x400F66: main (test_memleak.f90:20) ==5438== ==5438== 896 (96 direct, 800 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 5 ==5438==at 0x4C29F90: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5438==by 0x4009A1: MAIN__ (test_memleak.f90:10) ==5438==by 0x400F66: main (test_memleak.f90:20) ==5438== ==5438== 4,000 bytes in 1 blocks are definitely lost in loss record 5 of 5 ==5438==at 0x4C29F90: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5438==by 0x400DD7: MAIN__ (test_memleak.f90:13) ==5438==by 0x400F66: main (test_memleak.f90:20) ==5438== ==5438== LEAK SUMMARY: ==5438==definitely lost: 4,192 bytes in 3 blocks ==5438==indirectly lost: 800 bytes in 2 blocks ==5438== possibly lost: 0 bytes in 0 blocks ==5438==still reachable: 0 bytes in 0 blocks ==5438== suppressed: 0 bytes in 0 blocks
[Bug fortran/63553] [OOP] Wrong code when assigning a CLASS to a TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63553 --- Comment #5 from patnel97269-gfortran at yahoo dot fr --- Thanks for the patch. Another similar case, this time the type contains an allocatable field, produces a internal compiler error (without applying the patch) : internal compiler error: in fold_convert_loc, at fold-const.c:2112 program toto implicit none type mother integer :: i double precision,dimension(:),allocatable :: values end type mother class(mother),allocatable :: cm,cm2 allocate(cm) allocate(cm%values(10)) cm%i=3 cm%values=80d0 allocate(cm2) select type(cm2) type is (mother) cm2=cm end select print *,cm2%i,cm2%values end program
[Bug fortran/63553] [OOP] Wrong code when assigning a CLASS to a TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63553 patnel97269-gfortran at yahoo dot fr changed: What|Removed |Added CC||patnel97269-gfortran@yahoo. ||fr --- Comment #2 from patnel97269-gfortran at yahoo dot fr --- As I wrote here https://gcc.gnu.org/ml/fortran/2014-10/msg00079.html, I think this case is also related : program toto implicit none type mother integer :: i end type mother type,extends(mother) :: child end type child type(mother) :: tm type(child) :: tc class(mother),allocatable :: cm,cm2 class(child),allocatable :: cc allocate(cm) allocate(child::cm2) cm%i=10 select type (cm2) type is (child) cm2%mother=cm end select print *,'class cm2 is type tm',extends_type_of(cm2,tm) print *,'class cm2 is class cm',extends_type_of(cm2,cm) print *,'class cm2 is type tc',extends_type_of(cm2,tc) print *,'class cm2 is class cc',extends_type_of(cm2,cc) print *,'cm2=cm', cm%i,cm2%i end program
[Bug fortran/60596] Inquire size for stream zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60596 --- Comment #4 from patnel97269-gfortran at yahoo dot fr --- Ok so if I understand well, for gfortran once the input_unit is closed, the unit number corresponding to input_unit can be used for another file. But, the input_unit is defined to be the standard input. 1) If one wants to reconnect to standard input socket (/dev or /proc) how to find out with gfortran without knowing the file path ? 2) it is allowed to change some properties of an already connected unit by calling the open function again without closing first. When i do so , using open(unit=input_unit,status='old' ,access='stream') inquire(unit=input_unit,name=nm) print *,nm inquire(unit=input_unit,size=sz) I get : At line 26 of file test2.f90 (unit = 5, file = 'stdin') Fortran runtime error: Cannot change ACCESS parameter in OPEN statement And if I just ask the name of the file associated file input_unit with gfortran i get "stdin", with ifort i get "/proc/28683/fd/0". 3) Ifort is automatically reconnecting input_unit to standard input when file is omitted, how is that a bug ?
[Bug fortran/60596] Inquire size for stream zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60596 --- Comment #2 from patnel97269-gfortran at yahoo dot fr --- Using your program, I get the same behavior I describe . Running with gfortran I get ./a.out < tmp.dat 400 0 0 Running with ifort I get ./a.out < tmp.dat 400 0 400 Why the size the shell input is 0 ?
[Bug fortran/60596] New: Inquire size for stream zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60596 Bug ID: 60596 Summary: Inquire size for stream zero Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: patnel97269-gfortran at yahoo dot fr Created attachment 32398 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32398&action=edit program Hi all, When calling inquire for a stream size, the size is reported to be zero. In the intel fortran compiler the sizer is correctly reported. I attached a small program, and the necessary input file. Use that as < input : >ONE Homo sapiens alu Thanks.
[Bug fortran/52774] New: A check is needed to prevent deallocation in realloc-lhs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52774
Bug #: 52774
Summary: A check is needed to prevent deallocation in
realloc-lhs
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: patnel97269-gfort...@yahoo.fr
A check is needed to prevent deallocation and nullification of D.1880.p.data if
it is equal to p1.p.data, after the function call.
This has been reported at http://gcc.gnu.org/ml/fortran/2012-03/msg00141.html
Here is the message of Paul Richard Thomas :
A reduced and tidied testcase that exhibits the
problem is:
program test
implicit none
type po
real(8), dimension(:), allocatable :: p
end type
type(po) :: p1
allocate(p1%p(1))
p1=toto(p1)
print *, p1%p
contains
function toto(dd) result(y)
type(po) ::dd,y
deallocate(dd%p)
end function toto
end program test
The call to toto gives the following code:
D.1880 = p1;
p1 = toto (&p1);
if (D.1880.p.data != 0B)
{
__builtin_free ((void *) D.1880.p.data);
}
D.1880.p.data = 0B;
Thus, if dd is deallocated within toto, without reassigning something
to dd%p, the address of p.data is retained by D.1880 and so it is
doubly freed. This can be tested by adding an assignment to dd%p,
after the deallocation, whereupon everything works as it should. For
example,
program test
implicit none
type po
real(8), dimension(:), allocatable :: p
end type
type(po) :: p1
allocate(p1%p(1))
p1=toto(p1)
print *, p1%p
contains
function toto(dd) result(y)
type(po) ::dd,y
deallocate(dd%p)
dd%p = [1d0, 2d0]
y = dd
end function toto
end program test
