precompiled header

[Ingo_L_]

This looks like a weird bug/behavior to me. If I compile a source file using a precompiled headers extra defines passed to compiler are ignored, meaning that it is impossible to switch between export/import via such defines as common pratice.

1. pch creation

icl "-Fp./mypch" "-Ycmypch.hxx" "-FImypch.hxx"

2. pch usage

icl a.cxx  "-Fp./mypch" "-Ycmypch.hxx" "-FImypch.hxx" -DDLL_DUMMY

then adding a error pragma to a.hxx to verify if DLL_DUMMY is defined fails with an error.

Same usage under msvcN (N >= 8) is no problem.

It looks like the compiler does not allow passing additional defines, if using a precompiled header (?!).

[Melanie_B_Intel]

Could you supply a small test case including header file(s) and complete command lines?

The -D options on the command line should be the same between the compilation which creates the precompiled header file and the compilation which uses the precompiled header file.  This is similar with Microsoft compiler, see http://msdn.microsoft.com/en-us/library/21khx4ke.aspx

If the -D options are not the same, the Intel compiler gives a warning message, then proceeds with the compilation. I found that Microsoft and Intel produced the same results with this test case:

#include <stdio.h>
int main(void)
{
#ifdef DLL_DUMMY
        printf("dll dummy is defined\n");
#else
        printf("dll dummy is not defined\n");
#endif
        return 0;
}

   cl a.cxx  "-Fp./mypch" "-Ycmypch.hxx" "-FImypch.hxx" -DDLL_DUMMY
   ./a.exe
   cl a.cxx  "-Fp./mypch" "-Yumypch.hxx" "-FImypch.hxx"
   ./a.exe

In both cases, a.exe prints "dll dummy is defined".  Compiling with icl gives same results.

i found a difference between cl and icl if the Yc compilation was initially done without -DDLL_DUMMY.  In this case, the Yu compilation with cl prints "dll dummy is defined" but the Yu compilation with icl prints "dll dummy is not defined".

The Microsoft documentation says, the value of /D macros "Must be the same between the compilation that created the precompiled header and the current compilation. The state of defined constants is not checked, but unpredictable results can occur if your files depend on the values of the changed constants."

[Ingo_L_]

Your test case already models the described behavior correct and shows the difference.

If the creation of the pch was initially not done with -DDLL_DUMMY on a microsoft compiler, the Yu compilation with cl allows to add the define, wherease icl ignores adding such defines.

We used one global precompiled header for our complete codebase for at least 10 years in this way for myriads of modules sharing the same precompiled header allowing easy switching between export/import and i am suprised, that this is undefined behavior (not aware yet of what the official documentation says about it) ...

The point is that adding such defines is not harmful, wherease of course changing other compiler options maybe very dangerous.

Is there a way to achieve the same behavior with icl? Otherwise i would try creating the precompiled header with cl and then using the sharing option \Qpchi with intel and Yu having a look, if then injecting those defines may be succesful. Ofc its more a hack than a solution.

[Melanie_B_Intel]

I don't understand the workaround you have in mind, to inject the new values. What you're doing -- using inconsistent /D values for Yc and Yu is explicitly mentioned in the Microsoft documentation as contraindicated (I was quoting the Microsoft documentation above, along with the documentation url.) Could you create 2 different Microsoft projects, one which creates the precompiled headers with /DDLL_IMPORT and the other with /DLL_EXPORT?  For further support, could you file an issue with Intel Premier Support?  Thanks!