[Bug fortran/48937] New: Discrepancy in computation between 32 and 64-bit builds

["thatcadguy at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48937

           Summary: Discrepancy in computation between 32 and 64-bit
                    builds
           Product: gcc
           Version: 4.5.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: thatcadguy@gmail.com


Created attachment 24214
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24214
zip file of the two source files in question and a makefile

I have created a subroutine to solve pentadiagonal systems of equations
according to H.L. Stone's 1968 paper. I have tested this subroutine on a
homework problem requiring such a system and observed similar results from
gfortran and MATLAB. For thoroughness, I have made a test program that creates
a random matrix to solve. Basically, in solving Ax = B, it creates a random A
and adds a fixed number to the diagonal to ensure the matrix is
well-conditioned. Exact x is hardcoded in the program and B is computed. Then,
A and B are given to the subroutine to find x iteratively and finally it prints
the absolute error between the iteratively solved x and the exact x.

I have compiled these files without error on both 32 and 64-bit versions of
mingw, both running under Windows 7. The 32-bit system is an Intel Atom
processor and the 64-bit system is an Intel CORE i7.

When run on the 32-bit system, the solution converges within 23 iterations
every time and shows an absolute error of zero, as should be expected. When run
on the 64-bit system, it almost never converges and seems to stay at a constant
residual around 1e-11 or will alternate between two or three values. Basically,
the same exact code converges on one system and fails to solve on the other.

These files are very simple in nature and only use simple loops and arithmetic.
About the only thing special that's used is the RANDOM_NUMBER intrinsic.

Note: I obtained these binaries from TDM-GCC. That may be to blame, or perhaps
mingw; anyone with a 64-bit Windows build should be able to quickly confirm
this bug or disprove it.