[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code

["vajdaz at protonmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934

--- Comment #15 from Zoltan Vajda <vajdaz at protonmail dot com> ---
In my special case, I have an embedded realtime application with a lot of FP
atithmetic on Intel 32 bit architecture (huge and complex legacy codebase). FPU
exceptions are enabled, so loading an SNaN results in an exception. This is
intended, and we will don't want to change this configuration. In this context
the generated ASM code does result in an fld of an uninitialized local
variable, where looking on the C++ code such an access should not be possible.
If the content of the uninitialized local variable happens to be a SNaN by
accident (chances are very small, but not zero), an FPU exception happens. And
again, based on the C++ code no FPU exception should be possible (assuming d is
not an SNaN).

Here is a synthetic example that triggers the exception by "placing a bomb" on
the stack.

https://gcc.godbolt.org/z/aooex6dcT

Function place_bomb() has an effect on what happens in func(). That should not
be the case! This is all valid C++ code.

This may now accidentally happen in our application. The behavior is
unpredictable, because it depends on what previous function calls left on the
stack.

If you change "-march=i686" to "-march=i386" in the example linked above,
everything goes fine.