------- Comment #5 from dominiq at lps dot ens dot fr 2007-09-11 15:40 ------- > Well, I think the "depending on the language being compiled" is important. I > think the testcase is valid Fortran, and shouldn't fail whatever the > optimization level you use.
FX, may I recall what you wrote in PR33296: > "A program is prohibited from invoking an intrinsic procedure under > circumstances where a value to be returned in a subroutine argument or > function > result is outside the range of values representable by objects of the > specified > type and type parameters, unless the intrinsic module IEEE_ARITHMETIC (section > 14) is accessible and there is support for an infinite or a NaN result, as > appropriate." Although there is no intrinsic involved in the test case, I don't see the logic to consider (abuse of) overflows valid for arithmetic operations and invalid for intrinsics. Now it would probably make sense to link the -fno-range-check option to -fno-strict-overflow (or to replace the former by the later): if one violation is allowed, I do not see why the other one could be forbiden. Note that without -fno-range-check the code gives a ton of hard errors. I stick to my opinion that, from a numerical point of view, the only valid option for exceptions is ABORT(). Last point, the two recent failures are the result of inlining not performed before (the other one was due to a bug that have been fixed). Unless it is shown that such inlining causes a performance regression, I do not see the point to revert it based on the behavior of (in)valid corner test cases. To see the lot of traffic involved by the gcc choice you can follow the threads starting at http://gcc.gnu.org/ml/gcc/2006-12/msg00459.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33391
