问题标签 [fenv]

任何人都知道用于 MS 编译器的体面的 C99 fenv.h 实现吗？

我想这不难做到；我只是想节省一些时间。

The documentation (in the standards) for all of fenv.h is rather confusing, but I'm especially confused about feholdexcept and the concept of "non-stop mode" for a floating point exception. As far as I can tell, on any IEEE floating point implementation, exceptions are non-signaling/"non-stop" by default, and the fenv.h interfaces seem to provide no way to enable a signaling mode unless it was the default. Is the whole concept of feholdexcept useless except on non-IEEE systems or systems with nonstandard extensions for setting the signaling exception mask?

考虑以下代码：

我希望它打印一个对应于 的非零值FE_DIVBYZERO，但它打印 0。更改 to 的第二行main会double x = 1.0/0.0;给出预期的行为。这是允许的，还是一个错误？

编辑：对于它的价值，起初似乎在大多数现实世界的代码中，可能导致 fenv 异常的操作无法被优化出来，因此人们可以安全地执行大型计算并在最后检查是否有发生溢出、除零等。然而，当你考虑内联和优化时，事情变得一团糟，一个真正的问题出现了。如果这样的函数在由于常量参数而总是被零除的情况下被内联，gcc 可能会变得非常聪明，并从本质上优化整个内联函数而return INFINITY;不会引发任何异常。

我在网上看了一些，发现了这个： http ://www.cygwin.com/ml/cygwin-cvs/2013-q1/msg00093.html

更多信息：

$ cygcheck -cd | grep gcc gcc-core 4.8.1-3 gcc-fortran 4.8.1-3 gcc-g++ 4.8.1-3 gcc-objc 4.8.1-3 gcc-objc++ 4.8.1-3 gcc-tools-epoch1-autoconf 2.59-2 gcc-tools-epoch1-automake 1.9.6-2 gcc-tools-epoch2-autoconf 2.64-2 gcc-tools-epoch2-automake 1.11.6-1 libgcc1 4.8.1-3 mingw-gcc-debuginfo 4.7.3-1 mingw64-i686-gcc-debuginfo 4.8.1-2

$ uname -a CYGWIN_NT-6.2 Raven 1.7.25(0.270/5/3) 2013-08-31 20:37 x86_64 Cygwin

让我们采取以下程序：

我希望它输出“0 1 1 1”：即，一旦我启用FE_INVALID异常，对 的调用fegetenv或fesetenv使用相同的环境不应修改它。

这在 i386-linux 上按预期工作，但在 x86_64-linux（在 64 位模式下）上，我得到“0 1 0 1”。也就是说，调用fegetenv清除异常掩码。

我看不到任何记录它的地方，甚至没有看到 C99 下允许的行为。我可以在glibc-2.5和glib-2.13下确认。

有人可以在最近的 glibc 上对其进行测试吗？我认为这是一个错误是正确的吗？

我想计算两个 IEEE 754 binary64 数字的总和，四舍五入。为此，我编写了下面的 C99 程序：

但是，如果我使用各种编译器编译和运行我的程序：

它不起作用！（我期待结果0x1.0000000000001p0）。

实际上，计算是在编译时以默认的舍入到最近模式完成的：

是的，我确实看到了每个编译器发出的警告。我知道在生产线的规模上打开或关闭适用的优化可能很棘手。如果可能的话，我仍然希望以文件的比例关闭它们，这足以解决我的问题。

我的问题是：我应该在 GCC 或 Clang 中使用什么命令行选项来编译包含旨在以 FPU 舍入模式而不是默认模式执行的代码的 C99 编译单元？

题外话

在研究这个问题时，我发现了这个GCC C99 合规性页面，其中包含以下条目，我将离开这里以防其他人觉得它很有趣。呸呸呸。

我想使用 fpeenableexcept 或 _MM_SET_EXCEPTION_MASK（在 Mac OS X 上）在某些关键代码上启用浮点异常。

在 x86/x86-64 上是否有任何情况下更改启用的异常会在不发生错误时损害程序性能？

我只在更改异常后询问数字代码以及不引发任何异常的代码。

阅读关于不支持 FENV_ACCESS pragma的 clang 错误报告我遇到了一条评论：

在不使用的情况下设置舍入模式会#pragma STDC FENV_ACCESS ON调用未定义的行为。见 C11 7.6.1/2。（C++ 中不存在此编译指示，因此 <cfenv> 无法使用，但这不是我们的错...）

C++ 中真的不存在这个编译指示，导致<cfenv>无法使用吗？我试图在 C++11 标准中搜索它，但实际上根本没有提到它。编译指示是否与函数原型一起从 C 继承？或者他们实际上不需要避免 UB，因为 C++ 标准没有说明当不使用编译指示时行为未定义（由于根本没有提到编译指示）？

我想按照本主题和cppreference中的建议使用标准库更改浮点舍入模式。我使用 MingGW 作为环境。CMake 用于构建项目。我的代码：

主.cpp：

CMakeLists.txt：

但是，在编译过程中会出现以下错误：

那就是<fenv.h>我的代码中没有#if _GLIBCXX_USE_C99_FENV_TR1的内容（\MinGW\lib\gcc\mingw32\4.8.1\include\c++\fenv.h不满足条件）。我究竟做错了什么？

我想知道 glibc 库中的哪些代码和文件在启用陷阱时负责为浮点异常生成陷阱。

目前，RISC-V 的 GCC 不捕获浮点异常。我有兴趣添加此功能。因此，我正在研究如何在 GCC for x86 中实现此功能。

我知道我们可以按照 [question] ( Trapping floating-point overflow in C ) 中的描述捕获信号，但我想了解有关它如何工作的更多详细信息。

我浏览了 glibc/math 中的文件，据我所知，这些文件以某种形式负责生成陷阱，例如

以及许多其他以 . 开头的文件fe。

所有这些文件也存在于 RISC-V 的 glibc 中。我无法弄清楚 x86 的 glibc 如何生成陷阱。