ie due to reoptimizing the function and then calling into the compiled code.
We could handle this specific case by not treating these as "real" frames
that need to be introspected, but we have these kinds of situations in other
places (reopt from compiled code, osr from either kind) so I'd rather
find a more general improvement.

Before it was recompiling the OSR-entry function every
time it would take an osr exit.

New AST interpreter

- Move internal definitions from header to source file
- Fix root_stack_set bug carried over from llvm_interpreter
- Cut off access to the old llvm interpreter
- Slightly tune the tiering thresholds
 - They seem too high but our LLVM compilation is overly expensive right now
 - Our AST interpreter is also somewhat slow due to its string handling

Once we get the AST interpreter in, we can add resume-from-any-point
functionality, which means that we can get rid of the current OSR system.
Maybe we should have done that first, but I thought it would be easy
to get the OSR stuff working.

This time for the llvm configuration.

Sometimes when updating the LLVM directory, we need to reconfigure things.
We don't know that until after we update it, though, but Make will decide
at the beginning whether it needs to be updated or not.  We could always
reconfigure every time we update LLVM (might be ok), or add a helper
target that recursively calls Make after the updating is done (what this
patch does).

This should fix those "C compiler can't generate executables" errors that
come from running two copies of the configure script in parallel.

Ie if you override sys.stdout, prints without an explicit destination
will go to the new location.

Also sneak in a couple other bugfixes.

List right multiplication, tuple multiplication

Implement FloorDivInt

In preparation for using bitmaps for other purposes in the heap.

Fix uninitiated read of >> 3 == 3 (REPL)

Not sure how hard a requirement it is to match CPython's behavior,
but just assert out for now rather than doing something different.

Also add an assert to copySlice, which could have similar issues.

Fix slicing issues

Fix assert in very verbose mode

Set pypa option for not handling future import errors

Astprint improvements

fix memory leak

In addition:
 * unify slicing
 * performance improvements, especially for string slicing

[use_latest_valgrind] Use valgrind-3.10.0

Signed-off-by: Vinzenz Feenstra <evilissimo@gmail.com>

Signed-off-by: Vinzenz Feenstra <evilissimo@gmail.com>

We were scanning the wrong number of bytes for conservative objects;
we were using the allocated size instead of the user size, but
starting the scan at the beginning of the user section.

Finally ran into a case where a conservative object was the very
last object in the heap and it segfaulted.

An experimental way of making the runtime faster.  Previously, the C++
runtime was much slower than pure-Python code, since the Python code
can use the JIT to improve performance (through inline caches and type
speculation).  This commit adds "runtime ics", which are out-of-band
patchpoints that we can allocate from C++.  We insert them into the
same patchpoint system that gets used by the main JIT pipeline, so
they get rewritten like any other patchpoint, but the lifetime and use
gets controlled by the C++ code.

The trickiest part is getting the newly-allocated instruction regions
to work with our exception handling; to make this work we have to emit
.eh_frame sections.  (A custom libunwind-based exception unwinder
might not have this requirement.)

Otherwise it feels like a decent approach.  Right now just using it to
implement class slots and then only using them in the pyElements
iterator; it's probably not the most direct or efficient way of
implementing that particular feature, but it has the benefit of being
general and being useful for things such as binops which are not
directly expressible in terms of class slots.

This commit adds the support without turning the feature on (next
commit will turn it on), since there are a number of other changes
needed.

Hopefully this doesn't break things for people trying non-default
toolchains, but it might.

We were previously using -static-libstdc++ to make sure that we would
find the right libstdc++.  I noticed that we weren't getting the right
version of libgcc_s (using the system one instead of the freshly-built
one), so use rpath for now.