Unexpected differences with -assume byterecl in a large program

[Arjen_Markus]

We have run into unexpected differences in a large program (order 100000 lines of code) that occur when it is built with or without the compiler option -assume byterecl. These differences even occur when there is no unformatted I/O. Typical differences are in the order of 0.1% but are occasionally quite a bit larger.

My colleague assures me that the only difference between the builds is the use of this particular option.

It is not going to be easy to reduce the program size, but it is an open-source program.

Does anybody have a clue where this might be coming from or how to analyse it?

[Steve_Lionel]

The only thing this should affect is the interpretation of RECL= in an OPEN. If the value specified is inconsistent with the option specification, it could affect formatted I/O too (if ACCESS='DIRECT' or RECORDTYPE='FIXED').

What I have done in the past, when confronted with result divergence, is to instrument the code with logging of intermediate values, then compare runs.

[Arjen_Markus]

What we are thinking of is compile selected parts of the program with and without the option and try to isolate the culprit that way. I do not know it well enough to judge how much work it will be (it is not organised in neat little libraries/directories), the alternative as you suggest is to print the intermediate results. Either way, we are going to have some fun hunting this down.

[Steve_Lionel]

That's an excellent approach. Good luck!

[Arjen_Markus]

Thanks, we can use a bit of luck ;).

[Steve_Lionel]

I assume you know about the binary search approach to this - compile half with the option and half without, then reduce the half that shows the problem by half, etc.

[JohnNichols]

Excellent advice for tracking down problems.