This is the mail archive of the
mailing list for the GCC project.
Re: [LTO][PATCH] Fix lto1 ICE in pp_base_format
2008/11/21 Diego Novillo <firstname.lastname@example.org>:
> On Fri, Nov 21, 2008 at 11:25, Manuel López-Ibáñez
> <email@example.com> wrote:
>> 2008/11/21 Simon Baldwin <firstname.lastname@example.org>:
>>> This patch fixes a compiler error that can occur in lto1 where a backend
>>> diagnostic message contains a %E formatter. Without the patch lto1 fails
>>> at pretty-print.c:559, for example:
>>> +/* Called during diagnostic message formatting process to print a
>>> + source-level entity onto BUFFER. This is a slightly extended version
>>> + of default_tree_printer() from toplev.c, and adds support for the '%E'
>>> + for error messages printed by backends. */
>> So why not extend default_tree_printer() instead of duplicating all this code?
> That's an alternative, but we may want to grow more formatters
> specific for gimple. It's true that this is a latent bug for every
> other front-end that doesn't implement '%E'.
If this is gimple specific, then don't put it lto1.c, put it in
gimple-pretty-print.c or such. But then, I don't understand why this
code is gimple specific and the one in toplev.c is not. I don't see
any gimple stuff in the body of the function. It actually gets a tree
and not a gimple type.
I may be wrong but I still do not see why we need this code duplication.
> It's also not clear exactly what format strings are required to be
> supported by every FE. I presume we don't have such a thing?
The second problem I see here is that when this code is compiled
without lto1 you get the FE specific pretty-printing and when compiled
with lto1 it uses the default pretty printing (or after this patch, a
specific lto pretty-print). Is this what we want?