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? > > 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
