public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug lto/54962] New: Strange-looking diagnostics from diagnostic_report_current_module() from warnings emitted during LTO
@ 2012-10-17 20:30 dmalcolm at redhat dot com
2012-10-17 20:44 ` [Bug lto/54962] " manu at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: dmalcolm at redhat dot com @ 2012-10-17 20:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54962
Bug #: 54962
Summary: Strange-looking diagnostics from
diagnostic_report_current_module() from warnings
emitted during LTO
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: dmalcolm@redhat.com
I'm working on a whole-program static analyzer that runs from a gcc plugin
during lto1 when invoked via
-flto -flto-partition=none
as an IPA_PASS registered before "whole-program".
I'm currently emitting errors using error_at() with inform() to give extra
information on the (possibly interprocedural) execution path taken to reach the
error. This works, but leads to unusual-looking output.
For example, with:
$ gcc -flto -flto-partition=none [...various plugin args...] input-f.c
input-g.c input-h.c
my code detects a double-free involving an execution path between input-h.c and
input-g.c and calls
error_at("double-free of r")
on a location_t from input-h.c and gets this strange output on stderr:
In file included from test.h:1:0,
from /usr/include/stdlib.h:489,
from input-f.c:14,
from :3:
input-h.c:13:9: error: double-free of r
it then calls
inform("q passed to free()")
on a location_t from input-g.c (to show the location of the 1st free call) and
gets this on stderr:
In file included from test.h:1:0,
from /usr/include/stdlib.h:489,
from input-f.c:14,
from :3:
input-g.c:11:7: note: q passed to free()
In both cases, the "In file included from " hierarchies look bogus: the files
are being directly compiled, not included.
Debugging, it comes from gcc/diagnostic.c:diagnostic_report_current_module()
where I see this code:
275 if (map && diagnostic_last_module_changed (context, map))
276 {
277 diagnostic_set_last_module (context, map);
278 if (! MAIN_FILE_P (map))
279 {
280 map = INCLUDED_FROM (line_table, map);
281 if (context->show_column)
282 pp_verbatim (context->printer,
283 "In file included from %s:%d:%d",
284 LINEMAP_FILE (map),
285 LAST_SOURCE_LINE (map), LAST_SOURCE_COLUMN (map));
286 else
287 pp_verbatim (context->printer,
288 "In file included from %s:%d",
289 LINEMAP_FILE (map), LAST_SOURCE_LINE (map));
290 while (! MAIN_FILE_P (map))
291 {
292 map = INCLUDED_FROM (line_table, map);
This code appears to assume (via MAIN_FILE_P) that there is a concept of a main
file, and that everything else is included from it. However in the context of
diagnostics emitted during LTO it's not clear that this concept makes sense (or
maybe I'm missing something? I also wonder if by attempting to issue
diagnostics from within lto1 if I'm in unexplored territory here?)
This is called by default_tree_diagnostic_starter FWIW; perhaps lto1 needs its
own implementation of this?
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug lto/54962] Strange-looking diagnostics from diagnostic_report_current_module() from warnings emitted during LTO
2012-10-17 20:30 [Bug lto/54962] New: Strange-looking diagnostics from diagnostic_report_current_module() from warnings emitted during LTO dmalcolm at redhat dot com
@ 2012-10-17 20:44 ` manu at gcc dot gnu.org
2012-10-18 9:56 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: manu at gcc dot gnu.org @ 2012-10-17 20:44 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54962
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |manu at gcc dot gnu.org
--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-10-17 20:43:51 UTC ---
Where doe the line_maps that LTO use come from? Perhaps they are not
saved/restored correctly?
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug lto/54962] Strange-looking diagnostics from diagnostic_report_current_module() from warnings emitted during LTO
2012-10-17 20:30 [Bug lto/54962] New: Strange-looking diagnostics from diagnostic_report_current_module() from warnings emitted during LTO dmalcolm at redhat dot com
2012-10-17 20:44 ` [Bug lto/54962] " manu at gcc dot gnu.org
@ 2012-10-18 9:56 ` rguenth at gcc dot gnu.org
2012-10-18 10:39 ` manu at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-10-18 9:56 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54962
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-10-18
Ever Confirmed|0 |1
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2012-10-18 09:55:45 UTC ---
(In reply to comment #0)
> 290 while (! MAIN_FILE_P (map))
> 291 {
> 292 map = INCLUDED_FROM (line_table, map);
>
> This code appears to assume (via MAIN_FILE_P) that there is a concept of a main
> file, and that everything else is included from it. However in the context of
> diagnostics emitted during LTO it's not clear that this concept makes sense (or
> maybe I'm missing something? I also wonder if by attempting to issue
> diagnostics from within lto1 if I'm in unexplored territory here?)
You definitely are, if you are expecting everything to work just fine ;)
> This is called by default_tree_diagnostic_starter FWIW; perhaps lto1 needs its
> own implementation of this?
Maybe yes. LTO should print the "main" file as well (so it doesn't have
a MAIN_FILE_P), but not as included-from but in some other way.
Patches welcome ;)
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug lto/54962] Strange-looking diagnostics from diagnostic_report_current_module() from warnings emitted during LTO
2012-10-17 20:30 [Bug lto/54962] New: Strange-looking diagnostics from diagnostic_report_current_module() from warnings emitted during LTO dmalcolm at redhat dot com
2012-10-17 20:44 ` [Bug lto/54962] " manu at gcc dot gnu.org
2012-10-18 9:56 ` rguenth at gcc dot gnu.org
@ 2012-10-18 10:39 ` manu at gcc dot gnu.org
2012-10-18 10:40 ` rguenth at gcc dot gnu.org
2012-10-18 11:38 ` manu at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: manu at gcc dot gnu.org @ 2012-10-18 10:39 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54962
--- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-10-18 10:39:08 UTC ---
(In reply to comment #2)
> > This is called by default_tree_diagnostic_starter FWIW; perhaps lto1 needs its
> > own implementation of this?
>
> Maybe yes. LTO should print the "main" file as well (so it doesn't have
> a MAIN_FILE_P), but not as included-from but in some other way.
>
How does the line_map works in LTO? Is it saved and restored or re-build from
scratch?
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug lto/54962] Strange-looking diagnostics from diagnostic_report_current_module() from warnings emitted during LTO
2012-10-17 20:30 [Bug lto/54962] New: Strange-looking diagnostics from diagnostic_report_current_module() from warnings emitted during LTO dmalcolm at redhat dot com
` (2 preceding siblings ...)
2012-10-18 10:39 ` manu at gcc dot gnu.org
@ 2012-10-18 10:40 ` rguenth at gcc dot gnu.org
2012-10-18 11:38 ` manu at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-10-18 10:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54962
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> 2012-10-18 10:40:34 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > > This is called by default_tree_diagnostic_starter FWIW; perhaps lto1 needs its
> > > own implementation of this?
> >
> > Maybe yes. LTO should print the "main" file as well (so it doesn't have
> > a MAIN_FILE_P), but not as included-from but in some other way.
> >
>
> How does the line_map works in LTO? Is it saved and restored or re-build from
> scratch?
We stream the expanded location and allocate new line-map entries at LTO
read time.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug lto/54962] Strange-looking diagnostics from diagnostic_report_current_module() from warnings emitted during LTO
2012-10-17 20:30 [Bug lto/54962] New: Strange-looking diagnostics from diagnostic_report_current_module() from warnings emitted during LTO dmalcolm at redhat dot com
` (3 preceding siblings ...)
2012-10-18 10:40 ` rguenth at gcc dot gnu.org
@ 2012-10-18 11:38 ` manu at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: manu at gcc dot gnu.org @ 2012-10-18 11:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54962
--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-10-18 11:38:33 UTC ---
(In reply to comment #4)
>
> We stream the expanded location and allocate new line-map entries at LTO
> read time.
Where?
I guess this precludes any knowledge of what is included from where and for
sure no tracking of macro expansion, but it still doesn't explain why
MAIN_FILE_P and INCLUDED_FROM do not work reliably. They should be true for
every map and return NULL, respectively. That seems like a bug.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-10-18 11:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-17 20:30 [Bug lto/54962] New: Strange-looking diagnostics from diagnostic_report_current_module() from warnings emitted during LTO dmalcolm at redhat dot com
2012-10-17 20:44 ` [Bug lto/54962] " manu at gcc dot gnu.org
2012-10-18 9:56 ` rguenth at gcc dot gnu.org
2012-10-18 10:39 ` manu at gcc dot gnu.org
2012-10-18 10:40 ` rguenth at gcc dot gnu.org
2012-10-18 11:38 ` manu at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).