../module.c:341:53: error: passing argument 1 of ‘PyArray_TYPE’ from incompatible pointer type [-Wincompatible-pointer-types]  341 |         else if (PyArray_Check(obj) && PyArray_TYPE(obj) == NPY_LONGDOUBLE) {      |                                                     ^~~      |                                                     |      |                                                     PyObject * {aka struct _object *}In file included from /usr/lib64/python3.13/site-packages/numpy/_core/include/numpy/ndarrayobject.h:12,                 from /usr/lib64/python3.13/site-packages/numpy/_core/include/numpy/arrayobject.h:5,                 from /usr/lib64/python3.13/site-packages/numpy/f2py/src/fortranobject.h:16,                 from ../flibmodule.c:23:/usr/lib64/python3.13/site-packages/numpy/_core/include/numpy/ndarraytypes.h:1567:35: note: expected ‘const PyArrayObject *’ {aka ‘const struct tagPyArrayObject *’} but argument is of type ‘PyObject *’ {aka ‘struct _object *’} 1567 | PyArray_TYPE(const PyArrayObject *arr)      |              ~~~~~~~~~~~~~~~~~~~~~^~~../module.c:342:53: error: passing argument 1 of ‘PyArray_DATA’ from incompatible pointer type [-Wincompatible-pointer-types]  342 |             (*v) = *((npy_longdouble *)PyArray_DATA(obj));      |                                                     ^~~      |                                                     |      |                                                     PyObject * {aka struct _object *}/usr/lib64/python3.13/site-packages/numpy/_core/include/numpy/ndarraytypes.h:1512:35: note: expected ‘const PyArrayObject *’ {aka ‘const struct tagPyArrayObject *’} but argument is of type ‘PyObject *’ {aka ‘struct _object *’} 1512 | PyArray_DATA(const PyArrayObject *arr)      |              ~~~~~~~~~~~~~~~~~~~~~^~~

Following some of the other uses of this API in the cfuncs file, this just uses an explicit pointer cast, as we've already validated it upon use.

BUG: Avoid compile errors in f2py modules

54529e2

Some of the casts from cfuncs pass PyObject* to PyArrayObject*, whichcauses compile errors due to incompatible pointer types on at leastGCC 14.

github-actionsbot added the 00 - Bug label

May 22, 2025

seberg approved these changes

May 22, 2025

View reviewed changes

Copy link

Member

seberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

LGTM, could you look into adding a test, though? Since looks a bit like we are not hitting this code in our test suite at all.
Which I guess is not too weird considering that it is longdouble (and there are even thoughts to move support for it out of NumPy proper).

seberg added the 09 - Backport-CandidatePRs tagged should be backported label

May 22, 2025

melissawm added this toNumPy first-time contributor PRs

May 22, 2025

melissawm moved this toPending authors' response inNumPy first-time contributor PRs

May 22, 2025

Copy link

ContributorAuthor

angus-g commentedMay 23, 2025

could you look into adding a test, though?

Done, I've just done this by extending the assumption that real/complex kinds map to bit widths (I'm only familiar with GNU and Intel compilers where this does indeed hold).

Copy link

Member

seberg commentedMay 23, 2025

Let's see, sorry, yeah this is longdouble, which means it's a platform dependent mess. So there is a good chance CI will barf at this and we can't integrate this into a test for all platforms.

Copy link

ContributorAuthor

angus-g commentedMay 23, 2025

😁 Well that'll be fun to see. Surely tests can be targeted to supported platforms, at least?

Copy link

Member

seberg commentedMay 23, 2025

I am not sure it worries me less that the tests seem to pass... they seem to pass on windows, but windows has no real longdouble support in NumPy. So how comecomplex(kind=16) even compiles? And if it exists in the fortran side, then surely any interoperability with NumPy is probably broken?

Maybe@HaoZeke has a quick thought, but not sure it's wise to do this test. I wonder what happens if you do some trivial set of math and check the result (but not sure the tests can be changed to do that easily).

Unless it compiles, but we skip the actual tests forkind=16 on these platforms... which maybe?!

Copy link

ContributorAuthor

angus-g commentedMay 23, 2025

Thereturn_* tests are marked "slow". I am a bit overwhelmed by all the test configurations, so it's tricky to figure out what goes where!

I also realised that I didn't add the actual function checks totest_return_real.py andtest_return_complex.py. Doing so leads to segfaults in the real code (but not complex)... It doesn't seem like anything interacts very nicely with long doubles without a bit of work!

angus-g force-pushed thef2py-incompat-pointer branch from3be3895 toc99292cCompare

May 23, 2025 12:17

Copy link

Member

seberg commentedMay 23, 2025

Yeah, basically, I am happy to put this in as it is a clear fix (if it works for you!); maybe without the tests if they are just dubious anyway...
Butlong double is already a sticky point (to the point that support may leave numpy eventually), and mixing that with fortran seems like a "your problem not ours" :).