https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111506
--- Comment #5 from Robin Dapp <rdapp at gcc dot gnu.org> --- Ah, thanks Joseph, so this at least means that we do not need !flag_trapping_math here. However, the vectorizer emulates the 64-bit integer to _Float16 conversion via an intermediate int32_t and now the riscv expander does the same just without the same restrictions. I'm assuming the restrictions currently imposed on two-step vectorizing conversions are correct. For e.g. int64_t -> _Float16 we require the value range of the source fit in int32_t (first step int64_t -> int32_t). For _Float16 -> int64_t we require -fno-trapping-math (first step _Float16 -> int32_t). The latter follows from Annex F of the C standard. Therefore, my general question would rather be: - Is it OK to circumvent either restriction by pretending to have an instruction that performs the conversion in two steps but doesn't actually do the checks? I.e. does "implementation-defined behavior" cover the vectorizer checking one thing and one target not doing it? In our case the int64_t -> int32_t conversion is implementation defined when the source doesn't fit the target.
