Skip to content

[flang][runtime] Resume rounding hexadecimal floating-point input #77006

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 15, 2024

Conversation

klausler
Copy link
Contributor

@klausler klausler commented Jan 4, 2024

This reverts commit cab156c, and adds language to Extensions.md documenting the discrepancy with the letter of the language standard.

This reverts commit cab156c, and
adds language to Extensions.md documenting the discrepancy with
the letter of the language standard.
@klausler klausler requested a review from psteinfeld January 4, 2024 21:25
@llvmbot llvmbot added flang:runtime flang Flang issues not falling into any other category labels Jan 4, 2024
@llvmbot
Copy link
Member

llvmbot commented Jan 4, 2024

@llvm/pr-subscribers-flang-runtime

Author: Peter Klausler (klausler)

Changes

This reverts commit cab156c, and adds language to Extensions.md documenting the discrepancy with the letter of the language standard.


Full diff: https://github.com/llvm/llvm-project/pull/77006.diff

2 Files Affected:

  • (modified) flang/docs/Extensions.md (+4-5)
  • (modified) flang/runtime/edit-input.cpp (+35-3)
diff --git a/flang/docs/Extensions.md b/flang/docs/Extensions.md
index 16eb67f2e27c81..c71beb5262439f 100644
--- a/flang/docs/Extensions.md
+++ b/flang/docs/Extensions.md
@@ -648,11 +648,10 @@ end
   only in function references, but not an explicit `INTRINSIC` statement,
   its name is not brought into other scopes by a `USE` statement.
 
-* Should hexadecimal floating-point input editing apply any rounding?
-  F'2023 subclause 13.7.2.3.8 only discusses rounding in the context of
-  decimal-to-binary conversion; it would seem to not apply, and so
-  we don't round.  This seems to be how the Intel Fortran compilers
-  behave.
+* The subclause on rounding in formatted I/O (13.7.2.3.8 in F'2023)
+  only discusses rounding for decimal-to/from-binary conversions,
+  omitting any mention of rounding for hexadecimal conversions.
+  As other compilers do apply rounding, so does this one.
 
 ## De Facto Standard Features
 
diff --git a/flang/runtime/edit-input.cpp b/flang/runtime/edit-input.cpp
index 6d4fa588cbf60d..385a36174ed595 100644
--- a/flang/runtime/edit-input.cpp
+++ b/flang/runtime/edit-input.cpp
@@ -627,6 +627,31 @@ decimal::ConversionToBinaryResult<binaryPrecision> ConvertHexadecimal(
       fraction <<= 1;
       --expo;
     }
+    // Rounding
+    bool increase{false};
+    switch (rounding) {
+    case decimal::RoundNearest: // RN & RP
+      increase = roundingBit && (guardBit | ((int)fraction & 1));
+      break;
+    case decimal::RoundUp: // RU
+      increase = !isNegative && (roundingBit | guardBit);
+      break;
+    case decimal::RoundDown: // RD
+      increase = isNegative && (roundingBit | guardBit);
+      break;
+    case decimal::RoundToZero: // RZ
+      break;
+    case decimal::RoundCompatible: // RC
+      increase = roundingBit != 0;
+      break;
+    }
+    if (increase) {
+      ++fraction;
+      if (fraction >> binaryPrecision) {
+        fraction >>= 1;
+        ++expo;
+      }
+    }
   }
   // Package & return result
   constexpr RawType significandMask{(one << RealType::significandBits) - 1};
@@ -637,9 +662,16 @@ decimal::ConversionToBinaryResult<binaryPrecision> ConvertHexadecimal(
     expo = 0; // subnormal
     flags |= decimal::Underflow;
   } else if (expo >= RealType::maxExponent) {
-    expo = RealType::maxExponent; // +/-Inf
-    fraction = 0;
-    flags |= decimal::Overflow;
+    if (rounding == decimal::RoundToZero ||
+        (rounding == decimal::RoundDown && !isNegative) ||
+        (rounding == decimal::RoundUp && isNegative)) {
+      expo = RealType::maxExponent - 1; // +/-HUGE()
+      fraction = significandMask;
+    } else {
+      expo = RealType::maxExponent; // +/-Inf
+      fraction = 0;
+      flags |= decimal::Overflow;
+    }
   } else {
     fraction &= significandMask; // remove explicit normalization unless x87
   }

Copy link
Contributor

@psteinfeld psteinfeld left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All builds and tests correctly and looks good.

@klausler klausler merged commit add189c into llvm:main Jan 15, 2024
@klausler klausler deleted the bug1477 branch January 15, 2024 18:39
justinfargnoli pushed a commit to justinfargnoli/llvm-project that referenced this pull request Jan 28, 2024
…vm#77006)

This reverts commit cab156c, and adds
language to Extensions.md documenting the discrepancy with the letter of
the language standard.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flang:runtime flang Flang issues not falling into any other category
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants