Re: [petsc-dev] [petsc-maint #68651] Re: [petsc-users] compile petsc error about mmintrin.h

29 Mar 2011

      Matt and Satish,

     How about on non-Windows systems configure  refuses to use Intel compilers if the appropriate environmental variables (that are obtaining by sourcing ccvars.sh  and friends) are not set?

For example in setCompilers.py at the lines

        if vendor == 'intel' or not vendor:
          yield 'icc'
          yield 'ecc'          
          yield 'win32fe icl'

        if vendor == 'intel' or not vendor:
          yield 'icpc'
          yield 'ccpc'          
          yield 'icc'
          yield 'ecc'          
          yield 'win32fe icl'

check for the existence of icc in the path, if it exists {check the needed environmental variables are set; if not set bitch and moan with a useful error message pointing to faq.html#libimf telling the person to do the proper sourcing.  If the environmental variables are set then do the yield.} 

  Without these checks we will continue to be haunted by this type of problem,

   Barry

On Mar 28, 2011, at 11:45 PM, Gong Ding wrote:
...
Sorry, its my problem. 
I didn't source iccvars.sh which set the include and lib path for intel compiler correctly.
For long time, I just include bin directory of intel compiler in my PATH, and use icc directly.
So stupid.
...
This is very strange.
1) The Intel compiler is making understanding this difficult. Normally when a compiler detects an error it gives the exact location where it found the problem, if it is in an include file then it shows where the include file was included from. Here it just prints the error message and goes on. I don't see why it is even including that include file. And why doesn't this problem get triggered in compiling other files???? Other files have the exact same includes so should have the same problem.
I think there may be a conflict between your machines setup and the Intel compiler.
2) Could you please try the following, move the file /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include/mmintrin.h to something like /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include/mmintrin.h.backup  and then run the make again, what happens?
You might need to start removing chunks of factimpl.c to see where it is triggering the error. You can change that file and then just run make in that directory until the compiler stops failing and that leads to the problem
Do you have access to some other Linux system you can compile on with the Intel compilers.
Barry
On Mar 27, 2011, at 12:48 AM, Gong Ding wrote:
...
The attachment is configure.log and make.log.
...
...
...
...
...
...
...
...
We need configure.log and make.log sent to [email protected]   Always error on the side of sending too much information to [email protected] rather than too few.
...
...
...
...
...
...
...
...
Barry
...
...
...
...
...
...
...
...
On Mar 25, 2011, at 1:57 AM, Gong Ding wrote:
...
...
...
...
...
...
...
...
...
On centos5 with icc version 11.1, factimpl.c produced many errors such as
...
...
...
...
...
...
...
...
...
...
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include/mmintrin.h(78): error: cast to type "__m64" is not allowed
...
...
...
...
...
return (__m64) __i;
...
...
...
...
...
...
...
...
...
...
This problem exists for a long time. In the petsc version of 3.1, I just comment out
...
...
...
...
...
#ifndef PETSC_HAVE_XMMINTRIN_H
...
...
...
...
...
#define PETSC_HAVE_XMMINTRIN_H 1
...
...
...
...
...
#endif
...
...
...
...
...
in the petscconf.h, and compile it.
...
...
...
...
...
...
...
...
...
...
However, petsc-dev has other dependence on mmintrin.h, comment out PETSC_HAVE_XMMINTRIN_H will product other problems.
...
...
...
...
...
How can I solve this problem?
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
BTW, it seems gcc works well.
...
...
...
...
...
...
...
...
...
...
Gong Ding
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
<configure.log.gz><make.log>

Barry Smith

tags

participants (1)