Re: Fortran compiler

[Holcomb, Katherine A (kah3f) via Fortran]

Hi Elliot,

Did you look at my online instructions?  You can also use a prebuilt 
distribution as Arjen suggests.  If you’re not actually on the mailing list but 
just sending to it so didn’t see that, he recommended 
http://www.equation.com/servlet/equation.cmd?fa=fortran 
. You would still need 
to make sure your PATH is set so that gfortran and the other binaries you’d 
need are visible.

Unless you are adept with the Windows command line, you should look into a 
graphical development environment.  The problem with those is that most don’t 
support Fortran well or at all.  The two free, cross-platform ones I know that 
do are Geany and Code::Blocks.  Geany is more like a nice editor with some 
buttons for compiling and running (and it can run a Makefile) whereas 
Code::Blocks is closer to a traditional IDE.  Both may expect you to be using 
gfortran and would require some configuration if you wanted to use the Intel 
oneAPI option.  Easy to do, but an extra step to keep in mind.

VSCode is all the rage but I fought with it just to try to use it for C++ and 
didn’t want even to try Fortran.

> On Apr 25, 2022, at 9:57 PM, Elliot Cramer  
> wrote:
> 
> 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
> 



smime.p7s
Description: S/MIME cryptographic signature

[PATCH] fortran: Avoid infinite self-recursion [PR105381]

[Mikael Morin]

Hello,

this is a fix for the regression I recently introduced with the PR102043 
patch.  It is an infinite recursion problem.  I can’t see the memory 
consumption that Harald reported; maybe he doesn’t use the default 
optimization level to build the compiler.


Regression tested on x86_64-pc-linux-gnu.
I plan to push it tonight.From 85d57fb88203697d7e52d5f1f148eab35e4f7486 Mon Sep 17 00:00:00 2001
From: Mikael Morin 
Date: Tue, 26 Apr 2022 13:05:32 +0200
Subject: [PATCH] fortran: Avoid infinite self-recursion [PR105381]
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Dummy array decls are local decls different from the argument decl
accessible through GFC_DECL_SAVED_DESCRIPTOR.  If the argument decl has
a DECL_LANG_SPECIFIC set, it is copied over to the local decl at the
time the latter is created, so that the DECL_LANG_SPECIFIC object is
shared between local dummy decl and argument decl, and thus the
GFC_DECL_SAVED_DESCRIPTOR of the argument decl is the argument decl
itself.

The r12-8230-g7964ab6c364c410c34efe7ca2eba797d36525349 change introduced
the non_negative_strides_array_p predicate which recurses through
GFC_DECL_SAVED_DESCRIPTOR to avoid seeing dummy decls as purely local
decls.  As the GFC_DECL_SAVED_DESCRIPTOR of the argument decl is itself,
this can cause infinite recursion.

This change adds a check to avoid infinite recursion.

	PR fortran/102043
	PR fortran/105381

gcc/fortran/ChangeLog:

	* trans-array.cc (non_negative_strides_array_p): Don’t recurse
	if the next argument is the same as the current.

gcc/testsuite/ChangeLog:

	* gfortran.dg/character_array_dummy_1.f90: New test.
---
 gcc/fortran/trans-array.cc|  3 ++-
 .../gfortran.dg/character_array_dummy_1.f90   | 21 +++
 2 files changed, 23 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/character_array_dummy_1.f90

diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index e4b6270ccf8..e0070aa080d 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -3698,7 +3698,8 @@ non_negative_strides_array_p (tree expr)
   if (DECL_P (expr)
   && DECL_LANG_SPECIFIC (expr))
 if (tree orig_decl = GFC_DECL_SAVED_DESCRIPTOR (expr))
-  return non_negative_strides_array_p (orig_decl);
+  if (orig_decl != expr)
+	return non_negative_strides_array_p (orig_decl);
 
   return true;
 }
diff --git a/gcc/testsuite/gfortran.dg/character_array_dummy_1.f90 b/gcc/testsuite/gfortran.dg/character_array_dummy_1.f90
new file mode 100644
index 000..da5ed636f4f
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/character_array_dummy_1.f90
@@ -0,0 +1,21 @@
+! { dg-do compile }
+!
+! PR fortran/105381
+! Infinite recursion with array references of character dummy arguments.
+!
+! Contributed by Harald Anlauf 
+
+MODULE m
+  implicit none
+  integer,  parameter :: ncrit  =  8
+  integer,  parameter :: nterm  =  7
+contains
+
+  subroutine new_thin_rule (rule1)
+character(*),intent(in) ,optional :: rule1(ncrit)
+character(len=8) :: rules (ncrit,nterm)
+rules = ''
+if (present (rule1)) rules(:,1) = rule1  ! <-- compile time hog
+  end subroutine new_thin_rule
+
+end module m
-- 
2.35.1

Re: [PATCH] fortran: Avoid infinite self-recursion [PR105381]

[Tobias Burnus]

LGTM - however:

On 26.04.22 14:38, Mikael Morin wrote:

--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -3698,7 +3698,8 @@ non_negative_strides_array_p (tree expr)
if (DECL_P (expr)
&& DECL_LANG_SPECIFIC (expr))
  if (tree orig_decl = GFC_DECL_SAVED_DESCRIPTOR (expr))
-  return non_negative_strides_array_p (orig_decl);
+  if (orig_decl != expr)
+ return non_negative_strides_array_p (orig_decl);


Is the if()if()if() cascade really needed? I can see a reason that an
extra 'if' is preferred for the variable declaration of orig_decl, but
can't we at least put the new 'orig_decl != expr' with an '&&' into the
same if as the decl/in the second if? Besides clearer, it also avoids
further identing the return line.

Thanks,

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

Re: [PATCH] fortran: Avoid infinite self-recursion [PR105381]

[Jakub Jelinek via Fortran]

On Tue, Apr 26, 2022 at 03:22:08PM +0200, Tobias Burnus wrote:
> LGTM - however:
> 
> On 26.04.22 14:38, Mikael Morin wrote:
> > --- a/gcc/fortran/trans-array.cc
> > +++ b/gcc/fortran/trans-array.cc
> > @@ -3698,7 +3698,8 @@ non_negative_strides_array_p (tree expr)
> > if (DECL_P (expr)
> > && DECL_LANG_SPECIFIC (expr))
> >   if (tree orig_decl = GFC_DECL_SAVED_DESCRIPTOR (expr))
> > -  return non_negative_strides_array_p (orig_decl);
> > +  if (orig_decl != expr)
> > + return non_negative_strides_array_p (orig_decl);
> 
> Is the if()if()if() cascade really needed? I can see a reason that an
> extra 'if' is preferred for the variable declaration of orig_decl, but
> can't we at least put the new 'orig_decl != expr' with an '&&' into the
> same if as the decl/in the second if? Besides clearer, it also avoids
> further identing the return line.

I think we can't in C++11/C++14.  The options can be if orig_decl would be 
declared
earlier, then it can be
tree orig_decl;
if (DECL_P (expr)
&& DECL_LANG_SPECIFIC (expr)
&& (orig_decl = GFC_DECL_SAVED_DESCRIPTOR (expr))
&& orig_decl != expr)
  return non_negative_strides_array_p (orig_decl);
but I think this is generally frowned upon,
or one can repeat it like:
if (DECL_P (expr)
&& DECL_LANG_SPECIFIC (expr)
&& GFC_DECL_SAVED_DESCRIPTOR (expr)
&& GFC_DECL_SAVED_DESCRIPTOR (expr) != expr)
  return non_negative_strides_array_p (GFC_DECL_SAVED_DESCRIPTOR (expr));
or what Mikael wrote, perhaps with the && on one line:
if (DECL_P (expr) && DECL_LANG_SPECIFIC (expr))
  if (tree orig_decl = GFC_DECL_SAVED_DESCRIPTOR (expr))
if (orig_decl != expr)
  return non_negative_strides_array_p (orig_decl);
In C++17 and later one can write:
if (DECL_P (expr) && DECL_LANG_SPECIFIC (expr))
  if (tree orig_decl = GFC_DECL_SAVED_DESCRIPTOR (expr);
  orig_decl && orig_decl != expr)
return non_negative_strides_array_p (orig_decl);

Jakub

Re: Fortran compiler

[Holcomb, Katherine A (kah3f) via Fortran]

Please try reading my instructions, see whether it helps to clarify things.  
MinGW and such don’t directly have Fortran.  You first install MSYS2 and MinGW 
and you have to then install Fortran as a package.

https://learning.rc.virginia.edu/courses/fortran_introduction/setting_up 
/

I have not tried downloading from Arjen’s suggested site so I can’t comment on 
the bad link.  It should be safe to install 10.3 and there is bound to be a way 
to bypass (“whitelist”) the executable.  

> On Apr 26, 2022, at 9:28 AM, Elliot Cramer  
> wrote:
> 
> On 4/26/2022 7:55 AM, Holcomb, Katherine A (kah3f) wrote:
>> Hi Elliot,
>> 
>> Did you look at my online instructions?
> NO
>>  You can also use a prebuilt distribution as Arjen suggests.  If you’re not 
>> actually on the mailing list but just sending to it so didn’t see that, he 
>> recommended http://www.equation.com/servlet/equation.cmd?fa=fortran 
>> .
> 
> 11.2 is a bad link.  When I download 10.3 I get a message
> 
> Microsoft Defender SmartScreen prevented an unrecognized app from starting. 
> Running this app might put your PC at risk.
> 
> It doesn't give me an options to accept it and  I am clueless I used avast on 
> windows 7 and I guess I should load it
> 
> The other sites that Jerry mentioned don't seem tohave gfortran  on them
> 
> 
> or this one: 
> https://www.mingw-w64.org/  
> 
> or this one: 
> https://www.cygwin.com/ 
> 
> Mandaicrosoft Defender SmartScreen prevented an unrecognized app from 
> starting. Running this app might put your PC at risk.
> 
> 
>> You would still need to make sure your PATH is set so that gfortran and the 
>> other binaries you’d need are visible.
> I don't know how to do this;  I seem not to have access to the c: folder as I 
> did in windows 7.  I'm just getting a windows 10 computer going
>> 
>> Unless you are adept with the Windows command line,
> I've used it in the past.  I literally spent hours downloading intel Fortran 
> and don't have a clue as to how to use it.  I see why it is free.  You guys 
> must have spent a great deal of time and effort developing gfortran and it 
> sounds wonderful.  It would be great if  there was a way of making it 
> available to unsophisticated windows users.  I naively though I could just 
> download load it and be off.  I appreciate you guys trying to help me
> 
> 
> 
>> you should look into a graphical development environment.
> I think it is beyond my capabilities
> 
> 
> 
> Thanks,
> 
> Elliot
> 
> 
> 
> 
> 
> 
> 
>>  The problem with those is that most don’t support Fortran well or at all.  
>> The two free, cross-platform ones I know that do are Geany and Code::Blocks. 
>>  Geany is more like a nice editor with some buttons for compiling and 
>> running (and it can run a Makefile) whereas Code::Blocks is closer to a 
>> traditional IDE.  Both may expect you to be using gfortran and would require 
>> some configuration if you wanted to use the Intel oneAPI option.  Easy to 
>> do, but an extra step to keep in mind.
>> 
>> VSCode is all the rage but I fought with it just to try to use it for C++ 
>> and didn’t want even to try Fortran.
>> 
>>> On Apr 25, 2022, at 9:57 PM, Elliot Cramer >> > wrote:
>>> 
>>> 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 
>>> 
>> 
> 
> -- 
> 
> 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:/

Re: *PING* [PATCH 0/4] Use pointer arithmetic for array references [PR102043]

[Hans-Peter Nilsson via Fortran]

> From: Thomas Koenig via Gcc-patches 
> Date: Fri, 22 Apr 2022 15:59:45 +0200

> Hi Mikael,
> 
> > Ping for the four patches starting at 
> > https://gcc.gnu.org/pipermail/fortran/2022-April/057759.html :
> > https://gcc.gnu.org/pipermail/fortran/2022-April/057757.html
> > https://gcc.gnu.org/pipermail/fortran/2022-April/057760.html
> > https://gcc.gnu.org/pipermail/fortran/2022-April/057758.html
> > https://gcc.gnu.org/pipermail/fortran/2022-April/057761.html
> > 
> > Richi accepted the general direction and the middle-end interaction.
> > I need a fortran frontend ack as well.
> 
> Looks good to me.
> 
> Thanks a lot for taking this on! This would have been a serious
> regression if released with gcc 12.
> 
> Best regards
> 
>   Thomas

These, or specifically r12-8227-g89ca0fffa48b79, "fortran:
Pre-evaluate string pointers. [PR102043]" have further
exposed (the issue existed before but now fails for more
platforms) PR78054 "gfortran.dg/pr70673.f90 FAILs at -O0",
at least for cris-elf and apparently also
s390x-ibm-linux-gnu.

In the PR it is mentioned that running the test through
valgrind shows invalid accesses also on x86_64-linux-gnu.
Could it be that the test-case is invalid and has undefined
behavior?  I don't know fortran so I can't tell.

That exact commit causing a regression for s390x is somewhat
an assumption based on posted date and testresults, as the
s390x results don't include a git version.  (@Stefansf: I'm
referring to
https://gcc.gnu.org/pipermail/gcc-testresults/2022-April/760060.html
https://gcc.gnu.org/pipermail/gcc-testresults/2022-April/760137.html
Perhaps that tester isn't using the contrib/gcc_update and
contrib/test_summary scripts, thus no LAST_UPDATED
included?)

brgds, H-P

Re: [PATCH] fortran: Avoid infinite self-recursion [PR105381]

[Mikael Morin]

Le 26/04/2022 à 15:32, Jakub Jelinek a écrit :

On Tue, Apr 26, 2022 at 03:22:08PM +0200, Tobias Burnus wrote:

LGTM - however:

On 26.04.22 14:38, Mikael Morin wrote:

--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -3698,7 +3698,8 @@ non_negative_strides_array_p (tree expr)
 if (DECL_P (expr)
 && DECL_LANG_SPECIFIC (expr))
   if (tree orig_decl = GFC_DECL_SAVED_DESCRIPTOR (expr))
-  return non_negative_strides_array_p (orig_decl);
+  if (orig_decl != expr)
+ return non_negative_strides_array_p (orig_decl);


Is the if()if()if() cascade really needed? I can see a reason that an
extra 'if' is preferred for the variable declaration of orig_decl, but
can't we at least put the new 'orig_decl != expr' with an '&&' into the
same if as the decl/in the second if? Besides clearer, it also avoids
further identing the return line.


I think we can't in C++11/C++14.  The options can be if orig_decl would be 
declared
earlier, then it can be
 tree orig_decl;
 if (DECL_P (expr)
&& DECL_LANG_SPECIFIC (expr)
&& (orig_decl = GFC_DECL_SAVED_DESCRIPTOR (expr))
&& orig_decl != expr)
   return non_negative_strides_array_p (orig_decl);
but I think this is generally frowned upon,
or one can repeat it like:
 if (DECL_P (expr)
&& DECL_LANG_SPECIFIC (expr)
&& GFC_DECL_SAVED_DESCRIPTOR (expr)
&& GFC_DECL_SAVED_DESCRIPTOR (expr) != expr)
   return non_negative_strides_array_p (GFC_DECL_SAVED_DESCRIPTOR (expr));


I think I’ll use that.  There are numerous places where macros are 
repeated like this already and everybody seems to be pleased with it.

Thanks for the feedback, and for the suggestions.


or what Mikael wrote, perhaps with the && on one line:
 if (DECL_P (expr) && DECL_LANG_SPECIFIC (expr))
   if (tree orig_decl = GFC_DECL_SAVED_DESCRIPTOR (expr))
if (orig_decl != expr)
  return non_negative_strides_array_p (orig_decl);
In C++17 and later one can write:
 if (DECL_P (expr) && DECL_LANG_SPECIFIC (expr))
   if (tree orig_decl = GFC_DECL_SAVED_DESCRIPTOR (expr);
  orig_decl && orig_decl != expr)
return non_negative_strides_array_p (orig_decl);

Jakub

Fix up 'libgomp.oacc-fortran/print-1.f90' GCN offloading compilation [PR104717] (was: [PATCH] fortran: Fix up gfc_trans_oacc_construct [PR104717])

[Thomas Schwinge]

Hi!

On 2022-04-25T23:19:26+0200, I wrote:
> 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.

>> 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.

One more issue became apparent, where the code changes pushed actually do
lead to a GCN offloading compilation failure:

[...]/libgomp.oacc-fortran/print-1.f90: In function ‘MAIN__._omp_fn.0’:
[...]/libgomp.oacc-fortran/print-1.f90:13:14: error: 512 bytes of 
gang-private data-share memory exhausted (increase with 
‘-mgang-private-size=560’, for example)
   13 | !$acc parallel
  |  ^

In my configuration, I may indeed fix GCN offloading compilation with
'-foffload-options=amdgcn-amdhsa=-mgang-private-size=560', but I don't
think that's generally correct/sufficient, so in the the attached
"Fix up 'libgomp.oacc-fortran/print-1.f90' GCN offloading compilation
[PR104717]", I instead "raise '-mgang-private-size' to an arbitrary high
value".  This avoids having to route the actual 'sizeof' from GCC build
down to the test suite harness (which ought to be doable, but
non-trivial).  OK to push that:

+! For GCN offloading compilation, when gang-privatizing 'dt_parm.N'
+! (see below), we run into an 'gang-private data-share memory exhausted'
+! error: the default '-mgang-private-size' is too small.  Per
+! 'gcc/fortran/trans-io.cc'/'libgfortran/io/io.h', that one is
+! 'struct st_parameter_dt', which indeed is rather big.  Instead of
+! working out its exact size (which may vary per GCC configuration),
+! raise '-mgang-private-size' to an arbitrary high value.
+! { dg-additional-options 
"-foffload-options=amdgcn-amdhsa=-mgang-private-size=13579" { target 
openacc_radeon_accel_selected } }

... to master branch? (This doubles the use/testing of the
'-mgang-private-size' option!)  ;-)

We've currently not been doing OpenACC privatization scanning in
'libgomp.oacc-fortran/print-1.f90', which I've now added, to help
document the issue; no need to review that.

Of course, the issue could alternatively be fixed by adding more logic to
the GCN back end to auto-scale the allocation, or be fixed by adding more
logic to the compiler to avoid gang-privatizing varibales such as
'dt_parm.N' in such cases, but that's not something I'm going to look
into at this point.

Or, of course, be avoided by re-writing the test case to not require
gang-privatizing 'dt_parm.N', but the test case is correct as it is.


Grüße
 Thomas


>   PR fortran/104717
>   gcc/fortran/
>   * trans-openmp.cc (gfc_trans_oacc_construct): Wrap construct body
>   in an extra BIND_EXPR.

> --- a/gcc/fortran/trans-openmp.cc
> +++ b/gcc/fortran/trans-openmp.cc
> @@ -,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);


-
Siemens Electronic Design Aut

Re: [PATCH] fortran: Avoid infinite self-recursion [PR105381]

[Jakub Jelinek via Fortran]

On Tue, Apr 26, 2022 at 07:12:13PM +0200, Mikael Morin wrote:
> > I think we can't in C++11/C++14.  The options can be if orig_decl would be 
> > declared
> > earlier, then it can be
> >  tree orig_decl;
> >  if (DECL_P (expr)
> > && DECL_LANG_SPECIFIC (expr)
> > && (orig_decl = GFC_DECL_SAVED_DESCRIPTOR (expr))
> > && orig_decl != expr)
> >return non_negative_strides_array_p (orig_decl);
> > but I think this is generally frowned upon,
> > or one can repeat it like:
> >  if (DECL_P (expr)
> > && DECL_LANG_SPECIFIC (expr)
> > && GFC_DECL_SAVED_DESCRIPTOR (expr)
> > && GFC_DECL_SAVED_DESCRIPTOR (expr) != expr)
> >return non_negative_strides_array_p (GFC_DECL_SAVED_DESCRIPTOR 
> > (expr));
> 
> I think I’ll use that.  There are numerous places where macros are repeated
> like this already and everybody seems to be pleased with it.
> Thanks for the feedback, and for the suggestions.

Agreed in this case, GFC_DECL_SAVED_DESCRIPTOR is really just a dereference
at least in release compiler.  Doing that when the macro actually calls some
functions is worse.

Jakub

Re: Fix up 'libgomp.oacc-fortran/print-1.f90' GCN offloading compilation [PR104717] (was: [PATCH] fortran: Fix up gfc_trans_oacc_construct [PR104717])

[Thomas Schwinge]

Hi!

On 2022-04-26T19:25:31+0200, I wrote:
> On 2022-04-25T23:19:26+0200, I wrote:
>> 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.
>
>>> 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.
>
> One more issue became apparent, where the code changes pushed actually do
> lead to a GCN offloading compilation failure:
>
> [...]/libgomp.oacc-fortran/print-1.f90: In function ‘MAIN__._omp_fn.0’:
> [...]/libgomp.oacc-fortran/print-1.f90:13:14: error: 512 bytes of 
> gang-private data-share memory exhausted (increase with 
> ‘-mgang-private-size=560’, for example)
>13 | !$acc parallel
>   |  ^
>
> In my configuration, I may indeed fix GCN offloading compilation with
> '-foffload-options=amdgcn-amdhsa=-mgang-private-size=560', but I don't
> think that's generally correct/sufficient, so in the the attached
> "Fix up 'libgomp.oacc-fortran/print-1.f90' GCN offloading compilation
> [PR104717]", I instead "raise '-mgang-private-size' to an arbitrary high
> value".  This avoids having to route the actual 'sizeof' from GCC build
> down to the test suite harness (which ought to be doable, but
> non-trivial).  OK to push that:
>
> +! For GCN offloading compilation, when gang-privatizing 'dt_parm.N'
> +! (see below), we run into an 'gang-private data-share memory exhausted'
> +! error: the default '-mgang-private-size' is too small.  Per
> +! 'gcc/fortran/trans-io.cc'/'libgfortran/io/io.h', that one is
> +! 'struct st_parameter_dt', which indeed is rather big.  Instead of
> +! working out its exact size (which may vary per GCC configuration),
> +! raise '-mgang-private-size' to an arbitrary high value.
> +! { dg-additional-options 
> "-foffload-options=amdgcn-amdhsa=-mgang-private-size=13579" { target 
> openacc_radeon_accel_selected } }
>
> ... to master branch? (This doubles the use/testing of the
> '-mgang-private-size' option!)  ;-)

Eh.  That only works with the default GCN multilib '-march=fiji', testing
on gfx803 amdfury2 system.  For all of '-march=gfx900' (amdnano2),
'-march=gfx906' (amd_ryzen3), '-march=gfx908' (amd-instinct1), I get:

libgomp: GCN fatal error: Asynchronous queue error
Runtime message: HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION: The agent 
attempted to access memory beyond the largest legal address.

..., and I still get that if lowering the allocation to the minimum,
'-foffload-options=amdgcn-amdhsa=-mgang-private-size=560'.

This is a really simple OpenACC 'parallel' construct:

!$acc parallel
  write (0, '("The answer is ", I2)') var
!$acc end parallel

..., which ought to launch a 1-gang x 1-worker x 1-vector GPU kernel, so
I'd assume '-mgang-private-size=560' (or '-mgang-private-size=13579' in
fact) is not a problem?

Help?


Grüße
 Thomas


> We've currently not been doing OpenACC privatization scanning in
> 'libgomp.oacc-fortran/print-1.f90', which I've now added, to help
> document the issue; no need to review that.
>
> Of course, the issue could alternatively be fixed by adding more logic to
> the GCN back end to auto-scale the allocation, or be fixed by adding more
> logic to the compiler to avoid gang-privatizing varibales such as
> 'dt_parm.N' in such cases, but that's not somet

[PATCH] fortran: Compare non-constant bound expressions. [PR105379]

[Mikael Morin]

Hello,

this fixes a regression caused by my recent PR103662 patch.

Regression tested on x86_64-pc-linux-gnu. OK for master?From d7309a471c42e51e84c37d5d4a3fd5bb0ed67405 Mon Sep 17 00:00:00 2001
From: Mikael Morin 
Date: Mon, 25 Apr 2022 19:47:04 +0200
Subject: [PATCH] fortran: Compare non-constant bound expressions. [PR105379]

Starting with r12-8235-gfa5cd7102da676dcb1757b1288421f5f3439ae0e,
class descriptor types are compared to detect duplicate declarations.

This caused ICEs as the comparison of array spec supported only constant
explicit bounds, but dummy class variable descriptor types can have a
_data field with non-constant array spec bounds.

This change adds support for non-constant bounds.  For that,
gfc_dep_compare_expr is used.  It does probably more than strictly
necessary, but using it avoids rewriting a specific comparison function,
making mistakes and forgetting cases.

	PR fortran/103662
	PR fortran/105379

gcc/fortran/ChangeLog:

	* array.cc (compare_bounds): Use bool as return type.
	Support non-constant expressions.
	(gfc_compare_array_spec): Update call to compare_bounds.

gcc/testsuite/ChangeLog:

	* gfortran.dg/class_dummy_8.f90: New test.
	* gfortran.dg/class_dummy_9.f90: New test.
---
 gcc/fortran/array.cc| 27 -
 gcc/testsuite/gfortran.dg/class_dummy_8.f90 | 20 +++
 gcc/testsuite/gfortran.dg/class_dummy_9.f90 | 20 +++
 3 files changed, 56 insertions(+), 11 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/class_dummy_8.f90
 create mode 100644 gcc/testsuite/gfortran.dg/class_dummy_9.f90

diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index 90ea812d699..bbdb5b392fc 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -957,23 +957,28 @@ gfc_copy_array_spec (gfc_array_spec *src)
 }
 
 
-/* Returns nonzero if the two expressions are equal.  Only handles integer
-   constants.  */
+/* Returns nonzero if the two expressions are equal.
+   We should not need to support more than constant values, as that’s what is
+   allowed in derived type component array spec.  However, we may create types
+   with non-constant array spec for dummy variable class container types, for
+   which the _data component holds the array spec of the variable declaration.
+   So we have to support non-constant bounds as well.  */
 
-static int
+static bool
 compare_bounds (gfc_expr *bound1, gfc_expr *bound2)
 {
   if (bound1 == NULL || bound2 == NULL
-  || bound1->expr_type != EXPR_CONSTANT
-  || bound2->expr_type != EXPR_CONSTANT
   || bound1->ts.type != BT_INTEGER
   || bound2->ts.type != BT_INTEGER)
 gfc_internal_error ("gfc_compare_array_spec(): Array spec clobbered");
 
-  if (mpz_cmp (bound1->value.integer, bound2->value.integer) == 0)
-return 1;
-  else
-return 0;
+  /* What qualifies as identical bounds?  We could probably just check that the
+ expressions are exact clones.  We avoid rewriting a specific comparison
+ function and re-use instead the rather involved gfc_dep_compare_expr which
+ is just a bit more permissive, as it can also detect identical values for
+ some mismatching expressions (extra parenthesis, swapped operands, unary
+ plus, etc).  It probably only makes a difference in corner cases.  */
+  return gfc_dep_compare_expr (bound1, bound2) == 0;
 }
 
 
@@ -1006,10 +1011,10 @@ gfc_compare_array_spec (gfc_array_spec *as1, gfc_array_spec *as2)
   if (as1->type == AS_EXPLICIT)
 for (i = 0; i < as1->rank + as1->corank; i++)
   {
-	if (compare_bounds (as1->lower[i], as2->lower[i]) == 0)
+	if (!compare_bounds (as1->lower[i], as2->lower[i]))
 	  return 0;
 
-	if (compare_bounds (as1->upper[i], as2->upper[i]) == 0)
+	if (!compare_bounds (as1->upper[i], as2->upper[i]))
 	  return 0;
   }
 
diff --git a/gcc/testsuite/gfortran.dg/class_dummy_8.f90 b/gcc/testsuite/gfortran.dg/class_dummy_8.f90
new file mode 100644
index 000..0976a725866
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/class_dummy_8.f90
@@ -0,0 +1,20 @@
+! { dg-do compile }
+!
+! PR fortran/105379
+! Type comparison of class containers used to trigger an ICE when one of the
+! class containers had a non-constant array spec.
+!
+! Contributed by Gerhard Steinmetz .
+
+program p
+   type t
+   end type
+contains
+   subroutine s1(x)
+  class(t) :: x(3)
+   end
+   subroutine s2(n, x)
+  integer :: n
+  class(t) :: x(n)
+   end
+end
diff --git a/gcc/testsuite/gfortran.dg/class_dummy_9.f90 b/gcc/testsuite/gfortran.dg/class_dummy_9.f90
new file mode 100644
index 000..0fd98c05be2
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/class_dummy_9.f90
@@ -0,0 +1,20 @@
+! { dg-do compile }
+!
+! PR fortran/105379
+! Type comparison of class containers used to trigger an ICE when one of the
+! class containers had a non-constant array spec.
+!
+! Contributed by Gerhard Steinmetz .
+
+program p
+   type t
+   end type
+   integer :: m = 3
+contains
+   subroutine s1(x)
+

Re: [PATCH] fortran: Compare non-constant bound expressions. [PR105379]

[Thomas Koenig via Fortran]

Hi Mikael,


this fixes a regression caused by my recent PR103662 patch.

Regression tested on x86_64-pc-linux-gnu. OK for master?


OK.  Good to see that a bit of optimization can also sneak in with
a bug fix :-)

Best regards

Thomas

[PATCH v2] fortran: Avoid infinite self-recursion [PR105381]

[Mikael Morin]

Le 26/04/2022 à 19:12, Mikael Morin a écrit :

Le 26/04/2022 à 15:32, Jakub Jelinek a écrit :

or one can repeat it like:
 if (DECL_P (expr)
&& DECL_LANG_SPECIFIC (expr)
&& GFC_DECL_SAVED_DESCRIPTOR (expr)
&& GFC_DECL_SAVED_DESCRIPTOR (expr) != expr)
   return non_negative_strides_array_p (GFC_DECL_SAVED_DESCRIPTOR 
(expr));


I think I’ll use that. 


Here it comes.
Regression tested again. OK?
From 9da696478832bb3fe5ac25542ad9226ce3235368 Mon Sep 17 00:00:00 2001
From: Mikael Morin 
Date: Tue, 26 Apr 2022 13:05:32 +0200
Subject: [PATCH v2] fortran: Avoid infinite self-recursion [PR105381]

Dummy array decls are local decls different from the argument decl
accessible through GFC_DECL_SAVED_DESCRIPTOR.  If the argument decl has
a DECL_LANG_SPECIFIC set, it is copied over to the local decl at the
time the latter is created, so that the DECL_LANG_SPECIFIC object is
shared between local dummy decl and argument decl, and thus the
GFC_DECL_SAVED_DESCRIPTOR of the argument decl is the argument decl
itself.

The r12-8230-g7964ab6c364c410c34efe7ca2eba797d36525349 change introduced
the non_negative_strides_array_p predicate which recurses through
GFC_DECL_SAVED_DESCRIPTOR to avoid seeing dummy decls as purely local
decls.  As the GFC_DECL_SAVED_DESCRIPTOR of the argument decl is itself,
this can cause infinite recursion.

This change adds a check to avoid infinite recursion.

	PR fortran/102043
	PR fortran/105381

gcc/fortran/ChangeLog:

	* trans-array.cc (non_negative_strides_array_p): Inline variable
	orig_decl and merge nested if conditions.  Add condition to not
	recurse if the next argument is the same as the current.

gcc/testsuite/ChangeLog:

	* gfortran.dg/character_array_dummy_1.f90: New test.
---
 gcc/fortran/trans-array.cc|  7 ---
 .../gfortran.dg/character_array_dummy_1.f90   | 21 +++
 2 files changed, 25 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/character_array_dummy_1.f90

diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index e4b6270ccf8..05134952db4 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -3696,9 +3696,10 @@ non_negative_strides_array_p (tree expr)
   /* If the array was originally a dummy with a descriptor, strides can be
  negative.  */
   if (DECL_P (expr)
-  && DECL_LANG_SPECIFIC (expr))
-if (tree orig_decl = GFC_DECL_SAVED_DESCRIPTOR (expr))
-  return non_negative_strides_array_p (orig_decl);
+  && DECL_LANG_SPECIFIC (expr)
+  && GFC_DECL_SAVED_DESCRIPTOR (expr)
+  && GFC_DECL_SAVED_DESCRIPTOR (expr) != expr)
+return non_negative_strides_array_p (GFC_DECL_SAVED_DESCRIPTOR (expr));
 
   return true;
 }
diff --git a/gcc/testsuite/gfortran.dg/character_array_dummy_1.f90 b/gcc/testsuite/gfortran.dg/character_array_dummy_1.f90
new file mode 100644
index 000..da5ed636f4f
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/character_array_dummy_1.f90
@@ -0,0 +1,21 @@
+! { dg-do compile }
+!
+! PR fortran/105381
+! Infinite recursion with array references of character dummy arguments.
+!
+! Contributed by Harald Anlauf 
+
+MODULE m
+  implicit none
+  integer,  parameter :: ncrit  =  8
+  integer,  parameter :: nterm  =  7
+contains
+
+  subroutine new_thin_rule (rule1)
+character(*),intent(in) ,optional :: rule1(ncrit)
+character(len=8) :: rules (ncrit,nterm)
+rules = ''
+if (present (rule1)) rules(:,1) = rule1  ! <-- compile time hog
+  end subroutine new_thin_rule
+
+end module m
-- 
2.35.1

Re: [PATCH v2] fortran: Avoid infinite self-recursion [PR105381]

[Harald Anlauf via Fortran]

Hi Mikael,

Am 26.04.22 um 21:10 schrieb Mikael Morin:

Le 26/04/2022 à 19:12, Mikael Morin a écrit :

Le 26/04/2022 à 15:32, Jakub Jelinek a écrit :

or one can repeat it like:
 if (DECL_P (expr)
&& DECL_LANG_SPECIFIC (expr)
&& GFC_DECL_SAVED_DESCRIPTOR (expr)
&& GFC_DECL_SAVED_DESCRIPTOR (expr) != expr)
   return non_negative_strides_array_p (GFC_DECL_SAVED_DESCRIPTOR 
(expr));


I think I’ll use that. 


Here it comes.
Regression tested again. OK?


works for me.

Thanks for the quick fix!

Harald

Re: *PING* [PATCH 0/4] Use pointer arithmetic for array references [PR102043]

[Thomas Koenig via Fortran]

On 26.04.22 16:40, Hans-Peter Nilsson wrote:


These, or specifically r12-8227-g89ca0fffa48b79, "fortran:
Pre-evaluate string pointers. [PR102043]" have further
exposed (the issue existed before but now fails for more
platforms) PR78054 "gfortran.dg/pr70673.f90 FAILs at -O0",
at least for cris-elf and apparently also
s390x-ibm-linux-gnu.

In the PR it is mentioned that running the test through
valgrind shows invalid accesses also on x86_64-linux-gnu.
Could it be that the test-case is invalid and has undefined
behavior?  I don't know fortran so I can't tell.


You're right.  I just looked at the test case and can confirm
what Steve Kargl observed in the PR, it is in fact invalid.
You cannot do

  a = a

after deallocating a.

I've assigned the PR to myself and will commit the change to
dg-do compile soon (unless anybody objects).

Best regards

Thomas