I am still using your timsort implementation in a project, but recently noticed that Valgrind sometimes complained when trying to sort an std::deque with timsort. Here is my reduced test case:

std::deque<double> collection(35);
std::iota(std::begin(collection), std::end(collection), -47.0);
std::mt19937 engine(std::time(nullptr));
std::shuffle(std::begin(collection), std::end(collection), engine);

gfx::timsort(std::begin(collection), std::end(collection));
assert(std::is_sorted(std::begin(collection), std::end(collection)));

The actual test case is slightly more complicated than that since I am using Catch, but nothing really different. Unfortunately, Valgrind's error is way too big for me to include it here, but you can find the full error log here. Now, note that it is a log obtained with the test compiled by g++ in release mode, so it lacks some information about where exactly the error happens.

I will try to find a sequence of numbers that makes Valgrind report errors for sure, and edit this issue when I have one. Currently I don't really have many ideas about what can cause the error. I got similar errors when trying to sort an std::deque with another sorting algorithm: apparently, std::deque is less cool than std::vector when it comes to accessing out-of-bound iterators (not even dereferencing them), so that might be the culprit.

Update: some things in the original testcase such as the shuffling or the fact that I used double were a bit dumb/unneeded. I managed to find a sequence of integers that always triggers the Valgrind errors and cleaned the minimal testcase a bit:

std::deque<int> collection = {
    15, 7, 16, 20, 25, 28, 13, 27, 34, 24, 19, 1,
    6, 30, 32, 29, 10, 9, 3, 31, 21, 26, 8, 2, 22,
    14, 4, 12, 5, 0, 23, 33, 11, 17, 18
};

gfx::timsort(std::begin(collection), std::end(collection));
assert(std::is_sorted(std::begin(collection), std::end(collection)));

Now that we have an initial sequence that always triggers the Valgrind error, here are the corresponding error logs for the program compiler in debug mode with clang++ and g++. Most of them seem to come from mergeHi but I also remember having seen errors coming from mergeAt and gallopRight in older logs.