Changes relating to the value attribute

[Simon_Geard]

We're currently checking our code prior to upgrading from 12.1.0.233 to 14.0.1.139. Apart from syntax changes for subroutines with no arguments and bind(c) evrything seems to be okay. For example

[fortran]

subroutine mysub bind(c)

[/fortran]

no longer compiles, instead we have

[fortran]

subroutine mysub() bind(c)

[/fortran]

Yesterday we found that some functions that are C and used in the Fortran code through asssociated function pointers now need the bind(c) attribute. However it isn't true of all such functions. For example with the interface below

[fortran]

    abstract interface
    subroutine updateloadsetvector(loadcaseid,berror,igid,dval)
    use iso_c_binding
    integer(c_int),value,intent(in) :: loadcaseid,igid
    logical*4,intent(out):: berror
    real(c_double),value,intent(in) :: dval
    end subroutine  updateloadsetvector
    end interface
[/fortran]

the arguments are not passed by value, whereas if bind(c) is added then the arguments are passed by value. But this isn't true of all such functions; with the interface below

[fortran]

    abstract interface
    subroutine getdefaultgroup(key,igrflag,zcurgrp)
    use iso_c_binding
    integer(c_int), value, intent(in) :: key
    integer(c_int),intent(out):: igrflag(*)
    character*(*), intent(out):: zcurgrp
    end subroutine getdefaultgroup
    end interface
[/fortran]

the bind(c) attribute is not needed in order to get pass-by-value. It is almost as if the value attribute is being ignored when there are no arrays or character strings in the argument list. I have tried at /assume:std_value but that has not effect in this case.

So although I've fixed the problem by adding a sprinkling of bind(c)s I'd like to understand the change - or report the new behaviour as a bug.

Thanks,

Simon

[IanH]

[fortran]subroutine mysub bind(c)[/fortran]

In fixed form source that looks like a normal (non-bind) function statement, hence the parentheses are syntactically required.

The change in VALUE for non-bind(c) procedures has been discussed here recently.  It was intentional.

[Simon_Geard]

According to that thread the (erroneous) behaviour of value is unchanged unless the /assume:std_value argument is given, in which case the correct behaviour is invoked. What it doesn't explain what change was made between v12 and v14 of the compiler. I'm sure the effect is due to the indirection caused by associating functions through function pointers since we use the value attribute in many places without problems and it may well be that the new behaviour is correct, I'd just like to understand what change was made and why so that I can explain it to my boss when he asks!

[Steven_L_Intel1]

If you didn't use BIND(C), then nothing should have changed. As explained in the other thread, we intended to make a change to conform to the standard in 14, but made it optional. However, it seems we missed at least one case where the VALUE attribute is inconsistently applied.

Can you show a small but complete example that shows the problem? If you were relying on the incorrect behavior, where without BIND(C) VALUE causes pass-by-value, then /standard-semantics would just make it worse.