Constraint value @bazel_tools//tools/cpp:compiler:gcc not true when using GCC compiler

[pudelkoM]

Description of the problem:

The constraint value @bazel_tools//tools/cpp:compiler:gcc is not detected/enabled correctly when the GCC compiler is used and can not be targeted with a config_setting.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

The following Bazel repo demonstrates the issue. It has a dummy target that is intended to be compiled with different copts, depending on the compiler. We use config_settings which match on the @bazel_tools//tools/cpp:compiler flag and select on them later.

WORKSPACE:

workspace(name = "test-bar")

BUILD:

config_setting(
    name = "llvm_compiler",
    flag_values = {"@bazel_tools//tools/cpp:compiler": "clang"},
)

config_setting(
    name = "gcc_compiler",
    flag_values = {"@bazel_tools//tools/cpp:compiler": "gcc"},
)

# Only to show the bug(?) in the local `cc_toolchain_config`.
config_setting(
    name = "compiler_compiler",
    flag_values = {"@bazel_tools//tools/cpp:compiler": "compiler"},
)

# non-existent flags to show which condition matched.
DEFAULT_COPTS = select({
    ":llvm_compiler": ["-fail_llvm"],
    ":gcc_compiler": ["-fail_gcc"],
    ":compiler_compiler": ["-fail_compiler"],
    "//conditions:default": ["-fail_default"],
})

cc_binary(
    name = "dummy",
    srcs = ["empty.cc"],
    copts = DEFAULT_COPTS,
    deps = [],
)

empty.cc

The system has both gcc and clang installed and available in $PATH:

> gcc -v
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)

> clang -v
Ubuntu clang version 12.0.0-++20201207052627+22558c8501e-1~exp1~20201207163316.246

Now try to compile the dummy target.

With no $CC/$CXX set, we expect the build to fail with the -fail_gcc message, as GCC is the default. Bazel found and used gcc as seen in the error, but with the wrong flags (unrecognized command line option '-fail_compiler'):

> bazel build -s //...
INFO: Invocation ID: bc64f64e-a338-4f97-a7ba-005dc3f6cb3a
INFO: Analyzed target //:dummy (1 packages loaded, 21 targets configured).
INFO: Found 1 target...
SUBCOMMAND: # //:dummy [action 'Compiling empty.cc', configuration: a5d130b0966b4a9ca2d32725aa5baf40e215bcfc4d5cdcdc60f5cc5b4918903b, execution platform: @local_config_platform//:host]
(cd /home/max/.cache/bazel/_bazel_max/2ba0fe81f3bf905bcacad82a417d35f2/execroot/test-bar && \
  exec env - \
    PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin \
    PWD=/proc/self/cwd \
  /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '-std=c++0x' -MD -MF bazel-out/k8-fastbuild/bin/_objs/dummy/empty.pic.d '-frandom-seed=bazel-out/k8-fastbuild/bin/_objs/dummy/empty.pic.o' -fPIC -iquote . -iquote bazel-out/k8-fastbuild/bin -iquote external/bazel_tools -iquote bazel-out/k8-fastbuild/bin/external/bazel_tools -fail_compiler -fno-canonical-system-headers -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c empty.cc -o bazel-out/k8-fastbuild/bin/_objs/dummy/empty.pic.o)
ERROR: /tmp/bazel_compiler_test/BUILD:23:10: C++ compilation of rule '//:dummy' failed (Exit 1): gcc failed: error executing command /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '-std=c++0x' -MD -MF ... (remaining 21 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox gcc failed: error executing command /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '-std=c++0x' -MD -MF ... (remaining 21 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox
gcc: error: unrecognized command line option '-fail_compiler'
Target //:dummy failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 1.012s, Critical Path: 0.08s
INFO: 2 processes: 2 internal.
FAILED: Build did NOT complete successfully

Snippet from <bazel cache dir>/external/local_config_cc/BUILD:

...
cc_toolchain_config(
    name = "local",
    cpu = "k8",
    compiler = "compiler",  # should be gcc?
...

With $CC=clang/$CXX=clang++, the build fails as expected: clang: error: unknown argument: '-fail_llvm'
And the local config seems correct, too:

...
cc_toolchain_config(
    name = "local",
    cpu = "k8",
    compiler = "clang",
...

Setting $CC=gcc/$CXX=g++ does not help, same error as above: gcc: error: unrecognized command line option '-fail_compiler'

...
cc_toolchain_config(
    name = "local",
    cpu = "k8",
    compiler = "compiler",
...

What operating system are you running Bazel on?

20.04.1 LTS (Focal Fossa)

Linux 5.4.0-53-generic #59-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux

What's the output of bazel info release?

release 3.7.1

Have you found anything relevant by searching the web?

Abseil uses the same technique to detect the compiler, but uses the default condition for GCC:

• https://github.com/abseil/abseil-cpp/blob/master/absl/BUILD.bazel#L20-L26
• https://github.com/abseil/abseil-cpp/blob/master/absl/copts/configure_copts.bzl#L24-L28

[fmeum]

@oquenchil I have a (simple) fix for this bug, but am wondering about your thoughts on backwards compatibility here: If compiler starts to have the value "gcc" instead of "compiler" for gcc, this could mess with existing uses of select.

Envoy may break, but would certainly welcome the fix based on the discussion on that PR. Abseil would not break as they treat gcc as the default case.

[aaron-michaux]

@fmeum , can you describe what your simple fix is? Is there a way to simply tell bazel which compiler to use?

[fmeum]

@aaron-michaux If you just want to have Bazel use a particular compiler, add --repo_env=CC=<path to your compilet> to your .bazelrc and run bazel sync --configure.

The fix I was talking about above was for getting GCC recognized by Bazel as gcc rather than the generic compiler. Fixing that comes down to parsing the output of --version, but the backwards compatibility concerns are real.

@oquenchil Friendly ping, do you think reporting GCC as gcc would be too disruptive?

[oquenchil]

No. I think it's fine. This would be a bug fix. Ideally the change would be checked in together with a script that runs buildozer (or some regex) over a project and fixes the places that need fixing. But if that's not possible then properly describing how it can break and what the instructions for fixing it are should be enough.

[jbms]

Note: This isn't fully fixed: #17794