[PATCH] Fortran: error recovery handling invalid CLASS variable [PR107899]

[Harald Anlauf via Fortran]

Dear all,

the attached obvious patch fixes a NULL pointer dereference
that occurs with an invalid CLASS argument to DEALLOCATE.

Regtested on x86_64-pc-linux-gnu.

Will commit soon unless there are comments.

Thanks,
Harald

From dfe7f1a06d78f6319ad81f5774dc43fe52e37f45 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Sat, 3 Dec 2022 19:21:07 +0100
Subject: [PATCH] Fortran: error recovery handling invalid CLASS variable
 [PR107899]

gcc/fortran/ChangeLog:

	PR fortran/107899
	* resolve.cc (resolve_deallocate_expr): Avoid NULL pointer dereference
	on invalid CLASS variable.

gcc/testsuite/ChangeLog:

	PR fortran/107899
	* gfortran.dg/pr107899.f90: New test.
---
 gcc/fortran/resolve.cc |  2 +-
 gcc/testsuite/gfortran.dg/pr107899.f90 | 13 +
 2 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr107899.f90

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 3396c6ce4a7..75dc4b59105 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -7570,7 +7570,7 @@ resolve_deallocate_expr (gfc_expr *e)
   sym = e->symtree->n.sym;
   unlimited = UNLIMITED_POLY(sym);

-  if (sym->ts.type == BT_CLASS)
+  if (sym->ts.type == BT_CLASS && sym->attr.class_ok && CLASS_DATA (sym))
 {
   allocatable = CLASS_DATA (sym)->attr.allocatable;
   pointer = CLASS_DATA (sym)->attr.class_pointer;
diff --git a/gcc/testsuite/gfortran.dg/pr107899.f90 b/gcc/testsuite/gfortran.dg/pr107899.f90
new file mode 100644
index 000..e47b57b7b91
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr107899.f90
@@ -0,0 +1,13 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=single" }
+! PR fortran/107899 - ICE in resolve_deallocate_expr
+! Contributed by G.Steinmetz
+
+program p
+  type t
+  end type
+  class(t), target :: x[:] ! { dg-error "deferred shape" }
+  if (allocated (x)) then  ! { dg-error "must be ALLOCATABLE" }
+ deallocate (x)! { dg-error "must be ALLOCATABLE or a POINTER" }
+  end if
+end
--
2.35.3

[PATCH] Fortran: fix typo in documentation of intrinsic FLOOR [PR107870]

[Harald Anlauf via Fortran]

Dear all,

here's a small documentation fix for the intrinsic FLOOR.
Besides that, I adjusted the description of the optional
KIND argument to Fortran intrinsics to conform to the F2018
standard, which reads "scalar integer constant expression".

Tested with "make dvi".

OK for mainline?

Thanks,
Harald

From 2ad9a19b1cfc0bd9c71d10894f9aca2532f88db4 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Sat, 3 Dec 2022 21:13:48 +0100
Subject: [PATCH] Fortran: fix typo in documentation of intrinsic FLOOR
 [PR107870]

gcc/fortran/ChangeLog:

	PR fortran/107870
	* intrinsic.texi: Fix typo in documentation of intrinsic FLOOR.
	Describe the optional KIND argument to intrinsics as a scalar
	constant expression, in accordance with the current standard.
---
 gcc/fortran/intrinsic.texi | 60 +++---
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index 55f53fc1137..7af1ca3eae6 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -553,7 +553,7 @@ Elemental function
 @item @emph{Arguments}:
 @multitable @columnfractions .15 .70
 @item @var{I}@tab The type shall be @code{INTEGER}.
-@item @var{KIND} @tab (Optional) An @code{INTEGER} initialization
+@item @var{KIND} @tab (Optional) A scalar @code{INTEGER} constant
 expression indicating the kind parameter of the result.
 @end multitable

@@ -920,7 +920,7 @@ Elemental function
 @item @emph{Arguments}:
 @multitable @columnfractions .15 .70
 @item @var{A}@tab The type of the argument shall be @code{REAL}.
-@item @var{KIND} @tab (Optional) An @code{INTEGER} initialization
+@item @var{KIND} @tab (Optional) A scalar @code{INTEGER} constant
 expression indicating the kind parameter of the result.
 @end multitable

@@ -1202,7 +1202,7 @@ Elemental function
 @item @emph{Arguments}:
 @multitable @columnfractions .15 .70
 @item @var{A}@tab The type of the argument shall be @code{REAL}.
-@item @var{KIND} @tab (Optional) An @code{INTEGER} initialization
+@item @var{KIND} @tab (Optional) A scalar @code{INTEGER} constant
 expression indicating the kind parameter of the result.
 @end multitable

@@ -3406,7 +3406,7 @@ Elemental function
 @item @emph{Arguments}:
 @multitable @columnfractions .15 .70
 @item @var{A} @tab The type shall be @code{REAL}.
-@item @var{KIND} @tab (Optional) An @code{INTEGER} initialization
+@item @var{KIND} @tab (Optional) A scalar @code{INTEGER} constant
 expression indicating the kind parameter of the result.
 @end multitable

@@ -3452,7 +3452,7 @@ Elemental function
 @item @emph{Arguments}:
 @multitable @columnfractions .15 .70
 @item @var{I} @tab The type shall be @code{INTEGER}.
-@item @var{KIND} @tab (Optional) An @code{INTEGER} initialization
+@item @var{KIND} @tab (Optional) A scalar @code{INTEGER} constant
 expression indicating the kind parameter of the result.
 @end multitable

@@ -3636,7 +3636,7 @@ Elemental function
 or @code{COMPLEX}.
 @item @var{Y} @tab (Optional; only allowed if @var{X} is not
 @code{COMPLEX}.)  May be @code{INTEGER} or @code{REAL}.
-@item @var{KIND} @tab (Optional) An @code{INTEGER} initialization
+@item @var{KIND} @tab (Optional) A scalar @code{INTEGER} constant
 expression indicating the kind parameter of the result.
 @end multitable

@@ -4527,7 +4527,7 @@ Transformational function
 @multitable @columnfractions .15 .70
 @item @var{MASK} @tab The type shall be @code{LOGICAL}.
 @item @var{DIM}  @tab (Optional) The type shall be @code{INTEGER}.
-@item @var{KIND} @tab (Optional) An @code{INTEGER} initialization
+@item @var{KIND} @tab (Optional) A scalar @code{INTEGER} constant
 expression indicating the kind parameter of the result.
 @end multitable

@@ -6186,7 +6186,7 @@ conformance with @var{ARRAY}.
 inclusive.  It may not be an optional dummy argument.
 @item @var{MASK} @tab (Optional) Shall be of type @code{LOGICAL},
 and conformable with @var{ARRAY}.
-@item @var{KIND} @tab (Optional) An @code{INTEGER} initialization
+@item @var{KIND} @tab (Optional) A scalar @code{INTEGER} constant
 expression indicating the kind parameter of the result.
 @item @var{BACK} @tab (Optional) A scalar of type @code{LOGICAL}.
 @end multitable
@@ -6215,7 +6215,7 @@ is of default kind.

 @table @asis
 @item @emph{Description}:
-@code{FLOOR(A)} returns the greatest integer less than or equal to @var{X}.
+@code{FLOOR(A)} returns the greatest integer less than or equal to @var{A}.

 @item @emph{Standard}:
 Fortran 95 and later
@@ -6229,7 +6229,7 @@ Elemental function
 @item @emph{Arguments}:
 @multitable @columnfractions .15 .70
 @item @var{A} @tab The type shall be @code{REAL}.
-@item @var{KIND} @tab (Optional) An @code{INTEGER} initialization
+@item @var{KIND} @tab (Optional) A scalar @code{INTEGER} constant
 expression indicating the kind parameter of the result.
 @end multitable

@@ -7550,7 +7550,7 @@ Elemental function
 @item @emph{Arguments}:
 @multitable @columnfractions .15 .70
 @item @var{C}@tab Shall be a sc

Team Collaboration Considerations

[Jerry D via Fortran]

Hi all,

Some of you may recall way back when I established the gfortran IRC 
channel to facilitate collaboration on gfortran development.


I have had some discussions with a few people about advancing to newer 
technology.  One thing I have learned is that the gcc C++ team has 
adopted the Mattermost platform.  I have also used Slack and Teams.  
There are many others. The gcc IRC channel is still active. The gfortran 
IRC channel exists but is less used.


I would like suggest that gfortranners adopt one of these platforms. The 
advantages are:


1.   We can post chat questions back and forth via mobile devices
   without having toopen and scan our emails
2. We can share examples and files easily.
3. Screen shot are easily exchanged.
4. Integration with platforms such as Github.

Pros and Cons of some of the choices.  I have only looked at the Free 
options


1. Slack has adopted some limitations on being able to go back and look
   at older posts.  Functionally it is quite good and integrates well
   with github.
2. I looked at Element and Fractal which use the Matrix protocols. 
   Very open source, not so mature yet.
3. Mattermost looks pretty good and was easy to set up.  The free
   version is a bit better than Slacks. GCC C++ uses it.

If we can get a concensus I would happy to get something set up .  I am 
leaning to Mattermost.  The mobile phone app is easy and the web browser 
works fine.


I do think in the long run, doing this will help everyone greatly.

Any thoughts from all?

Regards,

Jerry