On 29.10.21 18:47, Jakub Jelinek wrote:
Or we can keep 3 sections and say that the first one is for the
calls on the library side without suffixes and second is for those with
no and _ suffixes, but that in DECL_NAME those don't make a difference.
That's what I have now done.
+ &&
On Fri, Oct 29, 2021 at 05:54:57PM +0200, Tobias Burnus wrote:
> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -3926,8 +3926,9 @@ omp_runtime_api_call (const_tree fndecl)
>
>static const char *omp_runtime_apis[] =
> {
> - /* This array has 3 sections. First omp_* calls that don't
On 29.10.21 12:53, Jakub Jelinek wrote:
On Fri, Oct 29, 2021 at 12:09:55PM +0200, Tobias Burnus wrote:
[...] only routines calls to
omp_get_num_teams() and omp_get_team_num()
are permitted in teams when closely nested.
I'm afraid using DECL_ASSEMBLER_NAME opens a new can of worms. [...]
At l
On Fri, Oct 29, 2021 at 12:09:55PM +0200, Tobias Burnus wrote:
> The original motivation was to fix the routine part
> of the restriction quoted below. Namely that the only
> routines calls to
> omp_get_num_teams() and omp_get_team_num()
> are permitted in teams when closely nested.
>
>
> "Rest
The original motivation was to fix the routine part
of the restriction quoted below. Namely that the only
routines calls to
omp_get_num_teams() and omp_get_team_num()
are permitted in teams when closely nested.
"Restrictions to the teams construct are as follows:
...
• distribute regions, incl
