Re: [Patch] Fortran/OpenMP: Avoid ICE for invalid char array in omp atomic [PR104329]

2022-02-09 Thread Jakub Jelinek via Fortran 
On Fri, Feb 04, 2022 at 12:39:53PM +0100, Tobias Burnus wrote:
> Already during parsing, the allocatable character array assignment
>x = (x)
> 
> is converted to two gfc_codes with EXEC_ASSIGN, namely:
> 
>   ASSIGN z1:_F.DA0(FULL) (parens z1:x(FULL))
>   ASSIGN z1:x(FULL) z1:_F.DA0(FULL)
> 
> But the current code expects only one gfc_code - as parse.c does some
> checks, that's unexpected for resolution and currently is checked with
> an gcc_assert.
> 
> Solution: I now defer the gfc_assert until after diagnosing the arguments.
> 
> OK for mainline (only affected version)?
> 
> 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

> Fortran/OpenMP: Avoid ICE for invalid char array in omp atomic [PR104329]
> 
>   PR fortran/104329
> gcc/fortran/ChangeLog:
> 
>   * openmp.cc (resolve_omp_atomic): Defer extra-code assert after
>   other diagnostics.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gfortran.dg/gomp/atomic-28.f90: New test.
> 
>  gcc/fortran/openmp.cc| 11 ---
>  gcc/testsuite/gfortran.dg/gomp/atomic-28.f90 | 28 
> 
>  2 files changed, 36 insertions(+), 3 deletions(-)

Ok, thanks.

Jakub

Re: [PATCH] PR fortran/66193 - ICE for initialisation of some non-zero-sized arrays

2022-02-09 Thread Mikael Morin 

Hello

Le 06/02/2022 à 22:14, Harald Anlauf via Fortran a écrit :

Dear Fortranners,

some instances of valid constant array constructors did lead to ICEs.
It turned out that on the one hand we need to attempt simplification of
elements of the constructor, especially when we encounter parenthesized
expression.  On the other hand the occurence of type specs and empty
constructors need to be handled more gracefully.

Parts of the PR have been fixed previously, so the remaining part was
rather simple.

The testcase is based on Gerhards latest example attached to the PR.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?


OK.


Given the simplicity of the patch and that it is an ICE on valid code,
would this qualify for later application to 11-branch?


I suppose it does.

Thanks.

[PATCH] PR fortran/77693 - ICE in rtl_for_decl_init, at dwarf2out.c:17378

2022-02-09 Thread Harald Anlauf via Fortran 
Dear all,

as we did not properly check the initialization of pointers in
DATA statements for valid initial data targets, we could either
ICE or generate wrong code.  Testcase based on Gerhard's, BTW.

The attached patch adds a check in gfc_assign_data_value by
calling gfc_check_pointer_assign, as the latter did not get
called otherwise.

Along the course I introduced a new macro IS_POINTER() that
should help to make the code more readable whenever we need
to check the attributes of a symbol to see whether it is a
pointer, CLASS or not.  At least it may save some typing in
the future.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald

From c94d8f63482e810453dd188faa8396dfac397929 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Wed, 9 Feb 2022 21:54:29 +0100
Subject: [PATCH] Fortran: improve check of pointer initialization in DATA
 statements

gcc/fortran/ChangeLog:

	PR fortran/77693
	* data.cc (gfc_assign_data_value): If a variable in a data
	statement has the POINTER attribute, check for allowed initial
	data target that is compatible with pointer assignment.
	* gfortran.h (IS_POINTER): New macro.

gcc/testsuite/ChangeLog:

	PR fortran/77693
	* gfortran.dg/data_pointer_2.f90: New test.
---
 gcc/fortran/data.cc  |  4 
 gcc/fortran/gfortran.h   |  3 +++
 gcc/testsuite/gfortran.dg/data_pointer_2.f90 | 21 
 3 files changed, 28 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/data_pointer_2.f90

diff --git a/gcc/fortran/data.cc b/gcc/fortran/data.cc
index f7c91437439..7a5866f3c28 100644
--- a/gcc/fortran/data.cc
+++ b/gcc/fortran/data.cc
@@ -618,6 +618,10 @@ gfc_assign_data_value (gfc_expr *lvalue, gfc_expr *rvalue, mpz_t index,
 	gfc_convert_type (expr, &lvalue->ts, 0);
 }

+  if (IS_POINTER (symbol)
+  && !gfc_check_pointer_assign (lvalue, rvalue, false, true))
+return false;
+
   if (last_con == NULL)
 symbol->value = expr;
   else
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 993879feda4..32618c155dc 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3896,6 +3896,9 @@ bool gfc_is_finalizable (gfc_symbol *, gfc_expr **);
 	 && CLASS_DATA (sym) \
 	 && CLASS_DATA (sym)->attr.dimension \
 	 && !CLASS_DATA (sym)->attr.class_pointer)
+#define IS_POINTER(sym) \
+	(sym->ts.type == BT_CLASS && sym->attr.class_ok && CLASS_DATA (sym) \
+	 ? CLASS_DATA (sym)->attr.class_pointer : sym->attr.pointer)

 /* frontend-passes.cc */

diff --git a/gcc/testsuite/gfortran.dg/data_pointer_2.f90 b/gcc/testsuite/gfortran.dg/data_pointer_2.f90
new file mode 100644
index 000..e1677d1c3fb
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/data_pointer_2.f90
@@ -0,0 +1,21 @@
+! { dg-do compile }
+! { dg-options "-O -g" }
+! PR fortran/77693 - ICE in rtl_for_decl_init
+! Contributed by G.Steinmetz
+
+program p
+  implicit none
+  complex, target  :: y= (1.,2.)
+  complex, target  :: z(2) = (3.,4.)
+  complex, pointer :: a => y
+  complex, pointer :: b => z(1)
+  complex, pointer :: c, d, e
+  data c /NULL()/   ! Valid
+  data d /y/! Valid
+  data e /(1.,2.)/  ! { dg-error "Pointer assignment target" }
+  if (associated (a)) print *, a% re
+  if (associated (b)) print *, b% im
+  if (associated (c)) print *, c% re
+  if (associated (d)) print *, d% im
+  if (associated (e)) print *, e% re
+end
--
2.34.1