why common named data block not really initialize?

[xinjian_qian]

I have ported a CVF 6.0project to VC.net and using IVF9 to compiler it. But I found my named block data which used to initialize global variables not acturaly initialize. Why? How can I do to make the named block data actually initialize? Note: Our code is ok in VC6.0 and CVF.

Best Regards!

[emc-nyc]

By "initialize", I'm presuming you mean "set to 0". It is, bluntly, bad practice to assume the compiler will do this for you; it is not standard compliant behavior, and many will not initialize anything. Some will when compiles are done with debugging turned on but won't when the optimizer is used.



Explicitly initialize everything.

Message Edited by emc-nyc on 11-30-2005 04:21 PM

[TimP]

The standard way to initialize labeled common at program load time is with BLOCK DATA. Many compilers have additional means, but none of the non-standard ways can be counted upon, particularly now that alternatives to COMMON are generally recommended for new development.

[xinjian_qian]

Thanks for your reply! but I mean, I used the Block data to explicitly initialized my project varibles, like initialize a variable to 5 in Block data. But when I debug, I found the initialize in Block data is not effect. such as the varialbe still 0, but 5. My project code (.cxx and .f mix program) in VC6 and CVF6.6 is ok, the Block data can initialize. but When I used the VC.net 2003 and IVF 9.0 to build. found this problems. help!

Best Regards!

[jim_dempsey]

You might have two different named variables. One with the leading "_" and one without. Or, as I experienced recently, If you are compiling with OpenMP the variables declared in a module have the module name pre-pended to the variable:

module mod_foo

real :: fooArray(1000)

...

(With OpenMP)

creates

MOD_FOO_mp_fooArray

Then if you have additionaly compiled a source file without OpenMP your program will also contain "_fooArray". One of the two get initialized.

If you are not compiling with OpenMP you may have other similar problems.

What you could do to track this down is to insert a little test subroutine in the source module that initializes the data. Something like

Code:

module YourModule
real :: YourData(someSize)
...
end module YourModule
contains
subroutine CheckYourData(suspicious)
real :: suspicious(*)
if(loc(YourData(1)) .ne. loc(suspicious(1))) then
 write(*,*) "(loc(YourData(1)) .ne. loc(suspicious(1)))"
 stop
endif
end subroutine CheckYourData
....
Then in the source module that exhibits the un-initialized data insert

  call CheckYourData(YourData)

Jim

[xinjian_qian]

Hi tim:

Thanks for your reply? You mean I have to not using OpenMP? I have closed all OpenMP to "no" in all projects. It still have the same problem. I am very confused.

block data bdhaha

C Included from: gi.dek
include 'gi.fh'

data luhah / 5 /

end

at using place, I used: external bdhaha

To your check program, Our project's loc seems have other use, I can't insert your code to our projects.

and Could you tell me how to fix this problem by use of change project settings?

Best Regards!

[hansr]

How do you transfer the value of luhah in your example?

I miss something like "common luhah" in the block data and in the calling routine.

Hans

[xinjian_qian]

The luhah is defined in gi.fh (global), it's a integer, I initialized it in bdhaha to 5. At using place, using "external bdhaha"

Best Regards!

[emc-nyc]

If you are using BLOCK DATA to initialize a common block make very sure it's actually being linked in. I usually do this by explicitly including it in the same file as the main program.

My experience is that if a BLOCK DATA routine is missing, the linker won't generate a warning. If you have multiple BLOCK DATAs with the same (or no) name, this may also be confusing the linker.

My suggestions, then, are:

1) Listen to tim18; use more module variables, vs common.

2) If you can't do that, put all your BLOCK DATAs are in a file with executable code -- say your main program. If you have multiple BLOCK DATAs, give them each distinct names which are also distinct from the names of any subroutines, functions, and common blocks.

[hansr]

>>At using place, using "external bdhaha"

sorry, but I think this doesn't replace theredefinition of the common defined in gi.fh. (common /com1/ luhah)

With this your sample runs at me.

Hans

[xinjian_qian]

thanks emc!

David