For the record, some package authors whose packages depend on RcppParallel have had their new submissions accepted to CRAN, so I suppose part of the answer is "explain it to the maintainers and they'll understand".
However, a response from the CRAN team regarding how I should handle these warnings emitted myself from TBB would still be appreciated (for myself and other package authors who might want to embed 3rd party code in their packages). Thanks, Kevin On Thu, Jan 18, 2018 at 11:19 AM, Kevin Ushey <kevinus...@gmail.com> wrote: > > 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/603d1aa6f340668e34f5f490438967489edc9197/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/603d1aa6f340668e34f5f490438967489edc9197/inst/include/tbb/flow_graph_opencl_node.h#L1234-L1252 > > https://github.com/RcppCore/RcppParallel/blob/603d1aa6f340668e34f5f490438967489edc9197/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 ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
