[See edit history for quite a different answer that's now basically obsolete.]
Yes, there are a couple of JIT compilers for C and/or C++.
CLing (as you might guess from the game) is based on Clang/LLVM. It acts like an interpreter. That is, you give it some source code, give a command for it to run, and it runs. The emphasis here is primarily on convenience and fast compiling, not maximum optimization. As such, although technically an answer to the question itself, this doesn't really suit the OP's intent very well.
Another possibility is NativeJIT. This fits the question somewhat differently. In particular, it does not accept C or C++ source code, and compile it and execute it. Rather, it is a small compiler that you can compile into your C++ program. It accepts an expression which is basically expressed as an EDSL inside your C++ program, and generates actual machine code from that, which you can then execute. This fits much better with a framework where you can compile most of your program with a normal compiler, but have a few expressions that you won't know until run-time, which you want to execute with something that approaches optimum execution speed.
As for the apparent intent of original question, I think the basic point of my original answer still stands: while a JIT compiler can adapt to such things as data that varies from one execution to the next, or even varying dynamically during a single execution, the reality is that this makes relatively little difference at least as a general rule. In most cases, running a compiler at run time means you need to forego quite a bit of optimization, so about the best you usually even hope for is that it's close to as fast as a conventional compiler would produce.
Although it's possible to postulate situations where information available to a JIT compiler could allow it to generate substantially better code than a conventional compiler, instances of this happening in practice seem to be pretty unusual (and in most cases where I've been able to verify its happening, it was really due to a problem in the source code, not with the static compilation model).