On Fri, Nov 20, 2020 at 09:33:48PM -0700, Jeff Law wrote: > > * doc/invoke.texi (-ffast-math): Remove mention of -fno-signaling-nans. > > Clarify conditions when __FAST_MATH__ preprocessor macro is defined. > > > > * opts.c (common_handle_option): Pass OPTS_SET to set_fast_math_flags > > and set_unsafe_math_optimizations_flags. > > (set_fast_math_flags): Add OPTS_SET argument, and use it to avoid > > setting flags already explicitly set on the command line. In the !set > > case, also reset x_flag_cx_limited_range and x_flag_excess_precision. > > Never reset x_flag_signaling_nans or x_flag_rounding_math. > > (set_unsafe_math_optimizations_flags): Add OPTS_SET argument, and use > > it to avoid setting flags already explicitly set on the command line. > > (fast_math_flags_set_p): Also test x_flag_cx_limited_range, > > x_flag_associative_math, x_flag_reciprocal_math, and > > x_flag_rounding_math. > It appears this was dropped on the floor. It looks reasonable to me. > Please retest and commit. Thanks!
This did handle flag_excess_precision incorrectly, causing in particular https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97970 I've reverted for now and will post a modified patch later. Sorry for the breakage! At a first glance, it appears the problem is that -fexcess-precision=fast is already the default, so it does not make sense for -fno-fast-math to "reset" this back to default. Probably the best is for fast-math to simply not touch excess precision at all: - if it is set explicitly on the command line, fast-math should not affect it in any case; - if it is not set explicitly on the command line, the default either with fast-math or no-fast-math is excess-precision=fast, so again it should not be touched. I'll still need to look into the language-specific handling of the excess precision setting to make sure this works for all languages. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
