================
@@ -76,7 +77,13 @@ namespace Fortran {
namespace lower {
namespace omp {
bool requiresImplicitDefaultDeclareMapper(
- const semantics::DerivedTypeSpec &typeSpec) {
+ const semantics::DerivedTypeSpec &typeSpec,
+ bool enableImplicitDefaultMapperAllocatableMembers) {
+ // If disabled via -fno-implicit-default-mapper-allocatable-members
+ // return false, as we do not need to emit allocatable member maps.
+ if (!enableImplicitDefaultMapperAllocatableMembers)
----------------
agozillon wrote:
So, this one is an odd one that I am not entirely sure should be handled in
this PR, but I'll update it none the less and we can discuss fracturing it into
a separate commit if it doesn't make sense.
That case seems to only work because there's an allocatable member inside of
outer, if you remove it or change it to a non-allocatable, you run into the
exact same problem with/without this patch. So this allocatable case is
effectively an oddity and is being propped up entirely by the implicit
allocatable mapper behaviour.
There's two options I can see and I'll likely opt for the path of least
resistance for now which would be number 2:
1) We generate a member map that we can attach the mapper to, rather than
recursively creating mappers. As a recursive series of mappers just for a
nested user mapper feels a bit overkill. But that works entirely differently to
how it does today for this example, hence option 2.
2) We generate our usual nested mappers if we find a need to (user defined
mapper in nesting), but opt out of emitting allocatable maps for the mappers we
create along the way.
https://github.com/llvm/llvm-project/pull/228748
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
