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

[Gus Correa]

Hi Dave, list

Dave: Thank you very much for the configure.in
patch and for your help.

I applied the patch, did "make distclean", deleted all old
build files and directories, configured again, did make again.
However, I still get the same exact error on the make phase.

Somehow the preprocessor macro HAVE_GCC_AND_X86_64_ASM
continues to be undefined in src/include/mpichconf.h.
Likewise HAVE_GCC_ATTRIBUTE is also undefined.
I guess the lack of HAVE_GCC_AND_X86_64_ASM
is what eventually leads to the error.

By contrast on my "Gnu only (gcc,g++,gfortran)) build,
on my "Intel only (icc, icpc, ifort) build,
and on my two hybrid (Gnu+Intel and Gnu+PGI) builds,
both macros (HAVE_GCC_AND_X86_64_ASM and HAVE_GCC_ATTRIBUTE)
are defined as 1 on the src/include/mpichconf.h file.

There may be more that needs to be patched in configure.in, I'd guess.

I will email to you off list the output of configure,
config.log, and src/include/mpichconf.h

Many thanks again.

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

Dave Goodell wrote:
> On Mar 30, 2009, at 8:02 PM, Gus Correa wrote:
> 
>>> Did you successfully build the original mpich2-1.0.8 (non-patch) 
>>> release with these same PGI compilers?
>>
>> Since you asked, I tried mpich2-1.0.8 (non-patch) with PGI 8.0-4.
>> It fails with the same exact error.  :(
> 
> As I suspected.  In a way this is good because it means that we didn't 
> break anything in our small p1 patch ;)
> 
>> I also tried to replace PGI 8.0-4 with PGI 7.2-5,
>> and build mpich2-1.0.8p1 (patch).
>> No difference whatsoever, same exact error again :(
> 
> Not surprising.  In looking at your configure output and the 
> configure.in from MPICH2-1.0.8p1, it's clear that the PGI compilers 
> won't ever work without a modification.  We make an explicit check for 
> either gcc (by any name) or icc (only named "icc") before checking for 
> inline assembly.  So when CC=pgcc we don't even check for inline 
> assembly capability.
> 
> Please try the attached patch to configure.in and let me know if this 
> solves your problem.  This area of the configure.in is a hack and this 
> patch is just another hack on top of that, but it might get you unstuck 
> for now.  To apply the patch, put it in the same directory as the 
> top-level configure.in and run "patch -p1 < pgcc_atomics.patch".
> 
>> FYI, I also tried a hybrid build of mpich2-1.0.8 (patch),
>> using Gnu gcc/g++ and PGI pgf90 release 8.0-4.
>> This one builds correctly, no error! :)
>>
>> So, somehow the problem may be in using pgcc instead of gcc, right?
>> Wouldn't the PGI developers be interested in giving you
>> a hand here?
> 
> They might be interested and willing, but the bug is all on our side, 
> I'm afraid.
> 
>>> In the mean time you could install one of the other channels such as 
>>> ch3:sock for the PGI-compiled version.  The intranode performance 
>>> won't be as good but it should work just fine.
>>
>> I can, but I wonder if this will bring in other type of problems.
>> Not my direct experience, but other people reported runtime problems
>> with the ch3:sock on x86_64 and recent kernels.
>> See this thread:
>>
>> http://marc.info/?l=npaci-rocks-discussion&m=123175012813683&w=2
>>
>> On the other hand, nemesis seems to work.
> 
> Hmm... well, a substantial number of bugs were fixed between 1.0.7 and 
> 1.0.8.  I believe that ch3:sock should be very stable in 1.0.8 (modulo 
> some heavy dynamic process usages).  In fact, in 1.0.8 I suspect that 
> ch3:sock might be more stable than ch3:nemesis.  The main reason to use 
> nemesis in 1.0.8 is for improved intranode performance.
> 
> -Dave
> 
>