redefine intrinsic operator

[Blane_J_]

I am a little confused of the default operation of intrinsic operator(==), here's the example:

program main
    implicit none

    if('a' == 96) print*, 1
    if('a' == 97) print*, 2
    if('a' == 98) print*, 3

end

there's no output when program executes. And what's more, when extending the operator(==) to deal with character-integer comparison, As:

module test
    implicit none
    
    interface operator(==)
        module procedure :: equals
    end interface operator(==)

    contains

    function equals(c, value)

    logical               :: equals
    character, intent(in) :: c
    integer,   intent(in) :: value

    equals = (c == char(value))
    
    end function equals
    
end module test

The compiler generates an error message:

error #6748: The type/rank for the arguments of this specific function for a defined OPERATOR redefines intrinsic expression operations.   [EQUALS]

So how does the operator(==) work when dealing with operands other than character-character ? And is it extensible? Appriciate any help.

PS: The user-defined extension of other intrinsic comparison operators such as (>, <, >=, <=) are all fine when dealing with character-integer operands.

[Steve_Lionel]

If you had compiled your first program with standards checking enabled, you would have seen a clue:

t.f90(4): warning #7840: A character string or Hollerith string is non-standard in this context.   ['a']
    if('a' == 96) print*, 1
-------^
t.f90(5): warning #7840: A character string or Hollerith string is non-standard in this context.   ['a']
    if('a' == 97) print*, 2
-------^
t.f90(6): warning #7840: A character string or Hollerith string is non-standard in this context.   ['a']
    if('a' == 98) print*, 3
-------^

It is not standard Fortran to use the equality operator with a character and numeric type. So what is happening here?

Note the "Hollerith string". This is a variant of a feature that was in FORTRAN IV (F66) but dropped in F77. F66 didn't have character type at all, but did have Hollerith constants of the form 4HABCD. These were actually numeric values. Many compilers then added an extension allowing you to use quoted strings instead of the nH syntax.

So what does 'a' mean? Since character values are "big-endian", you get a default integer value with the high byte set to 97. This is not the same as 97.

I strongly advise against using this extension. If you had used IACHAR('a') instead, you'd get what you want.

[Steve_Lionel]

As for your extension procedure, that's a compiler bug. It should allow this. One of the Intel folks will escalate it.

[FortranFan]

The compilation error though shown by OP with the defined operator looks like a bug in the compiler, may be someone will take a closer look.

[Kevin_D_Intel]

I reported to defect with the extension procedure to Development.

(Internal tracking id: DPD200419309)

[FortranFan]

Kevin D (Intel) wrote:

I reported to defect with the extension procedure to Development.

(Internal tracking id: DPD200419309)

Thanks, most surprising though.  And it looks like this one goes back all the way to the days of Digital Fortran as a Fortran 90 compiler, the same exact text appears in the compiler message!

[Steve_Lionel]

I suspect the problem relates to the compiler supporting comparison of Hollerith literals as an extension. It needs to first check to see if there is a user-supplied generic extension before applying the nonstandard behavior.

[Blane_J_]

Thanks for all the help and demonstration.

[Blane_J_]

Kevin D (Intel) wrote:

I reported to defect with the extension procedure to Development.

(Internal tracking id: DPD200419309)

Hi, Is anyone know if this problem has been fixed in the latest release ?

[mecej4]

The 2018 compiler took in the file with no complaints.

You may wish to complete your testing by writing a main program that uses the module and exercises the operator for proper functioning.

[Blane_J_]

mecej4 wrote:

The 2018 compiler took in the file with no complaints.

You may wish to complete your testing by writing a main program that uses the module and exercises the operator for proper functioning.

Thanks, mecej4. I'll try out later.

[Devorah_H_Intel]

Blane J. wrote:

Quote:

Kevin D (Intel) wrote:

I reported to defect with the extension procedure to Development.

(Internal tracking id: DPD200419309)

Hi, Is anyone know if this problem has been fixed in the latest release ?

I confirmed with development that this was fixed in 18.0 compiler.

[Blane_J_]

All right, Devorah, Thank you.