- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It has been fixed and the fix will be available in a future release.
![](/skins/images/7FC17B7B85029576C25F1E43CE255B51/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page