- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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]
1 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I expect the fix for this bug to be in the next update (early September).
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Looks like a bug. Thanks, I'll report this. Issue ID is DPD200137715.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I expect the fix for this bug to be in the next update (early September).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Steve Lionel (Intel)
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This second issue is fixed in our sources, but the fix won't appear in the product for a while.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page