io_nemo fails with gfortran-10 (on mac)

[teuben]

gfortran-10 is a more strict compiler, it does not like the varargs style it internally finds that is being used. This might be something for @jcldc possibly an extra flag to the compiler

[teuben]

A more detailed look seems to show that gfortran-10 on linux works fine, but it's the one on the Mac that is broken. And to be clear, this is homebrew version 10.2.0
The working version on linux is Ubuntu 10.2.0-5ubuntu1~20.04
@jcldc might be partially happy.

[jcldc]

Indeed I am VERY happy !
Thanks Peter

[teuben]

Not sure if you saw my first, or edited message, as i had to admit the problem is on mac only

[teuben]

The compiler error on gcc-11 is:
Error: Type mismatch between actual argument at (1) and actual argument at (2) (REAL(8)/CHARACTER(*)).
but by adding a -fallow-argument-mismatch flag, this passes the compiler now.
There is still a runtime error in the testsuite.

[jcldc]

Hi,
on which file do you get this error ?

[jcldc]

The compiler error on gcc-11 is: Error: Type mismatch between actual argument at (1) and actual argument at (2) (REAL(8)/CHARACTER(*)). but by adding a -fallow-argument-mismatch flag, this passes the compiler now. There is still a runtime error in the testsuite.

on almalinux (redhat8 like) and gcc 11 activated, IO_NEMO test-suite pass (with -fallow-argument-mismatch enable)

[teuben]

I've added this flag to the Makefile in io_nemo. I don't have runtime error on ubuntu20, but I'm looking into U21.10 where there is still a runtime error.

[teuben]

My error was that from a previous test a 0 length plummer was there, then the rest fails. I would like to argue the testsuite scripts should write their files in a clean directory, so no side-effects like this could occur. By default the testsuite tree is removed.
Other than this, the testsuite compiles and work again!

[teuben]

I have a proposed solution (not committed yet), where RT= is set via commandline arg to the scripts. We could also make this the default. The other problem with /tmp/ is that the name would be shared by another user and thus the test would fail

[teuben]

committed

[teuben]

not sure if it's really fully solved, I still see a lot of "FAIL" on io-nemo, but intermittendly.

[jcldc]

The bug still persists. It affects only fortran code using io_nemo on ARM mac computer.
It's a nasty bug, looks like it's a regression from the compiler.
I have created a simple test case to reproduce the bug.
The issue occurs when fortran call a c function with variable arguments.
Variable arguments are not decoded correctly, and they corrupt the memory.
See in attachment a tar file to reproduce the bug :

# compile
tar zxvf va_arg.tar.gz
cd va_arg
make

# run test from an intel x86 machine (linux or macos)
./test_va_arg 
>>>>>>>> s1 [666]
>>>>>>>> myval [hello world]

# run from an ARM mac
 ./test_va_arg 
>>>>>>>> s1 [666]
>>>>>>>> myval [`7>m]

We can see that variable myval is corrupted. It should contain "hello world"

va_arg.tar.gz

[teuben]

can you try it with the -fallow-argument-mismatch compile flag. Perhaps also -std=legacy

[jcldc]

nope, same issue.
What I can see :
va_arg object works from C to C language, but does not work when fortran call a C routine with variable argument.
Looks like really a compiler bug.
BTW, I have tested using gcc-14 and gfortran-14 (from mac M4)

[jcldc]

And my test program works from an intel mac and gcc-11

[teuben]

@cnjmike did you not also have a peek at this problem?

[jcldc]

Well, I filled a bug report on gcc, here it is, with a lot of discussion :

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118831

To summarize, there is no solution for aarch64 (arm) architecture, except not to use variadic C language function.
They even told me that it should not work on x86_64 architecture either, which is crazy bc tons of Fortran programs have been developed using io_nemo_f. And through the nemo TestFile process, I have pure C programs which compare the results with io_nemo Fortran version with always no errors.

[teuben]

frustrating to see it labeled "RESOLVED INVALID" now

[jcldc]

Yes it's really incomprehensible, I am really desperate and frustrated...

[teuben]

as with many a bug I've eventually resolved, best is to walk away for a while, work on other things. Often a solution then drops out of thin air.