/check:uninit

[lklawrie]

Same code, same compiler settings, one compiled with /check:uninit, one not.

Different results (sometimes quite different).

Is this expected? Does /check:uninit cause some different libarary to be used?

Release configuration:

/nologo /assume:buffered_io /real_size:64 /names:lowercase /module:"Release" /object:"Release" /traceback /check:uninit /c

/QPrec

Linda

[Steven_L_Intel1]

Different library? No. But memory allocation can be quite different, so if you have other errors using incorrectly addressed memory, this could cause a difference. I suggets also turning on /gen_interface and /warn:interface plus /check:bounds.

[lklawrie]

That should turn up problems?

And if it doesn't?

Linda

[Steven_L_Intel1]

It may turn up problems. If it doesn't, then it's debug time - watching the memory of the variable which changes unexpectedly and seeing where it changes. This sort of problem can be time-consuming.

[lklawrie]

so, theoretically the runs should produce the same results with and without /check:uninit (all other things being equal)

I added check allocate/pointers to the compile and am working through some problems found (compile time is sloooooow :-) but wanted to check the above (results the same) while I'm working through those.

Linda

[Steven_L_Intel1]

Uninitialized variable checking should not change the results of a correct program. It could change the results of a program that accessed memory outside of where it should be.

[lklawrie]

Nice in theory, doesn't seem to be holding up in practice. Spent most of two days running through issues identified with adding more checks to the basic compiler / release configuraiton. (including allocation detection and most of the issues were with that).

Reran checks -- version with check uninit still exhibits some major differences with the same code run without. And version run without is still similar to previous results.

I just can't spend more time on trying to track down whether this is an issue with our code (which is big and complex) or with the compiler.

Linda

[Steven_L_Intel1]

Those results strongly imply an error in the code, though a compiler error is of course a possibility.

[brianlamm]

I think you should try letting single and double precision REALs default to "4" and "8" respectively. I am posting a new thread in a moment wherein I will write about significant calculation errors when those two settings are set to "8" and "16" respectively, and all other settings remaining the same.

Leave uninitalized variable checking on and reset default REALs to "4" and "8" and see what you get regarding correctness.

Setting default INTEGER to "8", however, produced no such (correctness) errors.

Also, checking uninitialized variables caused problems within FORALL statements/constructs, but I think that's been resolved.

Brian Lamm

Oh yes, one other thing: builds wherein I had this correctness error were debug (I've not tried experimenting with release, yet). You might try building debug first, since it is much quicker than release.