>>...the _M_X64 macro is only defined for the Windows* version of our compiler...

This is what MSDN says about a pre-defined ANSI macro _M_X64:
...
_M_X64 - Defined for x64 processors
...

My understanding is as follows: if some project is compiled for a 64-bit platform then _M_X64 has to be defined. If Intel C++ compiler defines the macro on a 64-bit WIndows platform and doesn't define the macro on 64-bit Linux or Mac platforms it doesn't look right because all macros with a prefix '_M_' are ANSI pre-defined macros.

I gave you a complete set of '_M_'-like macros.

I didn't have an opportunity to verify just three macros: _M_MRX000, _M_ALPHA and _M_PPC. All the rest are defined when different C++ compilers are used to compile my project for different platforms.

>My understanding is as follows: if some project is compiled for a 64-bit platform then _M_X64 has to be defined. If Intel C++ compiler defines >the macro on a 64-bit WIndows platform and doesn't define the macro on 64-bit Linux or Mac platforms it doesn't look right because all macros >with a prefix '_M_' are ANSI pre-defined macros

It makes no difference what ANSI/ISO says. On Windows platform we predefine the same macros as the Microsoft compiler and on Linux we predefine the same macros as the GNU compiler. This is necessary for compatibility.

Is that an official statement from Intel? Does it mean that Intel C++ compiler team and support guys don't want to take ANSI standard into account?

>>...and on Linux we predefine the same macros as the GNU compiler. This is necessary for compatibility...

It means that if the GNU C/C++ compiler has a _M_X64 bug then Intel C++ compiler on Linux platform perfectly reproduces it because of compatibility. It makes no sense at all.

I see this again and again that Intel C++ compiler team simply copies some feature(s) or functionality without doing a proper analysis and without asking a question "What if this is wrong in the GNU compiler?".

No one in the GNU* world would ever expect those to be oblige. Hence we don't handle them in our Linux* and Mac OS* X compilers, too.
Both worlds are different by design - just think about LP64 vs. LLP64!

Back to the original question: Is there a platform independent way to test for 64 bit compilation?
Answer: There is not. It always requires to take the platform into account. Even if Intel compilers provide the Microsoft* specific macros for Linux*, it won't work with GNU* compilers, thus being another dead-end regarding portability.

The C preprocessor normally predefines several macros that indicate
what type of system and machine is in use. They are obviously
different on each target supported by GCC. This manual, being for all
systems and machines, cannot tell you what their names are, but you can
use `cpp -dM' to see them all. *Note Invocation::. All system-specific
predefined macros expand to the constant 1, so you can test them with
either `#ifdef' or `#if'.

The C standard requires that all system-specific macros be part of
the "reserved namespace". All names which begin with two underscores,
or an underscore and a capital letter, are reserved for the compiler and
library to use as they wish. However, historically system-specific
macros have had names with no special prefix; for instance, it is common
to find `unix' defined on Unix systems. For all such macros, GCC
provides a parallel macro with two underscores added at the beginning
and the end. If `unix' is defined, `__unix__' will be defined too.
There will never be more than two underscores; the parallel of `_mips'
is `__mips__'.

When the `-ansi' option, or any `-std' option that requests strict
conformance, is given to the compiler, all the system-specific
predefined macros outside the reserved namespace are suppressed. The
parallel macros, inside the reserved namespace, remain defined.

We are slowly phasing out all predefined macros which are outside the
reserved namespace. You should never use them in new programs, and we
encourage you to correct older code to use the parallel macros whenever
you find it. We don't recommend you use the system-specific macros that
are in the reserved namespace, either. It is better in the long run to
check specifically for features you need, using a tool such as `autoconf'.
...

As Sergey hints, a typical method for distinguishing 32- vs. 64-bit platform is by C pointer size. I think the method based on e.g. sizeof(int *) or (C99) PTRDIFF_MAX is as close as you could call to a standard C method. If your dependencies on 32- vs. 64-bit are covered by such standard facilities, evidently you should take advantage of them.
The C standard doesn't deal at all with pre-defined macros which distinguish platform environment. As mentioned earlier in the thread, the Intel compilers usually set the same macros as the Microsoft or gnu compiler which is being modeled, This leaves the __INTEL_COMPILER macros as a way to distinguish from those compilers.
There have been some weakly documented macros you could set to turn off Microsoft bug compatibility for certain cases, but I don't see how that is relevant to the original topic of this thread. In the case of known bugs in gnu compilers, it's usually been possible to get bug fixes quickly enough that the best solution was to update compilers to compatible versions.

Define _M_X64 macro in a makefile project file for a 64-bit Linux platform.

[ Note ]

>>..._M_* macros are Microsoft* specific only...

Even if _M_X64 macro has a letter M it doesn't stand for Microsoft. Even if these macros are Microsoft specific the letter M stands for Machine and it is a more generic term. A letter L ( in _LP64 macro ) stands for Linux and, of course, that is why Microsoft doesn't support / use it.

As I already mentioned it is no longer a problem for me since workarounds are simple and working.

As Sergey points out, if your actual concern is the nature of size_t, there also you should simply rely on standard syntax to make your code portable. On most current platforms, of course, size_t and pointer types will match as 32- or 64-bit data types.