[llvm-bugs] [Bug 35076] std::is_pod weirdly affected by volatile
via llvm-bugs
llvm-bugs at lists.llvm.org
Fri Oct 27 15:24:55 PDT 2017
https://bugs.llvm.org/show_bug.cgi?id=35076
Richard Smith <richard-llvm at metafoo.co.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
CC| |richard-llvm at metafoo.co.uk
--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> ---
Clang's result is correct. "is_pod" determines whether a type is a C++11 POD
type, which means trivial and standard layout. Triviality requires that the
type be trivially-copyable. Trivial copyability requires
"each copy constructor, move constructor, copy assignment operator, and move
assignment operator (15.8, 16.5.3) is either deleted or trivial, [and]
[the class] has at least one non-deleted copy constructor, move constructor,
copy assignment operator, or move assignment operator"
But all of MyTimeDate's copy/move constructors/assignment operators are
deleted, because mytime_t has no copy/move constructor/assignment that can take
a 'volatile mytime_t&' or 'volatile mytime_t&&'.
So the first MyTimeDate is not copyable at all, so it is not
trivially-copyable, so is not trivial, so is not POD. GCC knows that it's not
copyable, but appears to not realize that this means it's not
trivially-copyable.
In the second case, copying the volatile int64_t member within the copy/move
constructor/assignment operator of mytime_t is valid, and MyTimeDate ends up
being trivially copyable and, ultimately, POD.
So this is a GCC bug.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171027/9597eb74/attachment.html>
More information about the llvm-bugs
mailing list