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

[pinskia at gcc dot 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.