error #6341 - ifx can't compile line like: if(aFunction)

[cean]

Here is a demo.

! if_aFunc.f90
!======================================================================
! Compile with: 

! ifx if_aFunc.f90
!======================================================================
! Compiling Errors:

!Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.1.0 Build 20250317
!Copyright (C) 1985-2025 Intel Corporation. All rights reserved.

!if_afunc.f90(27): error #6385: The highest data type rank permitted is INTEGER(KIND=8).   [AFUNC]
!      if (aFunc(sText1)) print *,'false'
!----------^
!if_afunc.f90(27): error #6341: A logical data type is required in this context.   [AFUNC]
!      if (aFunc(sText1)) print *,'false'
!----------^
!compilation aborted for if_afunc.f90 (code 1)
!======================================================================
!source

      logical      :: iRet       
      iRet = aFunc(sText1)
      if (iRet) print *,'Work' 
      
      !Can't compile next line 
      if (aFunc(sText1)) print *,'Not Work.'
      end
!======================================================================
RECURSIVE LOGICAL FUNCTION aFunc()
      aFunc=.TRUE. 
END FUNCTION aFunc

[Steve_Lionel]

The compiler is correct, because aFunc is implicitly REAL and not allowed as the IF expression. It's possibly also a mismatch in your real application. Try this instead:

      logical      :: iRet, aFunc       
      iRet = aFunc(sText1)
      if (iRet) print *,'Work' 
      
      !Can't compile next line 
      if (aFunc(sText1)) print *,'Not Work.'
      end

[cean]

why this definition doesn't work: RECURSIVE LOGICAL FUNCTION aFunc()

How to define a function to return a  LOGICAL value?

I am trying to compile Xeffort. It has a lost of this kind of call.

[witwald]

Here is a working example of your original code. It compiles and runs using the Intel ifx compiler (under Windows). It is necessary to ensure that the data types are explicitly declared. Using 'implicit none' will help you to ensure that this is the case.

program prog_if_aFunc

implicit none

logical           :: aFunc, iRet
character(len=20) :: sText1

iRet = aFunc(sText1)
if (iRet) print *,'Works - iRet'

if (aFunc(sText1)) print *,'Works - aFunc'

end

!======================================================================

RECURSIVE LOGICAL FUNCTION aFunc(sText)
  implicit none
  character(len=*), intent(in) :: sText
  aFunc = .TRUE.
END FUNCTION aFunc

 Below is the output:

 Works - iRet
 Works - aFunc

[cean]

No, you have the redeclare in the main.
logical :: aFunc

I don't want to add this.

[witwald]

The compiler is not clairvoyant when it comes to using functions in a program. In the C programming language, this issue is gotten around by the use of header files. That way the compiler knows how to deal with a function when it encounters it. Of course, most Fortran compilers handle intrinsic functions, which are part of the language standard and are thus well defined, in the manner you are thinking of.

[Steve_Lionel]

The main program doesn't know the declaration of aFunc as it is a separate subprogram. Just having it in the same source file is not sufficient. Given this, you must declare it in the main program or from whichever program unit you call it from. You can avoid this by putting aFunc in a module and USEing the module in the main program,. or by making aFunc an internal subprogram of the main, after a CONTAINS.

For further reading, see my 2012 post Doctor Fortran Gets Explicit - Again! - Doctor Fortran

[cean]

Thanks all.

I got this question when trying to compile Xeffort. 

Look at the code, it is in a module. Like the STRCMP function in xftstrings.f90

[Steve_Lionel]

Your example has no module and in no way resembles xftstrings.f90. Which part of xftstrings.f90 do you think is a problem? I can tell you that the original sources build fine with a 32-bit compiler.

[cean]

[andrew_4619]

That error you highlight will be because the module that contains STRCMP has not compiled so the USE association as logical is not seen. These are  simple problems you are highlighting and will get you 0.1% down the path of getting an x64 build sorted . I actually have an X64 build after many hundreds if edits and some necessary design modification.   It does not successfully run  all the sample programs due to  run time bugs. My modified X64 version does build and run fine in 32 bit builds....