Joseph Myers wrote: > On Fri, 7 Feb 2020, Ulrich Weigand wrote: > > > I thought that a *more specific* option like -fsignalling-nans was always > > intended to override a more generic option like -ffast-math, no matter > > whether it comes before or after it on the command line. > > Yes, that's correct. (There are cases where it's ambiguous which option > is more specific - see what I said in > <https://gcc.gnu.org/ml/gcc/2016-03/msg00245.html> about -Werror= - but I > don't think -ffast-math involves such cases.)
I see. However, this does not appear to be implemented in current code. GCC (without my patch) behaves like this (using -fno-finite-math-only as an example instead of -fsignaling-nans, given the separate point about the latter option raised by Segher): gcc -dD -E -x c /dev/null | grep FINITE #define __FINITE_MATH_ONLY__ 0 gcc -dD -E -x c /dev/null -ffast-math | grep FINITE #define __FINITE_MATH_ONLY__ 1 gcc -dD -E -x c /dev/null -ffast-math -fno-finite-math-only | grep FINITE #define __FINITE_MATH_ONLY__ 0 gcc -dD -E -x c /dev/null -fno-finite-math-only -ffast-math | grep FINITE #define __FINITE_MATH_ONLY__ 1 Given the above rule, in the last case __FINITE_MATH_ONLY__ should also be 0, right? I'm not sure how this can be implemented in the current option handling framework. The -ffast-math handling case would have to check whether or not there is any explicit use of -f(no-)finite-math-only; is there any infrastructure to readily perform such a test? Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
