[Bug c++/13986] New: [3.4/3.5 regression] Unnecessary check for copy constructor

["bangerth at dealii dot org" <gcc-bugzilla at gcc dot gnu dot org>]

This is probably a tricky point: take this example 
---------------------- 
class X { 
    X (const X&); 
  public: 
    X (); 
}; 
 
class Y : public X { 
  public: 
    Y (); 
}; 
 
void f(const X&); 
 
int main () { 
  f(Y()); 
} 
----------------- 
then I understand that calling f() with a temporary requires 
the copy constructor of Y to be available, even if it is not 
used since the copy is elided. In this case, it is actually 
available (since automatically synthetized), so that's fine.  
The point is that the copy constructor 
of the base class is not. Does it matter? If the copy constructor 
is not actually used (it isn't indeed, in this case), then are 
we supposed to check for the accessibility of X::X(const X&)? 
 
Previous versions of gcc didn't, but present mainline and 3.4 
branch do so, yielding these error messages: 
g/x> /home/bangerth/bin/gcc-3.3.3-pre/bin/c++ -c x.cc 
 
g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c x.cc 
x.cc: In copy constructor `Y::Y(const Y&)': 
x.cc:2: error: `X::X(const X&)' is private 
x.cc:15: error: within this context 
 
g/x> /home/bangerth/bin/gcc-3.5-pre/bin/c++ -c x.cc 
x.cc: In copy constructor `Y::Y(const Y&)': 
x.cc:2: error: `X::X(const X&)' is private 
x.cc:15: error: within this context 
 
On the other hand, for example icc accepts the code even in strict 
mode. I claim that we should, too. 
 
W.

-- 
           Summary: [3.4/3.5 regression] Unnecessary check for copy
                    constructor
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bangerth at dealii dot org
                CC: gcc-bugs at gcc dot gnu dot org


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