- User Since
- Sep 29 2013, 1:48 AM (531 w, 22 h)
Jan 16 2020
This change is causing test regressions, e.g::
Jan 15 2020
I did some local work to make this build and pass almost all tests on Linux as well, not to make use of the multi-process features but just to avoid having a separate "for Windows only" branch, and to ensure tests pass across platforms. Unfortunately my change is not at all acceptable for inclusion because it's extremely Linux-specific, and Unix/Program.inc very explicitly says "only use generic UNIX code here". I use pidfds and a timerfd combined with epoll_wait to implement sys::WaitMany. It works well, but I'd be concerned about how to implement this as smoothly for any other *nix platform. pidfd/timerfd/epoll made it downright easy, but I started off trying to look at options that would work more universally on e.g. Linux *and* the BSDs, but I couldn't find anything that wouldn't require building a Rube-Goldberg machine juggling timers, alarms, signals, etc, etc.
Jan 14 2020
Sep 13 2019
OK, those two problems were actually easy enough to fix.
I rebased this myself on the release_90 branch and I was pleasantly surprised that I got the merge right on the first try (?!), and it actually works well without any significant changes (other than merge conflict resolutions).
Aug 6 2019
OK, that makes sense. So this change would not enforce -O2/-O3 for the bitcode emission, but would enforce one of the two for the LTO phase.
Apr 26 2019
Also this maybe an independent change, but:
Sep 21 2018
May 9 2016
May 1 2016
Also I just tested the current patch revision. There's an error in how it is checking whether the destination register is used as the input. The input of popcnt can be a memory location, and the destination register may be part of the address calculation: