https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107702
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot
com> ---
On Tue, 15 Nov 2022, jakub at gcc dot gnu.org via Gcc-bugs wrote:
> _Float16 f9 (__int128 x) { return x; }
> _Float16 f10 (__int128 x) { return x; }
I suppose one of those is meant to be unsigned __int128?
> verifies that the __floattihf implementation always gives the same answer as
> does signed SImode -> SFmode cast followed by SFmode -> HFmode conversion.
> Isn't a conversion of a value > 65504 && value < -65504 UB in both C and C++?
No, an overflow is defined to produce an appropriately rounded value,
either an infinity or the largest finite value with the right sign,
depending on the rounding mode, with "overflow" and "inexact" raised (note
that the exact threshold for overflow depends on the rounding mode).
> So, can't we just implement the TI -> HF conversions by say ignoring upper 64
> bits of the __int128?
No. You could check for any high bits being set and e.g. use a different
path that converts a smaller value of the right sign that's still
guaranteed to overflow, if that's beneficial on a particular architecture
(it might well be if there's a hardware instruction for converting from
32-bit or 64-bit integers to _Float16, but not one for conversion from
128-bit integers, for example). Or you could go via converting such a
saturated value to SFmode if that's beneficial (standard C doesn't provide
any way to count the number of times an exception is raised by a single
operation, or the order in which they are raised, so it's OK that such an
approach may raise "inexact" before "overflow" and possibly more than
once).
