On Mon, Sep 12, 2022 at 11:04:08AM +0200, Tobias Burnus wrote:
> This patch is about the OpenMP 5.{1,2} implementation status.
>
> For omp/ompx/omx, I think it was a bit misleading. omp/ompx (and omx)
> are reserved namespaces; for 'omp' nothing needs to be done (either
> already implemented or not), while for 'ompx'/'omx' (vendor extension),
> the note + footnote tries to describe what happens. – I hope the revised
> wording is clearer.
>
> The other change is about two OpenMP 5.1 items; the first one seems to
> get used in some code – 'begin declare target' is essentially the same
> as 'declare target' ... 'end declare target' but additionally permits
> clauses.
>
> And the second new item: I think it was regarded as bug fix, but I
> personally read it rather as change. The question is as what to read it
> and how to handle it? Initially I wrote and thought of it as deprecation
> of the previous syntax, i.e. warning but only once the OpenMP version
> has been bumped to 5.2's. I now think we could diagnose it earlier – IMO
> a warning would be sufficient, but it could also be read it such that an
> error is required. – Thoughts about this item + what to implement?
IMNSHO we should support it without any diagnostics until the big
deprecation day of 5.2 (when we are almost done with 5.2 and add all the
-Wdeprecated stuff there).
It is very similar to many other 5.2 changes, introduce a new syntax and
deprecate the old one.
> libgomp.texi: Impl. status fix/addition
>
> libgomp/ChangeLog:
>
> * libgomp.texi (OpenMP 5.1 Impl. Status): Add two new minor items.
> (OpenMP 5.2 Impl. Status): Improve omp/omx/ompx wording.
>
> diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
> index 3dc467aade0..7db5fab580a 100644
> --- a/libgomp/libgomp.texi
> +++ b/libgomp/libgomp.texi
> @@ -348,6 +348,9 @@ The OpenMP 4.5 specification is fully supported.
> @item Support @code{begin/end declare target} syntax in C/C++ @tab N @tab
> @item Pointer predetermined firstprivate getting initialized
> to address of matching mapped list item per 5.1, Sect. 2.21.7.2 @tab N @tab
> +@item @code{begin declare target} directive @tab N @tab
> +@item For Fortran, diagnose placing declarative before/between @code{USE},
> + @code{IMPORT}, and @code{IMPLICIT} as invalid @tab N @tab
> @end multitable
>
>
> @@ -362,12 +365,13 @@ to address of matching mapped list item per 5.1, Sect.
> 2.21.7.2 @tab N @tab
> @tab N @tab
> @item @code{omp}/@code{ompx}/@code{omx} sentinels and
> @code{omp_}/@code{ompx_}
> namespaces @tab N/A
> - @tab warning for @code{omp/ompx} sentinels@footnote{@code{omp/ompx}
> - sentinels as C/C++ pragma and C++ attributes are warned for with
> + @tab warning for @code{ompx/omx} sentinels@footnote{The @code{ompx}
> + sentinel as C/C++ pragma and C++ attributes are warned for with
> @code{-Wunknown-pragmas} (implied by @code{-Wall}) and
> @code{-Wattributes}
> (enabled by default), respectively; for Fortran free-source code,
> there is
> - a warning enabled by default and for fixed-source code with
> - @code{-Wsurprising} (enabled by @code{-Wall})}
> + a warning enabled by default and, for fixed-source code, the @code{omx}
> + sentinel is warned for with with @code{-Wsurprising} (enabled by
> + @code{-Wall}). Unknown clauses are always rejected with an error.}
Two spaces after ., not just one.
Otherwise LGTM.
Jakub
