Bug or feature: Intel 18.0.0 eagerly deallocates INTENT(out) POINTER variables

[Thomas Jahns]

For the below program, ifort 17.0.2

$ ifort --version
ifort (IFORT) 17.0.2 20170213
Copyright (C) 1985-2017 Intel Corporation. All rights reserved.

gives the following result:

$ ifort -O0 -o intel17-ptr-out ptr-out.f90 && ./intel17-ptr-out
p = 42 42 42 42 42
q = 42 42 42 42 42
p = 23 23 23 23 23
q = 42 42 42 42 42

but ifort 18.0.0 deallocates the pointee and therefore results in

$ ifort --version
ifort (IFORT) 18.0.0 20170811
Copyright (C) 1985-2017 Intel Corporation. All rights reserved.

$ ifort -O0 -o intel18-ptr-out ptr-out.f90 && ./intel18-ptr-out
p = 42 42 42 42 42
q = 42 42 42 42 42
p = 23 23 23 23 23
q = 23 23 23 23 23

because p is then allocated at the same heap place previously occupied by q.
(notice the second printing of q). nagfor 6.1, gfortran 7.1 and pgfortran 17.7
give the same result as ifort 17.0.2.

$ cat ptr-out.f90
MODULE bar
IMPLICIT NONE
PRIVATE
PUBLIC :: baz
CONTAINS
SUBROUTINE baz(p)
INTEGER, POINTER, INTENT(out) :: p(:)
ALLOCATE(p(5))
p = 23
END SUBROUTINE baz
END MODULE bar

PROGRAM foo
USE bar, ONLY: baz
IMPLICIT NONE
INTEGER, POINTER :: p(:), q(:)
ALLOCATE(q(5))
p => q
q = 42
WRITE (0, '(a,10(" ",i0))') 'p = ', p
WRITE (0, '(a,10(" ",i0))') 'q = ', q
CALL baz(p)
WRITE (0, '(a,10(" ",i0))') 'p = ', p
WRITE (0, '(a,10(" ",i0))') 'q = ', q
END PROGRAM foo

Is there a known work-around (e.g. some compiler option)? Does the observed
behaviour conform to any release of the Fortran standard?

Thomas

[FortranFan]

On Friday, November 24, 2017 at 11:41:23 AM UTC-5, Thomas Jahns wrote:

> ..

>
> Is there a known work-around (e.g. some compiler option)? Does the observed

> behaviour conform to any release of the Fortran standard? ..


To me, it looks like a bug in the Intel Fortran 18.0 compiler. And it is worthy of a support request at the Intel Online Service Center (OSC), at least for you to learn what Intel's Fortran team thinks of the issue.
https://supporttickets.intel.com/?lang=en-US

Re: a work-around, one option is to treat variables with the POINTER attribute in Fortran as entities that only *point* to some explicit targets with ALLOCATABLE attribute as opposed to anonymous targets which come into play in the code in the original post. It can make codes a lot safer and cleaner with far fewer worries about memory leaks and also be easier to understand and maintain:

module bar
implicit none
private
integer, allocatable, target, save :: m_dat(:)
public :: baz
contains
subroutine baz( p )
integer, pointer, intent(inout) :: p(:)
! Any checks elided
p => null()
if ( .not. allocated(m_dat) ) then
allocate( m_dat(5) )
end if
m_dat = 23
p => m_dat
return
end subroutine
end module

program foo

use, intrinsic :: iso_fortran_env, only : compiler_version
use bar, only: baz

implicit none

integer, allocatable, target :: q(:)
integer, pointer :: p(:)

print *, "Compiler version: ", compiler_version()
allocate( q(5) )

p => q
q = 42

write (0, '(a,10(" ",i0))') 'p = ', p
write (0, '(a,10(" ",i0))') 'q = ', q

call baz(p)
write (0, '(a,10(" ",i0))') 'p = ', p
write (0, '(a,10(" ",i0))') 'q = ', q

p => null()

stop

end program foo


Upon execution using Intel Fortran 18.0 compiler update 1,
Compiler version:
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.0.1.156 Build 20171018
- hide quoted text -

[Themos Tsikas]

Hello,

A colleague noticed that changing the INTENT of P in BAZ from OUT to INOUT avoids the issue.

Regards
Themos Tsikas

[Steve Lionel]

On 11/24/2017 11:41 AM, Thomas Jahns wrote:
> For the below program, ifort 17.0.2

> but ifort 18.0.0 deallocates the pointee

This is interesting. I agree that it's a compiler bug and I have
submitted request 03143573 on your behalf to Intel.

The standard says, "The INTENT (OUT) attribute for a pointer dummy
argument specifies that on invocation of the procedure the pointer
association status of the dummy argument becomes undefined."

For INTENT(OUT), ALLOCATABLE dummies, the standard notes that they are
deallocated on procedure entry, but that isn't (and can't be) the case
for POINTER dummies, since not all pointers can be deallocated.
(Technically, this one can, since p points to the "whole of q", but it
shouldn't be deallocated here.)

Your program doesn't adequately display the errant behavior - it depends
on just how the memory allocator happens to work. I added some prints of
ALLOCATED to demonstrate the problem when I sent it to Intel.

--
Steve Lionel
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: http://intel.com/software/DrFortran

[Thomas Jahns]

On 11/28/17 23:34, Steve Lionel wrote:
> On 11/24/2017 11:41 AM, Thomas Jahns wrote:
>> For the below program, ifort 17.0.2
>
>> but ifort 18.0.0 deallocates the pointee
>
> This is interesting. I agree that it's a compiler bug and I have submitted
> request 03143573 on your behalf to Intel.
>
> The standard says, "The INTENT (OUT) attribute for a pointer dummy argument
> specifies that on invocation of the procedure the pointer association status of
> the dummy argument becomes undefined."
>
> For INTENT(OUT), ALLOCATABLE dummies, the standard notes that they are
> deallocated on procedure entry, but that isn't (and can't be) the case for
> POINTER dummies, since not all pointers can be deallocated. (Technically, this
> one can, since p points to the "whole of q", but it shouldn't be deallocated here.)
>
> Your program doesn't adequately display the errant behavior - it depends on just
> how the memory allocator happens to work. I added some prints of ALLOCATED to
> demonstrate the problem when I sent it to Intel.

Thanks Steve, we are customers through Bull/Atos. So once I got some feedback
here that the observed behaviour indeed is not covered by the standard, I would
have created a ticket. But since update 1 (i.e. ifort 18.0.1) seems to address
this issue, I just asked for that version to be installed.

Thomas

[Ian Harvey]

From looking at the assembly generated by 18.0.1, I think the problem
still exists with that version (there is an suspicious call to an
internal compiler routine that deallocates an object in the preamble for
the module subroutine). As Steve suggests, you are just lucky (or
unlucky) that changes in memory layout with the different version of the
compiler mask the problem.

[Steve Lionel]

I agree with Ian - the bug is still there. As I wrote earlier, your
example program doesn't sufficiently test it. Very simply, look to see
if p is still associated before the ALLOCATE in procedure baz. If the
bug is there, it will not be associated.

[FortranFan]

On Wednesday, November 29, 2017 at 1:38:49 PM UTC-5, Steve Lionel wrote:

> .. the bug is still there. As I wrote earlier, your

> example program doesn't sufficiently test it. Very simply, look to see
> if p is still associated before the ALLOCATE in procedure baz. If the

> bug is there, it will not be associated. ..

@Steve Lionel,

Given that the standard states:

1) for dummy variables with the POINTER attribute, "If the dummy argument has INTENT (OUT), the pointer association status of the actual argument becomes undefined on invocation of the procedure." and

2) for the ASSOCIATED intrinsic, "the result is true if and only if POINTER is associated with a target."

should not the "if p is still associated before the ALLOCATE in procedure baz." check return FALSE. Then how do you surmise with Intel Fortran "the bug is there, it will not be associated"?

Thanks,

[Steve Lionel]

On 11/30/2017 8:37 AM, FortranFan wrote:
> Given that the standard states:
>
> 1) for dummy variables with the POINTER attribute, "If the dummy argument has INTENT (OUT), the pointer association status of the actual argument becomes undefined on invocation of the procedure." and
>
> 2) for the ASSOCIATED intrinsic, "the result is true if and only if POINTER is associated with a target."
>
> should not the "if p is still associated before the ALLOCATE in procedure baz." check return FALSE. Then how do you surmise with Intel Fortran "the bug is there, it will not be associated"?

It's a more likely test than displaying the values and guessing about
what went on behind the scenes. You're right that, technically, you
can't ask about the association status when it's undefined, but
practically speaking, the test reveals a problem. Perhaps if the
implementation did something like nullifying the pointer, the test would
then fail, but I think it serves the purpose.

[Thomas Jahns]

On 11/29/17 19:38, Steve Lionel wrote:
> On 11/29/2017 5:01 AM, Ian Harvey wrote:
>> On 29/11/2017 7:05 PM, Thomas Jahns wrote:
>
>>> Thanks Steve, we are customers through Bull/Atos. So once I got some feedback
>>> here that the observed behaviour indeed is not covered by the standard, I
>>> would have created a ticket. But since update 1 (i.e. ifort 18.0.1) seems to
>>> address this issue, I just asked for that version to be installed.
>>
>>  From looking at the assembly generated by 18.0.1, I think the problem still
>> exists with that version (there is an suspicious call to an internal compiler
>> routine that deallocates an object in the preamble for the module
>> subroutine).  As Steve suggests, you are just lucky (or unlucky) that changes
>> in memory layout with the different version of the compiler mask the problem.
>
> I agree with Ian - the bug is still there. As I wrote earlier, your example
> program doesn't sufficiently test it. Very simply, look to see if p is still
> associated before the ALLOCATE in procedure baz. If the bug is there, it will
> not be associated.

Now that 18.0.1 is installed at our cluster I can confirm that the behaviour
with 18.0.1 is indeed different to 18.0.0 but still invokes lots of problematic
operations (reading from free'd memory) with valgrind.

I'll have our support representative inquire about issue 03143573.

Regards, Thomas

[casimir....@gmail.com]

The problem has been fixed by Intel