On Tue, Jun 3, 2008 at 2:37 AM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > Diego Novillo wrote: >> >> In g++.dg/torture/20070621-1.C we are trying to stream out a structure >> that contains a TEMPLATE_DECL. This currently causes a failure in >> lto-function-out.c:output_tree because not only TEMPLATE_DECL is >> C++-specific, we can't even access its fields from lto-function-out.c. >> >> The only way I see to handle these cases is to use a langhook. I >> appreciate that we are trying to get rid of these, but this is only a >> langhook used when streaming things out (in cc1plus). On the way in >> (lto1), we would not need the langhook, as we would just mechanically >> recreate the fields. >> >> Thoughts? >> >> >> Diego. >> > > i had been told (but such statements are often lies) that there were not > supposed to be any languages specific tree codes this late in the > compilation. if there needs to be, then this should not be a lang specific > tree code and needs to become a regular tree code. > the problem with making this a langhook is that there is no "there-there" in > that on the serialize in side, you would have to recreate the c++ front end > code that expects this tree code. (if there is no such code, then this tree > code could/should have been removed before you got there. On the other > hand, if this tree code needs to be there, then copying the c++ front end > code that processes it later is a bad road to go down. > > I would like to see this publicly discussed by the c++ front end people to > see why this tree code lingers so long. In all other cases, these late lived > fe specific tree codes either have or are supposed to have been removed.
I agree with Kenny. Basically if there is nothing in lto1 that can deal with the data, why would you want to stream it out in the first place? I guess this is because with C++ there are still some bits that call back into the frontend very late in the game (debug info and thunks come to my mind). You may want to read http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00349.html again to see what C++ FE structures are still live and for what reason. Richard.
