User Details
- User Since
- Nov 20 2017, 12:14 PM (271 w, 6 d)
Sep 3 2019
Feb 26 2018
Feb 23 2018
Seems good to me! I'll give it a test on my end.
Jan 31 2018
Jan 25 2018
Jan 24 2018
Thanks for reviewing this for me!
Jan 23 2018
Confirmed, this fixes my issue! Thanks!
Hey guys, is there anything holding this back? If not, I'd love it if one of you could submit it for me.
Jan 17 2018
Rebased on top of the timer change
Yay, thanks! This is one of the last bugs that's blocking me. At some point I'll have to figure out how to get these changes merged to 6.0...
Got as close as I could to @rnk's suggested error format, while still using toString(theError).
Changes requested by @rnk. Warning is now handled by addObjFile().
Works for me! Update incoming.
Ok, that makes sense.
Jan 16 2018
Bump, could someone submit this for me?
Jan 12 2018
Thanks for the quick reviews!
Turns out you can do the easier thing
Switch error message to use decimal format from hex.
Thank you Zach!
Jan 11 2018
Ping, could someone please submit this for me?
Jan 10 2018
If you wouldn't mind committing this for me, I'd really appreciate it.
nth time's the charm!
Jan 9 2018
Updated with my newer, better understanding of the file layout
Jan 8 2018
Now that I actually understand how the intervals work, I reworked a lot of what I had written. I think it's much clearer now, but I'm sure there's more nits to be had :)
But according to the code, that can't be true. Specifically, I'm looking at llvm::msf::getFpmStreamLayout. If you look at the loop assuming that FpmBlock is 1, then it pushes index 1 as the first FPM block, adds the result of msf::getFpmIntervalLength (which always returns 4096), and pushes that. This means that the second FPM in the sequence is at index 4097, which would mean that there are 4097 blocks in front of it. Unless block at index 4096 is unused, the first interval is in fact 1 block longer.
Jan 5 2018
Oh hey also, should this go in 6.0?
Jan 4 2018
I'm assuming you'll want approval from someone else too, but this looks good to me, and is proven to fix my bug.
Makes sense! Thanks for adding a test btw.
Abandoned in favor of D41742.
Yeah, that's the callstack I'm seeing. And I'm all for as many asserts as we can add to guarantee safety.
Just kidding it already does that?
OOOOH That makes so much sense. I was wondering how you could have 2 FPMs at the start but only one every stride after that, but never connected that to this...
In the process of writing this comment, I rewrote it like 8 times whenever I discovered something. So sorry if this reads disjointly :)
This actually took me 3-4 days to track down, but I'll try to explain as clearly as I can :)
Dec 13 2017
Thanks Reid! Would you mind submitting this for me?
Dec 12 2017
llvm::IntegerType::get(getLLVMContext(), 128) -> Builder.getInt128Ty()
Moved implementation to X86_64 specific code, as according to Microsoft docs this function isn't supported on X86 or ARM.