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 petsc-maint at mcs.anl.gov
>>>> Always error on the side of sending too much information to petsc-maint at
>>>> mcs.anl.gov 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>
>>
>>
>>
>>
>
