I was able to work around this problem in two ways, as I mentioned
on the cfe-dev mailing list for LLVM: http://lists.llvm.org/pipermail/cfe-dev/2015-October/045336.html

(1)  Patch Module.cpp to move "struct Visitor" outside of VisibleModuleSet::setVisible()

OR

(2)  Add -fpermissive to command-line


clang can compile this with no problem, so I am filing the bug here.

Why do you use LLVM's libc++? This is not supported in any way.
So please use gcc's libstdc++ instead.

This is for cross-compiling the FreeBSD base system with GCC.
The FreeBSD base system has libc++, which was recently upgraded to clang 3.7.0.

Cross-compiling FreeBSD base system with GCC worked before,
with an older version of libc++.

Discussion on the llvm cfe-dev mailing list seems to point to this
being a bug in GCC, hence I filed this bug.

Reduced:

namespace std {

template <class _Tp> struct  remove_reference {typedef _Tp type;};
template <class _Tp> struct  remove_reference<_Tp&> {typedef _Tp type;};
template <class _Tp> struct  remove_reference<_Tp&&> {typedef _Tp type;};

template <class _Tp>
inline
_Tp&&
forward(typename std::remove_reference<_Tp>::type& __t) throw()
{
    return static_cast<_Tp&&>(__t);
}

template <class _Tp>
inline
_Tp&&
forward(typename std::remove_reference<_Tp>::type&& __t) throw()
{
    return static_cast<_Tp&&>(__t);
}

template<class _Fp> class function;

namespace __function
{

template<class _Fp> class __base;

template<class _Rp, class ..._ArgTypes>
class __base<_Rp(_ArgTypes...)>
{
public:
    virtual _Rp operator()(_ArgTypes&& ...) = 0;
};

template<class _FD, class _Alloc, class _FB> class __func;

template<class _Fp, class _Alloc, class _Rp, class ..._ArgTypes>
class __func<_Fp, _Alloc, _Rp(_ArgTypes...)>
    : public __base<_Rp(_ArgTypes...)>
{
public:
    virtual _Rp operator()(_ArgTypes&& ... __arg);
};



template<class _Fp, class _Alloc, class _Rp, class ..._ArgTypes>
_Rp
__func<_Fp, _Alloc, _Rp(_ArgTypes...)>::operator()(_ArgTypes&& ... __arg)
{
    return {};
}
}

template<class _Rp, class ..._ArgTypes>
class function<_Rp(_ArgTypes...)>
{
    typedef __function::__base<_Rp(_ArgTypes...)> __base;
    __base* __f_;

public:

    template<class _Fp>
      function(_Fp);

    _Rp operator()(_ArgTypes...) const;
};


template<class _Rp, class ..._ArgTypes>
template <class _Fp>
function<_Rp(_ArgTypes...)>::function(_Fp)
    : __f_(0)
{
}


template<class _Rp, class ..._ArgTypes>
_Rp
function<_Rp(_ArgTypes...)>::operator()(_ArgTypes... __arg) const
{
    return (*__f_)(std::forward<_ArgTypes>(__arg)...);
}

}

void setVisible()
{
  struct Visiting { };

  std::function<void(Visiting)> VisitModule { [&](Visiting) { } };
  VisitModule({});
}



Fails with 4.9 and 5.2:

mod.ii:34:17: error: ‘_Rp std::__function::__base<_Rp(_ArgTypes ...)>::operator()(_ArgTypes&& ...) [with _Rp = void; _ArgTypes = {setVisible()::Visiting}]’, declared using local type ‘setVisible()::Visiting’, is used but never defined [-fpermissive]
     virtual _Rp operator()(_ArgTypes&& ...) = 0;
                 ^

Compiles OK with trunk.

I don't know what fixed it, or if it's worth backporting.

This appears to have been fixed with https://gcc.gnu.org/viewcvs?rev=224492&root=gcc&view=rev by Paolo Carlini, see also bug 51048.  It seems to look easy enough to backport to earlier branchs.  Paolo, can you please confirm?

I have no objections, the patch seems safe to backport. Jason, shall I go ahead if it regtests Ok on the branch?

(In reply to Paolo Carlini from comment #7)
> I have no objections, the patch seems safe to backport. Jason, shall I go
> ahead if it regtests Ok on the branch?

Sure.

Done. I'm resolving this one as Dup of c++/51048.

*** This bug has been marked as a duplicate of bug 51048 ***