forums.silverfrost.com

IanLambley · Joined: 17 Dec 2006 Posts: 510 Location: Sunderland

How about adding a /debug

JohnCampbell · Joined: 16 Feb 2006 Posts: 2621 Location: Sydney

Ian,

I tried including /debug, but no change.
Just to check, I tried another small program example with /check, then SDBG and it started perfectly with the fortran code window, so I'm not sure why this example above starts with the assembler code window.
Does anyone know why this occurs ?

John

PS : It's also a pain that the module "interfaces" can not be used in SUB4. If it was, then we could have a module interfaces, which declares the interface for all subroutines and functions used in a program. This could then be used by the compiler to check for errors in argument lists for all uses of each routine. Otherwise there is never any checking that the INTERFACE defined is the same as in the coded routine. We still have 2 seperate definitions of the interface, which is a major deficiency in the INTERFACE concept in Fortran.

IanLambley · Joined: 17 Dec 2006 Posts: 510 Location: Sunderland

John,
Create a separate .f95 file containing the module and interface data. Compile it to produce the all_data.mod
Compile and link the main code part.
SDBG then opens the code window.

I don't see why this should be the case, - is it an error?

Ian

JohnCampbell · Joined: 16 Feb 2006 Posts: 2621 Location: Sydney

Paul,

Any chance of a fix to this error : "array sections not working with /check, for some types of arrays" to be included in the next release.

This has been an annoying bug to me for many years.

John

PaulLaidler · Posted: Fri Feb 05, 2010 11:58 am Post subject:

Sorry but this bug is still outstanding.
Thank you for reminding me.
The current work around is to add /inhibit_check 5.

lgriffiths · Joined: 09 Feb 2010 Posts: 3

Hi,
In regards to the error:
"Attempt to call a routine with argument number XX containing too few array elements" when using \check

I've been getting the same error. Lets say when program main calls subroutine SubA which calls subroutine SubB. With arrayx being passed to each. Arrayx initially declared in Program Main. Also, Subroutine SubB recieves some truncated version of arrayx (in my case one dimension less)

I.e.

Program main
bla bla
CALL subA(arrayx(:,:),n1,n2)
End Program main

Subroutine SubA
bla bla
CALL subB(arrayx(i1:i2,1),n) !ERROR
End subroutine SubA

a work around is to call subB as:

CALL subB(arrax(i1:i2,1:1),n)

For me this causes the error to go away. I have no idea why, but hope it helps.

Laurence
_________________
Well, Blimey! Lets have another go at it... Yeah!

JohnCampbell · Joined: 16 Feb 2006 Posts: 2621 Location: Sydney

Paul,

Lately I've been using /check more often and this error keeps coming up. The length of the array section is not being correctly transferred, but if I step up the stack in the debugger, all the info is available in the array with the correct dimension, although I assume the problem is that /check says the supplied array is not 4 long. I've cut the following example from my code.

PaulLaidler · Posted: Thu Apr 22, 2010 8:46 am Post subject:

Thanks. The bug is still outstanding and I hope to have it fixed before too long.

PaulLaidler · Posted: Wed Jul 21, 2010 7:13 am Post subject:

Sorry for the delay in getting back to you on this bug.
Having finally revisited the problem I find that the bug has been reported elsewhere and is now fixed. The fix will in the next release.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2621 Location: Sydney

Paul,

That is great news. I will be keen to get the update and get past this point.
I have had to avoid /check for these routines. Can you give any summary as to why these arrays lost their size attribute?

John

PaulLaidler · Posted: Wed Jul 21, 2010 8:26 am Post subject:

As I understand it, the size attribute was not lost (is there evidence that it was?).

Run time checking of array sizes turns out to be very difficult (maybe impossible with the current design for runtime checking) for array sections of varying size. The fix is to switch off this aspect of /check in this particular case.

JohnCampbell · Joined: 16 Feb 2006 Posts: 2621 Location: Sydney

Paul,

I thought it was lost, but now it is found ?? If you take the example I provided above and compile with /check and step in SDBG, at "call get_angle_props (tprop(9:12), angle_props)" SDBG claims the dimension of "tprop(9:12)" is not 4.
I have NOW modified the program. Try this modified program below using /check and step through SDBG and it shows a dimension of 1 for dimen and 9 for props ?

PaulLaidler · Posted: Wed Jul 21, 2010 2:41 pm Post subject:

I am guessing a little here but you probably need an interface together with the corresponding change in the definition of the subroutine...

JohnCampbell · Joined: 16 Feb 2006 Posts: 2621 Location: Sydney

Paul,

I did have the declaration of : real*8 dimen(4), props(9)
I changed it to: real*8 dimen(*), props(*)
So that I could get through the subroutine call with /CHECK

nd = size (dimen) ! gives an incorrect value of 1
np = size (props) ! gives a correct value of 9

For either declaration, I don't think I need an INTERFACE
The problem is that the size of DIMEN is being provided incorrectly for /CHECK. Does the latetest fix address this problem ?

I only need this so /CHECK works past this point.
I thought my possible problems that require /CHECK are not with this routine.

John

PaulLaidler · Posted: Thu Jul 22, 2010 8:57 am Post subject:

If you provide the interface for get_angle_props in the definition of sectin_prop then SDBG reports the sizes correctly.

The interface tells the compiler that the shapes of the arrays must be passed together with the base addresses. Otherwise get_angle_props does not receive the shapes of the arrays.

I can get the compiler to trap the explicit call to SIZE for a "star-sized" array but I don't know if anything can be done to "fix" SDBG in this context.