My understanding is that it must start with "CL", not "cl". (https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/clCompileProgram.html#id-1.6.18)

Again, I think it must be capital letters. This should be unnecessary.

make the diff easier to read by keeping the old function as a per-argument version and introduce a new function that only adds the loop over the args?

does this need to be a warning?

? what are you worried about here?

QStringLiteral, also below

dito

dito

I just looked at what clang accepts, and there are probably some build systems that use it lower case. I don't think it does any harm to also accept it lowercase but I don't mind removing it.

It should of course only be a debug message (or completely silent if you prefer)

Can multiple threads call GccLikeCompiler::defines() at the same time? If so we would need a mutex to protect m_definesIncludes to avoid data corruption

This code should be used from main thread only, because caller code is not thread safe (project model is used IIRC)

I think that depends on whether we want full compatibility with Clang or rather stick to the OpenCL standard. I think sticking to the standard is generally the safer bet, since Clang might decide to change this anytime, but the standard won't change.

I found over the years that cross-platform development is easiest when sticking close to standards and having tools that strictly enforce the standards instead of being permissive.

Does it mean that now we provide arguments like "-ferror-limit=100 -fspell-checking -Wdocumentation" to the compiler?

It won't work with gcc and old clang versions

Please, add tests for gcc too. Ideally all test should work equally well with clang/gcc

This function is pretty complex and full of hacks, even before this change. But what bothers me most: why do we try to guess the language here?

As far as I can see, it's only used in GccLikeCompiler::defines and GccLikeCompiler::includes, which are used in CompilerProvider::defines and CompilerProvider::includes, respectively. But there we know the language (it's just languageType), so why do we try to detect it again?

I think this can be made a lot easier by redesigning some of the methods a bit.

There is no standard beginning with cuda, as far as I know. (See the Clang documentation.) It seems that Cuda just uses the already known C and C++ standards, if we are to believe the comments in D5210: Proper CUDA handling. I don't think we can detect Cuda from the arguments, but I also think we don't need to. (See my other comment.)