On Fri, 11 Dec 2020, Andrew Haley via Gcc wrote:
> On 11/12/2020 07:12, Marc Glisse wrote: > > On Thu, 10 Dec 2020, Lucas de Almeida via Gcc wrote: > > > >> when performing (int64_t) foo / (int32_t) bar in gcc under x86, a call to > >> __divdi3 is always output, even though it seems the use of the idiv > >> instruction could be faster. > > > > IIRC, idiv requires that the quotient fit in 32 bits, while your C code > > doesn't. (1LL << 60) / 3 would cause an error with idiv. > > Isn't that an integer overflow, which is undefined behaviour? No, see my other response in this thread. The division happens in type 'int64_t' aka 'long long' (no overflow), and then int64_t result is converted to int32_t in an implementation-defined manner (without UB). Generally speaking an implementation-defined signal may be raised if the result would not fit in int32_t, but GCC defines the behavior as bitwise truncation in all cases. Alexander
