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)

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)

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)

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)

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)

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)

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)

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)

FYI: For reference, filed as nvfortran issue TPR #31549

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