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

["hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #11 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-05-02 15:26:23 UTC ---
> Most of them is moot if we just accept that direct calls to thunks are
> a barrier for IPA optimizations (in the case they do not have a gimple
> body).  We could represent variadic thunks in gimple using
> __builtin_va_arg_pack

Well, we could also go for the "half way" variant. Represent those thunks we
can and handle those thunks we can't as special cases. Problem of this is
  1) real thunks will become even more weird and rare special case (I think
     we have two testcases for variadic thunks in testsuite)
  2) we will need to forbid certain class of transformations of boides or the
     plan to throw them away won't work.

     We don't want to change function signatures, for example, we don't want
     to remove THIS parameter because we prove it is dead. 
     Things, like cloning, will most likely have tendency to upset ASM
     machinery in particular on exotic targets.
It seems to me that we would replace one ugly case of thunks, but two classes
of more evil thunks and less evil thunks.

> Similar to aliases (which, of course, also has ugly current handling).

Yes, aliases and thunks are symmetric to large extend. Thus my plan to handle

> So, indeed it sort-of makes sense to do symtab related changes first to
> get aliases implemented in a sane way.  As thunks really need similar
> handling in a lot of places.

Yep, or go the other way - first get thunks working and then make aliases on
top of them.  Aliases are more difficult than thunks by
  1) they can have different visibilities than the symbol they alias
  2) there is problem with fact that we don't know symbol names
  3) they have target specific behavior. I.e. ELF has no aliases in end, but
     some targets do. 
So one way or another, the conversion is not fun ;(

Honza