public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/100440] New: allocated() gives True for unallocated variable
@ 2021-05-05 23:11 dsmith at lmu dot edu
  2021-05-06  0:22 ` [Bug fortran/100440] " kargl at gcc dot gnu.org
                   ` (12 more replies)
  0 siblings, 13 replies; 14+ messages in thread
From: dsmith at lmu dot edu @ 2021-05-05 23:11 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440

            Bug ID: 100440
           Summary: allocated() gives True for unallocated variable
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dsmith at lmu dot edu
  Target Milestone: ---

A large program that ran correctly on several previous versions of gfortran
(and other compilers) failed when I installed version 10 on a 2017 Intel Mac
running 10.15.3.

gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin19/10.2.0/lto-wrapper
Target: x86_64-apple-darwin19
Configured with: ../gcc-10.2.0/configure --prefix=/usr/local/gfortran
--with-gmp=/Users/fx/devel/gcc/build_package/deps
--with-isl=/Users/fx/devel/gcc/build_package/deps
--enable-languages=c,c++,fortran,objc,obj-c++ --build=x86_64-apple-darwin19
--with-native-system-header-dir=/usr/include
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC) 


This program ran correctly under gfortran 6.3, but a similar program using
the same set of subroutines failed the same way.  That prompted me to upgrade
to gfortran 10, but instead things got worse with several other of my programs
failing with this error.

I have tried to reproduce the error in a small example program, but so far
I have not been able to do it.

Maybe this description will tell you what the error is, in lieu of the full
program.

The debug prints check the allocation status of the array within fmmatmul21_fm
at the top of the routine.  Running under gfortran 10.2 gives:


 21 j=           1  allocated(fmmatmul21_fm(j)%mfm%mp) =  T
  size(fmmatmul21_fm(j)%mfm%mp) =            1
At line 133497 of file fmprogram.f95
Fortran runtime error: Attempting to allocate already allocated variable
'fmmatmul21_fm'


Other compilers give correct results:


 21 j= 1  allocated(fmmatmul21_fm(j)%mfm%mp) =  F
  allocated(fmmatmul21_fm(j)%mfm%mp) =  T
  size(fmmatmul21_fm(j)%mfm%mp) =  12
 21 j= 2  allocated(fmmatmul21_fm(j)%mfm%mp) =  F
  allocated(fmmatmul21_fm(j)%mfm%mp) =  T
  size(fmmatmul21_fm(j)%mfm%mp) =  12
...


I don't understand why fmmatmul21_fm should show that it is already
allocated when it is basically an uninitialized local variable.
It shouldn't matter, but fmmatmul21_fm has not been called earlier
in the program.

With the deallocate statement enabled, so the allocate statement
should then work, I get:


 21 j=           1  allocated(fmmatmul21_fm(j)%mfm%mp) =  T
  size(fmmatmul21_fm(j)%mfm%mp) =            1
fmprogram(26871,0x10fa64dc0) malloc: *** error for object 0x5000000000000000:
pointer being freed was not allocated
fmprogram(26871,0x10fa64dc0) malloc: *** set a breakpoint in malloc_error_break
to debug

Program received signal SIGABRT: Process abort signal.




Here is the function where the error occurs:


   function fmmatmul21_fm(ma,mb)
      use fmvals
      implicit none
      type (fm) :: ma(:,:),mb(:)
      type (fm), dimension(size(ma,dim=1)) :: fmmatmul21_fm
      integer :: j,k,mxsave,nd2,ndsave
      intent (in) :: ma,mb
      type(multi), save :: mtlvfm,mulvfm,mvlvfm,mtlv01
      if (size(mb) == size(ma,dim=2)) then

do j = 1, size(ma,dim=1)
print*,'21 j=',j,' allocated(fmmatmul21_fm(j)%mfm%mp) = ',
allocated(fmmatmul21_fm(j)%mfm%mp)
if(allocated(fmmatmul21_fm(j)%mfm%mp)) print*,' size(fmmatmul21_fm(j)%mfm%mp) =
', size(fmmatmul21_fm(j)%mfm%mp)
!deallocate(fmmatmul21_fm(j)%mfm%mp)
allocate(fmmatmul21_fm(j)%mfm%mp(ndig+2))
print*,' allocated(fmmatmul21_fm(j)%mfm%mp) = ',
allocated(fmmatmul21_fm(j)%mfm%mp)
print*,' size(fmmatmul21_fm(j)%mfm%mp) = ', size(fmmatmul21_fm(j)%mfm%mp)
enddo

          ndsave = ndig
          j = max(ngrd52,2)
          nd2 = max(2*ndig+j,2)
          ndig = nd2
          mxsave = mxexp
          do j = 1, size(ma,dim=1)
             mxexp = mxexp2
             call fmi2m(0,mtlvfm)
             do k = 1, size(mb,dim=1)
                call fmequ(ma(j,k)%mfm,mulvfm,ndsave,ndig)
                call fmequ(mb(k)%mfm,mvlvfm,ndsave,ndig)
                call fmmpy(mulvfm,mvlvfm,mtlv01)
                call fmadd_r1(mtlvfm,mtlv01)
             enddo
             mxexp = mxsave
             call fmequ(mtlvfm,fmmatmul21_fm(j)%mfm,ndig,ndsave)
          enddo
          ndig = ndsave
      else
          call fmst2m(' unknown ',mvlvfm)
          do j = 1, size(ma,dim=1)
             call fmeq(mvlvfm,fmmatmul21_fm(j)%mfm)
          enddo
      endif
   end function fmmatmul21_fm


The context for this subroutine is that it provides the matmul function
for matrix times vector for variables of type(fm), which is defined in
terms of type(multi) containing allocatable d.p. arrays.

      type multi
         real (kind(1.0d0)), allocatable :: mp(:)
      end type

      type fm
         type(multi) :: mfm
      end type


I hope that can give a hint about what might be going wrong.

David Smith

^ 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 ` 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

end of thread, other threads:[~2021-07-26 16:45 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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
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

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).