Hi,
it's been some time since and I'd like to give an update on the issue.
Sorry for the long mail!
On Thu, Jul 22, 2010 at 08:34:54AM -0400, Jeff Squyres wrote:
> If anything moves on this front, let me know and I can create a mercurial
> branch out on bitbucket.org and add the relevant configur
On Jul 22, 2010, at 5:17 AM, Manuel Prinz wrote:
> > Manuel -- do you have anyone that could work on this?
>
> Not at the moment. I could ask the porters if someone is willing to jump
> in. I unfortunately can't do it myself since I lack knowledge in that
> area.
Ditto.
> > I'd be happy to supp
Paul raises good points, too.
Manuel -- do you have anyone that could work on this? I'd be happy to supply
the configury magic to check and see if the GCC intrinsics are available
(assumedly outputing an AM_CONDITIONAL and/or AC_DEFINE to let the code base
know the decision) if someone else ca
Jeff -
I think falling back to GCC built-in if available is a rational idea. We've
been using them in another project without any problems. They are potentially
a bit slower than the hand-crafted assembly because they generally use full
memory barriers when we only need read memory barriers,
One thing to note is that the GCC atomic intrinsics are not always
implemented either. Use of an intrinsic that is unimplemented in a
given GCC version for a given platform will result in an link failure
(trying to call an "external" implementation that probably does not
exist). So, even if t
*** This mail mainly targeted at Brian and George ***
Debian maintainer Manuel Prinz raised an idea to me this morning:
The Debian community compiles and tests Debian on a huge range of hardware
platforms. It's been a long-standing issue that Open MPI doesn't support all
of them (e.g., MIPS, A