on 2022/10/24 20:55, Richard Biener wrote: > On Mon, Oct 24, 2022 at 12:43 PM Kewen.Lin <li...@linux.ibm.com> wrote: >> >> Hi, >> >> As PR107338 shows, with the use of widening loads, the >> container_type can become a wider type, it causes us to >> get wrong shift_n since the BIT_FIELD_REF offset actually >> becomes bigger on BE. Taking the case in PR107338 as >> example, at the beginning the container type is short and >> BIT_FIELD_REF offset is 8 and size is 4, with unpacking to >> wider type int, the high 16 bits are zero, by viewing it >> as type int, its offset actually becomes to 24. So the >> shift_n should be 4 (32 - 24 - 4) instead of 20 (32 - 8 >> - 4). >> >> I noticed that if we move shift_n calculation early >> before the adjustments for widening loads (container type >> change), it's based on all the stuffs of the original >> container, the shfit_n calculated there is exactly what >> we want, it can be independent of widening. Besides, I >> add prec adjustment together with the current adjustments >> for widening loads, although prec's subsequent uses don't >> require this change for now, since the container type gets >> changed, we should keep the corresponding prec consistent. >> >> Bootstrapped and regtested on x86_64-redhat-linux, >> aarch64-linux-gnu, powerpc64-linux-gnu P7 and P8 and >> powerpc64le-linux-gnu P9 and P10. >> >> Is it ok for trunk? > > OK.
Thanks Richi, committed in r13-3474. BR, Kewen
