[Bug tree-optimization/116098] [14/15 Regression] _Bool value from tagged union is incorrect when built with optimization since r14-1597-g64d90d06d2db43

[rguenther at suse dot de]

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-bugzilla@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.