- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I'm running into what I thought was a bug with ifort XE, but it seems that all compilers behave in the same way, so I'm just posting for general advice. In the following example, the value of opt inside the subroutine is 0 when I was expecting 1. What must be happening is that the first argument of the subroutine is reset to default values as soon as it is passed because of the intent(out). Is that correct? I guess that this is because the values are being passed by reference, not by value, so a%opt changes straight away before it is used? However, there is no way to use the 'value' keyword with the 'optional' keyword, so is the only way around this to create a new variable to contain a%opt before the subroutine call and then to call it with that?
Thanks for any advice,[fortran]program test type test_type integer :: opt = 0 end type test_type type(test_type) :: a a%opt = 1 call sub(a, opt=a%opt) contains subroutine sub(b, opt) implicit none type(test_type),intent(out) :: b integer,optional,intent(in) :: opt print *, present(opt) if(present(opt)) then print *,opt end if end subroutine sub end program test [/fortran]
Thomas
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1. This program is not standard conforming. (If you pass the same or overlapping actual arguments to two different dummy arguments, you are prohibited from changing either.) However, compilers are not required to diagnose this error.
2. Your analysis of how ifort is handling your erroneous program appears to be essentially correct.
3. You can make your program correct and get the behavior you want by making the actual argument for opt an expression rather directly using the component. E.g.,
callsub(a,opt=(a%opt))
or
callsub(a,opt=a%opt+0)
In either case, the compiler will evaluate the expression into a temporary location and pass that location rather than the component, so its resetting of the b (and thus a) will not affect the value of opt.
-Kurt
2. Your analysis of how ifort is handling your erroneous program appears to be essentially correct.
3. You can make your program correct and get the behavior you want by making the actual argument for opt an expression rather directly using the component. E.g.,
callsub(a,opt=(a%opt))
or
callsub(a,opt=a%opt+0)
In either case, the compiler will evaluate the expression into a temporary location and pass that location rather than the component, so its resetting of the b (and thus a) will not affect the value of opt.
-Kurt

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page