soccer jersey forums.silverfrost.com :: View topic - Shape of deallocated array
forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Shape of deallocated array
Goto page Previous  1, 2
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
simon



Joined: 05 Jul 2006
Posts: 270

PostPosted: Tue May 02, 2023 9:53 pm    Post subject: Reply with quote

Understood Paul. Thanks for looking into this. I am loading a and b into the separate subprograms because typically the module contains a large number of subprograms, and I am looking to make available to each subprogram only those variables that it needs. If a and b are loaded before the CONTAINS statement, they become available to the every subprogram, which may not be desirable. Regardless, if s1 and s2 are in separate modules I get the same problem with the shape of b changing.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8011
Location: Salford, UK

PostPosted: Wed May 03, 2023 7:44 am    Post subject: Reply with quote

Simon

The failure concerns "allocate on assignment" (AOA) and the statement b(:,:) = a(:,:,1).

When using separate and local USE statements a work-around is to either 1) switch off /F2K which is on by default (add /-F2K) or 2) inhibit AOA with "/inhibit_F2K 1".

At the moment I don't know if FTN95 should be attempting AOA in this context, nor why it fails.

The problem with AOA is that it has the potential to break existing code (or learned expectations) even when all related compiler bugs have been fixed. There might be a case for having AOA switched off by default with a separate option to switch it on. This would have an impact on users who have started to use AOA because it would stop working until the new switch is applied.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2580
Location: Sydney

PostPosted: Wed May 03, 2023 11:02 am    Post subject: Reply with quote

Paul,

For the example I posted earlier in this thread, after "b(:,:) = a(:,:,1)", both FTN95 and Gfortran report SHAPE(b) as [4,6] and not [4,7], which suggests to me that AOA is not being implemented in my example.

I am not familiar with AOA to be confident in this claim.

John
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8011
Location: Salford, UK

PostPosted: Wed May 03, 2023 12:26 pm    Post subject: Reply with quote

John: Thanks for the feedback.

Simon: This failure has now been fixed for the next release of FTN95 (I can provide an new FTN95 straight away if needed).

When the array A is allocatable, its size is not known at compile time. With the fix, FTN95 will not attempt AOA in this context (i.e. that of the original reported failure).
Back to top
View user's profile Send private message AIM Address
simon



Joined: 05 Jul 2006
Posts: 270

PostPosted: Wed May 03, 2023 2:25 pm    Post subject: Reply with quote

Hi Paul,

MANY thanks for your diligent work on this problem. Let me try the compiler switches and see what that effect is. If AOA has to be switched off, I can deal with that more easily than with this problem since I am only using AOA in a few cases. If I am still having difficulties I will get back to you about accessing the fix.

Given that b is already allocated, how come this is classified as an AOA issue?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8011
Location: Salford, UK

PostPosted: Wed May 03, 2023 4:29 pm    Post subject: Reply with quote

Simon

The Standard says that for AOA, an array that has already been allocated must be de-allocated and then re-allocated.

If I am wrong on this point then please let me know because AOA would be a whole lot simpler without this "feature".
Back to top
View user's profile Send private message AIM Address
simon



Joined: 05 Jul 2006
Posts: 270

PostPosted: Wed May 03, 2023 4:58 pm    Post subject: Reply with quote

That is my understanding of AOA too. In my example, AOA should not be taking place, because b was already allocated. My assumption (which may be incorrect) was that because b's shape changed, some form of reallocation was occurring. What I think should be happening is that if b is unallocated, AOA should occur; if b is allocated, then the shape of b must be conformant with the shape of the RHS (in this case of a(:,:,1)), and if it is non-conformat, a runtime error should occur. John's code is an example of a non-conformant, and I would expect that to crash - but perhaps only if compiler options request it to do so. When optimising, I guess the assumption is that it is the coder's responsibility to make sure the arrays are conformant.

Meanwhile, today I will try to run some tests using the compiler options, and will let you know what the results are ...

Initial results are that /inhibit_F2K 1 seems to disables BIND(C), while /-F2K disables quite a few other features, including the use of intrinsics in initialisation, various new intrinsic functions, DO CONCURRENT, square brackets, allocatable dummy arguments etc. The F2K documentation in the help pages is rather out of date, so there is a lot more that stops working with /-F2K than suggested there.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group