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:50, Manuel López-Ibáñez
> <> 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?



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