This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [000/nnn] poly_int: representation of runtime offsets and sizes
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Richard Sandiford <richard dot sandiford at linaro dot org>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 24 Oct 2017 12:48:41 +0200
- Subject: Re: [000/nnn] poly_int: representation of runtime offsets and sizes
- Authentication-results: sourceware.org; auth=none
- References: <871sltvm7r.fsf@linaro.org> <4728974.295PUQgt1k@polaris> <87o9owq35v.fsf@linaro.org>
> Yeah. E.g. for ==, the two options would be:
>
> a) must_eq (a, b) -> a == b
> must_ne (a, b) -> a != b
>
> which has the weird property that (a == b) != (!(a != b))
>
> b) must_eq (a, b) -> a == b
> may_ne (a, b) -> a != b
>
> which has the weird property that a can be equal to b when a != b
Yes, a) was the one I had in mind, i.e. the traditional operators are the must
variants and you use an outer ! in order to express the may. Of course this
would require a bit of discipline but, on the other hand, if most of the cases
fall in the must category, that could be less ugly.
> Sorry about that. It's the best I could come up with without losing
> the may/must distinction.
Which variant is known_zero though? Must or may?
--
Eric Botcazou