В Tue, 7 Oct 2025 06:34:11 +0000 Tony Wilkes <[email protected]> пишет:
> 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 ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
