- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As for your extension procedure, that's a compiler bug. It should allow this. One of the Intel folks will escalate it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I reported to defect with the extension procedure to Development.
(Internal tracking id: DPD200419309)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for all the help and demonstration.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
All right, Devorah, Thank you.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page