GNU bug report logs - #43579
g++ does not provide std::fegetround

Previous Next

Full log

Message #43 received at 43579 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Enge <andreas <at> enge.fr>
To: 43579 <at> debbugs.gnu.org
Cc: rekado <at> elephly.net, ludo <at> gnu.org, rosen644835 <at> gmail.com
Subject: Problem still present
Date: Mon, 13 Jun 2022 19:03:37 +0200

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 <at> 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 <at> 10.3 it actually
succeeds.

But with gcc-toolchain <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.