[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #20 from Kyle Shores --- (In reply to Steve Kargl from comment #19) > On Fri, Mar 08, 2024 at 05:42:05PM +, kyle.shores44 at gmail dot com > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 > > > > --- Comment #17 from Kyle Shores --- > > I was able to get tuv-x to compile by putting use statements in problematic > > files at the top of the module. In one case, I had to match the use > > ordering to > > the order that the objects were used in the module (unsure if that > > mattered), > > and I also removed an object in a use only statement that wasn't used in > > that > > same file and then it compiled (these last two issues were for the same file > > test/unit/radiator/from_host.F90) > > > > > > It seems your code is hitting a NULL pointer dereference when > generating a warning. In resolve.cc(resolve_procedure_expression), > one finds > > /* A non-RECURSIVE procedure that is used as procedure expression within > its > own body is in danger of being called recursively. */ > if (is_illegal_recursion (sym, gfc_current_ns)) > gfc_warning (0, "Non-RECURSIVE procedure %qs at %L is possibly calling" >" itself recursively. Declare it RECURSIVE or use" >" %<-frecursive%>", sym->name, &expr->where); > > for whatever reason &expr->where is a NULL pointer. If I change > the above to remove &expr->where, then your code compiles with > a bunch of warningsi, e.g., > > [ 95%] Building Fortran object > test/oldtuv/CMakeFiles/oldphotolib.dir/util/la_srb.type.F90.o > /usr/home/sgk/tmp/tuv-x/test/oldtuv/util/la_srb.type.F90:873:28: > > 873 | end module la_srb_type > |1 > Warning: Non-RECURSIVE procedure 'get_config_array' at (1) is possibly > calling itself recursively. Declare it RECURSIVE or use '-frecursive' > > Unfortunately, without a much smaller example code, I cannot go > any further in debugging your problem. Well that's odd, that function doesn't call itself recursively For example get_config_array: https://github.com/NCAR/tuv-x/blob/6930151e3cd89189df4ec046fdf19c02300d4380/src/util/config.F90#L715-L754 Either way, this PR fixes the issue for gcc 13 be moving use statements around https://github.com/NCAR/tuv-x/pull/53. The bug still exists in gcc 13, but for anyone else who encounters this issue, they can try pulling use statements up to the top of the module
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #18 from Kyle Shores --- (In reply to Steve Kargl from comment #16) > On Fri, Mar 08, 2024 at 04:44:52PM +, kyle.shores44 at gmail dot com > wrote: > > I have not made a smaller example, but we have since removed json-fortran > > as a > > dependency for tuv-x. > > > > So it should be easier to view the failure in tuv-x. I have not made the > > time > > to try to reduce the code to an example, but maybe this could help. > > > > Following this instructions should show an error > > > > git clone https://github.com/NCAR/tuv-x > > cd tuv-x > > mkdir build && cd build > > FC=g++-13 cmake .. > > make > > > > FC=g++-13? > > Should that be gfortran13? > > I get > > % env FC=/usr/home/sgk/work/x/bin/g++ cmake .. > -- The Fortran compiler identification is GNU 14.0.1 > -- The CXX compiler identification is GNU 14.0.1 > -- The C compiler identification is GNU 14.0.1 > -- Detecting Fortran compiler ABI info > -- Detecting Fortran compiler ABI info - failed > -- Check for working Fortran compiler: /usr/home/sgk/work/x/bin/g++ > -- Check for working Fortran compiler: /usr/home/sgk/work/x/bin/g++ - broken > CMake Error at > /usr/local/share/cmake/Modules/CMakeTestFortranCompiler.cmake:59 (message): > The Fortran compiler > > "/usr/home/sgk/work/x/bin/g++" ya, sorry about that. I'm more used to typing g++ than gfortran, muscle memory kicked in
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #17 from Kyle Shores --- I was able to get tuv-x to compile by putting use statements in problematic files at the top of the module. In one case, I had to match the use ordering to the order that the objects were used in the module (unsure if that mattered), and I also removed an object in a use only statement that wasn't used in that same file and then it compiled (these last two issues were for the same file test/unit/radiator/from_host.F90) Here's the PR: https://github.com/NCAR/tuv-x/pull/53
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #15 from Kyle Shores --- To reiterate how this issue can sometimes be resolved, if I take use statements out of subroutines and place them at the top of a module, files can then be compiled.
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #14 from Kyle Shores --- I have not made a smaller example, but we have since removed json-fortran as a dependency for tuv-x. So it should be easier to view the failure in tuv-x. I have not made the time to try to reduce the code to an example, but maybe this could help. Following this instructions should show an error git clone https://github.com/NCAR/tuv-x cd tuv-x mkdir build && cd build FC=g++-13 cmake .. make
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #3 from Kyle Shores --- I'll try to create a smaller example, but as y'all know this can be hard...
[Bug fortran/110644] New: Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 Bug ID: 110644 Summary: Error in gfc_format_decoder Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kyle.shores44 at gmail dot com Target Milestone: --- I moved from gcc 11 to gcc 13.1 recently. I have a library that compiled with gcc 11 but cannot be compiled with gcc 13 without moving use statements out of functions and subroutines and also changing the order of the use statements. I would like to provide a small example but I could not figure out how to replicate this when writing a smaller program. However, here is a PR (https://github.com/NCAR/tuv-x/pull/272) that shows changes to files that allow them to compile. I have not been able to compile the entire project yet, but I have noticed that in general if I put the use statements in the order that the imported content is used in the rest of the file that I can compile. Sadly, this pattern doesn't always seem to be true. After I finish getting the full project compiled, maybe I'll learn enough to create a smaller example that better reproduces the error. The error I get is not very useful: `in gfc_format_decoder, at fortran/error.cc:1078` I added the line to get the bug report, but I don't see any temporary files created.
[Bug libfortran/108618] ISO C-Fortran Interface fails to pass CFI descriptor version check when using code coverage flags for fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618 --- Comment #10 from Kyle Shores --- Ah, wait I lied. I must not have recompiled or something because everything works now. Thank you again for addressing this and sorry for submitting a false positive.
[Bug libfortran/108618] ISO C-Fortran Interface fails to pass CFI descriptor version check when using code coverage flags for fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618 --- Comment #8 from Kyle Shores --- Thanks for looking into this. I believe that this worked for you, but for me, on both my machine and in the docker container, that addition did not fix the problem.
[Bug libfortran/108618] ISO C-Fortran Interface fails to pass CFI descriptor version check when using code coverage flags for fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #5 from Kyle Shores ---
New C++ source file:
```
#include
#include
#include
#include
#include
#include
extern "C" {
void Finit(void);
void get_names( CFI_cdesc_t * );
}
std::vector extract_names(CFI_cdesc_t* names){
std::vector vs;
for (int i = 0; i < names->dim[0].extent; i++) {
// determine the length of the string up to the first whitespace character
char* addr = (char *)(names->base_addr) + i * names->elem_len;
char* first_space = strchr(addr, ' ');
size_t strlen = first_space - addr;
vs.push_back(std::string_view(addr).substr(0, strlen));
}
return vs;
}
int main(){
CFI_CDESC_T(1) names;
std::cout << names.version << std::endl;
get_names((CFI_cdesc_t *)&names);
std::cout << names.version << std::endl;
std::vector vs = extract_names((CFI_cdesc_t *)&names);
for(const auto& elem : vs)
{
std::cout << elem << std::endl;
}
}
```
Makefile:
```
CXX=g++-12
FC=gfortran
CXX_FLAGS=-c -g -O0 -fprofile-arcs -ftest-coverage -fprofile-abs-path
FORT_FLAGS=-c -g -O0 -fprofile-arcs -ftest-coverage -fcheck=bounds,do,pointer
-ffpe-trap=zero,overflow,invalid -fprofile-abs-path
all: cpp fort
${CXX} -o bad_version test.o fortran_strings.o -lgcov -lgfortran
cpp:
${CXX} ${CXX_FLAGS} test.cpp
fort:
${FC} ${FORT_FLAGS} fortran_strings.F90
```
Hope that helps
[Bug libfortran/108618] ISO C-Fortran Interface fails to pass CFI descriptor version check when using code coverage flags for fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618 --- Comment #4 from Kyle Shores --- Sure, I'll attempt to remove gtest and cmake. I was merely slimming the example down from my use case in case it mattered.
[Bug libfortran/108618] ISO C-Fortran Interface fails to pass CFI descriptor version check when using code coverage flags for fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618 --- Comment #3 from Kyle Shores --- Ah, the specific error message printed at runtime: Fortran runtime error: Unexpected version 16 (expected 1) in CFI descriptor passed to dummy argument the_names
[Bug libfortran/108618] New: ISO C-Fortran Interface fails to pass CFI descriptor version check when using code coverage flags for fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618 Bug ID: 108618 Summary: ISO C-Fortran Interface fails to pass CFI descriptor version check when using code coverage flags for fortran Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: kyle.shores44 at gmail dot com Target Milestone: --- Created attachment 54378 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54378&action=edit A zipped archive with 5 files, a dockerfile, CMakeLists.txt, a cmake file for code coverage, a fortran source file, a c++ source file The C-Fortran interface fails to pass a runtime Fortran check for the CFI descriptor when checking code coverage. Specifically, the `-fcheck=bounds` flag causes the runtime failure. Included is a zip file that has a minimal working example. It's a cmake project with two source files (one c++, one fortran), a Dockerfile, a CMakeLists.txt file as well as the necessary code coverage cmake file. Fortran creates some strings and passes them to C(++) through the `CFI_cdesc_t` struct defined in ISO_Fortran_binding.h. Inside of the CMakeLists.txt file there are two calls to `set(CMAKE_Fortran_FLAGS ...`. Above each is a comment indicating which of the flags passes and which fails. You can comment and uncomment the pair to watch the created executable fail intermittently. When I compile the sources on my machine with the below versions of tools, I see the failure. os: macOS 12.5 architecture: Apple M1 Pro gfortran: GNU Fortran (Homebrew GCC 12.2.0) 12.2.0 g++: (Homebrew GCC 12.2.0) 12.2.0 cmake: 3.25.1 I also see the failure in the Dockerfile included in the zipped archive (hopefully this aids in the reproducibility of the issue). The tool versions in the Dockerfile are os: Fedora Linux 38 architecture: Apple M1 Pro gfortran: GNU Fortran (GCC) 13.0.1 20230127 (Red Hat 13.0.1-0) g++: (GCC) 13.0.1 20230127 (Red Hat 13.0.1-0) cmake: 3.25.2 The specific flag that causes the issue is `-fcheck=bounds`. The full list of compiler flags passed to gfortran on my machine: /opt/homebrew/bin/gfortran -I/Users/kshores/Downloads/mwe/build/_deps/googletest-src/googletest/include -I/Users/kshores/Downloads/mwe/build/_deps/googletest-src/googletest -g -O0 -fprofile-arcs -ftest-coverage -fcheck=bounds,do,pointer -ffpe-trap=zero,overflow,invalid -fprofile-abs-path -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.3.sdk -c /Users/kshores/Downloads/mwe/fortran_strings.F90 -o CMakeFiles/bad_version.dir/fortran_strings.F90.o The full list of compiler flags passed to gfortran in the Dockerfile: /usr/bin/gfortran -I/build/_deps/googletest-src/googletest/include -I/build/_deps/googletest-src/googletest -g -O0 -fprofile-arcs -ftest-coverage -fcheck=bounds,do,pointer -ffpe-trap=zero,overflow,invalid -fprofile-abs-path -c /mwe/fortran_strings.F90 -o CMakeFiles/bad_version.dir/fortran_strings.F90.o I hope that this is enough information. Please let me know if there is more that is needed from me.
