<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Access violation from a combination of programming error, alloc in Intel® Fortran Compiler</title>
    <link>https://community.intel.com/t5/Intel-Fortran-Compiler/Access-violation-from-a-combination-of-programming-error/m-p/800982#M37675</link>
    <description>The compiler has been fixed to give an error under /check:pointer for this case. This will appear in a future release.</description>
    <pubDate>Wed, 01 Feb 2012 20:15:21 GMT</pubDate>
    <dc:creator>Steven_L_Intel1</dc:creator>
    <dc:date>2012-02-01T20:15:21Z</dc:date>
    <item>
      <title>Access violation from a combination of programming error, allocatable strings and certain compiler options</title>
      <link>https://community.intel.com/t5/Intel-Fortran-Compiler/Access-violation-from-a-combination-of-programming-error/m-p/800978#M37671</link>
      <description>&lt;P&gt;&lt;/P&gt;&lt;P&gt;          Hi!&lt;/P&gt;&lt;P&gt;I have been investigating an access violation that only occurs in production build but not in debug build. I have been able to make quite a minimal example that reproduces the error.&lt;/P&gt;&lt;P&gt;Here's the code:&lt;/P&gt;&lt;P&gt;&lt;PRE&gt;[fortran]module stringer

    implicit none

contains

    ! a devious routine that does not always allocate 
    ! the return value
    pure function create_string( actually_allocate ) result( res )
    
        logical, intent(in) :: actually_allocate
        character( len = : ), allocatable :: res
        
        if ( actually_allocate ) res = 'hello world'
    end function

    ! two crashing routines where runtime checks do no good.
    ! The difference is that in the first one an unallocated allocatable string
    ! is assigned to a local character buffer whereas in the second the
    ! unallocated string is passed to a routine that expects a character buffer
    
    subroutine crash
        character( len = 100 ) :: string
        
        
        string = create_string( actually_allocate = .true. )        
        call print_len( string )


        ! this will not go well...
        string = create_string( actually_allocate = .false. )
        call print_len( string )
    
    end subroutine
    
    subroutine crash2
        character( len = : ), allocatable :: string
        
        
        string = create_string( actually_allocate = .true. )
        call print_len( string )


        string = create_string( actually_allocate = .false. )
        ! this will not go well...
        call print_len( string )

    end subroutine

end module

program lentest

    use stringer

    implicit none
    
    call crash
    call crash2

end program

subroutine print_len( s )

    character( len = * ), intent(in) :: s

    print '(I10)', len( s )

end subroutine
[/fortran]&lt;/PRE&gt; &lt;/P&gt;&lt;P&gt;If you compile this e.g. like this:&lt;/P&gt;&lt;P&gt;ifort lentest.f90&lt;/P&gt;&lt;P&gt;there will be no problems, the program will run just fine.&lt;/P&gt;&lt;P&gt;OTOH, compiled with either of these will cause the program to end in access violation:&lt;/P&gt;&lt;P&gt;ifort /check:uninit /check:pointer /RTCu /traceback /check:bounds /O3  /Qopenmp /Qopt-prefetch4 lentest.f90&lt;/P&gt;&lt;P&gt;ifort /Qopenmp lentest.f90&lt;/P&gt;&lt;P&gt;Now, I know that there is an error in the program, although I'm not sure whether it is in the function create_string not always allocating it's return value or the caller not being prepared for the return value not being allocated. Is it legal for a function returning an allocatable string to leave the return value unallocated?&lt;/P&gt;&lt;P&gt;In either case, it would be immensely helpful if there was a runtime check that would notice this problem, print out an error message and quit the program. Maybe there already is one and I'm not aware of it? Any other hints?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Environment: Windows 7 64bit, ifort11.1.054, compiling 32 bit executable&lt;/P&gt;&lt;P&gt;&lt;/P&gt;</description>
      <pubDate>Tue, 01 Nov 2011 08:53:29 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Fortran-Compiler/Access-violation-from-a-combination-of-programming-error/m-p/800978#M37671</guid>
      <dc:creator>Karanta__Antti</dc:creator>
      <dc:date>2011-11-01T08:53:29Z</dc:date>
    </item>
    <item>
      <title>Access violation from a combination of programming error, alloc</title>
      <link>https://community.intel.com/t5/Intel-Fortran-Compiler/Access-violation-from-a-combination-of-programming-error/m-p/800979#M37672</link>
      <description>It's not illegal for the function to return an unallocated result but it is "illegal" to reference an unallocated value. I would have expected /check:pointer to pick up on this, but it doesn't. I will ask the developers to add this. Issue ID is DPD200175687.&lt;BR /&gt;&lt;BR /&gt;The reason it works in a Release mode is most likely that the length field is zero when the lower level copy routine is called - just the way it happened to work out. When you get the error, the length is unpredictable.</description>
      <pubDate>Mon, 07 Nov 2011 20:46:38 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Fortran-Compiler/Access-violation-from-a-combination-of-programming-error/m-p/800979#M37672</guid>
      <dc:creator>Steven_L_Intel1</dc:creator>
      <dc:date>2011-11-07T20:46:38Z</dc:date>
    </item>
    <item>
      <title>Access violation from a combination of programming error, alloc</title>
      <link>https://community.intel.com/t5/Intel-Fortran-Compiler/Access-violation-from-a-combination-of-programming-error/m-p/800980#M37673</link>
      <description>&lt;P&gt;Thanks Steve!&lt;/P&gt;&lt;P&gt;Is it possible for me to subscribe to the said issue to follow its progress?&lt;/P&gt;</description>
      <pubDate>Thu, 10 Nov 2011 07:48:43 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Fortran-Compiler/Access-violation-from-a-combination-of-programming-error/m-p/800980#M37673</guid>
      <dc:creator>Karanta__Antti</dc:creator>
      <dc:date>2011-11-10T07:48:43Z</dc:date>
    </item>
    <item>
      <title>Access violation from a combination of programming error, alloc</title>
      <link>https://community.intel.com/t5/Intel-Fortran-Compiler/Access-violation-from-a-combination-of-programming-error/m-p/800981#M37674</link>
      <description>Subscribe to this thread for updates.</description>
      <pubDate>Fri, 11 Nov 2011 18:58:27 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Fortran-Compiler/Access-violation-from-a-combination-of-programming-error/m-p/800981#M37674</guid>
      <dc:creator>Steven_L_Intel1</dc:creator>
      <dc:date>2011-11-11T18:58:27Z</dc:date>
    </item>
    <item>
      <title>Access violation from a combination of programming error, alloc</title>
      <link>https://community.intel.com/t5/Intel-Fortran-Compiler/Access-violation-from-a-combination-of-programming-error/m-p/800982#M37675</link>
      <description>The compiler has been fixed to give an error under /check:pointer for this case. This will appear in a future release.</description>
      <pubDate>Wed, 01 Feb 2012 20:15:21 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Fortran-Compiler/Access-violation-from-a-combination-of-programming-error/m-p/800982#M37675</guid>
      <dc:creator>Steven_L_Intel1</dc:creator>
      <dc:date>2012-02-01T20:15:21Z</dc:date>
    </item>
  </channel>
</rss>

