Summary of the general policy of floating point arithmetic in GCC BOF (2007 GCC Summit)
Following the issues that were discussed:
What is the "acceptable" level of FP accuracy -ffast-math should follow? A black and white approach vs. allowing only "acceptable" level of FP accuracy. Add -faggressive-math? (http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01146.html)
- Do –ffast-math (or subset of it) by default like other compilers do. Precondition - run SPEC without regressions.
- PR 28684 – Imprecise -funsafe-math-optimizations flag definition. The claim: Unsafe-math does not violate IEEE standard 754 but ANSI/ISO C rules. This should be re-visited after splitting funsafe-math-optimizations into sub-flags.
Allow re-ordering on non-strictly ordered computations. The problem – some programs (like glibc) contains strictly ordered statements. Currently there is all or nothing policy regarding applying re-ordering optimization which prevents using -funsafe-math-optimization on such programs. No simple solution; one is to introduce new tree type similar to volatile such that it will prevent re-association. (see PR32172 and http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00983.html)
- Trapping-math - not defined well, no tests, possible of trapping where there are NANS.
- Add more testcases to the ieee directory; for each fp-flag.
Improve documentation. (starting with http://gcc.gnu.org/wiki/GeertBosch).