LLVM 13 changes break C++ compilation via API?

We are using the Clang C++ API on Linux to generate bitcode from C++ source code. Our application works fine with LLVM 11 and 12, but breaks with LLVM 13: STL calls are not handled right.

After doing some digging, I discovered that the -internal-isystem options passed to the driver differ with respect to LLVM 11 and 12, and with respect to the options used when compiling on the command line. In previous versions, and on the command line, they look something like this:

-internal-isystem /opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9
-internal-isystem /opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/x86_64-redhat-linux
-internal-isystem /opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/backward
-internal-isystem /u/geoff/llvm13/lib/clang/13.0.1/include
-internal-isystem /usr/local/include
-internal-isystem /opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/../../../../x86_64-redhat-linux/include

But when we use the API in LLVM 13, they look more like this:

-internal-isystem /../lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5
-internal-isystem /../lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/x86_64-redhat-linux
-internal-isystem /../lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/backward
-internal-isystem /u/geoff/llvm13/lib/clang/13.0.1/include
-internal-isystem /usr/local/include
-internal-isystem /../lib/gcc/x86_64-redhat-linux/4.8.5/../../../../x86_64-redhat-linux/include

That is, when using the LLVM 13 API, Clang seems to get the C++ header files from an old version of gcc (4.8.5) rather than the version we use (9.3.1). Does anybody out there have any idea why?

Potentially useful small print:

We are using CentOS 7.8, where the default gcc compiler is indeed 4.8.5. But LLVM and Clang are compiled with gcc 9.3.1, which is installed via the devtoolset-9 package, and activated on the command line like so:

scl enable devtoolset-9 tcsh

So the gcc on the PATH is /opt/rh/devtoolset-9/root/usr/bin/gcc, which is version 9.3.1, both when building LLVM and when running our application. Although, until now, Clang has always located the C++ header files and libraries by itself, regardless of which gcc is on the PATH.

Problem solved.

For the teeming millions who have been wondering what the problem was, it was clang’s mechanism for searching for gcc. The first place clang looks for gcc is side by side with the clang executable, i.e. in INSTALL_DIR/.., where INSTALL_DIR is the directory where the clang executable is located. In our case, since we don’t actually use a clang executable, we didn’t bother specifying a location, so that became /... And starting in LLVM 13, for some reason, clang considers that invalid location to hold a valid gcc installation.

I would consider that to be a bug in clang, but apparently a bug that bothers no one but me.