Compiler Quirks

[Intel_C_Intel]

I have waited until upgrading to CVF 6.5 to see if any of the following quirks (bugs?) had been fixed. However, no change from 6.1A on these.

Initial setting of variables (1)

Despite my Language Reference Manual, p5-27 ?Rules and Behaviour? stating quite clearly:

?A variable can be initialised only once in an executable program.?

Not so! It apparently allows setting as many times as you like without complaining, even in the same DATA statement, but takes the value of the last setting.

Initial setting of variables (2)

Although the initialisation of array variables is superficially similar between DATA statements and setting at declaration, there is an irritating difference. In a data statement to set array BWINFAC the following is legal:

DATA BWINFAC / 3*1.D0 /

In setting at declaration the following is illegal:

REAL*8, DIMENSION(3) :: BWINFAC = (/3*1.D0 /)

So one has to use:

REAL*8, DIMENSION(3) :: BWINFAC = (/1.D0, 1.D0, 1.D0 /)

Which is not such a pain for arrays of size 3, but I became a Bear with a sore head on some much longer ones, eg when the following was illegal:

CHARACTER*4, DIMENSION(24) :: FMT4 = (/?(1H+?,22*? ?,? )?/)

Unused Variables

When compiling using /warn:unused, the compiler wrongly complains that argument FY1 in subroutine ITER1V below is unused; in fact it is used, and the subroutine produces the correct values.

 
SUBROUTINE ITER1V(X1,Y1,FY1,X1MIN,X1MAX,DX1,N) 
IMPLICIT NONE 
REAL*8 X1, Y1, X2, Y2, Y, FY1, X1MIN, X1MAX, DX1, 
1 LINEAR_INT, XX1(2), YY1(2), DX 
REAL*8, PARAMETER :: OTOL = 1.D-10 
INTEGER N 
LINEAR_INT(X2,X1,Y2,Y1,Y) = (Y-Y1)*((X2-X1)/(Y2-Y1)) 
C 
IF (N .EQ. 1) THEN 
  YY1(2) = Y1 
  XX1(2) = X1 
  X1 = X1 + DX1 
ELSE 
  XX1(1) = X1 
  YY1(1) = Y1 
  IF (DABS(YY1(2)-YY1(1)).GT.OTOL) THEN 
    DX = LINEAR_INT(XX1(2),XX1(1),YY1(2),YY1(1),FY1)  ! FY1 is used! 
    IF (DABS(DX) .GT. 2.*DABS(DX1)) 
1      DX=DSIGN(2.D+00,DX)*DABS(DX1) 
    X1 = XX1(1) + DX 
  END IF    
  IF (X1.LT.X1MIN) X1 = X1MIN 
  IF (X1.GT.X1MAX) X1 = X1MAX 
C 
  XX1(2) = XX1(1) 
  YY1(2) = YY1(1) 
END IF 
C 
RETURN 
END 

I presume that I have to put up with these irritations. Please preface any replies ?Oh Bear of little brain!?

[marklewy]

Oh bear of little brain,

Re: initialisation (2). Repeat factors in array constructors are not part of the Fortran standard, hence the lack of support. Your friend here is the implied-do loop, see page 3-46 of the Language reference manual.

Re: unused variables. Have you let VF support know about this problem?

HTH,

Mark.

[Intel_C_Intel]

Mark,

Thanks for that - but do you not then need a parameter array set beforehand, which will need every element written out. So it will help with repeated settings of the same data in a sequence of different variables, but the basic irritation is still there.

I have not yet sent the unused variable example to COMPAQ Support, because I am waiting for someone to point out (obvious?) shortcomings in the Subroutine. Although I would not have written it quite that way, I can see nothing obviously wrong. The compiler is consistent in also complaining about a similar argument in a 2-D version of this 1-D iteration step.

Bear of little brain

[marklewy]

Oh Bear of little brain,

I'm not entirely clear what your first paragraph means, but I think the answer is no.

Just to clarify my original reply, you can cast your 2nd example with an implied-do loop as:

CHARACTER*4, DIMENSION(24) :: FMT4 = (/ '(1H+', (' ', i = 1, 22), ' )' /)

I couldn't see anything obviously wrong with your subroutine either.

Mark.

[Intel_C_Intel]

Mark,

Thanks for the example - I was living up to my handle in my response to you. One down, two to go on this one now.

Bear of little brain

[Steven_L_Intel1]

The unused variable warning is a bug - we'll fix that. Seems to happen when the only use is as an argument to a statement function.

Regarding multiple initialization - the Fortran standard says that a variable may be initialized once only, so our manual says that too. However, the compiler does try to "do the right thing" if you initialize multiple times, for compatibility with our earlier F77 compilers. This is still a bad thing to do, and it may make your program non-portable, so I recommend against it in general.

Steve

[Intel_C_Intel]

Steve,

Many thanks: I found out about the possibility of multiple initial settings when converting a rather long BLOCK DATA, getting rid of COMMON and setting values on declaration in Modules. In widely separated parts of the BLOCK DATA, the same Logical variable had been set twice (but differently!). I have consequently resolved to set initial values only at declaration, so I would thoroughly endorse your comments.

Bear of little brain