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 

*Invalid* dimension with assumed size array

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
jjgermis



Joined: 21 Jun 2006
Posts: 404
Location: Nürnberg, Germany

PostPosted: Fri Aug 17, 2012 11:10 am    Post subject: *Invalid* dimension with assumed size array Reply with quote

I have some strange behaviour - perhaps I miss something. In the example I have an assumed size array. In this case it is a m x n matrix meaning I only have to specify the 1st dimension. However, in the example below I get an *Invalid* message when I check the size with the debugger.

At the very bottom I have another example where I get the correct message. Am I missing something or is it a problem with the debugger?



This code works, i.e. in the debugger i = size(m,1) = 8 is given as the size.

Code:
PROGRAM bandmatrizen

IMPLICIT NONE

INTEGER :: n,i
REAL,DIMENSION(:,:),ALLOCATABLE :: m

n = 8
allocate(m(n,n))

call test(m,n)

deallocate(m)
END PROGRAM bandmatrizen

subroutine test(m,n)
implicit none
integer n,i,j
real m(n,*)

i = size(m,1)

return
end


This code does not work, i.e. in the debugger mention *Invalid* assumed size array.

Code:
      PROGRAM PROFILE

      implicit none
      integer nr
      parameter(NR=3000)
      integer IG(NR,50)

      CALL REDUCE(IG, NR)

      end

      SUBROUTINE REDUCE(IG, NR)
      implicit none
      integer NR
      INTEGER IG(NR,*)

      write(*,*) size(IG,1)

      RETURN
      END
Back to top
View user's profile Send private message
jjgermis



Joined: 21 Jun 2006
Posts: 404
Location: Nürnberg, Germany

PostPosted: Mon Aug 20, 2012 12:46 pm    Post subject: Reply with quote

This code is still puzzling. Using gfortran the code works without any problems. This is a working example.

It would be interessting to know why FTN gives problems here.

With a cut and a paste you can experience this yourself Wink
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Aug 20, 2012 3:47 pm    Post subject: Reply with quote

This is probably a bug. I will log it for investigation.
Back to top
View user's profile Send private message AIM Address
jjgermis



Joined: 21 Jun 2006
Posts: 404
Location: Nürnberg, Germany

PostPosted: Wed Aug 22, 2012 9:44 am    Post subject: Reply with quote

Hi Paul,

thanks for your comment on the message.

In a previous thread the debugger showed strange results. In that case we got a fix quite fast - really impressive performance from Silverfrost.

This of course set high expectaions for a quick work arround. What do think is the changes of getting 100% clearance on this issue?

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


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

PostPosted: Wed Aug 22, 2012 8:29 pm    Post subject: Reply with quote

There is a good chance that I will be able to fix this bug but I cannot promise a quick response.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Thu Mar 14, 2013 9:15 am    Post subject: Reply with quote

I have started to look at this problem and (for me) both of your samples fail with an access violation at run time.

This appears to be a regression.

The problem is not with the debugger. The size of the second dimension is not really "Invalid" but just not available to the debugger.

Please let me know if these two samples run correctly for you (without using the debugger) and what version of FTN95 you are using.
Back to top
View user's profile Send private message AIM Address
jjgermis



Joined: 21 Jun 2006
Posts: 404
Location: Nürnberg, Germany

PostPosted: Thu Mar 21, 2013 1:49 pm    Post subject: Reply with quote

Hi Paul

Thanks for the update on this issue.

I still get the same invalid message when using the debugger. At run-time (both Debug and Release) I get access violation.

The version of FTN is 6.00.0
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Mar 21, 2013 4:18 pm    Post subject: Reply with quote

Thank you. I have now tracked the regression as being at version 6.0.
I will be able to provide a fix for the regression that leads to an access violation at runtime but the "invalid" label in the debugger may have to be tolerated.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Thu Mar 21, 2013 11:56 pm    Post subject: Reply with quote

This bug is in an area of Fortran that is not a trivial problem. Any solution might have a lot of consequences for old codes.
The problem of array size has been around since I first learnt Fortran.
INTERFACE was introduced in Fortran 90, but this did not fully solve the problem.
The correct solution to the problem should have been an EXTERNAL_Fortran calling interface, where the rank and size of all arguments/arrays was included in the call information.

Perhaps the solution to Jacques problem is he should use an INTERFACE definition and appropriate dimension declarations, if he wants the dimensions available.
If you use ...*) then you are not requiring the size of the last dimension.
If you want the last dimension then use ...:)
There are some of us (at least me) who still use the pre allocate coding techniques for memory management, which does not have the array size available. These involve declaring a large array "A(100000)" and using parts "A(n1)" for managing memory allocation.
This is a historically significant coding technique and should not be disabled, especially until ALLOCATE allows an option to resize or an option to return the largest available array size.

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


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

PostPosted: Fri Mar 22, 2013 7:42 am    Post subject: Reply with quote

Just to confirm, this bug is a regression at version 6.0 of FTN95.
I now have a fix but not in time for the forth-coming release.
Apart this particular usage of the SIZE intrinsic, this bug has no other effect on the compiler.
Back to top
View user's profile Send private message AIM Address
davidb



Joined: 17 Jul 2009
Posts: 560
Location: UK

PostPosted: Fri Mar 22, 2013 8:20 am    Post subject: Reply with quote

With an assumed size dummy array then SIZE should work for all dimensions except the last one, e.g. the following is standard conforming.

Code:

SUBROUTINE XXX(A, IA)
INTEGER IA
REAL A(IA, *)
INTEGER N
N = SIZE(A,1)
PRINT *, IA, N
END


In this case, of course, the size is just IA. I can't think of a case where one would **need** to use SIZE to get the extent of a dimension, when it is explicit in the declaration.

Anyway, this is clearly a bug, and its good it will be fixed in due course.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
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
Page 1 of 1

 
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