[PATCH] D69825: [Clang][Driver] Re-use the calling process instead of creating a new process for the cc1 invocation

[Dimitry Andric via Phabricator via cfe-commits]

dim added a subscriber: asbirlea.
dim added a comment.

Okay, after a long while of attempting to make a reproduction scenario, I finally managed one that consistently worked. As BSD make puts in different redirections for stderr when running in `-j` mode, it turned out that I could simply run the compilation twice on a terminal, first normally, then with stderr redirected to `/dev/null`, e.g. my test script is:

  #!/bin/sh
  
  exec </dev/tty >/dev/tty 2>&1
  
  ulimit -c 0
  trap "rm -f testcase[12].s testcase[12].s-* testcase-*.s.tmp" EXIT
  
  ${CLANG:-clang} -fintegrated-cc1 -Werror -O2 -std=gnu99 -fstack-protector-strong -S testcase.c -o testcase1.s || exit 1
  ${CLANG:-clang} -fintegrated-cc1 -Werror -O2 -std=gnu99 -fstack-protector-strong -S testcase.c -o testcase2.s 2>/dev/null || exit 1
  
  cmp -s testcase1.s testcase2.s
  test $? = 1 || exit 1
  
  exit 0

(Here `testcase.c` is a copy of the .c file in https://www.andric.com/freebsd/clang/bug246630-repro.tar.xz)

Using this script I could finally bisect, and arrived at the following commit which fixes the issue, i.e. it makes the outputs of both clang runs the same again, and it is rG0cecafd647cc <https://reviews.llvm.org/rG0cecafd647ccd9d0acc5968d4d6e80c1cbdee275> ("[BasicAA] Make BasicAA a cfg pass"). @asbirlea seems to indicate in the commit message that it influences the way the BasicAA pass is freed/invalidaed or not during runs?

So is this commit fixing it as an unintended side effect, or would it be according to expectation?  If the latter, we should merge it into 10.0.1, and I will create a PR for it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69825/new/

https://reviews.llvm.org/D69825