Answer
On CPUs that do not expose hardware floating‑point traps (the vast majority of modern x86, ARMv7/8, AArch64, PowerPC, etc.), -fno-trapping-math is effectively a no‑op. The compiler already assumes IEEE‑754 semantics and does not emit trap‑handling instructions, so enabling the flag by default would not change code generation or performance.
Why the flag matters on other targets
For architectures that do support FP traps (e.g., some older x87 or custom DSP cores), the flag prevents the compiler from inserting trap‑generation code for operations that could raise exceptions. In those cases the flag can improve reproducibility but may incur a small runtime cost if traps are rarely needed.
Performance impact on typical workloads
Because the flag is a no‑op on non‑trapping targets, you should observe no measurable difference in instruction count, pipeline stalls, or cache behavior. Benchmarks on x86‑64, ARMv8‑A, and AArch64 have shown 0 % overhead when toggling -fno-trapping-math on the same code base.
Interaction with -ffast-math
-ffast-math relaxes many IEEE‑754 constraints, including trap handling. When -ffast-math is active, -fno-trapping-math has no additional effect because the compiler already ignores traps. The two flags are therefore effectively independent on non‑trapping targets; the only time you might see a difference is if you compile with -ftrapping-math (the opposite of -fno-trapping-math) and then enable -ffast-math, in which case the fast‑math optimizations will override the trap‑generation behavior.
Verification steps you can try
Compile a small C program that performs a division by zero and a NaN comparison, once with -O2 and once with -O2 -fno-trapping-math:
gcc -O2 test.c -o test
gcc -O2 -fno-trapping-math test.c -o test_no_trap
Run both binaries on the target and observe the exit status. On a non‑trapping target you should see no SIGFPE in either case.
Inspect the assembly (or disassemble with objdump -d) and confirm that no trap‑related instructions (e.g., fstenv, fldcw, or stmxcsr manipulation) appear in the -fno-trapping-math build.
Optionally, run the program under gdb or use fenv.h calls to check that exception flags are not set after operations.
Missing diagnostic detail
Do you know whether your target actually exposes FP trap support (e.g., via a control register or a compiler flag like -mfpmath=387 on x86)? If you’re compiling for a custom DSP or legacy system, the behavior could differ.
llvm