After removing the patch that works around this problem in fplll with commit 5dec5f65ec3c7371dde309a101b85b930e423a46, I noticed that it actually still does occur.
We used to have the problem with gcc-toolchain@10.2 that with test.cpp equal to #include <cfenv> int main() { std::fesetround (FE_TONEAREST); return 1; } the compilation "g++ test.cpp" fails. With gcc-toolchain@10.3 it actually succeeds. But with gcc-toolchain@11.3 or @12.1 it fails again. Indeed, /gnu/store/bxh206gz379wkn8cvb2ghlkvpqgwfd2v-gcc-toolchain-10.3.0/include/c++/x86_64-unknown-linux-gnu/bits/c++config.h contains in line 1572: #define _GLIBCXX_USE_C99_FENV_TR1 1 whereas /gnu/store/c17nwiafb01pig2r3mjm1jznfpas61np-gcc-toolchain-12.1.0/include/c++/x86_64-unknown-linux-gnu/bits/c++config.h contains in line 1759: /* #undef _GLIBCXX_USE_C99_FENV_TR1 */ Did we change anything between 10.2 and 10.3, and then revert it with 11.3? Or is it a transient thing that depends on some random ordering of include files? The latter looks more plausible, since the change from 10.2 and 10.3 really just changes the version and the hash. What can we do? Andreas