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 tu
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 ta
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_
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/
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
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)
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
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 appe
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
Confi
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
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-kon
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
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_versio
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_1
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/
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:
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)' ) ''
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
18 matches
Mail list logo
