Re: [Ping x2 , Fortran, Patch, PR77518, (coarray), v4] Fix ICE in sizeof(coarray)

[Andre Vehreschild]

Hi Jerry,

thank you for the review. Committed as gcc-15-3062-g515730fd65a

Thanks again,
Andre

On Tue, 20 Aug 2024 09:16:50 -0700
Jerry D  wrote:

> On 8/20/24 5:35 AM, Andre Vehreschild wrote:
> > Hi all,
> >
> > pinging this patch.
> >
> > Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
> >
> > Regards,
> > Andre
> >
>
> Your approach looks reasonable so I think OK to push.
>
> Thanks,
>
> Jerry
>


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

Re: [Ping x2 , Fortran, Patch, PR77518, (coarray), v4] Fix ICE in sizeof(coarray)

[Paul Richard Thomas]

Indeed - thanks, Jerry.

I haven't had enough bandwidth to support gfortran these last few weeks and
will only be able to return to normal service in a couple of weeks.

Cheers

Paul


On Wed, 21 Aug 2024 at 08:42, Andre Vehreschild  wrote:

> Hi Jerry,
>
> thank you for the review. Committed as gcc-15-3062-g515730fd65a
>
> Thanks again,
> Andre
>
> On Tue, 20 Aug 2024 09:16:50 -0700
> Jerry D  wrote:
>
> > On 8/20/24 5:35 AM, Andre Vehreschild wrote:
> > > Hi all,
> > >
> > > pinging this patch.
> > >
> > > Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
> > >
> > > Regards,
> > > Andre
> > >
> >
> > Your approach looks reasonable so I think OK to push.
> >
> > Thanks,
> >
> > Jerry
> >
>
>
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
>

Re: [Fortran, Patch, PR86468, v1] Fix propagation of corank to array components in derived types.

[Andre Vehreschild]

Hi Harald,

thanks for the review. I have changed the style of the code. Interestingly did
the contrib/check_GNU_style.(py|sh) not complain on the old style nor on the new
style. I tend to just trust clang-format to do a reproducible job and stick
with that.

Committed as: gcc-15-3066-g723b30bee4e

Thanks again,
Andre

On Tue, 20 Aug 2024 22:32:32 +0200
Harald Anlauf  wrote:

> Hi Andre,
>
> Am 20.08.24 um 13:52 schrieb Andre Vehreschild:
> > Hi all,
> >
> > attached patch fixes an ICE in gimplify by assuring that the corank of a
> > non-pointer, non-coarray array component in a derived type is zero.
> > Previously (erroneously) the full corank of the type has been used. There
> > is one exception for pointer typed array components in coarray derived
> > types. These can be associated only to coarray array targets (compare F2018
> > C1024 and C1026). Therefore for those the corank is still propagated.
>
> the patch is OK for mainline, but the formatting violates the coding
> style here:
>
> @@ -2909,12 +2909,14 @@ gfc_get_derived_type (gfc_symbol * derived, int
> codimen)
> else
>   akind = GFC_ARRAY_ALLOCATABLE;
> /* Pointers to arrays aren't actually pointer types.  The
> -  descriptors are separate, but the data is common.  */
> -   field_type = gfc_build_array_type (field_type, c->as, akind,
> -  !c->attr.target
> -  && !c->attr.pointer,
> -  c->attr.contiguous,
> -  codimen);
> +  descriptors are separate, but the data is common.  Every
> +  array pointer in a coarray derived type needs to provide
> space
> +  for the coarray management, too.  Therefore treat coarrays
> +  and pointers to coarrays in derived types the same.  */
> +   field_type = gfc_build_array_type (
>  ^^^
> Please move this opening parenthesis to the next line,
> otherwise the indenting with emacs goes sideways.
>
> + field_type, c->as, akind, !c->attr.target &&
> !c->attr.pointer,
> + c->attr.contiguous,
> + c->attr.codimension || c->attr.pointer ? codimen : 0);
>   }
> else
>   field_type = gfc_get_nodesc_array_type (field_type, c->as,
>
>
> Thanks,
> Harald
>
> > Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
> >
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>


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

[Fortran, Patch, PR86468, v1] Follow up: Remove obsolete VIEW_CONVERT

[Andre Vehreschild]

Hi all,

attached small patch removes a VIEW_CONVERT that I erroneously inserted during
patching pr110033. PR86468 fixes the (co-)rank computation and therefore this
VIEW_CONVERT is IMO obsolete. I think it may cause hard to find runtime bugs in
the future and therefore like to remove it.

Regtests ok on x86_64-pc-linux-gnu. Ok for mainline?

Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 3a83901e64568967600d5ba643723ae2ad80e0ac Mon Sep 17 00:00:00 2001
From: Andre Vehreschild 
Date: Wed, 21 Aug 2024 11:22:57 +0200
Subject: [PATCH] [Fortran] Remove unnecessary view_convert obsoleted by
 [PR86468].

This patch removes an unnecessary view_convert in trans_associate to
prevent hard to find runtime errors in the future.  The view_convert was
erroneously introduced not understanding why ranks of the arrays to
assign are different.  The ranks are fixed by PR86468 now and the
view_convert is obsolete.

gcc/fortran/ChangeLog:

	PR fortran/86468

	* trans-stmt.cc (trans_associate_var): Remove superfluous
	view_convert.
---
 gcc/fortran/trans-stmt.cc | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index 023b1739b85..d92ca6477e4 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -2031,9 +2031,7 @@ trans_associate_var (gfc_symbol *sym, gfc_wrapped_block *block)
 			  gfc_class_data_get (GFC_DECL_SAVED_DESCRIPTOR (tmp)));
 	}
   else
-	gfc_add_modify (&se.pre, sym->backend_decl,
-			build1 (VIEW_CONVERT_EXPR,
-TREE_TYPE (sym->backend_decl), se.expr));
+	gfc_add_modify (&se.pre, sym->backend_decl, se.expr);

   if (unlimited)
 	{
--
2.46.0

Re: [Ping, Patch, Fortran, 77871, v1] Allow for class typed coarray parameter as dummy [PR77871]

[Andre Vehreschild]

Hi all,

pinging this patch for the first time.

Rebased and regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?

- Andre

On Thu, 15 Aug 2024 14:39:25 +0200
Andre Vehreschild  wrote:

> Hi all,
>
> attached patch fixes another regression on coarrays. This time for class typed
> coarrays as dummys.
>
> Regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
>
> Regards,
>   Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de


--
Andre Vehreschild * Email: vehre ad gmx dot de
From eeacd9a2c5cc4ddfe6201ad335adb0f48767fba1 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild 
Date: Thu, 15 Aug 2024 13:49:49 +0200
Subject: [PATCH] [Fortran] Allow for class type coarray parameters. [PR77871]

gcc/fortran/ChangeLog:

	PR fortran/77871

	* trans-expr.cc (gfc_conv_derived_to_class): Assign token when
	converting a coarray to class.
	(gfc_get_tree_for_caf_expr): For classes get the caf decl from
	the saved descriptor.
	(gfc_get_caf_token_offset):Assert that coarray=lib is set and
	cover more cases where the tree having the coarray token can be.
	* trans-intrinsic.cc (gfc_conv_intrinsic_caf_get): Use unified
	test for pointers.

gcc/testsuite/ChangeLog:

	* gfortran.dg/coarray/dummy_3.f90: New test.
---
 gcc/fortran/trans-expr.cc | 36 ---
 gcc/fortran/trans-intrinsic.cc|  2 +-
 gcc/testsuite/gfortran.dg/coarray/dummy_3.f90 | 33 +
 3 files changed, 58 insertions(+), 13 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/coarray/dummy_3.f90

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 8801a15c3a8..4681a131139 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -810,6 +810,16 @@ gfc_conv_derived_to_class (gfc_se *parmse, gfc_expr *e, gfc_symbol *fsym,
   /* Now set the data field.  */
   ctree = gfc_class_data_get (var);

+  if (flag_coarray == GFC_FCOARRAY_LIB && CLASS_DATA (fsym)->attr.codimension)
+{
+  tree token;
+  tmp = gfc_get_tree_for_caf_expr (e);
+  if (POINTER_TYPE_P (TREE_TYPE (tmp)))
+	tmp = build_fold_indirect_ref (tmp);
+  gfc_get_caf_token_offset (parmse, &token, nullptr, tmp, NULL_TREE, e);
+  gfc_add_modify (&parmse->pre, gfc_conv_descriptor_token (ctree), token);
+}
+
   if (optional)
 cond_optional = gfc_conv_expr_present (e->symtree->n.sym);

@@ -2368,6 +2378,10 @@ gfc_get_tree_for_caf_expr (gfc_expr *expr)

   if (expr->symtree->n.sym->ts.type == BT_CLASS)
 {
+  if (DECL_P (caf_decl) && DECL_LANG_SPECIFIC (caf_decl)
+	  && GFC_DECL_SAVED_DESCRIPTOR (caf_decl))
+	caf_decl = GFC_DECL_SAVED_DESCRIPTOR (caf_decl);
+
   if (expr->ref && expr->ref->type == REF_ARRAY)
 	{
 	  caf_decl = gfc_class_data_get (caf_decl);
@@ -2432,16 +2446,12 @@ gfc_get_caf_token_offset (gfc_se *se, tree *token, tree *offset, tree caf_decl,
 {
   tree tmp;

+  gcc_assert (flag_coarray == GFC_FCOARRAY_LIB);
+
   /* Coarray token.  */
   if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (caf_decl)))
-{
-  gcc_assert (GFC_TYPE_ARRAY_AKIND (TREE_TYPE (caf_decl))
-		== GFC_ARRAY_ALLOCATABLE
-		  || expr->symtree->n.sym->attr.select_type_temporary
-		  || expr->symtree->n.sym->assoc);
   *token = gfc_conv_descriptor_token (caf_decl);
-}
-  else if (DECL_LANG_SPECIFIC (caf_decl)
+  else if (DECL_P (caf_decl) && DECL_LANG_SPECIFIC (caf_decl)
 	   && GFC_DECL_TOKEN (caf_decl) != NULL_TREE)
 *token = GFC_DECL_TOKEN (caf_decl);
   else
@@ -2459,7 +2469,7 @@ gfc_get_caf_token_offset (gfc_se *se, tree *token, tree *offset, tree caf_decl,
   && (GFC_TYPE_ARRAY_AKIND (TREE_TYPE (caf_decl)) == GFC_ARRAY_ALLOCATABLE
 	  || GFC_TYPE_ARRAY_AKIND (TREE_TYPE (caf_decl)) == GFC_ARRAY_POINTER))
 *offset = build_int_cst (gfc_array_index_type, 0);
-  else if (DECL_LANG_SPECIFIC (caf_decl)
+  else if (DECL_P (caf_decl) && DECL_LANG_SPECIFIC (caf_decl)
 	   && GFC_DECL_CAF_OFFSET (caf_decl) != NULL_TREE)
 *offset = GFC_DECL_CAF_OFFSET (caf_decl);
   else if (GFC_TYPE_ARRAY_CAF_OFFSET (TREE_TYPE (caf_decl)) != NULL_TREE)
@@ -2526,11 +2536,13 @@ gfc_get_caf_token_offset (gfc_se *se, tree *token, tree *offset, tree caf_decl,
 }
   else if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (caf_decl)))
 tmp = gfc_conv_descriptor_data_get (caf_decl);
+  else if (INDIRECT_REF_P (caf_decl))
+tmp = TREE_OPERAND (caf_decl, 0);
   else
-   {
- gcc_assert (POINTER_TYPE_P (TREE_TYPE (caf_decl)));
- tmp = caf_decl;
-   }
+{
+  gcc_assert (POINTER_TYPE_P (TREE_TYPE (caf_decl)));
+  tmp = caf_decl;
+}

   *offset = fold_build2_loc (input_location, MINUS_EXPR, gfc_array_index_type,
 			fold_convert (gfc_array_index_type, *offset),
diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index 0632e3e4d2f..ceda7843fa9 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans-intrinsic.cc
@@ -1900,7 +1900,7 @@ gfc_conv_intrinsic_caf_get (gfc_se *se, gfc_expr *expr, tree lhs, tree lhs_kind,
   gf

[patch] libgomp: Add interop types and routines to OpenMP's headers and module

[Tobias Burnus]

This patch adds 'interop' to C/C++'s omp.h and Fortran's omp_lib.h and 
omp_lib module.


The implementation should match OpenMP 5.1 (which added interop) and 
also TR13; the Fortran routine support is new in TR13. It also adds 
'hsa' as foreign object enum/paramter, which is currently being added to 
the additional-definitions document.


* * *

The routine interface does not exactly match the OpenMP spec as some 
VALUE and BIND(C) and one c_int has been used to reduce pointless 
differences between OpenMP and C/C++.


This shouldn't affect the usage as almost no user will worries about the 
API used for a procedure reference. But if a user defines the routine 
interface him-/herself, this will fail. (But why should (s)he? There is 
'omp_lib.h' and the 'omp_lib' module, after all – and several items in 
those files are implementation defined.)


On the C/C++ side, there are also some differences (at least with TR13) 
with regards to unsigned vs. signed and to enum (of size __UINTPTR_T__) 
vs. 'typdef (u)intptr_t', but they shouldn't matter either (effectively 
same API) – and, again, there is a omp.h, which any sensible user should 
use.


* * *

While there is a stub implementation for the routines, to make them 
really useful, two things are missing: Support for the 'interop' 
directive in the compiler itself (+ a libgomp function for it) and 
supporting some foreign run time types in the libgomp plugin. Also 
missing is the documentation of the added routines in libgomp.texi. All 
of which will be added in later patches.


Build + tested on x86-64-gnu-linux (with offloading enabled but that's 
not yet relevant).


Comments, remarks, suggestions before I commit it?

Tobias
libgomp: Add interop types and routines to OpenMP's headers and module

This commit adds OpenMP 5.1+'s interop enumeration, type and routine
declarations to the C/C++ header file and, new in OpenMP TR13, also to
the Fortran module and omp_lib.h header file.

While a stub implementation is provided, only with foreign runtime
support by the libgomp GPU plugins and with the 'interop' directive,
this becomes really useful.

libgomp/ChangeLog:

	* fortran.c (omp_get_interop_str_, omp_get_interop_name_,
	omp_get_interop_type_desc_, omp_get_interop_rc_desc_): Add.
	* libgomp.map (GOMP_5.1.3): New; add interop routines.
	* omp.h.in: Add interop typedefs, enum and prototypes.
 	* omp_lib.f90.in: Add paramters and interfaces for interop.
	* omp_lib.h.in: Likewise; move F90 '&' to column 81 for
	-ffree-length-80.
	* target.c (omp_get_num_interop_properties, omp_get_interop_int,
	omp_get_interop_ptr, omp_get_interop_str, omp_get_interop_name,
	omp_get_interop_type_desc, omp_get_interop_rc_desc): Add.
	* testsuite/libgomp.c/interop-routines-1.c: New test.
	* testsuite/libgomp.fortran/interop-routines-1.F90: New test.
	* testsuite/libgomp.fortran/interop-routines-2.F90: New test.
	* testsuite/libgomp.fortran/interop-routines-3.F: New test.
	* testsuite/libgomp.fortran/interop-routines-4.F: New test.
	* testsuite/libgomp.fortran/interop-routines-5.F: New test.
	* testsuite/libgomp.fortran/interop-routines-6.F: New test.

 libgomp/fortran.c  |  41 
 libgomp/libgomp.map|  15 ++
 libgomp/omp.h.in   |  69 ++
 libgomp/omp_lib.f90.in |  99 +
 libgomp/omp_lib.h.in   | 167 --
 libgomp/target.c   |  91 
 libgomp/testsuite/libgomp.c/interop-routines-1.c   | 246 +
 .../libgomp.fortran/interop-routines-1.F90 | 222 +++
 .../libgomp.fortran/interop-routines-2.F90 |   3 +
 .../testsuite/libgomp.fortran/interop-routines-3.F |   2 +
 .../testsuite/libgomp.fortran/interop-routines-4.F |   4 +
 .../testsuite/libgomp.fortran/interop-routines-5.F |   4 +
 .../testsuite/libgomp.fortran/interop-routines-6.F |   4 +
 13 files changed, 945 insertions(+), 22 deletions(-)

diff --git a/libgomp/fortran.c b/libgomp/fortran.c
index cfbea32b022..b62a3f29916 100644
--- a/libgomp/fortran.c
+++ b/libgomp/fortran.c
@@ -102,6 +102,10 @@ ialias_redirect (omp_set_default_allocator)
 ialias_redirect (omp_get_default_allocator)
 ialias_redirect (omp_display_env)
 ialias_redirect (omp_fulfill_event)
+ialias_redirect (omp_get_interop_str)
+ialias_redirect (omp_get_interop_name)
+ialias_redirect (omp_get_interop_type_desc)
+ialias_redirect (omp_get_interop_rc_desc)
 #endif
 
 #ifndef LIBGOMP_GNU_SYMBOL_VERSIONING
@@ -807,4 +811,41 @@ omp_display_env_8_ (const int64_t *verbose)
   omp_display_env (!!*verbose);
 }
 
+void
+omp_get_interop_str_ (const char **res, size_t *res_len,
+		  const omp_interop_t interop,
+		  omp_interop_property_t property_id,
+		  omp_interop_rc_t *ret_code)
+{
+  *res = omp_get_interop_str (interop, property_id, ret_code);
+  *res_len = *res ? strlen (*res) : 0;
+}
+
+void
+omp_get_inter

Re: [Fortran, Patch, PR86468, v1] Follow up: Remove obsolete VIEW_CONVERT

[Steve Kargl]

On Wed, Aug 21, 2024 at 12:17:46PM +0200, Andre Vehreschild wrote:
> 
> attached small patch removes a VIEW_CONVERT that I erroneously inserted during
> patching pr110033. PR86468 fixes the (co-)rank computation and therefore this
> VIEW_CONVERT is IMO obsolete. I think it may cause hard to find runtime bugs 
> in
> the future and therefore like to remove it.
> 
> Regtests ok on x86_64-pc-linux-gnu. Ok for mainline?
> 

Yes.

-- 
Steve

Re: Installing gfortran-14

[John Harper]

Thank you Damian. Tried the first suggestion. It said I already had 
gfortran; it turned out to be version 13. Tried the second suggestion. My 
system has not heard of git. Managed to find gcc-14.2.0.tar so I am now 
struggling to do something with that.


On Tue, 20 Aug 2024, Damian Rouson wrote:


Date: Tue, 20 Aug 2024 23:34:50 +
From: Damian Rouson 
To: John Harper 
Cc: "fortran@gcc.gnu.org" 
Subject: Re: Installing gfortran-14
Resent-Date: Wed, 21 Aug 2024 11:35:39 +1200 (NZST)
Resent-From: 

You don't often get email from damian@archaeologic.codes. Learn why this is 
important
It has been a few years since I used Ubuntu. If I recall correctly, I think you 
can just use

sudo apt install gcc

and that will install gcc, g++, and gfortran.  My Linux knowledge is limited.  
I never figured out how to install a specific version of GCC on Ubuntu so I 
think you just get what you get.  However, what I liked about Ubuntu was that 
it seemed to be aggressive about installing more up-to-date versions of GCC 
than some other Linux distributions, so if it's an option, you might get a 
newer version of GCC by updating your Ubuntu kernel and then the above apt 
command again.  I think the latest version is Ubuntu 24.  FWIW, I mostly used 
the Lubuntu lightweight Ubuntu distribution.

If you really need GCC 14 and the above advice doesn't help, you might try 
running the OpenCoarrays installer script to build whatever version you want 
from source:

git clone https://github.com/sourceryinstitute/opencoarrays
cd opencoarrays
./install.sh --package gcc --install-version 14 --install-prefix 
 --num-threads 4

or run ./install.sh. --help for additional options or shorter versions of the 
above options.

I hope this is all helpful.

Damian



On Tue, Aug 20, 2024 at 4:08 PM John Harper 
mailto:john.har...@vuw.ac.nz>> wrote:
I did this in my Ubuntu 22.04 system with no trouble:

(lf) john:~$ sudo add-apt-repository ppa:ubuntu-toolchain-r/test

but the next step failed:

(lf) john:~$ sudo apt install gfortran-14
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package gfortran-14 is not available, but is referred to by another
package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'gfortran-14' has no installation candidate
(lf) john:~$

What should I have done?

-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz




-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz

Re: Installing gfortran-14

[Thomas Koenig]

Hi John,

Thank you Damian. Tried the first suggestion. It said I already had 
gfortran; it turned out to be version 13. Tried the second suggestion. 
My system has not heard of git. Managed to find gcc-14.2.0.tar so I am 
now struggling to do something with that.


Assuming you have the top level of the gcc sources (where the configure
script resides) in the ~/Gcc directory, you can do the following:

$ cd ~/Gcc
$ contrib/download-prerequisites
$ cd
$ mkdir Gcc-build
$ cd Gcc-build
$ ../Gcc/configure --prefix=$HOME --enable-languages=c,c++,fortran
$ make -j8
$ make -j4 install

The --prefix=$HOME option will install binaries, support libraries etc
under your home directory; if you want to put it somewhere else, specify
it as an alternative argument.

The build directory has to be separate from the source directory,
this is a frequent source of weird build errors.  Adjust directory
names to taste.

The "-j8" option will use eight parallel compilations if possible;
adjust to approximately the number of CPUs on your system. Having
2GB memory per job is quite sufficient.

Hope this helps

Thomas