This is the mail archive of the
mailing list for the GCC project.
Re: [LTO][PATCH] Fix lto1 ICE in pp_base_format
On Fri, Nov 21, 2008 at 11:50, Manuel LÃpez-IbÃÃez
> 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
So, we can fix this in two ways. Either add '%E' to toplev.c or force
the back ends to not use %E and use %T instead. In chatting offline
with Simon we agreed on adding %E to toplev.c.
> 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?
lto1 is the front end for the gimple language, so this is a definite
possibility. Diagnostic messages coming out of the optimizers may
eventually look slightly different than what the original FE might
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.