• Please do away with the using namespace std; it forces that style on users who don't want it.
• The fixed tests should also be in the submission tests too.
• Minor stylistic nitpick, but scoping every assert statement in the fixed tests is unneeded and might be a source of confusion.
• The input sizes are determined at compile-time. This is not random
• The usage of std::linear_congruential_engine here is overengineered; with this config, it generates a linear sequence with a step of 3 starting from 1 (exclusively). Every single test run would generate the sequence (4, 4+3, 4+3+3, ...) without fail. This is also not random
• All the values in the generated b are from a. This doesn't test how the user's solution handles values in b that are not in a. Also, this means that b preserves the order of a which reduces the randomness further.
• This point is more general, but I really feel like the structure of the random tests can be massively simplified. Between the usage of std::linear_congruential_engine, the need for explicit moves, the magic numbers (like LN/4) and the reaally long function, I really feel like some parts can be refactored, some removed, and some restructured to make the random testing strategy more readable.

never thought I would see asm here

what in the absolute code is this

Please use spoiler flag next time. Because you did integer division there. That's how Ruby's division work.

devagya, please use spoiler flag next time.

It can be, but plenty of compilers will optimize a divide-by-two into a shift anyway. (Specifically any divide-by-power-of-two can be turned into a single shift)

Yes, bit operating is faster

As guriyeller correctly observes, for all numbers greater than 1, multiplying will give the maximum result. So I special-cased where numbers are equal to 1, because then it's better to add them to another multiplier. For a and c that can only be to b, for b it depends on whether a<c or not; (a+1)c==ac+c and a(c+1)==ac+a. I made use of invariants throughout the various steps to arrive at a compact final expression, carefully avoiding overwriting values. All paths that add to variables make sure the correct variables are still 1 to not affect the result.

i love your solution, you must be an Obfuscated C code contestant ;-)

Fixed

i was very surprised how few C solutions actually used #include <regex.h>
given that it is tagged as a regex kata.

There's compilation warnings in the test code (fixture.c).

you inspired my insanity ;)