- 13 May, 2016 2 commits
-
-
Kevin Modzelewski authored
I think this is the main source of our jit-time regression.
-
Kevin Modzelewski authored
This time, structure it a different way, This does a better job of highlighting the JIT-time regression from the refcounting branch.
-
- 12 May, 2016 2 commits
-
-
Kevin Modzelewski authored
Enable the gcc build
-
Kevin Modzelewski authored
The release CI builds are failing since they run the extra tests
-
- 11 May, 2016 8 commits
-
-
Kevin Modzelewski authored
Fix usage of undef variables
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
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.
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
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.
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
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.
-
Kevin Modzelewski authored
Otherwise they can end up seeing the return address of their caller
-
- 10 May, 2016 1 commit
-
-
Kevin Modzelewski authored
Fix the last two reffail tests
-
- 09 May, 2016 17 commits
-
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
At least what I added here is what CPython does.
-
Kevin Modzelewski authored
But still some in test/integration
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
Undo a bunch of Pyston changes to cpython code
-
Kevin Modzelewski authored
copy CPython sys.getsizeof implementation with some Pyston changes
-
Kevin Modzelewski authored
Bitset iteration micro optimize
-
Boxiang Sun authored
This just copy the CPython implementation, so some NumPy tests could pass. But most of types in Pyston didn't implement '__sizeof__' attribute yet.
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
Haven't been able to test them all extensively but I tried to only pick things refcount-related.
-
Kevin Modzelewski authored
Another run-arbitrary-code-during-unwinding issue
-
Kevin Modzelewski authored
The part that tests that certain dicts compare a given way. We don't have consistent dict comparisons yet (#1135)
-
Kevin Modzelewski authored
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()".
-
Dong-hee Na authored
-
Kevin Modzelewski authored
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.
-
Kevin Modzelewski authored
bitset begin() function fix
-
- 08 May, 2016 7 commits
-
-
Marius Wachtler authored
refcounting fixes for numpy in PyTuple_GetSlice, PyErr_SetExcInfo and PyErr_GetExcInfo
-
Marius Wachtler authored
-
Dong-hee Na authored
-
Kevin Modzelewski authored
Fix test_set.py
-
Kevin Modzelewski authored
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.
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
This time it was if __eq__ throws.
-
- 07 May, 2016 3 commits
-
-
Kevin Modzelewski authored
It was failing on master due to some of the test cases checking for immediate destruction.
-
Kevin Modzelewski authored
Marius fixed the propagate-C++-exception case, and this commit adds the to- and from-CAPI cases as well.
-
Kevin Modzelewski authored
We were missing a guard and we ended up calling the wrong function :/ Still some other issuse with this test
-