Skip to content

[flang] Fix crash with USE of hermetic module file #138785

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

klausler
Copy link
Contributor

@klausler klausler commented May 7, 2025

When one hermetic module file uses another, a later compilation may crash in semantics when it itself is used, since the module file reader sets the "current hermetic module file scope" to null after reading one rather than saving and restoring that pointer.

@llvmbot llvmbot added flang Flang issues not falling into any other category flang:semantics labels May 7, 2025
@llvmbot
Copy link
Member

llvmbot commented May 7, 2025

@llvm/pr-subscribers-flang-semantics

Author: Peter Klausler (klausler)

Changes

When one hermetic module file uses another, a later compilation may crash in semantics when it itself is used, since the module file reader sets the "current hermetic module file scope" to null after reading one rather than saving and restoring that pointer.


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

2 Files Affected:

  • (modified) flang/lib/Semantics/mod-file.cpp (+2-1)
  • (added) flang/test/Semantics/modfile75.F90 (+17)
diff --git a/flang/lib/Semantics/mod-file.cpp b/flang/lib/Semantics/mod-file.cpp
index ee356e56e4458..3df229cc85587 100644
--- a/flang/lib/Semantics/mod-file.cpp
+++ b/flang/lib/Semantics/mod-file.cpp
@@ -1537,6 +1537,7 @@ Scope *ModFileReader::Read(SourceName name, std::optional<bool> isIntrinsic,
   // created under -fhermetic-module-files?  If so, process them first in
   // their own nested scope that will be visible only to USE statements
   // within the module file.
+  Scope *previousHermetic{context_.currentHermeticModuleFileScope()};
   if (parseTree.v.size() > 1) {
     parser::Program hermeticModules{std::move(parseTree.v)};
     parseTree.v.emplace_back(std::move(hermeticModules.v.front()));
@@ -1552,7 +1553,7 @@ Scope *ModFileReader::Read(SourceName name, std::optional<bool> isIntrinsic,
   GetModuleDependences(context_.moduleDependences(), sourceFile->content());
   ResolveNames(context_, parseTree, topScope);
   context_.foldingContext().set_moduleFileName(wasModuleFileName);
-  context_.set_currentHermeticModuleFileScope(nullptr);
+  context_.set_currentHermeticModuleFileScope(previousHermetic);
   if (!moduleSymbol) {
     // Submodule symbols' storage are owned by their parents' scopes,
     // but their names are not in their parents' dictionaries -- we
diff --git a/flang/test/Semantics/modfile75.F90 b/flang/test/Semantics/modfile75.F90
new file mode 100644
index 0000000000000..e8cfb13552437
--- /dev/null
+++ b/flang/test/Semantics/modfile75.F90
@@ -0,0 +1,17 @@
+!RUN: (%flang -c -DWHICH=1 %s && %flang -c -DWHICH=2 %s && %flang_fc1 -fdebug-unparse %s) | FileCheck %s
+
+#if WHICH == 1
+module m1
+  use iso_c_binding
+end
+#elif WHICH == 2
+module m2
+  use m1
+end
+#else
+program test
+  use m2
+!CHECK: INTEGER(KIND=4_4) n
+  integer(c_int) n
+end
+#endif

program test
use m2
!CHECK: INTEGER(KIND=4_4) n
integer(c_int) n
Copy link
Contributor

Choose a reason for hiding this comment

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

Something is broken here. See buildbots "flang/test/Semantics/modfile75.F90:15:11: error: Must be a constant value".

I am thinking this could be a lit "race" with module file (I am not sure, but I think all the tests are ran in the same directory in parallel, which would cause the issue since m1 are common names and could be overridden before the final part of the test).

Copy link
Contributor

@akuhlens akuhlens left a comment

Choose a reason for hiding this comment

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

LGTM

When one hermetic module file uses another, a later compilation
may crash in semantics when it itself is used, since the module
file reader sets the "current hermetic module file scope" to
null after reading one rather than saving and restoring that
pointer.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flang:semantics flang Flang issues not falling into any other category
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants