Difference: CompilerWoes ( vs. 1)

Revision 124 May 2006 - FawziMohamed

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="FortranBase64"

Compiler Woes

Making the code work across compilers without cluttering the code too much was not easy. It seems that ieee compliance, ieee functions, fraction, exponent are not well standarized, and not very much tested across compilers.

I found out a couple of interesting bugs or strange behaviours through this:

  • g95:
    • denormalized numbers (1.4e-45..2.35e-38 single precision, 4.94e-324..4.45e-308 double precision) are read in incorrectly (bug filed)
    • Apart from this only for g95 r=scale(fraction(r),exponent(r)) is true for any r which is not nan or infinity (i.e. it was one of the saner compilers)
  • intel:
    • denormalided numbers are clamped to 0 unless one compiles with the "-mp" (mantain precision) flag. For a single precision version of the code I think that this could be relevant and really make a difference.
    • It cannot read back inf and nan
  • NAG:
    • denormalized numbers are printed/read in a way such that it is not possible to obtain exactly the same number through a formatted input.
    • It cannot read back inf and nan
    • compile it with -D__NAG
  • xlf:
    • works well, only compiler that can convert back and forth also denormalized numbers to formatted output
    • compile it with -qsuffix=cpp=F90 -WF,-D__XLF

Anyway finally it works on all these compilers...

If you have problems with other architectures, let me know. Run the python script testBase64.py to test the resulting executable on your architecture...

-- FawziMohamed - 24 May 2006

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback