...

One corresponds to an MPICH configure with my default environment and the other with a vanilla environment not including my GCC 4.8.1 install. When the environment knows about GCC 4.8.1, configure tests related to C++ fail.

See the icc(1) man page:

GNU* gcc Interoperability C++ compilers are interoperable if they can link object files and libraries generated by one compiler with object files and libraries generated by the second compiler, and the resulting executable runs successfully. Some GNU* gcc versions are not interoperable, some versions are interoperable. By default, the Intel compiler will generate code that is interoperable with the version of gcc it finds on your system.

The Intel(R) C++ Compiler options that affect GNU* gcc interoperability include:

· -cxxlib

· -gcc-name

· -gcc-version

· -gxx-name

· -fabi-version

· -no-gcc (see gcc Predefined Macros for more information)

So there is no way to disable Intel's auto-detection of GCC from PATH? I do not see the options http://software.intel.com/sites/products/documentation/studio/composer/en-us... or http://software.intel.com/sites/products/documentation/studio/composer/en-us... any effect in this regard.

The Intel(R) C++ Compiler is interoperable with GNU* gcc compiler versions greater than or equal to 3.2. See the Intel(R) C++ Compiler Documentation for more information.

Well that's complete nonsense since it is clearly not compatible with GCC 4.8.1.

We just debugged essentially this problem from some BW users that couldn't manage to have exactly the same GCC modules loaded when they configured PETSc as when they ran later (it took way too many emails to pin them down on this bit of the environment changing). The gcc-version also affects the dialect and attributes, so for example, when icc finds a recent version of gcc,

You mean this is a _runtime_ dependency? Thank goodness I am not trained in martial arts, or I would have just killed myself with a lethal slap to the forehead.

__attribute((deprecated("explanation why")))

works, but if it finds an old version of gcc, then "explanation why" is not understood, so only

__attribute((deprecated))

can be used. This dependence on whatever gcc is found in the path is horrendous for reproducibility since it makes it harder to create configurations that don't depend on the environment and even if you concede dependence on the environment, few people realize that the Intel's compilers change behavior based on the version of gcc found in PATH.

I completely agree. This is atrocious behavior. Does the Intel C++ compiler not work if I don't have GCC installed? What if - as is my inalienable right as the operator of my computer - I alias all GCC commands to /usr/bin/light-machine-room-on-fire or /usr/bin/pull-the-plug-on-grandma? I suppose the Intel commercial license has an indemnification clause, because otherwise, I could get rich by exploiting this nonsense. Jeff -- Jeff Hammond [email protected]