Is G++ 5.1's `-Wctor-dtor-privacy` warning broken?

Question

The ctor-dtor-privacy warning is intended to be triggered when all constructors and destructors are private.

So for the following class, I would expect warning to trigger:

struct foo
{
  public:
    static int test(void) { return 3; };
  private:
    foo(void) {}
};

But neither clang++ (version clang 3.7.0 (trunk 238948)) nor GCC 5.1.0 issues a warning for this code when using -Wctor-dtor-privacy. This seems suspicious, but warnings aren't perfect, so some false negatives are to be expected, I suppose. (Perhaps the warning doesn't get triggered because the copy and move constructors are still implicitly defined, so technically not all constructors are private--even though the class still can't be constructed.)

However, this code does get a warning:

struct foo
{
  private:
    static int test(void) { return 3; };
  // private:
  //   foo(void) {}
};

Here, test is made private and the explicit constructor is removed so that foo's constructor is implicitly defined. G++ gives the following warning:

 warning: all member functions in class ‘foo’ are private [-Wctor-dtor-privacy]

clang++ gives no warning.

This warning certainly seems incorrect, since there is an implicit public constructor. What's going on here? Is this a bug?

EDIT: It seems that perhaps Clang++ doesn't ever issue a warning. Even the following class does not trigger any warnings with -Wctor-dtor-privacy:

class ReallyTrulyPrivateOnly
{
  private:
    ReallyTrulyPrivateOnly(void) =default;
    ReallyTrulyPrivateOnly(ReallyTrulyPrivateOnly&&) =default;
    ReallyTrulyPrivateOnly(const ReallyTrulyPrivateOnly&) =default;
  public:
    void foo(void) {}
};

So perhaps this warning is simply provided for G++ command-line compatibility, but actually does nothing? (Note that this class generates a quite sensible warning with GCC: warning: ‘class ReallyTrulyPrivateOnly’ only defines private constructors and has no friends [-Wctor-dtor-privacy])

EDIT 2: I believe the behavior of this warning is not well understood or documented, and that this issue was noticed and reported in bug 55813. This was marked "fixed" in release 4.8, but since the behavior still seems suspect to me, I've added a comment pointing back to this question.

EDIT 3: The bug in the above edit is not the same issue; I have opened a new bug report (71484) for this issue.