Going dotty over user defined operators

[IDZ_A_Intel]

Intel Fortran 11.1 update 5 gives a syntax error (found '.' when expecting ... well, pretty much anything else it seems) on the following.

TheCompilerSpotsADot.f90

The compiler seems to accept a similar pattern using an intrinsic operator - something like .NOT. (.OpOnA. a) - is there an addiitonal restriction for user defined operators that I'm missing?

If I put the expression in parenthesis the compiler complains (with /stand:f03 /warn:all) that the added () is an extension. Isn't an expression in () just another expression? Or does the std express that such expressing of expressions is expressly forbidden?

Thanks,

IanH

[IDZ_A_Intel]

Ian,

Your attachment wasn't attached (accessible).

Jim

[IDZ_A_Intel]

Attempt two!

(There's a minimum character limit for posts?)

[Steven_L_Intel1]

Ok, that's a bug. Issue ID is DPD200151085.

The parentheses issue is interesting. What would be non-standard is:

WRITE (*,*) (A,B,C)

But in a WRITE, a single I/O list item can be an expression which can be in parentheses. I'll report that too. However, you can use the parentheses as a workaround.

[Steven_L_Intel1]

I expect the error message to be fixed in Update 6.

[Steven_L_Intel1]

And indeed it is.

[IDZ_A_Intel]

I get the same error message with 11.1.065 when I apply a user defined operator to an array of user defined type.

[fortran]MODULE A
  IMPLICIT NONE
  PRIVATE
  PUBLIC :: OPERATOR(.OpOnA.)
  TYPE, PUBLIC :: AType
    LOGICAL :: logical_comp
  END TYPE AType 
  INTERFACE OPERATOR(.OpOnA.)
    MODULE PROCEDURE op_on_atype
  END INTERFACE OPERATOR(.OpOnA.)  
CONTAINS
  FUNCTION op_on_atype(obj) RESULT(val)
    TYPE(AType), INTENT(IN) :: obj
    LOGICAL :: val
    !****
    val = obj%logical_comp
  END FUNCTION op_on_atype
END MODULE A

PROGRAM OutOutDamnSpot
  USE A
  IMPLICIT NONE
  TYPE(AType) :: an_array(1)
  !****
  an_array(1)%logical_comp = .FALSE.  
  WRITE (*, *) .OpOnA. an_array(1)  ! error #5082 here
END PROGRAM OutOutDamnSpot
[/fortran]

(Or am I confused about what got fixed? If so - then I'm still seeing the non-standard usage warning with /stand:f03 and friends)

Ta,

IanH

[Steven_L_Intel1]

It could be that your code is just different enough to trigger another bug. We'll look at it.

[Steven_L_Intel1]

Ian, your new example is bug DPD200155692. I don't know why the previous fix did not work for this case too, but I do know that the parser is complex.

[Steven_L_Intel1]

Ian,

The problem you had will be fixed in the next major release.