[Bug c++/13979] New: no matching function for call with derived class arguments

[Bug c++/13979] New: no matching function for call with derived class arguments

[bkramer at ciprico dot com]

When supplying a derived class as the argument to a function it cannot match the
signature.  This works under 3.2.2.

Reading specs from
/devel/new_compiler/engsrc/tools/linux/lib/gcc-lib/powerpc-wrs-vxworks/3.4.0/specs
Configured with: ../../src/gcc/configure --target=powerpc-wrs-vxworks
--prefix=/devel/gcc-vxworks --enable-languages=c,c++ --enable-thread=vxworks
--with-headers=/devel/Tornado/target/h --with-gnu-ld --with-gnu-as
--enable-altivec --enable-long-long
Thread model: vxworks
gcc version 3.4.0 20040130 (prerelease)
 /devel/new_compiler/engsrc/tools/linux/bin/../libexec/gcc/powerpc-wrs-vxworks/3.4.0/cc1plus -E -quiet -nostdinc -v -I/devel/new_compiler/engsrc/tools/Tornado/target/config/all -I/devel/new_compiler/engsrc/tools/Tornado/target/src/config -I/devel/new_compiler/engsrc/tools/Tornado/target/src/drv -I/devel/new_compiler/engsrc/tools/Tornado/target/h -I/devel/new_compiler/engsrc/tools/Tornado/target/h/c++/3.4.0-O2 -iprefix /devel/new_compiler/engsrc/tools/linux/bin/../lib/gcc/powerpc-wrs-vxworks/3.4.0/ -isystem /devel/new_compiler/engsrc/tools/linux/lib/gcc-lib/include -isystem /devel/new_compiler/engsrc/tools/linux/powerpc-wrs-vxworks/bin/include -DCPU_FAMILY=PPC -D__ppc -D__EABI__ -DCPU=PPC603 -D__hardfp -DVXWORKS -DROM_SIZE=0x00080000 -DRAM_LOW_ADRS=0x00010000 -DRAM_HIGH_ADRS=0x01000000 Test.cpp -mcpu=603 -mstrict-align -mstrict-align -Wall -fno-exceptions -fno-builtin -fno-exceptions -fworking-directory -o Test.ii
ignoring nonexistent directory
"/devel/new_compiler/engsrc/tools/linux/lib/gcc-lib/include"
ignoring nonexistent directory
"/devel/new_compiler/engsrc/tools/linux/powerpc-wrs-vxworks/bin/include"
ignoring nonexistent directory
"/devel/new_compiler/engsrc/tools/Tornado/target/h/c++/3.4.0-O2"
#include "..." search starts here:
#include <...> search starts here:
 /devel/new_compiler/engsrc/tools/Tornado/target/config/all
 /devel/new_compiler/engsrc/tools/Tornado/target/src/config
 /devel/new_compiler/engsrc/tools/Tornado/target/src/drv
 /devel/new_compiler/engsrc/tools/Tornado/target/h
End of search list.
 /devel/new_compiler/engsrc/tools/linux/bin/../libexec/gcc/powerpc-wrs-vxworks/3.4.0/cc1plus -fpreprocessed Test.ii -mcpu=603 -mstrict-align -quiet -dumpbase Test.cpp -mstrict-align -auxbase Test -g -gdwarf-2 -Wall -version -fno-exceptions -fno-builtin -fno-exceptions -o Test.s
GNU C++ version 3.4.0 20040130 (prerelease) (powerpc-wrs-vxworks)
        compiled by GNU C version 3.2.2 20030222 (Red Hat Linux 3.2.2-5).
GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=63140
Test.cpp: In function `void test()':
Test.cpp:117: error: no matching function for call to
`SCSI::Dispatcher::dispatch(SCSI::TaskId&, SCSI::TaskType&, SCSI::LunId&,
uint8*&, uint32&, Derived::DTaskData*&, Derived::Adapter&)'
Test.cpp:62: note: candidates are: SCSI::Dispatcher::Return
SCSI::Dispatcher::dispatch(const SCSI::TaskId&, const SCSI::TaskType&, const
SCSI::LunId&, const uint8*, const uint32&, SCSI::TaskData*&, SCSI::Adapter&)

-- 
           Summary: no matching function for call with derived class
                    arguments
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bkramer at ciprico dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-wrs-vxworks


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

[Bug c++/13979] no matching function for call with derived class arguments

[bkramer at ciprico dot com]

------- Additional Comments From bkramer at ciprico dot com  2004-02-02 14:51 -------
Created an attachment (id=5650)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=5650&action=view)
Preprocessed file


-- 


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

[Bug c++/13979] [3.3/3.4/3.5 Regression] no matching function for call with derived class arguments

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-02-02 15:05 -------
The code is invalid by two things, the first is that  Derived::Adapter does not  Derived from 
SCSI::Adapter and that you cannot pass a  Derived::DTaskData* in a SCSI::TaskData*&, it needs a 
temparay variable, yes the error message is misleading.
The error message is a regression from 2.95.3:
pr13979.cc: In function `void test()':
pr13979.cc:117: initializing non-const `SCSI::TaskData *&' with `Derived::DTaskData *' will use a 
temporary
pr13979.cc:61: in passing argument 6 of `SCSI::Dispatcher::dispatch(const TaskId &, const SCSI::
TaskType &, const LunId &, const uint8 *, const uint32 &, SCSI::TaskData *&, SCSI::Adapter &)'

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |diagnostic
      Known to work|                            |2.95.3
   Last reconfirmed|0000-00-00 00:00:00         |2004-02-02 15:05:37
               date|                            |
            Summary|no matching function for    |[3.3/3.4/3.5 Regression] no
                   |call with derived class     |matching function for call
                   |arguments                   |with derived class arguments
   Target Milestone|---                         |3.3.3


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

[Bug c++/13979] [3.3/3.4/3.5 Regression] no matching function for call with derived class arguments

[gdr at gcc dot gnu dot org]

------- Additional Comments From gdr at gcc dot gnu dot org  2004-02-15 12:45 -------
Adjust milestone

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.3.3                       |3.3.4


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

[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-02-15 21:59 -------
To the extent this is a regression (which is very mild), the best way to fix
this is, in my opinion, to make some changes tok our overall policies about
overload resolution and conversion.

In particular, we permit (with -fpermissive) certain invalid conversions (the
ones given by ptr_reasonably_similar).  The way our overload machinery works is
that when we see that a conversion is "reasonably similar" we allow the
conversion, but mark it as "bad", so that if we actually try to use it we will
issue a pedwarn.  If the pointer and reference conversions used in this example
were so marked, we would issue helpful error messages as the submitter requests.

However, if we did that, we would also allow these conversions with
-fpermissive, which would make -fpermissive even more permissive than it already is.

I think that we should change -fpermissive so that it is *less* permissive that
it currently is; in particular, we should not allow any bad conversions, even
with -fpermissive.  However, we should treat any pointer->pointer or
reference->reference conversion as "bad", and eliminate ptr_reasonably_similar.

(Actually, I'd be happy to eliminate -fpermissive altogether, but that's another
story.)

Jason, as the key force behind -fpermissive, what say you?

In any case, I'm going to move this test case into the enhancement category.  To
the extent it's a regression that comes from deliberate improvements in our
overloading code, and is not easily fixed without resolving the questions above.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at redhat dot com
           Severity|minor                       |enhancement
            Summary|[3.3/3.4/3.5 Regression] no |Error message about no
                   |matching function for call  |matching function for call
                   |with derived class arguments|with derived class arguments
                   |                            |could be improved
   Target Milestone|3.3.4                       |---


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

[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |16992
              nThis|                            |


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

[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2005-03-21 22:17 -------
Here's a small testcase: 
---------------- 
struct B {}; 
struct D : B {}; 
 
struct S { 
    int foo(B* & taskData); 
}; 
 
int i = S().foo((D*)0); 
----------------- 
 
We get these messages, the one for 2.95 being slightly more helpful: 
 
g/x> /home/bangerth/bin/gcc-4.0-pre/bin/c++ -c x.cc 
x.cc:8: error: no matching function for call to ?S::foo(D*)? 
x.cc:5: note: candidates are: int S::foo(B*&) 
 
g/x> /home/bangerth/bin/gcc-2.95.3/bin/c++ -c x.cc 
x.cc:8: initializing non-const `B *&' with `D *' will use a temporary 
x.cc:5: in passing argument 1 of `S::foo(B *&)' 
 
W. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.0.0


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

[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved

[manu at gcc dot gnu dot org]

------- Comment #6 from manu at gcc dot gnu dot org  2009-08-04 16:02 -------
This is still valid and it does not depend on -fpermissive. It would be
interesting to see what is the output from other C++ compilers.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2005-12-18 20:30:27         |2009-08-04 16:02:11
               date|                            |


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

[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved

[jwakely dot gcc at gmail dot com]

------- Comment #7 from jwakely dot gcc at gmail dot com  2009-08-04 17:48 -------
(In reply to comment #5)
> Here's a small testcase: 
> ---------------- 
> struct B {}; 
> struct D : B {}; 
>  
> struct S { 
>     int foo(B* & taskData); 
> }; 
>  
> int i = S().foo((D*)0); 
> ----------------- 

That tries to initialise a B*& with a D* rvalue, which would fail even if D was
the same type as B.  This might be a slightly better testcase:

struct B {}; 
struct D : B {}; 

struct S { 
    int foo(B* & taskData); 
}; 

D* p = 0;
int i = S().foo(p); 


It might be an improvement if GCC gave different diagnostics for the case where
a suitable conversion sequence exists but cannot be used because it would
create an rvalue which cannot bind to a non-const reference, and the case where
there is no suitable conversion (i.e. the types are unrelated)

That seems to be what 2.95 attempted to do by saying "initializing 'blah' with
'blah' will use a temporary" but I find that message confusing, as it *won't*
use a temporary because doing so is not valid.  The message should really have
been something like "initializing 'blah' with 'blah' would use a temporary, but
that's not allowed"


-- 

jwakely dot gcc at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwakely dot gcc at gmail dot
                   |                            |com


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

[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved

[manu at gcc dot gnu dot org]

------- Comment #8 from manu at gcc dot gnu dot org  2009-08-04 22:42 -------
(In reply to comment #7)
> 
> It might be an improvement if GCC gave different diagnostics for the case where
> a suitable conversion sequence exists but cannot be used because it would
> create an rvalue which cannot bind to a non-const reference, and the case where
> there is no suitable conversion (i.e. the types are unrelated)

I don't even know if we have different codepaths for those!


> That seems to be what 2.95 attempted to do by saying "initializing 'blah' with
> 'blah' will use a temporary" but I find that message confusing, as it *won't*
> use a temporary because doing so is not valid.  The message should really have
> been something like "initializing 'blah' with 'blah' would use a temporary, but
> that's not allowed"

Agreed. 


-- 


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

[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved

[jwakely dot gcc at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2586 bytes --]



------- Comment #9 from jwakely dot gcc at gmail dot com  2009-08-05 10:03 -------
This example has four slightly different errors:

struct B {}; 
struct D : B {}; 

struct X {};

int foo(B*&);

int i = foo( (B*)0 );

int j = foo( (D*)0 );

D* pd = 0;
int k = foo( pd );

X* px = 0;
int l = foo( px );

GCC 4.4.1 gives:

pr13979.cc:8:20: error: invalid initialization of non-const reference of type
‘B*&’ from a temporary of type ‘B*’
pr13979.cc:6:5: error: in passing argument 1 of ‘int foo(B*&)’
pr13979.cc:10:20: error: invalid initialization of non-const reference of type
‘B*&’ from a temporary of type ‘D*’
pr13979.cc:6:5: error: in passing argument 1 of ‘int foo(B*&)’
pr13979.cc:13:17: error: invalid initialization of reference of type ‘B*&’ from
expression of type ‘D*’
pr13979.cc:6:5: error: in passing argument 1 of ‘int foo(B*&)’
pr13979.cc:16:17: error: invalid initialization of reference of type ‘B*&’ from
expression of type ‘X*’
pr13979.cc:6:5: error: in passing argument 1 of ‘int foo(B*&)’

Comeau gives equivalent errors in all four cases. The only significant
difference is that Comeau doesn't mention the types in the first two errors.

GCC 2.95.2 is quite different:

pr13979.cc:8: initialization of non-const reference type `struct B *&'
pr13979.cc:8: from rvalue of type `B *'
pr13979.cc:6: in passing argument 1 of `foo(B *&)'
pr13979.cc:10: initializing non-const `B *&' with `D *' will use a temporary
pr13979.cc:6: in passing argument 1 of `foo(B *&)'
pr13979.cc:13: initializing non-const `B *&' with `D *' will use a temporary
pr13979.cc:6: in passing argument 1 of `foo(B *&)'
pr13979.cc:16: type `B' is not a base type for type `X'
pr13979.cc:6: in passing argument 1 of `foo(B *&)'

I think the current diagnostics are better than the 2.95 ones.  As I said
above, "will use a temporary" is misleading.  The fourth error saying "is not a
base type" may be true, but is also misleading, because it wouldn't compile
even if it was a base type.

As I said earlier, it might be nice if the third error said e.g.

pr13979.cc:13:17: error: invalid initialization of reference of type ‘B*&’ from
expression of type ‘D*’
pr13979.cc:6:5: error: in passing argument 1 of ‘int foo(B*&)’
pr13979.cc:13:17: note: conversion from `D*' to `B*' would create a temporary

However,

(In reply to comment #8)
> I don't even know if we have different codepaths for those!

if it's not possible then I think the current diagnostics are reasonable, and
at least as good as Comeau's.


-- 


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

[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved

[jason at redhat dot com]

------- Comment #10 from jason at redhat dot com  2009-08-05 13:42 -------
Subject: Re:  Error message about no matching function for
 call with derived class arguments could be improved

On 08/04/2009 06:42 PM, manu at gcc dot gnu dot org wrote:
> I don't even know if we have different codepaths for those!

We do: if there's a conversion that seems likely but invalid, we build 
it up but set bad_p on it so that we can give a more helpful diagnostic 
when we try to use it.

Jason


-- 


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