On Sat, Aug 24, 2024 at 6:19 PM Georg-Johann Lay <a...@gjlay.de> wrote: > > Trying to use the value-range interface and functions I am running > into that ICE when using invert(). > > From what the sources suggest, invert() computes the complement of > the current set (the union of finitely many intervals). > > For example, when I have a range of [-128, -1] for int8_t, invert() > runs into that ICE because that interval is undefined or varying. > > Take for example, this code that wants to take the complement of > the complete interval (with respect to the complete interval given > by uint8_t): > > tree t = unsigned_intQI_type_node; > int n_bits = TYPE_PRECISION (t); > > int_range<2, false /*resizable*/ > j(t); > > // j is undefined(?), thus set its bounds to the entire range. > j.set (t, wi::to_wide (j.lbound()), wi::to_wide (j.ubound())); > j.invert(); > <built-in>: internal compiler error: in invert, at value-range.cc:2165 > 0 > > This should just return the empty set; no? And vice versa, the > complement of the empty set (with respect to the whole interval) > should be the whole interval provided by t, no? > > If I understand correctly, the int_range<> implementation does not > implement a semi-group, and there are sets / intervals that are not > allowed, like the empty set or intervals that touch a boundary. > > Does this mean that I have to test and special-case all these cases > and do them by hand? Are there more invalid / disallowed intervals?
A lot of functions do not allow undefined_p () ranges, but it's odd that invert doesn't handle varying_p (). But yes, the range API (unfortunately) requires you to check for certain exceptional cases beforehand even though they are not really exceptional for range arithmetic in general. > So I guess it is simpler when I write my own interval arithmetic > that handles these cases and behaves like a semi group. As there > will be at most 3 sub-intervals, that's the way to go...? > > Isn't there a knob to tell that complement is with respect to the > range as provided by type(), and not w.r.t. the integers? Andrew would have to answer that but I think that's how ranges behave. They just have those API requirements that are sometimes annoying. Richard. > > Johann
