https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #19 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:591a05e2027d202e2d28ef6fd5df63e7c7f9556d
commit r10-8730-g591a05e2027d202e2d28ef6fd5df63e7c7f9556d
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #18 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:3536ff2de8317c430546fd97574d44c5146cef2b
commit r11-2995-g3536ff2de8317c430546fd97574d44c5146cef2b
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #17 from Jakub Jelinek ---
Created attachment 49175
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49175&action=edit
gcc11-pr94311.patch
Untested patch which implements location and block caching and the above test
passes with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #16 from Jakub Jelinek ---
One possible way at the libcpp side is to make sure we don't deplete the
location_t stuff too much once we are above highest >
LINE_MAP_MAX_LOCATION_WITH_COLS. I mean, the comment above this if block says:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #15 from Jakub Jelinek ---
Short reproducer:
$ cat pr94311.c
#line 210
static inline __attribute__((always_inline)) void
foo (void)
{
int a = 23;
}
#line 65570
volatile int v;
#define A { int b = 42; foo (); }
#define B A A A A A A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #14 from Richard Biener ---
so
void
lto_location_cache::input_location_and_block (location_t *loc, tree *block,
struct bitpack_d *bp,
class lto_input_block *ib,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #12 from Richard Biener ---
For PHIs we could use the cache but I see we're simply dropping the BLOCKs
there (now that block location is encoded in the location we _do_ have
a location BLOCK there as well).
At least
/* Do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #13 from Richard Biener ---
Note we can still overflow locations so I wonder if we can have a more
forgiving failure mode? Return UNKNOWN_LOCATION maybe.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #11 from Jakub Jelinek ---
I think the problem is just we ran out of the locations.
We hit both
if (start_location >= LINE_MAP_MAX_LOCATION)
/* We ran out of line map space. */
start_location = 0;
in linemap_add and
ov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #10 from Jakub Jelinek ---
When I put a breakpoint on ../../libcpp/line-map.c:1737 with xloc.line > 4
(i.e. near end of linemap_expand_location after xloc.line is set), I see
(gdb) p/x line_table->highest_line
$16 = 0x66e48c7c
(gd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
Jakub Jelinek changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #8 from Mark Wielaard ---
Note that VEX/priv/guest_arm64_toIR.c is fairly big (1.2M):
$ wc VEX/priv/guest_amd64_toIR.c
32655 127564 1189783 VEX/priv/guest_amd64_toIR.c
(but still less than 2^15 lines)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #7 from Mark Wielaard ---
Note that the above is in ./install/lib/valgrind/memcheck-amd64-linux
Which has .debug_line entries like:
[0x00098404] Set is_stmt to 0
[0x00098405] Advance PC by constant 17 to 0x5809993c
[0x000984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #6 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #5)
> I can no longer replicate the issue of the bad line numbers with gcc (GCC)
> 10.1.1 20200507 (Red Hat 10.1.1-1) on fedora 32. With either 3.15.0 or
> current valg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
Mark Wielaard changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Mark Wielaard -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #4 from Richard Biener ---
(In reply to Mark Wielaard from comment #3)
> (In reply to Richard Biener from comment #1)
> > Err, but isn't this interpreting the dwarf from 'date'? So doesn't this
> > mean that valgrind is "miscompiled"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #3 from Mark Wielaard ---
(In reply to Richard Biener from comment #1)
> Err, but isn't this interpreting the dwarf from 'date'? So doesn't this
> mean that valgrind is "miscompiled" with --enable-lto rather than wrong
> debug?
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
19 matches
Mail list logo
