This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/56856] the location of Wformat warnings points *after* the format string
- From: "manu at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 13 Jul 2016 21:03:36 +0000
- Subject: [Bug c++/56856] the location of Wformat warnings points *after* the format string
- Auto-submitted: auto-generated
- References: <bug-56856-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56856
--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #5)
> I thought I'd look into this bug since it affects the testing of my patch
> for bug 49905 and I'm finding out that it seems to be a general problem with
> C++ and function arguments. From what I can see, the C front end tracks the
> locations of function arguments through the parser, passing them from
> function to function, while the C++ front end doesn't. Sadly, it doesn't
> look like a simple fix...
This happens for "expressions" that don't have a location (such as constants,
variable uses, etc.). I'm not even sure that passing the location is enough,
since the C++ parser will do a lot of tentative parsing and, by the time you
call the function, input_location is too far away and the original location of
the argument is lost. You may need to store the locations together with the
arguments when they are parsed and somehow keep them together throughout the
C++ FE. Which is of course redundant when the expressions actually have a
location.
At the end, everything comes back to fixing PR43486