search

NOAA-GFDL / FMS

GFDL's Flexible Modeling System
Other
87 stars 128 forks source link

FMS does not appear to compile with GFortran 14.1 #1527

Open marshallward opened 1 month ago

marshallward commented 1 month ago

Describe the bug The GFortran 14.1 parser is choking on a particular line in FMS2_IO:

The line is

        err = nf90_put_att(fileobj%ncid, varid, trim(attribute_name), &
                           trim(attribute_value(1:str_len)))

The error (and corresponding build command) is:

mpifort -DPACKAGE_NAME=\"FMS\" -DPACKAGE_TARNAME=\"fms\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"FMS\" -DPACKAGE_BUGREPORT=\"https://github.com/NOAA-GFDL/FMS/issues\" -DPACKAGE_URL=\"\" -DHAVE_MPI=1 -DHAVE_GETTID=1 -DHAVE_SCHED_GETAFFINITY=1 -DHAVE_MPI=1 -Duse_libMPI=1 -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DHAVE_NETCDF_H=1 -Duse_netCDF=1 -g -O0 -fcray-pointer -fdefault-real-8 -fdefault-double-8 -fallow-invalid-boz -fallow-argument-mismatch  -c ../src/fms2_io/netcdf_io.F90 -I../src/fms2_io/include
register_variable_attribute.inc:56:60:

internal compiler error: in gfc_walk_array_ref, at fortran/trans-array.cc:11870
0x1ffd19a internal_error(char const*, ...)
    ???:0
0x6f365f fancy_abort(char const*, int, char const*)
    ???:0
0x844964 gfc_walk_expr(gfc_expr*)
    ???:0
0x884767 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec<tree_node*, va_gc, vl_embed>*)
    ???:0
0x8833b3 gfc_conv_expr_reference(gfc_se*, gfc_expr*)
    ???:0
0x886ed3 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec<tree_node*, va_gc, vl_embed>*)
    ???:0
0x8d252c gfc_trans_block_construct(gfc_code*)
    ???:0
0x8c7980 gfc_trans_select_type(gfc_code*)
    ???:0
0x8d252c gfc_trans_block_construct(gfc_code*)
    ???:0
0x8c0caa gfc_trans_if(gfc_code*)
    ???:0
0x87dcd7 gfc_generate_function_code(gfc_namespace*)
    ???:0
0x839c89 gfc_generate_module_code(gfc_namespace*)
    ???:0
0x7f1c4f gfc_parse_file()
    ???:0
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues> for instructions.
make[2]: *** [Makefile.dep:235: netcdf_io.o] Error 1
make[2]: Leaving directory '/home/marshall/gfdl/mom6/.testing/deps/fms/build'
make[1]: *** [Makefile:45: fms/build/libFMS.a] Error 2
make[1]: Leaving directory '/home/marshall/gfdl/mom6/.testing/deps'
make: *** [Makefile:342: deps/lib/libFMS.a] Error 2

It does not like these attribute_value(1:str_len)) terms. If I get rid of the (1:str_len) then it works fine. (There is another similar error that can be fixed in the same way.)

To Reproduce Compile the FMS library with GFortran 14.1. Then make the modifications above to verify that it works.

Expected behavior Should compile

System Environment None of this is relevant. This is happening in both MacOS and several Linux environments.

Additional context I recall that these changes were made to accommodate character select type blocks in PGI (now Nvidia) Fortran. We may find that this has been fixed in the newer Nvidia compilers, and no longer require such a trick.

rem1776 commented 1 month ago

We have a check for a similar compiler bug in our configure script. It would test assigning a string with subscripts in the select type. It was added for gcc 4.8 originally but looks like it's made a return in 14.

We should be able to get rid of the explicit string bounds as long as that doesn't mess with the strings, it's definitely been fixed in the newer nvhpc versions.

rem1776 commented 1 month ago

@marshallward My apologies, I was wrong about the substring issue being fixed in the new nvidia compiler (must've been thinking of a different bug...). It still needs a substring specified to work properly within the select type, otherwise it winds up with an incorrect length when it gets passed into a routine.

Since this was a regression from previous gcc versions we will need to wait for a fix to support GCC 14. I will put in a bug report for gcc and make sure there's one in for nvidia.

rem1776 commented 1 month ago

This has reportedly been fixed in the gcc dev branch:

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