Re: is there a way to find out gfortran version and/or options from a given binary?
Hi Kay, (you forgot to reply to everybody ;)) I am using a Windows version of gfortran and strings. I use a file viewer that comes with the Total Commander file manager. So, it may be something specific to that version of strings. Regards, Arjen Op vr 3 jun. 2022 om 09:25 schreef Kay Diederichs < kay.diederi...@uni-konstanz.de>: > On 6/3/22 08:47, Arjen Markus via Fortran wrote: > > Do you know why the strings command does not show the identification > > string, > > which clearly present in the executable file, even though it should > examine > > the > > entire file (the --all option does not alter the output)? > > > > Regards, > > > > Arjen > > > > Op vr 3 jun. 2022 om 07:22 schreef Janne Blomqvist < > > blomqvist.ja...@gmail.com>: > > > >> On Thu, Jun 2, 2022 at 10:33 PM Kay Diederichs > >> wrote: > >>> Am 02.06.22 um 21:06 schrieb Janne Blomqvist: > As an alternative approach, make a command-line option (say, "-v") > that prints the version number of the program, name of the author and > other pertinent information, as well as the output of > compiler_version() and compiler_options(), and then exits. That would > ensure that those calls won't be optimized away. > > >>> > >>> I was thinking of such a -v option as well, and it is a solution for > >>> some situations, but not e.g. for a dynamically loadable library (see > >>> https://cims.nyu.edu/~donev/Fortran/DLL/DLL.Forum.txt ) which is my > >>> situation ( > >>> https://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/LIB ). I'd > >>> like to be able to see later which compiler version and options were > >>> used when compiling that library, because over the years of > distributing > >>> this code, compilers and options have been changing. > >> > >> For the library case, can't you make a function > >> libraryname_print_version_info() or whatever you want to call it that > >> does the same? Of course, if the user never calls that function, uses > >> a static library, and everything is compiled with -ffunction-sections > >> and linked with --gc-sections that will not work, but otherwise the > >> string should still be there in the binary so you should be able to > >> find it with the strings tool? > >> > >>> -g includes the source code, which is not always desired, and is not > >>> possible here due to license issues - there was no concept of "open > >>> source" as we have it today in the 80ies when this code was started. > >> > >> Hmm, maybe that's the case, I don't have a legal opinion to offer on > >> this, sorry. > >> > >>> Also I think it makes the code slower. > >> > >> No, at least with GCC -g doesn't affect the code generation. It makes > >> the binary bigger so it takes longer to copy around, and depending on > >> how the debug info is spread out in the binary some of that might be > >> unnecessarily mapped into memory when running, but I think you'd be > >> very hard pressed to measure any difference in performance. > >> > >> -- > >> Janne Blomqvist > >> > > > > Arjen, > > "egrep"-ing for 'GNU|GCC' in the "strings" output shows more than > "grep"-ing for GNU, which is what I tried first. > But I don't think you see even more with a "fileviewer" (which do you > refer to? > I tried the "bless" hex editor and "okteta"; they don't show more than > "strings"). > > @Janne thanks for pointing out that -g does not make the code slower. > Is there an option that prevents the sourcecode to be included when -g is > used? > > thanks, > Kay >
Re: is there a way to find out gfortran version and/or options from a given binary?
On Fri, Jun 3, 2022 at 10:30 AM Arjen Markus via Fortran wrote: > > Hi Kay, > > (you forgot to reply to everybody ;)) > > I am using a Windows version of gfortran and strings. I use a file viewer > that comes with the Total Commander file manager. So, it may be something > specific to that version of strings. One caveat being that Fortran strings are not NULL terminated like C strings. So a tool that searches for C-style strings in a binary might not find Fortran-style strings unless there happens to be a NULL after them for some other reason. The version of strings included in GNU binutils searches for strings terminated by any non-printable character, so it finds Fortran style strings (and a lot of noise which isn't strings). > Op vr 3 jun. 2022 om 09:25 schreef Kay Diederichs < > kay.diederi...@uni-konstanz.de>: > > @Janne thanks for pointing out that -g does not make the code slower. > > Is there an option that prevents the sourcecode to be included when -g is > > used? You might try -frecord-gcc-switches. There's also -grecord-gcc-switches (which puts the info somewhere in the debug data), which is enabled by -g, but without -g it seems it doesn't do anything. -- Janne Blomqvist
Re: is there a way to find out gfortran version and/or options from a given binary?
On 6/3/22 10:16, Janne Blomqvist via Fortran wrote: On Fri, Jun 3, 2022 at 10:30 AM Arjen Markus via Fortran wrote: Hi Kay, (you forgot to reply to everybody ;)) I am using a Windows version of gfortran and strings. I use a file viewer that comes with the Total Commander file manager. So, it may be something specific to that version of strings. One caveat being that Fortran strings are not NULL terminated like C strings. So a tool that searches for C-style strings in a binary might not find Fortran-style strings unless there happens to be a NULL after them for some other reason. The version of strings included in GNU binutils searches for strings terminated by any non-printable character, so it finds Fortran style strings (and a lot of noise which isn't strings). Op vr 3 jun. 2022 om 09:25 schreef Kay Diederichs < kay.diederi...@uni-konstanz.de>: @Janne thanks for pointing out that -g does not make the code slower. Is there an option that prevents the sourcecode to be included when -g is used? You might try -frecord-gcc-switches. There's also -grecord-gcc-switches (which puts the info somewhere in the debug data), which is enabled by -g, but without -g it seems it doesn't do anything. thanks for pointing at -frecord-gcc-switches . This appears to be what I was looking for. Googling for frecord-gcc-switches (without the leading "-", of course) brings up very interesting exchanges. For the record, when -frecord-gcc-switches is used in compilation, objdump -s --section=.GCC.command.line or readelf -p .GCC.command.line shows the compiler options. I have not (yet) tried to find out how -grecord-gcc-switches differs, nor if and why the suggestion to "Introduce a new GCC option, --record-gcc-command-line" was rejected ( https://gcc.gnu.org/legacy-ml/gcc-patches/2019-11/msg00434.html ). Thanks to all who responded! Kay
[Patch] OpenMP/Fortran: Add support for firstprivate and allocate clauses on scope construct
Simple patch. Testcases based on the C/C++ commit.
For allocate, I found an unrelated bug which prevented me from adding
the associated testcase: https://gcc.gnu.org/PR105836
Tested on x86-64 (w/o offloading).
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
OpenMP/Fortran: Add support for firstprivate and allocate clauses on scope construct
Fortran commit to C/C++/backend commit
r13-862-gf38b20d68fade5a922b9f68c4c3841e653d1b83c
gcc/fortran/ChangeLog:
* openmp.cc (OMP_SCOPE_CLAUSES): Add firstprivate and allocate.
libgomp/ChangeLog:
* libgomp.texi (OpenMP 5.2): Mark scope w/ firstprivate/allocate as Y.
* testsuite/libgomp.fortran/scope-2.f90: New test.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/scope-5.f90: New test.
* gfortran.dg/gomp/scope-6.f90: New test.
gcc/fortran/openmp.cc | 3 +-
gcc/testsuite/gfortran.dg/gomp/scope-5.f90| 9 +
gcc/testsuite/gfortran.dg/gomp/scope-6.f90| 23 +++
libgomp/libgomp.texi | 2 +-
libgomp/testsuite/libgomp.fortran/scope-2.f90 | 57 +++
5 files changed, 92 insertions(+), 2 deletions(-)
diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index a1aa88c5d74..d12cec43d64 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -3682,7 +3682,8 @@ cleanup:
| OMP_CLAUSE_PRIVATE | OMP_CLAUSE_LASTPRIVATE | OMP_CLAUSE_REDUCTION)
#define OMP_SCOPE_CLAUSES \
- (omp_mask (OMP_CLAUSE_PRIVATE) | OMP_CLAUSE_REDUCTION)
+ (omp_mask (OMP_CLAUSE_PRIVATE) |OMP_CLAUSE_FIRSTPRIVATE \
+ | OMP_CLAUSE_REDUCTION | OMP_CLAUSE_ALLOCATE)
#define OMP_SECTIONS_CLAUSES \
(omp_mask (OMP_CLAUSE_PRIVATE) | OMP_CLAUSE_FIRSTPRIVATE \
| OMP_CLAUSE_LASTPRIVATE | OMP_CLAUSE_REDUCTION | OMP_CLAUSE_ALLOCATE)
diff --git a/gcc/testsuite/gfortran.dg/gomp/scope-5.f90 b/gcc/testsuite/gfortran.dg/gomp/scope-5.f90
new file mode 100644
index 000..baddae51b42
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/gomp/scope-5.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+
+subroutine foo ()
+ integer f
+ f = 0;
+ !$omp scope firstprivate(f) ! { dg-error "firstprivate variable 'f' is private in outer context" }
+f = f + 1
+ !$omp end scope
+end
diff --git a/gcc/testsuite/gfortran.dg/gomp/scope-6.f90 b/gcc/testsuite/gfortran.dg/gomp/scope-6.f90
new file mode 100644
index 000..9c595b1e117
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/gomp/scope-6.f90
@@ -0,0 +1,23 @@
+! { dg-additional-options "-fdump-tree-original" }
+
+module m
+ use iso_c_binding
+ !use omp_lib, only: omp_allocator_handle_kind
+ implicit none
+ integer, parameter :: omp_allocator_handle_kind = c_intptr_t
+ integer :: a = 0, b = 42, c = 0
+
+contains
+ subroutine foo (h)
+ integer(omp_allocator_handle_kind), value :: h
+ !$omp scope private (a) firstprivate (b) reduction (+: c) allocate ( h : a , b , c)
+if (b /= 42) &
+ error stop
+a = 36
+b = 15
+c = c + 1
+ !$omp end scope
+ end
+end
+
+! { dg-final { scan-tree-dump "omp scope private\\(a\\) firstprivate\\(b\\) reduction\\(\\+:c\\) allocate\\(allocator\\(D\\.\[0-9\]+\\):a) allocate\\(allocator\\(D\\.\[0-9\]+\\):b) allocate\\(allocator\\(D\\.\[0-9\]+\\):c)" "original" } }
diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index ff02ccd4969..11613bf7599 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -386,7 +386,7 @@ The OpenMP 4.5 specification is fully supported.
@item Deprecation of delimited form of @code{declare target} @tab N @tab
@item Reproducible semantics changed for @code{order(concurrent)} @tab N @tab
@item @code{allocate} and @code{firstprivate} clauses on @code{scope}
- @tab N @tab
+ @tab Y @tab
@item @code{ompt_callback_work} @tab N @tab
@item Default map-type for @code{map} clause in @code{target enter/exit data}
@tab N @tab
diff --git a/libgomp/testsuite/libgomp.fortran/scope-2.f90 b/libgomp/testsuite/libgomp.fortran/scope-2.f90
new file mode 100644
index 000..f2e1593403e
--- /dev/null
+++ b/libgomp/testsuite/libgomp.fortran/scope-2.f90
@@ -0,0 +1,57 @@
+program main
+ implicit none
+ integer a(0:63)
+ integer r, r2, i, n
+ a = 0
+ r = 0
+ r2 = 0
+ n = 64
+ !$omp parallel
+!$omp scope
+ !$omp scope firstprivate (n)
+ !$omp do
+ do i = 0, 63
+ a(i) = a(i) + 1
+ end do
+ !$omp end scope nowait
+!$omp end scope nowait
+
+!$omp scope reduction(+: r) firstprivate (n)
+ !$omp do
+ do i = 0, 63
+r = r + i
+if (a(i) /= 1) &
+ error stop
+ end do
+ !$omp end do nowait
+ !$omp barrier
+ if (n /= 64) then
+error stop
+ else
+n = 128
+ end if
+!$omp end scope nowait
+
+!$omp barrier
+if
Re: [Patch] OpenMP/Fortran: Add support for firstprivate and allocate clauses on scope construct
On Fri, Jun 03, 2022 at 03:37:56PM +0200, Tobias Burnus wrote: > Simple patch. Testcases based on the C/C++ commit. > For allocate, I found an unrelated bug which prevented me from adding > the associated testcase: https://gcc.gnu.org/PR105836 > > Tested on x86-64 (w/o offloading). > 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 > OpenMP/Fortran: Add support for firstprivate and allocate clauses on scope > construct > > Fortran commit to C/C++/backend commit > r13-862-gf38b20d68fade5a922b9f68c4c3841e653d1b83c > > gcc/fortran/ChangeLog: > > * openmp.cc (OMP_SCOPE_CLAUSES): Add firstprivate and allocate. > > libgomp/ChangeLog: > > * libgomp.texi (OpenMP 5.2): Mark scope w/ firstprivate/allocate as Y. > * testsuite/libgomp.fortran/scope-2.f90: New test. > > gcc/testsuite/ChangeLog: > > * gfortran.dg/gomp/scope-5.f90: New test. > * gfortran.dg/gomp/scope-6.f90: New test. Ok, thanks. Jakub
