8000 f2py - f2cmap fails on common blocks in f90 · Issue #19161 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

f2py - f2cmap fails on common blocks in f90 #19161

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub 8000 ? Sign in to your account

Jump to bottom
Closed
2sn opened this issue Jun 3, 2021 · 3 comments · Fixed by #25186
Closed

f2py - f2cmap fails on common blocks in f90 #19161

2sn opened this issue Jun 3, 2021 · 3 comments · Fixed by #25186
Assignees
@HaoZeke
Labels
57 - Close? Issues which may be closable unless discussion continued component: numpy.f2py

Comments

@2sn
Copy link
Contributor
2sn commented Jun 3, 2021

Reproducing code example:

The code (data.f90)

module data
  use typedef, only: real64
  implicit none
  real(kind=real64) :: x
  common/test/x
end module data

fails compile with f2py, whereas without the common block,

module data
  use typedef, only: real64
  implicit none
  real(kind=real64) :: x
  save
end module data

it just compiles fine. (Sadly, I require common blocks since I cannot import data from external modules.)
I use a custom .f2py_f2cmap file

{
   'real': {'real32': 'float', 'real64': 'double', 'real128': 'long_double'},
   'integer': {'int8': 'signed_char', 'int16': 'short', 'int32': 'int', 'int64': 'long', 'int128': 'long_long'},
   'complex': {'comp32': 'complex_float', 'comp64': 'complex_double', 'comp128': 'complex_long_double'},
   'character': {'char8' : 'char'},
}

and I do get affirmative output

Reading f2cmap from '/home/alex/python/source/kepler/.f2py_f2cmap' ...
        Mapping "real(kind=real32)" to "float"
        Mapping "real(kind=real64)" to "double"
        Mapping "real(kind=real128)" to "long_double"
        Mapping "integer(kind=int8)" to "signed_char"
        Mapping "integer(kind=int16)" to "short"
        Mapping "integer(kind=int32)" to "int"
        Mapping "integer(kind=int64)" to "long"
        Mapping "integer(kind=int128)" to "long_long"
        Mapping "complex(kind=comp32)" to "complex_float"
        Mapping "complex(kind=comp64)" to "complex_double"
        Mapping "complex(kind=comp128)" to "complex_long_double"
        Mapping "character(kind=char8)" to "char"
Successfully applied user defined f2cmap changes

It applease some F77 module file is created, but my use statement may be ignored.

when I directly add the line

INTEGER, PARAMETER :: real64 = SELECTED_REAL_KIND(15)

instead of

  use typedef, only: real64

It appears to work.

Would it be possible to have f2py not create F77 interface module for .f90 codes even if they use common blocks?

(that might resolve it)

Error message:

/tmp/tmpnlatc0rg/src.linux-x86_64-3.9/_kepler_ARCH_native_NBURN_8192_JMZ_1983_FULDEF_fuldef1_f90_CPU_Intel_R_Xeon_R_W_2145_CPU_3_70GHz-f2pywrappers.f:7:16:

    7 |       real(kind=real64) x
      |                1
Error: Parameter ‘real64’ at (1) has not been declared or is a variable, which does not reduce to a constant expression
error: Command "/usr/bin/gfortran -fPIC -O3 -funroll-loops -fno-second-underscore -fconvert=big-endian -cpp -Djmzmacro=1983 -cpp -Djmzmacro=1983 -Dnburnmacro=8192 -I/home/alex/kepler/source -I/home/alex/python/source/kepler/code/_kepler_ARCH_native_NBURN_8192_JMZ_1983_FULDEF_fuldef1_f90_CPU_Intel_R_Xeon_R_W_2145_CPU_3_70GHz -fPIC -O3 -funroll-loops -Djmzmacro=1983 -Djmzmacro=1983 -Dnburnmacro=8192 -I/tmp/tmpnlatc0rg/src.linux-x86_64-3.9 -I/home/alex/Python/lib/python3.9/site-packages/numpy/core/include -I/home/alex/Python/include/python3.9 -c -c /tmp/tmpnlatc0rg/src.linux-x86_64-3.9/_kepler_ARCH_native_NBURN_8192_JMZ_1983_FULDEF_fuldef1_f90_CPU_Intel_R_Xeon_R_W_2145_CPU_3_70GHz-f2pywrappers.f -o /tmp/tmpnlatc0rg/tmp/tmpnlatc0rg/src.linux-x86_64-3.9/_kepler_ARCH_native_NBURN_8192_JMZ_1983_FULDEF_fuldef1_f90_CPU_Intel_R_Xeon_R_W_2145_CPU_3_70GHz-f2pywrappers.o -J/tmp/tmpnlatc0rg/ -I/tmp/tmpnlatc0rg/" failed with exit status 1

NumPy/Python version information:

1.20.3 3.9.5 (default, May  7 2021, 05:52:00) 
[GCC 11.1.1 20210428 (Red Hat 11.1.1-1)]
@melissawm
Copy link
Member

Thanks for the report, @2sn - we'll try to look into it as soon as possible.

@HaoZeke
Copy link
Member
HaoZeke commented Apr 29, 2022

I can't seem to reproduce this... @2sn could you confirm if this is still an issue?

module data
  implicit none
  INTEGER, PARAMETER :: real64 = SELECTED_REAL_KIND(15)
  real(kind=real64) :: x
  common/test/x
end module data

Seems to compile alright:

> python -c "import numpy as np; print(np.__version__)"
1.23.0.dev0+1087.g0eaa40db3
> python -m numpy.f2py data.f90 -c -m dat
> python -c "import dat; print(dat.test.x)"
0.0

@HaoZeke HaoZeke added the 57 - Close? Issues which may be closable unless discussion continued label Apr 29, 2022
@HaoZeke HaoZeke self-assigned this Apr 29, 2022
@2sn
Copy link
Contributor Author
2sn commented Apr 29, 2022

I believe I have since been able to work around the issue, but I do not recall what solved the issue.

But maybe you also misread my message: I said that the version you have was working but the issue was the version at the top of the message that had the line

use typedef, only: real64

instead of

INTEGER, PARAMETER :: real64 = SELECTED_REAL_KIND(15)

Could you please try that?

HaoZeke added a commit to HaoZeke/numpy that referenced this issue Nov 19, 2023
@HaoZeke
BUG: Add use-block handling for common blocks
3e442fc 
Closes numpygh-19161
@HaoZeke HaoZeke mentioned this issue Nov 19, 2023
Merged
1 task
HaoZeke added a commit to HaoZeke/numpy that referenced this issue Nov 19, 2023
@HaoZeke
TST: Add a test for numpygh-19161 [f2py]
0faebe9
HaoZeke added a commit to HaoZeke/numpy that referenced this issue Nov 19, 2023
@HaoZeke
TST: Add a test for numpygh-19161 [f2py]
ce940a0
mattip added a commit that referenced this issue Nov 19, 2023
@mattip
Merge pull request #25186 from HaoZeke/gh-19161
907ccc3 
BUG: Handle `common` blocks with `kind` specifications from modules
charris pushed a commit to charris/numpy that referenced this issue Nov 21, 2023
@HaoZeke @charris
BUG: Add use-block handling for common blocks
abdcb43 
Closes numpygh-19161
charris pushed a commit to charris/numpy that referenced this issue Nov 21, 2023
@HaoZeke @charris
TST: Add a test for numpygh-19161 [f2py]
33fcf1d
@charris charris mentioned this issue Nov 21, 2023
Merged
3 tasks
@andrea-bia andrea-bia mentioned this issue Dec 7, 2023
Closed
@ftherrien ftherrien mentioned this issue Mar 28, 2024
Closed
@akrherz akrherz mentioned this issue Sep 5, 2024
Open
@akrherz akrherz mentioned this issue Sep 17, 2024
Merged
@TimotheusBachinger TimotheusBachinger mentioned this issue Nov 25, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@HaoZeke HaoZeke

Labels
57 - Close? Issues which may be closable unless discussion continued component: numpy.f2py
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

BUG: Handle common blocks with kind specifications from modules HaoZeke/numpy
3 participants
@2sn @melissawm @HaoZeke
0