https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78509
--- Comment #6 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> --- None of the logic was there in the original code, so there is not much to compare. The question for the backend when TYPE is EXCESS_PRECISION_TYPE_FAST or EXCESS_PRECISION_TYPE_STANDARD is, does it wants tree.c to insert operations to guarantee explicit excess precision for the types, or does it wants tree.c to keep them as their native types. The assert exists because it makes no sense to ask the front-end to explicitly make the operations unpredictable. The fix which most closely maps to the semantics I think i386 wants is... For EXCESS_PRECISION_TYPE_FAST: Always return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT For EXCESS_PRECISION_TYPE_STANDARD: If we're in a mode which should never promote, or we're in a mode which will be implicitly unpredictable, return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT If we're in the mode which should explicitly promote to LONG_DOUBLE, do that. For EXCESS_PRECISION_TYPE_IMPLICIT: Keep the current logic. I'll write a patch along those lines, and test it as well as I can, but I don't really know how to get good -m32 testing out of my x86_64 box, which doesn't have a good multilib environment set up. If you can point me at a machine in the compile farm I can use I'd be happy to test more extensively.
