Re: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).

[Hafiz Abid Qadeer]

On 05/02/2022 19:09, Hafiz Abid Qadeer wrote:
> On 04/02/2022 11:25, Hafiz Abid Qadeer wrote:
>> On 04/02/2022 09:46, Thomas Schwinge wrote:
>>
>>>
>>> Abid, are you going to address these?  I think it does make sense if the
>>> C/C++ and Fortran test cases match as much as feasible.
>>>
>> Sure. I will do that.
> 
> The attached patch address those issues apart from removing pool_size trait.

Is this change ok to commit?

Thanks,
-- 
Hafiz Abid Qadeer

Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization

[Paul Richard Thomas via Fortran]

Hi Harald and Jerry,

I have gone back to the start and have gone through finalizable derived
type assignments with the F2018 in hand. I have had a dreadful time with
direct by reference function calls and still am struggling with assignment
number 6 in the attached. I would be very grateful if you would run this
testcase for the other brands.

As soon as I fix the 6th assignment, I will get on to class assignments.

Best regards

Paul


On Fri, 11 Feb 2022 at 21:59, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:

> Hi Harald and Jerry,
>
> I am reworking my way through, line by line wit F2018 in hand. Up to test
> with offset 70, NAG looks to be right. I introduced an assignment with a
> direct by ref function call, which doesn't finalise at the moment. Class
> entities are yet to come. I'll report back early next week.
>
> Thanks for all the help. I have (re)learned to read the standard very
> carefully.
>
> Best regards
>
> Paul
>
>
> On Fri, 11 Feb 2022, 21:08 Harald Anlauf,  wrote:
>
>> Hi Paul,
>>
>> Am 11.02.22 um 10:08 schrieb Paul Richard Thomas via Fortran:
>> > Your "stupid questions" are not at all stupid. The finalization of
>> > 'variable' that occurs in your testcase demonstrates that the
>> finalization
>> > with my patch is occurring at the wrong time. I now see that NAG is
>> correct
>> > on this.
>> >
>> > Please press on with the questions!
>>
>> Jerry's suggestion to add lots of prints turned out to be really
>> enlightening with regard to observable behavior.  I rewrote the
>> testcase again and placed the interesting stuff into a subroutine.
>> This way one can distinguish what actually happens during program
>> start, entering and leaving a subroutine.
>>
>> I encountered the least surprises (= none) with NAG 7.0 here.
>> For reference this is the output:
>>
>>   At start of program : 0
>>
>>   Enter sub   : 0
>>   After 1st allocation: 0
>>   After 2nd allocation: 0
>>   Checking MyType% ind: 21
>>   Checking MyType2%ind: 22
>>   Deallocate MyType   : 0
>>   # Leave desctructor1: 1 21
>>   * MyType deallocated: 1
>>   (kept MyType2 for automatic deallocation on return from sub)
>>   Leave sub   : 1
>>   # Leave desctructor1: 2 22
>>
>>   After sub   : 2
>>
>> To make it short: the destructor is called only when deallocation
>> occurs, either explicitly or automatically.
>>
>>
>> Intel 2021.5.0:
>>
>>   At start of program :   0
>>
>>   Enter sub   :   0
>>   # Leave desctructor1:   1   0
>>   After 1st allocation:   1
>>   # Leave desctructor1:   2   0
>>   After 2nd allocation:   2
>>   Checking MyType% ind:  21
>>   Checking MyType2%ind:  22
>>   Deallocate MyType   :   2
>>   # Leave desctructor1:   3  21
>>   * MyType deallocated:   3
>>   (kept MyType2 for automatic deallocation on return from sub)
>>   Leave sub   :   3
>>   # Leave desctructor1:   4  21
>>   # Leave desctructor1:   5  22
>>   # Leave desctructor1:   6  22
>>
>>   After sub   :   6
>>
>> So after entering the subroutine, the destructor is called twice,
>> but for unknown reasons element ind, which I had expected to be
>> either default-initialized to -1, or explicitly to 21 or 22, is 0.
>> The places where this happens seem to be the assignments of
>> MyType and MyType2.
>>
>> Furthermore, variable MyType is finalized on return from sub,
>> although it is already deallocated, and MyType2 appears to
>> get finalized twice automatically.
>>
>> I have no idea how this can get justified...
>>
>>
>> Crayftn 12.0.2: in order to make the output easier to understand,
>> I chose to reset final_count twice.  This will become clear soon.
>>
>>   # Leave desctructor1: 1,  20
>>
>>   At start of program : 1
>>   +++ Resetting final_count for Cray Fortran : Version 12.0.2
>>
>>   # Leave desctructor1: 1,  21
>>   # Leave desctructor1: 2,  22
>>   Enter sub   : 2
>>   +++ Resetting final_count for Cray Fortran : Version 12.0.2
>>   After 1st allocation: 0
>>   After 2nd allocation: 0
>>   Checking MyType% ind: -21
>>   Checking MyType2%ind: 22
>>   Deallocate MyType   : 0
>>   # Leave desctructor1: 1,  -21
>>   * MyType deallocated: 1
>>   (kept MyType2 for automatic deallocation on return from sub)
>>   Leave sub   : 1
>>   # Leave desctructor1: 2,  22
>>
>>   After sub   : 2
>>
>> So it appears that Cray is calling the destructor for each declaration
>> where a constructor is involved, or the like.  Even if this is a
>> parameter declaration, like in the main.  Resetting the counter for
>> the first time.
>>
>> On entering sub, I see now two finalizations before the first print.
>> Resetting the counter for the second time.
>>
>> But then the assignments do not invoke finalization, where Intel did.
>> So this part appears more like NAG, but...
>>
>> ... something is

[PATCH] PR fortran/104573 - ICE in resolve_structure_cons, at fortran/resolve.cc:1299

[Harald Anlauf via Fortran]

Dear Fortranners,

while we detect invalid uses of type(*), we may run into other issues
later when the declared variable is used, leading to an ICE due to a
NULL pointer dereference.  This is demonstrated by Gerhard's testcase.

Steve and I came to rather similar fixes, see PR.  Mine is attached.

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

Thanks,
Harald

From 01d629506edca711f02912e2cc124f8894cfa389 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Wed, 16 Feb 2022 22:13:02 +0100
Subject: [PATCH] Fortran: error recovery after invalid assumed type
 declaration

gcc/fortran/ChangeLog:

	PR fortran/104573
	* resolve.cc (resolve_structure_cons): Avoid NULL pointer
	dereference when there is no valid component.

gcc/testsuite/ChangeLog:

	PR fortran/104573
	* gfortran.dg/assumed_type_14.f90: New test.
---
 gcc/fortran/resolve.cc|  8 +---
 gcc/testsuite/gfortran.dg/assumed_type_14.f90 | 12 
 2 files changed, 17 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/assumed_type_14.f90

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 266e41e25b1..2fa1acdbd6d 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -1288,15 +1288,17 @@ resolve_structure_cons (gfc_expr *expr, int init)
 	}
 }

-  cons = gfc_constructor_first (expr->value.constructor);
-
   /* A constructor may have references if it is the result of substituting a
  parameter variable.  In this case we just pull out the component we
  want.  */
   if (expr->ref)
 comp = expr->ref->u.c.sym->components;
-  else
+  else if (expr->ts.u.derived)
 comp = expr->ts.u.derived->components;
+  else
+return false;
+
+  cons = gfc_constructor_first (expr->value.constructor);

   for (; comp && cons; comp = comp->next, cons = gfc_constructor_next (cons))
 {
diff --git a/gcc/testsuite/gfortran.dg/assumed_type_14.f90 b/gcc/testsuite/gfortran.dg/assumed_type_14.f90
new file mode 100644
index 000..6cfe2e4fb73
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/assumed_type_14.f90
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! PR fortran/104573 - ICE in resolve_structure_cons
+! Contributed by G.Steinmetz
+
+program p
+  type t
+  end type
+  type(*), parameter :: x = t() ! { dg-error "Assumed type of variable" }
+  print *, x
+end
+
+! { dg-prune-output "Cannot convert" }
--
2.34.1