clang-cl and INCLUDE path ordering

Clang Frontend
1

Hi,

I ran into a problem when switching from cl.exe to clang-cl.exe (3.8.1) for building a large proprietary Windows application. I’m not sure if this counts as a bug in clang-cl, but I thought I should report it anyway.

Our app:

  • has its own header called cpuid.h
  • for obscure reasons, includes all its own headers using angle brackets instead of double quotes: #include <cpuid.h>

The problem goes like this:

$ cat foo.c
#include <cpuid.h>
T x;

$ cat cpuid.h
typedef int T;

$ INCLUDE=. cl /c foo.c # works

$ INCLUDE=. clang-cl /c foo.c # doesn’t work
foo.c(2,1) : error: unknown type name ‘T’

… because it has picked up the cpuid.h shipped with clang-cl, not the one in the current directory.

A few experiments with cl suggest that it looks for headers in these directories, in this order:

  1. /I command line options
  2. INCLUDE environment variable
  3. C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include

Whereas clang-cl -Xclang -v tells me it is looking in:

  1. /I command line options
  2. C:\Program Files\LLVM\bin..\lib\clang\3.8.1\include
  3. INCLUDE environment variable

Any chance of swapping 2 and 3 round, to better match cl?

Thanks,
Jay.

2

I don't think we can change the ordering because VC/include is typically
included in the INCLUDE environment variable, and that directory contains
MSVC's *mmintrin.h headers, which are compiler-specific. We need clang's
intrinsic headers to win out over MSVC's. It sounds like you can work
around the issue by passing /I., though, right?

Thanks for the report, though, always excited to hear about new user
experiences. :slight_smile:

3

I don't think we can change the ordering because VC/include is typically
included in the INCLUDE environment variable, and that directory contains
MSVC's *mmintrin.h headers, which are compiler-specific. We need clang's
intrinsic headers to win out over MSVC's.

OK, that sounds like a plausible excuse! :slight_smile:

It sounds like you can work around the issue by passing /I., though, right?

Yes, there are plenty of easy workarounds.

Thanks for the report, though, always excited to hear about new user

experiences. :slight_smile:

Overall the transition from cl to clang-cl was incredibly smooth. Thanks!

For the record, the only other problem I ran into that I haven't seen
mentioned elsewhere is that cl (as of VS 2015) accepts _try/_except as
synonyms for __try/__except, even though it's more or less explicitly
documented that they *don't* exist!

"For backward compatibility, single-underscore versions of all the
double-underscored keywords except *__except*,*__finally*, *__leave*, and
*__try* are supported."

Jay.