> Am 04.11.2024 um 16:01 schrieb Andrew MacLeod <amacl...@redhat.com>:
>
> The invert() range operation is not supported on values of either VARYING or
> UNDEFINED. Primarily this is because UNDEFINED has no type, which makes it
> impossible to perform invert() twice on a value, and produce that same value.
> There were also times when it wasn't precisely clear what the client expects
> when UNDEFINED or VARYING is inverted.. so it is handled at the caller point.
>
> When processing switches, whenever we find the ranges for a particular label,
> we invert that range, and intersect that inversion with the current
> "default:" ranges to determine the default case. In this testcase, one
> label has all possible values, so the label was producing VARYING. inverting
> that value was causing a trap.
>
> This patch simple checks for VARYING and sets the default ranges to UNDEFINED
> in this case.
Is that correct? The VARYING is not necessarily precise so „the rest“ should
be VARYING as well? That said, I don’t think you can use invert and intersect
to compute the default case range.
Richard
> Bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed.
>
> Backports to GCC12 - 14 forthcoming.
>
> Andrew
>
>
> <0001-Don-t-call-invert-on-VARYING.patch>
