KQuery SPOJ problem, using merge sort segment tree
Your biggest issue here is that you are building a new list for every single query. Each of these lists can have size up to \$N\$ (since the query could be over the entire universe), so building this list takes time \$O(N)\$ in the worst case (this is true even though it is built from logarithmically many smaller lists). This makes the total runtime of your algorithm \$O(N\log^2 N + QN)\$, and \$O(QN)\$ is way too large to run in time for the parameters of this problem. 

Of course, the solution to this issue is that you don't really need to build the list for each query; you just need to count how many elements are larger than k. Since the list for each query is just the union of logarithmically many sorted lists in your segment tree, just count this quantity for each of those lists and sum this up. This reduces your time complexity to \$O(N\log^2 N + Q\log^2 N)\$ (there are \$O(\log N)\$ lists, and it takes \$O(\log N)\$ time to binary search each one), which should run in time.

If your code still times out after making this change, I would recommend rewriting the code for build and query iteratively instead of recursively; this can sometimes speed things up a bit (however we're no longer in the realm of asymptotic improvements).

Some other code things:


I might be wrong, but I think it's generally accepted that the register keyword in C++ doesn't really do much anymore; compilers are way better than people at figuring out which variables should be stored in registers, so you're not going to get any speedup by explicitly declaring this. 
Your query method accepts k as a parameter, but you don't actually use k anywhere (short of passing it along in recursive calls). That said, given the above answer, you probably should be using k in the query method. 
I guess it's not super necessary for short and quick solutions to contest problems like this, but I think your code would benefit a lot from a bit more whitespace and consistent indentation (I think it would make it a lot easier to spot bugs as well). One of the things that bugs me the most about your code is how you write for(i=0;i&lt;n;i++) and scanf("%d", &amp;arr[n]) on two consecutive lines at the same indentation; it makes it very unclear that the second line is part of the for loop.