On Fri, Aug 26, 2022 at 6:08 PM Jeff Law via Gcc-patches wrote: > > > > On 8/23/2022 4:33 AM, Aldy Hernandez via Gcc-patches wrote: > > For the frange implementation with endpoints I'm about to contribute, > > we need to set REAL_VALUE_TYPEs with negative infinity. The support > > is already there in real.cc, but it is awkward to get at. One could > > call real_inf() and then negate the value, but I've added the ability > > to pass the sign argument like many of the existing real.* functions. > > > > I've declared the functions in such a way to avoid changes to the > > existing code base: > > > > // Unchanged function returning true for either +-INF. > > bool real_isinf (const REAL_VALUE_TYPE *r); > > // New overload to be able to specify the sign. > > bool real_isinf (const REAL_VALUE_TYPE *r, int sign); > > // Replacement function for setting INF, defaults to +INF. > > void real_inf (REAL_VALUE_TYPE *, int sign = 0); > > > > Tested on x86-64 Linux. > > > > OK? > > > > gcc/ChangeLog: > > > > * real.cc (real_isinf): New overload. > > (real_inf): Add sign argument. > > * real.h (real_isinf): New overload. > > (real_inf): Add sign argument. > > Funny in that I've fairly recently had the desire to do something a bit > similar. Let's consider 0.5, which we have a dconsthalf, but we don't > have dconstmhalf for -0.5. To get that value I create a dconsthalf > object and flip its sign. Similarly for a variety of other special > constants (particularly powers of two, but a few others as well). Ugh, yeah. I've been doing a lot of gymnastics in this space because frange's will have REAL_VALUE_TYPE endpoints. > > Consider making the "sign" argument a boolean. It's defined as a single > bit bitfield in the real_value structure. We don't want folks to pass > in values outside [0..1] for the sign if we can easily avoid it:-) I was trying to follow all the other functions in real.cc which have "int sign", though I suppose none of them are exported in the header file. OK pending tests? Aldy