https://gcc.gnu.org/g:e7a0f04ddb708320403c7477679fbeae3638820d
commit r14-11429-ge7a0f04ddb708320403c7477679fbeae3638820d
Author: Jakub Jelinek <ja...@redhat.com>
Date: Thu Mar 20 10:36:29 2025 +0100
libstdc++: Fix comment typo
Another IEE typo.
2025-03-20 Jakub Jelinek <ja...@redhat.com>
* testsuite/18_support/numeric_limits/traps.cc (main): Fix comment
typo.
(cherry picked from commit d458020e19b686e0d46320e7d26fa876c19965a0)
Diff:
---
libstdc++-v3/testsuite/18_support/numeric_limits/traps.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/testsuite/18_support/numeric_limits/traps.cc
b/libstdc++-v3/testsuite/18_support/numeric_limits/traps.cc
index a4b30fd01c3f..adb2dba9f8fc 100644
--- a/libstdc++-v3/testsuite/18_support/numeric_limits/traps.cc
+++ b/libstdc++-v3/testsuite/18_support/numeric_limits/traps.cc
@@ -48,7 +48,7 @@ int main()
For floating points, trapping is a different, more complicated
story. If is_iecxxx is true, then division by zero would not trap
(infinity). If is_iecxxx is false, we don't know (VAX may trap for
- 0/0 -- I have to check). For most cases (i.e. IEE-754), trapping
+ 0/0 -- I have to check). For most cases (i.e. IEEE-754), trapping
for floating points have to do with whether there is a support for
signaling NaN.
- Gaby.
