• ALLOCATE ERRMSG can be misleading

    From Beliavsky@21:1/5 to All on Wed Mar 23 11:09:37 2022
    For the code at https://github.com/Beliavsky/FortranTip/blob/main/alloc_errmsg.f90 and also below

    program alloc_errmsg
    use iso_fortran_env, only: int64
    implicit none
    integer (kind=int64) :: n
    integer :: ierr,ipow
    real, allocatable :: x(:)
    character (len=100) :: errmsg
    allocate (x(2))
    allocate (x(3),stat=ierr,errmsg=errmsg)
    print*,"here ierr =",ierr," errmsg = ",trim(errmsg)
    n = 10**8
    do ipow=1,5
    ierr = 0
    if (allocated(x)) deallocate(x)
    allocate (x(n),stat=ierr,errmsg=errmsg)
    if (ierr /= 0) then
    print "(3(1x,a,1x,i0),2a)","ipow =",ipow,"n =",n,"ierr =",ierr," errmsg = ",trim(errmsg)
    exit
    end if
    call random_number(x)
    print "(3(1x,a,1x,i0),a,f0.6)","ipow =",ipow," n =",n," size(x) =",size(x)," maxval(x) = ",maxval(x)
    n = n*10
    end do
    end program alloc_errmsg

    gfortran gives

    here ierr = 5014 errmsg = Attempt to allocate an allocated object
    ipow = 1 n = 100000000 size(x) = 100000000 maxval(x) = 1.000000
    ipow = 2 n = 1000000000 size(x) = 1000000000 maxval(x) = 1.000000
    ipow = 3 n = 10000000000 ierr = 5014 errmsg = Attempt to allocate an allocated object

    Intel Fortran gives

    here ierr = 151 errmsg = allocatable array is already allocated
    ipow = 1 n = 100000000 size(x) = 100000000 maxval(x) = 1.000000
    ipow = 2 n = 1000000000 size(x) = 1000000000 maxval(x) = 1.000000
    ipow = 3 n = 10000000000 ierr = 41 errmsg = insufficient virtual memory

    producing distinct error messages for the cases of allocating an allocated array and allocating an array that is too big. I prefer Intel's behavior.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John@21:1/5 to All on Wed Mar 23 21:06:13 2022
    If you are making a tweet, a question I had about allocate is does the standard require a failed allocate to make no change to the variables listed, or is the state undefined? That is, after this failed ALLOCATE() do I know anything about the state of
    the variable per the standard?
    #!/bin/bash
    (
    exec 2>&1
    cat >xx.f90 <<\EOF
    program testit
    implicit none
    character(len=:),allocatable :: line
    character(len=256) :: message
    integer :: istat
    line='abc'
    message=''
    allocate(character(len=132):: line,errmsg=message,stat=istat)
    if(istat.ne.0)write(*,*)trim(message)
    write(*,*)'allocated?',allocated(line),'len=',len(line)
    line='xxxxx'
    write(*,*)len(line)
    end program testit
    EOF
    rm -f ./a.out;gfortran xx.f90&&./a.out 2>&1|sed -e 's/^/gfortran:/'
    rm -f ./a.out;ifort xx.f90&&./a.out 2>&1|sed -e 's/^/ifort:/'
    rm -f ./a.out;nvfortran xx.f90&&./a.out 2>&1|sed -e 's/^/nvfortran:/'
    ) >>$0
    exit
    gfortran: Attempt to allocate an allocated object
    gfortran: allocated? T len= 3
    gfortran: 5
    ifort: allocatable array is already allocated
    ifort: allocated? T len= 3
    ifort: 5
    nvfortran: array already allocated
    nvfortran: allocated? T len= 132
    nvfortran: 5

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John@21:1/5 to All on Wed Mar 23 20:44:55 2022
    program testit
    character(len=:),allocatable :: line
    line=''
    allocate(character(len=132) :: line)
    end program testit

    I think gfortran wins this one.

    gfortran:Fortran runtime error: Attempting to allocate already allocated variable 'line'
    ifort:forrtl: severe (151): allocatable array is already allocated
    nvfortran:0: ALLOCATE: array already allocated

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Lionel@21:1/5 to John on Thu Mar 24 10:56:36 2022
    On 3/24/2022 12:06 AM, John wrote:
    If you are making a tweet, a question I had about allocate is does the standard require a failed allocate to make no change to the variables listed, or is the state undefined? That is, after this failed ALLOCATE() do I know anything about the state of
    the variable per the standard?

    Allocatable variables do not have an undefined state - it is either
    allocated or unallocated (9.7.1.3).

    If an ALLOCATE fails, the allocation status is unchanged. This applies
    to both allocatable and pointer variables (pointers can have an
    undefined state.)

    --
    Steve Lionel
    ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
    Retired Intel Fortran developer/support
    Email: firstname at firstnamelastname dot com
    Twitter: @DoctorFortran
    LinkedIn: https://www.linkedin.com/in/stevelionel
    Blog: https://stevelionel.com/drfortran
    WG5: https://wg5-fortran.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John@21:1/5 to All on Thu Mar 24 16:53:16 2022
    Is stated that the value as well as the allocation status remains the same. I could not find that, and gfortran and ifort left it as it was before the failed allocate, but nvfortran applied the length but left the original values intact, padding the
    value with nulls (not blanks). I planned on reporting that but wanted to make sure the compiler was not free to change the state and value on failure of an allocate.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John@21:1/5 to Steve Lionel on Thu Mar 24 16:50:34 2022
    On Thursday, March 24, 2022 at 10:56:42 AM UTC-4, Steve Lionel wrote:
    On 3/24/2022 12:06 AM, John wrote:
    If you are making a tweet, a question I had about allocate is does the standard require a failed allocate to make no change to the variables listed, or is the state undefined? That is, after this failed ALLOCATE() do I know anything about the state
    of the variable per the standard?
    Allocatable variables do not have an undefined state - it is either allocated or unallocated (9.7.1.3).

    If an ALLOCATE fails, the allocation status is unchanged. This applies
    to both allocatable and pointer variables (pointers can have an
    undefined state.)

    --
    Steve Lionel
    ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
    Retired Intel Fortran developer/support
    Email: firstname at firstnamelastname dot com
    Twitter: @DoctorFortran
    LinkedIn: https://www.linkedin.com/in/stevelionel
    Blog: https://stevelionel.com/drfortran
    WG5: https://wg5-fortran.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Lionel@21:1/5 to John on Thu Mar 24 20:28:38 2022
    On 3/24/2022 7:53 PM, John wrote:
    I planned on reporting that but wanted to make sure the compiler was not free to change the state and value on failure of an allocate.

    It is not. Report the bug.

    --
    Steve Lionel
    ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
    Retired Intel Fortran developer/support
    Email: firstname at firstnamelastname dot com
    Twitter: @DoctorFortran
    LinkedIn: https://www.linkedin.com/in/stevelionel
    Blog: https://stevelionel.com/drfortran
    WG5: https://wg5-fortran.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John@21:1/5 to Steve Lionel on Thu Mar 24 19:30:32 2022
    On Thursday, March 24, 2022 at 8:28:43 PM UTC-4, Steve Lionel wrote:
    On 3/24/2022 7:53 PM, John wrote:
    I planned on reporting that but wanted to make sure the compiler was not free to change the state and value on failure of an allocate.
    It is not. Report the bug.
    --
    Steve Lionel
    ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
    Retired Intel Fortran developer/support
    Email: firstname at firstnamelastname dot com
    Twitter: @DoctorFortran
    LinkedIn: https://www.linkedin.com/in/stevelionel
    Blog: https://stevelionel.com/drfortran
    WG5: https://wg5-fortran.org

    https://forums.developer.nvidia.com/t/a-failed-allocate-statement-should-not-change-values/209348

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John@21:1/5 to All on Fri Mar 25 14:23:51 2022
    FYI: For reference, filed as nvfortran issue TPR #31549

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)