public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/97920] New: [FINAL] -O2 segment fault due to extend derive type's member being partially allocated
@ 2020-11-20 2:08 xin.liu@compiler-dev.com
2020-11-20 7:35 ` [Bug fortran/97920] " marxin at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: xin.liu@compiler-dev.com @ 2020-11-20 2:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97920
Bug ID: 97920
Summary: [FINAL] -O2 segment fault due to extend derive type's
member being partially allocated
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: xin.liu@compiler-dev.com
Target Milestone: ---
Consider the following Fortran testcase:
module m
type t1
real, dimension(:), pointer :: a
contains
final :: t1f
end type
type, extends(t1) :: t2
real, dimension(:), pointer :: b
contains
final :: t2f
end type
contains
subroutine t1f(x)
type(t1) :: x
if (associated(x%a)) deallocate(x%a)
end subroutine
subroutine t2f(x)
type(t2) :: x
if (associated(x%b)) deallocate(x%b)
end subroutine
end module
subroutine test
use m
implicit none
type(t1) :: a
type(t2) :: b
allocate(b%a(3))
! allocate(b%b(3))
end subroutine
program p
use m
call test()
end program
Compiled with gfortran 10.1.0 in -O2, the testcase prints:
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
If add a statement as 'allocate(b%b(3))', it will pass with no segment fault.I
guess this segment fault maybe due to extend derive type's member being
partially allocated.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug fortran/97920] [FINAL] -O2 segment fault due to extend derive type's member being partially allocated
2020-11-20 2:08 [Bug fortran/97920] New: [FINAL] -O2 segment fault due to extend derive type's member being partially allocated xin.liu@compiler-dev.com
@ 2020-11-20 7:35 ` marxin at gcc dot gnu.org
2020-12-08 17:05 ` pault at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-11-20 7:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97920
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org,
| |marxin at gcc dot gnu.org,
| |tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed| |2020-11-20
Status|UNCONFIRMED |NEW
--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Confirmed with valgrind. At least as old as 4.9.0.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug fortran/97920] [FINAL] -O2 segment fault due to extend derive type's member being partially allocated
2020-11-20 2:08 [Bug fortran/97920] New: [FINAL] -O2 segment fault due to extend derive type's member being partially allocated xin.liu@compiler-dev.com
2020-11-20 7:35 ` [Bug fortran/97920] " marxin at gcc dot gnu.org
@ 2020-12-08 17:05 ` pault at gcc dot gnu.org
2020-12-12 13:58 ` tkoenig at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: pault at gcc dot gnu.org @ 2020-12-08 17:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97920
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
CC| |pault at gcc dot gnu.org
--- Comment #2 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #1)
> Confirmed with valgrind. At least as old as 4.9.0.
Hi,
>From a quick perusal of the standard, I find in F2003 16.4.2.1:
"Unless a pointer is initialized (explicitly or by default), it has an initial
association status of undefined. A pointer may be initialized to have an
association status of disassociated".
In your testcase, the status of b%b is undefined and so the compiler can do
anything it wants with it, including segfaulting. I think therefore that you
should initialize the derived types in your application as follows:
type t1
real, dimension(:), pointer :: a => NULL ()
contains
final :: t1f
end type
type, extends(t1) :: t2
real, dimension(:), pointer :: b => NULL ()
contains
final :: t2f
end type
This clears the valgrind error "Conditional jump or move depends on
uninitialised value(s)". Also the finalization is invoked so that the programme
completes with zero memory allocation,
To my surprise (probably due to standard ignorance), leaving the declared type
declarations as you have them, and declaring 'b' as
type(t2) :: b = t2 (NULL(), NULL())
clears the valgrind fault but no finalization occurs. I notice that
finalization does not occur if an entity has the save attribute. gfortran
assigns 'b' the IMPLICIT-SAVE attribute, which is why the finalization does not
occur. I have been unable to find whether or not this is conforming.
However, initializing 'b' in an assignment:
b = t2(NULL(), NULL())
clears the valgrind fault and results in the deallocation of memory. This
confirms my suspicion about the save attribute.
In conclusion, I do not believe that this is a bug. If you do not use pointers
as pointers, make them allocatable instead. These are automatically nullified
on entry into scope.
Thanks for the report by the way!
Paul
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug fortran/97920] [FINAL] -O2 segment fault due to extend derive type's member being partially allocated
2020-11-20 2:08 [Bug fortran/97920] New: [FINAL] -O2 segment fault due to extend derive type's member being partially allocated xin.liu@compiler-dev.com
2020-11-20 7:35 ` [Bug fortran/97920] " marxin at gcc dot gnu.org
2020-12-08 17:05 ` pault at gcc dot gnu.org
@ 2020-12-12 13:58 ` tkoenig at gcc dot gnu.org
2020-12-16 0:27 ` xin.liu@compiler-dev.com
2020-12-16 0:30 ` xin.liu@compiler-dev.com
4 siblings, 0 replies; 6+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2020-12-12 13:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97920
Thomas Koenig <tkoenig at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|WAITING |RESOLVED
--- Comment #3 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Paul is correct, the state of the pointers is undefined.
What you can do to correct this is to use
module m
type t1
real, dimension(:), pointer :: a => NULL()
contains
final :: t1f
end type
type, extends(t1) :: t2
real, dimension(:), pointer :: b => NULL()
contains
final :: t2f
end type
which will then run as expected.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug fortran/97920] [FINAL] -O2 segment fault due to extend derive type's member being partially allocated
2020-11-20 2:08 [Bug fortran/97920] New: [FINAL] -O2 segment fault due to extend derive type's member being partially allocated xin.liu@compiler-dev.com
` (2 preceding siblings ...)
2020-12-12 13:58 ` tkoenig at gcc dot gnu.org
@ 2020-12-16 0:27 ` xin.liu@compiler-dev.com
2020-12-16 0:30 ` xin.liu@compiler-dev.com
4 siblings, 0 replies; 6+ messages in thread
From: xin.liu@compiler-dev.com @ 2020-12-16 0:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97920
--- Comment #4 from xin liu <xin.liu@compiler-dev.com> ---
(In reply to Thomas Koenig from comment #3)
> Paul is correct, the state of the pointers is undefined.
>
> What you can do to correct this is to use
>
> module m
> type t1
> real, dimension(:), pointer :: a => NULL()
> contains
> final :: t1f
> end type
>
> type, extends(t1) :: t2
> real, dimension(:), pointer :: b => NULL()
> contains
> final :: t2f
> end type
>
> which will then run as expected.
OK,Thanks!
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug fortran/97920] [FINAL] -O2 segment fault due to extend derive type's member being partially allocated
2020-11-20 2:08 [Bug fortran/97920] New: [FINAL] -O2 segment fault due to extend derive type's member being partially allocated xin.liu@compiler-dev.com
` (3 preceding siblings ...)
2020-12-16 0:27 ` xin.liu@compiler-dev.com
@ 2020-12-16 0:30 ` xin.liu@compiler-dev.com
4 siblings, 0 replies; 6+ messages in thread
From: xin.liu@compiler-dev.com @ 2020-12-16 0:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97920
--- Comment #5 from xin liu <xin.liu@compiler-dev.com> ---
(In reply to Paul Thomas from comment #2)
> (In reply to Martin Liška from comment #1)
> > Confirmed with valgrind. At least as old as 4.9.0.
>
> Hi,
>
> From a quick perusal of the standard, I find in F2003 16.4.2.1:
>
> "Unless a pointer is initialized (explicitly or by default), it has an
> initial association status of undefined. A pointer may be initialized to
> have an
> association status of disassociated".
>
> In your testcase, the status of b%b is undefined and so the compiler can do
> anything it wants with it, including segfaulting. I think therefore that you
> should initialize the derived types in your application as follows:
>
> type t1
> real, dimension(:), pointer :: a => NULL ()
> contains
> final :: t1f
> end type
>
> type, extends(t1) :: t2
> real, dimension(:), pointer :: b => NULL ()
> contains
> final :: t2f
> end type
>
> This clears the valgrind error "Conditional jump or move depends on
> uninitialised value(s)". Also the finalization is invoked so that the
> programme completes with zero memory allocation,
>
> To my surprise (probably due to standard ignorance), leaving the declared
> type declarations as you have them, and declaring 'b' as
>
> type(t2) :: b = t2 (NULL(), NULL())
>
> clears the valgrind fault but no finalization occurs. I notice that
> finalization does not occur if an entity has the save attribute. gfortran
> assigns 'b' the IMPLICIT-SAVE attribute, which is why the finalization does
> not occur. I have been unable to find whether or not this is conforming.
>
> However, initializing 'b' in an assignment:
> b = t2(NULL(), NULL())
>
> clears the valgrind fault and results in the deallocation of memory. This
> confirms my suspicion about the save attribute.
>
> In conclusion, I do not believe that this is a bug. If you do not use
> pointers as pointers, make them allocatable instead. These are automatically
> nullified on entry into scope.
>
> Thanks for the report by the way!
>
> Paul
I get it, Thanks for your explain.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-12-16 0:30 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-20 2:08 [Bug fortran/97920] New: [FINAL] -O2 segment fault due to extend derive type's member being partially allocated xin.liu@compiler-dev.com
2020-11-20 7:35 ` [Bug fortran/97920] " marxin at gcc dot gnu.org
2020-12-08 17:05 ` pault at gcc dot gnu.org
2020-12-12 13:58 ` tkoenig at gcc dot gnu.org
2020-12-16 0:27 ` xin.liu@compiler-dev.com
2020-12-16 0:30 ` xin.liu@compiler-dev.com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).