Problem with allocatable string array expansion

[Xj_Kong]

program SumRes
implicit none

! file1
!  lc120008A100Lh0_11     840.9    1031.9  1     843.3    1015.5  2     492.4    1496.3    5479.7    5956.7      1.26      3.03
!  lc122391A100Lh0_11     795.0    1146.5  8     796.8    1139.6  9     442.4    1453.2    5478.6    5927.7      1.18      4.01
  integer::nlc,ius=10
  character(:),allocatable::crad,StrArr(:)
  iuS=10; crad='lc120008A100Lh0_11     840.9    1031.9  1     843.3    1015.5  2     492.4    1496.3    5479.7    5956.7      1.26      3.03'
   do nlc=1,20000
        if(nlc==1)then
           strarr=[crad]
        else
           strarr=[strarr,crad] 
        end if
  end do  ! nsim
   
end program SumRes

! I got access violation when calling CRTIMP PFLS_GETVALUE_FUNCTION __cdecl __set_flsgetvalue in tidtable.c when nlc >8400 in a Modern 64bit PC, Win7 Platform and IVF11.

[Steven_L_Intel1]

Oh, you're using version 11.0? That version might have required adding /assume:realloc_lhs to the compiler options to get allocatable character variables to work properly. We changed that a long time ago to make that unnecessary.

[Xj_Kong]

Original objective is to keep the data in its original string format. That's why the string array has been used. Now, I think we should turn back to the real array which can be almost arbitrary large dimension.

[Xj_Kong]

The latest test on Intel® Fortran Compiler XE 13.1, 2013.5.198, and with and without  /assume:realloc_lhs gives the same problem of exception and violation.

Appreciate that some one can test it.

Kong

[IanH]

I suspect you are running out of stack space, with a temporary being created for each of the array constructions.  Put the body of the loop into a separate subroutine so that the stack gets reset each iteration.

[Xj_Kong]

I am not sure about the efficiency. But this might be the most straight-forward solution. So the stack can be reset repeatedly. /Thanks

[Steven_L_Intel1]

I agree - there is a problem here. We will look into it.

[Steven_L_Intel1]

I think Ian is on the right track. If I set a larger stack reserve size, 20000000, then the program runs to completion. My guess is that the compiler isn't checking for stack overflow when it should. In Visual Studio, set Linker > System > Stack Reserve Size to a larger value (such as 20000000). From the command line, use /link /stack:20000000 at the end of the ifort line that does the link.

I will let the developers know about this. Issue ID is DPD200253910.

[Xj_Kong]

Hi Steve,

Is it possible for your developers to expand TRIM(string) function to accept string array with concatenation like the following?

INTEGER::IU=5,I

CHARACTER(:),ALLOCATABLE::DIRS(:)

DIRS='C:\DOCUMENT\'//['BOOKS\','PAPER_AND_THESIS\']//'2014\'
! OBVIOUSLY THE OUTPUT PATH WILL BE 'C:\DOCUMENT\BOOKS\         2014\'
! DIRS='C:\DOCUMENT\'//TRIM(['BOOKS\','PAPER_AND_THESIS\'])//'2014\'

DO I=1,2

 OPEN(UNIT=IU,FILE=DIRS(I)//'SUBMITTED.LOG',STATUS='UNKNOWN')

END DO

[Steven_L_Intel1]

The Fortran standard requires the argument to TRIM to be a scalar - you're passing an array. This isn't a concatenation. Even if we did make TRIM be an elemental function, which we're not about to do, it wouldn't do what you want (and the semantics of that would be very difficult to define.)
 

[Steven_L_Intel1]

The developers have told me that the compiler does not currently check for stack overflow when creating temporaries in the body of the procedure.  Perhaps we could add an optional check in a future release.