Fix compilation error on gcc 9.1 #441
Conversation
error: ‘void* memcpy(void*, const void*, size_t)’ copying an object of type ‘class pxrInternal_v0_20__pxrReserved__::GfVec4f’ with ‘private’ member ‘pxrInternal_v0_20__pxrReserved__::GfVec4f::_data’ from an array of ‘const class pxrInternal_v0_20__pxrReserved__::GfVec3f’; use assignment or copy-initialization instead [-Werror=class-memaccess]
huidong-chen
added
do-not-merge-yet
| @@ -164,7 +164,8 @@ namespace { | |||
| } | |||
|
|
|||
| if (channelOffset == 0 && sizeof(DEST_TYPE) == sizeof(SRC_TYPE)) { | |||
| memcpy(vertexBuffer, primvarData.cdata(), sizeof(DEST_TYPE) * numVertices); | |||
| const void* source = static_cast<const void*>(primvarData.cdata()); | |||
There was a problem hiding this comment.
I'm not sure I understand this fix. Isn't the compiler error telling us that sizeof test somehow failed and we are using memcpy for not matching types?
There was a problem hiding this comment.
No. gcc 9.1 is only complaining about the type mismatch between source and destination of memcpy op. The memcpy function won't called if their types don't match, but this is run-time behavior that won't be taken into account at compile time.
There was a problem hiding this comment.
I may be missing something here and we would need to have a bit more information about which actual invocation of _FillPrimvarData is generating this error.
FWIW. There is one possibility where we will have a destination as Vec4f and source as Vec3f when filling color with alpha buffer. In this case, we should never enter the memcpy section...and the error should never be generated.
There was a problem hiding this comment.
Indeed the invocation is from where the source is Vec3f and the destination is Vec4f. And we indeed don't enter the memcpy section at run time. But the compiler won't examine run-time code path at compile time, that is why it still generate the error.
The fix has been validated on gcc 9.1.
There was a problem hiding this comment.
One detail, sizeof is a constant expression, the compiler should know that it doesn't enter this condition. Maybe it's a bug in the compiler and this is why we never saw it before.
There was a problem hiding this comment.
I guess even if we had this memcpy call inside a if(false) clause the compiler would still generate this error. More because of compiler strictness, I am not sure if it is a bug.
There was a problem hiding this comment.
Looking at C++17 and what if const expression can do...you may be right that compiler won't help us here because of value dependency.
OK, you convinced me. Thx.
huidong-chen
removed
the
do-not-merge-yet
* HYDRA 411 - create Cpp test infrastructure and documentation * HYDRA 411 - remove unnecessary code changes * HYDRA 411 - fix linux and mac issue with dynamically loading plugin by modifying rpath * HYDRA 411 - removed unused imports, fixed readme * HYDRA 411-remove cppFramework directory * HYDRA 411 - remove unused variable
This commit is to fix the following compilation error with gcc 9.1:
‘void* memcpy(void*, const void*, size_t)’ copying an object
of type ‘class pxrInternal_v0_20__pxrReserved__::GfVec4f’ with
‘private’ member ‘pxrInternal_v0_20__pxrReserved__::GfVec4f::data’
from an array of ‘const class pxrInternal_v0_20__pxrReserved_::GfVec3f’;
use assignment or copy-initialization instead [-Werror=class-memaccess]