is there a way to find out gfortran version and/or options from a given binary?

[Kay Diederichs]

Hi,

is there any gfortran option and/or version information available from/in a 
binary? Maybe accessible with objdump or strings?

For ifort, we use the -sox option ("This option tells the compiler to save the 
compilation options and version number in the executable file. ..."). This enables 
e.g.
strings /path/to/binary | grep Intel

Or is there a gfortran option that makes this accessible in a binary?

Thanks,
Kay

Re: is there a way to find out gfortran version and/or options from a given binary?

[Arjen Markus via Fortran]

Are you perhaps looking for the compiler_version() and compiler_options()
functions? I use them like this, they were defined in Fortran 2008 if I am
not mistaken:


WRITE( lurep, '(a)' ) 'Report of simulation'
WRITE( lurep, '(a)' ) ''
WRITE( lurep, '(a)' ) 'Compiler version: ',
compiler_version()
WRITE( lurep, '(a)' ) 'Compiler options: ',
compiler_options()

Regards,

Arjen

Op wo 1 jun. 2022 om 10:42 schreef Kay Diederichs <
kay.diederi...@uni-konstanz.de>:

> Hi,
>
> is there any gfortran option and/or version information available from/in
> a binary? Maybe accessible with objdump or strings?
>
> For ifort, we use the -sox option ("This option tells the compiler to save
> the compilation options and version number in the executable file. ...").
> This enables e.g.
> strings /path/to/binary | grep Intel
>
> Or is there a gfortran option that makes this accessible in a binary?
>
> Thanks,
> Kay
>
>
>

Re: is there a way to find out gfortran version and/or options from a given binary?

[Kay Diederichs]

Hi Arjen,

thanks for your answer. I do know about these functions, and use them in my own 
programs if appropriate. However, programs
distributed to others for production use should not output this because it confuses users 
(as does "Note: The following floating-point exceptions are signalling: 
IEEE_INVALID_FLAG" which I need to switch off with -ffpe-summary=none).

So I really am looking for strings or other type of info in the binary.

Best wishes,
Kay

On 6/1/22 11:30, Arjen Markus wrote:

Are you perhaps looking for the compiler_version() and compiler_options() 
functions? I use them like this, they were defined in Fortran 2008 if I am not 
mistaken:


                 WRITE( lurep, '(a)' ) 'Report of simulation'
                 WRITE( lurep, '(a)' ) ''
                 WRITE( lurep, '(a)' ) 'Compiler version: ', compiler_version()
                 WRITE( lurep, '(a)' ) 'Compiler options: ', compiler_options()

Regards,

Arjen

Op wo 1 jun. 2022 om 10:42 schreef Kay Diederichs mailto:kay.diederi...@uni-konstanz.de>>:

Hi,

is there any gfortran option and/or version information available from/in a 
binary? Maybe accessible with objdump or strings?

For ifort, we use the -sox option ("This option tells the compiler to save the 
compilation options and version number in the executable file. ..."). This enables 
e.g.
strings /path/to/binary | grep Intel

Or is there a gfortran option that makes this accessible in a binary?

Thanks,
Kay




--
Kay Diederichshttp://strucbio.biologie.uni-konstanz.de
email: kay.diederi...@uni-konstanz.de Tel +49 7531 88 4049
Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz

This e-mail is digitally signed. If your e-mail client does not have the
necessary capabilities, just ignore the attached signature "smime.p7s".


smime.p7s
Description: S/MIME Cryptographic Signature

Re: is there a way to find out gfortran version and/or options from a given binary?

[Andre Vehreschild via Fortran]

Hi Kay,

did you try:

$ strings coarray_collectives_18 | grep  GNU
GCC: (GNU) 11.2.1 20211203 (Red Hat 11.2.1-7)
GCC: (GNU) 12.0.1 20220214 (experimental)
GNU Fortran2008 12.0.1 20220214 (experimental) -mtune=generic -march=x86-64 -g
-fcoarray=lib -fintrinsic-modules-path
/home/vehre/Projekte/gcc/gfortran/lib/gcc/x86_64-pc-linux-gnu/12.0.1/finclude
-fpre-include=/usr/include/finclude/math-vector-fortran.h GNU C11 12.0.1
20220214 (experimental) -mshstk -mtune=generic -march=x86-64 -g -O2 -O0
-std=gnu11 -fcf-protection=full -fcx-fortran-rules -ffunction-sections
-fdata-sections __GNU_EH_FRAME_HDR

or

strings coarray_collectives_18 | grep GCC

...
? 

Both give me some output (albeit more than I desire) for an executable compiled
with gfortran. But presumably, I had activated debug. I don't know, if
optimized builds will have it, too.

Regards,
Andre

On Wed, 1 Jun 2022 11:41:41 +0200
Kay Diederichs  wrote:

> Hi Arjen,
> 
> thanks for your answer. I do know about these functions, and use them in my
> own programs if appropriate. However, programs distributed to others for
> production use should not output this because it confuses users (as does
> "Note: The following floating-point exceptions are signalling:
> IEEE_INVALID_FLAG" which I need to switch off with -ffpe-summary=none).
> 
> So I really am looking for strings or other type of info in the binary.
> 
> Best wishes,
> Kay
> 
> On 6/1/22 11:30, Arjen Markus wrote:
> > Are you perhaps looking for the compiler_version() and compiler_options()
> > functions? I use them like this, they were defined in Fortran 2008 if I am
> > not mistaken:
> > 
> > 
> >                  WRITE( lurep, '(a)' ) 'Report of simulation'
> >                  WRITE( lurep, '(a)' ) ''
> >                  WRITE( lurep, '(a)' ) 'Compiler version: ',
> > compiler_version() WRITE( lurep, '(a)' ) 'Compiler options: ',
> > compiler_options()
> > 
> > Regards,
> > 
> > Arjen
> > 
> > Op wo 1 jun. 2022 om 10:42 schreef Kay Diederichs
> > mailto:kay.diederi...@uni-konstanz.de>>:
> > 
> > Hi,
> > 
> > is there any gfortran option and/or version information available
> > from/in a binary? Maybe accessible with objdump or strings?
> > 
> > For ifort, we use the -sox option ("This option tells the compiler to
> > save the compilation options and version number in the executable file.
> > ..."). This enables e.g. strings /path/to/binary | grep Intel
> > 
> > Or is there a gfortran option that makes this accessible in a binary?
> > 
> > Thanks,
> > Kay
> > 
> >   
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: is there a way to find out gfortran version and/or options from a given binary?

[Arjen Markus via Fortran]

I thought you might get this information by using these two functions in a
parameter definition, but that is not allowed, alas.

Regards,

Arjen


Op wo 1 jun. 2022 om 11:50 schreef Andre Vehreschild via Fortran <
fortran@gcc.gnu.org>:

> Hi Kay,
>
> did you try:
>
> $ strings coarray_collectives_18 | grep  GNU
> GCC: (GNU) 11.2.1 20211203 (Red Hat 11.2.1-7)
> GCC: (GNU) 12.0.1 20220214 (experimental)
> GNU Fortran2008 12.0.1 20220214 (experimental) -mtune=generic
> -march=x86-64 -g
> -fcoarray=lib -fintrinsic-modules-path
>
> /home/vehre/Projekte/gcc/gfortran/lib/gcc/x86_64-pc-linux-gnu/12.0.1/finclude
> -fpre-include=/usr/include/finclude/math-vector-fortran.h GNU C11 12.0.1
> 20220214 (experimental) -mshstk -mtune=generic -march=x86-64 -g -O2 -O0
> -std=gnu11 -fcf-protection=full -fcx-fortran-rules -ffunction-sections
> -fdata-sections __GNU_EH_FRAME_HDR
>
> or
>
> strings coarray_collectives_18 | grep GCC
>
> ...
> ?
>
> Both give me some output (albeit more than I desire) for an executable
> compiled
> with gfortran. But presumably, I had activated debug. I don't know, if
> optimized builds will have it, too.
>
> Regards,
> Andre
>
> On Wed, 1 Jun 2022 11:41:41 +0200
> Kay Diederichs  wrote:
>
> > Hi Arjen,
> >
> > thanks for your answer. I do know about these functions, and use them in
> my
> > own programs if appropriate. However, programs distributed to others for
> > production use should not output this because it confuses users (as does
> > "Note: The following floating-point exceptions are signalling:
> > IEEE_INVALID_FLAG" which I need to switch off with -ffpe-summary=none).
> >
> > So I really am looking for strings or other type of info in the binary.
> >
> > Best wishes,
> > Kay
> >
> > On 6/1/22 11:30, Arjen Markus wrote:
> > > Are you perhaps looking for the compiler_version() and
> compiler_options()
> > > functions? I use them like this, they were defined in Fortran 2008 if
> I am
> > > not mistaken:
> > >
> > >
> > >  WRITE( lurep, '(a)' ) 'Report of simulation'
> > >  WRITE( lurep, '(a)' ) ''
> > >  WRITE( lurep, '(a)' ) 'Compiler version: ',
> > > compiler_version() WRITE( lurep, '(a)' ) 'Compiler options: ',
> > > compiler_options()
> > >
> > > Regards,
> > >
> > > Arjen
> > >
> > > Op wo 1 jun. 2022 om 10:42 schreef Kay Diederichs
> > > mailto:kay.diederi...@uni-konstanz.de
> >>:
> > >
> > > Hi,
> > >
> > > is there any gfortran option and/or version information available
> > > from/in a binary? Maybe accessible with objdump or strings?
> > >
> > > For ifort, we use the -sox option ("This option tells the compiler
> to
> > > save the compilation options and version number in the executable file.
> > > ..."). This enables e.g. strings /path/to/binary | grep Intel
> > >
> > > Or is there a gfortran option that makes this accessible in a
> binary?
> > >
> > > Thanks,
> > > Kay
> > >
> > >
> >
>
>
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
>

Re: is there a way to find out gfortran version and/or options from a given binary?

[Arjen Markus via Fortran]

Well, if you call these functions in the code, the text is available in the
executable file. I used:

! staticv.f90 --
! Static information about the compiler? Not via parameters
!
program staticv
use iso_fortran_env

implicit none
character(len=200) :: c, d

c = compiler_version()
d = compiler_options()
write(*,*) c(1:1), d(1:)1
end program staticv

to force the text strings to appear. I think a long character string is
required.

Regards,

Arjen

Op wo 1 jun. 2022 om 11:53 schreef Arjen Markus :

> I thought you might get this information by using these two functions in a
> parameter definition, but that is not allowed, alas.
>
> Regards,
>
> Arjen
>
>
> Op wo 1 jun. 2022 om 11:50 schreef Andre Vehreschild via Fortran <
> fortran@gcc.gnu.org>:
>
>> Hi Kay,
>>
>> did you try:
>>
>> $ strings coarray_collectives_18 | grep  GNU
>> GCC: (GNU) 11.2.1 20211203 (Red Hat 11.2.1-7)
>> GCC: (GNU) 12.0.1 20220214 (experimental)
>> GNU Fortran2008 12.0.1 20220214 (experimental) -mtune=generic
>> -march=x86-64 -g
>> -fcoarray=lib -fintrinsic-modules-path
>>
>> /home/vehre/Projekte/gcc/gfortran/lib/gcc/x86_64-pc-linux-gnu/12.0.1/finclude
>> -fpre-include=/usr/include/finclude/math-vector-fortran.h GNU C11 12.0.1
>> 20220214 (experimental) -mshstk -mtune=generic -march=x86-64 -g -O2 -O0
>> -std=gnu11 -fcf-protection=full -fcx-fortran-rules -ffunction-sections
>> -fdata-sections __GNU_EH_FRAME_HDR
>>
>> or
>>
>> strings coarray_collectives_18 | grep GCC
>>
>> ...
>> ?
>>
>> Both give me some output (albeit more than I desire) for an executable
>> compiled
>> with gfortran. But presumably, I had activated debug. I don't know, if
>> optimized builds will have it, too.
>>
>> Regards,
>> Andre
>>
>> On Wed, 1 Jun 2022 11:41:41 +0200
>> Kay Diederichs  wrote:
>>
>> > Hi Arjen,
>> >
>> > thanks for your answer. I do know about these functions, and use them
>> in my
>> > own programs if appropriate. However, programs distributed to others for
>> > production use should not output this because it confuses users (as does
>> > "Note: The following floating-point exceptions are signalling:
>> > IEEE_INVALID_FLAG" which I need to switch off with -ffpe-summary=none).
>> >
>> > So I really am looking for strings or other type of info in the binary.
>> >
>> > Best wishes,
>> > Kay
>> >
>> > On 6/1/22 11:30, Arjen Markus wrote:
>> > > Are you perhaps looking for the compiler_version() and
>> compiler_options()
>> > > functions? I use them like this, they were defined in Fortran 2008 if
>> I am
>> > > not mistaken:
>> > >
>> > >
>> > >  WRITE( lurep, '(a)' ) 'Report of simulation'
>> > >  WRITE( lurep, '(a)' ) ''
>> > >  WRITE( lurep, '(a)' ) 'Compiler version: ',
>> > > compiler_version() WRITE( lurep, '(a)' ) 'Compiler options: ',
>> > > compiler_options()
>> > >
>> > > Regards,
>> > >
>> > > Arjen
>> > >
>> > > Op wo 1 jun. 2022 om 10:42 schreef Kay Diederichs
>> > > > kay.diederi...@uni-konstanz.de>>:
>> > >
>> > > Hi,
>> > >
>> > > is there any gfortran option and/or version information available
>> > > from/in a binary? Maybe accessible with objdump or strings?
>> > >
>> > > For ifort, we use the -sox option ("This option tells the
>> compiler to
>> > > save the compilation options and version number in the executable
>> file.
>> > > ..."). This enables e.g. strings /path/to/binary | grep Intel
>> > >
>> > > Or is there a gfortran option that makes this accessible in a
>> binary?
>> > >
>> > > Thanks,
>> > > Kay
>> > >
>> > >
>> >
>>
>>
>> --
>> Andre Vehreschild * Email: vehre ad gmx dot de
>>
>

Re: is there a way to find out gfortran version and/or options from a given binary?

[Kay Diederichs]

I tried your suggestion below, but it does not store the options unless 
the -g option is used.


If -g is used, the executable _always_ has version and option info (no 
extra code invoking compiler_version() and compiler_options() is 
needed). Just use strings  | grep GNU .

If -g is not used, no option info is in the executable.

Best wishes,
Kay

On 01.06.22 12:00, Arjen Markus wrote:

staticv.f90 --
!     Static information about the compiler? Not via parameters
!
program staticv
     use iso_fortran_env

     implicit none
     character(len=200) :: c, d

     c = compiler_version()
     d = compiler_options()
     write(*,*) c(1:1), d(1:)1
end program staticv



--
Kay Diederichshttp://strucbio.biologie.uni-konstanz.de
email: kay.diederi...@uni-konstanz.de Tel +49 7531 88 4049
Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz

This e-mail is digitally signed. If your e-mail client does not have the
necessary capabilities, just ignore the attached signature "smime.p7s".


smime.p7s
Description: S/MIME Cryptographic Signature

Re: is there a way to find out gfortran version and/or options from a given binary?

[Arjen Markus via Fortran]

Hm, I ran it without any options - would that be equivalent to -g then? A
rather awkward workaround might be to compile one source file containing
this code with -g, but that is pushing things to the limit.

Regards,

Arjen

Op wo 1 jun. 2022 om 12:16 schreef Kay Diederichs <
kay.diederi...@uni-konstanz.de>:

> I tried your suggestion below, but it does not store the options unless
> the -g option is used.
>
> If -g is used, the executable _always_ has version and option info (no
> extra code invoking compiler_version() and compiler_options() is
> needed). Just use strings  | grep GNU .
> If -g is not used, no option info is in the executable.
>
> Best wishes,
> Kay
>
> On 01.06.22 12:00, Arjen Markus wrote:
> > staticv.f90 --
> > ! Static information about the compiler? Not via parameters
> > !
> > program staticv
> >  use iso_fortran_env
> >
> >  implicit none
> >  character(len=200) :: c, d
> >
> >  c = compiler_version()
> >  d = compiler_options()
> >  write(*,*) c(1:1), d(1:)1
> > end program staticv
> >
>
> --
> Kay Diederichshttp://strucbio.biologie.uni-konstanz.de
> email: kay.diederi...@uni-konstanz.de Tel +49 7531 88 4049
> Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz
>
> This e-mail is digitally signed. If your e-mail client does not have the
> necessary capabilities, just ignore the attached signature "smime.p7s".
>

Re: is there a way to find out gfortran version and/or options from a given binary?

[Arjen Markus via Fortran]

Are you sure that -g is the trigger? It may very well be that you need to
make sure that the optimiser does not eliminate the variable that holds the
identification. That is why I write the first character of these strings,
to make sure that the variables are retained. That could be achieved in all
manner of ways to fool the optimiser. Note that with -O2 and the program I
posted I still get the strings.

Regards,

Arjen

Op wo 1 jun. 2022 om 13:36 schreef Arjen Markus :

> Hm, I ran it without any options - would that be equivalent to -g then? A
> rather awkward workaround might be to compile one source file containing
> this code with -g, but that is pushing things to the limit.
>
> Regards,
>
> Arjen
>
> Op wo 1 jun. 2022 om 12:16 schreef Kay Diederichs <
> kay.diederi...@uni-konstanz.de>:
>
>> I tried your suggestion below, but it does not store the options unless
>> the -g option is used.
>>
>> If -g is used, the executable _always_ has version and option info (no
>> extra code invoking compiler_version() and compiler_options() is
>> needed). Just use strings  | grep GNU .
>> If -g is not used, no option info is in the executable.
>>
>> Best wishes,
>> Kay
>>
>> On 01.06.22 12:00, Arjen Markus wrote:
>> > staticv.f90 --
>> > ! Static information about the compiler? Not via parameters
>> > !
>> > program staticv
>> >  use iso_fortran_env
>> >
>> >  implicit none
>> >  character(len=200) :: c, d
>> >
>> >  c = compiler_version()
>> >  d = compiler_options()
>> >  write(*,*) c(1:1), d(1:)1
>> > end program staticv
>> >
>>
>> --
>> Kay Diederichshttp://strucbio.biologie.uni-konstanz.de
>> email: kay.diederi...@uni-konstanz.de Tel +49 7531 88 4049
>> Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz
>>
>> This e-mail is digitally signed. If your e-mail client does not have the
>> necessary capabilities, just ignore the attached signature "smime.p7s".
>>
>

Re: is there a way to find out gfortran version and/or options from a given binary?

[Kay Diederichs]

Hi Arjen,

below is what I get with gfortran 11.2.1 and no options, or just -g:

[dikay@turn29]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/scratch/opt/rh/devtoolset-11/root/usr/bin/../libexec/gcc/x86_64-redhat-linux/11/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap 
--enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-11/root/usr 
--mandir=/opt/rh/devtoolset-11/root/usr/share/man 
--infodir=/opt/rh/devtoolset-11/root/usr/share/info 
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared 
--enable-threads=posix --enable-checking=release --enable-multilib 
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions 
--enable-gnu-unique-object --enable-linker-build-id 
--with-gcc-major-version-only --with-linker-hash-style=gnu 
--with-default-libstdcxx-abi=gcc4-compatible --enable-plugin 
--enable-initfini-array 
--with-isl=/builddir/build/BUILD/gcc-11.2.1-20210728/obj-x86_64-redhat-linux/isl-install
 --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 
--build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.1 20210728 (Red Hat 11.2.1-1) (GCC)
[dikay@turn29]$ cat staticv.f90
! staticv.f90 --
! Static information about the compiler? Not via parameters
!
program staticv
use iso_fortran_env

implicit none
character(len=200) :: c, d

c = compiler_version()
d = compiler_options()
write(*,*) c(1:1), d(1:1)
end program staticv


[dikay@turn29]$ gfortran staticv.f90
[dikay@turn29]$ strings a.out | grep GNU
GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-44)
GCC: (GNU) 11.2.1 20210728 (Red Hat 11.2.1-1)
__GNU_EH_FRAME_HDR

[dikay@turn29]$ gfortran staticv.f90
[dikay@turn29]$ strings a.out | grep GNU
GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-44)
GCC: (GNU) 11.2.1 20210728 (Red Hat 11.2.1-1)
__GNU_EH_FRAME_HDR
[dikay@turn29]$ gfortran -g staticv.f90
[dikay@turn29]$ strings a.out | grep GNU
GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-44)
GCC: (GNU) 11.2.1 20210728 (Red Hat 11.2.1-1)
GNU Fortran2008 11.2.1 20210728 (Red Hat 11.2.1-1) -mtune=generic -march=x86-64 
-g -fintrinsic-modules-path 
/scratch/opt/rh/devtoolset-11/root/usr/bin/../lib/gcc/x86_64-redhat-linux/11/finclude
__GNU_EH_FRAME_HDR

Best wishes,
Kay



On 6/1/22 13:46, Arjen Markus wrote:

Are you sure that -g is the trigger? It may very well be that you need to make 
sure that the optimiser does not eliminate the variable that holds the 
identification. That is why I write the first character of these strings, to 
make sure that the variables are retained. That could be achieved in all manner 
of ways to fool the optimiser. Note that with -O2 and the program I posted I 
still get the strings.

Regards,

Arjen

Op wo 1 jun. 2022 om 13:36 schreef Arjen Markus mailto:arjen.markus...@gmail.com>>:

Hm, I ran it without any options - would that be equivalent to -g then? A 
rather awkward workaround might be to compile one source file containing this 
code with -g, but that is pushing things to the limit.

Regards,

Arjen

Op wo 1 jun. 2022 om 12:16 schreef Kay Diederichs mailto:kay.diederi...@uni-konstanz.de>>:

I tried your suggestion below, but it does not store the options unless
the -g option is used.

If -g is used, the executable _always_ has version and option info (no
extra code invoking compiler_version() and compiler_options() is
needed). Just use strings  | grep GNU .
If -g is not used, no option info is in the executable.

Best wishes,
Kay

On 01.06.22 12:00, Arjen Markus wrote:
 > staticv.f90 --
 > !     Static information about the compiler? Not via parameters
 > !
 > program staticv
 >      use iso_fortran_env
 >
 >      implicit none
 >      character(len=200) :: c, d
 >
 >      c = compiler_version()
 >      d = compiler_options()
 >      write(*,*) c(1:1), d(1:)1
 > end program staticv
 >

-- 
Kay Diederichs http://strucbio.biologie.uni-konstanz.de 

email: kay.diederi...@uni-konstanz.de 
             Tel +49 7531 88 4049
Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz

This e-mail is digitally signed. If your e-mail client does not have the
necessary capabilities, just ignore the attached signature "smime.p7s".



--
Kay Diederichshttp://strucbio.biologie.uni-konstanz.de
email: kay.diederi...@uni-konstanz.de Tel +49 7531 88 4049
Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz

This e-mail is digitally signed. If your e-mail client does not have the
necessary capabilities, just ignore the attached signature "smime.p7s".


smime.p7s
Description: S/MIME C

Re: is there a way to find out gfortran version and/or options from a given binary?

[Arjen Markus via Fortran]

Hm, I was using a file viewer, not strings to examine the file and I looked
for the text "GCC". That must be the difference. Indeed, strings does not
show that string nor any string containing "GCC"

Here is a small part of the text in the file (compiled without -O2, as with
it some characters appear mangled):

  GCC version 10.2.0-mtune=generic -march=x86-64staticv.f90   D  ÿ
Trace/breakpoint trap SIGTRAP Terminal quit signal

Regards,

Arjen

[PATCH 0/6] OpenMP 5.0: Fortran "declare mapper" support

[Julian Brown]

This patch series implements "declare mapper" support for Fortran,
following on from the C and C++ support for same in the currently
in-review series posted here:

  https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591973.html

Further commentary on individual patches. Tested with offloading to NVPTX.

OK? (Pending rework of the patch series it depends on?)

Thanks,

Julian

Julian Brown (6):
  Fortran: Typo/unicode-o fixes
  OpenMP: Templatize omp_mapper_list
  OpenMP: Rename strip_components_and_deref to omp_get_root_term
  OpenMP: Tweak NOP handling in in omp_get_root_term and
accumulate_sibling_list
  OpenMP: Pointers and member mappings
  OpenMP: Fortran "!$omp declare mapper" support

 gcc/c-family/c-common.h   |   4 +-
 gcc/c-family/c-omp.cc |   2 +-
 gcc/c/c-decl.cc   |   6 +-
 gcc/cp/semantics.cc   |   8 +-
 gcc/fortran/dump-parse-tree.cc|   5 +-
 gcc/fortran/f95-lang.cc   |   7 +
 gcc/fortran/gfortran.h|  55 +-
 gcc/fortran/match.cc  |   8 +-
 gcc/fortran/match.h   |   1 +
 gcc/fortran/module.cc | 252 +-
 gcc/fortran/openmp.cc | 296 ++-
 gcc/fortran/parse.cc  |   9 +-
 gcc/fortran/resolve.cc|   2 +
 gcc/fortran/st.cc |   2 +-
 gcc/fortran/symbol.cc |  16 +
 gcc/fortran/trans-decl.cc |  30 +-
 gcc/fortran/trans-openmp.cc   | 778 +-
 gcc/fortran/trans-stmt.h  |   1 +
 gcc/fortran/trans.h   |   3 +
 gcc/gimplify.cc   | 422 --
 gcc/omp-general.h |  32 +-
 .../gfortran.dg/gomp/declare-mapper-1.f90 |  71 ++
 .../gfortran.dg/gomp/declare-mapper-14.f90|  26 +
 .../gfortran.dg/gomp/declare-mapper-16.f90|  22 +
 .../gfortran.dg/gomp/declare-mapper-5.f90 |  45 +
 gcc/tree-pretty-print.cc  |   3 +
 include/gomp-constants.h  |   5 +-
 .../libgomp.fortran/declare-mapper-10.f90 |  40 +
 .../libgomp.fortran/declare-mapper-11.f90 |  38 +
 .../libgomp.fortran/declare-mapper-12.f90 |  33 +
 .../libgomp.fortran/declare-mapper-13.f90 |  49 ++
 .../libgomp.fortran/declare-mapper-15.f90 |  24 +
 .../libgomp.fortran/declare-mapper-17.f90 |  92 +++
 .../libgomp.fortran/declare-mapper-18.f90 |  46 ++
 .../libgomp.fortran/declare-mapper-19.f90 |  29 +
 .../libgomp.fortran/declare-mapper-2.f90  |  32 +
 .../libgomp.fortran/declare-mapper-20.f90 |  29 +
 .../libgomp.fortran/declare-mapper-3.f90  |  33 +
 .../libgomp.fortran/declare-mapper-4.f90  |  36 +
 .../libgomp.fortran/declare-mapper-6.f90  |  28 +
 .../libgomp.fortran/declare-mapper-7.f90  |  29 +
 .../libgomp.fortran/declare-mapper-8.f90  | 115 +++
 .../libgomp.fortran/declare-mapper-9.f90  |  27 +
 .../libgomp.fortran/map-subarray.f90  |  33 +
 .../libgomp.fortran/map-subcomponents.f90 |  32 +
 .../libgomp.fortran/struct-elem-map-1.f90 |  10 +-
 46 files changed, 2702 insertions(+), 164 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/gomp/declare-mapper-1.f90
 create mode 100644 gcc/testsuite/gfortran.dg/gomp/declare-mapper-14.f90
 create mode 100644 gcc/testsuite/gfortran.dg/gomp/declare-mapper-16.f90
 create mode 100644 gcc/testsuite/gfortran.dg/gomp/declare-mapper-5.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/declare-mapper-10.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/declare-mapper-11.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/declare-mapper-12.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/declare-mapper-13.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/declare-mapper-15.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/declare-mapper-17.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/declare-mapper-18.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/declare-mapper-19.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/declare-mapper-2.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/declare-mapper-20.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/declare-mapper-3.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/declare-mapper-4.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/declare-mapper-6.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/declare-mapper-7.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/declare-mapper-8.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/declare-mapper-9.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/map-subarray.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/map-subcomponents.f90

-

[PATCH 1/6] Fortran: Typo/unicode-o fixes

[Julian Brown]

This patch fixes a minor typo in dump output and a stray unicode character
in a comment.

This one probably counts as obvious.

2022-06-01  Julian Brown  

gcc/fortran/
* dump-parse-tree.cc (show_attr): Fix OMP-UDR-ARTIFICIAL-VAR typo.
* trans-openmp.cc (gfc_trans_omp_array_section): Replace stray unicode
m-dash character with hyphen.
---
 gcc/fortran/dump-parse-tree.cc | 2 +-
 gcc/fortran/trans-openmp.cc| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 3112caec053..f7bf91370a5 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -893,7 +893,7 @@ show_attr (symbol_attribute *attr, const char * module)
   if (attr->pdt_string)
 fputs (" PDT-STRING", dumpfile);
   if (attr->omp_udr_artificial_var)
-fputs (" OMP-UDT-ARTIFICIAL-VAR", dumpfile);
+fputs (" OMP-UDR-ARTIFICIAL-VAR", dumpfile);
   if (attr->omp_declare_target)
 fputs (" OMP-DECLARE-TARGET", dumpfile);
   if (attr->omp_declare_target_link)
diff --git a/gcc/fortran/trans-openmp.cc b/gcc/fortran/trans-openmp.cc
index 8c6f6a250de..9ca019b9535 100644
--- a/gcc/fortran/trans-openmp.cc
+++ b/gcc/fortran/trans-openmp.cc
@@ -2440,7 +2440,7 @@ gfc_trans_omp_array_section (stmtblock_t *block, 
gfc_omp_namelist *n,
= gfc_conv_descriptor_data_get (decl);
   /* This purposely does not include GOMP_MAP_ALWAYS_POINTER.  The extra
 cast prevents gimplify.cc from recognising it as being part of the
-struct – and adding an 'alloc: for the 'desc.data' pointer, which
+struct - and adding an 'alloc: for the 'desc.data' pointer, which
 would break as the 'desc' (the descriptor) is also mapped
 (see node4 above).  */
   if (ptr_kind == GOMP_MAP_ATTACH_DETACH)
-- 
2.29.2

[PATCH 2/6] OpenMP: Templatize omp_mapper_list

[Julian Brown]

This patch parameterizes the omp_mapper_list class to allow it to use
different representations for the types of mappers -- e.g., to allow
Fortran to gather mappers by "gfc_typespec *" instead of tree type
(in a later patch in the series).

There should be no behavioural changes introduced by this patch.

OK?

Julian

2022-06-01  Julian Brown  

gcc/c-family/
* c-common.h (omp_mapper_list): Add T type parameter.
(c_omp_find_nested_mappers): Update prototype.
* c-omp.cc (c_omp_find_nested_mappers): Use omp_mapper_list.

gcc/c/
* c-decl.cc (c_omp_scan_mapper_bindings): Use omp_name_type and
omp_mapper_list.

gcc/cp/
* semantics.cc (omp_target_walk_data, finish_omp_target_clauses_r):
Likewise.

gcc/
* gimplify.cc (gimplify_omp_ctx, new_omp_context,
omp_instantiate_mapper): Use omp_name_type.
* omp-general.h (omp_name_type): Parameterize by T.
(hash traits template): Use omp_name_type.
(omp_mapper_list): Parameterize by T.
---
 gcc/c-family/c-common.h |  4 ++--
 gcc/c-family/c-omp.cc   |  2 +-
 gcc/c/c-decl.cc |  6 +++---
 gcc/cp/semantics.cc |  8 
 gcc/gimplify.cc |  6 +++---
 gcc/omp-general.h   | 32 +---
 6 files changed, 30 insertions(+), 28 deletions(-)

diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index adebd0a2605..fe493fb3916 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -1252,8 +1252,8 @@ extern tree c_omp_check_context_selector (location_t, 
tree);
 extern void c_omp_mark_declare_variant (location_t, tree, tree);
 extern const char *c_omp_map_clause_name (tree, bool);
 extern void c_omp_adjust_map_clauses (tree, bool);
-struct omp_mapper_list;
-extern void c_omp_find_nested_mappers (struct omp_mapper_list *, tree);
+template struct omp_mapper_list;
+extern void c_omp_find_nested_mappers (struct omp_mapper_list *, tree);
 extern tree c_omp_instantiate_mappers (tree);
 
 class c_omp_address_inspector
diff --git a/gcc/c-family/c-omp.cc b/gcc/c-family/c-omp.cc
index 789da097bb0..ee02121f1d5 100644
--- a/gcc/c-family/c-omp.cc
+++ b/gcc/c-family/c-omp.cc
@@ -3401,7 +3401,7 @@ c_omp_address_inspector::get_attachment_point (tree expr)
themselves, add it to MLIST.  */
 
 void
-c_omp_find_nested_mappers (omp_mapper_list *mlist, tree mapper_fn)
+c_omp_find_nested_mappers (omp_mapper_list *mlist, tree mapper_fn)
 {
   tree mapper = lang_hooks.decls.omp_extract_mapper_directive (mapper_fn);
   tree mapper_name = NULL_TREE;
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 64e5faf7137..ea920e5c452 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -12562,7 +12562,7 @@ static tree
 c_omp_scan_mapper_bindings_r (tree *tp, int *walk_subtrees, void *ptr)
 {
   tree t = *tp;
-  omp_mapper_list *mlist = (omp_mapper_list *) ptr;
+  omp_mapper_list *mlist = (omp_mapper_list *) ptr;
   tree aggr_type = NULL_TREE;
 
   if (TREE_CODE (t) == SIZEOF_EXPR
@@ -12600,9 +12600,9 @@ c_omp_scan_mapper_bindings_r (tree *tp, int 
*walk_subtrees, void *ptr)
 void
 c_omp_scan_mapper_bindings (location_t loc, tree *clauses_ptr, tree body)
 {
-  hash_set seen_types;
+  hash_set> seen_types;
   auto_vec mappers;
-  omp_mapper_list mlist (&seen_types, &mappers);
+  omp_mapper_list mlist (&seen_types, &mappers);
 
   walk_tree_without_duplicates (&body, c_omp_scan_mapper_bindings_r, &mlist);
 
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 21234be3c31..4e19872c246 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -9455,7 +9455,7 @@ struct omp_target_walk_data
  variables when recording lambda_objects_accessed.  */
   hash_set local_decls;
 
-  omp_mapper_list *mappers;
+  omp_mapper_list *mappers;
 };
 
 /* Helper function of finish_omp_target_clauses, called via
@@ -9469,7 +9469,7 @@ finish_omp_target_clauses_r (tree *tp, int 
*walk_subtrees, void *ptr)
   struct omp_target_walk_data *data = (struct omp_target_walk_data *) ptr;
   tree current_object = data->current_object;
   tree current_closure = data->current_closure;
-  omp_mapper_list *mlist = data->mappers;
+  omp_mapper_list *mlist = data->mappers;
   tree aggr_type = NULL_TREE;
 
   /* References inside of these expression codes shouldn't incur any
@@ -9603,9 +9603,9 @@ finish_omp_target_clauses (location_t loc, tree body, 
tree *clauses_ptr)
   else
 data.current_closure = NULL_TREE;
 
-  hash_set seen_types;
+  hash_set > seen_types;
   auto_vec mapper_fns;
-  omp_mapper_list mlist (&seen_types, &mapper_fns);
+  omp_mapper_list mlist (&seen_types, &mapper_fns);
   data.mappers = &mlist;
 
   cp_walk_tree_without_duplicates (&body, finish_omp_target_clauses_r, &data);
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 861159687a7..cb6877b5009 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -219,7 +219,7 @@ struct gimplify_omp_ctx
 {
   struct gimplify_omp_ctx *outer_context;
   splay_tree variables;
-  hash_map *implicit_mappers;
+  ha

[PATCH 3/6] OpenMP: Rename strip_components_and_deref to omp_get_root_term

[Julian Brown]

This patch renames the strip_components_and_deref function to better
describe what it does. I'll fold this into the originating patch series
during rework.

2022-06-01  Julian Brown  

gcc/
* gimplify.cc (strip_components_and_deref): Rename to...
(omp_get_root_term): This.
---
 gcc/gimplify.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index cb6877b5009..1646fdaa9b8 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -8768,7 +8768,7 @@ omp_get_base_pointer (tree expr)
 /* Remove COMPONENT_REFS and indirections from EXPR.  */
 
 static tree
-strip_components_and_deref (tree expr)
+omp_get_root_term (tree expr)
 {
   while (TREE_CODE (expr) == COMPONENT_REF
 || TREE_CODE (expr) == INDIRECT_REF
@@ -11168,7 +11168,7 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq 
*pre_p,
 
  if (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_STRUCT)
{
- tree base = strip_components_and_deref (decl);
+ tree base = omp_get_root_term (decl);
  if (DECL_P (base))
{
  decl = base;
-- 
2.29.2

[PATCH 4/6] OpenMP: Tweak NOP handling in in omp_get_root_term and accumulate_sibling_list

[Julian Brown]

This patch strips NOPs in omp_get_root_term and accumulate_sibling_list
to cover cases that came up writing tests for "omp declare mapper"
functionality. I'll fold this into the originating patch series for
those functions during rework.

2022-06-01  Julian Brown  

gcc/
* gimplify.cc (omp_get_root_term): Look through NOP_EXPRs.
(accumulate_sibling_list): Strip NOPs on struct base pointers.
---
 gcc/gimplify.cc | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 1646fdaa9b8..742fd5e4a8d 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -8775,7 +8775,8 @@ omp_get_root_term (tree expr)
 || (TREE_CODE (expr) == MEM_REF
 && integer_zerop (TREE_OPERAND (expr, 1)))
 || TREE_CODE (expr) == POINTER_PLUS_EXPR
-|| TREE_CODE (expr) == COMPOUND_EXPR)
+|| TREE_CODE (expr) == COMPOUND_EXPR
+|| TREE_CODE (expr) == NOP_EXPR)
   if (TREE_CODE (expr) == COMPOUND_EXPR)
expr = TREE_OPERAND (expr, 1);
   else
@@ -9932,6 +9933,8 @@ accumulate_sibling_list (enum omp_region_type 
region_type, enum tree_code code,
sdecl = TREE_OPERAND (sdecl, 0);
}
 
+  STRIP_NOPS (sdecl);
+
   while (TREE_CODE (sdecl) == POINTER_PLUS_EXPR)
sdecl = TREE_OPERAND (sdecl, 0);
 
-- 
2.29.2

[PATCH 5/6] OpenMP: Pointers and member mappings

[Julian Brown]

Implementing the "omp declare mapper" functionality, I noticed some
cases where handling of derived type members that are pointers doesn't
seem to be quite right. At present, a type such as this:

  type T
  integer, pointer, dimension(:) :: arrptr
  end type T

  type(T) :: tvar
  [...]
  !$omp target map(tofrom: tvar%arrptr)

will be mapped using three mapping nodes:

  GOMP_MAP_TO tvar%arrptr   (the descriptor)
  GOMP_MAP_TOFROM *tvar%arrptr%data (the actual array data)
  GOMP_MAP_ALWAYS_POINTER tvar%arrptr%data  (a pointer to the array data)

This follows OMP 5.0, 2.19.7.1 "map Clause":

  "If a list item in a map clause is an associated pointer and the
   pointer is not the base pointer of another list item in a map clause
   on the same construct, then it is treated as if its pointer target
   is implicitly mapped in the same clause. For the purposes of the map
   clause, the mapped pointer target is treated as if its base pointer
   is the associated pointer."

However, we can also write this:

  map(to: tvar%arrptr) map(tofrom: tvar%arrptr(3:8))

and then instead we should follow:

  "If the structure sibling list item is a pointer then it is treated
   as if its association status is undefined, unless it appears as
   the base pointer of another list item in a map clause on the same
   construct."

But, that's not implemented quite right at the moment (and completely
breaks once we introduce declare mappers), because we still map the "to:
tvar%arrptr" as the descriptor and the entire array, then we map the
"tvar%arrptr(3:8)" part using the descriptor (again!) and the array slice.

The solution is to detect when we're mapping a smaller part of the array
(or a subcomponent) on the same directive, and only map the descriptor
in that case. So we get mappings like this instead:

  map(to: tvar%arrptr)   -->
  GOMP_MAP_ALLOC  tvar%arrptr  (the descriptor)

  map(tofrom: tvar%arrptr(3:8)   -->
  GOMP_MAP_TOFROM tvar%arrptr%data(3) (size 8-3+1, etc.)
  GOMP_MAP_ALWAYS_POINTER tvar%arrptr%data (bias 3, etc.)

OK?

Thanks,

Julian

2022-06-01  Julian Brown  

gcc/fortran/
* trans-openmp.cc (dependency.h): Include.
(gfc_trans_omp_array_section): Do not map descriptors here for OpenMP.
(gfc_trans_omp_clauses): Check subcomponent and subarray/element
accesses elsewhere in the clause list for pointers to derived types or
array descriptors, and map just the pointer/descriptor if we have any.

libgomp/
* testsuite/libgomp.fortran/map-subarray.f90: New test.
* testsuite/libgomp.fortran/map-subcomponents.f90: New test.
* testsuite/libgomp.fortran/struct-elem-map-1.f90: Adjust for
descriptor-mapping changes.
---
 gcc/fortran/trans-openmp.cc   | 106 +++---
 .../libgomp.fortran/map-subarray.f90  |  33 ++
 .../libgomp.fortran/map-subcomponents.f90 |  32 ++
 .../libgomp.fortran/struct-elem-map-1.f90 |  10 +-
 4 files changed, 164 insertions(+), 17 deletions(-)
 create mode 100644 libgomp/testsuite/libgomp.fortran/map-subarray.f90
 create mode 100644 libgomp/testsuite/libgomp.fortran/map-subcomponents.f90

diff --git a/gcc/fortran/trans-openmp.cc b/gcc/fortran/trans-openmp.cc
index 9ca019b9535..21f3336a898 100644
--- a/gcc/fortran/trans-openmp.cc
+++ b/gcc/fortran/trans-openmp.cc
@@ -40,6 +40,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "omp-general.h"
 #include "omp-low.h"
 #include "memmodel.h"  /* For MEMMODEL_ enums.  */
+#include "dependency.h"
 
 #undef GCC_DIAG_STYLE
 #define GCC_DIAG_STYLE __gcc_tdiag__
@@ -2416,22 +2417,18 @@ gfc_trans_omp_array_section (stmtblock_t *block, 
gfc_omp_namelist *n,
 }
   if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (decl)))
 {
-  tree desc_node;
   tree type = TREE_TYPE (decl);
   ptr2 = gfc_conv_descriptor_data_get (decl);
-  desc_node = build_omp_clause (input_location, OMP_CLAUSE_MAP);
-  OMP_CLAUSE_DECL (desc_node) = decl;
-  OMP_CLAUSE_SIZE (desc_node) = TYPE_SIZE_UNIT (type);
-  if (ptr_kind == GOMP_MAP_ALWAYS_POINTER)
+  if (ptr_kind != GOMP_MAP_ALWAYS_POINTER)
{
- OMP_CLAUSE_SET_MAP_KIND (desc_node, GOMP_MAP_TO);
- node2 = node;
- node = desc_node;  /* Needs to come first.  */
-   }
-  else
-   {
- OMP_CLAUSE_SET_MAP_KIND (desc_node, GOMP_MAP_TO_PSET);
- node2 = desc_node;
+ /* For OpenMP, the descriptor must be mapped with its own explicit
+map clause (e.g. both "map(foo%arr)" and "map(foo%arr(:))" must
+be present in the clause list if "foo%arr" is a pointer to an
+array).  So, we don't create a GOMP_MAP_TO_PSET node here.  */
+ node2 = build_omp_clause (input_location, OMP_CLAUSE_MAP);
+ OMP_CLAUSE_SET_MAP_KIND (node2, GOMP_MAP_TO_PSET);
+ OMP_CLAUSE_DECL (node2) = decl;
+ OMP_CLAUSE_SIZE (node2) = TYPE_SIZE_UNIT (type);
}
   no

[PATCH 6/6] OpenMP: Fortran "!$omp declare mapper" support

[Julian Brown]

This patch implements "omp declare mapper" functionality for Fortran,
following the equivalent support for C and C++.

Fortran differs quite substantially from C and C++ in that "map"
clauses are naturally represented in the gfortran front-end's own
representation rather than as trees. Those are turned into one -- or
several -- OMP_CLAUSE_MAP nodes in gfc_trans_omp_clauses.

The "several nodes" case is problematic for mappers, for a few different
reasons:

 - Firstly, if we're invoking a nested mapper, we need some way of
   keeping those nodes together so they can be replaced "as one" by the
   clauses listed in that mapper. (For C and C++, a single OMP_CLAUSE_MAP
   node is used to represent a map clause early in compilation, which
   is then expanded in c_finish_omp_clauses for C, and similar for C++.
   We process mappers before that function is called.)

 - Secondly, the process of translating FE representation of clauses
   into "tree" mapping nodes can generate preamble code, and we need to
   either defer that generation or else put the preamble code somewhere
   if we're defining a mapper.

 - Thirdly, gfc_trans_omp_clauses needs to examine both the FE
   representation and partially-translated tree codes.  In the case
   where we're instantiating mappers implicitly from the middle end,
   the FE representation is long gone.

The scheme used is as follows.

For the first problem, we introduce a GOMP_MAP_MAPPING_GROUP mapping kind.
This is used to keep several mapping nodes together in mapper definitions
until instantiation time.  If the group triggers a nested mapper,
the required information can be extracted from it and then it can be
deleted/replaced as a whole.

For the second and third problems, we emit preamble code into a function
wrapping the "omp declare mapper" node.  This extends the scheme currently
under review for C++, and performs inlining of a modified version of
the function whenever a mapper is invoked from the middle-end.  New copies
of variables (e.g. temporary array descriptors or other metadata) are
introduced to copy needed values out of the inlined function to where
they're needed in the mapper instantiation.

For Fortran, we also need to add special-case handling for mapping
derived-type variables that are (a) pointers and (b) trigger a mapper,
in both the explicit mapping and implicit mapping cases.  If we have a
type and a mapper like this:

  type T
  integer, dimension(10) :: iarr
  end type T

  type(T), pointer :: tptr

  !$omp declare mapper (T :: t) map(t%iarr)

  !$omp target map(tptr)
  [...]
  !$omp end target

Here "map(tptr)" maps the pointer itself, and implicitly maps the
pointed-to object as well.  So, when invoking the mapper, rather than
rewriting this as just:

  !$omp target map(tptr%iarr)

we must introduce a new node to map the pointer also, i.e.:

  !$omp target map(alloc:tptr) map(tptr%iarr)

...before the mapping nodes go off to gimplify for processing.
(This relates to the previous patch in the series.)

We also need to handle module writing and reading for "declare mappers".
This requires an ABI bump that I noticed one of Tobias's patches also
does, so we'll probably need to synchronize on that somehow.

OK?

Thanks,

Julian

2022-06-01  Julian Brown  

gcc/fortran/
* dump-parse-tree.cc (show_attr): Show omp_udm_artificial_var flag.
(show_omp_namelist): Support OMP_MAP_UNSET.
* f95-lang.cc (LANG_HOOKS_OMP_FINISH_MAPPER_CLAUSES,
LANG_HOOKS_OMP_EXTRACT_MAPPER_DIRECTIVE,
LANG_HOOKS_OMP_MAP_ARRAY_SECTION): Define language hooks.
* gfortran.h (gfc_statement): Add ST_OMP_DECLARE_MAPPER.
(symbol_attribute): Add omp_udm_artificial_var attribute.
(gfc_omp_map_op): Add OMP_MAP_UNSET.
(gfc_omp_namelist): Add udm pointer to u2 union.
(gfc_omp_udm): New struct.
(gfc_omp_namelist_udm): New struct.
(gfc_symtree): Add omp_udm pointer.
(gfc_namespace): Add omp_udm_root symtree. Add omp_udm_ns flag.
(gfc_free_omp_namelist): Update prototype.
(gfc_free_omp_udm, gfc_omp_udm_find, gfc_find_omp_udm,
gfc_resolve_omp_udms): Add prototypes.
* match.cc (gfc_free_omp_namelist): Change FREE_NS parameter to LIST,
to handle freeing user-defined mapper namelists safely.
* match.h (gfc_match_omp_declare_mapper): Add prototype.
* module.cc (MOD_VERSION): Bump to 16.
(ab_attribute): Add AB_OMP_DECLARE_MAPPER_VAR.
(attr_bits): Add OMP_DECLARE_MAPPER_VAR.
(mio_symbol_attribute): Read/write AB_OMP_DECLARE_MAPPER_VAR attribute.
Set referenced attr on read.
(omp_map_clause_ops, omp_map_cardinality): New arrays.
(load_omp_udms, check_omp_declare_mappers): New functions.
(read_module): Load and check OMP declare mappers.
(write_omp_udm, write_omp_udms): New functions.
(write_module): Write OMP declare mappers.
* openmp.cc (gfc_free_omp_clauses, gfc_mat