Thomas Gazagnaire

Hello, I am not sure it is related, but we also just noticed some wrong behaviour of the `inverse` function when upgrading from clang 14.0.0 to 14.0.3 on macOS. I...

@andres-erbsen I've added an [ok](https://gist.github.com/samoht/7c27b6418148ee04590e571f390f1997/raw/78fcd4cec629643bc730e0d76674a52ec9310f5e/repro-ok.exe) (generated with clang 14.0.0) and a [ko](https://gist.github.com/samoht/7c27b6418148ee04590e571f390f1997/raw/78fcd4cec629643bc730e0d76674a52ec9310f5e/repro-ko.exe) (compiled with clang 14.0.3) binary to the gist: https://gist.github.com/samoht/7c27b6418148ee04590e571f390f1997 -- let me know if you want to track...

removing noise ``` #include #include int main() { uint64_t x=UINT64_C(0xffffffffffffffff); printf("x=%llu\n", x); } ``` is generating a different result on GCC/clang 14.0.0 vs. clang 14.0.3 ``` CLANG-14.0.3 x=18446744073709551615 GCC /...

Ok, I'm now very confused - it used to by `x=-1` for clan 14.0.3, but now I cannot reproduce when scripting this (I copied/pasted the output of my scripts without...

ok more news - `-O0` fixes the issue on clang 14.0.3.

Bisecting the compilation passes with `opt-bisect-limit` points to this pass: ``` BISECT: running pass (303) InstCombinePass on fiat_p256_divstep ``` Also I've added a p256_64 test using the C-language test template,...

I managed to reproduce using C only, by tracing what values the OCaml code was sending to the C side. ```c #define LIMBS 4 #define WORD uint64_t #define WORDSIZE 64...

I've pushed a smaller repro with less clutter. It is still too big?

Apologies for the painful process. I still haven't managed to find enough time to inline all of this properly and I do realise it doesn't help you very much. But...

I have updated to clang version 16.0.4 (the one shipped with homebrew and not Xcode) and the bug disappeared - not totally sure what to do now. I have pushed...