https://gcc.gnu.org/g:2a88778a1d6740854d20de4a31853e71bb9127ba

commit 2a88778a1d6740854d20de4a31853e71bb9127ba
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.

Reply via email to