[flang-commits] [flang] [Flang][OpenMP] Implement "promotion" of use_device_ptr non-cptr arguments to use_device_addr (PR #82834)

[via flang-commits]

================
@@ -745,6 +797,20 @@ genDataOp(Fortran::lower::AbstractConverter &converter,
                          useDeviceSymbols);
   cp.processUseDeviceAddr(deviceAddrOperands, useDeviceTypes, useDeviceLocs,
                           useDeviceSymbols);
+  // This function implements the deprecated functionality of use_device_ptr
+  // that allows users to provide non-CPTR arguments to it with the caveat
+  // that the compiler will treat them as use_device_addr. A lot of legacy
+  // code may still depend on this functionality, so we should support it
+  // in some manner. We do so currently by simply shifting non-cptr operands
+  // from the use_device_ptr list into the front of the use_device_addr list
+  // whilst maintaining the ordering of useDeviceLocs, useDeviceSymbols and
+  // useDeviceTypes to use_device_ptr/use_device_addr input for BlockArg
+  // ordering.
+  // TODO: Perhaps create a user provideable compiler option that will
+  // re-introduce a hard-error rather than a warning in these cases.
+  promoteNonCPtrUseDevicePtrArgsToUseDeviceAddr(
+      devicePtrOperands, deviceAddrOperands, useDeviceTypes, useDeviceLocs,
+      useDeviceSymbols);
----------------
agozillon wrote:

I could certainly try to do that if you would prefer it! 

I opted for this originally as it keeps the behavior as a seperate process and currently processUseDevicePtr/processUseDeviceAddr effectively use the same function call currently under the hood, so I was a little apprehensive to overload it for just useDevcePtr related behavior. 

Doing it this way also allowed keeping the ordering easier at the time as access to the complete list (of use device and addr) is possible (but I suppose that depends on your perspective of order in this case, i.e. should the non-cptr useDevicePtr arguments be inserted at the end or front of the useDeviceAddr list).

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