On Wed, 2026-02-04 at 10:15 -0800, Andrew Pinski wrote: > On Wed, Feb 4, 2026 at 9:52 AM Andrew MacLeod <[email protected]> > wrote: > > > > > > On 2/4/26 11:35, David Malcolm wrote: > > > One of the difficulties I ran into when familiarizing myself with > > > value-range.{h,cc} is that the comments and classes refer to > > > representations of "ranges", but the implementation has grown > > > beyond > > > mere ranges of values (such as with bitmasks and NaN-tracking). > > > > > > Arguably "range" could refer to the mathematical definition: the > > > set > > > of possible outputs of a function, but I find it much clearer to > > > think > > > of these classes as efficient representations of subsets of > > > possible > > > values of a type. > > > > > > This patch updates various leading comments in a way that > > > clarifies > > > the intent of these classes (for me, at least). > > > > > > Andrew: did I get all the details correct, and is this OK for > > > trunk? > > > (assuming it bootstraps) > > > > The clarifications are fine with me... Only the release managers > > can > > approve it for trunk however. > > > > If they don't want it checked it in now, I can add it to my tree of > > things for stage 1. > > Comments changes/fixes are acceptable during stage 4 since comments > are considered documentation rather than code. I thought this was > mentioned before but I can't find it.
Thanks; I've gone ahead and pushed this now as r16-7343-gecb34673283fe1 (having done a successful bootstrap with the patch, fwiw). Dave
