In vanilla GCC, the output from the --version option includes the word "GCC" in the first line. For example, if the compiler is invoked as "cc": "cc (GCC) 8.2.0" Gentoo changes the "GCC" to a string which does not contain GCC, e.g.: "cc (Gentoo 8.2.0-r2 p1.2) 8.2.0", so that the --version output does not contain "GCC" or "gcc" anywhere unless basename(argv[0]) happens to include it. It would be useful to keep the "GCC" so callers can more easily guess at the type of compiler being called.
(In reply to Andrew Church from comment #0) > In vanilla GCC, the output from the --version option includes the word "GCC" > in the first line. For example, if the compiler is invoked as "cc": "cc > (GCC) 8.2.0" > > Gentoo changes the "GCC" to a string which does not contain GCC, e.g.: "cc > (Gentoo 8.2.0-r2 p1.2) 8.2.0", so that the --version output does not contain > "GCC" or "gcc" anywhere unless basename(argv[0]) happens to include it. > > It would be useful to keep the "GCC" so callers can more easily guess at the > type of compiler being called. In theory we could prepend GCC. But in practice it looks like it's the place of a package vendor string and not compiler implementation: https://github.com/gcc-mirror/gcc/blob/master/gcc/doc/install.texi#L651 See Debian's gcc as an example: $ cc --version cc (Debian 7.3.0-19) 7.3.0 Which software relies on 'GCC' string? It should use something more robust like preprocessor macros or compiler feature tests.
I use it in build scripts for selecting compiler invocation options (see e.g. http://achurch.org/SIL/current/build/common/toolchain.mk). It's true that I could explicitly test for individual flags, but that would require invoking the compiler once per test, which in practice gets expensive. (A major reason I've always avoided autoconf, for example, is because it's so slow that the actual compile is often faster than the configuration process.) So I'd rather be able to detect the compiler type using a single invocation and use that to select a base set of flags. Additionally, it's conceivable that even if a particular warning flag is supported by the compiler, the precise meaning varies between compilers, such as GCC vs. Clang. I don't know of any specific instances because I've been using --version heuristics for warning flag selection, but I certainly have seen cases in which one compiler warns but the other doesn't for the same set of flags. That said, if other distributions also omit "GCC" from that string then I suppose the current behavior is reasonable. FWIW, I never actually experienced this until updating GCC to 8.2.0 a few days ago, but reinstalling 7.3.0 gave the same result; unless Gentoo's GCC vendor string was changed recently, I'm not sure why it just started happening.
(In reply to Andrew Church from comment #2) > I use it in build scripts for selecting compiler invocation options (see > e.g. http://achurch.org/SIL/current/build/common/toolchain.mk). It's true > that I could explicitly test for individual flags, but that would require > invoking the compiler once per test, which in practice gets expensive. [ to clarify: the below are just ideas to consider ] I'm not sure about "expensive" argument. 1000 gcc executions take 3 seconds here, 1000 clang invocations takes 1 minute. 1000 is a lot of options. You can also cache flag checks the similar way object files are cached and not reexecute tests if 'cc --version' is not changed. It's what autoconf or cmake would do for you. > (A > major reason I've always avoided autoconf, for example, is because it's so > slow that the actual compile is often faster than the configuration > process.) So I'd rather be able to detect the compiler type using a single > invocation and use that to select a base set of flags. I'd say it's a matter of how you write configure.ac and not inherent autoconf slowness. But it really depends on what amount of additional slowness you can tolerate. For example this autoconf file takes 2 seconds to execute on my machine and detects a bunch of options: https://github.com/skvadrik/re2c/blob/master/re2c/configure.ac#L59 and it it easy to make that 'configure.ac' shorter by removing autodetection of things you don't need. If you still want to just detect gcc vs. clang I'd suggest using preprocessor flags. gcc has only __GNUC__, clang has both __GNUC__ and __clang__: $ clang -dM -E - </dev/null | egrep '__GNUC__|__clang__' > Additionally, it's conceivable that even if a particular warning flag is > supported by the compiler, the precise meaning varies between compilers, > such as GCC vs. Clang. I don't know of any specific instances because I've > been using --version heuristics for warning flag selection, but I certainly > have seen cases in which one compiler warns but the other doesn't for the > same set of flags. > > That said, if other distributions also omit "GCC" from that string then I > suppose the current behavior is reasonable. Closing as RESOLVED/INVALID. > FWIW, I never actually experienced this until updating GCC to 8.2.0 a few > days ago, but reinstalling 7.3.0 gave the same result; unless Gentoo's GCC > vendor string was changed recently, I'm not sure why it just started > happening. I guess it started happening after >=sys-devel/gcc-config-2.0 upgrade (a few days ago). Older gcc-config used to provide a wrapper that silently changed 'cc' command for 'gcc' command: $ LANG=C cc --version gcc (Gentoo 7.3.0-r3 p1.4) 7.3.0 $ LANG=C cc --version cc (Gentoo 8.1.0-r3 p1.3) 8.1.0 Note that GCC is not present in any of these lines. It's an argv[0] change. It was removed in https://gitweb.gentoo.org/proj/gcc-config.git/commit/?id=9b907ef80bc421df23515afc4c306e4d96c67649
