On Sat, Aug 17, 2024 at 11:18 PM Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Sat, Aug 17, 2024 at 05:03:14AM +0000, Li, Pan2 wrote:
> > Please feel free to let me know if there is anything I can do to fix this
> > issue. Thanks a lot.
>
> There is no bug. The operands of .{ADD,SUB,MUL}_OVERFLOW don't have to have
> the same type, as described in the __builtin_{add,sub,mul}_overflow{,_p}
> documentation, each argument can have different type and result yet another
> one, the behavior is then (as if) to perform the operation in infinite
> precision and if that result fits into the result type, there is no overflow,
> otherwise there is.
> So, there is no need to promote anything.
Hmm, it's a bit awkward to have this state in the IL. I see that
expand_arith_overflow eventually applies
promotion, namely to the type of the LHS. Exposing this earlier could
enable optimization even
apart from IL hygiene which is violated with different typed operands
of an ADD, SUB or MUL.
Richard.
>
