[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


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

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