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

Data statement not working?

Adrian_F_1
Beginner
697 Views

I think I am going crazy, what's wrong with this?

      character(20) :: rowt(6,12) = ' '
      data rowt(1,1:4) / ' ','zfactg','rhog','viscg' 

When I run, I get this in the debugger:

      -        rowt(1,1:4)    {...}    CHARACTER(20) 
        rowt(1,1)    '                    '    CHARACTER(20) 
        rowt(1,2)    '                    '    CHARACTER(20) 
        rowt(1,3)    '                    '    CHARACTER(20) 
        rowt(1,4)    '                    '    CHARACTER(20) 

0 Kudos
15 Replies
mecej4
Honored Contributor III
697 Views

You have initialized the array more than once: first in the declaration with an initialization clause, and again in the DATA statement.

0 Kudos
Adrian_F_1
Beginner
697 Views

No that's not it, as that was a cut-down version of the real code which shows some data is being set, see below:

      character(20) :: rowt(6,12) = ' '

      data rowt(1,1:4) / ' '   ,'zfactg'   ,'rhog'   ,'viscg' /
      data rowt(2,1:1) / 'psat'                               /
      data rowt(3,1:9) / ' '   ,'liq_rv'   ,'rv'     ,'yfun'   ,'zfactg','rhoo'  ,'rhog'  ,'visco' ,'viscg' /

-        rowt(1,1:4)    {...}    CHARACTER(20) 
        rowt(1,1)    '                    '    CHARACTER(20) 
        rowt(1,2)    '                    '    CHARACTER(20) 
        rowt(1,3)    '                    '    CHARACTER(20) 
        rowt(1,4)    '                    '    CHARACTER(20) 
-        rowt(2,1:1)    {...}    CHARACTER(20) 
        rowt(2,1)    ' sa                 '    CHARACTER(20) 
-        rowt(3,1:9)    {...}    CHARACTER(20) 
        rowt(3,1)    '                    '    CHARACTER(20) 
        rowt(3,2)    ' i _rv              '    CHARACTER(20) 
        rowt(3,3)    'r                   '    CHARACTER(20) 
        rowt(3,4)    'y                   '    CHARACTER(20) 
        rowt(3,5)    'z    g              '    CHARACTER(20) 
        rowt(3,6)    'rhoo                '    CHARACTER(20) 
        rowt(3,7)    'rho                 '    CHARACTER(20) 
        rowt(3,8)    ' isco               '    CHARACTER(20) 
        rowt(3,9)    '  sc                '    CHARACTER(20) 

 

0 Kudos
mecej4
Honored Contributor III
697 Views

There is an initialization in the declaration on line-1 of #3. Lines-3, 4 and 5 provide alternative initializations for the same variable (rowt).

I cannot make sense of lines 7 and later in #3, if they are part of a Fortran source code..

From section 5.2.3, "Initialization", of the Fortran Standard:

The appearance of initialization in an entity-decl for an entity without the PARAMETER attribute specifies that the entity is a variable with explicit initialization. Explicit initialization alternatively may be specified in a DATA statement unless the variable is of a derived type for which default initialization is specified.

...

A variable, or part of a variable, shall not be explicitly initialized more than once in a program.

 

0 Kudos
andrew_4619
Honored Contributor II
697 Views

Lines 7 and later are showing debugger output for the variable values from one of the the watch windows I think....

 

 

0 Kudos
mecej4
Honored Contributor III
697 Views

app4619 wrote:
Lines 7 and later are showing debugger output for the variable values from one of the the watch windows I think....

I wonder if the compiler should have refused to produce an EXE in this case, since the code has errors.

0 Kudos
Adrian_F_1
Beginner
697 Views

Yes lines 7-> are the debug output lines which show the rather strange initialization of the array.

I would have hoped the declaration would have blanked out the entire array, then the DATA statement selectively assign values to certain elements.  In fact it did selectively assign values but very strangely...

Steve?

0 Kudos
andrew_4619
Honored Contributor II
697 Views

Put some standards checking on and see if it throws some errors...

However I am surprised it compiles because I don't think it is valid to initialise strings in that way. It looks like a case of 'garbage in garbage out' IMO but that said I don't think the compiler is behaving correctly.

Data statements are very f77 there are other ways but if you only have a handful of the 6x12=72 elements set non-blank why not just assign those at run time otherwise you I think you need to initialise all 72 at FULL length (in your case 20) something like:

character(len=4), save :: gt(8)=(/'1   ','2   ','10  ','20  ','50  ','100 ','1000','2000'/)

 

0 Kudos
Lorri_M_Intel
Employee
697 Views

If you compile with /stand, the compiler will do more error checking about initialization overlaps.  This, however, may cause a great increase in compile-time performance when there are many initializations to the same object (such as a COMMON block with a big DATA statement).

And, yes, when there are multiple initializations to the same object, it is non-deterministic which initialization will ultimately override.

                    --Lorri

0 Kudos
mecej4
Honored Contributor III
697 Views

Adrian F., #7 wrote:
I would have hoped the declaration would have blanked out the entire array, then the DATA statement selectively assign values to certain elements.  In fact it did selectively assign values but very strangely...

The DATA statement is not executable. The variables in the statement will be assigned the values specified, prior to the running of the program. The data may be placed in the initialized data segment, in which case the OS program loader takes care of the initialization, or the assignments can be made in the start-up code that is run before the program itself is given control.

0 Kudos
Adrian_F_1
Beginner
697 Views

I know it is not executable, I just thought the compiler would do something a bit more sensible than what it did.   Or if it didn't know what to do, then issue a warning.

0 Kudos
Steven_L_Intel1
Employee
697 Views
C:\Projects>ifort /c /stand t.f90
Intel(R) Visual Fortran Compiler XE for applications running on IA-32, Version 14.0.2.176 Build 20140130
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

t.f90(1): warning #5436: Overlapping storage initializations encountered with ROWT
character(20) :: rowt(6,12) = ' '
-----------------^

The compiler allows you to have overlapping initializations as an extension and, as Lorri says, it warns you if you ask for standards warnings. It does know what to do with it but that may not be what you want.

0 Kudos
Adrian_F_1
Beginner
697 Views

Thanks Steve,

I have never used /stand (never heard of it until now).  But I guess I need to now invoke this as a default in all my projects, as clearly without it, I could get serious errors in my programs.  And as this is only a warning, I may need to look at warnings a little more seriously!  I will turn on /stand tomorrow and wait for the heavens to erupt.

Adrian

0 Kudos
Steven_L_Intel1
Employee
697 Views

/stand warns you about non-standard usage. It can help reveal things you might not want to do, but will also warn of extensions you deliberately use. 

0 Kudos
andrew_4619
Honored Contributor II
697 Views

Steve Lionel (Intel) wrote:

/stand warns you about non-standard usage. It can help reveal things you might not want to do, but will also warn of extensions you deliberately use. 

But you can suppress warning numbers you are happy with e.g.  /stand /Qdiag-disable:7025,5142,6477

0 Kudos
Adrian_F_1
Beginner
697 Views

I turned on /stand and selectively disabled those numbers I was happy with, and found some bugs!

Thanks for the help, Adrian

0 Kudos
Reply