[MPICH2-dev] problem with C++ binding library on IPF

[Ryzhykh, Alexey]

Hi,

Unfortunately Intel C++ behaves the same way as g++. Intel C++ compiler
must be fully compatible with gnu.

One possible way to solve this problem is to move the body of such
functions into header mpicxx.h.

But the implementation depends on internal mpich2 functions and so such
declarations should be added as well.

The easy way to detect gnu version is to check macros     __GNUC__,
__GNUC_MINOR__ and __GNUC_PATCHLEVEL__

For g++ version 3.2.3 these macros are set as __GNUC__=3 ,
__GNUC_MINOR__=2 , __GNUC_PATCHLEVEL__=3

Regards,

Alexey

 

________________________________

From: William Gropp [mailto:gropp at mcs.anl.gov] 
Sent: Friday, February 10, 2006 7:54 PM
To: Ryzhykh, Alexey
Cc: mpich2-dev at mcs.anl.gov; Supalov, Alexander; Voronov, German;
Shumilin, Victor
Subject: Re: [MPICH2-dev] problem with C++ binding library on IPF 

 

At 07:56 AM 2/10/2006, Ryzhykh, Alexey wrote:



Hi,
I am working at Intel Parallel System & Applications group
We faced the problem with using C++ binding library on IPF platforms.
We built mpich2 on Linux EL3.0 by GNU compiler version 3.2.3.
But MPI application was built on EL4.0 by GNU compiler  3.4.3
We got SIGSEGV on the call of static class function
MPI::File::Create_errhandler().
This function is declared in class File as:
static Errhandler Create_errhandler( Errhandler_fn* );
 
I found that the problem is due to differences in C++ ABI of g++ 3.2.3
and 3.2.4 compilers.
These compilers makes the call  of  Create_errhandler() in different
convention.
g++ 3.4.3  makes the call of the function with two arguments. First
implicit argument is address of object of class  Errhandler.
The second is for dummy argument Errhandler_fn.
g++ 3.2.3  generates the call of this function with only one argument
for passing Errhandler_fn.
The address of Errhandler  object  is passed through register r8.
I can provide the simple test and detail assembler analysis if you
needed.
 
The problem disappears when mpich2 and application are built on the same
platform by the same gnu compiler.
The problem is not happen on x86 and x86_64 platforms.
I am interested in your opinion of this problem.  
To have two versions of mpich2 compiled by gnu 3.2.3 and gnu 3.2.4 is
not convenient.


I agree that this is not convenient.  My opinion is that changing the
calling convention for routines should only be done with a major version
change of the compiler (e.g., 3.2.4 -> 4.0) .  I'm not sure what we can
do about this other than warn the users about this or suggest that the
use a more stable compiler (e.g., one of yours :) ).  Do you have any
recommendation?  Is there an easy way to at least detect the version
mismatch?

Bill




 
With best regards,
Alexey Ryzhykh,
---
Intel, Sarov
 
 
 
 
 
 

William Gropp
http://www.mcs.anl.gov/~gropp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mcs.anl.gov/mailman/private/mpich2-dev/attachments/20060210/abd40d8a/attachment.htm>