running code on Opteron

running code on Opteron


I am using the latest Linux Intel Fortran 14.0.1.

I compiled my code using the following options:

 -O2 -vec-report0 -axSSE4.2 -assume buffered_io -warn noalignments  -openmp

This code works fine on my computer.  I gave the executable to another user who has AMD Opteron(tm) Processor 2384 CPU, and he told me that he is getting the following error message when he tries running the code:

"Please verify that both the operating system and the processor support Intel (R) X87, CMOV, MMX, FXSAVE, SSE and SSE2 instructions"

Does anyone know what the problem could be?  I am using the -axSSE4.2 option, but from what I have read, it should still work.  Should I remove -ax and try again?


30 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

It looks like the cpu identification function is failing.   If the -ax option runs into trouble identifying the CPU, -x might be expected to fail as well.

You might try building with -msse3, as that would be the latest Intel instruction set supported by that and other AMD CPUs of the last 7 years, then there should be no cpu identification, except possibly in the run-time library.  You should be able to avoid any problems with run-time library by adding -imf-arch-consistency=true in the build options.

That should have worked. Are you absolutely certain that those are the exact options you selected? In particular, did you also add -fast? (You shouldn't.) Yes, try removing -ax but if adding -ax gives this error then we may have a bug. Let me know what you find.

Retired 12/31/2016

That error message ought not to be displayed when -ax is used. For non-Intel CPUs, it would simply take the generic code path (which is SSE2 by default, changeable with -m). If this is not working correctly, we want to know about it.

Retired 12/31/2016

I have just checked, and the options I told you about previously are the ones used to compile and link all source files.  I'll try without the -ax and see what happens.  Sorry, but it is difficult for me to debug this since I don't have access to a computer with AMD CPU, and the person who wants to run my code is on a different continent.  I will let you know what happens.


Thanks. We'll do some testing on our own. We do regularly test on Opterons so it seems improbable that we'd have introduced a bug here, but one never knows.  For my benefit, would you please do a test compile with the options you stated and add -watch - then attach the console output from that compile.

Retired 12/31/2016

After removing the -axSSE4.2 option, I was told that the code now works on the Opteron computer.

I have recompiled everything with the original options and -watch.  The output is attached.  I have checked, and the compiled executable is identical to the one that produced the above error message.



Downloadapplication/zip watch-output.zip7.67 KB

Thanks - I'll have the developers check this out. Would you be willing to provide us with the executable? You can do it here, use "Send Author a Message" for more privacy, or use Intel Premier Support (please ask that the issue be assigned to me.)

Retired 12/31/2016

One more question - do you know if your customer is running this under a virtual machine? I know some VMs deliberately mis-report the CPU capabilities.

Retired 12/31/2016

Please ask your customer to download and run CPU-Z in the environment where the application is run, and to send you a screenshot of the first screen (as shown on the web site). Then attach that here.

Retired 12/31/2016

CPU-Z in a Windows, not Linux utility.  Would the output of /proc/cpuinfo be useful?

Oh, right. Sorry.  I see that Linux has a cpuid command - maybe that would help. I want to see what the processor says its capabilities are. And if you can get an answer to the VM question that would help.

Retired 12/31/2016

I asked about the virtual machine, and I was told that he is not using it.   Can you see if the attached file has the information you need about the CPU.



Downloadapplication/zip cpuinfo.zip840 bytes

Thanks - that was helpful. I will now escalate this to the developers fror investigation. Issue ID is DPD200249585.

Retired 12/31/2016

If you add -msse2 (along with -axSSE4.2), it should work. I'm discussing this with the developers now.

Retired 12/31/2016

I removed my previous reply as it may not end up being correct. The workaround I suggested is valid. Stay tuned.

Retired 12/31/2016

Ok, final answer. This is a bug and is expected to be fixed in Update 2, scheduled for January. Adding -msse2 is a workaround for 32-bit compiles. You may need to use -msse3 for 64-bit.

Retired 12/31/2016

Thanks for the information.  Do you know if this bug also exists in the Windows Fortran compiler, or is it only in Linux?


It exists on Windows as well. On Windows, use /arch:sse2 or /arch:sse3 as workarounds.

Retired 12/31/2016

It did get fixed in Update 2.

Retired 12/31/2016

Hi !

It seems it isn't fixed.

I'm using latest ICC.

I've built my app with /fast /QxAVX. But when I try to start it it shows:

Please verify that both the operating system and the processor support Intel(R) X87, CMOV, MMX, FXSAVE, SSE, SSE2, SSE3, SSSE3, SSE4_1, SSE4_2, POPCNT and AVX instructions.

My CPU is AMD FX-8350. And the app works well if I use MSVC with /arch:AVX.

Please, stop this CPU discrimination.


I've disassembled a little resulting code.

ICC generates a cpuid with check if manufacturer is GeniuneIntel if it is not it drops CPU capabilities without performing any further checks !

Then it checks the CPU capabilities and shows an error.

It seems that I need to replace ICC with MSVC or GCC for instance.

Too poor competition Intel.

If you intend to target amd with arch :avx don't use options which are documented as excluding amd.

If you want closer to msvc you will need also to pay attention to options such as /fp :source.

/Qx (and -x) requires an Intel CPU. /Qax (-ax) will run on non-Intel using the "generic" code path (SSE2 by default but you can change it with /arch (-m). The bug described earlier is fixed. Please read the documentation on these options.

Retired 12/31/2016

OK, thanks for reply, I've found these options.

But another one question : for which purpose there's separation with these options ?

Both are specifying an instruction set. If it's about optimization for process(Intel vs Non-Intel) then maybe it should look like:

/arch:AVX (for wide number of processors)

/arch:AVX /favor:Intel (Some optimization for Intel processors)

As no reliable way has been documented to detect various instruction sets supported by non-Intel CPU at run time, you must choose one at compile time. Should you choose to do so, you may set options to detect when running on an Intel CPU with a newer isa.  That option may not be useful if a non-Intel CPU is your primary target.  Even among Intel cpu it's not always good to choose a multiple path option.

You may be confusing the automatic compile time selection [Q]xhost which resembles gcc march =native except for working only for Intel CPU. 

I would disagree with Tim's last post. There is an architected method of detecting instruction subset support through the CPUID instruction. This is used by /QxHost (-xHost) and it DOES support non-Intel CPUs.

Use of /Qx (-x) does enable some Intel-specific optimizations, as called out in our Optimization Notice, and requires an Intel processor. This is the way we have chosen to do it. Other compilers may decide differently.

Retired 12/31/2016

Ok I haven't had an amd CPU lately to try xhost. It's reasonable to expect it to select sse3 or avx if supported on the build platform.

noting that msvc never uses parallel simd reductions or in openmp regions, you may expect small numerical differences dependent on Ifort fp-model setting.

If one of those is supported by /arch or -m, then yes, it will be selected. If not, then no, even if the processor supports those instructions. That is the intent, anyway, even on AMD. Sometimes we don't add /arch support for a new instruction set right away. I wrote the original code that detected CPU capabilities for /QxHost so I know how it's supposed to work. If it doesn't work we want to know about it.

Retired 12/31/2016

I just checked the compiler code. It will select AVX if the CPU and OS supports it, otherwise SSE4.2 is the highest level.

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today