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

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

[temporal at gmail dot com]

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 )

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

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> ---
The documentation definitely needs updating. The builtins track the C++11
semantics.

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

[richard-gccbugzilla at metafoo dot co.uk]

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

Richard Smith <richard-gccbugzilla at metafoo dot co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |richard-gccbugzilla@metafoo
                   |                            |.co.uk

--- Comment #2 from Richard Smith <richard-gccbugzilla at metafoo dot co.uk> ---
Which C++11 semantics? Is __has_trivial_copy(T) intended to determine:
 1) if T has a trivial copy constructor, or
 2) whether T has a trivial copy constructor and no non-trivial copy
constructor, or
 3) whether the constructor selected to perform a copy from a 'const T' lvalue
would be trivial, or 
 4) the value of std::is_trivially_copyable<T>::value?

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

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Sorry, I spent too little time on my message. I meant to say that, *in
general*, our intrinsics (modulo bugs, of course) try to track the c++11
semantics of the corresponding C++11 type trait with the same name. In general
- maybe that's already clear, I don't know - we don't try to provide a separate
C++98 semantics when -std=c++98 is in effect. In the specific area at issue,
the various is_trivially_* would be the reference, but those are still
unimplemented. In my opinion we should simply deprecate the various
__has_trivial*, which by now are just legacy, too bad that internally they are
implemented in terms of functions which in turn changed over time, but frankly
I'm not sure there is much interest in "fixing" that, implementing correctly
the various is_trivially_* has a much higher priority. You may want to ask
other people, of course.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>:

https://gcc.gnu.org/g:83a21c993449a32b98916814ed8ca237b3276912

commit r12-7863-g83a21c993449a32b98916814ed8ca237b3276912
Author: Jason Merrill <jason@redhat.com>
Date:   Mon Mar 28 15:32:30 2022 -0400

    c++: Fix __has_trivial_* docs [PR59426]

    These have been misdocumented since C++98 POD was split into C++11 trivial
    and standard-layout in r149721.

            PR c++/59426

    gcc/ChangeLog:

            * doc/extend.texi: Refer to __is_trivial instead of __is_pod.

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

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
   Target Milestone|---                         |12.0
                 CC|                            |jason at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> ---
Fixed.