On the SPU, all single-precision floating-point arithmetic always
takes place in round-to-zero rounding mode.  The Fortran front-end
always assumes round-to-nearest mode.  This causes a number of issues:

- Both real->string and string->real transformations (e.g. printf, scanf)
  operate in round-to-zero mode.  This means that a round-trip transform
  will often not yield an identical result; this causes e.g. the
  default_format_1.f90 test case to fail.

  It seems this cannot be fixed as the behaviour of printf and scanf
  is specified to follow round-to-zero on the SPU ...

- As a special case of the real->string->real round-trip transform problem,
  the value of GFC_REAL_4_HUGE from the (generated) kinds.h does not convert
  to the largest real when read back in, but its immediate predecessor.
  This causes the scalar_mask_2.f90 test case to fail.

  This can be fixed by using rounding away from zero when generating the
  string constant that is written to the kinds.h file.

- Compile-time operations performed by the Fortran front-end are always
  done in round-to-nearest mode.  This results in different results as
  compared to executing the corresponding operations at run-time.  This
  causes e.g. the integer_exponentiation_3.F90 test case to fail.

  This can be fixed by having the Fortran front-end check the target
  floating format rounding mode, and using this mode to perform
  compile-time operations in.