[Bug c++/59426] New: __has_trivial_{copy/assign} behavior differs from documentation

["temporal at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 59426
           Summary: __has_trivial_{copy/assign} behavior differs from
                    documentation
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: temporal at gmail dot com

Consider this struct with deleted copy/assignment:

struct S {
  S(const S&) = delete;
  S& operator=(const S&) = delete;
};

GCC's __has_trivial_{copy,assign}() intrinsics return false for this type. 
This is a useful answer, but appears to disagree with the documentation:

http://gcc.gnu.org/onlinedocs/gcc/Type-Traits.html

"__has_trivial_copy(type): If __is_pod (type) is true or type is a reference
type then the trait is true, else if type is a cv class or union type with a
trivial copy constructor ([class.copy]) then the trait is true, else it is
false. Requires: type shall be a complete type, (possibly cv-qualified) void,
or an array of unknown bound."

Technically, according to [class.copy], a deleted copy constructor is "trivial"
(because it is not user-provided, and none of the other exceptions apply).  A
similar argument applies to assignment.  Clang has chosen to implement these
intrinsics according to the docs rather than according to GCC's actual
behavior, and thus both return true for S.  To avoid confusion, GCC should
update either its documentation or its implementation so that the two match.

Apparently, other compilers (Embarcadero, MSVC) implement these intrinsics as
well.  I do not have access to them to test their behavior in this case.

(I originally filed a bug against Clang: 
http://llvm.org/bugs/show_bug.cgi?id=18185 )