[Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15
Hi all,
attached patch makes an attempt to announce the ABI-changes in the coarrays
library. Me being German always has difficulties to find a proper wording. So
please propose improvements.
Stupid question: How to I test this? The change looks good in my browser. Is
there a style checker, I don't see?
Regards,
Ande
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 8b1ba25dd27c89dc6ff860835431e09f3895a4e1 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Thu, 20 Feb 2025 10:47:22 +0100
Subject: [PATCH] gcc-15/changes: Document coarray changes.
ABI of coarrays has changed. Document possible linker errors for
caf_single.
---
htdocs/gcc-15/changes.html | 6 ++
1 file changed, 6 insertions(+)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 853fad03..ea1e7553 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -436,6 +436,12 @@ asm (".text; %cc0: mov %cc2, %%r0; .previous;"
incompatible with the module format generated by GCC 8 - 14, but GCC
15 can for compatibility still read GCC 8 - 14 created module
files.
+ Coarray support has been reworked to allow access to data in derived types
+ that have not been compiled with coarray support enabled. Esp. when the
+ derived type is in a binary only module. This may lead to linking errors
+ with the provided caf_single-libraries of previous GCC versions. It is
+ recommended to only use the newest version of caf_single. The OpenCoarrays
+ library is not affected and provides all ABIs.
--
2.48.1
Re: 7/7 [Fortran, Patch, Coarray, PR107635] Remove deprecated coarray routines
Hi all, I just merged the patch series as gcc-15-7644-gd3244675441. Thanks for all the reviews. I will now prepare the Relasenotes. Regards and thanks again, Andre On Tue, 18 Feb 2025 18:13:53 +0100 Thomas Koenig wrote: > Am 18.02.25 um 16:00 schrieb Andre Vehreschild: > > Hi Thomas, > > > >> This patch series (of necessity) introduces ABI changes. What will > >> happen with user code compiled against the old interface? > > > > That depends on the library you are linking against. When using caf_single > > from gfortran, then you will get link failures when you mix code compiled by > > gfortran < 15 and gfortran-15. But caf_single is anyhow only considered for > > testing. So why should one do this ? > > OK. > > > If your questions targets the users of this ABI, which to my knowledge is > > only OpenCoarrays at the moment, then the user will experience nothing. A > > mix of pre-gfortran-15 and gfortran-15 generated .o-files will link and > > work as expected, because OpenCoarrays provides all ABIs. We do not compile > > a gfortran-15 exclusive version of OpenCoarrays, i.e. all routines are > > present, fully functional and interoperable. > > Very good, then. > > >> I guess a link failure (plus an answer in stack exchange where the > >> explanation is given, so people can google it, and a mention in the > >> release notes) would be acceptable, but is there anything that > >> can be done in addition? > > > > I can provide an entry in release notes, if need be. Where do I have to do > > this? Never did. > > It is a separate repository from the gcc source, it can be found by > cloning git+ssh://you...@gcc.gnu.org/git/gcc-wwwdocs.git . > > Best regards (and a lot of thanks for the patch series!) > > Thomas > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Patch] Fortran: Improve gfc_array_kind for assumed rank; gfc_tree_array_size on 'tree'
Just to be clear: the following touches generic Fortran code and, hence,
needs Fortran FE review (still pending):
Tobias Burnus wrote:
(1) gfc_tree_array_size now can determine the array size not only from
the passed Fortran gfc_expr but also using a descriptor, passed as
gimple 'tree'.
(2) Adds missing GFC_ARRAY_ASSUMED_RANK_{ALLOCATABLE,POINTER{,_CONT}} […]
OK for mainline?
While changes to OpenMP-specific code in gfortran, it can be either
OpenMP or Fortran approval.* – In any case, code review is always
welcome, whether required or not, whether done by an approved
reviewer/maintainer or simple bystanders!
Tobias
(* Fortran only has reviewers (as some other parts of the compiler);
while other code parts have maintainers. The difference is whether one
can approve one own's patch or not. See MAINTAINERS for details.)
Re: [Patch] Fortran: Improve gfc_array_kind for assumed rank; gfc_tree_array_size on 'tree'
On 2/19/25 10:08 AM, Tobias Burnus wrote:
The attached patch does some ground-laying work for OpenMP
deep mapping - touching common gfortran code.
It does so by:
(1)gfc_tree_array_size now can determine the array size not only from
the passed Fortran gfc_expr but also using a descriptor, passed as
gimple 'tree'.
(2) Adds missingGFC_ARRAY_ASSUMED_RANK_{ALLOCATABLE,POINTER{,_CONT}} to
enum gfc_array_kind to complete the kinds – for non-assumed-rank, those
subtypes already existed, for assumed rank, the pointer/allocatable
flags were missing (and for pointer: contiguous, while allocatables are
always contigous).
Build and regtested on x86-64_gnu-linux.
OK for mainline?
Looks good Tobias. I don't know if anyone else was looking through it.
Jerry
* * *
When doing the change (2) back when I first created the patch, I
encountered an issue, which I could not fix quickly. Hence, I filed
https://gcc.gnu.org/PR104651 - see also the FIXME in the code which
should be IMHO be used but it causes fails. Although, the proper fix is
probably to change how CLASS/attributes in it are represented (cf. PR).
[I don't recall the details - and don't know more anymore than what's
in the FIXME comment and in the problem report.]
* * *
BACKGROUND/EXAMPLE
-> OpenMP + derived-type mapping with allocatable components
(i.e. why I need the modifications; for those changes, I will also
add testcases.)
Namely, assume:
type t
real, allocatable :: x(:)
real, pointer :: p(:)
end type t
type(t) :: var(4)
!$omp target enter data map(to:var)
This is supposed to copy 'var' onto an offloading device
(device = omp_get_default_device()) - by doing a deep
copying/mapping. Thus, the compiler needs to generate code
like - pseudocode:
map (to: var [size: 4*storage_size(type(t))])
for i = 1 to 4:
if (allocated (var(i)%x)
map (to: var(i)%x [size: size(var(i)%x) * sizeof(real)])
[plus attaching the just mapped data to the base_addr
of the array descriptor.]
Namely: var and also var(:)%x have to be copied to the device,
var(:)%p is not touched – as it is a pointer and not an allocatable.
Another example would be:
!$omp target
var(1)%x(2) = 7
!$omp end target
where 'map(tofrom:var)' is implicitly added, which happens
quite late in the game. Thus, the code handles the mapping
both by explicit and implicit mapping and does so very late.
(omp-low.cc calls back to the Fortran front-end to do the
work.)
* * *
Soon/next, I will post the patch that handles code above (for
nonpolymorphic allocatable components). However, if you want to
glance at the code, already you can find an older version at
* https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591144.html
And a re-based commit relative to GCC 14, applied to OG14
(devel/omp/gcc-14) at https://gcc.gnu.org/g:92c3af3d4f8
(or 'git log ' or 'git log devel/omp/gcc-14' in any of
your GCC repos).
Note that the to-be-posted patch will differ a bit as:
- the middle end bits are already in
- the CLASS/polymorphic handling will be removed.
- minor cleanup/fixes
Reason for not including polymorphism support:
* As the vtab is not handled, there is no benefit of having it.
Additionally, the patch changes what's in the vtable/vtab by
adding an entry, breaking all backward compatibility of vtabs.
Thus, I only want to add it when it works properly.
* On the OpenMP spec side, it is similar: OpenMP 6.0 clarified
that mapping polymorphic variables in Fortran is not supported
(5.x was unclear) but it added full support for shared-memory
part (data sharing clauses). Plus there is on-going work to
add polymorphism support to OpenMP 6.1.
[For 6.1, parts of the GCC polymorphism patch will be resurrected
in some way, but for now not having polymorphism is simply better!]
* * *
Tobias
Re: 6/7 [Fortran, Patch, Coarray, PR107635] Add transfer_between_remotes
Hi Andre, this patch broke Solaris bootstrap: /vol/gcc/src/hg/master/local/libgfortran/caf/single.c: In function ‘_gfortran_caf_transfer_between_remotes’: /vol/gcc/src/hg/master/local/libgfortran/caf/single.c:675:23: error: implicit declaration of function ‘alloca’ [-Wimplicit-function-declaration] 675 | transfer_desc = alloca (desc_size); | ^~ /vol/gcc/src/hg/master/local/libgfortran/caf/single.c:675:23: warning: incompatible implicit declaration of built-in function ‘alloca’ [-Wbuiltin-declaration-mismatch] /vol/gcc/src/hg/master/local/libgfortran/caf/single.c:680:20: warning: incompatible implicit declaration of built-in function ‘alloca’ [-Wbuiltin-declaration-mismatch] 680 | transfer_ptr = alloca (*opt_dst_charlen * src_size); |^~ make[3]: *** [Makefile:4675: caf/single.lo] Error 1 Solaris needs to include to get an alloca declaration. While this could be handled with AC_FUNC_ALLOCA (like libcpp does) or checking for alloca.h and including it if found (like libssp does), I guess there's a simpler way: several runtime libs use __builtin_alloca unconditionally (libgcc, libquadmath, libstdc++-v3). Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH] Fortran: initialize non-saved pointers with -fcheck=pointer [PR48958]
Dear all,
the attached simple patch addresses a small, left-over issue in the
above PR and was already OK'ed in the PR by Thomas. With it we
initialize the data component of a non-saved pointer variable when
-fcheck=pointer is specified, so that subsequent pointer checks
(e.g. for the SIZE intrinsic) trigger consistently and not randomly.
I plan to commit within 24h unless there are comments.
Regtested on x86_64-pc-linux-gnu. ON for mainline?
Thanks,
Harald
From eca02da7cfa3781727dfd1a0914b7d9d377b1511 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 20 Feb 2025 21:03:12 +0100
Subject: [PATCH] Fortran: initialize non-saved pointers with -fcheck=pointer
[PR48958]
PR fortran/48958
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_trans_deferred_array): Initialized the data
component of non-saved pointers when -fcheck=pointer is set.
gcc/testsuite/ChangeLog:
* gfortran.dg/pointer_init_13.f90: New test.
---
gcc/fortran/trans-array.cc| 7 --
gcc/testsuite/gfortran.dg/pointer_init_13.f90 | 24 +++
2 files changed, 29 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pointer_init_13.f90
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index ec627dddffd..27378c432f7 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -12122,8 +12122,11 @@ gfc_trans_deferred_array (gfc_symbol * sym, gfc_wrapped_block * block)
type = TREE_TYPE (descriptor);
}
- /* NULLIFY the data pointer, for non-saved allocatables. */
- if (GFC_DESCRIPTOR_TYPE_P (type) && !sym->attr.save && sym->attr.allocatable)
+ /* NULLIFY the data pointer for non-saved allocatables, or for non-saved
+ pointers when -fcheck=pointer is specified. */
+ if (GFC_DESCRIPTOR_TYPE_P (type) && !sym->attr.save
+ && (sym->attr.allocatable
+ || (sym->attr.pointer && (gfc_option.rtcheck & GFC_RTCHECK_POINTER
{
gfc_conv_descriptor_data_set (&init, descriptor, null_pointer_node);
if (flag_coarray == GFC_FCOARRAY_LIB && sym->attr.codimension)
diff --git a/gcc/testsuite/gfortran.dg/pointer_init_13.f90 b/gcc/testsuite/gfortran.dg/pointer_init_13.f90
new file mode 100644
index 000..ece423a9db6
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pointer_init_13.f90
@@ -0,0 +1,24 @@
+! { dg-do compile }
+! { dg-options "-fcheck=pointer -fdump-tree-optimized -O -fno-inline" }
+!
+! PR fortran/48958
+!
+! Initialize non-saved pointers with -fcheck=pointer to support runtime checks
+! of uses of possibly undefined pointers
+
+program p
+ implicit none
+ call s
+contains
+ subroutine s
+integer, pointer :: a(:)
+integer, pointer :: b(:) => NULL()
+if (size (a) /= 0) stop 1
+if (size (b) /= 0) stop 2
+print *, size (a)
+print *, size (b)
+ end
+end
+
+! { dg-final { scan-tree-dump-times "_gfortran_runtime_error_at" 1 "optimized" } }
+! { dg-final { scan-tree-dump-not "_gfortran_stop_numeric" "optimized" } }
--
2.43.0
