Code generation changed in 2023.1 for %VAL parameters

[Christian]

When you call the 64 bit compiler "ifort -c test.f" with the following code, the generated assembler code changed from version 2023.0 and older to 2023.1:

      subroutine this_func

      implicit none
      integer val

      interface to subroutine bindc_func(val) bind(C)
        integer, value :: val
      end

      interface to subroutine value_func(val)
        integer, value :: val
      end

      interface to subroutine ref_func(val)
        integer, value :: val
      end

      val = 0

c     -- 2023.0+2023.1: Put 0 on stack
      call bindc_func(val)

c     -- 2023.0+2023.1: Put pointer to 0 on stack
      call value_func(val)

c     -- 2023.0+2023.1: Put pointer to 0 on stack
      call ref_func(val)

c     -- 2023.0+2023.1: Put 0 on stack
      call bindc_func(%VAL(val))

c     -- 2023.0: Put 0 on stack, 2023.1: Put pointer to 0 on stack
      call value_func(%VAL(val))

c     -- 2023.0: Put 0 on stack, 2023.1: Put pointer to 0 on stack
      call ref_func(%VAL(val))

      end subroutine

Is this change intended?

[Ron_Green]

We constantly fix bugs, add features, implement new features of F2018 and soon F2023.  Yes, we have made some changes around bind(c) and interfaces.  In every update there are many changes and fixes.

Does the code run correctly?  What exactly is your concern about a change in the assembly language? 

[IanH]

What's supposed to be the difference between value_func and ref_func?  Bar the identifier for the procedure, the subprograms have the same token sequence.

The non-bind(c) variants of the subroutines would be expecting a pointer on the stack.

The use of archaic language extensions with relatively modern language features gives me a headache.

[Christian]

Thank you for your responses.

I made a mistake by placing the ", value" in the ref_func - it shouldn't be there.

BUT when I change this, the code generated by the older versions (2023.0, 2020.4) changes to the code of the newer version (2023.1) - even for the call of the value_func... Funny.

The whole point of my initial post is this:

The older versions of the compiler (2020.4,2023.0) didn't put a pointer on the stack for the non-bind(c) variants (as @IanH assumed) but the value 0. Our called function assumed this behaviour.

The new version (2023.1) changes this behaviour and puts a pointer on the stack for non-bind(c) variants.

I now learned that the newer version is correct - so we have to change our assumption or use bind(c) to force the value on the stack.

[Xiaoping_D_Intel]

I have reproduced the change of passing "%val" parameter for "value_func" call in 2023.1.0 compiler:

For   "call value_func(%VAL(val))"

2023.0.0:

..B1.5:             # Preds ..B1.4

                # Execution count [1.00e+00]

    movl   (%rsp), %edi                 #33.12 // Immediate value of "0" is passed

..___tag_value_this_func_.12:

    call   value_func_                  #33.12

..___tag_value_this_func_.13:

2023.1.0:

..B1.5:             # Preds ..B1.4

                # Execution count [1.00e+00]

    movl   (%rsp), %eax                 #33.12

    lea    8(%rsp), %rdi                 #33.12 // Address of a temporary copy of "0" is passed

    movl   %eax, (%rdi)                 #33.12

..___tag_value_this_func_.12:

    call   value_func_                  #33.12

..___tag_value_this_func_.13:

I will forward it to developers for further investigation and let you know when there is an update.

[Xiaoping_D_Intel]

It has been fixed and the fix will be available in a future release.