https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116098
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[14 Regression] _Bool value |[14/15 Regression] _Bool
|from tagged union is |value from tagged union is
|incorrect when built with |incorrect when built with
|optimization since |optimization since
|r14-1597-g64d90d06d2db43 |r14-1597-g64d90d06d2db43
--- Comment #16 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Laria Chabowski from comment #15)
> (In reply to Andrew Pinski from comment #14)
> > Fixed so far on the trunk.
>
> Thank you! That fixed the test cases I provided.
>
> However, when I tested it against the code where I stumbled upon this, I
> still
> got an unexpected result.
>
> Essentially the same idea: A function truthy() that switches over the type
> enum,
> returns the bool value if it's bool or always false if the type is nil or
> true
> in all other cases. Then, inverting it and saving and reading it as a value
> struct again, some garbage comes out and when using the resulting bool in a
> ternary, the opposite of the expected happens.
Yes it is the same bug just I had worked around the previous one really :).
Here we have:
```
if (value_10 == 0)
goto <bb 5>; [33.33%]
else
goto <bb 3>; [66.67%]
<bb 3> [local count: 715827875]:
if (value_10 == 1)
goto <bb 4>; [50.00%]
else
goto <bb 5>; [50.00%]
<bb 4> [local count: 357913942]:
<L1>:
_4 = VIEW_CONVERT_EXPR<_Bool>(value$8_11);
<bb 5> [local count: 1073741824]:
# _1 = PHI <0(2), _4(4), 1(3)>
```
And we are optimizing bb3/bb4/bb5 and in this case we can't move out the VCE of
the condition since it is from 3 bb rather than just 2.
Back to drawing board.
