Problem passing the real part of a complex using %re syntax

Compilers Intel
1

I was surprised by an error generated by ifx 2025.0.0 20241008 (Ubuntu) concerning those pieces of code:

    subroutine testc(calcul, attendu, precision)
        complex(wp), intent(in) :: calcul, attendu
        real(wp), intent(in)    :: precision

        call testr(calcul%re, attendu%re, precision)
        ...
    end subroutine

    subroutine testr(calcul, attendu, precision)
        real(wp), intent(in)        :: calcul, attendu, precision

The error is:

././src/RAY3D_libunit.f90(58): error #6780: A dummy argument with the INTENT(IN) attribute shall not be defined nor become undefined.   [CALCUL]
        call testr(calcul%re, attendu%re, precision)
-------------------^

No problem with gfortran 14.2.0.
I had the strange intuition to put those access to the real part of a complex between parenthesis:

        call testr((calcul%re), (attendu%re), precision)

and now ifx compiles it without problem.
Is there any reason for this behavior?

N.B. Same problem of course with %im syntax.

2 Likes
2

It’s a mistake, the compiler is issuing an error for conforming code. Putting the designator X%RE in brackets forces interpretation of the actual argument as an expression, which cannot become defined or undefined, so the check for this spurious error is not done.
Arguably, leaving the workaround brackets in the source is a good reminder to the next human that those complex variables are not going to be modified by the procedure reference.

1 Like
3

Here is a minimalist fpm project reproducing the error with ifx:

module strange
  implicit none
  private

  public :: say_hello
contains
  subroutine receive(x, y)
    real, intent(in) :: x, y
  end subroutine

  subroutine inter(z)
    complex, intent(in) :: z
    call receive(z%re, z%im)
  end subroutine

  subroutine say_hello
    complex :: z = (2.0, 3.0)
    call inter(z)
  end subroutine
end module strange

I needed to add the inter(z) subroutine to reproduce the error. Calling the receive() subroutine directly from say_hello would compile.

$ fpm run --compiler ifx
fpm: Entering directory '/tmp/strange'
strange.f90                            failed.
[ 25%] Compiling...
././src/strange.f90(13): error #6780: A dummy argument with the INTENT(IN) attribute shall not be defined nor become undefined.   [Z]
    call receive(z%re, z%im)
-----------------^
4

Compiler Explorer suggests that previous versions of ifx were not complaining about this case.

5

I think so, because I did not touch my computing model for one or two years, but it was indeed running without problem with ifx before.

Updated: same problem with ifx (IFX) 2025.1.0 20250317 that just arrived in Ubuntu.

6

Has anybody reported this upstream?

7

related:

But I do not see a new entry. Looks like it might be a regression.

2 Likes
8

I tried adapting your test to see if the %kind designator also triggers problems, but it appears to work. Probably the %kind designator is treated differently at the level of types, and not like %re and %im which need to exist at the level of variables.

1 Like