https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190
--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 9 Dec 2020, rsandifo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190 > > --- Comment #10 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot > gnu.org> --- > (In reply to Jakub Jelinek from comment #9) > > Perhaps some of those checks on the other side are redundant and could be > > turned e.g. into gcc_checking_assert of gcc_assert, I bet if the MEM_REF > > doesn't overwrite all bits, but only some subset of them, then the > > destination couldn't be a nonmem decl and thus couldn't be promoted. > Yeah, asserting sounds good. Checking the other conditions makes it > look like we could still fall through to the else for some promoted > subregs. > > If we can't assert, I guess the rule is that we need to extend > whenever we're storing to the MSB of the inner register. We can > do that either by extending the source value and the range to > the outer register, or by assigning to the inner register and > then extending it separately. So I guess if you do a GIMPLE FE testcase with a __BIT_INSERT to the MSB of a promoted var that should end up doing the extension as well? Like (probably doesn't parse, needs a 1-bit precision '1') signed char __GIMPLE () foo() { signed char _1; signed char _2; __BB(2): _2 = __BIT_INSERT (_1(D), 1, 7); return _2; } int main() { if (foo() > 0) abort (); } ?
