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).

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.

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

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?!

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!

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" :).