Hi, This is mostly a question for the CRAN team, but I figured posting here would be best since other package maintainers could see the responses as well.
I'm currently in the process of preparing a submission of RcppParallel to CRAN. RcppParallel bundles Intel's Threading Building Blocks (https://www. threadingbuildingblocks.org/) and builds + installs it alongside the package. However, the TBB sources themselves do a lot of things that trip up R CMD check + versions of R compiled with sanitizers, which are mostly out of my control. For example, some UBSAN errors are emitted here: https://www.stats.ox.ac.uk/pub/bdr/memtests/clang-UBSAN/ RcppParallel/tests/doRUnit.Rout Executing test function test.distance ... /data/gannet/ripley/R/ packages/tests-clang-SAN/RcppParallel.Rcheck/RcppParallel/include/tbb/task.h:721:30: runtime error: member call on address 0x7fbf31e93d00 which does not point to an object of type 'tbb::internal::scheduler' 0x7fbf31e93d00: note: object is of type 'tbb::internal::custom_ scheduler<tbb::internal::IntelSchedulerTraits>' 00 00 00 00 a8 ab 76 32 bf 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 ff c9 31 ^~~~~~~~~~~~~~~~~~~~~~~ vptr for 'tbb::internal::custom_scheduler<tbb::internal:: IntelSchedulerTraits>' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /data/gannet/ripley/R/packages/tests-clang-SAN/RcppParallel.Rcheck/ RcppParallel/include/tbb/task.h:721:30 in This occurs, as far as I can tell, because TBB sidesteps typical C++ object construction for some objects: instead, it allocates some memory, then casts it to some required type. As an example, https://github.com/RcppCore/RcppParallel/blob/603d1aa6f340668e34f5f490438967 489edc9197/src/tbb/src/tbb/scheduler.cpp#L322-L328 While this is 'wrong', it also 'works'. What am I, as a package maintainer, supposed to do in this situation? To make things worse, this UBSAN warning unfortunately affects all client packages of RcppParallel as well, as this warning is triggered by code ran by RcppParallel on load / startup. Do other package maintainers just need to say, "sorry, that's RcppParallel's fault"? In addition, TBB itself suppresses a number of compiler diagnostics deliberately -- for example, https://github.com/RcppCore/RcppParallel/blob/603d1aa6f340668e34f5f490438967 489edc9197/inst/include/tbb/flow_graph_opencl_node.h#L1234-L1252 https://github.com/RcppCore/RcppParallel/blob/603d1aa6f340668e34f5f490438967 489edc9197/src/tbb/include/tbb/tbb_machine.h#L666-L674 Presumedly, TBB does this because they know what they're doing and the compiler diagnostic will not be useful within this region of code. However, this also triggers R CMD check warnings. What should I do here -- just explain the case to CRAN? Patch TBB to allow the compiler diagnostics to flow through? The more general question here -- what should package authors do when third-party code bundled in the package emits compiler warnings? Thanks, Kevin [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel