[Bug c++/28901] New: unable to resolve function overloads involving inheritance

[Bug c++/28901] New: unable to resolve function overloads involving inheritance

[msebor at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28901

            Bug ID: 28901
           Summary: unable to resolve function overloads involving
                    inheritance
           Product: gdb
           Version: 11.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
          Assignee: unassigned at sourceware dot org
          Reporter: msebor at gmail dot com
  Target Milestone: ---

The following test case shows that GDB 11.1 is unable to perform basic overload
resolution involving derivation.  This limitation prevents, for example,
calling output functions when debugging LLVM.  The LLVM debugger, lldb, handles
this without a problem.

I'm using GNU gdb (GDB) Fedora 11.1-5.fc35.

$ cat t.C && g++ -g3 t.C && gdb -batch -nx -ex "break main" -ex run -ex "print
f (x, b)" a.out 
struct A { };
struct B: A { };

struct X { };
struct Z { };

void f (X&, A&) { }
void f (Z&, B&) { }

B b;
X x;

int main ()
{
  f (x, b);
}

Breakpoint 1 at 0x401128: file t.C, line 15.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, main () at t.C:15
15        f (x, b);
Cannot resolve function f to any overloaded instance

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/28901] unable to resolve function overloads involving inheritance

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28901

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org
   Last reconfirmed|                            |2022-02-18
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
gdb uses a relaxed set of rules for user convenience, but
in this case what happens is that this leads gdb into thinking
that these two overloads are incomparable, whereas in reality
one of them ought to be rejected.

I think a possible fix is for 'compare_badness' to declare a
winner in the case where one badness vector has an invalid
component and one does not.

That's pretty easy to do, but what isn't clear to me is if we
need finer-grained decisions about the kinds of laxity gdb applies.
Probably overthinking it though.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/28901] unable to resolve function overloads involving inheritance

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28901

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |tromey at sourceware dot org

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
https://sourceware.org/pipermail/gdb-patches/2022-February/186002.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/28901] unable to resolve function overloads involving inheritance

[msebor at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28901

--- Comment #3 from Martin Sebor <msebor at gmail dot com> ---
Thanks for the quick patch!  I can confirm it fixes the test case I submitted
but it doesn't seem to help with the LLVM use case.  I still get the same error
-- see below.  Let me see if I can reduce it to a test case.

Breakpoint 1, llvm::LibCallSimplifier::optimizeStrLen (this=0x7fffffff6898,
CI=0x986a2a0, B=...) at
/src/llvm/llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp:726
726       if (Value *V = optimizeStringLength(CI, B, 8))
(gdb) p CI
$1 = (llvm::CallInst *) 0x986a2a0
(gdb) p errs()
$2 = (llvm::raw_fd_ostream &) @0x979fe40: {<llvm::raw_pwrite_stream> =
{<llvm::raw_ostream> = {
  ...
(gdb) p (llvm::Value*)CI
$3 = (llvm::Value *) 0x986a2a0
(gdb) p *$3
$4 = {VTy = 0x9862c00, UseList = 0x986a350, SubclassID = 83 'S', 
  ...
(gdb) p $3->print($2, false) 
Cannot resolve method llvm::Value::print to any overloaded instance

(gdb) ptype $3
type = class llvm::Value {
  ...
  public:
    llvm::Value & operator=(const llvm::Value &);
    void deleteValue(void);
    void dump(void) const;
    void print(llvm::raw_ostream &, bool) const;
    void print(llvm::raw_ostream &, llvm::ModuleSlotTracker &, bool) const;
    void printAsOperand(llvm::raw_ostream &, bool, 
    ...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/28901] unable to resolve function overloads involving inheritance

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28901

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
Can you "set debug overload 1" and paste the output from that?
It might be informative.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/28901] unable to resolve function overloads involving inheritance

[msebor at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28901

--- Comment #5 from Martin Sebor <msebor at gmail dot com> ---
Here you go:

(gdb) p (llvm::Value*)CI
$1 = (llvm::Value *) 0x986a2a0
(gdb) p errs()                  
Overloaded function instance llvm::errs() # of parms 0
...Badness of length : {0, 0}
Overload resolution champion is 0, ambiguous? 0
$2 = (llvm::raw_fd_ostream &) @0x979fbc0: {<llvm::raw_pwrite_stream> =
{<llvm::raw_ostream> = {
      _vptr$raw_ostream = 0x96d2698 <vtable for llvm::raw_fd_ostream+16>, 
      Kind = llvm::raw_ostream::OStreamKind::OK_OStream, OutBufStart = 0x0, 
      OutBufEnd = 0x0, OutBufCur = 0x0, ColorEnabled = true, 
      TiedStream = 0x0, 
      BufferMode = llvm::raw_ostream::BufferKind::Unbuffered, 
      static BLACK = llvm::raw_ostream::Colors::BLACK, 
      static RED = llvm::raw_ostream::Colors::RED, 
      static GREEN = llvm::raw_ostream::Colors::GREEN, 
      static YELLOW = llvm::raw_ostream::Colors::YELLOW, 
      static BLUE = llvm::raw_ostream::Colors::BLUE, 
      static MAGENTA = llvm::raw_ostream::Colors::MAGENTA, 
      static CYAN = llvm::raw_ostream::Colors::CYAN, 
      static WHITE = llvm::raw_ostream::Colors::WHITE, 
      static SAVEDCOLOR = llvm::raw_ostream::Colors::SAVEDCOLOR, 
      static RESET = llvm::raw_ostream::Colors::RESET}, <No data fields>}, 
  FD = 2, ShouldClose = false, SupportsSeeking = false, 
  IsRegularFile = false, HasColors = {Storage = {{empty = 0 '\000', 
        value = false}, hasVal = false}}, EC = {_M_value = 0, 
    _M_cat = 0x7ffff7eb3160 <(anonymous namespace)::system_category_instance>}, 
  pos = 207}
(gdb) p $1->print($2, false)
Overloaded method instance llvm::Value::print(llvm::raw_ostream&, bool) const,
# of parms 3
...Badness of length : {0, 0}
...Badness of arg 1 : {1, 1}
...Badness of arg 2 : {100, 0}
...Badness of arg 3 : {0, 0}
Overload resolution champion is 0, ambiguous? 0
Overloaded method instance llvm::Value::print(llvm::raw_ostream&,
llvm::ModuleSlotTracker&, bool) const, # of parms 4
...Badness of length : {100, 0}
...Badness of arg 1 : {1, 1}
...Badness of arg 2 : {100, 0}
...Badness of arg 3 : {100, 0}
Overload resolution champion is 0, ambiguous? 0
Cannot resolve method llvm::Value::print to any overloaded instance

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/28901] unable to resolve function overloads involving inheritance

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28901

--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
> Overloaded method instance llvm::Value::print(llvm::raw_ostream&, bool) const, # of parms 3
> ...Badness of length : {0, 0}
> ...Badness of arg 1 : {1, 1}
> ...Badness of arg 2 : {100, 0}

This means it thinks $2 isn't an llvm::raw_ostream, which seems weird,
because it sure looks like it is derived from that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/28901] unable to resolve function overloads involving inheritance

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28901

--- Comment #7 from Tom Tromey <tromey at sourceware dot org> ---
If you feel like debugging gdb, I think what you'd want to do
is set a breakpoint in distance_to_ancestor and see why it is
failing.

If not ... some kind of reproducer would be good.  I tried
a few tweaks to the simple test program you gave, but couldn't
reproduce this new failure.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/28901] unable to resolve function overloads involving inheritance

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28901

--- Comment #8 from Tom Tromey <tromey at sourceware dot org> ---
I'm going to check in the patch, but not close this bug, pending
a reproducer for the second issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/28901] unable to resolve function overloads involving inheritance

[msebor at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28901

--- Comment #9 from Martin Sebor <msebor at gmail dot com> ---
Please go ahead.  I will see if I can come up with a reproducer for the bigger
issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/28901] unable to resolve function overloads involving inheritance

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28901

--- Comment #10 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ac03c8d8fd6cf7f9080068589683cb06531879c2

commit ac03c8d8fd6cf7f9080068589683cb06531879c2
Author: Tom Tromey <tromey@adacore.com>
Date:   Fri Feb 18 14:03:03 2022 -0700

    Fix bug in C++ overload resolution

    PR c++/28901 points out a bug in C++ overload resolution.  When
    comparing two overloads, one might be better than the other for
    certain parameters -- but, if that one also has some invalid
    conversion, then it should never be considered the better choice.
    Instead, a valid-but-not-apparently-quite-as-good overload should be
    preferred.

    This patch fixes this problem by changing how overload comparisons are
    done.  I don't believe it should affect any currently valid overload
    resolution; nor should it affect resolutions where all the choices are
    equally invalid.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/28901] unable to resolve function overloads involving inheritance

[msebor at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28901

--- Comment #11 from Martin Sebor <msebor at gmail dot com> ---
I'm not having any luck isolating the problem from LLVM to a standalone test
case.  I can't even recreate it within LLVM if I replace llvm::raw_ostream with
an exact copy of it (llvm::xxx_raw_ostream).  There's something about
llvm::raw_ostream that GDB doesn't like.

With a copy of raw_ostream called xraw_ostream and the code below in
SimplifyLibCalls.cpp:

struct Foo
{
  void foo(xxx_raw_ostream &);
  void foo(xxx_raw_ostream &, int);

  void bar(raw_ostream &);
  void bar(raw_ostream &, int);
};

void Foo::foo(xxx_raw_ostream &) { }
void Foo::foo(xxx_raw_ostream &, int) { }

void Foo::bar(raw_ostream &) { }
void Foo::bar(raw_ostream &, int) { }

GDB can resolve the call pfoo->foo (xr) but not pfoo->bar (r) (with pfoo being
a pointer to Foo, xr a reference to xxx_raw_ostream, and r a reference to
raw_ostream).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/28901] unable to resolve function overloads involving inheritance

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28901

--- Comment #12 from Tom Tromey <tromey at sourceware dot org> ---
One option, if you have a debuggable gdb, is to debug it,
break in types_equal, and find out why the two types
in question aren't considered equal.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/28901] unable to resolve function overloads involving inheritance

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28901

--- Comment #13 from Tom Tromey <tromey at sourceware dot org> ---
I wonder if this could possibly be related to
https://sourceware.org/pipermail/gdb-patches/2022-November/193405.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/28901] unable to resolve function overloads involving inheritance

[blarsen at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28901

B. Larsen <blarsen at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |blarsen at redhat dot com

--- Comment #14 from B. Larsen <blarsen at redhat dot com> ---
I'm not sure it is related. I'm not sure, but I think even if the type is
exactly the same, GDB can resolve even if it is incomplete. A way to test would
be installing glibc debuginfo and testing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.