[all-commits] [llvm/llvm-project] 3018c3: [Flang][OpenMP] Remove close map type member remov...

[agozillon via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 3018c32171d439dec1b76ef961cc60c0d8db2c6c
      https://github.com/llvm/llvm-project/commit/3018c32171d439dec1b76ef961cc60c0d8db2c6c
  Author: agozillon <Andrew.Gozillon at amd.com>
  Date:   2026-09-15 (Tue, 15 Sep 2026)

  Changed paths:
    M flang/lib/Lower/OpenMP/Utils.cpp
    M flang/lib/Optimizer/OpenMP/MapInfoFinalization.cpp
    M flang/lib/Semantics/check-omp-structure.cpp
    M flang/lib/Semantics/check-omp-structure.h
    A flang/test/Lower/OpenMP/close-map-derived-members.f90
    M flang/test/Semantics/OpenMP/map-modifiers.f90
    A offload/test/offloading/fortran/usm_map_close_derived_type_members.f90

  Log Message:
  -----------
  [Flang][OpenMP] Remove close map type member removal code from MapInfoFinalization (#219438)

This should no longer be required as we removed the application of close
automatically in USM mode in a prior PR. So they bug this was originally
put in place for is now addressed without the need for this PR. And
whilst it was fine to put in place for a bug the user had no control of
(automatic application of close to descriptor members), it's not our
place to intervene in scenarios where a user is making explicit errors
in their mapping, e.g.

map(to: dtype) map(close, to: dtype%x, dtype%y)

A user should be left to shoot themselves in the foot if that's there
goal (or perhaps there's some really wild or single memory system
architectures that would allow this), we'd ideally prevent this as a
compiler warning or error as opposed to fixing the problem
under-the-hood for them. Otherwise we help create unportable code for
the user, alongside forcing ourselves to maintain the underlying fix.



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