Date: Fri, 29 May 2020 19:33:24 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 246630] stable/11 regression: base.txz reproducibility depends on number of cpu cores Message-ID: <bug-246630-227-m88WoaNtrQ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-246630-227@https.bugs.freebsd.org/bugzilla/> References: <bug-246630-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246630 Dimitry Andric <dim@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open --- Comment #18 from Dimitry Andric <dim@FreeBSD.org> --- So after quite a bit of head scratching, I found that the problem appears t= o be caused by upstream commit https://github.com/llvm/llvm-project/commit/b4a99a061f517e60985667e39519f60= 186cbb469: commit b4a99a061f517e60985667e39519f60186cbb469 Author: Alexandre Ganea <alexandre.ganea@ubisoft.com> Date: Mon Jan 13 10:40:04 2020 -0500 [Clang][Driver] Re-use the calling process instead of creating a new process for the cc1 invocation With this patch, the clang tool will now call the -cc1 invocation direc= tly inside the same process. Previously, the -cc1 invocation was creating, and waiting for, a new process. This patch therefore reduces the number of created processes during a build, thus it reduces build times on platforms where process creation can = be costly (Windows) and/or impacted by a antivirus. It also makes debugging a bit easier, as there's no need to attach to t= he secondary -cc1 process anymore, breakpoints will be hit inside the same process. Crashes or signaling inside the -cc1 invocation will have the same side-effect as before, and will be reported through the same means. This behavior can be controlled at compile-time through the CLANG_SPAWN= _CC1 cmake flag, which defaults to OFF. Setting it to ON will revert to the prev= ious behavior, where any -cc1 invocation will create/fork a secondary process. At run-time, it is also possible to tweak the CLANG_SPAWN_CC1 environme= nt variable. Setting it and will override the compile-time setting. A value of= 0 calls -cc1 inside the calling process; a value of 1 will create a secondary process, as before. Differential Revision: https://reviews.llvm.org/D69825 For some reason, not spawning a second process for the cc1 stage has this particular influence on the end result, and *only* for the printf.c file! I'm still digging further into this rabbit hole, but for now a good workaro= und is to set the environment variable CLANG_SPAWN_CC1=3D1. This forces the cla= ng driver to fork and exec a new instance for the cc1 stage, and clears up the problem completely for me. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-246630-227-m88WoaNtrQ>