[flang-commits] [flang] [llvm] [Proof-of-Concept][flang][OpenMP] Implicitely map allocatable record fields (PR #117867)

via flang-commits flang-commits at lists.llvm.org
Wed Nov 27 09:43:49 PST 2024


================
@@ -0,0 +1,63 @@
+! Test implicit mapping of alloctable record fields.
+
+! REQUIRES: flang, amdgpu
+
+! This fails only because it needs the Fortran runtime built for device. If this
+! is avaialbe, this test succeedds when run.
+! XFAIL: *
+
+! RUN: %libomptarget-compile-fortran-generic
+! RUN: env LIBOMPTARGET_INFO=16 %libomptarget-run-generic 2>&1 | %fcheck-generic
+module record_m
+  implicit none
+
+  private
+  public :: recored_t
+
+  type recored_t
----------------
agozillon wrote:

Excellent start! :-) 

Will likely need to consider the cases where we have an allocatable derived type, with allocatable members (or regular members), and cases where we have multiple nested allocatable derived types within each other. Basically just mixes of various allocatable/pointers etc. Doesn't need to work in the first PR iteration, but at the very least we need to make sure we don't blow up the compiler or runtime mappings by accident with the new implicit mappings.

Although, I think if you can run check-offload, this should all be covered as-is, but please do make sure check-offload runs correctly for you (e.g. intentionally fail a test locally and run to make sure it does in fact test them all), there's annoying cases where check-offload doesn't actually run the fortran offload tests even when Flang and all it's relevant components have been compiled! Unsure why unfortunately, likely related to environment setup.

But still might want to prevent the generation of these in nested cases if you're going to leave them as a TODO for now, just to prevent any possible erroneous cases that aren't caught by check-offload and to prevent unnecessary mappings that may not be correct!

https://github.com/llvm/llvm-project/pull/117867


More information about the flang-commits mailing list