[all-commits] [llvm/llvm-project] ee3b6b: [Flang][OpenMP] Fix broken offload test caused by ...
agozillon via All-commits
all-commits at lists.llvm.org
Fri Sep 25 13:55:26 PDT 2026
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: ee3b6b045bc37b156c3860481090d68367e961dc
https://github.com/llvm/llvm-project/commit/ee3b6b045bc37b156c3860481090d68367e961dc
Author: agozillon <Andrew.Gozillon at amd.com>
Date: 2026-09-25 (Fri, 25 Sep 2026)
Changed paths:
M flang/lib/Lower/OpenMP/ClauseProcessor.cpp
M flang/lib/Lower/OpenMP/Utils.cpp
M flang/lib/Lower/OpenMP/Utils.h
M flang/test/Lower/OpenMP/declare-mapper.f90
A flang/test/Lower/OpenMP/target-map-nested-dtype-allocatable-member.f90
Log Message:
-----------
[Flang][OpenMP] Fix broken offload test caused by MapInfoFinalization code movement (#226384)
This change addresses the breakage in
target-map-nested-dtype-allocatable-member.f90 I inadvertently broke it
by removing the excess bit of implicit mapping code in the
MapInfoFinalizaiton pass without correctly addressing it.
This PR tries to do so by allowing mappers to be generated for member
maps such as var1%b, var2%b, which were previously being blocked.
Currently (and conveniently for this patch) we do avoid duplicate maps
in the scenario where we specify something along the lines of:
map(tofrom: var1, var1%b, var2, var2%b)
But that is through the fact that we completely negate var1/var2's
mapper attachment in this scenario, which I do not believe is the
correct behavior. But it's the existing behavior and facilitates this
patch, but it is something I'll see if I can address in a follow up PR
in the near future, the logic might need a bit of debating. For now this
simply seeks to amend the existing test without rocking the boat more
than required (that's the hope at least).
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