[Bug preprocessor/108900] [libcpp] cpp gives wrong line number information with a file huge number of lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108900 --- Comment #3 from Libin Dang --- For the uploaded test case, `-fdump-internal-locations' gives the following output: ORDINARY MAP: 9 location_t interval: 274912 <= loc < 1342178464 file: header3.h starting at line: 1 column and range bits: 12 column bits: 7 range bits: 5 reason: 0 (LC_ENTER) included from location: 270816 (in ordinary map 8) header3.h: 1|loc:274912|header3 begins |44 |9900011133 |47047036036926 |46802468024680 header3.h: 2|loc:279008|header3 begins |99 |0011133344 |47036036926925 |02468024680246 ... header3.h:327613|loc:1342173664|header3 begins |33 |67778889990001 |92692582581481 |68024680246802 header3.h:327614|loc:1342177760|#include "header2.h" |7778 |78889990001112223334 |92582581481470470360 |24680246802468024680 However, location 1342173664 (0x41e0) < LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES (0x5000) but location 1342177760 (0x51e0) > LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES, therefore these two locations should not in the same line map. In linemap_line_start() of libcpp/line-map.cc, if it does not create new line map (add_map is false), it will return the following new location: r = set->highest_line + (line_delta << map->m_column_and_range_bits); and this location will be included in the last ordinary map, even that location is greater than LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES and therefore should be in a new line map. The following patch can fix this issue: --- a/libcpp/line-map.cc +++ b/libcpp/line-map.cc @@ -860,7 +860,9 @@ linemap_line_start (line_maps *set, linenum_type to_line, || (highest > LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES && map->m_range_bits > 0) || (highest > LINE_MAP_MAX_LOCATION_WITH_COLS - && (set->max_column_hint || highest >= LINE_MAP_MAX_LOCATION))) + && (set->max_column_hint || highest >= LINE_MAP_MAX_LOCATION)) + || ((set->highest_line + (line_delta << map->m_column_and_range_bits)) + > LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES)) add_map = true; else max_column_hint = set->max_column_hint; After applied this change, the `-fdump-internal-locations' options gives the following results: ORDINARY MAP: 9 location_t interval: 274912 <= loc < 1342174176 file: header3.h starting at line: 1 column and range bits: 12 column bits: 7 range bits: 5 reason: 0 (LC_ENTER) included from location: 270816 (in ordinary map 8) header3.h: 1|loc:274912|header3 begins |44 |9900011133 |47047036036926 |46802468024680 header3.h: 2|loc:279008|header3 begins |99 |0011133344 |47036036926925 |02468024680246 ... header3.h:327613|loc:1342173664|header3 begins |33 |67778889990001 |92692582581481 |68024680246802 ORDINARY MAP: 10 location_t interval: 1342174176 <= loc < 1342178272 file: header3.h starting at line: 327614 column and range bits: 12 column bits: 7 range bits: 5 reason: 2 (LC_RENAME) included from location: 270816 (in ordinary map 8) header3.h:327614|loc:1342174176|#include "header2.h" | |2223335556667778 |04703603692692582581 |80246802468024680246
[Bug preprocessor/108900] [libcpp] cpp gives wrong line number information with a file huge number of lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108900 --- Comment #2 from Libin Dang --- The reason we rose this issue is that it broken our internal code coverage test suite.
[Bug preprocessor/108900] [libcpp] cpp gives wrong line number information with a file huge number of lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108900
--- Comment #1 from Libin Dang ---
For this test case, `-fdump-internal-locations' gives:
...
header3.h:327614|loc:1342177760|#include "header2.h"
|7778
|78889990001112223334
|92582581481470470360
|24680246802468024680
ORDINARY MAP: 10
location_t interval: 1342178464 <= loc < 1342178464
file: header3.h
starting at line: 327615
column and range bits: 7
column bits: 7
range bits: 0
reason: 2 (LC_RENAME)
included from location: 270816 (in ordinary map 8)
ORDINARY MAP: 11
location_t interval: 1342178464 <= loc < 1342178496
file: header2.h
starting at line: 1
column and range bits: 7
column bits: 7
range bits: 0
reason: 0 (LC_ENTER)
included from location: 1342178336 (in ordinary map 9)
header2.h: 1|loc:1342178464|
|
|
|
|
ORDINARY MAP: 12
location_t interval: 1342178496 <= loc < 1342178528
file: header3.h
starting at line: 327614
column and range bits: 7
column bits: 7
range bits: 0
reason: 1 (LC_LEAVE)
included from location: 270816 (in ordinary map 8)
header3.h:327614|loc:1342178496|#include "header2.h"
|
|4445
|99900111
|78901234567890123456
...
Map 10 has `location_t interval: 1342178464 <= loc < 1342178464', this does not
look right. And Map 12 suppose to have location information for `header3 ends'
instead of `#include "header2.h"'.
Both the following changes can fix this issue (at least for this test case):
diff --git a/libcpp/line-map.c b/libcpp/line-map.c
index 8a390d0..991170e 100644
--- a/libcpp/line-map.c
+++ b/libcpp/line-map.c
@@ -524,6 +524,10 @@ linemap_add (line_maps *set, enum lc_reason reason,
/* A TO_FILE of NULL is special - we use the natural values. */
if (to_file == NULL)
{
+ /* Adjust for LC_RENAME in some special cases */
+ while (from->to_file == from[1].to_file && from->included_from ==
from[1].included_from)
+++from;
+
diff --git a/libcpp/line-map.cc b/libcpp/line-map.cc
index 62077c3857c0..452016f377c9 100644
--- a/libcpp/line-map.cc
+++ b/libcpp/line-map.cc
@@ -775,8 +775,6 @@ linemap_line_start (line_maps *set, linenum_type to_line,
&& line_delta * map->m_column_and_range_bits > 1000)
|| (max_column_hint >= (1U << effective_column_bits))
|| (max_column_hint <= 80 && effective_column_bits >= 10)
- || (highest > LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES
- && map->m_range_bits > 0)
|| (highest > LINE_MAP_MAX_LOCATION_WITH_COLS
&& (set->max_column_hint || highest >= LINE_MAP_MAX_LOCATION)))
add_map = true;
However, neither of them looks right.
[Bug preprocessor/108900] New: [libcpp] cpp gives wrong line number information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108900 Bug ID: 108900 Summary: [libcpp] cpp gives wrong line number information Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: libin.dang at gmail dot com Target Milestone: --- Created attachment 54514 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54514&action=edit test case Reproduce: $ /home/wrsadmin/works/gcc/b0/gcc/cpp -B /home/wrsadmin/works/gcc/b0/gcc main.c -o main.i $ tail main.i header3 begins header3 begins # 1 "header2.h" 1 # 327614 "header3.h" 2 header3 ends # 4 "header1.h" 2 # 1 "header4.h" 1 # 5 "header1.h" 2 header1 ends # 2 "main.c" 2 $ cat -n header3.h | tail 327606 header3 begins 327607 header3 begins 327608 header3 begins 327609 header3 begins 327610 header3 begins 327611 header3 begins 327612 header3 begins 327613 header3 begins 327614 #include "header2.h" 327615 header3 ends The line number information for `header3 ends' is wrong. BTW, this issue is very sensitive to the input files, for example, if we add another line `header3 begins' above the `#include "header2.h"' in header3.h, we will get the correct result: $ cat -n header3.h | tail 327607 header3 begins 327608 header3 begins 327609 header3 begins 327610 header3 begins 327611 header3 begins 327612 header3 begins 327613 header3 begins 327614 header3 begins 327615 #include "header2.h" 327616 header3 ends $ tail main.i header3 begins header3 begins # 1 "header2.h" 1 # 327616 "header3.h" 2 header3 ends # 4 "header1.h" 2 # 1 "header4.h" 1 # 5 "header1.h" 2 header1 ends # 2 "main.c" 2
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
--- Comment #6 from Libin Dang ---
(In reply to Martin Liška from comment #2)
> Using latest GCC release you can see what happens:
>
> $ g++ pr96919.cc --coverage && ./a.out && gcov a-pr96919.cc -t
> hello
> libgcov profiling
> error:/home/marxin/Programming/testcases/a-pr96919.gcda:overwriting an
> existing profile data with a different timestamp
> -:0:Source:pr96919.cc
> -:0:Graph:a-pr96919.gcno
> -:0:Data:a-pr96919.gcda
> -:0:Runs:1
> -:1:class Base {
> -:2:public:
> -:3: Base() = default;
>1*:4: virtual ~Base() = default;
> --
> _ZN4BaseD0Ev:
> #:4: virtual ~Base() = default;
> --
> _ZN4BaseD2Ev:
> 1:4: virtual ~Base() = default;
> --
> -:5: virtual void foo() = 0;
> -:6:};
> -:7:class Hello : public Base {
> -:8:public:
> -:9: Hello() = default;
>1*: 10: ~Hello() = default;
> --
> _ZN5HelloD0Ev:
> #: 10: ~Hello() = default;
> --
> _ZN5HelloD2Ev:
> 1: 10: ~Hello() = default;
> --
> -: 11: void foo() override;
> -: 12:};
> -: 13:
> -: 14:#include
> -: 15:
> -: 16:using namespace std;
> -: 17:
> 1: 18:void Hello::foo() {
> 1: 19: cout << "hello" << endl;
> 1: 20:}
> -: 21:
> 1: 22:int main(int argc, char* argv[]) {
> #: 23: Hello hello;
> 1: 24: hello.foo();
> 1: 25: return 0;
> -: 26:}
>
> So yes, it's a virtual destructor _ZN4BaseD0Ev that is not called.
> And the not executed line:
> #:4: Hello hello;
>
> corresponds to a basic block
>
>:
> :
> Hello::~Hello (&hello);
> resx 2
>
> which would be executed when the Hellow constructor fails.
A strange thing about this test case:
If I removed 'return 0;' at line 25, gcov will mark line 23 as executed.
Tested with both gcov 8.3 and 10.2.
