[mpich-discuss] Cannot build mpich2-1.0.8p1 (nemesis) with PGI 8.0-4 on Linux x86_64

[Gus Correa]

Hi Dave, list

Thank you for all your effort to fix this problem.

Dave Goodell wrote:
> So I have some bad news, Gus.  I managed to locate an installation of 
> PGI-7.1-6 and got MPICH2-1.0.8p1 to compile and link using it with a few 
> tweaks.  Unfortunately the binary it generates always segfaults deep 
> down in MPI_Finalize because of some issue related to the inline 
> assembly register constraints.  It is possible that this issue could be 
> worked-around in our code or maybe it is resolved by the 8.X version, 
> but I don't have immediate access to it.  

Again, I wonder if the PGI developers wouldn't be interested in
this problem, and would perhaps offer some hints or fixes
(Maybe fixes need to be applied to their compiler too.)
After all, a number of their customers are MPICH2 users also,
and somehow this type of problem isn't happening with other compilers,
which is not good news for them.

> And even if we were to solve 
> that issue, I bet there is another one lurking behind it.
> 

We have PGI and Intel compilers because our processors are AMD Opteron,
and there have been cases where the Intel compiler is not friendly
to AMD hardware.
Also, in the past we used only PGI, but lately some codes stopped
compiling with PGI, or failed with runtime errors,
but would be happy to compile and run with Intel.
We have yet to try gfortran, with which I also built MPICH2.

> I'm afraid that I just have to say that 1.0.8* does not work with 
> ch3:nemesis and PGI.  We'll make sure to test it and try to get it 
> working for the upcoming 1.1.0 release instead.  As an alternative, 
> ch3:sock can be used in 1.0.8.
> 

We have dual-socket quad-core Opteron processor nodes (8 cores/node).
I am afraid ch3:sock may not be the best choice for this type of
"fat" node, where shared memory shortcuts (memcpy ?)
may work better than sockets.
Is this a wrong perception?

> Sorry,
> -Dave

Thank you again.

Regards,
Gus Correa
---------------------------------------------------------------------
Gustavo Correa
Lamont-Doherty Earth Observatory - Columbia University
Palisades, NY, 10964-8000 - USA
---------------------------------------------------------------------


> 
> On Apr 1, 2009, at 1:59 PM, Gus Correa wrote:
> 
>> Hi Scott, list
>>
>> Thank you for the suggestion.
>> Finding out the right compiler flags is always a pain,
>> so it is always worth trying what worked for other people.
>>
>> I tried to build with "-c9x" added to the CFLAGS.
>> Unfortunately the same error happens.
>>
>> According to Dave Goodell, the fix really requires making changes
>> in the configure script to handle the PGI compilers correctly.
>>
>> As far as I can tell, pgcc abides by the C99 standard
>> (or whatever part of it) by default.
>> Again, please correct me if I am wrong.
>>
>> If I do "pgcc -show" it gives me a long list of
>> compiler configuration variables, among which these two,
>> which suggest to me that the c99 (a.k.a. c9x in pgcc parlance)
>> language standard is the default:
>>
>> C99                 =-x 123 0x80000000
>> CARGS               Switches to C compiler
>>                    =-x 123 0x80000000 -x 123 4 -x 2 0x400 -x 119 0x20 
>> -alwaysinline /home/sw/pgi/8.0-4/linux86-64/8.0-4/lib/libintrinsics.il 4
>> C
>>
>> Thank you,
>> Gus Correa
>> ---------------------------------------------------------------------
>> Gustavo Correa
>> Lamont-Doherty Earth Observatory - Columbia University
>> Palisades, NY, 10964-8000 - USA
>> ---------------------------------------------------------------------
>>
>> Scott Atchley wrote:
>>> Hi Gus,
>>> I do not know if this is applicable or not, but we have the following 
>>> in our MPICH2-MX README:
>>>> If you are compiling with Portland Group compilers, you will need to 
>>>> also set:
>>>>
>>>> $ export CFLAGS=-c9x
>>> I do not remember why we added it and I have not tested it with the 
>>> latest Portland compilers.
>>> Scott
>>