[Bug middle-end/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875

["jgreenhalgh at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.