This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug lto/54962] New: Strange-looking diagnostics from diagnostic_report_current_module() from warnings emitted during LTO


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]