Implement CWG496, volatile qualified types are not trivially copyable, special copy/move member functions are not trivial for classes with volatile qualified non-static data members. Fixes PR21070. Breaks CodeGenCXX/no-opt-volatile-memcpy.cpp, which specifically tests assignment for a struct with a volatile member resulting in memcpy.
Details
Diff Detail
Event Timeline
Any suggestions on what to do with the failing testcase (CodeGenCXX/no-opt-volatile-memcpy.cpp)? This test checks that the issued @llvm.memcpy has isvolatile=true, but after this patch memcpy is no longer issued as those operations are no longer considered trivial. This could suggest that memcpy with isvolatile=true should still be used in those cases (albeit the docs say "it is unwise to depend on it"), or that there is dead code out there looking for volatile members in trivial operations.
test/SemaCXX/type-traits.cpp | ||
---|---|---|
1863–1865 | I don't have commit rights, but I will take this out and prepare a new revision. |
Some possible approaches:
- update the tests to check that we don't memcpy in this case
- change FieldMemcpyizer (in CGClass) to allow volatile fields and create a volatile memcpy call
The test was added for PR9027, which is just trying to make sure we emit a volatile load/store in this case, and either approach satisfies its requirements, but checking for the absence of a memcpy seems like a somewhat better approach to me.
Addressed review comments. Added test for the newly introduced diagnostic.
CodeGenCXX/no-opt-volatile-memcpy.cpp still fails. I tried checking for the absence of @llvm.memcpy, but the non-volatile array member of the struct is still memcpy-ed (good!). I have little to no experience with codegen tests, let alone llvm ir, I could use some help to adjust the offending test case.
dr496: 3.7, please.