Ping...
---------------------------------------- > From: bernd.edlin...@hotmail.de > To: gcc-patches@gcc.gnu.org > CC: richard.guent...@gmail.com; hubi...@ucw.cz > Subject: RE: [PING**2] [PATCH] Fix PR ipa/61190, 2nd edition > Date: Mon, 27 Oct 2014 09:23:41 +0100 > > > Ping again... > > Thanks. > > ---------------------------------------- >> From: bernd.edlin...@hotmail.de >> To: hubi...@ucw.cz >> CC: gcc-patches@gcc.gnu.org; richard.guent...@gmail.com >> Subject: [PING] [PATCH] Fix PR ipa/61190, 2nd edition >> Date: Tue, 14 Oct 2014 11:40:56 +0200 >> >> Ping... >> >> see: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00536.html >> >>> Hi Honza, >>> >>> >>> as you know, we have a wrong code bug, when a pure or const method is >>> called via a virtual thunk. >>> I had some more Ideas, how to fix that, but all of them had some serious >>> draw-backs, so I leave the details out... >>> >>> >>> But now I have a new insight, why the "obvious" fix for this serious code >>> generation bug did not work >>> in the first place. >>> >>> >>> And the reason was, that if ipa-pure-const.c calls set_const_flag or >>> set_pure_flag for a thunk, it calls the same >>> function later for the called method, and this overwrites the flags of >>> _all_ associated thunks and aliases. >>> However that should at least not be done for virtual thunks, as these need >>> to be IPA_NEITHER, even if >>> the method itself has different attributes, that is because the assembler >>> thunk accesses the vtable, while >>> other thunks do not. >>> >>> >>> So I re-factored set_const_flag and set_pure_flag to exclude the virtual >>> thunks, taking care that other >>> users of call_for_symbol_thunks_and_aliases do not get a different behavior >>> than before this patch. >>> >>> >>> The attached patch was boot-strapped and >>> regression-tested on x86_64-linux-gnu. >>> Ok for trunk? >>> >>> >>> PS: As a side-note, there are two identical functions, named >>> "call_for_symbol_and_aliases", in >>> class symtab_node and in class cgraph_node, which inherits from >>> symtab_node. Both functions are >>> not declared virtual. Is that what's intended? Usually this could lead to >>> errors, or at least some serious >>> compiler warnings. >>> >>> >>> Thanks >>> Bernd. >>> >> >
