What actually breaks moving Fortran from 32-bit to 64-bit
Categories:
The optimistic version of a 64-bit migration is “change the compiler flags and rebuild”. On a real production system — in our case an ERP that had been running correctly for thirty years — the compile is the easy week. The interesting failures come later, and they’re quiet.
The data outlives the code. Binary record files written by a 32-bit program encode integer sizes and record layouts on disk. The 64-bit build happily reads them — into the wrong fields. Nothing crashes; the numbers are just wrong. Every on-disk format has to be audited before the first test run means anything.
Implicit assumptions don’t announce themselves. EQUIVALENCE blocks,
common blocks sized in words, integers stuffed into the halves of a REAL*8 —
these were normal techniques when memory was expensive. The compiler accepts
them all at 64 bits; the behaviour just changes. Static analysis finds some.
Only comparison testing finds the rest.
“Matches the old system” is the only spec that matters. The business logic was never documented — the 32-bit binary is the documentation. So the migration that works is the one where you build a test harness first, capture the 32-bit behaviour across real workloads, and refuse to cut over until the 64-bit build provably produces the same answers.
That harness — not the translation tooling — is where most of the engineering went, and it’s the part that keeps paying after cutover: the system now has a regression suite for the first time in its life.
The full write-up of how we approach this, including the tooling (Promula / gmFortran) and the cutover mechanics, is at Expertise → 32 → 64-bit migration. If you run Fortran in production and a migration is looming, talk to us.