[Bug 246630] stable/11 regression: base.txz reproducibility depends on number of cpu cores

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246630

Dimitry Andric <dim at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Open

--- Comment #18 from Dimitry Andric <dim at FreeBSD.org> ---
So after quite a bit of head scratching, I found that the problem appears to be
caused by upstream commit
https://github.com/llvm/llvm-project/commit/b4a99a061f517e60985667e39519f60186cbb469:

commit b4a99a061f517e60985667e39519f60186cbb469
Author: Alexandre Ganea <alexandre.ganea at 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 directly
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 the
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 previous
behavior, where any -cc1 invocation will create/fork a secondary process.
    At run-time, it is also possible to tweak the CLANG_SPAWN_CC1 environment
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 workaround
is to set the environment variable CLANG_SPAWN_CC1=1. This forces the clang
driver to fork and exec a new instance for the cc1 stage, and clears up the
problem completely for me.

-- 
You are receiving this mail because:
You are the assignee for the bug.