On Tue, Apr 29, 2025 at 12:56 PM Hongtao Liu <crazy...@gmail.com> wrote: > > On Sun, Apr 27, 2025 at 10:58 AM H.J. Lu <hjl.to...@gmail.com> wrote: > > > > When passing 0xff as an unsigned char function argument with the C frontend > > promotion, expand_normal used to get > > > > <integer_cst 0x7fffe6aa23a8 type <integer_type 0x7fffe98225e8 int> constant > > 255> > > > > and returned the rtx value using the sign-extended representation: > > > > (const_int 255 [0xff]) > > > > But after > > > > commit a670ebde3995481225ec62b29686ec07a21e5c10 > > Author: H.J. Lu <hjl.to...@gmail.com> > > Date: Thu Nov 21 07:54:35 2024 +0800 > > > > Drop targetm.promote_prototypes from C, C++ and Ada frontends > > > > expand_normal now gets > > > > <integer_cst 0x7fffe9824018 type <integer_type 0x7fffe9822348 unsigned char > > > co > > nstant 255> > > > > and returns > > > > (const_int -1 [0xffffffffffffffff]) > It sounds like a general issue which should be fixed in expand_normal > instead of fixing it in the backend?
It is related to trunc_int_for_mode. I think this is a backend issue. > > > > which doesn't work with the predicates nor the instruction templates which > > expect the unsigned expanded value. Extract the unsigned char and short > > integer constants to return > > > > (const_int 255 [0xff]) > > > > so that the expanded value is always unsigned, without the C frontend > > promotion. > > > > PR target/117547 > > * config/i386/i386-expand.cc (ix86_expand_unsigned_small_int_cst_argumen > > t): > > New function. > > (ix86_expand_args_builtin): Call > > ix86_expand_unsigned_small_int_cst_argument to expand the argument > > before calling fixup_modeless_constant. > > (ix86_expand_round_builtin): Likewise. > > (ix86_expand_special_args_builtin): Likewise. > > (ix86_expand_builtin): Likewise. > > > > -- > > H.J. > > > > -- > BR, > Hongtao -- H.J.
