[flang-commits] [flang] [llvm] [flang] Enumeration Type: (PR 3/5) Intrinsics + I/O + Modules (PR #193235)

via flang-commits flang-commits at lists.llvm.org
Mon Aug 3 10:50:46 PDT 2026


================
@@ -1224,7 +1338,32 @@ parser::Message *IoChecker::CheckForBadIoType(const evaluate::DynamicType &type,
         where, "I/O list item may not be unlimited polymorphic"_err_en_US);
   } else if (type.category() == TypeCategory::Derived) {
     const auto &derived{type.GetDerivedTypeSpec()};
+    if (const auto *details{
+            derived.typeSymbol().detailsIf<DerivedTypeDetails>()}) {
+      if (details->isEnumerationType()) {
+        if (which == common::DefinedIo::ReadUnformatted ||
+            which == common::DefinedIo::WriteUnformatted) {
+          return &context_.Say(where,
+              "Enumeration type may not be used in unformatted I/O"_err_en_US);
----------------
kwyatt-ext wrote:

You got me on this one.  I thought I had a justification for not allowing unformatted I/O.  I've been digging through my notes for a while and can't find the reason for this limitation.  After scouring the spec it doesn't seem like a valid limitation.  On the other hand, allowing it means assuming that it present itself as the underlying integer ordinal.  This is not specifically spelled out by the standard.  I can go the ordinal route which is justifiable or enter a new issue for a decision and correction later.  What do you prefer?

https://github.com/llvm/llvm-project/pull/193235


More information about the flang-commits mailing list