[all-commits] [llvm/llvm-project] 4b5f74: [flang][OpenMP] Implicit declarations of procedure...

Krzysztof Parzyszek via All-commits all-commits at lists.llvm.org
Wed Jun 10 16:13:59 PDT 2026


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4b5f74b154228f5d129ccd7dcb1e09e7193643ae
      https://github.com/llvm/llvm-project/commit/4b5f74b154228f5d129ccd7dcb1e09e7193643ae
  Author: Krzysztof Parzyszek <Krzysztof.Parzyszek at amd.com>
  Date:   2026-06-10 (Wed, 10 Jun 2026)

  Changed paths:
    M flang/lib/Semantics/resolve-names.cpp
    A flang/test/Semantics/OpenMP/declare-target-resolve.f90
    A flang/test/Semantics/OpenMP/declare-target-symbols.f90
    M flang/test/Semantics/OpenMP/declare-target08.f90

  Log Message:
  -----------
  [flang][OpenMP] Implicit declarations of procedures in DECLARE_TARGET (#201935)

This replaces commit 8f5df8891840b, since it was rejecting the following
case:
```
  function baz(a)
    !$omp declare target to(baz)
    real, intent(in) :: a
    baz = a
  end

  program main
    !$omp declare target(baz)
    integer, save :: baz        ! error: 'baz' is already declared
  end
```
Instead of flagging an error, the 'baz' in the directive should be
resolved to the explicitly declared variable.

The original motivating example was to allow the case where the main
program (from the above snippet) looked like the following:
```
  program main
    real :: a
    !$omp declare target(baz)   ! 'baz' should be resolved to the
    !$omp target                ! external function
      a = baz(a)                ! <- because of this call
    !$omp end target
  end
```

The problem is that "declare_target(baz)" despite being the same in both
cases, should lead to two different outcomes in symbol resolution.

This fix will treat declarations introduced by a DECLARE_TARGET as
eligible for overriding with a potentially conflicting declaration
stemming from the use of that name in a language construct or
expression. Since a mere mention of a name alone declares an object,
such conflict occurs when the name would have been otherwise resolved to
a procedure.
This changes the behavior introduced in 8f5df8891840b, where
yet-undeclared names on a DECLARE_TARGET were preferentially resolved to
external procedures.

The function HandleProcedureName was modified to "undeclare" names
implicitly declared due to their appearance in a DECLARE_TARGET.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications


More information about the All-commits mailing list