Re: [OG11-committed][stage1-patch] Fortran: Fix finalization resolution with deep copy (was: [Patch][Stage 1] Fortran/OpenMP: Support mapping of DT with allocatable components)
More testing found more issues. Instead of adding more band aid to the
pre-existing band aid, which was extended before, let's try a different
approach:
Just ensure that all component types are resolved (which includes
finalizers) before continuing with the derived type. This also resolves
the finalizers (but also derived-type procedures) before using it in the
_callback vtable entry (with the deep mapping patch) – or in general:
before creating the vtable.
Committed to OG11 – and stashed for mainline. See attachment.
Tobias
PS: With the deep-mapping patch, the vtable of allocatable DT components
is required. Thus, the _callback code generation tries to get the
associated vtable. That in turned triggered the generation of the
DT-component's vtable, which did fail with an assert, unless it either
does not have finalizers or the type has been resolved before.
On 25.04.22 15:47, Tobias Burnus wrote:
Found another issue – applied to OG11 as attached. Will include it in
the mainline patch once Stage1.
(However, I intent to split the original patch (+ follow ups) into
smaller pieces for mainline incorporation.)
Tobias
On 02.03.22 23:20, Tobias Burnus wrote:
Some testing found an issue in class.cc (in the new _callback
function) – updated patch attached (long version + interdiff).
Tobias
(PS: OG11 - original patch was committed as
https://gcc.gnu.org/g:98961d3a0ccb02d7d54d2d4dd07cca75473d685a ;
follow-up version to be committed in a moment)
On 01.03.22 16:34, Tobias Burnus wrote:
Hi all,
this patch adds support for mapping something like
type t
type(t2), allocatable :: a, b(:)
integer, allocatable :: c, c(:)
end type t
type(t), allocatable :: var, var2(:,:)
!$omp target enter data map(var, var)
which does a deep walk of the components at runtime.
On the ME side, the static addr/size/kinds arrays are
replaced (only if need) by allocatable arrays – which
are then filled by trans-openmp.c.
All deep-mapping handling happens via the hooks called
late in omp-low.c such that removing mappings or implicitly
added one are handled.
In principle, there is also code to handle polymorphic
variables (new callback function in vtable + two on-the-fly
generated functions to be used for walking the vtable).
Issues: None known, but I am sure with experimenting,
more can be found - especially with arrays/array sections
and polymorphism, I expect issues. I did find some on the
way and fixed them - but (see PR refs in testcase -7.f90),
I also found unrelated bugs, which I did not fix ;-)
Comments? OK for mainline (GCC 13)?
Tobias
PS: I will commit this patch to OG11 for further testing.
PPS: Previously discussed at
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586237.html
-
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
commit 492ea356ce4b9e40c417b3740cc298d6cc78e870
Author: Tobias Burnus
Date: Wed Apr 27 19:44:52 2022 +0200
Fortran: Fix finalization resolution with deep copy (cont)
gcc/fortran/ChangeLog:
* resolve.c (gfc_resolve_finalizers): Remove
gfc_resolve_finalizers calls, use gfc_is_finalizable.
(resolve_fl_derived): Resolve derived-type components
first.
gcc/testsuite/ChangeLog:
* gfortran.dg/abstract_type_6.f03: Remove dg-error as
now hidden by other errors; copy to ...
* gfortran.dg/abstract_type_6a.f03: ... here; remove
some error to diagnose the error.
* gfortran.dg/finalize_39.f90: New test.
---
gcc/fortran/resolve.c | 29 ---
gcc/testsuite/gfortran.dg/abstract_type_6.f03 | 3 +-
gcc/testsuite/gfortran.dg/abstract_type_6a.f03 | 46 ++
gcc/testsuite/gfortran.dg/finalize_39.f90 | 112 +
4 files changed, 177 insertions(+), 13 deletions(-)
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 10c89de0eaa..84a538ee5bc 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -13582,18 +13582,10 @@ gfc_resolve_finalizers (gfc_symbol* derived, bool *finalizable)
handle allocatables but avoid issues with (in)direct allocatable types. */
bool has_final = derived->f2k_derived && derived->f2k_derived->finalizers;
for (c = derived->components; c; c = c->next)
-if (c->ts.type == BT_DERIVED && !c->attr.pointer && !c->attr.proc_pointer
- && (!c->attr.allocatable
- || (c->ts.u.derived != derived
- && c->ts.u.derived->f2k_derived
- && c->ts.u.derived->f2k_derived->finalizers
- && !c->ts.u.derived->f2k_derived->finalizers->proc_tree)))
- {
- bool has_final2 = false;
- if (!gfc_resolve_finalizers (c->ts.u.derived, &has_final2))
- return false; /* Error. */
- has_final = has_final || has_final2;
- }
+if (c->t
[patch, fortran, doc] Mention new CONVERT options for POWER
Hi,
as we say in German "Nicht documentiert ist nicht gemacht", if
it is not documented, it wasn't done.
So I thought it would be time to document the changes to the various
ways of specifying CONVERT before gcc12 went out of the door, so
here is a patch for that.
If that goes in, I will also write up something for gcc-12/changes.html.
OK for trunk? Suggestions for improvements?
Best regards
Thomas
Document changes to CONVERT for -mabi-ieeelongdouble for POWER
gcc/fortran/ChangeLog:
* gfortran.texi: Mention r16_ieee and r16_ibm.
* invoke.texi: Likewise.diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index f8737f4d323..6f622fb9898 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -589,7 +589,7 @@ Malformed environment variables are silently ignored.
* GFORTRAN_SHOW_LOCUS:: Show location for runtime errors
* GFORTRAN_OPTIONAL_PLUS:: Print leading + where permitted
* GFORTRAN_LIST_SEPARATOR:: Separator for list output
-* GFORTRAN_CONVERT_UNIT:: Set endianness for unformatted I/O
+* GFORTRAN_CONVERT_UNIT:: Set conversion for unformatted I/O
* GFORTRAN_ERROR_BACKTRACE:: Show backtrace on run-time errors
* GFORTRAN_FORMATTED_BUFFER_SIZE:: Buffer size for formatted files
* GFORTRAN_UNFORMATTED_BUFFER_SIZE:: Buffer size for unformatted files
@@ -686,11 +686,12 @@ when @command{a.out} is the compiled Fortran program that you want to run.
Default is a single space.
@node GFORTRAN_CONVERT_UNIT
-@section @env{GFORTRAN_CONVERT_UNIT}---Set endianness for unformatted I/O
+@section @env{GFORTRAN_CONVERT_UNIT}---Set conversion for unformatted I/O
By setting the @env{GFORTRAN_CONVERT_UNIT} variable, it is possible
to change the representation of data for unformatted files.
-The syntax for the @env{GFORTRAN_CONVERT_UNIT} variable is:
+The syntax for the @env{GFORTRAN_CONVERT_UNIT} variable for
+most systems is:
@smallexample
GFORTRAN_CONVERT_UNIT: mode | mode ';' exception | exception ;
mode: 'native' | 'swap' | 'big_endian' | 'little_endian' ;
@@ -711,14 +712,24 @@ the modes are the same as for the @code{CONVERT} specifier:
for unformatted files.
@item @code{BIG_ENDIAN} Use the big-endian format for unformatted files.
@end itemize
+For POWER systems which support @option{-mabi=ieeelongdouble},
+there are additional options, which can be combined with the
+others with commas. Those are
+@itemize @w{}
+@item @code{R16_IEEE} Use IEEE 128-bit format for @code{REAL(KIND=16)}.
+@item @code{R16_IBM} Use IBM @code{long double} format for
+@code{REAL(KIND=16)}.
+@end itemize
A missing mode for an exception is taken to mean @code{BIG_ENDIAN}.
Examples of values for @env{GFORTRAN_CONVERT_UNIT} are:
@itemize @w{}
-@item @code{'big_endian'} Do all unformatted I/O in big_endian mode.
+@item @code{'big_endian'} Do all unformatted I/O in big_endian mod.e
@item @code{'little_endian;native:10-20,25'} Do all unformatted I/O
in little_endian mode, except for units 10 to 20 and 25, which are in
native format.
@item @code{'10-20'} Units 10 to 20 are big-endian, the rest is native.
+@item @code{'big_endian,r16_ibm'} Do all unformatted I/O in big-endian
+mode and use IBM long double for output of @code{REAL(KIND=16)} values.
@end itemize
Setting the environment variables should be done on the command
@@ -1736,7 +1747,7 @@ the @code{CONVERT} specifier on the @code{OPEN} statement.
@xref{GFORTRAN_CONVERT_UNIT}, for an alternative way of specifying
the data format via an environment variable.
-Valid values for @code{CONVERT} are:
+Valid values for @code{CONVERT} on most systems are:
@itemize @w{}
@item @code{CONVERT='NATIVE'} Use the native format. This is the default.
@item @code{CONVERT='SWAP'} Swap between little- and big-endian.
@@ -1745,6 +1756,15 @@ for unformatted files.
@item @code{CONVERT='BIG_ENDIAN'} Use the big-endian representation for
unformatted files.
@end itemize
+On POWER systems which support @option{-mabi=ieeelongdouble},
+there are additional options, which can be combined with the others
+with commas. Those are
+@itemize @w{}
+@item @code{CONVERT='R16_IEEE'} Use IEEE 128-bit format for
+@code{REAL(KIND=16)}.
+@item @code{CONVERT='R16_IBM'} Use IBM @code{long double} format for
+real@code{REAL(KIND=16)}.
+@end itemize
Using the option could look like this:
@smallexample
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 5c7501a28b1..c0932f6cd70 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1435,10 +1435,20 @@ These options affect the runtime behavior of programs compiled with GNU Fortran.
@item -fconvert=@var{conversion}
@opindex @code{fconvert=}@var{conversion}
Specify the representation of data for unformatted files. Valid
-values for conversion are: @samp{native}, the default; @samp{swap},
-swap between big- and little-endian; @samp{big-endian}, use big-endian
-representation for unformatted files; @samp{little-endian}, use little-endian
-representati
