[Bug fortran/110644] New: Error in gfc_format_decoder

[Bug fortran/110644] New: Error in gfc_format_decoder

[kyle.shores44 at gmail dot com]

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 fortran/110644] Error in gfc_format_decoder

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Unfortunately, we're going to need a reduced testcase.  I tried the simple
instruction to build tuv-x, but don't have json-fortran.

[Bug fortran/110644] Error in gfc_format_decoder

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2023-10-13

--- Comment #2 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Need more information.

[Bug fortran/110644] Error in gfc_format_decoder

[kyle.shores44 at gmail dot com]

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

--- Comment #3 from Kyle Shores <kyle.shores44 at gmail dot com> ---
I'll try to create a smaller example, but as y'all know this can be hard...

[Bug fortran/110644] Error in gfc_format_decoder

[aluaces at udc dot es]

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

Alberto Luaces <aluaces at udc dot es> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aluaces at udc dot es

--- Comment #4 from Alberto Luaces <aluaces at udc dot es> ---
I got the same error in almost the same circumstances (crash in error.cc:1078).

I have a large codebase and I could not prepare a minimal testcase, but I have
built gfortran 13 from source with the aim to debug the crash.

Hoewever, even I set "set follow-fork-mode children", f951 crashes and I cannot
navigate through the backtrace nor see the arguments of the functions.

Is there any reference for debugging gcc in order to send some useful
information to this bug?

[Bug fortran/110644] Error in gfc_format_decoder

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Oct 18, 2023 at 03:56:32PM +0000, aluaces at udc dot es wrote:
> --- Comment #4 from Alberto Luaces <aluaces at udc dot es> ---
> I got the same error in almost the same circumstances (crash in error.cc:1078).
> 
> I have a large codebase and I could not prepare a minimal testcase, but I have
> built gfortran 13 from source with the aim to debug the crash.
> 
> Hoewever, even I set "set follow-fork-mode children", f951 crashes and I cannot
> navigate through the backtrace nor see the arguments of the functions.
> 
> Is there any reference for debugging gcc in order to send some useful
> information to this bug?
> 

If you've built 13 and still have the source files and build 
directory, then locate the installed l f951.  For me, I have 

${HOME}/work/x/libexec/gcc/x86_64-unknown-freebsd14.0/14.0.0/f951

In following, I'm going to use ${PATH} for the above path.

Go to the directory where your project dies.  Suppose it is 
compiling foo.f90 when it crashes.  Do the following.

gdb ${PATH}/f951

(gdb) b error.cc:1078
(gdb) run foo.f90

Line 1078 is 

        gcc_assert (loc->nextc - loc->lb->line >= 0);

so the source file information looks corrupt.  You may need to 
continue the process a few to generate the crash, i.e.,

(gdb) c

<when it crashes>

(gdb) bt

This will generate a backtrace.  Post that.

[Bug fortran/110644] Error in gfc_format_decoder

[aluaces at udc dot es]

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

--- Comment #6 from Alberto Luaces <aluaces at udc dot es> ---
Thanks a lot for the guidance.  This is the backtrace of the last call to
gcc_assert() that makes it crash.

It says something about a non-recursive function likely calling itself.  I will
inspect my source, even it is a bit too big.  Maybe a better solution would be
if I compiled gcc with debugging flags.  Can I just use C_FLAGS="-O0 -g" and
CXX_FLAGS="-O0 -g" at configure time, or if is there a specific configure flag?

1078            gcc_assert (loc->nextc - loc->lb->line >= 0);
(gdb) bt
#0  gfc_format_decoder (pp=0x2706750, text=0x7fffffffb840, spec=0x2708d10 "L",
precision=<optimized out>, wide=false, set_locus=false, hash=false,
quoted=0x7fffffffb667, buffer_ptr=0x2708b00)
    at ../../gcc-13.2.0/gcc/fortran/error.cc:1078
#1  0x0000000001b44c0a in pp_format (pp=<optimized out>,
text=text@entry=0x7fffffffb840) at ../../gcc-13.2.0/gcc/pretty-print.cc:1475
#2  0x0000000001b34e02 in diagnostic_report_diagnostic (context=0x26ee380
<global_diagnostic_context>, diagnostic=diagnostic@entry=0x7fffffffb840) at
../../gcc-13.2.0/gcc/diagnostic.cc:1592
#3  0x000000000071cbc8 in gfc_report_diagnostic (diagnostic=0x7fffffffb840) at
../../gcc-13.2.0/gcc/fortran/error.cc:890
#4  gfc_warning(int, const char *, typedef __va_list_tag __va_list_tag *)
(opt=0,
    gmsgid=0x1c9c420 "Non-RECURSIVE procedure %qs at %L is possibly calling
itself recursively.  Declare it RECURSIVE or use %<-frecursive%>",
ap=ap@entry=0x7fffffffb9c8)
    at ../../gcc-13.2.0/gcc/fortran/error.cc:923
#5  0x000000000071d287 in gfc_warning (opt=opt@entry=0,
gmsgid=gmsgid@entry=0x1c9c420 "Non-RECURSIVE procedure %qs at %L is possibly
calling itself recursively.  Declare it RECURSIVE or use %<-frecursive%>")
    at ../../gcc-13.2.0/gcc/fortran/error.cc:954
#6  0x00000000007a275f in resolve_procedure_expression (expr=0x32a9530) at
../../gcc-13.2.0/gcc/fortran/resolve.cc:1956
#7  resolve_variable (e=0x32a9530) at
../../gcc-13.2.0/gcc/fortran/resolve.cc:6066
#8  gfc_resolve_expr (e=e@entry=0x32a9530) at
../../gcc-13.2.0/gcc/fortran/resolve.cc:7302
#9  0x000000000079ffca in gfc_resolve_expr (e=0x32a9530) at
../../gcc-13.2.0/gcc/fortran/resolve.cc:7267
#10 resolve_structure_cons (expr=<optimized out>, init=init@entry=1) at
../../gcc-13.2.0/gcc/fortran/resolve.cc:1341
#11 0x00000000007b0f02 in resolve_values (sym=0x3285270) at
../../gcc-13.2.0/gcc/fortran/resolve.cc:12802
#12 0x00000000007c79d3 in do_traverse_symtree (st=<optimized out>,
st_func=st_func@entry=0x0, sym_func=0x7b0e80 <resolve_values(gfc_symbol*)>) at
../../gcc-13.2.0/gcc/fortran/symbol.cc:4198
#13 0x00000000007d080d in gfc_traverse_ns (ns=<optimized out>,
sym_func=<optimized out>) at ../../gcc-13.2.0/gcc/fortran/symbol.cc:4223
#14 0x00000000007a7671 in resolve_types (ns=ns@entry=0x2bf2140) at
../../gcc-13.2.0/gcc/fortran/resolve.cc:17932
#15 0x00000000007ae8dd in gfc_resolve (ns=0x2bf2140) at
../../gcc-13.2.0/gcc/fortran/resolve.cc:18029
#16 0x000000000079d711 in resolve_symbol (sym=<optimized out>) at
../../gcc-13.2.0/gcc/fortran/resolve.cc:16601
#17 0x00000000007c79d3 in do_traverse_symtree (st=<optimized out>,
st_func=st_func@entry=0x0, sym_func=0x79b5f0 <resolve_symbol(gfc_symbol*)>) at
../../gcc-13.2.0/gcc/fortran/symbol.cc:4198
#18 0x00000000007d080d in gfc_traverse_ns (ns=<optimized out>,
sym_func=<optimized out>) at ../../gcc-13.2.0/gcc/fortran/symbol.cc:4223
#19 0x00000000007a759f in resolve_types (ns=ns@entry=0x2b5ed60) at
../../gcc-13.2.0/gcc/fortran/resolve.cc:17914
#20 0x00000000007ae8dd in gfc_resolve (ns=0x2b5ed60) at
../../gcc-13.2.0/gcc/fortran/resolve.cc:18029
#21 0x000000000079d711 in resolve_symbol (sym=<optimized out>) at
../../gcc-13.2.0/gcc/fortran/resolve.cc:16601
#22 0x00000000007c79d3 in do_traverse_symtree (st=<optimized out>,
st_func=st_func@entry=0x0, sym_func=0x79b5f0 <resolve_symbol(gfc_symbol*)>) at
../../gcc-13.2.0/gcc/fortran/symbol.cc:4198
#23 0x00000000007d080d in gfc_traverse_ns (ns=<optimized out>,
sym_func=<optimized out>) at ../../gcc-13.2.0/gcc/fortran/symbol.cc:4223
#24 0x00000000007a759f in resolve_types (ns=ns@entry=0x27b4340) at
../../gcc-13.2.0/gcc/fortran/resolve.cc:17914
#25 0x00000000007ae8dd in gfc_resolve (ns=0x27b4340) at
../../gcc-13.2.0/gcc/fortran/resolve.cc:18029
#26 0x000000000079b5de in gfc_resolve (ns=<optimized out>) at
../../gcc-13.2.0/gcc/fortran/resolve.cc:18016
#27 0x000000000078dbf0 in gfc_parse_file () at
../../gcc-13.2.0/gcc/fortran/parse.cc:6861
#28 0x00000000007e6160 in gfc_be_parse_file () at
../../gcc-13.2.0/gcc/fortran/f95-lang.cc:229
#29 0x0000000000d021fe in compile_file () at ../../gcc-13.2.0/gcc/toplev.cc:444
#30 0x00000000006df6fe in do_compile (no_backend=false) at
../../gcc-13.2.0/gcc/toplev.cc:2125
#31 toplev::main (this=this@entry=0x7fffffffe0de, argc=<optimized out>,
argc@entry=13, argv=<optimized out>, argv@entry=0x7fffffffe208) at
../../gcc-13.2.0/gcc/toplev.cc:2277
#32 0x00000000006e13bb in main (argc=13, argv=0x7fffffffe208) at
../../gcc-13.2.0/gcc/main.cc:39

[Bug fortran/110644] Error in gfc_format_decoder

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Oct 19, 2023 at 08:00:27AM +0000, aluaces at udc dot es wrote:
> 
> It says something about a non-recursive function likely calling itself.  I will
> inspect my source, even it is a bit too big.  Maybe a better solution would be
> if I compiled gcc with debugging flags.  Can I just use C_FLAGS="-O0 -g" and
> CXX_FLAGS="-O0 -g" at configure time, or if is there a specific configure flag?

I doubt that these options will help with this problem.  Those
are for building your application with debugging info.  The issue
is the compiler itself is dying.

> 1078            gcc_assert (loc->nextc - loc->lb->line >= 0);
> (gdb) bt
> #0  gfc_format_decoder (pp=0x2706750, text=0x7fffffffb840, spec=0x2708d10 "L",
> precision=<optimized out>, wide=false, set_locus=false, hash=false,
> quoted=0x7fffffffb667, buffer_ptr=0x2708b00)
>     at ../../gcc-13.2.0/gcc/fortran/error.cc:1078
> #1  0x0000000001b44c0a in pp_format (pp=<optimized out>,
> text=text@entry=0x7fffffffb840) at ../../gcc-13.2.0/gcc/pretty-print.cc:1475
> #2  0x0000000001b34e02 in diagnostic_report_diagnostic (context=0x26ee380
> <global_diagnostic_context>, diagnostic=diagnostic@entry=0x7fffffffb840) at
> ../../gcc-13.2.0/gcc/diagnostic.cc:1592
> #3  0x000000000071cbc8 in gfc_report_diagnostic (diagnostic=0x7fffffffb840) at
> ../../gcc-13.2.0/gcc/fortran/error.cc:890
> #4  gfc_warning(int, const char *, typedef __va_list_tag __va_list_tag *)
> (opt=0,
>     gmsgid=0x1c9c420 "Non-RECURSIVE procedure %qs at %L is possibly calling
> itself recursively.  Declare it RECURSIVE or use %<-frecursive%>",
> ap=ap@entry=0x7fffffffb9c8)
>     at ../../gcc-13.2.0/gcc/fortran/error.cc:923
> #5  0x000000000071d287 in gfc_warning (opt=opt@entry=0,
> gmsgid=gmsgid@entry=0x1c9c420 "Non-RECURSIVE procedure %qs at %L is possibly
> calling itself recursively.  Declare it RECURSIVE or use %<-frecursive%>")
>     at ../../gcc-13.2.0/gcc/fortran/error.cc:954

I suspect that the locus associate with %L in the above
error message is undefined (i.e., a NULL pointer).  This
likely means expr in the next frame is missing some info.

> #6  0x00000000007a275f in resolve_procedure_expression (expr=0x32a9530) at
> ../../gcc-13.2.0/gcc/fortran/resolve.cc:1956

Can you do 

(gdb) up 6
(gdb) p *expr

You'll likely see expr->where is either NULL or its components are.
My sources are bit newer, resolve.cc:1974 is

  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);

You can try replacing &expr->where with gfc_current_locus.  I don't
remember if the & is needed with gfc_current_locus.

[Bug fortran/110644] Error in gfc_format_decoder

[aluaces at udc dot es]

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

--- Comment #8 from Alberto Luaces <aluaces at udc dot es> ---
No, I meant building *gcc* with those flags, but alas each gcc compilation
stage was still building with "-O2" so almost all of the compiler structures
are still optimized.

Nevertheless I did what you suggest and climbed up those 6 levels to find that
indeed expr->where has null fields.  To me it is not very strange since in my
code there is a structure that has copy and assignment members. gfortran is
arguing about them being called in another module, but of course there is no
physical place where they are called, as this is done implicitly by the
compiler when using those kind of objects, if I am correct.

I am rebuilding with your suggested gfc_current_locus change and reporting the
results.

[Bug fortran/110644] Error in gfc_format_decoder

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Oct 19, 2023 at 04:00:10PM +0000, aluaces at udc dot es wrote:
> 
> No, I meant building *gcc* with those flags, but alas each gcc compilation
> stage was still building with "-O2" so almost all of the compiler structures
> are still optimized.

Ah.  Yes, that can be a pain.  The only way I've ever "fixed" this
problem is hacking configure to use "-O -g" instead of "-O2 -g".

> Nevertheless I did what you suggest and climbed up those 6 levels to find that
> indeed expr->where has null fields.  To me it is not very strange since in my
> code there is a structure that has copy and assignment members. gfortran is
> arguing about them being called in another module, but of course there is no
> physical place where they are called, as this is done implicitly by the
> compiler when using those kind of objects, if I am correct.

This is definitely a bug in that expr->where should be set.  Are
you using OOP?   

> I am rebuilding with your suggested gfc_current_locus change and reporting the
> results.

It may simply give you nonsense, but the compiliation should continue.
This may be a warning that can then be ignored.

[Bug fortran/110644] Error in gfc_format_decoder

[aluaces at udc dot es]

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

--- Comment #10 from Alberto Luaces <aluaces at udc dot es> ---
Ok, indeed they were some warnings.  I had to use &gfc_current_locus, as you
suggested, so now all of them are pointed at the end of the file.

Yes, I am using OOP: we have a "states" class that has its assignment and copy
methods.  Those are the ones that I think that they are called implicitly by
the compiler, and gfortran is struggling to point exactly where.

I think now I may be able to get a minimal case for aiding solving this bug. 
Let me see if I can.

[4/126] Building Fortran object
CMakeFiles/MBSLIM.dir/solidos/solidos_Sensib.f90.o
[...]solidos/solidos_Sensib.f90:1001:28:

 1001 | END SUBMODULE SOLIDOS_Sensib
      |                            1
Warning: Non-RECURSIVE procedure ‘statescopystates’ at (1) is possibly calling
itself recursively.  Declare it RECURSIVE or use ‘-frecursive’
[...]solidos/solidos_Sensib.f90:1001:28:

 1001 | END SUBMODULE SOLIDOS_Sensib
      |                            1
Warning: Non-RECURSIVE procedure ‘statesassignstates’ at (1) is possibly
calling itself recursively.  Declare it RECURSIVE or use ‘-frecursive’
[...]solidos/solidos_Sensib.f90:1001:28:

 1001 | END SUBMODULE SOLIDOS_Sensib
      |                            1
Warning: Non-RECURSIVE procedure ‘statecopystate’ at (1) is possibly calling
itself recursively.  Declare it RECURSIVE or use ‘-frecursive’
[...]solidos/solidos_Sensib.f90:1001:28:

 1001 | END SUBMODULE SOLIDOS_Sensib
      |                            1
Warning: Non-RECURSIVE procedure ‘stateassignstate’ at (1) is possibly calling
itself recursively.  Declare it RECURSIVE or use ‘-frecursive

[Bug fortran/110644] Error in gfc_format_decoder

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Oct 20, 2023 at 03:13:06PM +0000, aluaces at udc dot es wrote:
> Ok, indeed they were some warnings.  I had to use &gfc_current_locus, as you
> suggested, so now all of them are pointed at the end of the file.

Yeah, this is one of the places I though it would point to.  The
other place would be the first line in the file.  Either way, it
is bogus location.

> Yes, I am using OOP: we have a "states" class that has its assignment and copy
> methods.  Those are the ones that I think that they are called implicitly by
> the compiler, and gfortran is struggling to point exactly where.

Thanks for confirmation.  When a 'class' entity is involved, gfortran
may generate an internal entity to resolve the class.  Unfortunately,
the location information is sometimes not properly propagated, and 
it seems you've found one of those places.

> I think now I may be able to get a minimal case for aiding solving this bug. 
> Let me see if I can.

This would be much appreciated.

BTW, as it seems you know your way around gdb, if you have
a breakpoint set where you found expr->where contained NULL
pointers, you can do

(gdb) p *expr

to dump the structure.  You'll see *expr->ts.type == BT_CLASS
(basic type CLASS).  IIRC, *expr->symtree->name will have the
name of the entity.  If it starts with __vtab (or _vtab), it
is an internally generated symbol.

[Bug fortran/110644] Error in gfc_format_decoder

[aluaces at udc dot es]

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

--- Comment #12 from Alberto Luaces <aluaces at udc dot es> ---
It seems to be slightly different:

(gdb) p expr->ts.type
$7 = BT_PROCEDURE
(gdb) p expr->symtree->name
$8 = 0x7ffff70244e8 "@1179"

(gdb) p expr->where
$9 = {nextc = 0x0, lb = 0x0}

Maybe it will be clearer if I manage to write the example.

[Bug fortran/110644] Error in gfc_format_decoder

[jvdelisle at gcc dot gnu.org]

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

--- Comment #13 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Any luck getting a reduced case?

[Bug fortran/110644] Error in gfc_format_decoder

[kyle.shores44 at gmail dot com]

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

--- Comment #14 from Kyle Shores <kyle.shores44 at gmail dot com> ---
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

[kyle.shores44 at gmail dot com]

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

--- Comment #15 from Kyle Shores <kyle.shores44 at gmail dot com> ---
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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #16 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Mar 08, 2024 at 04:44:52PM +0000, 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++"

[Bug fortran/110644] Error in gfc_format_decoder

[kyle.shores44 at gmail dot com]

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

--- Comment #17 from Kyle Shores <kyle.shores44 at gmail dot com> ---
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

[kyle.shores44 at gmail dot com]

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

--- Comment #18 from Kyle Shores <kyle.shores44 at gmail dot com> ---
(In reply to Steve Kargl from comment #16)
> On Fri, Mar 08, 2024 at 04:44:52PM +0000, 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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #19 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Mar 08, 2024 at 05:42:05PM +0000, kyle.shores44 at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
> 
> --- Comment #17 from Kyle Shores <kyle.shores44 at gmail dot com> ---
> 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.

[Bug fortran/110644] Error in gfc_format_decoder

[kyle.shores44 at gmail dot com]

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

--- Comment #20 from Kyle Shores <kyle.shores44 at gmail dot com> ---
(In reply to Steve Kargl from comment #19)
> On Fri, Mar 08, 2024 at 05:42:05PM +0000, kyle.shores44 at gmail dot com
> wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
> > 
> > --- Comment #17 from Kyle Shores <kyle.shores44 at gmail dot com> ---
> > 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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #21 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Mar 08, 2024 at 08:01:02PM +0000, kyle.shores44 at gmail dot com wrote:
> 
> (In reply to Steve Kargl from comment #19)
> > 
> > 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
>

If shuffling the USE statements around allows your code to
compile, then it is likely that gfortran cannot tell if
there is an indirect recursion.  gfortran tries to help
the user with a warning about **possible** recursion.  There
is likely an issue with how gfortran is searching namespaces,
but  

% find . -name \*.F90 | xargs wc -l | grep total
   96683 total
% find . -name \*.f90 | xargs wc -l | grep total
    4238 total

Chopping 100 kLOC to something that is managable is beyond
what I can do.