This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug preprocessor/79106] wrong source line printed in diagnostics for a translation unit
- From: "dmalcolm at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 17 Jan 2017 17:52:42 +0000
- Subject: [Bug preprocessor/79106] wrong source line printed in diagnostics for a translation unit
- Auto-submitted: auto-generated
- References: <bug-79106-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79106
David Malcolm <dmalcolm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dmalcolm at gcc dot gnu.org
--- Comment #5 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
It seems you want the diagnostic to read:
FILENAME-FROM-DIRECTIVE.c: some message
(content from .i file goes here)
We're encoding file/line information into location_t values. Currently we
encode the filename given by the line directive.
Maybe it's implementable. line_table_dump shows the LC_RENAME_VERBATIM for the
# line directive:
Map #0 [0x7ffff189e000] - LOC: 32 - REASON: LC_ENTER - SYSP: no
File: a.i:1
Included from: [-1] None
Map #1 [0x7ffff189e020] - LOC: 4128 - REASON: LC_RENAME_VERBATIM - SYSP: no
File: a.c:1
Included from: [-1] None
Perhaps the LC_RENAME_VERBATIM linemap could store the location of the
directive that created it, and we could then map back and apply an offset,
giving the line and column within the .i file. Though am not sure exactly how
we'd encode it (e.g. what if there are very wide lines? etc).
Maybe some kind of variant of expand_location that ignores directives like
this? (and then diagnostic_show_locus would use it).