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 <email@example.com>:
> On Fri, Nov 21, 2008 at 11:50, Manuel López-Ibáñez
> <firstname.lastname@example.org> wrote:
>> 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.
> That's a good point. This leaves me with some questions then. The
> back ends are required to use print formatting strings that are
> understood by all the front ends, right? This means that the pretty
> printers should all eventually call the default pretty print formatter
> in toplev.c.
As I see the current code, backends simply call the pretty-printer
that the language initialization code configured for them. Then, the
FE specific pretty printer may eventually call the default in
toplev.c. It doesn't need to. I see that there is a pp_c_identifier,
so I wouldn't be surprised if without lto1 this backend error uses
pp_c_identifier to print this string.
> Right now this division occurs when we emit IL to disk and read it
> back in lto1. In the future, however, this division will happen as
> soon as we go into gimple. The model that we are going after is that
> once the FE hands off to gimple, it disappears because it will simply
> not be needed anymore. Everything we need from it will have to be
> encoded somehow in the IL.
And the lang hooks? There is decl_printable_name for example. I am
sorry I haven't followed lto development but how is the lang hooks
usage solved? Are there gimple lang hooks?