bug#43579: Problem still present

[Andreas Enge <andreas@enge.fr>]

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