https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744
--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Lewis Fox from comment #12) > (In reply to Jonathan Wakely from comment #2) > > My original comment about libc++ was in reference to the LLVM bugzilla > report #27839: https://bugs.llvm.org/show_bug.cgi?id=27839 Thanks, that got copied to github as https://github.com/llvm/llvm-project/issues/28213 > It looks like the issue you discovered is LLVM bugzilla report #34206: > https://bugs.llvm.org/show_bug.cgi?id=34206 And that is now https://github.com/llvm/llvm-project/issues/33554 > It seems like since I made that comment here, libc++ has updated to fix the > misuse of Schrage's algorithm (though, looking at the current source code, > it still looks wrong to me), so it does mean my initial comment is a little > out of date. Unsurprising when it took me more than 5 years to look into it properly ;-) > This is a bit of an edge case that I don't think most users will encounter, > so performance is probably less important here than accuracy. 100% agreed > I'd personally > prioritize minimizing branches (i.e. improving simplicity) than optimizing > the operand sizes for performance, but that's just my opinion. Agreed again, for although as I said in comment 13 I think the extra branch in operator% might be worthwhile. Maybe with __builtin_expect(__l._M_hi == 0, 0)) as a branch prediction hint.
