On 7/17/26 04:22, Tobias Burnus wrote:
gcc/ChangeLog:
* doc/invoke.texi (-fopenmp-openmp, -fopenmp-openmp-detailed): Improve
Uh, those option names look like think-os....
wording.
libgomp/ChangeLog:
* libgomp.texi (OpenMP 5.1 Impl Status): Mark device_type on vars
in declare target as 'P'.
This is mostly OK, except...
+Add additional calls into the OpenMP runtime for more detailed tracing via
OMPT,
+which might have a measurable effect on the performance. The option enables
+additional constructs to issue events for the @code{dispatch} callback, which
+is invoked when begining to execute a section or a collapsed iteration in a
+@code{taskloop} or worksharing construct. With that option, also the
+@code{distribute} and worksharing loop constructs with static scheduling can
+dispatch the callback. Implies @option{-fopenmp-ompt} and requires
@option{-fopenmp}.
I don't know what "that option" is supposed to refer to (maybe you mean
"this option", namely -fopenmp-ompt-detailed, or what "dispatch the
callback" means.
FWIW, though, my preference would be to replace these two options with a
single option that takes an argument, like -fopenmp-ompt=none,
-fopenmp-ompt=basic, and -fopenmp-ompt=details, and -fopenmp-ompt being
a synonym for -fopenmp-ompt=basic, and -fno-openmp-ompt for
-fopenmp-ompt=none -- especially if more kinds of tracing or
finer-grained control are anticipated in the future.
-Sandra
