jzmaddock

Confirmed that this is a problem, and that a very large number of headers are effected. Note that the issue does not occur if you compile with `-std=c++XX -pedantic` only...

Looks good to me too - do we have a test case for the original Eigen issue? We do have some Eigen interoperability tests in Multiprecision which could be copied...

I'm hoping this will fix the outstanding develop test failure: https://github.com/boostorg/math/commit/526fc6eef47cbdedc09d0895c9ce97ed383dc45a

I confess I'm liking this less and less: the code appears to be correct, something somewhere is generating incorrect code if spurious overflow is happening on a code branch that...

> and the block following it, I am thinking: Are you missining fmax = fmid; there? No... I think if anything the `fmin = fmid` in the following block is...

I don't *think* anyone is using our versions of the functions listed in the paper, but we should probably experiment with this anyway: both for our versions of things listed...

I believe this is to be expected, I modified your program to print out epsilon differences as follows: ``` #include #include #include #include int main(int, char* []) { omp_set_num_threads(4); std::cout

>the thing is I dont get any difference between the serial and omp code here on linux (gcc 12.2) what would explain this diffs on cygwin or freebsd you guys...

I'm happy to reopen, but someone is going to have to give us clue here as the thread sanitizer messages are all from OpenMP's own runtime. If I get time...

OK, here's a revised test case that basically just splits the gamma_q calculation into it's two parts, and concentrates the test values around the #821 test value identified above. Interestingly...