topic C:\Projects>ifort /c /stand t in Intel® Fortran Compiler

Data statement not working?

Adrian_F_1 — Mon, 23 Jun 2014 14:33:52 GMT

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)

You have initialized the

mecej4 — Mon, 23 Jun 2014 14:53:43 GMT

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

No that's not it, as this is

Adrian_F_1 — Mon, 23 Jun 2014 15:04:00 GMT

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)

From section 5.2.3,

mecej4 — Mon, 23 Jun 2014 15:21:00 GMT

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.

Lines 7 and later are showing

andrew_4619 — Mon, 23 Jun 2014 18:43:41 GMT

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

Quote:app4619 wrote:Lines 7

mecej4 — Mon, 23 Jun 2014 19:53:00 GMT

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.

Yes lines 7-> are the debug

Adrian_F_1 — Mon, 23 Jun 2014 20:09:04 GMT

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?

Put some standards checking

andrew_4619 — Mon, 23 Jun 2014 20:28:49 GMT

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'/)

If you compile with /stand,

Lorri_M_Intel — Mon, 23 Jun 2014 20:29:05 GMT

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

Quote:Adrian F., #7 wrote:I

mecej4 — Mon, 23 Jun 2014 21:50:07 GMT

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.

I know it is not executable,

Adrian_F_1 — Tue, 24 Jun 2014 06:08:54 GMT

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.

C:\Projects>ifort /c /stand t

Steven_L_Intel1 — Tue, 24 Jun 2014 18:23:38 GMT

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.

Thanks Steve,

Adrian_F_1 — Tue, 24 Jun 2014 18:43:47 GMT

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

/stand warns you about non

Steven_L_Intel1 — Tue, 24 Jun 2014 19:51:19 GMT

/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.

Quote:Steve Lionel (Intel)

andrew_4619 — Tue, 24 Jun 2014 20:10:36 GMT

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

I turned on /stand and

Adrian_F_1 — Wed, 25 Jun 2014 13:00:19 GMT

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

Thanks for the help, Adrian