https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626
--- Comment #13 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- Strictly, all x86 excess precision cases are indeterminable (semantics of -1) except for the case where -fexcess-precision=standard is used (requires front-end support, present for C only), because of the possibility of intermediate values getting narrowed when spilt to the stack; in the absence of -fexcess-precision=standard, the choice of FLT_EVAL_METHOD is a heuristic one based on what code is likely to expect values of that macro to mean (including based on -fpermitted-flt-eval-methods= to control whether TS 18661-3 values can be used). Given the obscurity of the -msse -mno-sse2 -mfpmath=sse case I don't really think it makes sense to add a new enum flt_eval_method value and associated code that would be required to make that case of excess precision supported and predictable with -fexcess-precision=standard.
