Skip to content

BUG: crackfortran.py fails with 'common' blocks with Numpy version > 1.20 #22648

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? Sign in to your account

Jump to bottom
Closed
jarau-de opened this issue Nov 22, 2022 · 8 comments · Fixed by #22657
Closed

BUG: crackfortran.py fails with 'common' blocks with Numpy version > 1.20 #22648

jarau-de opened this issue Nov 22, 2022 · 8 comments · Fixed by #22657
Labels
00 - Bug component: numpy.f2py
Milestone
1.26.0 release

Comments

@jarau-de
Copy link

Describe the issue:

It seems Fortran 77 'COMMON' blocks are not matched correctly. I got the following error message:

crackline: groupcounter=1 groupname={0: '', 1: 'python module', 2: 'interface', 3: 'block data', 4: 'subroutine'}
crackline: Mismatch of blocks encountered. Trying to fix it by assuming "end" statement.

Following code causes the error:

python module iri16py ! in
interface ! in :iri16py
block data ! in :iri16py:iridreg_modified.for
COMMON /fircom/ eden,tabhe,tabla,tabmo,tabza,tabfl
end block data
end interface
end python module iri16py

Unfortunately all interface signature code after the common block will be ignored. With Numpy <= 1.20 it runs smooth. All versions above causes this error. If I document out the 'common' line all behaves fine. Please fix that soon. I tried to find out the reason in crackfortran.py, but it seems a bit too complex for me.
f2py seems also to be fine if one removes the space between end block data -> end blockdata.

Reproduce the code example:

f2py following code:
python module iri16py ! in 
    interface  ! in :iri16py
        block data  ! in :iri16py:iridreg_modified.for
           COMMON /fircom/ eden,tabhe,tabla,tabmo,tabza,tabfl
       end block data 
    end interface 
end python module iri16py

Error message:

crackline: groupcounter=1 groupname={0: '', 1: 'python module', 2: 'interface', 3: 'block data', 4: 'subroutine'}
crackline: Mismatch of blocks encountered. Trying to fix it by assuming "end" statement.

NumPy/Python version information:

1.21 and above

Context for the issue:

I use a Python module which make use of old Fortran 77 code. Since f2py ignore all signature code after the COMMON block, the Python module routine gets not compiled in and the load of module fails. Without a fix to this issue I am forced to stay at Numpy 1.20 but I would like to update.
@charris
Copy link
Member

charris commented Nov 22, 2022

@pearu @HaoZeke Thoughts?

@HaoZeke
Copy link
Member

HaoZeke commented Nov 23, 2022 •
edited
Loading

I can't seem to reproduce this as an error. The crackline warning is new, but that doesn't change anything. The generated files (f2pywrappers.f, module.c) aren't different w.r.t. to the common block handling either.

f2py -v
1.24.0.dev0+943.g0075d59ce
f2py -c bug.pyf -m iri16py
python -c "import iri16py; print(iri16py.fircom.eden)"
0.0

This has the same result in NumPy 1.20

f2py -v
2
f2py -c bug.pyf -m iri16py
python -c "import iri16py; print(iri16py.fircom.eden)"
0.0

@jarau-de could you mention the exact f2py invocation and post the full error log? The warning shouldn't be fatal.

EDIT: I think I see the issue, sorry, thanks for catching this!

The problem is that the groupcounter variable has been increased. It is hard to track because its global. In any case, this means that:

        if f77modulename and neededmodule == groupcounter:
            fl = 2
        while groupcounter > fl:
            outmess('crackline: groupcounter=%s groupname=%s\n' %
                    (repr(groupcounter), repr(groupname)))
            outmess(
                'crackline: Mismatch of blocks encountered. Trying to fix it by assuming "end" statement.\n')
            grouplist[groupcounter - 1].append(groupcache[groupcounter])
            grouplist[groupcounter - 1][-1]['body'] = grouplist[groupcounter]
            del grouplist[groupcounter]
            groupcounter = groupcounter - 1
        if f77modulename and neededmodule == groupcounter:
            grouplist[groupcounter - 1].append(groupcache[groupcounter])
            grouplist[groupcounter - 1][-1]['body'] = grouplist[groupcounter]
            del grouplist[groupcounter]
            groupcounter = groupcounter - 1  # end interface
            grouplist[groupcounter - 1].append(groupcache[groupcounter])
            grouplist[groupcounter - 1][-1]['body'] = grouplist[groupcounter]
            del grouplist[groupcounter]
            groupcounter = groupcounter - 1  # end module
            neededmodule = -1
        return

Takes the first (while) path when it used to use the second.

NumPy 1.20 --> groupcounter = 2, neededmodule = 2
NumPy Main --> groupcounter = 3, neededmodule = 2

@HaoZeke HaoZeke mentioned this issue Nov 23, 2022
Merged
@HDembinski HDembinski mentioned this issue Jan 15, 2023
Closed
@HDembinski
Copy link

HDembinski commented Jan 15, 2023 •
edited
Loading

Thanks for looking into this. We suffer from the same issue.

Is there a hotfix available that we could try out locally?

@HDembinski
Copy link

I found a temporary hotfix.

Install the latest version of numpy. Replace the folder f2py in your installed numpy package with the folder f2py from numpy-1.19.5. I tested this for numpy-1.24.1

@HDembinski
Copy link

HDembinski commented Jan 15, 2023 •
edited
Loading

@HaoZeke Would it be possible to increasing the priority of this issue? This is a critical bug that makes f2py unusable in recent numpy releases.

@HaoZeke
Copy link
Member

HaoZeke commented Jan 29, 2023 •
edited
Loading

@HDembinski, @jarau-de, sorry for the wait, the fix on #22657 now works.

The actual issue can be traced to e6dab4f where the parser was updated to include the Fortran 2008 block construct, which is used in several other places in the file and caused the issue.

HaoZeke added a commit to HaoZeke/numpy that referenced this issue Jan 29, 2023
@HaoZeke
TST: Add a test for numpygh-22648
b5fe07e
@HDembinski
Copy link

Thank you very much! Should I test-run this PR on my setup or do you think it is not necessary?

@mattip
Copy link
Member

mattip commented Jan 30, 2023

@HDembinski if it would be possible to test the PR that would help give confidence that the fix is correct.

@seberg seberg added this to the 1.24.2 release milestone Feb 1, 2023
@charris charris modified the milestones: 1.24.2 release, 1.24.3 release Feb 3, 2023
HaoZeke added a commit to HaoZeke/numpy that referenced this issue Feb 11, 2023
@HaoZeke
TST: Add a test for numpygh-22648
cec3cf0
HaoZeke added a commit to HaoZeke/numpy that referenced this issue Feb 11, 2023
@HaoZeke
TST: Add a test for numpygh-22648
f1b69ae
HaoZeke added a commit to HaoZeke/numpy that referenced this issue May 17, 2023
@HaoZeke
TST: Add a test for numpygh-22648
6398add
HaoZeke added a commit to HaoZeke/numpy that referenced this issue Jun 4, 2023
@HaoZeke
TST: Add a test for numpygh-22648
d6bdb08
@charris charris modified the milestones: 1.25.1 release, 1.25.2 release Jul 6, 2023
charris pushed a commit to charris/numpy that referenced this issue Aug 24, 2023
@HaoZeke @charris
TST: Add a test for numpygh-22648
215cbe0
@charris charris mentioned this issue Aug 24, 2023
Merged
charris pushed a commit to charris/numpy that referenced this issue Nov 11, 2023
@HaoZeke @charris
TST: Add a test for numpygh-22648
d298c9d
@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
No one assigned
Labels
00 - Bug component: numpy.f2py
Projects
None yet
Milestone
1.26.0 release
Development

Successfully merging a pull request may close this issue.

BUG: Fix common block handling in f2py HaoZeke/numpy
6 participants
@seberg @charris @mattip @HDembinski @HaoZeke @jarau-de