Does not compile with gcc 11.0.0 (due to compiler error)

[ghbrown]

Describe the bug Compiling PROGRESS with most recent gfortran compiler (gcc 11.0.0) results in a compiler error (as in the compiler itself breaks). I recognize that this is very likely not the problem of PROGRESS developers, but before I submit a bug report to any gfortran developers, I would like to make sure it is reproducible by somebody more knowledgeable about these libraries. Perhaps somebody has already reported this, but no open or closed issues have any mention of it.

Just a few months ago built with no issues, so perhaps the new gcc release has bugs if one came out in that time.

To Reproduce Steps to reproduce the behavior:

• install most recent version of BML and PROGRESS
• build BML (sh build.sh compile; sh build.sh install)
• go to PROGRESS directory and build (sh example_build.sh; cd build; cd build; make)
• if my problem is reproducible, you should get an error near gpmd_dist at about 79% (full error below)

Scanning dependencies of target gpmd_dist
[ 79%] Building Fortran object examples/CMakeFiles/gpmd_dist.dir/gpdist/gpmd_dist.F90.o
f951: internal compiler error: Segmentation fault
0x16db558 internal_error(char const*, ...)
	???:0
0x7606f0 gfc_sym_get_dummy_args(gfc_symbol*)
	???:0
0x808989 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*)
	???:0
0x808a9e gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*)
	???:0
0x808989 gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*)
	???:0
0x808a9e gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*)
	???:0
0x808a9e gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*)
	???:0
0x80a12a gfc_run_passes(gfc_namespace*)
	???:0
0x727323 gfc_resolve(gfc_namespace*)
	???:0
0x73880f gfc_resolve_code(gfc_code*, gfc_namespace*)
	???:0
0x73b107 gfc_resolve_blocks(gfc_code*, gfc_namespace*)
	???:0
0x7386d6 gfc_resolve_code(gfc_code*, gfc_namespace*)
	???:0
0x7272fa gfc_resolve(gfc_namespace*)
	???:0
0x719618 gfc_parse_file()
	???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.archlinux.org/> for instructions.
make[2]: *** [examples/CMakeFiles/gpmd_dist.dir/build.make:75: examples/CMakeFiles/gpmd_dist.dir/gpdist/gpmd_dist.F90.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:452: examples/CMakeFiles/gpmd_dist.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

The build log is attached: build.log, but please let me know if any more information is needed. Thank you.

[nicolasbock]

Thanks for reporting this issue @ghbrown ! Could you also share some information about the OS you are building the library on?

[ghbrown]

Sure, this is on my personal laptop running Manjaro Linux. All packages and applications are up to date.

Here is the output of cat /etc/lsb-release:

DISTRIB_ID=ManjaroLinux
DISTRIB_RELEASE=21.1.3
DISTRIB_CODENAME=Pahvo
DISTRIB_DESCRIPTION="Manjaro Linux"

[ghbrown]

I've been able to recreate this problem as recently as yesterday. However, after doing some compiler location, path and variable management on my side, as well as following the build instructions on the progress README (rather than the somewhat outdated wiki for LATTE-LAMMPS), things appear to be okay. No older compiler versions or anything seemed to be necessary (though I see there are other issues open for this...)

I'll keep track of my updated build process for BML-PROGRESS-LATTE-LAMMPS and then forward that info to the LATTE team to update the wiki.

[nicolasbock]

Thanks for the update @ghbrown

Out of curiosity, could you share what kind of "management" you did on your side to fix the issue?

[ghbrown]

It seemed anaconda was managing/providing my compilers (don't remember ever setting this up, so I just installed system-wide compilers instead). Then there were issues with CMake caches storing the old file and binary paths even after reboots and reclones of the repos, so I had to manually overwrite some environment variables due to how CMake grabbed things and searched paths. In addition to compilers, conda also started providing ar and ranlib somehow, which caused some very odd issues that were fixed in a similar way to the compiler ones.

All this being said, I'm not sure if the issue (if there every was one) is fixed, but at least I am not experiencing it anymore.

[nicolasbock]

Thanks for the detailed update @ghbrown ! Unfortunately once you use multiple package managers things can become quite tricky to debug.

I will add a CI test with gcc-11 so we test this compiler regularly.

[ghbrown]

Unfortunately, this issue has appeared again.

Based on CMakeCache.txt Anaconda is not managing any of the resources used in the build, and I've double checked the main ones.

Steps (slightly updated):

• install most recent version of BML and PROGRESS
• build BML (sh build.sh compile; sh build.sh install)
• go to PROGRESS directory, set BML_LIB variable to environment variable which terminates at ..../bml/install, and build (sh example_build.sh; cd build; make)

Thankfully this is not holding me up since making use of ./build.sh instead works as intended, which is very odd.

Perhaps when you add the test for GCC-11, you could add a version that makes use of the example_build.sh scheme as well, since (at least for me) this seems to be the only path that gives the error.