Bugfix/atrayno/#338 enf of file gfortran bug

[atrayano]

Description

Fixes #338. Adds a workaround for a gfortran bug that handles end-of-file incorrectly

Related Issue

Motivation and Context

How Has This Been Tested?

@mathomp4 tested the fix on discover and on his laptop

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Trivial change (affects only documentation or cleanup)

Checklist:

• I have tested this change with a run of GEOSgcm (if non-trivial)
• I have added one of the required labels (0 diff, 0 diff trivial, 0 diff structural, non 0-diff)
• I have updated the CHANGELOG.md accordingly following the style of Keep a Changelog

[mathomp4]

I did test this with GEOSgcm and it didn't seem to change any answers with GNU or Intel.

[tclune]

I don't think this is a bug in gfortran, but rather an attempt to do an unformatted read on a formatted file. The READ in question is missing a format.

http://www.hep.manchester.ac.uk/u/samt/misc/gfortran_errors.html

The correct fix would appear to be to read it one way for FORMATTED and the other for UNFORMATTED.

[atrayano]

@tclune Let discuss this in the morning. This is no formatted/unformatted file issue. Before I coded the "fix" I also have looked at at about several years old patch for gfortran that introduces LIB_ERROR_OPTION_CONFLICT (i.e. 5001). My point is that we intentionally read the file (in this case unformatted binary) to check if we are past the end-of-file. Every other compiler returns properly IOSTAT=IOSTAT_END. But gfortran returns 5001

[tclune]

I made a logical error in my analysis yesterday. PR is fine. This does appear to be a bug in gfortran based upon an isolated reproducer.