Hi Tobias, > @All, Harald: Does the attached patch make sense?
first of all: sorry for the really badly designed testcase. The best solution has already been discussed in this thread, which is to replace integer(16), parameter :: m1 = 9007199254740992_16 !2**53 integer(16), parameter :: m2 = 10384593717069655257060992658440192_16 !2**113 by integer(16), parameter :: m1 = 2_16 ** digits (x) ! IEEE: 2**53 integer(16), parameter :: m2 = 2_16 ** digits (y) ! IEEE: 2**113 The motivation was to test that compile-time and run-time produce the same correct result, as well as verifying that the user gets what he/she would naively expect from the intrinsic. There should be no hidden double conversion that might e.g. truncate. I decided for the largest real values which are exactly representable also as integer, and for which the rounding operation should always reproduce the expected result. E.g. nint (x) - nint (x-1) should give 1, while nint (x) - nint (x+1) might give 0, which happens for the chosen values on x86. I had this in my mind, but decided to drop this because I had no idea if there are exotic, non-IEEE, or other implementations which would fail on this. Thanks for fixing this! Harald
