error #6780: A dummy argument with the INTENT(IN) attribute shall not be defined nor become undefine

[DataScientist]

I recently started using `ifx` for development and testing after accidentally uninstalling `ifort` and not being able to find a download link anymore.
However, the new ifx 2025.2 is complaining about many issues in the code, which were not raised by either gfortran or ifort (or possibly even the previous versions of ifx, not sure about this one as the settings used might have been different).

Most recently and importantly, I frequently encounter the errors of the following nature:

error #6780: A dummy argument with the INTENT(IN) attribute shall not be defined nor become undefined.

for a line of code that is completely valid by the Fortran standard. The entire code is impossible to paste here and I have yet to find the time to reproduce this error in a minimal example.

But the relevant section of the code should at least give the compiler developers and forum members an idea of what might be wrong with the code or the compiler.

error #6780: A dummy argument with the INTENT(IN) attribute shall not be defined nor become undefined. [DIVISOR]
if (abs(divisor%re) < abs(divisor%im)) then
--------------------------^

There is nothing in the above if construct that is being (re)defined. So why is ifx complaining about this conditional?

[andrew_4619]

I don't know the answer but it seems that have been numerous bugs posted in recent months relating to the parts of complex numbers. I am guessing this is one of those.

[Steve_Lionel]

I can't reproduce this based on what you have posted:

subroutine sub (divisor)
complex, intent(in) :: divisor
if (abs(divisor%re) < abs(divisor%im)) then
   print *, 1
else
   print *, 2
end if
end subroutine sub

D:\Projects>ifx -c t.f90
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.2.0 Build 20250605
Copyright (C) 1985-2025 Intel Corporation. All rights reserved.


D:\Projects>

 So, we'll need to see a reproducer.

[DataScientist]

@Steve_Lionel 
Steve, thank you for taking the time to test this matter.
Unfortunately, I cannot readily reproduce this error here, as the code snippet is part of ~20,000 lines of code, whose interfaces reside in a parent module with procedures in child submodules and actual implementations included in the submodules. Maybe this error occurs because of separating the interfaces or the fact that this code snippet (below) is an internal function in the included file in the submodule. The code is compiled with heap arrays. I have noticed several compile-time errors due to heap array usage, some of which have also been confirmed with the ifx dev team.
Indeed, as you observed, I have also successfully run the same syntax code in isolated programs. However, the same code fails in the actual codebase, which has a module/submodule/include structure that contains it as an internal function. Here is the full internal function,

contains

    pure elemental function divide(dividend, divisor) result(quotient)
        complex, intent(in)    :: dividend, divisor
        complex                :: quotient
        real                   :: r, d
        if (abs(divisor%re) < abs(divisor%im)) then ! The offending line
            r = divisor%re / divisor%im
            d = divisor%im + r * divisor%re
            quotient%re = (dividend%re * r + dividend%im) / d
            quotient%im = (dividend%im * r - dividend%re) / d
        else
            r = divisor%im / divisor%re
            d = divisor%re + r * divisor%im
            quotient%re = (dividend%re + dividend%im * r) / d
            quotient%im = (dividend%im - dividend%re * r) / d
        end if
    end function divide

end

Here is a test of this code, which compiles successfully (but fails in the codebase where it is an internal function): https://godbolt.org/z/xGbbza4xM

Regardless of the code structure and the circumstances, don't you believe that ifx should never throw an error for the above if-block, even if the arguments are `intent(in)` or whatever, as long as they are complex? It is a 100% valid code, to my understanding. Am I wrong about this? Notably, neither the venerable ifort nor gfortran complains about the same code.

[DataScientist]

@Steve Here is an extra interesting piece of information. I have another identical if-block in an entirely independent set of module/submodule/include files that does not cause any compile time errors. The only structural difference between the two if-blocks is that the offending if-block is in an internal function (whose arguments `dividend` and `divisor` override parent subroutine's variables with the same names), while the other if-block in the other module is not part of an internal function, even though the host procedure follows a similar module/submodule/include file code structure as in the former. So, I do not think `heap-arrays` or module/submodule structuring are to blame for this compile-time error as I speculated above. Sorry for the lack of a minimal working example for reproducing the error at this time.

[DataScientist]

Again, under any circumstances, ifx should not emit a compile-time error for the if-block condition as it is valid Fortran syntax under any circumstances.

[Steve_Lionel]

Sorry, I am not going to keep trying random combinations of things to see if I can reproduce it. Please make the effort to provide a minimal reproducer.

[DataScientist]

@Steve_Lionel 
I did not mean for you to try random combinations again. Here is my question for the forum (and you as the topic expert): Regardless of the code structure and the circumstances, don't you believe that ifx should never throw an error for the above if-block, even if the arguments are `intent(in)` or whatever, as long as they are of type complex? 

When I replace the complex-part-designators with `real()` and `imag()` equivalents, ifx has no more issues with the if-block. This is very likely a bug in the implementation of complex-part-designators in ifx.

[Steve_Lionel]

I reserve comment until I can see a reproducer. My experience is that the issue is somewhere else in the code. It does not pay to focus on that one line - it could be some previous line or even something up-scope has confused the compiler. I'm not paid to debug anymore.

[garraleta_fortran]

No problem

(15.00000,5.000000)