>>>>> int32_t x = (int32_t)0x1.0p32; >>>>> int32_t y = (int32_t)(int64_t)0x1.0p32; >>>>> >>>>> sets x to 2147483647 and y to 0. >>> >>> Hmm, good question. GENERIC has a direct truncation to unsigned char >>> for example, the C standard generally says if the integral part cannot >>> be represented then the behavior is undefined. So I think we should be >>> safe here (0x1.0p32 doesn't fit an int). >> >> We should be following Annex F (unspecified value plus "invalid" exception >> for out-of-range floating-to-integer conversions rather than undefined >> behavior). But we don't achieve that very well at present (see bug 93806 >> comments 27-29 for examples of how such conversions produce wobbly >> values). > > That would mean guarding this with !flag_trapping_math would be the > appropriate > thing to do.
Follow-up on this: When we do a NARROW_DST multiple-step conversion we do not guard with !flag_trapping_math. Is this intentional and if so, why do we only require it for the NONE case? I was thinking of implementing an expander for double -> int16 conversion for RISC-V with multiple steps but that would just circumvent the !flag_trapping_math check. Then I wondered why we vectorize this using multiple steps on x86 even with trapping math and it turns out that the difference is the NARROW_DST modifier but we emit VEC_PACK_FIX_TRUNC_EXPR anyway. Is this "safe"? Regards Robin
