On 07/28/2016 02:12 PM, David Malcolm wrote:
On Wed, 2016-07-27 at 23:41 +0100, Manuel López-Ibáñez wrote:
On 27 July 2016 at 15:30, David Malcolm <dmalc...@redhat.com> wrote:
Perhaps it could live for now in c-format.c, since it is the only
place using it?
Martin Sebor [CC-ed] wants to use it from the middle-end:
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01088.html
so it's unclear to me that c-format.c would be a better location.
Fine. He will have to figure out how to get a cpp_reader from the
middle-end, though.
It seems to me that on-demand reconstruction of source locations for
STRING_CST nodes is inherently frontend-specific: unless we have the
frontend record the information in some fe-independent way (which I
assume we *don't* want to do, for space-efficiency), we need to be able
to effectively re-run part of the frontend.
So maybe this needs to be a langhook; the c-family can use the global
cpp_reader * there, and everything else can return a "not supported"
code if a diagnostic requests substring location information (and the
diagnostic needs to be able to cope with that).
The problem with the lanhook approach, as I learned from my first
-Wformat-length attempt, is that it doesn't make the front end
implementation available to LTO. So passes that run late enough
with LTO (like the latest version of the -Wformat-length pass
does) would not be bale to make use of it.
Martin
