https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116098
--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> --- > Am 27.07.2024 um 02:38 schrieb pinskia at gcc dot gnu.org > <gcc-bugzi...@gcc.gnu.org>: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116098 > > --- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #7) >> Ah, it's the code that makes SRA widen bit-precision values to >> size-precision integers. That said, I don't see why the V_C_E should not be >> moveable. >> >> value$8_11 = MEM <unsigned char> [(struct Value *)&s_value + 8B]; >> _8 = VIEW_CONVERT_EXPR<_Bool>(value$8_11); >> >> is exactly what RTL expansion will create - we're not truncating the >> result to bit-precision on _Bool loads. > > The problem is the bits outside of bool are set and we don't truncate them out > and since we turn it into: > > _6 = VIEW_CONVERT_EXPR<_Bool>(value$8_8); > _12 = value_7 != 0; > _13 = _6 | _12; > > We get the wrong answer. This is very similar to if _6 had been an > uninitialized which we fixed during the development of GCC 14. > That is the range of _6 (or _8) is only conditionally `[0,1]`, otherwise it > should be considered similar to an uninitialized variable. > > The other thing which we might be able to solve this is change: > ``` > /* For integral conversions with the same precision or pointer > conversions use a NOP_EXPR instead. */ > (simplify > (view_convert @0) > (if ((INTEGRAL_TYPE_P (type) || POINTER_TYPE_P (type)) > && (INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE (@0))) > && TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (@0))) > (convert @0))) > ``` > > to change bool convert to be convert too. In a similar way how we handle > `zero_one != 0` into a convert instead of a VCE (in VPR and other passes). > This > will fix the above too. > > Maybe I will test that to see what code generation will look like. That’s a possibility though it will affect all uses and cause a lot of extra truncation I fear. Richard > -- > You are receiving this mail because: > You are on the CC list for the bug.
