https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108900
Andrew Pinski changed:
What|Removed |Added
CC||ovidiu.panait at windriver dot
com
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
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.
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #55 from Jan Hubicka ---
> Can the bug be marked as resolved?
I think with the location cache we only made this problem less visible
and for really large programs linemap still can overflow and behave
funy, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #54 from Martin Liška ---
Can the bug be marked as resolved?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #48 from Jan Hubicka hubicka at gcc dot gnu.org ---
I run memory statistics with the cache and my patch. I will run stats with
cache w/o the libcpp patch tomorrow. I would like to get this problem solved,
but perhaps we want to only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #46 from Jan Hubicka hubicka at gcc dot gnu.org ---
Manuel,
I will hopefully commit the cache patch today or tomorrow morning. It does not
solve full issue. What we have is
1) we still drop columns for firefoxchromium pretty early
2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #47 from Jan Hubicka hubicka at gcc dot gnu.org ---
Author: hubicka
Date: Fri Mar 27 06:58:59 2015
New Revision: 221720
URL: https://gcc.gnu.org/viewcvs?rev=221720root=gccview=rev
Log:
PR lto/65536
* lto-streamer.h (class
understood the limit of 0x7000 to give some buffer so we can still record
new
files but also drop the line number information?
-I/home/manuel/test1/221728/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/home/manuel/test1/pristine/libstdc++-v3/libsupc++
-L/home/manuel/test1/221728/build
. */
+#define LINE_MAP_MAX_SOURCE_LOCATION 0x7FF0
I understood the limit of 0x7000 to give some buffer so we can still
record new
files but also drop the line number information?
Do we really need to reserve space for 0x7FF0 - 0x7000 = 268435440
files?
Well, this is a bug in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #49 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #46)
Manuel,
I will hopefully commit the cache patch today or tomorrow morning. It does
not solve full issue. What we have is
1) we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #51 from Jan Hubicka hubicka at ucw dot cz ---
Contrary to what I said before, I think now that it really makes sense for
line-maps to return UNKNOWN_LOCATION rather than the location of something
else
when overflow occurs, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #53 from Jan Hubicka hubicka at gcc dot gnu.org ---
You can get an estimate of how much memory would be required to stream in/out
directly the line_table by summing up the memory reported by
dump_line_table_statistics for each TU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #45 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #42)
Hi,
I read linemap_line_start and I think I noticed few issues with respect
to overflows and lines being added randomly.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #26 from Jan Hubicka hubicka at ucw dot cz ---
this is a proof of concept patch that makes streamer in to collect locations
into a cache and apply them in sorted order (looking up correct max_column
hints) at the end of handling of a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #27 from Jan Hubicka hubicka at ucw dot cz ---
I have in fact considered it already, since I think it should be fairly easy
and it can be done incrementally. However, as always in GCC, things are never
as trivial as they seem. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #29 from Martin Liška marxin at gcc dot gnu.org ---
Created attachment 35131
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35131action=edit
Chrome: ODR warnings before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #30 from Martin Liška marxin at gcc dot gnu.org ---
Created attachment 35132
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35132action=edit
Chrome: ODR warnings with patch from #c21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #28 from Martin Liška marxin at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #26)
Created attachment 35130 [details]
linemap
this is a proof of concept patch that makes streamer in to collect locations
into a cache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #31 from Martin Liška marxin at gcc dot gnu.org ---
Beginning of the difference of ODR warnings:
210,211c210,211
gen/blink/core/CSSPropertyNames.cpp:2330:0: warning: type ‘struct
stringpool_t’ violates one definition rule [-Wodr]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #32 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
The main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #33 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #26)
Created attachment 35130 [details]
linemap
this is a proof of concept patch that makes streamer in to collect locations
into a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #34 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Martin Liška from comment #30)
Created attachment 35132 [details]
Chrome: ODR warnings with patch from #c21
@Martin:
The previous comment where the ICE is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #35 from Jan Hubicka hubicka at ucw dot cz ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #31 from Martin Liška marxin at gcc dot gnu.org ---
Beginning of the difference of ODR warnings:
210,211c210,211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #37 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #36)
Here we seem to sometimes affect ORDINARY_MAP_NUMBER_OF_COLUMN_BITS of an
existing line map. How that can work? We already have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #44 from Jan Hubicka hubicka at ucw dot cz ---
Ah, ok, it seems to work now. It just takes ages to print the lto1 line and it
get printed way after the lto1 process is running already.
Yep, really anoying property that the stderr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #39 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #36)
Manuel,
I returned back looking for reason lines are going out wrong when we get
short on locators. I do not understand the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #43 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #40)
Manuel,
the following way you get the lto1 invocation:
Ah, ok, it seems to work now. It just takes ages to print the lto1 line and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #40 from Jan Hubicka hubicka at gcc dot gnu.org ---
Manuel,
the following way you get the lto1 invocation:
jan@linux-qos1:~ gcc t.c -flto -O2 -c
jan@linux-qos1:~ gcc t.o -flto -O2 --verbose -save-temps 21 | grep lto1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #42 from Jan Hubicka hubicka at ucw dot cz ---
Hi,
I read linemap_line_start and I think I noticed few issues with respect
to overflows and lines being added randomly.
1) line_delta is computed as to_line SOURCE_LINE (map,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #38 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #27)
I simply use --save-temps --verbose and use lto1 invocation from there. It
is easy ;)
When I add those two options to an invokation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #41 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #37)
But now that I think about it. If linemap_star_line returns UNKNOWN_LOCATION
because set-highest_location 0x7000, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
You could just stream another table, containing the { file, line, column }
triplets, and stream location_t as indexes into this table (with 0/1 being
special for UNKNOWN_LOCATION and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
if (file_change)
{
if (prev_file)
linemap_add (line_table, LC_LEAVE, false, NULL, 0);
linemap_add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #0)
One obvious thing is that linemap_line_start takes argument 3 to be max
column hint, but we pass current_col that is not cool.
If I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #5)
(In reply to Richard Biener from comment #2)
The main issue with LTO is that it re-creates a combined linemap but in
(most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Richard Biener from comment #7)
(In reply to Manuel López-Ibáñez from comment #5)
(In reply to Richard Biener from comment #2)
The main issue with LTO is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #11 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #9)
should reduce memory consumption (and perhaps speed) of the line_table by a
I meant increase speed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
Martin Liška marxin at gcc dot gnu.org changed:
What|Removed |Added
CC||marxin at gcc
number information
|number information garbled |garbled
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
Btw, this can't be a regression in GCC 5 only (or even a regression at all?).
Maybe with macro expansion locations and better column tracking we now
more likely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
The main issue with LTO is that it re-creates a combined linemap but in (most
of the time) quite awkward ordering (simply registering random-ordered
file:line:column entries by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
The main issue with LTO is that it re-creates a combined linemap but in (most
of the time) quite awkward ordering (simply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #24 from Jan Hubicka hubicka at gcc dot gnu.org ---
Manuel, you may be right person to implement the streaming of linemaps then :)
I suppose we do care about inline stacks in longer term to get proper warnings.
We even may want to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #12 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #10)
You could just stream another table, containing the { file, line, column }
triplets, and stream location_t as indexes into this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #13 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #12)
When reading, it is possible to merge different TU line_tables into a single
one quite efficiently (in the order of the maps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org ---
By streaming the line_table directly you'd stream lots of location_t that are
not actually used for anything that is streamed into the LTO.
I don't understand why the tables would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #25 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #24)
Manuel, you may be right person to implement the streaming of linemaps then
I have in fact considered it already, since I think it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #16 from Jan Hubicka hubicka at ucw dot cz ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
The main issue with LTO is that it re-creates a combined linemap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #15 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #14)
By streaming the line_table directly you'd stream lots of location_t that
are not actually used for anything that is streamed into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #20 from Jan Hubicka hubicka at gcc dot gnu.org ---
It seems that manuel just commented out the actual insertion to linemap,
columns are still streamed and ignored.
Doing so will clearly make ODR waring more difficult to follow, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #21 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #19)
Guess that can't really pass make check or lto bootstrap, because the LTO
streamer needs to be in sync between out and in, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #22 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #20)
It seems that manuel just commented out the actual insertion to linemap,
columns are still streamed and ignored.
Doing so will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #23 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #15)
(In reply to Jakub Jelinek from comment #14)
By streaming the line_table directly you'd stream lots of location_t that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
Bug ID: 65536
Summary: [5 regression] LTO line number information garbled
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||dodji at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #18 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #17)
Something like this (not even compiled):
This version compiles
Index: src/libcpp/include/line-map.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #17 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #16)
Other easier to implement idea for GCC 5 may be to simply collect locaiton
For GCC 5 you should just disable column numbers in
Hello Everyone,
I am trying to debug the trunk cc1 (revision 192483) and it is not
finding the line number information. I am using GDB 7.5. My OS is SuSE (not
sure if that matters). Is everyone else having this issue?
Thanks,
Balaji V. Iyer.
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-28 06:18 ---
Fixed in 4.0.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-24
05:15 ---
For the mainline and 4.0.0, the issue is really PR 19192.
--
What|Removed |Added
When compiling a function with an empty body, e.g.
int MyFunc(void)
{
}
GCC seems to add line number information for the line containing the opening
bracket in two different places.
Here is an example assembler output:
.globl MyFunc
.type MyFunc, @function
MyFunc:
.LFB3
--- Additional Comments From tommi dot hoynalanmaa at iki dot fi
2005-08-29 08:59 ---
Created an attachment (id=9612)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9612action=view)
Preprocessed source to generate the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23618
--- Additional Comments From tommi dot hoynalanmaa at iki dot fi
2005-08-29 09:01 ---
Here is the output of gcc -v on my system:
---
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.4/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29
12:40 ---
Fixed for 4.0.0:
MyFunc:
.LFB2:
.file 1 debugtest1.c
.loc 1 5 0
pushl %ebp
.LCFI0:
movl%esp, %ebp
.LCFI1:
.loc 1 6 0
popl%ebp
ret
--
68 matches
Mail list logo
