-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sequential_or: Fixed random order execution of underlying parsers #310
sequential_or: Fixed random order execution of underlying parsers #310
Conversation
Very interesting insights! I honestly haven't thought about this until now! Do we have tests for this? |
After two hours of fighting with the optimizer, I happily drew attention to this little nifty bitwise operator in `any_if_ns` function. Explanation of the bug: bitwise inclusive OR operator is not a sequence point (per chapter §5.13 of C++14 standard), that's why at compiling the expression `a() | b() | ... | z()` optimizer is allowed to rearrange the execution order of the functions `a`, `b` ... `z`. There is high chance that a lot of people were misguided by the bug and chose not to use `sequential_or`. I vaguely remember how about three years ago I thought that I am dumb and/or the documentation is wrong when I tried to use the `sequential_or` but ended with some workaround. There are three possible fixes: - This one - Make the original `any_ns` and `any_if_ns` strict ordered (could potentially make permutations operator slower) - Break the `any_ns` and `any_if_ns` API and somehow generalize the code
eb44967
to
6a37fde
Compare
There cannot be a test for this particular problem. For me it happened on |
Or if someone know a test for Example: #include <cstdio>
int main()
{
return printf("Hello") | printf("World");
} The example produces "WorldHello" for me on MSVC on any optimization strategy except From my point of view if such a test exists - it requires some preprocessor pragma or compiler argument. Actually this is a good idea for an in-compiler-fuzzer, but again, the bug will appear on already existing tests and does not require a dedicated test. |
OK, well, I haven't studied your solution yet, but could you give me a quick explanation on how the solution works? |
It is very simple, the crucial part is b1c74d0. |
I cannot setup Appveyor on the repository until the problem is fixed. Should I remove |
I understand now. Sorry for the delay. Please go ahead. |
After two hours of fighting with the optimizer, I happily drew attention to
this little nifty bitwise operator in
any_if_ns
function.Explanation of the bug: bitwise inclusive OR operator is not a sequence point
(per chapter §5.13 of C++14 standard), that's why at compiling the expression
a() | b() | ... | z()
optimizer is allowed to rearrange the execution orderof the functions
a
,b
...z
.There is high chance that a lot of people were misguided by the bug and chose
not to use
sequential_or
.I vaguely remember how about three years ago I thought that I am dumb and/or
the documentation is wrong when I tried to use the
sequential_or
but endedwith some workaround.
There are three possible fixes:
any_ns
andany_if_ns
strict ordered(could potentially make permutations operator slower)
any_ns
andany_if_ns
API and somehow generalize the code