Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29236 Discussions

Non expected behavior on deferred length string concatenation when they are fields in a type

thomas_boehme
New Contributor II
895 Views
During testing of the new deferred length character strings, I have found another issue related to string concatenation.

For "normal" deferred charater strings, the following seems to be allowed and is working fine:

A = A // B

However, if the string A is not directly declared as character string, but rather contained in a type (see attached code), then the concatenation does not work as expected.
In the code example, at the end, I'd expect a string 'abcdef', however, I get '===def' on screen.

Is that a issue with the new compiler v11.1 or is a concatenation like that generally not permitted.

regards,
Thomas
[plain]PROGRAM STRCAT
  TYPE tA
    CHARACTER(:),ALLOCATABLE :: Text
  END TYPE
  CHARACTER(:), ALLOCATABLE     ::  Str  
  TYPE (tA)      :: A
  A%Text = 'abc'
  Str = 'def'
  A%Text = A%Text // Str
  WRITE(*,*)  A%Text    
END PROGRAM STRCAT[/plain]

0 Kudos
1 Solution
Steven_L_Intel1
Employee
895 Views
I expect the fix for this bug to be in the next update (early September).

View solution in original post

0 Kudos
6 Replies
Steven_L_Intel1
Employee
895 Views
Looks like a bug. Thanks, I'll report this. Issue ID is DPD200137715.
0 Kudos
Steven_L_Intel1
Employee
896 Views
I expect the fix for this bug to be in the next update (early September).
0 Kudos
thomas_boehme
New Contributor II
895 Views
Looks like a bug. Thanks, I'll report this. Issue ID is DPD200137715.

I tested it with release 11.1.046 and it seems to be fixed now.

Thanks,
Thomas
0 Kudos
thomas_boehme
New Contributor II
895 Views

Unfortunately, I need to "reopen" this issue as I believethe fix does not work 100% correctly.

If appending an additional array element, the string length seems to be taken from the added element. In my opinion, the maximum length of all elements should be taken instead. See the code below. In the second WRITE statement the string "This is a long string" is truncated.
Is that intended behavior or accidential? I am pretty sure that it was diffferent with one of the initial IVF11.1 compilers.

Best regards,
Thomas

[plain]    program StrArrayConcat
    implicit none
    CHARACTER (LEN=:), ALLOCATABLE, DIMENSION(:) :: Str
    Str = [ 'This is a long string']
    WRITE(*,*) Str(1)
    Str = [ Str, 'Short string' ]
    WRITE(*,*) Str(1)
    WRITE(*,*) Str(2)
    end program StrArrayConcat[/plain]

0 Kudos
Steven_L_Intel1
Employee
895 Views

I think this is an unrelated issue. Your program here is not standard-conrforming as it violates the following rule regarding array constructors:

"If type-spec is omitted, each ac-value expression in the array constructor shall have the same length type parameters; in this case, the type and type parameters of the array constructor are those of the ac-value expressions." (p68, lines 8-10)

However, we do have an extension where we use the length of the longest ac-value expression to determine the length of the array constructor, and I'll agree with you that it is not working in this case. To be standard conforming, you'd want the following instead:

Str = [CHARACTER(LEN(Str)) :: Str, 'Short string' ]

and this works.

I will report this to the developers, but it will have lower priority because your test case is not standard code. The issue number is DPD200141790. This is not a regression - it behaved this way in earlier releases (or failed in a completely different manner in still earlier versions.)

0 Kudos
Steven_L_Intel1
Employee
895 Views
This second issue is fixed in our sources, but the fix won't appear in the product for a while.
0 Kudos
Reply