Hi Honza, On Mon, 2 Jun 2014 18:12:10, Jan Hubicka wrote: > >> Hi, >> >> On Mon, 2 Jun 2014 12:06:12, Richard Biener wrote: >>> >>> On Mon, Jun 2, 2014 at 11:00 AM, Bernd Edlinger >>> <bernd.edlin...@hotmail.de> wrote: >>>> Hi, >>>> >>>> the test case g++.old-deja/g++.mike/p4736b.C is mis-compiled with with all >>>> optimization levels, except -O0 and -Og. This probably started with gcc >>>> 4.7.x. >>>> >>>> The constructor Main::Main() is first inlined and then completely optimized >>>> away in the dce1 pass. But the thunk is still using the vtable, and >>>> therefore >>>> crashes. > > Why the ctor is eliminated? Is it because ipa-pure-const identifies the thunk > as const? > I think we need to update it to notice the read of vtable in those thunks. I > will > take a look. >
have you been able to find an alternative solution yet? Thanks Bernd. > Honza >>>> >>>> Well, the problem seems to be, that the thunk code is >>>> not emitted in the normal way using gimple code, >>>> but instead by the i386 back-end with a callback. >>>> >>>> This makes the thunk invisible to the ipa-pure-const pass, >>>> which assumes that all values just flow straight thu the thunk. >>>> >>>> See ipa-pure-const.c (analyze_function): >>>> >>>> if (fn->thunk.thunk_p || fn->alias) >>>> { >>>> /* Thunk gets propagated through, so nothing interesting happens. */ >>>> gcc_assert (ipa); >>>> return l; >>>> } >>>> >>>> But this is not true for a virtual base class: >>>> The thunk itself references the vtable, so if nothing else might need >>>> the vtable, the optimizer may remove the initalization of the vtable, >>>> which happened in this example. >>>> >>>> The most simple work around would be the attached patch, which >>>> simply falls back to emitting gimple code, if virtual base classes >>>> are used. >>>> >>>> Boot-Strapped and Regression-Tested on x86_64-linux-gnu. >>>> Ok for trunk? >>> >>> Honza should know better. I'd rather skip the above for >>> thunks going the output_mi_thunk way. >>> >> >> Ahh Yes, that was of course my first attempt... >> >> But there is not BB to enumerate in that case. >> And the loop below just crashed in: >> >> FOR_EACH_BB_FN (this_block, cfun) >> >> >> There is also another interesting thing to mention: when the >> output_mi_thunk outputs the virtual thunk, there is no inlining at all. >> >> But with this patch, the thunk inlines the called function, >> and therefore the generated code looks rather nifty, compared to >> the state before the patch. >> >> >> Thanks >> Bernd. >> >>> That is, the target hook docs should be updated to reflect which >>> kind of thunks it is supposed to handle. >>> >>> Richard. >>> >>>> >>>> Thanks >>>> Bernd. >>>> >>