BUG: f2py ignores value attribute

[jhaiduce]

Describe the issue:

f2py generates incorrect wrapper code when run on a Fortran procedure that uses the value attribute on any input variables. A compiler that complies with the Fortran 2003 standard treats such variables as pass-by-value. f2py wrappers for such functions produce incorrect behavior, presumably because f2py ignores the value attribute and the generated wrapper passes the variable's address instead of its value.

Here's some example Fortran code that illustrates this:

module fortfuncs

  implicit none

contains

  subroutine square(x,y)

    integer, intent(in), value :: x

    integer, intent(out) :: y

    y = x*x

  end subroutine square

end module fortfuncs

The above code compiles to a wrapper module as expected with the command f2py -m fortfuncs -c fortfuncs.f90, but the resulting wrapper code produces garbage output. For example the following

from fortfuncs import fortfuncs

y=fortfuncs.square(2)
assert y==4

raises an AssertionError.

As a workaround, one can avoid using the value attribute, but it would be simpler for users if f2py supported the value attribute (or at least threw an error indicating that the value attribute is not supported).

Reproduce the code example:

See above; the code to reproduce is in Fortran rather than Python.

Error message:

No response

NumPy/Python version information:

1.22.4 3.9.13 (main, May 24 2022, 21:28:12)
[Clang 12.0.0 (clang-1200.0.32.29)]

Fortran compiler version:
GNU Fortran (Homebrew GCC 11.3.0_1) 11.3.0

[HaoZeke]

Thanks @jhaiduce! We do currently have an understanding of the attribute:

                             'vars': {'x': {'attrspec': ['value'],
                                                                          'intent': ['in'],
                                                                          'typespec': 'integer'},
                                                                    'y': {'attrspec': [],
                                                                          'intent': ['out'],
                                                                          'typespec': 'integer'}}}],
                                                 'entry': {},

So a minimal fix is just to issue a warning, but this should be fixed in a more holistic manner (by adding special casing support for the attribute), since the current behavior is not standards compliant.