With the above changes to the test case (and the corresponding changes to the reference output), the problem would have been blatantly obvious from the start and we wouldn't have to jump through hoops to ensure opt isn't just giving us the right answer.
Will land it in a 24-hours if there is no objections from others.
I have no idea how to CC those mailing lists (Change Subscribers doesn't seem to allow those) in this tool (or shall I just mail them normally)?
As for tests, the ones I have for GCC are:
Fixed most of notes spotted by @kcc.
Please use the arc tool to submit the patch or otherwise paste the patch with full context.
Please always CC llvm-commits for changes in compiler-rt (phabricator doesn't do it automatically)
How is this even reviewed?
There are some test crashes with this and I think I made the wrong guess for dmask behavior
And FWIW, I still don't like the names of these helper functions. There isn't really much indication in the name what it is sign/zero extending from/to. Presume I want to do add/remove an instruction depending on whether the input is known to be sign-extended from a halfword to a doubleword, but not if it is only known to be sign-extended from a word to a doubleword, it isn't clear how I would use these functions to determine that.
- a test case added
@davide, This is why I didn't silently commit such a trivial change. I am happy if it could be reproduced easily.
I really don't like this solution, in particular as a global one. Can we try to reproduce the tests that are failing?
Trying to fix issue with coverage stats being duplicated if fork() is used
@frutiger you have commit rights now right?
Please land it asap.
Confirm, the patch fixes my issue.