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 )
