On 6/24/19 4:52 AM, Paolo Carlini wrote:
Hi,
On 23/06/19 19:45, Jason Merrill wrote:
On 6/23/19 7:53 AM, Paolo Carlini wrote:
... hi again ;)
The other day I was having a look at using declarations for this
issue and noticed that only a few lines below the de-virtualization
check we have to handle functions found by a using declaration, for
various reasons. In particular, we know whether we found a function
fn where has been declared or in a derived class. Thus the idea: for
the purpose of making some progress, in particular all the cases in
c++/67184 & co, would it make sense for the time being to simply add
a check to the de-virtualization condition restricting it to
non-using declarations? See the below (it also moves the conditional
a few lines below only for clarity and consistency with the code
handling using declarations, no functional impact) What do you think?
Hmm, perhaps we should check CLASSTYPE_FINAL in
resolves_to_fixed_type_p rather than in build_over_call at all; then
the code in build_new_method_call ought to set LOOKUP_NONVIRTUAL when
appropriate.
I think your suggestion has to do with the initial implementation of
this optimization, as contributed by my friend Roberto Agostino: we had
the issue that it didn't handle at all user-defined operators and
Vincenzo filed c++/53186. Thus, upon your suggestion, we moved the code
to build_over_call, the current place:
https://gcc.gnu.org/ml/gcc-patches/2012-05/msg00246.html
where it catched both member functions and operators. Now - before we
get to the details - if I move the CLASSTYPE_FINAL check to
resolves_to_fixed_type_p we exactly regress on c++/53186, that is
other/final2.C, because resolves_to_fixed_type_p is *never* called. The
pending final4.C, also involving operators (I constructed it exactly
because I knew operators could be tricky) is also not fixed, but in that
case at least resolves_to_fixed_type_p *is* called, only, too late (I
think, I more details later, if you like).
Ah, thanks. Then perhaps we want to change the CLASSTYPE_FINAL in
build_over_call to resolves_to_fixed_type_p (arg), to also handle the
other reasons we might know the dynamic type of the argument, and remove
the related code from build_new_method_call_1?
You could avoid needing to move the conditional lower by comparing
DECL_CONTEXT (fn) and BINFO_TYPE (cand->conversion_path) rather than
parmtype and TREE_TYPE (converted_arg).
Jason
