JARJAR challenge on SPOJ
At first glance:

The code is a bit difficult to read.  The macros and variable names do not improve readability (using the same names than the problem would help a lot).
If I understand correctly (and I'm honestly not sure) you compute all possible solutions, then use this huge table on the input.
This would be a good idea if the result set was small and the number of 'Q' benefiting from it (much) bigger. (I'd say the order of 10E+7 'Q', give or take an order of magnitude)

A bit deeper:

The sum of weights as a quick elimination is a good idea.

But your algorithm involves this brutal O(m * n²) loop.  This does not inspire confidence in the execution speed.
Also, your main buffer takes 850MB of memory (assuming an int is 32 bits).  That's a LOT of cache misses : another downer.

The way I imagine the algorithm, only 2 arrays of 60 integers are needed (plus bonuses). That's 240 bytes or ~4 to ~8 lines of L0 cache : fast.  As for the work for a given total weight, it should be broadly O(n*log(n))

Reading the problem, a few obvious algorithm optimization steps are presenting themselves.

First, there is no precision that say that pieces weights are different (and if the test is interesting, there should be a fair amount of pieces with identical weights in the input, if only to make room for subtlety).

The weight pieces should be sorted in reverse order and the number of different weights counted.
Note that by starting with the bigger values on each iteration, the test of overflow you will do after each addition will trigger earlier.

Now that you know how many times a weight is used, you only start from it once and multiply the amount of solutions for that starting weight by U. (Repeat for all different weights)

There is also no precision that the total weight cannot be repeated.
I'm assuming that's what your O³ was meant for.
But instead of computing what you don't need, just store the results by total weight in a map (that you will reset for each new set of pieces weights).

And at last, since it's C++11.  You could take advantage of the amount of CPUs and dispatch the test. This part is actually tricky because knowing if you have to divide by (N+Qs) (and have a printer dispatch, the main thread, that centralizes the printing to keep order) or to divide for each Q of an N requires a bit of experiment and tuning.

An example to be clear, with [] being a thread.

[N0 Q01 Q02 Q03 ...] [N1 Q10 ...] per thread, plus [printer dispatch].

or

[N0 Q00] [N0 Q01] [N0 Q02] [N0 Q03] [N1 Q10], plus [printer dispatch].

These are the first ideas but the result should be quite fast.