[R-pkg-devel] new package version fails on r-devel fedora clang

[Ivan Krylov]

В Tue, 7 Oct 2025 06:34:11 +0000
Tony Wilkes <tony_a_wilkes using outlook.com> пишет:

> I also don't know how to work around a bug in a compiler. How would
> you even do that?

For example, the SQLite developers have to do that every now and then:
https://sqlite.org/forum/forumpost/f0f921bb80b50959d50f5f560d42fef940ba9a78aa254703bb04cd680b261f11
https://sqlite.org/forum/forumpost/9626decbfa789f7c91ebdb66815f2e786b0195d6115dc145bfab5fcd5528ecf4

If the bug is reported to the compiler developers, sometimes it's
fixed, but that may take months (or years...), and the already released
versions of the compiler that still have the bug stay in use for much
longer: https://github.com/llvm/llvm-project/issues/70828

> If there is an issue in the compiler CRAN uses, it seems reasonable
> that CRAN fixes that.

Clang is programmed to print a message saying "PLEASE submit a bug
report" when it receives an unexpected fatal signal. Here, the fatal
signal is SIGXCPU, delivered by the kernel because of the 90-minute
per-process CPU time limit set for the job [0]. This is not a crash,
you can see this for yourself using something like

( ulimit -S -t 2; R -q -s -e 'repeat runif(100)' )

The bits of information we have are Ttotal=19394.68s [1], the R CMD
check output [2] saying that R CMD INSTALL tool 94 minutes of real time
but 323 minutes of userspace plus kernel CPU time, and 00install.log
saying that the processes being stopped for going over the limit are
compiling rcpp_bcRel_dec.cpp and rcpp_bc_int.cpp.

Using compilers from [3], it's possible to reproduce something similar
to but not as drastic as the problem visible on CRAN:

/usr/bin/time \
 ~/LLVM-21.1.2-Linux-X64/bin/clang++ -std=gnu++17 -I ~/R/include \
 -DNDEBUG  -I$HOME'/R/library/Rcpp/include' \
 -fpic  -O3 -Wall -pedantic -frtti -Wp,-D_FORTIFY_SOURCE=3 \
 -Wno-missing-template-arg-list-after-template-kw  \
 -c rcpp_bc_int.cpp -o rcpp_bc_int.o
657.00user 613.26system 21:10.42elapsed 99%CPU (0avgtext+0avgdata
455572maxresident)k
0inputs+2160outputs (0major+245790794minor)pagefaults 0swaps

/usr/bin/time \
 ~/LLVM-21.1.2-Linux-X64/bin/clang++ -std=gnu++17 -I ~/R/include \
 -DNDEBUG  -I$HOME'/R/library/Rcpp/include' \
 -fpic  -O3 -Wall -pedantic -frtti -Wp,-D_FORTIFY_SOURCE=3 \
 -Wno-missing-template-arg-list-after-template-kw  \
 -c rcpp_bcRel_dec.cpp -o rcpp_bcRel_dec.o
628.51user 359.64system 16:28.33elapsed 99%CPU (0avgtext+0avgdata
450924maxresident)k
0inputs+1888outputs (0major+74883426minor)pagefaults 0swaps

Why does it take more than 90 minutes of CPU time on the Fedora
machine running CRAN checks but only ~11 minutes on my lab workstation?
This probably has to do with 7 years of difference between the CPUs
running the code: Prof. Brian D. Ripley uses a server-oriented Intel
Xeon E5-2440 from ~2012, while mine is a desktop-oriented Ryzen from
2019.

Preprocessing the *.cpp files from your package and passing them
through clang-format, I see a lot of declarations and some inline
functions from Rcpp, but the code from files rcpp_bc_b.cpp,
rcpp_bc_int.cpp, and rcpp_bcRel_dec.cpp expands to tens of thousands of
lines on top of that, with some blocks nested ~28 times. Perhaps you
could join the #llvm channel at irc.oftc.net and ask for
recommendations regarding this kind of code? You may have a genuine
performance bug report on your hands.

With the deadline looming, are there any workarounds that would stop
the acute symptoms without spending the time treating the underlying
condition? It might help to put each macro-heavy function into a
separate *.cpp file, but I haven't tested that suggestion. 

-- 
Best regards,
Ivan

[0] See 'limit cputime':
https://svn.r-project.org/R-dev-web/trunk/CRAN/QA/BDR/gannet/packages/common.csh

[1]
https://cran.r-project.org/web/checks/check_results_broadcast.html

[2]
https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/broadcast-00check.html

[3]
https://github.com/llvm/llvm-project/releases/tag/llvmorg-21.1.2