OpenMP: docs - improve -fopenmp-openmp(-detailed) description + update impl. status (was: [PATCH] openmp: Add OMPT entry points for worksharing-loop, single, and masked constructs)

  -fopenmp-ompt(-details): Now with a patch - based on my original
proposal but I reworded it quite a bit.

Comments or remarks?

* * *

Thomas Schwinge wrote:
>>>     For some OpenMP constructs
> Maybe 'certain' instead of 'some'?

I am not sure what's better both have connotations that I don't like. In 
any case, the wording afterward should make clear what happens.

I have kept 'some'.

> I like in the current text that we say "calls [into libgomp]", which
> intends to help the user understand what kind of calls these are?
> Or, even better, as you have it below: "calls into the OpenMP runtime",
> to avoid implementor-speak?
Done so when rewording.
>>>     region instead of only on region entry.  This improves the OMPT
>>>     tracing
> Is "OMPT tracing" the correct term to use?

I hope the current wording is better. OpenMP distinguishes between 
events and callbacks (which can also only be invoked if registered by a 
tool). It also talks about "OMPT defines mechanisms to … notification 
about events, to trace activity".

I hope the new wording is both clear and (mostly) correct in terms of 
spec wording.

>>> at expense of additional calls.  In particular, the
>>>     additional calls will be added for static worksharing loops,
>>>     static worksharing @code{dispatch}
> Shoud this probably be 'distribute' instead of 'dispatch'?

Yes - the callback is 'dispatch' and the event occurs for 'distribute'.

When writing email review comments, I am more lazy then writing actual 
patches (cf. also previous email); I hope the real patch is fine in this 
regard.

>
>>>     Add additional calls into the OpenMP runtime that might affect
>>>     the performance
> Maybe "might negatively affect performance"?

The current wording is:
"Add additional calls …, which might have a measurable effect on the 
performance."

I think rewording it to include negative makes it more clumsy – and 
anyone who thinks that additional calls make it faster should think 
again, esp. as the flag is not enabled by default …

>>> but further improves OMPT tracing. In particular,
>>>     dispatch callbacks
> Should 'dispatch' get some mark-up here?  Or, prefix with "OMPT"?

@code{} makes sense, but clustering the wording with OMPT does not 
really improve the readabilty (IMHO).

Tobias
  

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
  

Sandra Loosemore wrote:
> 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....
... (no words)
>> +@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.

I changed this to:

The additional calls are generated with static scheduling
for the @code{distribute} and worksharing loop constructs.

which avoids all the word dance.

And committed it as r17-2499-gcfb1d8314830af

* * *

Dispatch means: When the event occurs and the tool has registered
the callback in the OpenMP runtime, that callback is invoked.
Confusingly, that callback is named 'dispatch'.

But if the tool didn't register that callback, obviously, it will
never be called.

In the words of the spec (here for workshare loops):

"A thread dispatches a registered 'dispatch' callback for each
  occurrence of a ws-loop-iteration-begin or ws-loop-chunk-begin
  event in that thread."

* * *

> 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.

I don't think that we will see finer control. The idea is:
-fopenmp
    add no additional runtime calls but have a decent OMPT support

-fopenmp -fopenmp-ompt
    Additional calls that have a low overhead but a larger benefit
    Namely: instead of telling the tool only when something begins,
    also tell it when it ends.

-fopenmp -fopenmp-ompt-detailed
    Add more expensive calls, usually not needed but if one really
    wants to drill down and does not fear a higher overhead

And I have a hard time imagine an additional option here.


Otherwise, I think combining the two and supporting
  (-fno-openmp-ompt )
   -fopenmp-ompt
   -fopenmp-ompt=detailed
would look better in the documentation than having two
separate options.

However, the -fopenmp-ompt=basic and -fopenmp-ompt=none
are a bit odd:

-fopenmp-ompt=none in particular but also -fno-openmp-ompt
are a bit strange as - despite 'none' / 'no' - OMPT is still
mostly handled, just some additional details aren't reported
to the tool.

Likewise, -fopenmp=basic is not the minimal support, even if
'basic' implies this but already provides something extra,
albeit less than with 'detailed'.

* * *

I am fine with combing the two options into one - but I am not
planing to implement it.


(On the bike-shedding side: basic, extended, detailed
would also work, albeit basic == -fno-openmp-ompt looks odd.
And extended vs. detailed has no clear ordering regarding
which provides more data and whether one includes the other or
not.)

Tobias
  

Tobias Burnus wrote:
> Sandra Loosemore wrote:
>> 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.
> 
> I don't think that we will see finer control. The idea is:
> -fopenmp
>     add no additional runtime calls but have a decent OMPT support
> 
> -fopenmp -fopenmp-ompt
>     Additional calls that have a low overhead but a larger benefit
>     Namely: instead of telling the tool only when something begins,
>     also tell it when it ends.
> 
> -fopenmp -fopenmp-ompt-detailed
>     Add more expensive calls, usually not needed but if one really
>     wants to drill down and does not fear a higher overhead
> 
> And I have a hard time imagine an additional option here.
> 
> 
> Otherwise, I think combining the two and supporting
>   (-fno-openmp-ompt )
>    -fopenmp-ompt
>    -fopenmp-ompt=detailed
> would look better in the documentation than having two
> separate options.
> 
> However, the -fopenmp-ompt=basic and -fopenmp-ompt=none
> are a bit odd:
> 
> -fopenmp-ompt=none in particular but also -fno-openmp-ompt
> are a bit strange as - despite 'none' / 'no' - OMPT is still
> mostly handled, just some additional details aren't reported
> to the tool.
> 
> Likewise, -fopenmp=basic is not the minimal support, even if
> 'basic' implies this but already provides something extra,
> albeit less than with 'detailed'.
> 
> * * *
> 
> I am fine with combing the two options into one - but I am not
> planing to implement it.
> 
> 
> (On the bike-shedding side: basic, extended, detailed
> would also work, albeit basic == -fno-openmp-ompt looks odd.
> And extended vs. detailed has no clear ordering regarding
> which provides more data and whether one includes the other or
> not.)

I am happy to implement an improved version of the -fopenmp-ompt option 
but I would like to reach consensus before actually writing a patch.

*What about the following*

Having a single option still called '-fopenmp-ompt' that takes an 
argument. Possible values would be 'minimal' (default), 'basic' and 
'extended'. Make it RejectNegative to disallow -fno-openmp-ompt. 
-fopenmp implies -fopenmp-ompt[=minimal]. -fopenmp-ompt still requires 
-fopenmp (no change).

*Rationale*

In GCC, OMPT is implemented in three tiers, hence three possible values 
for the argument. But it is not possible to completely opt out, hence 
'minimal' rather than 'none', and RejectNegative as -fno-openmp-ompt 
does not make sense.

What do you think?
  

Paul-Antoine Arras wrote:
> I am happy to implement an improved version of the -fopenmp-ompt 
> option but I would like to reach consensus before actually writing a 
> patch. *What about the following* Having a single option still called 
> '-fopenmp-ompt' that takes an argument. Possible values would be 
> 'minimal' (default), 'basic' and 'extended'. Make it RejectNegative to 
> disallow -fno-openmp-ompt. -fopenmp implies -fopenmp-ompt[=minimal]. 
> -fopenmp-ompt still requires -fopenmp (no change). *Rationale* In GCC, 
> OMPT is implemented in three tiers, hence three possible values for 
> the argument. But it is not possible to completely opt out, hence 
> 'minimal' rather than 'none', and RejectNegative as -fno-openmp-ompt 
> does not make sense.

I think basic + enhanced/detailed works. But I wonder whether
   -fopenmp-ompt=none / -fno-openmp-ompt
or
   -fopenmp-ompt=minimal
makes more sense - wording wise.

I think it depends how we word the manual page:

* If we talk about 'additional calls', then =none/-fno-… sounds fine
   as no additional calls are added.

* If we talk about minimal support for OMPT without adding calls that
   are only needed for OMPT, then =minimal + implying it by -fopenmp
   makes sense.

In any case, I like 'basic'; for the third option, instead of
'enhanced' we could also use 'detailed' or 'extended'.


* * *

Wording attempt for the 'none' version. Something similar
could be done for 'minimal' but that's left to others.

------------------
-fopenmp-ompt
-fopenmp-ompt=none
-fopenmp-ompt=basic
-fopenmp-ompt=enhanced  // detailed, extended

Specify whether additional calls into the OpenMP runtime are generated
to improve tracing results with tools using the OMPT interface at the
expense of additional runtime overhead.  However, OMPT is also supported
without this option.

With -fopenmp-ompt=none, no additional calls are generated.

Using -fopenmp-ompt=basic, or just -fopenmp-ompt, the runtime is called
on region entry and exit instead of only on region entry for the single,
masked, and master constructs and with static scheduling for the
distribute and worksharing loop constructs.

The -fopenmp-ompt={enhanced,detailed,extended} (?) option includes the
additional calls of 'basic' and also issues events for the dispatch
callback with static scheduling for the distribute and worksharing loop
constructs.  The dispatch callback is invoked when beginning to execute
a section or a collapsed iteration in a taskloop or worksharing construct;
this option might have a measurable effect on the performance.

Requires-fopenmp.
------------------

Thanks,

Tobias

PS: I found a typo for 'begin(n)ing' in the current man page :-/
https://gcc.gnu.org/onlinedocs/gcc/OpenMP-and-OpenACC-Options.html#index-fopenmp-ompt
  

On 7/21/26 05:53, Tobias Burnus wrote:
> -fopenmp-ompt
> -fopenmp-ompt=none
> -fopenmp-ompt=basic
> -fopenmp-ompt=enhanced  // detailed, extended
> 
> Specify whether additional calls into the OpenMP runtime are generated
> to improve tracing results with tools using the OMPT interface at the
> expense of additional runtime overhead.  However, OMPT is also supported
> without this option.
> 
> With -fopenmp-ompt=none, no additional calls are generated.

My confusion about this option is:  additional to *what*?  Talking about 
additional runtime overhead makes it sound like it's an internal 
implementation detail and I don't think users are supposed to have to 
know what what features do or don't involve "additional" overhead.  So 
could we talk about what features are supported at each level first, and 
secondarily mention that the features at lower levels have less runtime 
overhead than those at higher levels?  Otherwise it seems like the tail 
is trying to wag the dog.

-Sandra
  

Sandra Loosemore wrote:
> On 7/21/26 05:53, Tobias Burnus wrote:
>> -fopenmp-ompt
>> -fopenmp-ompt=none
>> -fopenmp-ompt=basic
>> -fopenmp-ompt=enhanced  // detailed, extended
>>
>> Specify whether additional calls into the OpenMP runtime are generated
>> to improve tracing results with tools using the OMPT interface at the
>> expense of additional runtime overhead.  However, OMPT is also supported
>> without this option.
>>
>> With -fopenmp-ompt=none, no additional calls are generated.
>
> My confusion about this option is:  additional to *what*?

To what GCC generated by default for -fopenmp as required by the semantic.

For every call into the runtime, GCC can invoke a registered OMPT 
callback - and in most cases, a call into the runtime is already there.

In a very few cases, the compiler-generated code can do either without a 
call into the runtime or only has one at the beginning of a block of 
user code (beginning of a region) – and not also at the end.

That's perfectly fine, except that for tracing with OMPT, the additional 
data could be helpful. – See below for an example what -fopenmp-ompt 
does and when it might help with actual code.

* * *

Thus, 'additional' refers to additionally to what always generated for 
OpenMP code (i.e. with the bare -fopenmp).

BTW: Between the lines, the current documentation implies: If the 
construct you are interested is not listed here, it is already handled 
by -fopenmp itself. [Which is mostly true.]

* * *

> Talking about additional runtime overhead makes it sound like it's an 
> internal implementation detail and I don't think users are supposed to 
> have to know what what features do or don't involve "additional" overhead.

It _is_ an implementation detail. It is only for users that care about OMPT - and they
need to decide between better OMPT data vs. slower program.

And the documentation explicitly states for which constructs what additional data can
be produced - and contains a reminder that this does not come for free, esp. not the
'detailed' option.

NOTE: When tracing huge programs, users need to be pretty much aware what they want to
trace. This might involve turning on the tracing only for certain blocks of code or only
for specific events. - Tracing can make a program easily 10× slower and produce tens of
gigabytes of tracing data very quickly, even when already strictly limiting what one
tries to trace.

For small program: Just enabling everything with OMPT when using OMPT and disabling it
("overhead") otherwise works as well. In that case, a user doesn't need to know all
the glory details.

* * *

> So could we talk about what features are supported at each level 
> first, and secondarily mention that the features at lower levels have 
> less runtime overhead than those at higher levels?  Otherwise it seems 
> like the tail is trying to wag the dog.

But that's more or less what we do:


> Using -fopenmp-ompt=basic, or just -fopenmp-ompt,

(feature level)

> the runtime is called on region entry and exit instead
> of only on region entry

(namely, what feature is additionally provides)

> for the single, masked, and master constructs and with
> static scheduling for the distribute and worksharing loop constructs. 

(additional data: list of what constructs are exactly affected by this.)


But somewhere we need to tell the user what this flag does in general:

> Specify whether additional calls into the OpenMP runtime are generated
> to improve tracing results with tools using the OMPT interface

Namely: This is about OMPT – using this feature improves the tracing

And there are two notes related to "additional calls into the runtime":

(A) it has the downside that additional calls come

> at the expense of additional runtime overhead.

i.e. they make the program slower - and

(B)

> However, OMPT is also supported without this option.

is there to make clear: OMPT also works without that option,
even if the tracing with OMPT is nicer with the optiona that follow.

* * *

I am sure that it can be worded better – but I still have to see any proposal
on how to improve this.

Any suggestion?


Tobias

-----------------------------
PS: Example for -fopenmp-detail, in case it helps:

#pragma omp parallel  // start multiple threads
{
    ... // some work by all threads
    #omp masked filter(my_thread)
    {
        // some work only done by thread my_thread
    }
    ... // more work done by all threads
}

The masked construct is turned into:

if (GOMP_has_masked_thread_num (my_thread))
{
   ...
}


And the runtime issues (if a callback is registered) for this:
anompt_callback_masked with scope 'encountered' (scope_begin_end) and some 
additional data. Thus, the tracing tool could record: For Thread 
my_thread: * 0 to 2500 ms - some work
* at 2500 ms - masked event encountered
* 2500 ms to 10000 ms some work


While with -fopenmp-ompt, this is changed; namely,
a slightly different function is called ('_with_end')
and an additional function ('masked_end'):

if (GOMP_has_masked_thread_num_with_end (my_thread))
{
   ...
   GOMP_masked_end ();
}


which permits the tracing:

* 0 to 2500 ms - some work
* at 2500 ms - masked 'begin' event
*   some work
* at 2650 ms - masked 'end' event
* 2650 ms to 1000 ms some work

Thus with -fopenmp-ompt, the tool and, hence, the user knows that the
work done between t = 2500 ms and t' = 2650 ms happend in a 'masked'
region.

In many cases, a user does not care. However, if my_thread takes 25 %
longer than the other threads, those 127 threads will be idle for
2500 ms which is generally a bad idea - wasting 2.5 s × 127 theeads =
5½ CPU minutes on waiting just for a single thread instead of running
shorter or using making use of that compute power for something else.

That's a lot - hence, a user might want to investigate way - and an
obvious candidate is the 'masked' region as that contains code only
executed by my_thread.

Well, with -fopenmp, the user just sees a 'masked' region - which does
not help for this purpose. It is sufficient to see that my_thread takes
10000 ms - and that the other threads need about 7500 milliseconds
plus that there is 'masked' region.

With -fopenmp-ompt, the user sees that my_thread spends there
150 ms - but that's only 1.5 % of the total runtime - or 6 % of the time
that my_thread takes longer.

Thus, the user has to search elsewhere why my_thread takes 25 % longer
than the other threads.

That would be real-world scenario for the usage of OMPT - both for what
OMPT with -fopenmp already gives -and when -fopenmp-opmpt on top helps.


* * *

Maybe that helps you to understand the feature - and, hence,
helps you to come up with a better wording :-)
  

Sandra, Tobias, all,

On 21/07/2026 16:29, Sandra Loosemore wrote:
> On 7/21/26 05:53, Tobias Burnus wrote:
>> -fopenmp-ompt
>> -fopenmp-ompt=none
>> -fopenmp-ompt=basic
>> -fopenmp-ompt=enhanced  // detailed, extended
>>
>> Specify whether additional calls into the OpenMP runtime are generated
>> to improve tracing results with tools using the OMPT interface at the
>> expense of additional runtime overhead.  However, OMPT is also supported
>> without this option.
>>
>> With -fopenmp-ompt=none, no additional calls are generated.
> 
> My confusion about this option is:  additional to *what*?  Talking about 
> additional runtime overhead makes it sound like it's an internal 
> implementation detail and I don't think users are supposed to have to 
> know what what features do or don't involve "additional" overhead.  So 
> could we talk about what features are supported at each level first, and 
> secondarily mention that the features at lower levels have less runtime 
> overhead than those at higher levels?  Otherwise it seems like the tail 
> is trying to wag the dog.
Here is a new proposition based on previous messages in this thread. 
What do you think?

@opindex fopenmp-ompt
@cindex OpenMP OMPT
@item -fopenmp-ompt
@itemx -fopenmp-ompt=@var{level}
Control how much detail GCC reports to an @dfn{OMPT} tool -- a tool
that registers callbacks with the OpenMP runtime to observe events
such as when a parallel region or worksharing construct starts and
ends.  The @var{level} argument is one of @code{minimal}, @code{basic},
or @code{extended}; @option{-fopenmp-ompt} without an argument is
equivalent to @option{-fopenmp-ompt=basic}.  OMPT support itself is
always present with @option{-fopenmp}; this option only changes how
much is reported and at what runtime cost.  Requires
@option{-fopenmp}.

@table @code
@item minimal
The level used when @option{-fopenmp-ompt} is not specified.  Some
OpenMP constructs are reported to an OMPT tool as a single combined
``encountered'' event, so a tool cannot tell how long the construct's
region actually ran.  No extra runtime calls are generated beyond
what the construct's semantics already require.

@item basic
For the @code{single}, @code{masked}, and @code{master} constructs,
and for @code{distribute} and worksharing-loop (@code{for}/@code{do})
constructs that use static scheduling, GCC instead reports a separate
``begin'' event when the region is entered and an ``end'' event when
it is left.  This lets an OMPT tool measure the time actually spent in
those regions, at the cost of one extra runtime call per region.

@item extended
In addition to what @code{basic} reports, report a ``dispatch'' event
each time a new chunk of loop iterations begins within a statically
scheduled @code{distribute} or worksharing-loop construct (a
@dfn{chunk} is the contiguous run of iterations handed to one thread
or team at a time).  This lets an OMPT tool see how work is actually
split across threads, but adds a runtime call for every chunk, which
can be measurably slower for loops with many small chunks.
@end table

There is no @option{-fno-openmp-ompt}: the lowest available level is
@option{-fopenmp-ompt=minimal}, since OMPT support cannot be disabled
outright once @option{-fopenmp} is in effect.
  

On 8/11/26 02:52, Paul-Antoine Arras wrote:
> Sandra, Tobias, all,
> 
> On 21/07/2026 16:29, Sandra Loosemore wrote:
>> On 7/21/26 05:53, Tobias Burnus wrote:
>>> -fopenmp-ompt
>>> -fopenmp-ompt=none
>>> -fopenmp-ompt=basic
>>> -fopenmp-ompt=enhanced  // detailed, extended
>>>
>>> Specify whether additional calls into the OpenMP runtime are generated
>>> to improve tracing results with tools using the OMPT interface at the
>>> expense of additional runtime overhead.  However, OMPT is also supported
>>> without this option.
>>>
>>> With -fopenmp-ompt=none, no additional calls are generated.
>>
>> My confusion about this option is:  additional to *what*?  Talking 
>> about additional runtime overhead makes it sound like it's an internal 
>> implementation detail and I don't think users are supposed to have to 
>> know what what features do or don't involve "additional" overhead.  So 
>> could we talk about what features are supported at each level first, 
>> and secondarily mention that the features at lower levels have less 
>> runtime overhead than those at higher levels?  Otherwise it seems like 
>> the tail is trying to wag the dog.
> Here is a new proposition based on previous messages in this thread. 
> What do you think?

This is much better.  I have only a few markup complaints.

> 
> @opindex fopenmp-ompt
> @cindex OpenMP OMPT
> @item -fopenmp-ompt
> @itemx -fopenmp-ompt=@var{level}
> Control how much detail GCC reports to an @dfn{OMPT} tool -- a tool

In Texinfo an em-dash is specified as three dashes with no space on 
either side, like "...tool---a tool..." here.

> that registers callbacks with the OpenMP runtime to observe events
> such as when a parallel region or worksharing construct starts and
> ends.  The @var{level} argument is one of @code{minimal}, @code{basic},

I think @samp{} markup is preferred to @code{} for these keywords.

> or @code{extended}; @option{-fopenmp-ompt} without an argument is
> equivalent to @option{-fopenmp-ompt=basic}.  OMPT support itself is
> always present with @option{-fopenmp}; this option only changes how
> much is reported and at what runtime cost.  Requires
> @option{-fopenmp}.
> 
> @table @code

Likewise in the @table.

> @item minimal
> The level used when @option{-fopenmp-ompt} is not specified.  Some
> OpenMP constructs are reported to an OMPT tool as a single combined
> ``encountered'' event, so a tool cannot tell how long the construct's
> region actually ran.  No extra runtime calls are generated beyond
> what the construct's semantics already require.
> 
> @item basic
> For the @code{single}, @code{masked}, and @code{master} constructs,
> and for @code{distribute} and worksharing-loop (@code{for}/@code{do})
> constructs that use static scheduling, GCC instead reports a separate
> ``begin'' event when the region is entered and an ``end'' event when
> it is left.  This lets an OMPT tool measure the time actually spent in
> those regions, at the cost of one extra runtime call per region.
> 
> @item extended
> In addition to what @code{basic} reports, report a ``dispatch'' event

And @samp{basic} here too.

> each time a new chunk of loop iterations begins within a statically
> scheduled @code{distribute} or worksharing-loop construct (a
> @dfn{chunk} is the contiguous run of iterations handed to one thread
> or team at a time).  This lets an OMPT tool see how work is actually
> split across threads, but adds a runtime call for every chunk, which
> can be measurably slower for loops with many small chunks.
> @end table
> 
> There is no @option{-fno-openmp-ompt}: the lowest available level is
> @option{-fopenmp-ompt=minimal}, since OMPT support cannot be disabled
> outright once @option{-fopenmp} is in effect.
> 

-Sandra
  

Sandra Loosemore wrote:
> On 8/11/26 02:52, Paul-Antoine Arras wrote:
>> Sandra, Tobias, all,
>>
>> On 21/07/2026 16:29, Sandra Loosemore wrote:
>>> On 7/21/26 05:53, Tobias Burnus wrote:
>>>> -fopenmp-ompt
>>>> -fopenmp-ompt=none
>>>> -fopenmp-ompt=basic
>>>> -fopenmp-ompt=enhanced  // detailed, extended
...
> This is much better.  I have only a few markup complaints. 

Works also for me – now besides those, also the *.opt file needs to be 
updated + .url regenerated, I'd guess.

Tobias
  

On 11/08/2026 22:05, Tobias Burnus wrote:
> Sandra Loosemore wrote:
>> On 8/11/26 02:52, Paul-Antoine Arras wrote:
>>> Sandra, Tobias, all,
>>>
>>> On 21/07/2026 16:29, Sandra Loosemore wrote:
>>>> On 7/21/26 05:53, Tobias Burnus wrote:
>>>>> -fopenmp-ompt
>>>>> -fopenmp-ompt=none
>>>>> -fopenmp-ompt=basic
>>>>> -fopenmp-ompt=enhanced  // detailed, extended
> ...
>> This is much better.  I have only a few markup complaints. 
> 
> Works also for me – now besides those, also the *.opt file needs to be 
> updated + .url regenerated, I'd guess.

Here is a patch with the new levelled option implementation, updated 
documentation, tests and comments.

Thanks,
  

On 8/12/26 06:22, Paul-Antoine Arras wrote:
> On 11/08/2026 22:05, Tobias Burnus wrote:
>> Sandra Loosemore wrote:
>>> On 8/11/26 02:52, Paul-Antoine Arras wrote:
>>>> Sandra, Tobias, all,
>>>>
>>>> On 21/07/2026 16:29, Sandra Loosemore wrote:
>>>>> On 7/21/26 05:53, Tobias Burnus wrote:
>>>>>> -fopenmp-ompt
>>>>>> -fopenmp-ompt=none
>>>>>> -fopenmp-ompt=basic
>>>>>> -fopenmp-ompt=enhanced  // detailed, extended
>> ...
>>> This is much better.  I have only a few markup complaints. 
>>
>> Works also for me – now besides those, also the *.opt file needs to be 
>> updated + .url regenerated, I'd guess.
> 
> Here is a patch with the new levelled option implementation, updated 
> documentation, tests and comments.

This looks fine to me.  Technically I can only approve the documentation 
changes, help strings, comments, and error message wording -- but I 
think we already have consensus on changing the user interface in this 
way and the remaining changes are "obvious" with that in mind.  Maybe 
wait another day before pushing in case anybody else with more powerful 
maintainer-fu wants to review it too.

-Sandra