https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246630
Dimitry Andric <d...@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|New |Open
--- Comment #18 from Dimitry Andric <d...@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.ga...@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.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
