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, including any distribute regions arising from composite constructs,
parallel regions, including any parallel regions arising from combined constructs, loop
regions, omp_get_num_teams() regions, and omp_get_team_num() regions are the
only OpenMP regions that may be strictly nested inside the teams region."


While being there, I found one issue related to the ancestor
check – which checked too strictly – and in the generic check
which assumed that the DECL_NAME in Fortran had the '_' suffix
while only the assembler name has.

That worked well with '_' as DECL_NAME then matched the C name
but for the integer(8) version, only ..._8_ was matched and
DECL_NAME only contained ..._8 without tailing '_'.

The assembler name is also needed because in Fortran,
  module m
  contains
    subroutine omp_is_initial_device ()
has an OpenMP API name in DECL_NAME but internally, it is
something like m_MOD_omp_is_initial_device_ - which is an
odd user name but is not the API routine name.

I hope that no target starts mangling the C name such that
C's DECL_NAME() != the assembler name as then the patch
will break, but I think all targets do permit those simple
names and don't introduce further mangling.


While other testsuites had surprisingly little problems with
this change – most did use omp_get_num_teams() and
omp_get_team_num() but that's fine - the GCC testsuite did
have many violations. — I hoped I have fixed them in a
sensible way.


OK for mainline?

Tobias
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955