My two cents,
- while the standard might not guarantee proper mapping for non trivially copyable types, we should determine under which condition we can guarantee the expected behaviour and not issue a warning expect we have to. The warning should then inform the user why we couldn’t and how it can be resolved.
Could anyone open a bug for this as well?
- atomics should “work”. I’ll look into this with the caveat that the performance is hardware dependent. as Alexey mentioned, if the hardware doesn’t provide direct support we’ll need to emulate them which might be even more costly. Nevertheless, it should work and not error out.
My key point is: Is the mapping of the type in question"working" or not? If not, it should be an error, if it is working, no warning, only if we don’t know, it should be a warning.
I think we talk past each other. Let me try to rephrase.
Even if a type is not trivially copyable, as defined by the standard, we can determine sufficient conditions under which the mapping will happen as expected by a reasonable user. That said, we need to define these conditions. Does this make sense?
That’d be extremely helpful for C++ application developers.
No error please, except if we know something will break. I’ll write up a proposal with more detail tomorrow (hopefully).
I think checkTypeMappable() in lib/Sema/SemaOpenMP.cpp currently checks QualType::isTrivialType(). This implies QualType::isTriviallyCopyableType(), but it additionally also requires a default constructor and no non-trivial default constructor.
Do we actually need guarantees on the default constructors? Please note that “trivially copyable” requires a trivial destructor, so this should be fine from that perspective.
For example, consider attached class T which is trivially copyable (see static_assert). Clang warns because T::T() is non-trivial, but I don’t see how this affects the mapping (which is eventually just memcpy’ing the int member).
map.cpp (274 Bytes)