Unknown option -xSSE4.2

[Seemanth_M_]

Hi all,

I am trying to compile a fortran code using ifort (version 10.1) in a linux machine (ia64) as follows

ifort -c -O3 -xSSE4.2 -ip my_code.f90

and I am getting the following warning

ifort: command line warning #10006: ignoring unknown option '-xSSE4.2'.

Could anyone give me a hint to avoid this warning?

(Although I could get the executable by compiling the code without the '-xSSE4.2' option, when I execute it, it stops with segmentation fault !!!)

Seemanth

[mecej4]

Are you sure that the system that you are running on uses an Itanium (ia64) CPU? If so, X86 and X64 options such as -xSSE4.2 do not apply to it.

If your system uses an AMD64/Intel64 CPU, check the different options allowed by your 10.1 compiler. It is not likely that a compiler will support instruction sets that were not yet defined when the compiler was released.

If your program seg-faulted after successful compilation, chances are high that there is a bug in the program. I suggest investigating and fixing that bug before you worry about optimization and choosing compiler options to speed up the program.

[Steven_L_Intel1]

-xSSE4.2 wasn't supported in version 10.1 - back then, the -x option used the single letter designation for instruction sets (and this version was before SSE4.2 anyway). Try -xS which is SSE4.1. I assume, as mecej4 did, that you didn't really mean IA-64 but rather "Intel 64".

[Seemanth_M_]

Dear mecej4 and Steve,

Thanks for your suggesions. I am sure that, I am using an Itanium CPU. Here is what 'uname -a' gives

Linux samudra 2.6.16.46-0.12-default #1 SMP Thu May 17 14:00:09 UTC 2007 ia64 ia64 ia64 GNU/Linux

I understand that -xSSE option is not available for itanium CPU.

Seemanth

[mecej4]

Seemanth wrote:
I am sure that, I am using an Itanium CPU

Given that, please note that many processor control/selection options, described in the documentation for the more ubituitous X86/X64 processor class, are irrelevant for your environment. If you do use those compiler options for some reason (you use a third-party makefile, for example), ignore the warning that is issued.

That clarification leaves us the seg-fault to address. There are numerous causes for its happening. You will need to narrow down the part of your code that causes the seg-fault. You can post the entire code, if it is small, or create a cut down reproducer and post it here.

[TimP]

consider reading the good advice about segfaults

https://software.intel.com/en-us/articles/determining-root-cause-of-sigsegv-or-sigbus-errors

[Seemanth_M_]

Dear mecej4,

I will be more specific now.

I was trying to install an ocean wave model ‘WAVEWATCH III (version 4.18)’ in my ia64 machine. The segmentation fault occurred, when I tried to run the model test case given by the model developers. Moreover, I could successfully run the same code (test case) in a X86_64 Linux machine using ifort version 14.0.2, with optimization flags (set through a comp file)

opt="-c -O3 -xSSE4.2 -ip  -module $path_m"

Hence I don’t think the seg fault is caused by any bug in the model code.

But, when I run the same code in  my ia64 machine with ifort v10.1 , the previous flags were not working and the model executable stops with segmentation fault. To solve this, I changed my flags to  

opt="-c -g -O3 -module $path_m"

and compiled and then executed the test case. In this case, although I am getting a warning in compilation (“optimization suppressed due to excessive resource requirements. Contact Intel Premier Support”), I could execute the test case without any seg fault, but with a low running speed compared to the model in X86_64 machine. So here are my queries,

1)How can I take care of this warning or should I neglect it?

2)Why my execution is too slow compared to that in a X86_64 machine and how can I speed up it in ia64 machine ?

[mecej4]

I have not had access to an Itanium machine for a number of years, but I remember that many models of the Itanium were rather sensitive to misalignment. If your code contains many common blocks, for instance, you may see if you can reorder the variables in each block. or add padding variables, or use a compiler option (if available) that can provide optimum alignment.

If there is an optimizer bug in the 10.1 compiler, you could try to localize the bug and compile just the problematic segment with a lower level of optimization. If that segment also happens to be a critical section in terms of execution speed, you are stuck with having to upgrade to a new version of the compiler or to use a different but compatible compiler (such as Gfortran) for the critical part.

How big is the package, and how long does it take to build? I looked at the page on the NOAA site, but it wants one to send an E-mail and wait for approval before downloading the source package.

[Seemanth_M_]

Thanks for the suggestions mecej4.

The WAVEWATCH III (v4.18) package is having a size of about 140 mb and it can be downloaded only by sending request to NOAA. Building of WW3 codes only takes a few minutes and to run the model, some test cases are also available with the package.

[TimP]

Seemanth M. wrote:

Dear mecej4,

I will be more specific now.

I was trying to install an ocean wave model ‘WAVEWATCH III (version 4.18)’ in my ia64 machine. The segmentation fault occurred, when I tried to run the model test case given by the model developers. Moreover, I could successfully run the same code (test case) in a X86_64 Linux machine using ifort version 14.0.2, with optimization flags (set through a comp file)

opt="-c -O3 -xSSE4.2 -ip  -module $path_m"

Hence I don’t think the seg fault is caused by any bug in the model code.

But, when I run the same code in  my ia64 machine with ifort v10.1 , the previous flags were not working and the model executable stops with segmentation fault. To solve this, I changed my flags to  

opt="-c -g -O3 -module $path_m"

and compiled and then executed the test case. In this case, although I am getting a warning in compilation (“optimization suppressed due to excessive resource requirements. Contact Intel Premier Support”), I could execute the test case without any seg fault, but with a low running speed compared to the model in X86_64 machine. So here are my queries,

1)How can I take care of this warning or should I neglect it?

2)Why my execution is too slow compared to that in a X86_64 machine and how can I speed up it in ia64 machine ?

You will be better off at -O2 without interprocedural optimization than running with optimization suppressed (possibly with separate compilation of source files), in case that allows performance critical functions to optimize normally.  If you don't care how long the compile takes, you can try override-limits, and hope the compile doesn't hang. 

Removing interprocedural optimization also sometimes avoids bad effects from source code bugs.  You really need those optimizations only where a procedure call occurs inside an inner DO loop.  Relying on the fact that a code runs on some platform is a poor way of concluding it doesn't have bugs, particularly if you didn't do any checking (e.g. -check compile and run).

My ia64 box died after about 5 years.