Bug 90380 - gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project
Summary: gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran p...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: gcov-profile (show other bugs)
Version: 8.3.0
: P3 normal
Target Milestone: ---
Assignee: Martin Liška
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2019-05-07 14:50 UTC by Victor
Modified: 2020-09-25 08:35 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work: 10.0, 8.3.1, 9.1.1
Known to fail:
Last reconfirmed: 2019-05-07 00:00:00


Attachments
Dot of basic blocks at p4est_triangulation.f90':688 (74.11 KB, image/svg+xml)
2019-05-09 07:28 UTC, Martin Liška
Details
-fdump-tree-original? (175.60 KB, application/x-compressed-tar)
2019-05-09 18:02 UTC, Victor
Details
Fortran module -fdump-tree-original (49.35 KB, application/x-xz)
2019-05-09 20:14 UTC, Melven.Roehrig-Zoellner
Details
Testcase: Fortran coverage .gcda and .gcno files (13.62 KB, application/x-xz)
2019-05-10 07:19 UTC, Melven.Roehrig-Zoellner
Details
Patch 2/2 (1.13 KB, application/mbox)
2019-05-10 08:36 UTC, Martin Liška
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Victor 2019-05-07 14:50:25 UTC
Dear GCC/Gcov team,

we are developing Fempar, a Fortran200X project with some mixed C code, that takes advantage of CPP preprocessor.

We have recently updated our CI environment from GCC 5.4.1 to 8.3.0. Coverage with GCC 8.3.0 fails because it gets stuck in a infinite loop while analyzing some files in our software project

We did not determine the exact version of GCC in which this issue appears. The latest version that was working correctly for us was 6.2.0. This issue can be reproduced, at least, with GCC 8.X.X and 9.X.X.

We have reproduced the issue environment by means of Docker containers. In particular, to reproduce the issue please run the following commands:

```
$ # Launch the docker container
$ docker run --rm -ti fempar/fempar:gnu-8.3.0_gcov-issue gcov
$ # Run the following command inside the docker container
$ gcov -l -o "/data/fempar/Sources/Lib/CMakeFiles/FEMPAR.dir/Geometry/Triangulation" "/data/fempar/Sources/Lib/CMakeFiles/FEMPAR.dir/Geometry/Triangulation/p4est_triangulation.f90.gcda"
```

After running these commands, gcov output is shown in the following lines:

```
File '/tmp/fempar-experimental/Sources/Lib/Geometry/Triangulation/sbm_p4est_base_triangulation.i90'
Lines executed:81.37% of 1653
Creating 'p4est_triangulation.f90.gcda##sbm_p4est_base_triangulation.i90.gcov'
```

At this point gcov gets stuck and, it seems, that never ends.

The code has been compiled with the following flags:

-fdefault-real-8 -ffree-line-length-0 -cpp -Wimplicit-interface -g -fbacktrace -fbounds-check -fprofile-arcs -ftest-coverage -Wimplicit-interface

Is this a known bug?
Is there any possible workaround?

Let me know if you need any other further information.

Thanks in advance,
Víctor.
Comment 1 Victor 2019-05-07 14:55:15 UTC
Sorry,

the command to launch the docker container has an extra `gcov` at the end.

To correctly launch the container, please use this command:

$ docker run --rm -ti fempar/fempar:gnu-8.3.0_gcov-issue

Best,
Víctor
Comment 2 Martin Liška 2019-05-07 15:04:07 UTC
Thanks for the report, I'll take a look..
Comment 3 Martin Liška 2019-05-07 15:14:35 UTC
Confirmed, I see following back-trace:

#0  0x000000000044f9d4 in handle_cycle (count=<optimized out>, edges=...) at /usr/src/debug/gcc8-8.3.1+r269200-1.1.x86_64/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include/bits/stl_vector.h:948
#1  circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:695
#2  0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#3  0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#4  0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#5  0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
...
#443 0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#444 0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#445 0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#446 0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#447 0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#448 0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#449 0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#450 0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#451 0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#452 0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#453 0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#454 0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#455 0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#456 0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#457 0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#458 0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#459 0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#460 0x000000000044fa54 in circuit (v=<optimized out>, path=..., start=0x6e0f10, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffd868: 0) at ../../gcc/gcov.c:697
#461 0x000000000044fb32 in get_cycles_count (linfo=..., handle_negative_cycles=handle_negative_cycles@entry=true) at ../../gcc/gcov.c:742
#462 0x0000000000450c5f in accumulate_line_info (add_coverage=false, src=<optimized out>, line=0x4c0670) at ../../gcc/gcov.c:2601
#463 accumulate_line_counts (src=0x67fdd0) at ../../gcc/gcov.c:2631
#464 generate_results (file_name=0x78df10 "p4est_triangulation.f90.gcda") at ../../gcc/gcov.c:1328
#465 0x0000000000438ac2 in main (argc=<optimized out>, argv=<optimized out>) at ../../gcc/gcov.c:796
Comment 4 Melven.Roehrig-Zoellner 2019-05-08 18:02:03 UTC
Hi

I have a similar problem with GCC 9.1.0, GCC 7.2.0 works fine.
(I also had problems with GCC 8.1.0 but I did not check that this is actually the same problem).

Backtrace obtained with gdb:

zoel_ml@SC-030083L:/home_local/zoel_ml/VAST_playground_clean (gcc9_fixes)> gdb --args gcov /localdata2/zoel_ml/VAST_playground_clean/build/extras/Freewake-prefix/src/Freewake-build/CMakeFiles/objpostproc.dir/source/postproc/fw_postproc_module.f90.gcda --branch-counts --branch-probabilities --preserve-paths --object-directory /localdata2/zoel_ml/VAST_playground_clean/build/extras/Freewake-prefix/src/Freewake-build/CMakeFiles/objpostproc.dir/source/postproc
GNU gdb (GDB) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from gcov...done.
(gdb) run
Starting program: /tools/modulesystem/tools/gcc/gcc-9.1.0/install/sled12.x86_64.gcc-4.8.5.release.combinedTree/bin/gcov /localdata2/zoel_ml/VAST_playground_clean/build/extras/Freewake-prefix/src/Freewake-build/CMakeFiles/objpostproc.dir/source/postproc/fw_postproc_module.f90.gcda --branch-counts --branch-probabilities --preserve-paths --object-directory /localdata2/zoel_ml/VAST_playground_clean/build/extras/Freewake-prefix/src/Freewake-build/CMakeFiles/objpostproc.dir/source/postproc
^C
Program received signal SIGINT, Interrupt.
std::__find_if<__gnu_cxx::__normal_iterator<block_info const**, std::vector<block_info const*, std::allocator<block_info const*> > >, __gnu_cxx::__ops::_Iter_equals_val<block_info const* const> > (__pred=...,
    __last=..., __first=...) at /tools/modulesystem/tools/gcc/gcc-9.1.0/build/sled12.x86_64.gcc-4.8.5.release.combinedTree/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/predefined_ops.h:240
240             operator()(_Iterator __it)
(gdb) bt
#0  std::__find_if<__gnu_cxx::__normal_iterator<block_info const**, std::vector<block_info const*, std::allocator<block_info const*> > >, __gnu_cxx::__ops::_Iter_equals_val<block_info const* const> > (
    __pred=..., __last=..., __first=...) at /tools/modulesystem/tools/gcc/gcc-9.1.0/build/sled12.x86_64.gcc-4.8.5.release.combinedTree/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/predefined_ops.h:240
#1  std::__find_if<__gnu_cxx::__normal_iterator<block_info const**, std::vector<block_info const*, std::allocator<block_info const*> > >, __gnu_cxx::__ops::_Iter_equals_val<block_info const* const> > (
    __pred=..., __last=..., __first=...) at /tools/modulesystem/tools/gcc/gcc-9.1.0/build/sled12.x86_64.gcc-4.8.5.release.combinedTree/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algo.h:161
#2  std::find<__gnu_cxx::__normal_iterator<block_info const**, std::vector<block_info const*, std::allocator<block_info const*> > >, block_info const*> (__val=<synthetic pointer>: 0x4d3a48, __last=...,
    __first=...) at /tools/modulesystem/tools/gcc/gcc-9.1.0/build/sled12.x86_64.gcc-4.8.5.release.combinedTree/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algo.h:3889
#3  unblock (u=0x4d3a48, blocked=..., block_lists=...) at /tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:725
#4  0x0000000000405dc7 in circuit (v=<optimized out>, path=..., start=start@entry=0x4cfe28, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffb088: 0)
    at /tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:775
#5  0x0000000000405d94 in circuit (v=<optimized out>, path=..., start=start@entry=0x4cfe28, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffb088: 0)
    at /tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:769
#6  0x0000000000405d94 in circuit (v=<optimized out>, path=..., start=start@entry=0x4cfe28, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffb088: 0)

... same line repeated ...

    at /tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:769
#94 0x0000000000405d94 in circuit (v=<optimized out>, path=..., start=start@entry=0x4cfe28, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffb088: 0)
    at /tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:769
#95 0x0000000000405d94 in circuit (v=<optimized out>, path=..., start=start@entry=0x4cfe28, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffb088: 0)
    at /tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:769
#96 0x0000000000405d94 in circuit (v=<optimized out>, path=..., start=0x4cfe28, blocked=..., block_lists=..., linfo=..., count=@0x7fffffffb088: 0) at /tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:769
#97 0x0000000000405f90 in get_cycles_count (linfo=..., handle_negative_cycles=handle_negative_cycles@entry=true) at /tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:814
#98 0x00000000004060e2 in accumulate_line_info (line=line@entry=0x589c40, src=src@entry=0x4c87f0, add_coverage=add_coverage@entry=true) at /tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:2695
#99 0x0000000000409c8a in accumulate_line_counts (src=0x4c87f0) at /tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:2735
#100 generate_results (file_name=<optimized out>) at /tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:1447
#101 main (argc=<optimized out>, argv=<optimized out>) at /tools/modulesystem/tools/gcc/gcc-9.1.0/src/gcc/gcov.c:868

This occurs for 6 Fortran files in our project (out of 200-300). We are also using mixed Fortran, C / C++ code (with bind(C) interfaces between them).

Regards
Melven
Comment 5 Martin Liška 2019-05-09 07:01:08 UTC
(In reply to Melven.Roehrig-Zoellner from comment #4)
> Hi
> 
> I have a similar problem with GCC 9.1.0, GCC 7.2.0 works fine.
> (I also had problems with GCC 8.1.0 but I did not check that this is
> actually the same problem).
> 

Yes, I can confirm that. I'm going to work on that today.
Comment 6 Victor 2019-05-09 07:06:58 UTC
Thanks for your quick responses Martin!

Please, let us know any advance on this.

Best regards,
Víctor
Comment 7 Melven.Roehrig-Zoellner 2019-05-09 07:27:56 UTC
Out of curiosity I tried to have a look at the debug output:

It seems to me that it gets stuck in the circuit detection of a source line that just contains an "end module"-statement.
And it seems to detect two cycles (handle_cycle) alternatingly with the paths:
 A B C D E .... X Y Z
 A B C D E .... Z
 A B C D E .... X Y Z

And in my case there is no single call to the related source file (count = 0).

Thanks for looking into that!

Regards
Melven
Comment 8 Martin Liška 2019-05-09 07:28:57 UTC
Created attachment 46320 [details]
Dot of basic blocks at p4est_triangulation.f90':688

Note that p4est_triangulation.f90':688 source line contains enormous number of basic block (~600). How is that possible?
Comment 9 Melven.Roehrig-Zoellner 2019-05-09 07:30:06 UTC
(In reply to Martin Liška from comment #8)
> Created attachment 46320 [details]
> Dot of basic blocks at p4est_triangulation.f90':688
> 
> Note that p4est_triangulation.f90':688 source line contains enormous number
> of basic block (~600). How is that possible?

Same for the case I looked at...
Comment 10 Martin Liška 2019-05-09 07:32:02 UTC
(In reply to Melven.Roehrig-Zoellner from comment #7)
> Out of curiosity I tried to have a look at the debug output:
> 
> It seems to me that it gets stuck in the circuit detection of a source line
> that just contains an "end module"-statement.
> And it seems to detect two cycles (handle_cycle) alternatingly with the
> paths:
>  A B C D E .... X Y Z
>  A B C D E .... Z
>  A B C D E .... X Y Z
> 
> And in my case there is no single call to the related source file (count =
> 0).

Yes, we can bail out quickly when having such a loopish graph with count equal to zero.

> 
> Thanks for looking into that!
> 
> Regards
> Melven
Comment 11 Martin Liška 2019-05-09 08:18:56 UTC
I've got a patch that I've been testing.
Comment 12 Melven.Roehrig-Zoellner 2019-05-09 08:38:16 UTC
Btw. in our gcc 7.2 coverage (which works fine), I often see about 800 branches at an "end module" statement...
Comment 13 Victor 2019-05-09 15:15:50 UTC
(In reply to Martin Liška from comment #8)
> Created attachment 46320 [details]
> Dot of basic blocks at 6191':688
> 
> Note that p4est_triangulation.f90':688 source line contains enormous number
> of basic block (~600). How is that possible?

Dear Martin,

regarding your comment, p4est_triangulation.f90 is a source file containing several includes. The raw file contains 688 lines, but after including other external source code it has a total length of 6191 lines.

I think with such amount of lines, having 600 basic blocks could be quite normal. 

Do you agree?

Best,
Víctor.
Comment 14 Martin Liška 2019-05-09 15:18:48 UTC
(In reply to Victor from comment #13)
> (In reply to Martin Liška from comment #8)
> > Created attachment 46320 [details]
> > Dot of basic blocks at 6191':688
> > 
> > Note that p4est_triangulation.f90':688 source line contains enormous number
> > of basic block (~600). How is that possible?
> 
> Dear Martin,
> 
> regarding your comment, p4est_triangulation.f90 is a source file containing
> several includes. The raw file contains 688 lines, but after including other
> external source code it has a total length of 6191 lines.
> 
> I think with such amount of lines, having 600 basic blocks could be quite
> normal. 
> 
> Do you agree?

I'm talking about 600 BB that belong to a single line in the original source file:
p4est_triangulation.f90:688

Martin

> 
> Best,
> Víctor.
Comment 15 Martin Liška 2019-05-09 15:19:30 UTC
Patch candidate:
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00418.html
Comment 16 Victor 2019-05-09 15:22:07 UTC
(In reply to Martin Liška from comment #14)
> (In reply to Victor from comment #13)
> > (In reply to Martin Liška from comment #8)
> > > Created attachment 46320 [details]
> > > Dot of basic blocks at 6191':688
> > > 
> > > Note that p4est_triangulation.f90':688 source line contains enormous number
> > > of basic block (~600). How is that possible?
> > 
> > Dear Martin,
> > 
> > regarding your comment, p4est_triangulation.f90 is a source file containing
> > several includes. The raw file contains 688 lines, but after including other
> > external source code it has a total length of 6191 lines.
> > 
> > I think with such amount of lines, having 600 basic blocks could be quite
> > normal. 
> > 
> > Do you agree?
> 
> I'm talking about 600 BB that belong to a single line in the original source
> file:
> p4est_triangulation.f90:688
> 
> Martin
> 
> > 
> > Best,
> > Víctor.
Martin,

this is weird, line 688 is an "end module" statement.
Comment 17 Martin Liška 2019-05-09 15:24:30 UTC
> 
> this is weird, line 688 is an "end module" statement.

I see. Can you please use -fdump-tree-original and attach the dump file it generates?
Comment 18 Victor 2019-05-09 18:02:24 UTC
Created attachment 46330 [details]
-fdump-tree-original?

Martin,

this is the first time I use this flag. Is the attached file the one you are asking for?

If not, please, let me know how to obtain what you are looking for.
Comment 19 Martin Liška 2019-05-09 18:52:33 UTC
(In reply to Victor from comment #18)
> Created attachment 46330 [details]
> -fdump-tree-original?
> 
> Martin,
> 
> this is the first time I use this flag. Is the attached file the one you are
> asking for?

Yes, you did it great ;)

> 
> If not, please, let me know how to obtain what you are looking for.

Apparently, it's clean up code that is present in multiple functions:


        while (1)
          {
            {
              logical(kind=4) D.6324;

              D.6324 = idx > D.6321;
              if (D.6324) goto L.2;
              if ((integer(kind=8)) (SAVE_EXPR <idx> <= 0))
                {
                  _gfortran_runtime_error_at (&"At line 688 of file /tmp/fempar-experimental/Sources/Lib/Geometry/Triangulation/p4est_triangulation.f90"[1]{lb: 1 sz: 1}, &"Index \'%ld\' of dimension 1 of array \'strides\' below lower bound of %ld"[1]{lb: 1 sz: 1}, SAVE_EXPR <idx>, 1);
                }
              if ((integer(kind=8)) (SAVE_EXPR <idx> > ubound.2))
                {
                  _gfortran_runtime_error_at (&"At line 688 of file /tmp/fempar-experimental/Sources/Lib/Geometry/Triangulation/p4est_triangulation.f90"[1]{lb: 1 sz: 1}, &"Index \'%ld\' of dimension 1 of array \'strides\' above upper bound of %ld"[1]{lb: 1 sz: 1}, SAVE_EXPR <idx>, ubound.2);
                }
              (*strides)[NON_LVALUE_EXPR <SAVE_EXPR <idx>> + -1] = array->dim[idx + -1].stride;
...
}

Anyway we've got a patch that I'll install probably tomorrow.
I'm going to backport that to GCC 8.x branch and GCC 9.x branch.
Btw. have you thought about using the fresh new release 9.1.0?
Comment 20 Victor 2019-05-09 19:02:24 UTC
Hi Martin, 

these are great news!

Indeed we are using 9.1.0 till today for the CI process, and since monday for testing purposes before production.

The coverage issue is still present in GCC 9.1.0. The great thing is that we discover the -fprofile-exclude-files option to try to workaround the issue. But the issue is present through many files of the project and it was a mess to try to exclude one by one ...

Anyway, please let me know when this patch is present in a gcc-release/patch version to test it.

Thanks for helping us!
Víctor
Comment 21 Melven.Roehrig-Zoellner 2019-05-09 19:23:57 UTC
Hi,

for me the patch seems to solve the problem only for some of the Fortran files.

I applied the patch in my GCC 9.1.0 build and I still have 4 files where gcov does not seem to terminate (running for over an hour now).

Would it help to provide source and gcda files?
Comment 22 Melven.Roehrig-Zoellner 2019-05-09 20:14:50 UTC
Created attachment 46333 [details]
Fortran module -fdump-tree-original

Hi again,

I also generated the -fdump-tree-original output for ony of my problematic source files.

You can have a look if you think this might be useful.

Thanks
Melven
Comment 23 Martin Liška 2019-05-10 06:13:24 UTC
(In reply to Melven.Roehrig-Zoellner from comment #21)
> Hi,
> 
> for me the patch seems to solve the problem only for some of the Fortran
> files.
> 
> I applied the patch in my GCC 9.1.0 build and I still have 4 files where
> gcov does not seem to terminate (running for over an hour now).
> 
> Would it help to provide source and gcda files?

Yes please, please attach only x.gcda and x.gcno files.
Comment 24 Melven.Roehrig-Zoellner 2019-05-10 07:19:37 UTC
Created attachment 46335 [details]
Testcase: Fortran coverage .gcda and .gcno files

Hi Martin

here is coverage test data for one of the Fortran files where gcov does not seem to terminate.

Steps to reproduce:
Just run
> gcov vast_mbs_model.gcda
... wait ...

I'm not sure if it would finish sometime; I aborted it after an hour.

Thanks for looking into that!
Melven
Comment 25 Martin Liška 2019-05-10 08:36:01 UTC
(In reply to Melven.Roehrig-Zoellner from comment #24)
> Created attachment 46335 [details]
> Testcase: Fortran coverage .gcda and .gcno files
> 
> Hi Martin
> 
> here is coverage test data for one of the Fortran files where gcov does not
> seem to terminate.
> 
> Steps to reproduce:
> Just run
> > gcov vast_mbs_model.gcda
> ... wait ...
> 
> I'm not sure if it would finish sometime; I aborted it after an hour.
> 
> Thanks for looking into that!
> Melven

Thanks a lot. Apparently, I did a stupid mistake in the 0002 patch. Please test me the updated patch.
Comment 26 Martin Liška 2019-05-10 08:36:25 UTC
Created attachment 46336 [details]
Patch 2/2
Comment 27 Melven.Roehrig-Zoellner 2019-05-10 09:00:35 UTC
(In reply to Martin Liška from comment #25)
> (In reply to Melven.Roehrig-Zoellner from comment #24)
> > Created attachment 46335 [details]
> > Testcase: Fortran coverage .gcda and .gcno files
> > 
> > Hi Martin
> > 
> > here is coverage test data for one of the Fortran files where gcov does not
> > seem to terminate.
> > 
> > Steps to reproduce:
> > Just run
> > > gcov vast_mbs_model.gcda
> > ... wait ...
> > 
> > I'm not sure if it would finish sometime; I aborted it after an hour.
> > 
> > Thanks for looking into that!
> > Melven
> 
> Thanks a lot. Apparently, I did a stupid mistake in the 0002 patch. Please
> test me the updated patch.

Hi Martin

With both patches it works fine.
The output seams reasonable and matches well with the results obtained by GCC 7.2.0 for the file I provided (not identical results but the different compiler versions most probably produce slightly different code/branches)

Thanks a lot
Melven
Comment 28 Martin Liška 2019-05-10 09:23:36 UTC
(In reply to Melven.Roehrig-Zoellner from comment #27)
> (In reply to Martin Liška from comment #25)
> > (In reply to Melven.Roehrig-Zoellner from comment #24)
> > > Created attachment 46335 [details]
> > > Testcase: Fortran coverage .gcda and .gcno files
> > > 
> > > Hi Martin
> > > 
> > > here is coverage test data for one of the Fortran files where gcov does not
> > > seem to terminate.
> > > 
> > > Steps to reproduce:
> > > Just run
> > > > gcov vast_mbs_model.gcda
> > > ... wait ...
> > > 
> > > I'm not sure if it would finish sometime; I aborted it after an hour.
> > > 
> > > Thanks for looking into that!
> > > Melven
> > 
> > Thanks a lot. Apparently, I did a stupid mistake in the 0002 patch. Please
> > test me the updated patch.
> 
> Hi Martin
> 
> With both patches it works fine.
> The output seams reasonable and matches well with the results obtained by
> GCC 7.2.0 for the file I provided (not identical results but the different
> compiler versions most probably produce slightly different code/branches)
> 
> Thanks a lot
> Melven

Hi Melven!

Thank you very much for testing. Yes, there can be slight differences among compiler versions.

A nice cooperation, I'm going to install the patch early next week.
Comment 29 Martin Liška 2019-05-13 07:05:30 UTC
Author: marxin
Date: Mon May 13 07:04:58 2019
New Revision: 271116

URL: https://gcc.gnu.org/viewcvs?rev=271116&root=gcc&view=rev
Log:
Test for not existence of a negative loop (PR gcov-profile/90380).

2019-05-13  Martin Liska  <mliska@suse.cz>

	PR gcov-profile/90380
	* gcov.c (enum loop_type): Remove the enum and
	the operator.
	(handle_cycle): Assert that we should not reach
	a negative count.
	(circuit): Use loop_found instead of a tri-state loop_type.
	(get_cycles_count): Do not handle NEGATIVE_LOOP as it can't
	happen.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gcov.c
Comment 30 Martin Liška 2019-05-13 07:05:54 UTC
Author: marxin
Date: Mon May 13 07:05:23 2019
New Revision: 271117

URL: https://gcc.gnu.org/viewcvs?rev=271117&root=gcc&view=rev
Log:
Do not follow zero edges in cycle detection (PR gcov-profile/90380).

2019-05-13  Martin Liska  <mliska@suse.cz>

	PR gcov-profile/90380
	* gcov.c (handle_cycle): Do not support zero cycle count,
	it should not be possible.
	(path_contains_zero_cycle_arc): New function.
	(circuit): Ignore zero cycle arc counts.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gcov.c
Comment 31 Martin Liška 2019-05-13 07:06:24 UTC
Fixed on trunk so far.
Comment 32 Victor 2019-05-13 10:57:32 UTC
(In reply to Martin Liška from comment #31)
> Fixed on trunk so far.

Thanks Martin!

is this going to be released within 8.X or 9.X branches/versions?
Comment 33 Martin Liška 2019-05-13 11:14:16 UTC
(In reply to Victor from comment #32)
> (In reply to Martin Liška from comment #31)
> > Fixed on trunk so far.
> 
> Thanks Martin!
> 
> is this going to be released within 8.X or 9.X branches/versions?

Yes, the fix will be in GCC 8.4.0 and GCC 9.2.0 when they are released.
Comment 34 Victor 2019-05-13 14:10:00 UTC
(In reply to Martin Liška from comment #26)
> Created attachment 46336 [details]
> Patch 2/2

Hi Martin,

sorry for a newbie question ... but,  which version this patch applies on?

I mean, I would like to generate a Docker container applying this patch to gcc.

For this purpose, I would like to take a recipe from https://github.com/docker-library/gcc, do some minor modifications (apply the patch) and compile/test our software.

Can you point me to the right startpoint-recipe?

Thanks in advance,
Víctor
Comment 35 Martin Liška 2019-05-14 08:46:58 UTC
Author: marxin
Date: Tue May 14 08:46:27 2019
New Revision: 271150

URL: https://gcc.gnu.org/viewcvs?rev=271150&root=gcc&view=rev
Log:
Backport r271116

2019-05-14  Martin Liska  <mliska@suse.cz>

	Backport from mainline
	2019-05-13  Martin Liska  <mliska@suse.cz>

	PR gcov-profile/90380
	* gcov.c (enum loop_type): Remove the enum and
	the operator.
	(handle_cycle): Assert that we should not reach
	a negative count.
	(circuit): Use loop_found instead of a tri-state loop_type.
	(get_cycles_count): Do not handle NEGATIVE_LOOP as it can't
	happen.

Modified:
    branches/gcc-9-branch/gcc/ChangeLog
    branches/gcc-9-branch/gcc/gcov.c
Comment 36 Martin Liška 2019-05-14 08:47:08 UTC
Author: marxin
Date: Tue May 14 08:46:35 2019
New Revision: 271151

URL: https://gcc.gnu.org/viewcvs?rev=271151&root=gcc&view=rev
Log:
Backport r271117

2019-05-14  Martin Liska  <mliska@suse.cz>

	Backport from mainline
	2019-05-13  Martin Liska  <mliska@suse.cz>

	PR gcov-profile/90380
	* gcov.c (handle_cycle): Do not support zero cycle count,
	it should not be possible.
	(path_contains_zero_cycle_arc): New function.
	(circuit): Ignore zero cycle arc counts.

Modified:
    branches/gcc-9-branch/gcc/ChangeLog
    branches/gcc-9-branch/gcc/gcov.c
Comment 37 Martin Liška 2019-05-14 08:50:46 UTC
(In reply to Victor from comment #34)
> (In reply to Martin Liška from comment #26)
> > Created attachment 46336 [details]
> > Patch 2/2
> 
> Hi Martin,
> 
> sorry for a newbie question ... but,  which version this patch applies on?
> 
> I mean, I would like to generate a Docker container applying this patch to
> gcc.
> 
> For this purpose, I would like to take a recipe from
> https://github.com/docker-library/gcc, do some minor modifications (apply
> the patch) and compile/test our software.
> 
> Can you point me to the right startpoint-recipe?

Yes, please take r271150 and r271151 revisions that I've just installed into gcc-9 branch and add them to gcc 9.1 package.

Martin

> 
> Thanks in advance,
> Víctor
Comment 38 Martin Liška 2019-05-14 09:13:06 UTC
Author: marxin
Date: Tue May 14 09:12:35 2019
New Revision: 271154

URL: https://gcc.gnu.org/viewcvs?rev=271154&root=gcc&view=rev
Log:
Backport r271116

2019-05-14  Martin Liska  <mliska@suse.cz>

	Backport from mainline
	2019-05-13  Martin Liska  <mliska@suse.cz>

	PR gcov-profile/90380
	* gcov.c (enum loop_type): Remove the enum and
	the operator.
	(handle_cycle): Assert that we should not reach
	a negative count.
	(circuit): Use loop_found instead of a tri-state loop_type.
	(get_cycles_count): Do not handle NEGATIVE_LOOP as it can't
	happen.

Modified:
    branches/gcc-8-branch/gcc/ChangeLog
    branches/gcc-8-branch/gcc/gcov.c
Comment 39 Martin Liška 2019-05-14 09:13:19 UTC
Author: marxin
Date: Tue May 14 09:12:47 2019
New Revision: 271155

URL: https://gcc.gnu.org/viewcvs?rev=271155&root=gcc&view=rev
Log:
Backport r271117

2019-05-14  Martin Liska  <mliska@suse.cz>

	Backport from mainline
	2019-05-13  Martin Liska  <mliska@suse.cz>

	PR gcov-profile/90380
	* gcov.c (handle_cycle): Do not support zero cycle count,
	it should not be possible.
	(path_contains_zero_cycle_arc): New function.
	(circuit): Ignore zero cycle arc counts.

Modified:
    branches/gcc-8-branch/gcc/ChangeLog
    branches/gcc-8-branch/gcc/gcov.c
Comment 40 Martin Liška 2019-05-14 09:13:50 UTC
Fixed on all active branches.
Comment 41 Victor 2019-05-16 08:54:47 UTC
(In reply to Martin Liška from comment #40)
> Fixed on all active branches.

I can confirm that coverage is working for us compiling gcc from gcc-9-branch from https://github.com/gcc-mirror/gcc mirror repository.

Thanks for the great work!
Comment 42 Martin Liška 2019-05-16 09:10:28 UTC
(In reply to Victor from comment #41)
> (In reply to Martin Liška from comment #40)
> > Fixed on all active branches.
> 
> I can confirm that coverage is working for us compiling gcc from
> gcc-9-branch from https://github.com/gcc-mirror/gcc mirror repository.
> 
> Thanks for the great work!

Glad to hear. I thank you, it was a nice cooperation.
Comment 43 Prasannanjaneyulu 2020-09-24 16:21:14 UTC
Looks like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48361 is similar. But We could still see this issue on GCC 5.4.0 on ubuntu 16.04.12 with Gcov 5.4.0 and lcov 1.2. Is it something can't be fixed for lower GCC versions or is there any possible workaround?
Comment 44 Martin Liška 2020-09-25 08:35:11 UTC
Please update to at least GCC 8.4.0, it should be fixed there.
Older releases are not supported right now.