This is the mail archive of the 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]

Re: [LTO][PATCH] Fix lto1 ICE in pp_base_format

2008/11/21 Diego Novillo <>:
> On Fri, Nov 21, 2008 at 11:25, Manuel López-Ibáñez
> <> wrote:
>> 2008/11/21 Simon Baldwin <>:
>>> 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?



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