Silverfrost Forums

Welcome to our forums

Compiler diagnostic on BLOCK DATA items

27 Feb 2012 3:43 #9720

Dear forists:

A Block Data routine is supossed to initialize the common areas in DELSML.INC. Both are included below.

FTN95 complains with the following disgnostic:

  1.     DATA    MSKTPA  / Z80000000 /
    

*** All items in a a DATA statement's value list must be literal constants

Could you please let me know why DATA item values cannot be integers, or hexadecimal, as defined in my INCLUDE file?

Thanks a lot

---------------------- DELSML.INC -------------------------- C Include file with parameters and arrays for the smoothing and C sharpening factors. Also bits indicating active status and fault C status for a triangle. C Revision List: C March 1994 Original Version C C ... Sharpness codes for the 'fast' smoothing operation. Actual C values must be loaded by including BLOCK DATA program LOADSH. C INTEGER * 4 SHLE PARAMETER (SHLE = 4) C CHARACTER * 1 SH(SHLE) C INTEGER * 4 MSKTPA ,MSKTFL INTEGER * 4 MSKTP1 ,MSKTP2 ,MSKTP3 INTEGER * 4 MSKTPS(3) EQUIVALENCE (MSKTP1 ,MSKTPS(1)) EQUIVALENCE (MSKTP2 ,MSKTPS(2)) EQUIVALENCE (MSKTP3 ,MSKTPS(3)) C INTEGER * 4 ISHTR(3) COMMON /SHINT4/MSKTPA ,MSKTFL ,MSKTPS ,ISHTR COMMON /SHCHAR/SH CCC

--------------------------------BLOCK DATA-----------------------------

C DELSHL BlockData Initialization of status masks and common areas BLOCK DATA C For initializing status masks and smoothing and sharpening common area C in file DELSML.INC C Originally: INCLUDE '/u/albert/dvlp/newup/DELSML.INC' INCLUDE 'C:\users\albert\AIX\dvlp\newup\DELSML.INC' C DATA SH(1) / 'v'/ DATA SH(2) / 's'/ DATA SH(3) / 'h'/ DATA SH(4) / 'b'/ C DATA MSKTPA / Z80000000 / DATA MSKTFL / Z01000000 / DATA MSKTPS(1)/ Z60000000 / DATA MSKTPS(2)/ Z18000000 / DATA MSKTPS(3)/ Z06000000 / C DATA ISHTR(1)/ 29 / DATA ISHTR(2)/ 27 / DATA ISHTR(3)/ 25 / C

27 Feb 2012 4:07 #9723

Possibly because your hexadecimal constants are not in the FTN95 form?

(Page 183 of the FTN77 manual - see the documentation section of this website - says they should be Z'80000000' ).

Seems probable to me, as Z80000000 is a valid, if rather odd, symbolic name.

Never used this type of specification, so can't be sure.

E

27 Feb 2012 8:24 #9725

Many thanks. You hit the nail in the right place.

27 Feb 2012 8:26 #9726

Many thanks. You hit the nail in the right place.

23 Mar 2012 12:12 #9889

WARNING - Common block '//' was previously defined as size 8704 but is now defined as size 8656 WARNING - Common block '//' was previously defined as size 8704 but is now defined as size 24

How do I fix this or does it matter. I have data overlaying data after calling a function subprogram.

23 Mar 2012 10:10 #9891

You can ignore warnings, and you can also set the compiler to not issue specific warnings (using -ignore followed by the warning number). You could pad out this block in each routine where the warning crops up with extra bites to make it the same length, but only if the warning bothers you.

Eddie

23 Mar 2012 11:27 #9892

I prefer not to ignore valuable warnings like these. A possible reason:

integer*4   A,B,C

common  /what_ever/  A,B,C

... in one subroutine, but

integer*2  A,B,C,D

common  /what_ever/  A,B,C,D

for instance in another subroutine will produce that warning. And ignoring that is not a good idea...

Regards - Wilfried

23 Mar 2012 1:02 #9894

Create an 'INCLUDE' file with all the variable/array definitions and common block definitions. Then include it in the appropriate routines. Or do it via modules and 'USE' Ian

23 Mar 2012 5:19 #9896

Wilfried,

He already said he was overlaying data - i.e. he knows that the COMMON block contains different things in different places.

I always exclude Warning 179 because it irritates me (it is the one that tells me I compared something to zero) - because I always test for zero before dividing by something that could be exactly zero as a result of a data error. Agree you are unlikely to get exactly zero as a result of a calculation, but then I wouldn't test for zero, I'd test for a small range around zero.

Ian,

If he uses INCLUDE, he has to INCLUDE different things in the different subroutines because of how he says that he has overlaid different things into this particular COMMON.

TarHot,

Why do you need to overlay anything? provided that you aren't a user craving for multi-gigabyte arrays, then there is ample space for just about anything - especially if you are using it for small (c. 8k bytes) COMMON.

Eddie

23 Mar 2012 5:55 #9897

I have data overlaying data and I do not want that. Sorry for the misunderstanding. Thanks for the help, I'm sure I'll have more questions.

21 May 2012 2:06 #10205

I'm trying to use common in a function as well as a subroutine. I looks like everything is OK until the call to the function or the subroutine. I get a run time error when trying to print either argument 'S' or 'T'. I tryed looking at your BLOCK COMMON but I couldn't find enough information to understand how to set it up. I think I just need a very good example. Can you help? Is there something I need to do in the SLINK? How would I set that up?

[code] winapp program testprint02 INCLUDE <windows.ins> EXTERNAL printer

INTEGER S(7),T(7)
CHARACTER *4 LINEA

COMMON S,T,LINEA

DO I=1,7
  S(I) = I
  T(I) = I
  ENDDO

  LINEA = 'TEST' 

! DO I = 1,7 PRINT *,S(I),T(I) ENDDO PRINT *,s(1),t(7),LINEA

i=winio@('%sc[Ready to Print?]%ww[invisible,toolwindow]','PRINTER_OPEN',7,printer)

call testit close (7)

END ! CONTINUE ! CONTAINS

! c----- INTEGER FUNCTION printer()

COMMON LINEA,S,T

	write(7,15)'Hello'
15		format(1x,a5)
  	do i = 1 , 10
 		print 10, i

10 format (5X,i5) write (7,10) i end do PRINT *,s(2),LINEA,'FUNCTION' printer=0 END FUNCTION PRINTER

subroutine testit

COMMON LINEA,S,T

	print *,'subroutine testit'
    write (7,20)

20 format (1x,'subroutine testit') PRINT *,LINEA,'SUBROUTINE'

end SUBROUTINE TESTIT

! END PROGRAM TESTPRINT02

21 May 2012 8:10 #10207

Well I changed the order and I still get a run time error.

'Error 29. Call to missing routine _S at ox004014e3

I also tried to use a CONTAIN statment and that screws up the Function Subroutine.

HELP!

21 May 2012 9:29 #10208

LINEA needs to be declared as CHARACTER*(4) in every routine where it is used: the definition in the calling program is not enough. S and T are arrays, and their lengths also need to be declared in every routine.

This is because a variable name has a scope that is limited to the routine in which it is declared and used. Up to Fortran 77 there was no way of giving a variable name that 'spanned across' routines. Under Fortran 90 and later, a variable name can have a wider scope using CONTAINS and/or MODULEs. In my opinion, you have to use this approach OR the approach using COMMON, because if you mix them you will get in a terrible mess. COMMON is, in any case, a tricky thing to use.

Some people will also advise you to use the declaration:

IMPLICIT NONE

in every routine. Then, you must specifically declare the type of every variable you use (and you must declare it in every routine). That will stop you making the error you made. On the other hand, lots of older Fortran books use what is known as 'implicit type' to avoid making many declarations.

If you use a variable as an array that has not been declared as an array, the Fortran compiler will assume that it is a FUNCTION, and will report that it is missing. (The underscore _ character is added to the name during this process).

I hope that you are not offended by this, but you really don't understand the basics, and you would benefit by getting some face to face instruction from someone who knows a lot more than you do. Self-tuition is possible, but it is a long and frustrating process. If you are anywhere near SW London, and would like some face-to-face help, send me a 'private message'.

Eddie

21 May 2012 11:50 #10209

Please bare with me on this, I've been working with Fortran since 1967 and used F77 thru 1988. The F77 was written by Dartmounth College capable of accessing HISAM data bases. This F77 used common the way it should be used which really ment common in all programs, included programs and subroutines. I agree that not all Fortrans are created equal but since I've been out of contact for about 30 years I have a little learning curve to go thru. The basics are still the same, it's just the new stuff that's been added over the years that I missed out on. The biggest change is the Windows interface. Please hang in there with me.

I may just abandon the Common stuff and use GOTO.

Please login to reply.