Apparently they are slowing down the irgen phase in debug mode quite a bit,
since a lot of the time is dominated by InternedString hashtables.

I think this is the main source of our jit-time regression.

This time, structure it a different way,  This does a better job of
highlighting the JIT-time regression from the refcounting branch.

Enable the gcc build

The release CI builds are failing since they run the extra tests

Fix usage of undef variables

I think I had gotten confused and mixed up "undefined variables" (Python
variables which hadn't gotten set) and "undefined values" (results of
expressions that the JIT knows will throw, or otherwise can't evaluate).

For undefined *variables*, we represent them using None, since they can
still have refcount operations done on them.

For undefined *values* (or results), we can use llvm's undefValues, since
they should never be touched.

I ended up running "make update_section_ordering" multiple times since it seemed to help.
Or maybe things are just very random and then I picked one that happened to benchmark well.

This should fix the bad behavior we had where setGlobal would only get rewritten
by having its call to setattr() get inlined, and having setattr() then think it
was being called directly.  This was both brittle (only worked on release builds)
and incorrect (there were checks that happened before calling into setattr, which
needed to be emitted as guards).

I had hacked in an attribute((always_inline)) to at least deal with the brittleness,
but this should be a fix for real.  And let us reenable the gcc builds.

Otherwise they can end up seeing the return address of their caller

Fix the last two reffail tests

At least what I added here is what CPython does.

But still some in test/integration

Undo a bunch of Pyston changes to cpython code

copy CPython sys.getsizeof implementation with some Pyston changes

Bitset iteration micro optimize

This just copy the CPython implementation, so some NumPy tests could pass.
But most of types in Pyston didn't implement '__sizeof__' attribute yet.

Haven't been able to test them all extensively but I tried
to only pick things refcount-related.

Another run-arbitrary-code-during-unwinding issue

The part that tests that certain dicts compare a given way.  We don't
have consistent dict comparisons yet (#1135)

Since the unwinder now supports throwing exceptions inside destructors (as long
as they don't propagate out).

This is the same change that C++17 makes, from "bool uncaught_exception()" to
"int uncaught_exceptions()".

This time it was from trying to look at the result of isUnwinding()
to determine if the function terminated successfully or via an exception.
(And in the exception case, to decref some values that would have been returned.)

This got tripped up in a case where we through an exception, this triggers
an AUTO_DECREF which takes an object to zero decrefs, which has a custom destructor,
and calls code that ends up calling isUnwinding().  This is all happening from inside
a C++ destructor, so this counts as isUnwinding().

We had some code to try to keep isUnwinding() meaning what we wanted to use it for,
but it was only for certain cases.  I think we might be able to extend it to more cases,
but it seems like that would be a losing battle since it's hard to say when "unwinding"
ends and then we are suddenly not unwinding.

So instead, I just disabled isUnwinding() (except in debug mode where it can be somewhat
useful for writing "assert(foo || isUnwinding())"), and then used a different way to
try to determine if the function exited normally.

bitset begin() function fix

refcounting fixes for numpy in PyTuple_GetSlice, PyErr_SetExcInfo and PyErr_GetExcInfo

Fix test_set.py

It fetches a webpage from a third-party server ("example.com")
and verifies the return code.  For some reason it's failing,
both for us and for CPython.

This time it was if __eq__ throws.

It was failing on master due to some of the test cases checking for immediate destruction.