Add test case for issue #306: module-level allocatable arrays

[jameskermode]

This test case demonstrates the reported issue where module-level allocatable arrays may fail after reallocation.

Investigation findings:

• Tests pass on this system (sizeof_fortran_t = 4)
• The generated wrapper uses dummy_this(4) but this parameter is unused for module-level arrays (only for derived types)
• Issue may be platform-specific when sizeof_fortran_t differs between wrapper generation time and runtime

Test files:

• alloc_mod.f90: Fortran module with allocatable array
• tests.py: Tests for allocation and reallocation
• Makefile/Makefile.meson: Build files

Related to #306

[jameskermode]

This was with GCC 13.3.0, not GCC 15. Continuing to investigate.

[jameskermode]

Analysis from Claude which looks plausible but which I haven't carefully checked:

Root Cause Identified

I've identified the root cause of this issue. It's a mismatch between the sizeof_fortran_t value used at wrapper generation time vs runtime.

The Problem

1. When f90wrap generates Fortran wrappers, it hardcodes dummy_this(N) where N is sizeof_fortran_t computed on the generation system
2. At runtime, f90wrap computes sizeof_fortran_t again and creates empty_handle = [0]*sizeof_fortran_t
3. If these values differ, f2py throws: "0-th dimension must be fixed to X but got Y"

Your Environment

Your error "0-th dimension must be fixed to 2 but got 4" indicates:

• Your GCC 15.2.1 produces sizeof_fortran_t = 2
• The wrappers were generated on a system with sizeof_fortran_t = 4

I can reproduce the exact error by simulating this mismatch:

>>> import _alloc_mod
>>> _alloc_mod.f90wrap_alloc_mod__array__data_array([0, 0])  # size 2 handle
ValueError: 0-th dimension must be fixed to 4 but got 2

Why GCC 15?

sizeof_fortran_t is computed by measuring the size of a Fortran derived type pointer using transfer(). GCC 15 may have changed the internal representation of type/class pointers, reducing their size from 4 integers to 2.

Questions

1. Could you confirm sizeof_fortran_t on your system?

from f90wrap.sizeof_fortran_t import sizeof_fortran_t
print(sizeof_fortran_t())

2. Are you installing f90wrap from PyPI wheels (pre-built) or building from source?

• If from wheels: they may have been built with GCC 13/14 where sizeof_fortran_t = 4
• If from source: you need to regenerate the wrappers after installing

Potential Fix

For module-level arrays, dummy_this is actually unused (the compiler even warns about it). We could:

1. Remove dummy_this from module-level array accessors entirely
2. Or make the size dynamic/flexible
   I'll work on a fix once we confirm the diagnosis.

[krystophny]

@jameskermode I try to build on this now...

[smiet]

I have a similar issue, answering the questions here:

The test passes on my system, but my wrapped code gives similar errors to those of @krystophny.
(The error is opposite to described above; at runtime sizeof_fortran_t is 4, but during wrapper generation it is 2: 0-th dimension must be fixed to 2 but got 4).

code: SPECTRE (revised edition of SPEC, not public yet)

• gcc 13.2.0
• python 3.10.14
• numpy 2.x (also numpy 1.26.x gave error)
• f90wrap: 0.2.16 (master) & 0.3.0

1. Could you confirm sizeof_fortran_t on your system?

 >>>from f90wrap.sizeof_fortran_t import sizeof_fortran_t
 >>>print(sizeof_fortran_t())
4

2. Are you installing f90wrap from PyPI wheels (pre-built) or building from source?
   from source.

Both SPECTRE and SIMPLE use scikit-build-core with CMake as a build backend.

It might be related with the wrapper generation through CMake, since that is also the backend of SIMPLE (see file). Here the wrapper generation command is:

add_custom_command(OUTPUT ${F90WRAP_OUTPUT}
	COMMAND ${Python_EXECUTABLE}
        -m f90wrap
        --f90wrap
        -m simple_backend
        -k ${CMAKE_CURRENT_SOURCE_DIR}/f2py_f2cmap
        ${CMAKE_CURRENT_BINARY_DIR}/*.f90.i
        > ${CMAKE_CURRENT_BINARY_DIR}/f90wrap.log 2>&1
	DEPENDS ${PREPROCESSED_SOURCES}
    COMMENT "Processing preprocessed sources with f90wrap"
)

(and very similar for SPECTRE). Could the issue somehow be related to this?

[krystophny]

@smiet in #328 we are now on itpplasma:fix/add-missing-makefile-meson branch that stacks on all the previous bugfix branches. Can you check if this works for you? SPECTRE is still a private code, right?

[smiet]

@krystophny Thanks, missed that! Yes SPECTRE is still private, and will be until it is in a presentable state...

The branch itpplasma:fix/add-missing-makefile-meson is giving me the same error.

[krystophny]

@krystophny Thanks, missed that! Yes SPECTRE is still private, and will be until it is in a presentable state...

The branch itpplasma:fix/add-missing-makefile-meson is giving me the same error.

@smiet no problem, let me know if you want to invite me to the project just for fixing f90wrap, or if we should rather go ahead and patch it later when your code is ready to be released.

[jameskermode]

Closed in favour of #321