Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FMS does not appear to compile with GFortran 14.1 #1527

Open
marshallward opened this issue May 16, 2024 · 3 comments
Open

FMS does not appear to compile with GFortran 14.1 #1527

marshallward opened this issue May 16, 2024 · 3 comments

Comments

@marshallward
Copy link
Member

marshallward commented May 16, 2024

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
Copy link
Contributor

rem1776 commented May 17, 2024

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
Copy link
Contributor

rem1776 commented May 21, 2024

@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
Copy link
Contributor

rem1776 commented May 22, 2024

This has reportedly been fixed in the gcc dev branch:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants