Skip to content
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

[flang] USE-associated explicit INTRINSIC names #76199

Merged
merged 1 commit into from
Dec 27, 2023
Merged

Conversation

klausler
Copy link
Contributor

The compiler doesn't USE-associate names of intrinsic procedures from modules (in the absence of ONLY:), so that the associating scope doesn't get populated with names of intrinsics that were used only in declarations (e.g., SELECTED_REAL_KIND). A recent bug report (below) shows that we should modify that policy in the case of names that appear in explicit INTRINSIC attribute statements. The behaviors of other Fortran compilers are not consistent and the requirements of the standard are not clear; this fix follows the precedent set by gfortran and nvfortran.

Fixes #72084.

@llvmbot
Copy link
Collaborator

llvmbot commented Dec 22, 2023

@llvm/pr-subscribers-flang-semantics

Author: Peter Klausler (klausler)

Changes

The compiler doesn't USE-associate names of intrinsic procedures from modules (in the absence of ONLY:), so that the associating scope doesn't get populated with names of intrinsics that were used only in declarations (e.g., SELECTED_REAL_KIND). A recent bug report (below) shows that we should modify that policy in the case of names that appear in explicit INTRINSIC attribute statements. The behaviors of other Fortran compilers are not consistent and the requirements of the standard are not clear; this fix follows the precedent set by gfortran and nvfortran.

Fixes #72084.


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

3 Files Affected:

  • (modified) flang/docs/Extensions.md (+4)
  • (modified) flang/lib/Semantics/resolve-names.cpp (+5-5)
  • (added) flang/test/Semantics/intrinsics02.f90 (+16)
diff --git a/flang/docs/Extensions.md b/flang/docs/Extensions.md
index 03d4310466485c..6c6588025a392d 100644
--- a/flang/docs/Extensions.md
+++ b/flang/docs/Extensions.md
@@ -641,6 +641,10 @@ module m
 end
 ```
 
+* When an intrinsic procedure appears in the specification part of a module
+  only in function references, but not an explicit `INTRINSIC` statement,
+  its name is not brought into other scopes by a `USE` statement.
+
 ## De Facto Standard Features
 
 * `EXTENDS_TYPE_OF()` returns `.TRUE.` if both of its arguments have the
diff --git a/flang/lib/Semantics/resolve-names.cpp b/flang/lib/Semantics/resolve-names.cpp
index e1cd34ddf65b6b..73f240abc95b7b 100644
--- a/flang/lib/Semantics/resolve-names.cpp
+++ b/flang/lib/Semantics/resolve-names.cpp
@@ -2904,7 +2904,7 @@ void ModuleVisitor::Post(const parser::UseStmt &x) {
     }
     for (const auto &[name, symbol] : *useModuleScope_) {
       if (symbol->attrs().test(Attr::PUBLIC) && !IsUseRenamed(symbol->name()) &&
-          (!symbol->attrs().test(Attr::INTRINSIC) ||
+          (!symbol->implicitAttrs().test(Attr::INTRINSIC) ||
               symbol->has<UseDetails>()) &&
           !symbol->has<MiscDetails>() && useNames.count(name) == 0) {
         SourceName location{x.moduleName.source};
@@ -6244,8 +6244,8 @@ bool DeclarationVisitor::HandleUnrestrictedSpecificIntrinsicFunction(
     // recreated for it later on demand, but capturing its result type here
     // will make GetType() return a correct result without having to
     // probe the intrinsics table again.
-    Symbol &symbol{
-        MakeSymbol(InclusiveScope(), name.source, Attrs{Attr::INTRINSIC})};
+    Symbol &symbol{MakeSymbol(InclusiveScope(), name.source, Attrs{})};
+    SetImplicitAttr(symbol, Attr::INTRINSIC);
     CHECK(interface->functionResult.has_value());
     evaluate::DynamicType dyType{
         DEREF(interface->functionResult->GetTypeAndShape()).type()};
@@ -7708,8 +7708,8 @@ void ResolveNamesVisitor::HandleProcedureName(
   auto *symbol{FindSymbol(NonDerivedTypeScope(), name)};
   if (!symbol) {
     if (IsIntrinsic(name.source, flag)) {
-      symbol =
-          &MakeSymbol(InclusiveScope(), name.source, Attrs{Attr::INTRINSIC});
+      symbol = &MakeSymbol(InclusiveScope(), name.source, Attrs{});
+      SetImplicitAttr(*symbol, Attr::INTRINSIC);
     } else if (const auto ppcBuiltinScope =
                    currScope().context().GetPPCBuiltinsScope()) {
       // Check if it is a builtin from the predefined module
diff --git a/flang/test/Semantics/intrinsics02.f90 b/flang/test/Semantics/intrinsics02.f90
new file mode 100644
index 00000000000000..1b8dc4f34ba69c
--- /dev/null
+++ b/flang/test/Semantics/intrinsics02.f90
@@ -0,0 +1,16 @@
+! RUN: %python %S/test_errors.py %s %flang_fc1
+module explicit
+  intrinsic cos
+end
+subroutine testExplicit
+  use explicit
+  !ERROR: 'cos' is use-associated from module 'explicit' and cannot be re-declared
+  real :: cos = 2.
+end
+module implicit
+  real :: one = cos(0.)
+end
+subroutine testImplicit
+  use implicit
+  real :: cos = 2.
+end

Copy link
Contributor

@ceseo ceseo left a comment

Choose a reason for hiding this comment

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

LGTM.

The compiler doesn't USE-associate the names of intrinsic procedures
from modules (in the absence of ONLY:), so that the associating
scope doesn't get populated with names of intrinsics that were used
only in declarations (e.g., SELECTED_REAL_KIND).  A recent bug report
(below) shows that we should modify that policy in the case of names
that appear in explicit INTRINSIC attribute statements.  The behaviors
of other Fortran compilers are not consistent and the requirements of the
standard are not clear; this fix follows the precedent set by gfortran
and nvfortran.

Fixes llvm#72084.
@klausler klausler merged commit 5a402c5 into llvm:main Dec 27, 2023
5 checks passed
@klausler klausler deleted the bug72084 branch December 27, 2023 00:03
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
3 participants