Re: [Patch] Fortran: Update use_device_ptr for OpenMP 5.1 [PR105318]

[Tobias Burnus <tobias@codesourcery.com>]

[-- Attachment #1: Type: text/plain, Size: 2452 bytes --]

Hi Jakub,

On 30.09.22 13:04, Jakub Jelinek via Fortran wrote:

On Fri, Sep 30, 2022 at 12:41:19PM +0200, Tobias Burnus wrote:


And 'device(omp_initial_device)' printed a warning in Fortran.
(BTW: C/C++ silently accepts any negative value.)


I think that is what the standard wants.
E.g. in 5.2 device Clause chapter, there is just
"If the device_num device-modifier is specified and target-offload-var is not mandatory,
device-description must evaluate to a conforming device number."
restriction, which is something that can't be checked at compile time,
you don't know if target-offload-var is mandatory or not.


Admittedly, it is valid to use a non-conforming device number with
target-offload-var being 'mandatory'; however, the result is still
it it has a "non-conforming device number, is as if the
omp_invalid_device device number was used." (Which implies error
termination.)

Thus, while not invalid (iff using 'mandatory'), it is still odd
code and using 'device(omp_invalid_device)' is more sensible.

I think it is legitimate to warn in this case - but not to
print an error. It is likewise fine to accept it silently.



   if (omp_clauses->device)
-    resolve_nonnegative_int_expr (omp_clauses->device, "DEVICE");
+    {
+      resolve_scalar_int_expr (omp_clauses->device, "DEVICE");
+      /* omp_initial_device == 1, omp_invalid_device = -4 (in GCC).  */
+      if (omp_clauses->device->expr_type == EXPR_CONSTANT
+         && omp_clauses->device->ts.type == BT_INTEGER
+         && mpz_cmp_si (omp_clauses->device->value.integer, -1) < 0
+         && mpz_cmp_si (omp_clauses->device->value.integer, -4) != 0)
+       gfc_warning (0,
+                    "INTEGER expression of DEVICE clause at %L must be non-"
+                    "negative or omp_initial_device or omp_invalid_device",
+                    &omp_clauses->device->where);
+    }



So I think we should just resolve_scalar_int_expr and be done with that.

Otherwise LGTM.


I have now done as suggested - and committed it as https://gcc.gnu.org/r13-2980-g10a116104969b3ecc9ea4abdd5436c66fd78d537

Thanks for the review!

Tobias


-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955