re: how nonstandard is this?

[Steven_L_Intel1]

I tried the example you posted (after editing out the undefined kind names) in 6.6B and it didn't give this standards warning (I did use /stand:f95). We did add quite a bit of standards checking (and corrected other inappropriate checking) in 6.6B.

Given the message, I suspect what triggered it was an initialization clause not included in your sample here.

If you have a complete sample that shows what you think is an inappropriate warning, please send it to vf-support@compaq.com

Steve

[Jugoslav_Dujic]

FYI, there were other "side effects", some even more unpleasant (I sent it as a bug report and Steve told me it was fixed in latest, not-yet-released version). CVF 6.6B swallows the following without even a warning (note absence of TARGET attribute throughout):

program TargetBug

   implicit none

   ! Variables

   integer, allocatable:: i(:)
   integer::              j(100)
   integer, pointer::     p(:)

   integer::              k
   integer, pointer::     q

   ! Body of TargetBug
   allocate(i(100))
   i=0
   p=>i
   p=>j
   q=>k
   write(*,*) p(1)

   end program TargetBug

While, on the following, it prints "1" instead of "2":

MODULE m

IMPLICIT NONE

!===========================
CONTAINS
!===========================
SUBROUTINE foo(n)

INTEGER, INTENT(OUT):: n

INTEGER, EXTERNAL:: bar

n = bar()

END SUBROUTINE Foo
!===========================
INTEGER FUNCTION Bar()

Bar = 1

END FUNCTION Bar

END MODULE m
!===========================
PROGRAM Proggie

USE m

IMPLICIT NONE

INTEGER:: n

CALL Foo(n)
WRITE(*,*) n

END PROGRAM Proggie
!===========================
INTEGER FUNCTION Bar()

Bar = 2

END FUNCTION Bar

Caveat canem!
Jugoslav

[Steven_L_Intel1]

Dmitri,

Your second example is somewhat different from the first. The compiler is correct in issuing the warning because of the following:

You are using MERGE in a specification expression, as part of the bounds of the array function return value.

A specification expression is a scalar integer expression with the constraint that it is "restricted", meaning that it must follow certain rules. The rules are rather long and convoluted in this case, but the essence is that it is required that each of the arguments to MERGE be a restricted expression, and package=="v" does not qualify (because it is of type logical, not integer).

Now when you had transFirst there instead, it fell under a different part of the rule and was permitted.

By the way, when I comment out your blank module, I still get the warning.

Steve

[Steven_L_Intel1]

Jugoslav,

Your case is an unrelated issue (although it fell out of our going through "Corrigendum 1" and trying to fix the problems we found. In your case, we didn't get it quite right. In Dmitri's, I think we did.

Steve

[Steven_L_Intel1]

I am writing this from home and don't have time to respond in detail, but..

1. I can reproduce the "oddity". Interesting.

2. The difference between an actual argument and an expression is that the actual argument meets rule (2) of what can be in a restricted expression, "A variable that is a dummy argument that has neither the OPTIONAL nor the INTENT(OUT) attribute, or a variable that is a subobject of such a dummy argument."

I didn't make any claims based on which particular intrinsic you used. Indeed, F95 does relax the rules as compared to F90, but there are still some restrictions.

More will have to wait until I have the time to write a detailed response.

Steve

[Steven_L_Intel1]

Send me mail at vf-support@compaq.com, and I'll see if I can get you a recent compiler you can try.

Steve