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.
