[Bug fortran/64397] [OOP] Runtime segfault with parenthesis expression passed to polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397 Paul Thomas changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Paul Thomas --- This indeed appears to be fixed. Closing. Paul
[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 #11 from Dominique d'Humieres --- This PR seems to have been fixed by revision r268474.
[Bug fortran/64397] [OOP] Runtime segfault with parenthesis expression passed to polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #10 from Dominique d'Humieres --- > Reverting to NEW and taking. So ASSIGNED!-)
[Bug fortran/64397] [OOP] Runtime segfault with parenthesis expression passed to polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397 Paul Thomas changed: What|Removed |Added Status|WAITING |NEW Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #9 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #8) > AFAICT this PR is now fixed, likely r251949 (pr34640 and friends). Well, for the original testcase, a=my_integer([1]) leaks memory. If replaced with: integer :: i(1) = [1] a=my_integer(i) the segfault at: c = (a) returns. It seems that there is a way to go on this one :-( Reverting to NEW and taking. Paul
[Bug fortran/64397] [OOP] Runtime segfault with parenthesis expression passed to polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING CC||pault at gcc dot gnu.org --- Comment #8 from Dominique d'Humieres --- AFAICT this PR is now fixed, likely r251949 (pr34640 and friends).
[Bug fortran/64397] [OOP] Runtime segfault with parenthesis expression passed to polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397
janus at gcc dot gnu.org changed:
What|Removed |Added
Summary|[OOP] Runtime segfault with |[OOP] Runtime segfault with
|type-bound assignment and |parenthesis expression
|parenthesis |passed to polymorphic dummy
||argument
--- Comment #4 from janus at gcc dot gnu.org ---
As shown by -fdump-tree-original, the first call to 'ass' is translated to:
{
struct __class_main_My_integer_t class.11;
class.11._vptr = (struct __vtype_main_My_integer * {ref-all})
__vtab_main_My_integer;
class.11._data = (struct my_integer *) a;
ass (class.11);
}
The second call, however, is translated to:
{
void * restrict D.3514;
integer(kind=8) D.3513;
integer(kind=8) D.3512;
integer(kind=8) D.3511;
struct __class_main_My_integer_t D.3510;
struct my_integer D.3509;
struct __class_main_My_integer_t class.13;
class.13._vptr = (struct __vtype_main_My_integer * {ref-all})
__vtab_main_My_integer;
D.3509 = a;
class.13._data = (struct my_integer *) D.3509;
D.3510 = class.13;
ass (class.13);
if ((void *) D.3510.x.data != 0B)
{
D.3511 = (D.3510.x.dim[0].ubound - D.3510.x.dim[0].lbound) + 1;
D.3512 = NON_LVALUE_EXPR D.3511;
D.3513 = D.3512 * 4;
D.3514 = (void * restrict) __builtin_malloc (MAX_EXPR (unsigned long)
D.3513, 1);
class.13.x.data = D.3514;
__builtin_memcpy ((real(kind=4)[0:] * restrict) class.13.x.data,
(real(kind=4)[0:] * restrict) D.3510.x.data, (unsigned long) (D.3512 * 4));
}
else
{
class.13.x.data = 0B;
}
if (class.13._data-x.data != 0B)
{
__builtin_free ((void *) class.13._data-x.data);
}
class.13._data-x.data = 0B;
}
While nothing is done after the call itself in the first case, quite a bit of
cleanup-code is added in the second case (which is also seen in comment 2.
[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] [OOP] Runtime segfault with parenthesis expression passed to polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397 --- Comment #6 from janus at gcc dot gnu.org --- (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.
[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.
