* [Bug fortran/100440] allocated() gives True for unallocated variable
2021-05-05 23:11 [Bug fortran/100440] New: allocated() gives True for unallocated variable dsmith at lmu dot edu
@ 2021-05-06 0:22 ` kargl at gcc dot gnu.org
2021-05-06 21:31 ` David.Smith at lmu dot edu
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: kargl at gcc dot gnu.org @ 2021-05-06 0:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
With neither access to the actual code nor a reduced testcase,
it will be virtually impossible to debug this problem.
Does the code run with the following compiler options:
-O0 -fno-frontend-optimize -fcheck=all
Does the code compile without warning if you use -Wall -Wextra?
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/100440] allocated() gives True for unallocated variable
2021-05-05 23:11 [Bug fortran/100440] New: allocated() gives True for unallocated variable dsmith at lmu dot edu
2021-05-06 0:22 ` [Bug fortran/100440] " kargl at gcc dot gnu.org
@ 2021-05-06 21:31 ` David.Smith at lmu dot edu
2021-05-06 22:54 ` sgk at troutmask dot apl.washington.edu
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: David.Smith at lmu dot edu @ 2021-05-06 21:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #2 from David.Smith at lmu dot edu ---
> With neither access to the actual code nor a reduced testcase,
> it will be virtually impossible to debug this problem.
Right, I have enclosed a small program pulled out of my real application
that displays the error.
> Does the code run with the following compiler options:
> -O0 -fno-frontend-optimize -fcheck=all
Yes, it compiles and runs, giving the allocate error.
> Does the code compile without warning if you use -Wall -Wextra?
There are many warnings, and I think they may all be ignored for this
program:
IUNKNO = -HUGE(I_TWO)/18
Warning: Integer division truncated to constant ‘119304647’
(Yes, that is what we want)
IF (MB%MP(2) /= MUNKNO .OR. MB%MP(3) /= 1) THEN
Warning: Inequality comparison for REAL(8)
(This is a numerical analysis application -- it knows what it is
doing when it compares reals)
KT1 = MWA%MP(J+1)
Warning: Possible change of value in conversion from REAL(8) to INTEGER(4)
(ditto)
TYPE(MULTI), SAVE, DIMENSION(LMBERN) :: MBERN
Warning: Array ‘mbern’ at (1) is larger than limit set by
‘-fmax-stack-var-size=’,
moved from stack to static storage.
(That's fine here)
INTEGER :: J,JMA,JMW,N1,N2
Warning: Unused variable ‘jma’ declared
(I removed most of the routines in the full program to make a small
version that gives the error. Also removed some test code that uses
these 'unused' variables)
IF (KRESLT /= 0) THEN
Warning: ‘kreslt’ may be used uninitialized in this function
(ditto)
I have attached the file "allocate_error.f95". Output (without the warnings):
gfortran allocate_error.f95 -o allocate_error -Wall -Wextra -O0
-fno-frontend-optimize -fcheck=all
$ allocate_error
Sample 10. Eigenvalue from matrix powers.
Iteration eigenvalue approximation
0 1.000000000000000000000000000000000000000000000000000000000
21 j= 1 allocated(FMMATMUL21_FM(J)%MFM%mp) = T
size(FMMATMUL21_FM(J)%MFM%mp) = 1
allocate_error(29813,0x108292dc0) malloc: *** error for object
0xb000000000000000: pointer being freed was not allocated
allocate_error(29813,0x108292dc0) malloc: *** set a breakpoint in
malloc_error_break to debug
Program received signal SIGABRT: Process abort signal.
Backtrace for this error:
#0 0x104c1ad3d
#1 0x104c1a16d
#2 0x7fff6f56042c
zsh: abort allocate_error
Thanks for your help,
David Smith
________________________________________
From: kargl at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
Sent: Wednesday, May 5, 2021 5:22 PM
To: Smith, David
Subject: [Bug fortran/100440] allocated() gives True for unallocated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
With neither access to the actual code nor a reduced testcase,
it will be virtually impossible to debug this problem.
Does the code run with the following compiler options:
-O0 -fno-frontend-optimize -fcheck=all
Does the code compile without warning if you use -Wall -Wextra?
--
You are receiving this mail because:
You reported the bug.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/100440] allocated() gives True for unallocated variable
2021-05-05 23:11 [Bug fortran/100440] New: allocated() gives True for unallocated variable dsmith at lmu dot edu
2021-05-06 0:22 ` [Bug fortran/100440] " kargl at gcc dot gnu.org
2021-05-06 21:31 ` David.Smith at lmu dot edu
@ 2021-05-06 22:54 ` sgk at troutmask dot apl.washington.edu
2021-05-07 14:49 ` David.Smith at lmu dot edu
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2021-05-06 22:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, May 06, 2021 at 09:31:49PM +0000, David.Smith at lmu dot edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
>
> --- Comment #2 from David.Smith at lmu dot edu ---
> > With neither access to the actual code nor a reduced testcase,
> > it will be virtually impossible to debug this problem.
>
> Right, I have enclosed a small program pulled out of my real application
> that displays the error.
Thanks for reduce this to a testcase. I don't see it attached
to this email or in bugzilla. gcc.gno.org may have stripped
the attachment (for some dumb reason). Feel free to send the
test case to me, and I make sure it gets attached to the bug
report.
>
> > Does the code run with the following compiler options:
>
> > -O0 -fno-frontend-optimize -fcheck=all
>
> Yes, it compiles and runs, giving the allocate error.
>
> > Does the code compile without warning if you use -Wall -Wextra?
>
> There are many warnings, and I think they may all be ignored for this
> program:
>
> IUNKNO = -HUGE(I_TWO)/18
> Warning: Integer division truncated to constant ‘119304647’
>
> (Yes, that is what we want)
>
> IF (MB%MP(2) /= MUNKNO .OR. MB%MP(3) /= 1) THEN
> Warning: Inequality comparison for REAL(8)
>
> (This is a numerical analysis application -- it knows what it is
> doing when it compares reals)
>
> KT1 = MWA%MP(J+1)
> Warning: Possible change of value in conversion from REAL(8) to INTEGER(4)
>
> (ditto)
>
> TYPE(MULTI), SAVE, DIMENSION(LMBERN) :: MBERN
> Warning: Array ‘mbern’ at (1) is larger than limit set by
> ‘-fmax-stack-var-size=’,
> moved from stack to static storage.
>
> (That's fine here)
>
> INTEGER :: J,JMA,JMW,N1,N2
> Warning: Unused variable ‘jma’ declared
>
> (I removed most of the routines in the full program to make a small
> version that gives the error. Also removed some test code that uses
> these 'unused' variables)
>
> IF (KRESLT /= 0) THEN
> Warning: ‘kreslt’ may be used uninitialized in this function
>
> (ditto)
>
>
>
> I have attached the file "allocate_error.f95". Output (without the warnings):
>
>
> gfortran allocate_error.f95 -o allocate_error -Wall -Wextra -O0
> -fno-frontend-optimize -fcheck=all
> $ allocate_error
>
>
>
> Sample 10. Eigenvalue from matrix powers.
>
> Iteration eigenvalue approximation
>
> 0 1.000000000000000000000000000000000000000000000000000000000
> 21 j= 1 allocated(FMMATMUL21_FM(J)%MFM%mp) = T
> size(FMMATMUL21_FM(J)%MFM%mp) = 1
> allocate_error(29813,0x108292dc0) malloc: *** error for object
> 0xb000000000000000: pointer being freed was not allocated
> allocate_error(29813,0x108292dc0) malloc: *** set a breakpoint in
> malloc_error_break to debug
>
> Program received signal SIGABRT: Process abort signal.
>
> Backtrace for this error:
> #0 0x104c1ad3d
> #1 0x104c1a16d
> #2 0x7fff6f56042c
> zsh: abort allocate_error
The above malloc error suggests to me that you're
possibly stepping off the end of an array. -fcheck=all
should have caught that. :(
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/100440] allocated() gives True for unallocated variable
2021-05-05 23:11 [Bug fortran/100440] New: allocated() gives True for unallocated variable dsmith at lmu dot edu
` (2 preceding siblings ...)
2021-05-06 22:54 ` sgk at troutmask dot apl.washington.edu
@ 2021-05-07 14:49 ` David.Smith at lmu dot edu
2021-05-07 21:09 ` kargl at gcc dot gnu.org
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: David.Smith at lmu dot edu @ 2021-05-07 14:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #4 from David.Smith at lmu dot edu ---
> Thanks for reduce this to a testcase. I don't see it attached
> to this email or in bugzilla. gcc.gno.org may have stripped
> the attachment (for some dumb reason). Feel free to send the
>test case to me, and I make sure it gets attached to the bug
> report.
Ok, I will try attaching it as a zip file this time.
________________________________________
From: sgk at troutmask dot apl.washington.edu <gcc-bugzilla@gcc.gnu.org>
Sent: Thursday, May 6, 2021 3:54 PM
To: Smith, David
Subject: [Bug fortran/100440] allocated() gives True for unallocated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, May 06, 2021 at 09:31:49PM +0000, David.Smith at lmu dot edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
>
> --- Comment #2 from David.Smith at lmu dot edu ---
> > With neither access to the actual code nor a reduced testcase,
> > it will be virtually impossible to debug this problem.
>
> Right, I have enclosed a small program pulled out of my real application
> that displays the error.
Thanks for reduce this to a testcase. I don't see it attached
to this email or in bugzilla. gcc.gno.org may have stripped
the attachment (for some dumb reason). Feel free to send the
test case to me, and I make sure it gets attached to the bug
report.
>
> > Does the code run with the following compiler options:
>
> > -O0 -fno-frontend-optimize -fcheck=all
>
> Yes, it compiles and runs, giving the allocate error.
>
> > Does the code compile without warning if you use -Wall -Wextra?
>
> There are many warnings, and I think they may all be ignored for this
> program:
>
> IUNKNO = -HUGE(I_TWO)/18
> Warning: Integer division truncated to constant ‘119304647’
>
> (Yes, that is what we want)
>
> IF (MB%MP(2) /= MUNKNO .OR. MB%MP(3) /= 1) THEN
> Warning: Inequality comparison for REAL(8)
>
> (This is a numerical analysis application -- it knows what it is
> doing when it compares reals)
>
> KT1 = MWA%MP(J+1)
> Warning: Possible change of value in conversion from REAL(8) to INTEGER(4)
>
> (ditto)
>
> TYPE(MULTI), SAVE, DIMENSION(LMBERN) :: MBERN
> Warning: Array ‘mbern’ at (1) is larger than limit set by
> ‘-fmax-stack-var-size=’,
> moved from stack to static storage.
>
> (That's fine here)
>
> INTEGER :: J,JMA,JMW,N1,N2
> Warning: Unused variable ‘jma’ declared
>
> (I removed most of the routines in the full program to make a small
> version that gives the error. Also removed some test code that uses
> these 'unused' variables)
>
> IF (KRESLT /= 0) THEN
> Warning: ‘kreslt’ may be used uninitialized in this function
>
> (ditto)
>
>
>
> I have attached the file "allocate_error.f95". Output (without the warnings):
>
>
> gfortran allocate_error.f95 -o allocate_error -Wall -Wextra -O0
> -fno-frontend-optimize -fcheck=all
> $ allocate_error
>
>
>
> Sample 10. Eigenvalue from matrix powers.
>
> Iteration eigenvalue approximation
>
> 0 1.000000000000000000000000000000000000000000000000000000000
> 21 j= 1 allocated(FMMATMUL21_FM(J)%MFM%mp) = T
> size(FMMATMUL21_FM(J)%MFM%mp) = 1
> allocate_error(29813,0x108292dc0) malloc: *** error for object
> 0xb000000000000000: pointer being freed was not allocated
> allocate_error(29813,0x108292dc0) malloc: *** set a breakpoint in
> malloc_error_break to debug
>
> Program received signal SIGABRT: Process abort signal.
>
> Backtrace for this error:
> #0 0x104c1ad3d
> #1 0x104c1a16d
> #2 0x7fff6f56042c
> zsh: abort allocate_error
The above malloc error suggests to me that you're
possibly stepping off the end of an array. -fcheck=all
should have caught that. :(
--
You are receiving this mail because:
You reported the bug.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/100440] allocated() gives True for unallocated variable
2021-05-05 23:11 [Bug fortran/100440] New: allocated() gives True for unallocated variable dsmith at lmu dot edu
` (3 preceding siblings ...)
2021-05-07 14:49 ` David.Smith at lmu dot edu
@ 2021-05-07 21:09 ` kargl at gcc dot gnu.org
2021-05-07 21:12 ` anlauf at gcc dot gnu.org
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: kargl at gcc dot gnu.org @ 2021-05-07 21:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #5 from kargl at gcc dot gnu.org ---
David,
On amd64-*-freebsd, I see
% gfcx -o z -O2 -fcheck=all allocate_error.f95
% ./z
Sample 10. Eigenvalue from matrix powers.
Iteration eigenvalue approximation
0 1.000000000000000000000000000000000000000000000000000000000
21 j= 1 allocated(FMMATMUL21_FM(J)%MFM%mp) = F
allocated(FMMATMUL21_FM(J)%MFM%mp) = F
At line 2499 of file allocate_error.f95
Fortran runtime error: Allocatable argument 'fmmatmul21_fm' is not allocated
with a number of different options. The runtime error is expected as
'allocated(FMMATMUL21_FM(J)%MFM%mp) = F', and the print statement checking
size() is not protected by an 'if' statement.
valgrind shows
==8708== HEAP SUMMARY:
==8708== in use at exit: 10,737 bytes in 68 blocks
==8708== total heap usage: 170 allocs, 102 frees, 40,166 bytes allocated
==8708==
==8708== LEAK SUMMARY:
==8708== definitely lost: 0 bytes in 0 blocks
==8708== indirectly lost: 0 bytes in 0 blocks
==8708== possibly lost: 0 bytes in 0 blocks
==8708== still reachable: 10,737 bytes in 68 blocks
==8708== suppressed: 0 bytes in 0 blocks
which suggests that this might be a MacOS specific bug.
Note, if I comment out your print statement for diagnostics, I see
% ./z
Sample 10. Eigenvalue from matrix powers.
Iteration eigenvalue approximation
0 1.000000000000000000000000000000000000000000000000000000000
1 24.238372093023255813953488372093023255813953488372093023260
2 .889072890369341844887411185964338107009906299229814263038M+20
3 .102214801410512542129975983352534954405105702575200225476M+43
4 .133558489514054527062720546215032551914781174136345314241M+87
5 .321140870607048831918216893831115589158773657747578318060M+175
6 .205341864155723417152215792855218285040195823798023639691M+352
7 .667355770417440618516624449043958628107088436355045114363M+705
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/100440] allocated() gives True for unallocated variable
2021-05-05 23:11 [Bug fortran/100440] New: allocated() gives True for unallocated variable dsmith at lmu dot edu
` (4 preceding siblings ...)
2021-05-07 21:09 ` kargl at gcc dot gnu.org
@ 2021-05-07 21:12 ` anlauf at gcc dot gnu.org
2021-05-07 21:58 ` sgk at troutmask dot apl.washington.edu
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: anlauf at gcc dot gnu.org @ 2021-05-07 21:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #6 from anlauf at gcc dot gnu.org ---
There seems to be something fishy with default initialization of function
results of derived types. Looking at the attached code, I guessed the
following potential reproducer:
program p
implicit none
type multi
real, allocatable :: mp(:)
end type
type fm
type(multi) :: mfm
end type
type(fm), allocatable :: a(:,:)
integer :: n = 1
allocate (a(n,n))
a = mm (a, a)
a = mm (a, a) ! crashes here with -fsanitize=address
contains
function mm (ma, mb)
type(fm) :: ma(:,:), mb(:,:)
type(fm), dimension(size(ma,dim=1),size(mb,dim=2)) :: mm
integer :: i, j
do i = 1, size(ma,dim=1)
do j = 1, size(mb,dim=2)
print *, i, j, allocated (mm(i,j)% mfm% mp)
end do
end do
end function mm
end program p
Compiling and running the program prints:
1 1 F
1 1 T
The second output line should really be identical to the first one, which is
confirmed by other compilers.
Under Linux, setting MALLOC_PERTURB_=1 I get:
1 1 T
1 1 T
Adding -fsanitize=address to the command line, I get a traceback pointing
to the line commented above:
1 1 T
1 1 T
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x14c71f85649f in ???
#1 0x14c720845c36 in
_ZN11__sanitizer30atomic_compare_exchange_strongINS_14atomic_uint8_tEEEbPVT_PNS2_4TypeES5_NS_12memory_orderE
at
../../../../gcc-trunk/libsanitizer/sanitizer_common/sanitizer_atomic_clang.h:80
#2 0x14c720845c36 in
_ZN6__asan9Allocator38AtomicallySetQuarantineFlagIfAllocatedEPNS_9AsanChunkEPvPN11__sanitizer18BufferedStackTraceE
at ../../../../gcc-trunk/libsanitizer/asan/asan_allocator.cpp:621
#3 0x14c720845c36 in
_ZN6__asan9Allocator10DeallocateEPvmmPN11__sanitizer18BufferedStackTraceENS_9AllocTypeE
at ../../../../gcc-trunk/libsanitizer/asan/asan_allocator.cpp:697
#4 0x14c720845c36 in
_ZN6__asan9asan_freeEPvPN11__sanitizer18BufferedStackTraceENS_9AllocTypeE
at ../../../../gcc-trunk/libsanitizer/asan/asan_allocator.cpp:971
#5 0x14c7208cac07 in __interceptor_free
at ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:128
#6 0x401f10 in p
at /home/anlauf/Downloads/pr100440-red.f90:13
#7 0x402180 in main
at /home/anlauf/Downloads/pr100440-red.f90:13
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/100440] allocated() gives True for unallocated variable
2021-05-05 23:11 [Bug fortran/100440] New: allocated() gives True for unallocated variable dsmith at lmu dot edu
` (5 preceding siblings ...)
2021-05-07 21:12 ` anlauf at gcc dot gnu.org
@ 2021-05-07 21:58 ` sgk at troutmask dot apl.washington.edu
2021-05-08 17:21 ` David.Smith at lmu dot edu
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2021-05-07 21:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, May 07, 2021 at 09:12:15PM +0000, anlauf at gcc dot gnu.org wrote:
> --- Comment #6 from anlauf at gcc dot gnu.org ---
> There seems to be something fishy with default initialization of function
> results of derived types.
There is no default initialization in the code below. default
initialization is
type foo
integer :: i = 1 ! <-- Default initialization
end tyep foo
> Looking at the attached code, I guessed the
> following potential reproducer:
>
> program p
> implicit none
> type multi
> real, allocatable :: mp(:)
> end type
> type fm
> type(multi) :: mfm
> end type
> type(fm), allocatable :: a(:,:)
> integer :: n = 1
> allocate (a(n,n))
> a = mm (a, a)
> a = mm (a, a) ! crashes here with -fsanitize=address
> contains
> function mm (ma, mb)
> type(fm) :: ma(:,:), mb(:,:)
> type(fm), dimension(size(ma,dim=1),size(mb,dim=2)) :: mm
So, it is the size(ma,dim=1) and size(mb,dim=2) that are causing
the problem.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/100440] allocated() gives True for unallocated variable
2021-05-05 23:11 [Bug fortran/100440] New: allocated() gives True for unallocated variable dsmith at lmu dot edu
` (6 preceding siblings ...)
2021-05-07 21:58 ` sgk at troutmask dot apl.washington.edu
@ 2021-05-08 17:21 ` David.Smith at lmu dot edu
2021-05-08 18:49 ` anlauf at gcc dot gnu.org
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: David.Smith at lmu dot edu @ 2021-05-08 17:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #8 from David.Smith at lmu dot edu ---
That is not good. The expected results from my test case with debug
prints commented out should be this:
Sample 10. Eigenvalue from matrix powers.
Iteration eigenvalue approximation
0 1.000000000000000000000000000000000000000000000000000000000
1 24.238372093023255813953488372093023255813953488372093023260
2 23.913064457596406344892377530895927499788142161414894216110
3 23.912767173080067549422508320051584489821761621077098788510
4 23.912767172321328589362041859914215096468342615030281071820
5 23.912767172321328589357039228003304505549129411762921508580
6 23.912767172321328589357039228003304505549129195999272982170
7 23.912767172321328589357039228003304505549129195999272982160
David Smith
________________________________________
From: kargl at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
Sent: Friday, May 7, 2021 2:09 PM
To: Smith, David
Subject: [Bug fortran/100440] allocated() gives True for unallocated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #5 from kargl at gcc dot gnu.org ---
David,
On amd64-*-freebsd, I see
% gfcx -o z -O2 -fcheck=all allocate_error.f95
% ./z
Sample 10. Eigenvalue from matrix powers.
Iteration eigenvalue approximation
0 1.000000000000000000000000000000000000000000000000000000000
21 j= 1 allocated(FMMATMUL21_FM(J)%MFM%mp) = F
allocated(FMMATMUL21_FM(J)%MFM%mp) = F
At line 2499 of file allocate_error.f95
Fortran runtime error: Allocatable argument 'fmmatmul21_fm' is not allocated
with a number of different options. The runtime error is expected as
'allocated(FMMATMUL21_FM(J)%MFM%mp) = F', and the print statement checking
size() is not protected by an 'if' statement.
valgrind shows
==8708== HEAP SUMMARY:
==8708== in use at exit: 10,737 bytes in 68 blocks
==8708== total heap usage: 170 allocs, 102 frees, 40,166 bytes allocated
==8708==
==8708== LEAK SUMMARY:
==8708== definitely lost: 0 bytes in 0 blocks
==8708== indirectly lost: 0 bytes in 0 blocks
==8708== possibly lost: 0 bytes in 0 blocks
==8708== still reachable: 10,737 bytes in 68 blocks
==8708== suppressed: 0 bytes in 0 blocks
which suggests that this might be a MacOS specific bug.
Note, if I comment out your print statement for diagnostics, I see
% ./z
Sample 10. Eigenvalue from matrix powers.
Iteration eigenvalue approximation
0 1.000000000000000000000000000000000000000000000000000000000
1 24.238372093023255813953488372093023255813953488372093023260
2 .889072890369341844887411185964338107009906299229814263038M+20
3 .102214801410512542129975983352534954405105702575200225476M+43
4 .133558489514054527062720546215032551914781174136345314241M+87
5 .321140870607048831918216893831115589158773657747578318060M+175
6 .205341864155723417152215792855218285040195823798023639691M+352
7 .667355770417440618516624449043958628107088436355045114363M+705
--
You are receiving this mail because:
You reported the bug.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/100440] allocated() gives True for unallocated variable
2021-05-05 23:11 [Bug fortran/100440] New: allocated() gives True for unallocated variable dsmith at lmu dot edu
` (7 preceding siblings ...)
2021-05-08 17:21 ` David.Smith at lmu dot edu
@ 2021-05-08 18:49 ` anlauf at gcc dot gnu.org
2021-05-09 0:32 ` sgk at troutmask dot apl.washington.edu
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: anlauf at gcc dot gnu.org @ 2021-05-08 18:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2021-05-08
Ever confirmed|0 |1
Keywords| |wrong-code
--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #7)
> There is no default initialization in the code below. default
> initialization is
>
> type foo
> integer :: i = 1 ! <-- Default initialization
> end tyep foo
The F2018 standard says:
7.5.4.6 Default initialization for components
[...] Allocatable components are always initialized to unallocated.
Anyway, the following extension shows that default initialization does not
work:
program p
implicit none
type fm
real, allocatable :: mp(:)
integer :: dummy = 42
end type
type(fm), allocatable :: a(:,:)
integer :: n = 1
allocate (a(n,n))
a = mm (a, a)
a = mm (a, a) ! crashes here with -fsanitize=address
contains
function mm (ma, mb)
type(fm) :: ma(:,:), mb(:,:)
type(fm), dimension(size(ma,dim=1),size(mb,dim=2)) :: mm
integer :: i, j
! type(fm), dimension(size(ma,dim=1),size(mb,dim=2)) :: z
! mm = z ! Explicit initialization of function result
do i = 1, size(ma,dim=1)
do j = 1, size(mb,dim=2)
print *, i, j, allocated (mm(i,j)% mp), mm(i,j)% dummy
end do
end do
end function mm
end program p
Which gives:
1 1 F 0
1 1 T 0
and with MALLOC_PERTURB_=2 :
1 1 T -33686019
1 1 T -33686019
Uncommenting the indicated lines in function mm procduces:
1 1 F 42
1 1 F 42
and crashes with MALLOC_PERTURB_=2
Not good.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/100440] allocated() gives True for unallocated variable
2021-05-05 23:11 [Bug fortran/100440] New: allocated() gives True for unallocated variable dsmith at lmu dot edu
` (8 preceding siblings ...)
2021-05-08 18:49 ` anlauf at gcc dot gnu.org
@ 2021-05-09 0:32 ` sgk at troutmask dot apl.washington.edu
2021-05-11 19:56 ` anlauf at gcc dot gnu.org
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2021-05-09 0:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #10 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sat, May 08, 2021 at 06:49:11PM +0000, anlauf at gcc dot gnu.org wrote:
> (In reply to Steve Kargl from comment #7)
> > There is no default initialization in the code below. default
> > initialization is
> >
> > type foo
> > integer :: i = 1 ! <-- Default initialization
> > end tyep foo
>
> The F2018 standard says:
>
> 7.5.4.6 Default initialization for components
>
> [...] Allocatable components are always initialized to unallocated.
>
Interesting choice of wording in the Fortran standard. Normally,
assigning a value to an entity would mean that it is initialized.
integer, allocatable :: i
allocate(i)
end
Is 'i' initialized? No. It is allocated, but undefined.
The ALLOCATED() intrinsic returns the status of its argument
as either allocated (.true.) or unallocated (.false.). It
does not tell if it is initialized.
In fact, the Fortran Standard states
3.49
default initialization
mechanism for automatically initializing pointer components to have a
defined pointer association status, and nonpointer components to have
a particular value (7.5.4.6)
I'll send a note to J3.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/100440] allocated() gives True for unallocated variable
2021-05-05 23:11 [Bug fortran/100440] New: allocated() gives True for unallocated variable dsmith at lmu dot edu
` (9 preceding siblings ...)
2021-05-09 0:32 ` sgk at troutmask dot apl.washington.edu
@ 2021-05-11 19:56 ` anlauf at gcc dot gnu.org
2021-05-11 20:23 ` anlauf at gcc dot gnu.org
2021-07-26 16:45 ` David.Smith at lmu dot edu
12 siblings, 0 replies; 14+ messages in thread
From: anlauf at gcc dot gnu.org @ 2021-05-11 19:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |anlauf at gcc dot gnu.org
--- Comment #11 from anlauf at gcc dot gnu.org ---
For a possibly related case see PR98454.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/100440] allocated() gives True for unallocated variable
2021-05-05 23:11 [Bug fortran/100440] New: allocated() gives True for unallocated variable dsmith at lmu dot edu
` (10 preceding siblings ...)
2021-05-11 19:56 ` anlauf at gcc dot gnu.org
@ 2021-05-11 20:23 ` anlauf at gcc dot gnu.org
2021-07-26 16:45 ` David.Smith at lmu dot edu
12 siblings, 0 replies; 14+ messages in thread
From: anlauf at gcc dot gnu.org @ 2021-05-11 20:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #12 from anlauf at gcc dot gnu.org ---
A small variation of the testcase in comment#9 suggests that there are
actually two underlying issues: lack of initialization and a missing
temporary.
program p
implicit none
type fm
real, allocatable :: mp(:)
integer :: dummy = 42
end type
type(fm), allocatable :: a(:), b(:)
integer :: n = 1
allocate (a(n))
print *, "main:", n, allocated (a(n)% mp), a(n)% dummy
b = mm (a)
a = mm (b)
a = mm (a)
a = mm (a) ! crashes here with -fsanitize=address
contains
function mm (ma)
type(fm), intent(in) :: ma(:)
type(fm) :: mm(size(ma))
integer :: i
! type(fm) :: z(size(ma))
! mm = z ! Explicit initialization of function result
do i = 1, size(ma)
print *, "in mm:", i, allocated (mm(i)% mp), mm(i)% dummy
end do
end function mm
end program p
This gives:
main: 1 F 42
in mm: 1 F 0
in mm: 1 F 42
in mm: 1 F 0
in mm: 1 T 0
while with -fsanitize=address,undefined :
main: 1 F 42
in mm: 1 F -1094795586
in mm: 1 F 42
in mm: 1 T -1094795586
in mm: 1 T -1094795586
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x14987da6f49f in ???
[...]
#6 0x409669 in p
at /home/anlauf/gcc-bugs/pr100440-red3.f90:14
#7 0x4097d9 in main
at /home/anlauf/gcc-bugs/pr100440-red3.f90:14
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/100440] allocated() gives True for unallocated variable
2021-05-05 23:11 [Bug fortran/100440] New: allocated() gives True for unallocated variable dsmith at lmu dot edu
` (11 preceding siblings ...)
2021-05-11 20:23 ` anlauf at gcc dot gnu.org
@ 2021-07-26 16:45 ` David.Smith at lmu dot edu
12 siblings, 0 replies; 14+ messages in thread
From: David.Smith at lmu dot edu @ 2021-07-26 16:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #13 from David.Smith at lmu dot edu ---
Thanks for working on the bug I reported in May.
I am hoping you can give me some information that I can pass on to
the users of my open-source software who use gfortran to run it.
Can you estimate when the fix will appear in an official release
of gfortran, and what version number to look for?
Thanks,
David Smith
________________________________________
From: anlauf at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
Sent: Tuesday, May 11, 2021 1:23 PM
To: Smith, David
Subject: [Bug fortran/100440] allocated() gives True for unallocated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #12 from anlauf at gcc dot gnu.org ---
A small variation of the testcase in comment#9 suggests that there are
actually two underlying issues: lack of initialization and a missing
temporary.
program p
implicit none
type fm
real, allocatable :: mp(:)
integer :: dummy = 42
end type
type(fm), allocatable :: a(:), b(:)
integer :: n = 1
allocate (a(n))
print *, "main:", n, allocated (a(n)% mp), a(n)% dummy
b = mm (a)
a = mm (b)
a = mm (a)
a = mm (a) ! crashes here with -fsanitize=address
contains
function mm (ma)
type(fm), intent(in) :: ma(:)
type(fm) :: mm(size(ma))
integer :: i
! type(fm) :: z(size(ma))
! mm = z ! Explicit initialization of function result
do i = 1, size(ma)
print *, "in mm:", i, allocated (mm(i)% mp), mm(i)% dummy
end do
end function mm
end program p
This gives:
main: 1 F 42
in mm: 1 F 0
in mm: 1 F 42
in mm: 1 F 0
in mm: 1 T 0
while with -fsanitize=address,undefined :
main: 1 F 42
in mm: 1 F -1094795586
in mm: 1 F 42
in mm: 1 T -1094795586
in mm: 1 T -1094795586
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x14987da6f49f in ???
[...]
#6 0x409669 in p
at /home/anlauf/gcc-bugs/pr100440-red3.f90:14
#7 0x4097d9 in main
at /home/anlauf/gcc-bugs/pr100440-red3.f90:14
--
You are receiving this mail because:
You reported the bug.
^ permalink raw reply [flat|nested] 14+ messages in thread