https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119007
--- Comment #2 from Jin Ma <majin at gcc dot gnu.org> --- (In reply to Jeffrey A. Law from comment #1) > I think when we discussed his several weeks ago the conclusion was this was > a problem in the intrinsics space. > > Essentially the intrinsics can modify FRM and when they do they probably > need to set -fno-rounding-math for at least the whole function in question. > That way the generic optimizers won't try to simplify FP ops assuming we're > still in the default rounding mode. Regarding this issue, I believe the optimal approach might be to follow scalar handling practices - explicitly documenting this behavior in the RVV Intrinsic specification rather than modifying the compiler. For example, add the following description in the RVV Intrinsic documentation: ```Compilers default to RNE (Round to Nearest, Ties to Even) for FP optimization, which may cause correctness issues when rounding modes change dynamically - use -frounding-math to preserve exact semantics, especially with RVV intrinsics in rounding-sensitive code.``` Or a more detailed description: ```By default, compilers assume floating-point operations follow the IEEE 754 "Round to Nearest, Ties to Even" (RNE) mode and perform aggressive optimizations under this assumption. However, if the program dynamically changes the rounding mode (e.g., through architecture-specific intrinsics or system calls), these optimizations may introduce correctness issues. For example, redundant FP conversions or constant folding could become invalid under non-default rounding. To mitigate this, -frounding-math disables rounding-sensitive optimizations, forcing the compiler to preserve exact FP semantics at a potential performance cost. This is particularly crucial when using RISC-V Vector (RVV) intrinsics or other operations that depend on precise rounding control, as incorrect optimizations might lead to subtle numerical errors. Always enable this flag for rounding-mode-aware code unless performance outweighs precision requirements.``` Ref: https://gcc.gnu.org/wiki/FloatingPointMath https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
