[Bug middle-end/48674] [4.7 Regression] FAIL: g++.dg/torture/pr48661.C

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48674

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-05-02 14:55:38 UTC ---
Just to add, the other alternatives discussed were

 I) Avoid direct calls to thunks at early optimization time.
    This has problem with fact that C++ FE doesn't really tell us about thunks
    in other units (though I think it has the knowledge) and thus this breaks
    with LTO or if someone does direct call by hand (using aliasing ASM name
that
    does not work at the moment in non-LTO compilation)
II) Invent Gimple representation of thunks
    To do so, one would need to invent way represeting variadic thunks
    Also either we would need to trash existing ASM thunk output machinery
    and re-implement in a way so RTL optimizers produce same code expanding
    the new construct.
    Still we would need to handle same special cases for 1) and 2) from 
    my initial list of problems
III)Thunks are really meant to be alternative entry points to the functions.
    We should eventually bite the bullet and implement them.  
IV) Attach the info to edges.  This makes things more transparent to WHOPR,
    and most of ipa passes: i.e. if you don't care about it, you can pretend
    thunks does not exist. It is also more consistent with III since
alternative
    entry points should probably be represented as different kind of edges into
    single callgraph node (=function).

    It however seems to make less sense to people and makes it easier to 
    introduce wrong code bugs by ignoring the info on edges wehere you should
not.