[Patch] Fortran: Fixes to OpenMP 'interop' directive parsing support

Tobias Burnus tburnus@baylibre.com
Thu Sep 12 17:00:12 GMT 2024


This patch fixes a couple of issues, like a missing white-space gobbling 
after matching an expression.

It also reorganizes some code to handle 'identifier_"string"' vs. 
'identifier' better as there were some diagnostic issues.

(OpenMP requires for 'fr' that the argument is either an identifier 
(that is a scalar integer parameter) or a string; while for the older 
syntax, it can be any constant integer expression.)

However, the two main changes are:

* 'fr' and 'attr' actually support a list of arguments. While I believe 
'attr("x", "y") and "attr("x"),attr("y")' are semantically identically, 
supporting more than one (or zero) values for 'fr' required a different 
encoding.

* Jakub additionally suggested that for 'fr', which supports constant 
integers and string literals, we could pass on integer values – and do 
some checking.

That's what this patch does: Known string values are converted to their 
associated integer values, others to 0. And if the integer/string value 
is unknown, a warning is printed [-Wopenmp].

Known values are those in the "OpenMP API Additional Definitions" 
document, https://www.openmp.org/specifications/ – with the addition of 
hsa / 7, which has been voted at spec level (no idea about ARB level) 
but not yet published.

Note that that's the warning is based on what is defined there, i.e. 
'level_zero' there is no warning, even though GCC does not support it. 
Obviously, if will add another value next year, GCC 15 will not support 
it and warn, even if the code is perfectly valid. — But I guess we can 
live with a warning in that case.

Comments, remarks, suggestions? — Especially regarding the internal 
representation?

Tobias

PS: Next step will be to get the C/C++ parsing working, which also 
implies encoding this representation into 'tree'. (Then doing the tree 
conversion for Fortran.) Once satisfied with that, the middle end + 
libgomp part that links those bits will come next. And the question 
whether there should be one call per 'interop' directive or might be 
multiple (e.g. one per interop object in 'init'/'use'/'destroy').
-------------- next part --------------
A non-text attachment was scrubbed...
Name: interop-fortran-parsing-fixes.diff
Type: text/x-patch
Size: 29559 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/fortran/attachments/20240912/86e4830d/attachment-0001.bin>


More information about the Fortran mailing list