We tried this and could not reproduce a problem. The machine is a two socket Magny Cours system running Win7 64-bit. VS 2008 is installed. We also have the intel compilers on this system, but a command line window is started and variables set so that the intel compilers are not visible to the command line. The window startup invokes the 32 bit Microsoft setup scripts rather than the x64 scripts.
Both the C and C++ examples run, and both can be built using the microsoft cl compiler. This is for the ifort32 library.
Make sure you don't have any issues with the PATH variable pointing at the wrong acml lib directory. The example makefile sets this for each example, but just running the executable on the command line will use whatever PATH is pointing at.
Thank you very much for looking into the issue!
The library keeps stalling on my Windows 7 x64 system, with the cause being rooted in libifcoremd.dll. I inspected the disassembly in the Visual Studio debugger and it seems to me that the infinite loop occurs while the CPU model is identified. I have a Core 2 Quad Q9650 installed, which would explain why you could not reproduce the error. The CPU identification routine seems to work properly and take the right path for my processor. However, as the last step of the identification, the extended control register XCR0 is retrieved via the xgetbv instruction. Bits 63..32 of the XCR0 are stored as result of the routine. As far as I understand, these bits are currently reserved and zero on my system. Yet the routine is repeated until the result is one of three nonzero values.
I believe this could be due to the following issue of the Intel Compiler:
Update 2 revised (Posted October 2009), Package IDs below
DPD200139120 C, C++, Fortran - The packages were rebuilt to correct an issue where the compiler would not run on certain Windows 7* and Windows Server 2008* systems. Correctness of the generated code is not an issue.
Or due to the same/related issue of the Intel Parallel Composer:
Update 2 Revised (Posted October 2009)
DPD200139120 C, C++ - Update 2 list below has more details on this issue. Note: The package was rebuilt to correct an issue where the compiler would not run on certain Windows 7* and Windows Server 2008* systems. Correctness of the generated code is not an issue.
Update 2 (Posted September 2009)
DPD200139120 C,C++ - Composer may hang or encounter a segmentation-fault when run on Microsoft* Windows 7* or Windows Server 2008* R2. Please refer to the following links for more details:
DPD200139120 C,C++ - Application hangs due to xgetbv in __intel_cpu_indicator_init() function
The respective websites are:
Is it possible that the acml 4.4.0-ifort32 was built with an Intel compiler not containing the afore-mentioned patch? The "product version" (Windows Explorer context menu) of libifcoremd.dll is listed as "11.1 (Beta)" on my system, the "File Version" is 22.214.171.124?
If that is the case, would it be possible to release the package built with a recent Intel compiler having the latest patches?
Thanks a lot for your efforts!
The current ifort32 library is built with 11.1.038. According to your data it looks like this could be subject to the problem.
We will build the next version with a newer compiler, but that won't be until the end of this year.