Re: Interested in participating in Fortran study to compile very large modules

[William Carter via Fortran]

Hello.  I have a windows 10 home 64 bit operating system.   Thanks for getting 
back to me 

Sent from Yahoo Mail on Android 
 
  On Sun, Apr 24, 2022 at 9:39, Arjen Markus wrote:  
 MicroSoft's Fortran compiler is a very old compiler that has not been 
maintained in a very long time. The gfortran compiler and the Intel Fortran 
oneAPI compiler, both freely available, would easily handle such arrays as you 
mention. What system are you running on?
Regards,
Arjen

Op vr 22 apr. 2022 om 22:46 schreef William Carter via Fortran 
:

Hello,

I am an engineer for the nuclear power industry.  As part of my master’s thesis 
I developed a model of a fuel pin using Fortran.  At the time I was working 
with a cheap Microsoft compiler.  It was version 5.1 if I remember correctly.  
My model does 3D finite differencing and is rather demanding on the compiler.  
My Microsoft compiler was pretty limiting on the size of the modules I could 
compile.  Typically I was working with a 7x7x7 spatial array with a 5 
properties at each node.  Everything was in double precision.  So it was 
7x7x7x5.  I could juggle these around, but I had to say within this maximum or 
the compiler would not work.  I would like to work with MUCH larger arrays.  I 
am thinking 100x100x100x5.  Again in double precision. So I need a better 
compiler.  Can you help?

Regards,

Bill Carter


Sent from Mail for Windows


  

[pushed] testsuite: add additional option to force DSE execution [PR103662]

[Mikael Morin]

I have just pushed the attached fix for two UNRESOLVED checks at 
-O0 that I hadn’t seen.From 6cc26f3037a18b9a958b4ac2a1363149a7fccd39 Mon Sep 17 00:00:00 2001
From: Mikael Morin 
Date: Mon, 25 Apr 2022 13:14:20 +0200
Subject: [pushed] =?UTF-8?q?testsuite:=C2=A0add=20additional=20option=20to?=
 =?UTF-8?q?=20force=20DSE=20execution=20[PR103662]?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This fixes a dump tree match check that is UNRESOLVED with the -O0
optimization option, as the optimization pass corresponding to the
dump file is not run at -O0, and the dump is not generated.

	PR fortran/103662

gcc/testsuite/ChangeLog:

	* gfortran.dg/unlimited_polymorphic_3.f03: Force execution of
	the DSE optimization pass.
---
 gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03 b/gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03
index 780d68cdd87..4104de6ac68 100644
--- a/gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03
+++ b/gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03
@@ -1,5 +1,5 @@
 ! { dg-do run }
-! { dg-additional-options "-fdump-tree-dse-details" }
+! { dg-additional-options "-ftree-dse -fdump-tree-dse-details" }
 !
 ! Check that pointer assignments allowed by F2003:C717
 ! work and check null initialization of CLASS(*) pointers.
-- 
2.35.1

Re: [pushed] testsuite: add additional option to force DSE execution [PR103662]

[Jakub Jelinek via Fortran]

On Mon, Apr 25, 2022 at 01:38:25PM +0200, Mikael Morin wrote:
> I have just pushed the attached fix for two UNRESOLVED checks at -O0 that I
> hadn’t seen.

I don't like forcing of DSE in -O0 compilation, wouldn't it be better
to just not check the dse dump at -O0 like in the following patch?

Even better would be to check that the z._data = stores are both present
in *.optimized dump, but that doesn't really work at -O2 or above because
we inline the functions and optimize it completely away (both the stores
and corresponding reads).

The first hunk is needed so that __OPTIMIZE__ effective target works in
Fortran testsuite, otherwise one gets a pedantic error and __OPTIMIZE__
is considered not to match at all.

2022-04-25  Jakub Jelinek  

PR fortran/103662
* lib/target-supports.exp (check_effective_target___OPTIMIZE__): Add
a var definition to avoid pedwarn about empty translation unit.
* gfortran.dg/unlimited_polymorphic_3.f03: Remove -ftree-dse from
dg-additional-options, guard scan-tree-dump-not directives on
__OPTIMIZE__ target.

--- gcc/testsuite/lib/target-supports.exp.jj2022-04-22 13:36:56.150960826 
+0200
+++ gcc/testsuite/lib/target-supports.exp   2022-04-25 14:06:21.620537483 
+0200
@@ -11770,6 +11770,7 @@ proc check_effective_target___OPTIMIZE__
#ifndef __OPTIMIZE__
# error nein
#endif
+   int optimize;
 } [current_compiler_flags]]
 }
 
--- gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03.jj2022-04-25 
13:54:38.320309119 +0200
+++ gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03   2022-04-25 
14:04:01.346486431 +0200
@@ -1,5 +1,5 @@
 ! { dg-do run }
-! { dg-additional-options "-ftree-dse -fdump-tree-dse-details" }
+! { dg-additional-options "-fdump-tree-dse-details" }
 !
 ! Check that pointer assignments allowed by F2003:C717
 ! work and check null initialization of CLASS(*) pointers.
@@ -71,5 +71,5 @@ end subroutine foo_sq
 ! We used to produce multiple independant types for the unlimited polymorphic
 ! descriptors (types for class(*)) which caused stores to them to be seen as
 ! useless.
-! { dg-final { scan-tree-dump-not "Deleted dead store: z._data = &w" "dse1" } }
-! { dg-final { scan-tree-dump-not "Deleted dead store: z._data = &x" "dse1" } }
+! { dg-final { scan-tree-dump-not "Deleted dead store: z._data = &w" "dse1" { 
target __OPTIMIZE__ } } }
+! { dg-final { scan-tree-dump-not "Deleted dead store: z._data = &x" "dse1" { 
target __OPTIMIZE__ } } }


Jakub

Re: Interested in participating in Fortran study to compile very large modules

[Arjen Markus via Fortran]

There are various solutions to install gfortran (or in general the GCC
compiler suite) on Windows: Cygwin and MinGW-w64/MSYS2 are both
environments that mimick to a certain extent Linux and allow you to manage
all manner of packages, among which the GCC compiler suite. I use both but
I also use the installation from equation.com -
http://www.equation.com/servlet/equation.cmd?fa=fortran. You can get Intel
Fortran oneAPI from Intel -
https://www.intel.com/content/www/us/en/developer/tools/oneapi/fortran-compiler.html#gs.xy9u8f.


General questions about Fortran: the comp.lang.fortran newsgroup or, a bit
more modern, Fortran discourse - https://fortran-lang.discourse.group/

Regards,

Arjen

Op ma 25 apr. 2022 om 12:41 schreef William Carter :

> Hello.  I have a windows 10 home 64 bit operating system.   Thanks for
> getting back to me
>
> Sent from Yahoo Mail on Android
> 
>
> On Sun, Apr 24, 2022 at 9:39, Arjen Markus
>  wrote:
> MicroSoft's Fortran compiler is a very old compiler that has not been
> maintained in a very long time. The gfortran compiler and the Intel Fortran
> oneAPI compiler, both freely available, would easily handle such arrays as
> you mention. What system are you running on?
>
> Regards,
>
> Arjen
>
> Op vr 22 apr. 2022 om 22:46 schreef William Carter via Fortran <
> fortran@gcc.gnu.org>:
>
> Hello,
>
> I am an engineer for the nuclear power industry.  As part of my master’s
> thesis I developed a model of a fuel pin using Fortran.  At the time I was
> working with a cheap Microsoft compiler.  It was version 5.1 if I remember
> correctly.  My model does 3D finite differencing and is rather demanding on
> the compiler.  My Microsoft compiler was pretty limiting on the size of the
> modules I could compile.  Typically I was working with a 7x7x7 spatial
> array with a 5 properties at each node.  Everything was in double
> precision.  So it was 7x7x7x5.  I could juggle these around, but I had to
> say within this maximum or the compiler would not work.  I would like to
> work with MUCH larger arrays.  I am thinking 100x100x100x5.  Again in
> double precision. So I need a better compiler.  Can you help?
>
> Regards,
>
> Bill Carter
>
>
> Sent from Mail for Windows
>
>

Re: [pushed] testsuite: add additional option to force DSE execution [PR103662]

[Mikael Morin]

Le 25/04/2022 à 14:12, Jakub Jelinek a écrit :

On Mon, Apr 25, 2022 at 01:38:25PM +0200, Mikael Morin wrote:

I have just pushed the attached fix for two UNRESOLVED checks at -O0 that I
hadn’t seen.


I don't like forcing of DSE in -O0 compilation, wouldn't it be better
to just not check the dse dump at -O0 like in the following patch?

Certainly better.  I actually looked for something alike already 
existing before trying to write a conditional in the dg-final code and 
finally deciding to go the easy way.



Even better would be to check that the z._data = stores are both present
in *.optimized dump, but that doesn't really work at -O2 or above because
we inline the functions and optimize it completely away (both the stores
and corresponding reads).


Yes, and global optimization is already checked by test execution anyway.


The first hunk is needed so that __OPTIMIZE__ effective target works in
Fortran testsuite, otherwise one gets a pedantic error and __OPTIMIZE__
is considered not to match at all.


Maybe worth putting as code comment.

OK from my side, thanks.

[OG11-committed][stage1-patch] Fortran: Fix finalization resolution with deep copy (was: [Patch][Stage 1] Fortran/OpenMP: Support mapping of DT with allocatable components)

[Tobias Burnus]

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 c6daf2090d48bc794c6809a5d98e8d9a583346bd
Author: Tobias Burnus 
Date:   Mon Apr 25 15:12:01 2022 +0200

Fortran: Fix finalization resolution with deep copy

Follow-up patch to
"Fortran/OpenMP: Support mapping of DT with allocatable components"
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591144.html

gcc/fortran/ChangeLog:

* resolve.c (gfc_resolve_finalizers): Also resolve allocatable comps.

gcc/testsuite/ChangeLog:

* gfortran.dg/finalize_38.f90: New test.
---
 gcc/fortran/resolve.c |  11 ++-
 gcc/testsuite/gfortran.dg/finalize_38.f90 | 135 ++
 2 files changed, 143 insertions(+), 3 deletions(-)

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 59faa4c119d..10c89de0eaa 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -13578,11 +13578,16 @@ gfc_resolve_finalizers (gfc_symbol* derived, bool *finalizable)
   if (parent)
 gfc_resolve_finalizers (parent, finalizable);
 
-  /* Ensure that derived-type components have a their finalizers resolved.  */
+  /* Ensure that derived-type components have a their finalizers resolved;
+ 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)
+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))
diff --git a/gcc/testsuite/gfortran.dg/finalize_38.f90 b/gcc/testsuite/gfortran.dg/finalize_38.f90
new file mode 100644
index 000..442e1753311
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/finalize_38.f90
@@ -0,0 +1,135 @@
+! { dg-do compile }
+!
+! Check finalization
+!
+module Real_2D__Form
+
+  implicit none
+  private
+  
+  integer, parameter :: &
+KDR = kind ( 1.0d0 ), &
+KDI = kind ( 1 ), &
+KDL = kind ( .true. )
+
+  type, public :: Real_2D_Form
+real ( KDR ), dimension ( :, : ), allocatable :: &
+  Value
+  contains
+procedure, private, pass :: &
+  Initialize_R_2D
+procedure, private, pass :: &
+  Initialize_R_2D_FromValue
+procedure, private, pass :: &
+  Initialize_R_2D_Copy
+generic :: &
+  Initialize &
+=> Initialize_R_2D, Initialize_R_2D_FromValue, Initialize_R_2D_Copy
+final :: &
+  Finalize_R_2D
+  end type Real_2D_Form
+  
+  type, public :: Real_2D_2D_Form
+type ( Real_2D_Form ), dimension ( :

Re: Interested in participating in Fortran study to compile very large modules

[William Carter via Fortran]

 Thank you very much
On Monday, April 25, 2022, 08:13:44 AM CDT, Arjen Markus 
 wrote:  
 
 There are various solutions to install gfortran (or in general the GCC 
compiler suite) on Windows: Cygwin and MinGW-w64/MSYS2 are both environments 
that mimick to a certain extent Linux and allow you to manage all manner of 
packages, among which the GCC compiler suite. I use both but I also use the 
installation from equation.com - 
http://www.equation.com/servlet/equation.cmd?fa=fortran. You can get Intel 
Fortran oneAPI from Intel - 
https://www.intel.com/content/www/us/en/developer/tools/oneapi/fortran-compiler.html#gs.xy9u8f.
 

General questions about Fortran: the comp.lang.fortran newsgroup or, a bit more 
modern, Fortran discourse - https://fortran-lang.discourse.group/
Regards,
Arjen

Op ma 25 apr. 2022 om 12:41 schreef William Carter :

Hello.  I have a windows 10 home 64 bit operating system.   Thanks for getting 
back to me 

Sent from Yahoo Mail on Android 
 
  On Sun, Apr 24, 2022 at 9:39, Arjen Markus wrote:  
 MicroSoft's Fortran compiler is a very old compiler that has not been 
maintained in a very long time. The gfortran compiler and the Intel Fortran 
oneAPI compiler, both freely available, would easily handle such arrays as you 
mention. What system are you running on?
Regards,
Arjen

Op vr 22 apr. 2022 om 22:46 schreef William Carter via Fortran 
:

Hello,

I am an engineer for the nuclear power industry.  As part of my master’s thesis 
I developed a model of a fuel pin using Fortran.  At the time I was working 
with a cheap Microsoft compiler.  It was version 5.1 if I remember correctly.  
My model does 3D finite differencing and is rather demanding on the compiler.  
My Microsoft compiler was pretty limiting on the size of the modules I could 
compile.  Typically I was working with a 7x7x7 spatial array with a 5 
properties at each node.  Everything was in double precision.  So it was 
7x7x7x5.  I could juggle these around, but I had to say within this maximum or 
the compiler would not work.  I would like to work with MUCH larger arrays.  I 
am thinking 100x100x100x5.  Again in double precision. So I need a better 
compiler.  Can you help?

Regards,

Bill Carter


Sent from Mail for Windows


  

  

Re: [pushed] testsuite: add additional option to force DSE execution [PR103662]

[Bernhard Reutner-Fischer via Fortran]

On 25 April 2022 14:12:30 CEST, Jakub Jelinek via Fortran  
wrote:
>On Mon, Apr 25, 2022 at 01:38:25PM +0200, Mikael Morin wrote:
>> I have just pushed the attached fix for two UNRESOLVED checks at -O0 that I
>> hadn’t seen.
>
>I don't like forcing of DSE in -O0 compilation, wouldn't it be better
>to just not check the dse dump at -O0 like in the following patch?

As Mikael already said, that's preferable indeed.

>
>Even better would be to check that the z._data = stores are both present
>in *.optimized dump, but that doesn't really work at -O2 or above because
>we inline the functions and optimize it completely away (both the stores
>and corresponding reads).
>
>The first hunk is needed so that __OPTIMIZE__ effective target works in
>Fortran testsuite, otherwise one gets a pedantic error and __OPTIMIZE__
>is considered not to match at all.
>
>2022-04-25  Jakub Jelinek  
>
>   PR fortran/103662
>   * lib/target-supports.exp (check_effective_target___OPTIMIZE__): Add
>   a var definition to avoid pedwarn about empty translation unit.
>   * gfortran.dg/unlimited_polymorphic_3.f03: Remove -ftree-dse from
>   dg-additional-options, guard scan-tree-dump-not directives on
>   __OPTIMIZE__ target.
>
>--- gcc/testsuite/lib/target-supports.exp.jj   2022-04-22 13:36:56.150960826 
>+0200
>+++ gcc/testsuite/lib/target-supports.exp  2022-04-25 14:06:21.620537483 
>+0200
>@@ -11770,6 +11770,7 @@ proc check_effective_target___OPTIMIZE__
>   #ifndef __OPTIMIZE__
>   # error nein

Hmz. I _think_ that was /me and reading it again now, we should should not 
bluntly say nein but more something like
unwilling to ignore __OPTIMIZE__, dude

or anything more descriptive and universally understandably I assume.

>   #endif
>+  int optimize;

a plain ; won't cut it. int dummy, maybe though. There is probably a lot more 
of these, aren't there?

thanks,

> } [current_compiler_flags]]
> }
> 
>--- gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03.jj   2022-04-25 
>13:54:38.320309119 +0200
>+++ gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03  2022-04-25 
>14:04:01.346486431 +0200
>@@ -1,5 +1,5 @@
> ! { dg-do run }
>-! { dg-additional-options "-ftree-dse -fdump-tree-dse-details" }
>+! { dg-additional-options "-fdump-tree-dse-details" }
> !
> ! Check that pointer assignments allowed by F2003:C717
> ! work and check null initialization of CLASS(*) pointers.
>@@ -71,5 +71,5 @@ end subroutine foo_sq
> ! We used to produce multiple independant types for the unlimited polymorphic
> ! descriptors (types for class(*)) which caused stores to them to be seen as
> ! useless.
>-! { dg-final { scan-tree-dump-not "Deleted dead store: z._data = &w" "dse1" } 
>}
>-! { dg-final { scan-tree-dump-not "Deleted dead store: z._data = &x" "dse1" } 
>}
>+! { dg-final { scan-tree-dump-not "Deleted dead store: z._data = &w" "dse1" { 
>target __OPTIMIZE__ } } }
>+! { dg-final { scan-tree-dump-not "Deleted dead store: z._data = &x" "dse1" { 
>target __OPTIMIZE__ } } }
>
>
>   Jakub
>

Re: [PATCH] fortran: Fix up gfc_trans_oacc_construct [PR104717]

[Thomas Schwinge]

Hi!

On 2022-04-20T19:06:17+0200, Jakub Jelinek  wrote:
> So that move_sese_region_to_fn works properly, OpenMP/OpenACC constructs
> for which that function is invoked need an extra artificial BIND_EXPR
> around their body so that we move all variables of the bodies.
>
> The C/C++ FEs do that both for OpenMP constructs like OMP_PARALLEL, OMP_TASK
> or OMP_TARGET and for OpenACC constructs that behave similarly to
> OMP_TARGET, but the Fortran FE only does that for OpenMP constructs.
>
> The following patch does that for OpenACC constructs too.
> This fixes ICE on the attached testcase.

ACK, thanks.

I do see that over the past years, there have been a number of similar
fixes been applied for other OMP constructs -- maybe that interface
should generally be made more obvious and fool-proof?

> Unfortunately, it also regresses
> FAIL: gfortran.dg/goacc/privatization-1-compute-loop.f90   -O  (test for 
> excess errors)
> FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
> -DACC_MEM_SHARED=1 -foffload=disable  -O0  (test for excess errors)
> FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
> -DACC_MEM_SHARED=1 -foffload=disable  -O1  (test for excess errors)
> FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
> -DACC_MEM_SHARED=1 -foffload=disable  -O2  (test for excess errors)
> FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
> -DACC_MEM_SHARED=1 -foffload=disable  -O3 -fomit-frame-pointer -funroll-loops 
> -fpeel-loops -ftracer -finline-functions  (test for excess errors)
> FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
> -DACC_MEM_SHARED=1 -foffload=disable  -O3 -g  (test for excess errors)
> FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
> -DACC_MEM_SHARED=1 -foffload=disable  -Os  (test for excess errors)
> Those emits emit tons of various messages and now there are some extra ones,

I've fixed these up.

> the previous as well as new ones are mostly on artificial variables created
> by the compiler, so I wonder if we should emit those at all.

Yes, I did wonder about that, too.  (This affects a lot of test cases.)

> Anyway, here it is the patch, appart from those regressions passed
> bootstrap/regtested on powerpc64le-linux.
>
> 2022-04-20  Jakub Jelinek  
>
>   PR fortran/104717
>   * trans-openmp.cc (gfc_trans_oacc_construct): Wrap construct body
>   in an extra BIND_EXPR.
>
>   * gfortran.dg/goacc/pr104717.f90: New test.
>
> --- gcc/fortran/trans-openmp.cc.jj2022-04-06 09:59:32.729654664 +0200
> +++ gcc/fortran/trans-openmp.cc   2022-04-20 12:48:19.773402677 +0200
> @@ -,7 +,9 @@ gfc_trans_oacc_construct (gfc_code *code
>gfc_start_block (&block);
>oacc_clauses = gfc_trans_omp_clauses (&block, code->ext.omp_clauses,
>   code->loc, false, true);
> +  pushlevel ();
>stmt = gfc_trans_omp_code (code->block->next, true);
> +  stmt = build3_v (BIND_EXPR, NULL, stmt, poplevel (1, 0));
>stmt = build2_loc (gfc_get_location (&code->loc), construct_code,
>void_type_node, stmt, oacc_clauses);
>gfc_add_expr_to_block (&block, stmt);
> --- gcc/testsuite/gfortran.dg/goacc/pr104717.f90.jj   2022-04-20 
> 12:53:54.002748265 +0200
> +++ gcc/testsuite/gfortran.dg/goacc/pr104717.f90  2022-04-20 
> 12:53:12.811321862 +0200
> @@ -0,0 +1,22 @@
> +! PR fortran/104717
> +! { dg-do compile }
> +! { dg-options "-O1 -fopenacc -fstack-arrays" }

As the ICE was "during IPA pass: pta", I've added an explicit '-fipa-pta'
here.

> +
> +program main
> +  implicit none (type, external)
> +  integer :: j
> +  integer, allocatable :: A(:)
> +
> +  A = [(3*j, j=1, 10)]
> +  call foo (A, size(A))
> +  deallocate (A)
> +contains
> +  subroutine foo (array, nn)
> +integer :: i, nn
> +integer :: array(nn)
> +
> +!$acc parallel copyout(array)
> +array = [(-i, i = 1, nn)]
> +!$acc end parallel
> +  end subroutine foo
> +end

Pushed to master branch commit b2202431910e30d8505c94d1cb9341cac7080d10
"fortran: Fix up gfc_trans_oacc_construct [PR104717]", see attached.


Grüße
 Thomas


-
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
>From b2202431910e30d8505c94d1cb9341cac7080d10 Mon Sep 17 00:00:00 2001
From: Jakub Jelinek 
Date: Wed, 20 Apr 2022 19:06:17 +0200
Subject: [PATCH] fortran: Fix up gfc_trans_oacc_construct [PR104717]

So that move_sese_region_to_fn works properly, OpenMP/OpenACC constructs
for which that function is invoked need an extra artificial BIND_EXPR
around their body so that we move all variables of the bodies.

The C/C++ FEs do that both for OpenMP constructs like OMP_PARALLEL, OMP_TASK
or OMP_TARGET and for OpenACC constructs that behave

Re: Fortran compiler

[Elliot Cramer]

Windows 10; how can we do this?
Elliot

On 4/23/2022 10:00 PM, Jerry D wrote:
> Elliot,
>
> Let me know what system you want the compiler to run on?
>
> Linux, Windows, PowerPC?
>
> I can guide you through installing on some of these.
>
> Usually we build it from source. However, many linux distributions
> have packages you can install easily.
>
> Cheers,
>
> Jerry
>
> On 4/23/22 9:31 AM, Elliot Cramer wrote:
>> A few years ago I started converting a large old Fortran program
>> which I had running on an IBM 7040 and then on a 360. I have a
>> copy of Lahey Fortran and ran into a compiler bug and gave up on
>> it. How can I download your compiler and get documentation. I
>> don't understand what I've read on the internetThanksElliot
>>
>> Sent from AT&T Yahoo Mail on Android
>

-- 

Elliot M. Cramer
PO 428
Chapel Hill, NC 27514

919-942-2503

Professor Emeritus
Department of Psychology
University of North Carolina at Chapel Hill

ecra...@alum.mit.edu

Websites  
http://www.ourpaws.info/cramer
http://www.friendsofocas.org

Re: Fortran compiler

[Arjen Markus via Fortran]

An alternative is to use a prebuilt distribution. See my answer to William
Carter.

Regards,

Arjen

Op di 26 apr. 2022 om 03:57 schreef Elliot Cramer <
elliottcra...@bellsouth.net>:

> Windows 10; how can we do this?
> Elliot
>
> On 4/23/2022 10:00 PM, Jerry D wrote:
> > Elliot,
> >
> > Let me know what system you want the compiler to run on?
> >
> > Linux, Windows, PowerPC?
> >
> > I can guide you through installing on some of these.
> >
> > Usually we build it from source. However, many linux distributions
> > have packages you can install easily.
> >
> > Cheers,
> >
> > Jerry
> >
> > On 4/23/22 9:31 AM, Elliot Cramer wrote:
> >> A few years ago I started converting a large old Fortran program
> >> which I had running on an IBM 7040 and then on a 360. I have a
> >> copy of Lahey Fortran and ran into a compiler bug and gave up on
> >> it. How can I download your compiler and get documentation. I
> >> don't understand what I've read on the internetThanksElliot
> >>
> >> Sent from AT&T Yahoo Mail on Android
> >
>
> --
>
> Elliot M. Cramer
> PO 428
> Chapel Hill, NC 27514
>
> 919-942-2503
>
> Professor Emeritus
> Department of Psychology
> University of North Carolina at Chapel Hill
>
> ecra...@alum.mit.edu
>
> Websites
> http://www.ourpaws.info/cramer
> http://www.friendsofocas.org
>
>