http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913
--- Comment #9 from Marc Glisse <marc.glisse at normalesup dot org> 2011-03-02 11:50:41 UTC --- (In reply to comment #8) > Right. Mine was sort of a general comment: the comments in ratio_less are also > rather terse ;) I'll try to expand a bit on them. > I don't think you should really handcode something, just pick the right > __builtin_* depending on the actual type of uintmax_t (after all it's just a > typedef for one of the builtin types). Thus, if we aim for something really > general here, use just a bit of templates to pick the best match among the > various available __builtin_*, via make_signed on uintmax_t and then three > special cases for int, long, long long. Granted, probably on widespread 32-bit > and 64-bit machines, long long it's indeed a safe bet. If intmax_t is guaranteed to be one of int/long/long long, then it seems that it has to be equivalent to long long. I was more afraid that it might be a bigger type than long long. (by the way, __builtin_clz takes an unsigned argument) > Understood. Since 4.6.0 is approaching, do you think it would make sense for > this release series to modify only a bit the GCC code, to the point that we > are > as good or even slightly better, if possible, than Boost, without requiring > too > much new code? I fear regressions, as you of course can easily understand. > Ideally, we should add, mano a mano, testcases for each "subclass" of inputs > which we are able to process without overflowing. I think there is nothing wrong with the implementation of ratio_add currently in libstdc++ (shipping it as it is seems fine), but we could indeed easily avoid all unnecessary denominator overflows (attachment in a minute). The factorization of the gcd of numerators is a heuristic that sometimes helps but doesn't really close a category of overflow, so I am more reluctant to add it, but it is really easy if you think it should be done.
