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

Problem with initialization of derived type variable

johnyb_
New Contributor I
609 Views

In the following example code, the behaviour changes if the value of the parameter clen is more than 7196

[fortran]program test
    integer, parameter :: clen = 7197
    TYPE T_BLOCK
        character(len=clen)    :: ch
    end type T_BLOCK

    type(T_BLOCK) :: b2
    type(T_BLOCK) :: b1 = T_BLOCK( '' )
    b2                  = T_BLOCK( '' )   

    print *, "clen          :", clen
    print *, "len_trim b1%ch:", len_trim(b1%ch)
    print *, "len_trim b2%ch:", len_trim(b2%ch)

    if (b1%ch /= '') then
        print *, "b1 ch is not empty"
    else
        print *, "b1 ch is empty"
    endif
    
    if (b2%ch /= '') then
        print *, "b2 ch is not empty"
    else
        print *, "b2 ch is empty"
    endif
end program[/fortran]


with the value of 7196 i get the following:

[plain] clen          :        7196
 len_trim b1%ch:           0
 len_trim b2%ch:           0
 b1 ch is empty
 b2 ch is empty
[/plain]

with the value of 7197 i get this:

[plain]clen          :        7197
len_trim b1%ch:        7197
len_trim b2%ch:           0
b1 ch is not empty
b2 ch is empty[/plain]

I compile without any options:
C:\\TEMP>ifort test.f90
Intel Visual Fortran Compiler XE for applications running on IA-32, Version 12.1.1.258 Build 20111011
Copyright (C) 1985-2011 Intel Corporation. All rights reserved.

Microsoft Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.

-out:test.exe
-subsystem:console
test.obj

In the compiler documentation I read about a limit for character and Hollerith constants of 7198. However, in the above example, if I set clen to 50000 the behaviour is still the same as for 7197 (b1 not empty, b2 empty).

I can not understand if this is a compiler limit, compiler bug or a missunderstanding on my behalf.

I'd be grateful for any explanation

Johny

0 Kudos
4 Replies
Steven_L_Intel1
Employee
609 Views
I'd say that this is a compiler bug. It is in fact setting b1%ch to all nulls, or not setting it at all (more likely). I will report this to the developers - thanks for the nice test case. I would expect that, given this bug, any value above 7196 would fail in the same way. Issue ID is DPD200176374.
0 Kudos
johnyb_
New Contributor I
609 Views
Yes, any value above 7196 fails.

This happened in a piece of code that is generated where several character components of a derived type have a length of > 32000 characters. We have recently acquired licenses for Intel Fortran and I am porting our code, which worked nicely except for this small trouble.

I can work around the bug by changing the tests generated to something like if ( .not. b1%ch > '')

It only happens with derived types, simple character variables work correctly:
[fortran]program test
    integer, parameter :: clen = 50000

    character(len=clen)    :: ch1 = ''
    character(len=clen)    :: ch2
    
    ch2 = ''

    print *, "clen          :", clen
    print *, "ch1:", len_trim(ch1)
    print *, "ch2:", len_trim(ch2)

    if (ch1 /= '') then
        print *, "ch1 is not empty"
    else
        print *, "ch1 is empty"
    endif
    
    if (ch2 /= '') then
        print *, "ch2 is not empty"
    else
        print *, "ch2 is empty"
    endif
end program[/fortran]

and the result:

[plain] clen          : 50000
 ch1: 0
 ch2: 0
 ch1 ch is empty
 ch2 ch is empty[/plain]
0 Kudos
Steven_L_Intel1
Employee
609 Views
Yes, I expect this is related to the structure constructor, since this implicitly creates a value as long as the character component when used in an initialization expression. In the executable code, the components are assigned individually.
0 Kudos
Steven_L_Intel1
Employee
609 Views

We've found and fixed the bug here - it was indeed restricted to structure constructors when the character component was longer than 7196. I expect the fix to appear in the first update to the 15.0 compiler.

0 Kudos
Reply