Open MPI v5.0.x does not support 32 bit

[jsquyres]

PMIx 4.2.x does not support 32 bit, and therefore Open MPI v5.0.x does not support 32 bit.

I do not think that this is necessarily a big deal, but I wanted to call attention to this to make sure we didn't accidentally make this decision without realizing it. Indeed, this is something we should:

1. Explicitly document in OMPI docs
2. Explicitly fail in configure if building in a 32 bit environment

Does anyone in the community have any strong feelings about supporting 32-bit environments for v5.0.x?

[awlauria]

32 bit builds are supported, but only with C11-capable compilers:
#8722

[rhc54]

Can you two please reconcile those two statements? I'm assuming at least one of you are basing your statement on having tested it - I know I have not.

[jsquyres]

I don't think that's right -- PMIx flat-out doesn't support 32 bit.

[rhc54]

It isn't philosophical but just happened that way. If someone needs it and wants to provide a patch for it, I am happy to take it

[awlauria]

That's where we left it as of a year and a half ago. That said it may no longer be accurate, and I don't really care one way or another.

I do agree that we need to make the final determination, and document it somewhere.

[jsquyres]

Let me clarify my comment -- it wasn't intended to be inflammatory. Right now, there are some compile errors with PMIx master and 32 bit (see below). No one has had the time to dig deep into these issues, and the presumption is that there are some code issues that make PMIx (at least master) not 32-bit clean. Since no one seems to care about supporting PMIx in 32 bit environments, this really hasn't been an issue.

This carried over to Open MPI a long time ago: we no longer run 32 bit builds in our CI.

So the question is: does OMPI v5.0.x care about 32 bit? If so, we can submit a PR to fix PMIx to be 32-bit clean (I'm sure it's do-able; it's just that no one has cared). As @rhc54 mentioned, it's not a philosophical issue at PMIx. If OMPI v5.0.0 doesn't care about 32 bit, then we need to what I mentioned in the initial description on this issue.

I think we're violently agreeing. 😄

---

If you care, I did a 32-bit OpenPMIx build on Ubuntu 22 this morning. This is the first compile error that comes up. Granted; it's just a warning, but PMIx builds with -Werror, so it causes the build to fail:

  CC       pmix_vmem.lo
pmix_vmem.c: In function ‘pmix_vmem_find_hole’:
pmix_vmem.c:173:47: error: passing argument 3 of ‘use_hole’ from incompatible pointer type [-Werror=incompatible-pointer-types]
  173 |                     return use_hole(0, begin, addrp, size);
      |                                               ^~~~~
      |                                               |
      |                                               size_t * {aka unsigned int *}
pmix_vmem.c:117:20: note: expected ‘long unsigned int *’ but argument is of type ‘size_t *’ {aka ‘unsigned int *’}
  117 |     unsigned long *addrp,
      |     ~~~~~~~~~~~~~~~^~~~~
pmix_vmem.c:181:67: error: passing argument 3 of ‘use_hole’ from incompatible pointer type [-Werror=incompatible-pointer-types]
  181 |                         return use_hole(prevend, begin - prevend, addrp, size);
      |                                                                   ^~~~~
      |                                                                   |
      |                                                                   size_t * {aka unsigned int *}
pmix_vmem.c:117:20: note: expected ‘long unsigned int *’ but argument is of type ‘size_t *’ {aka ‘unsigned int *’}
  117 |     unsigned long *addrp,
      |     ~~~~~~~~~~~~~~~^~~~~
pmix_vmem.c:188:67: error: passing argument 3 of ‘use_hole’ from incompatible pointer type [-Werror=incompatible-pointer-types]
  188 |                         return use_hole(prevend, begin - prevend, addrp, size);
      |                                                                   ^~~~~
      |                                                                   |
      |                                                                   size_t * {aka unsigned int *}
pmix_vmem.c:117:20: note: expected ‘long unsigned int *’ but argument is of type ‘size_t *’ {aka ‘unsigned int *’}
  117 |     unsigned long *addrp,
      |     ~~~~~~~~~~~~~~~^~~~~
pmix_vmem.c:239:52: error: passing argument 3 of ‘use_hole’ from incompatible pointer type [-Werror=incompatible-pointer-types]
  239 |         return use_hole(biggestbegin, biggestsize, addrp, size);
      |                                                    ^~~~~
      |                                                    |
      |                                                    size_t * {aka unsigned int *}
pmix_vmem.c:117:20: note: expected ‘long unsigned int *’ but argument is of type ‘size_t *’ {aka ‘unsigned int *’}
  117 |     unsigned long *addrp,
      |     ~~~~~~~~~~~~~~~^~~~~

There are a bunch more similar warnings which cause the build to fail.

I didn't look closely into these. If someone cares, I'm betting that they're fixable.

[awlauria]

Sorry yeah I didn't mean to sound snarky either.

Yeah I agree. I don't remember why we decided to leave the 32 bit support hanging around for certain compilers - maybe there was one distribution that still used it at the time? Since we don't have 32 bit mtt or a 32 bit pr build it is hard to maintain compliance, and unless we have an owner I don't know if it's worth keeping.

[awlauria]

Relevant old issue: #4157

I tried digging through the mailing list and couldn't find a recent reference to 32 bit builds....Though I may not be pushing the right buttons.

I think @hjelmn fixed the last breakage because it was simple to do, and we decided to keep it since it was 'easy'. But I could be wrong on that.

edit: Checked mpich - they still seem to at least build with 32 bit. I wonder if that factored in our decision making to keep it around.

[jsquyres]

Let's discuss at the Monday RM meeting + Tuesday community webex.

[jsquyres]

The conclusion we came to was: we'll ask if anyone in the community wants to maintain 32 bit. So far, we're unaware of anyone who wants to maintain it, and are also unaware of any customers who care about 32 bit. As such, we'll propose a PR that has configure fail for 32 bit environments (#11282). If no one continues to care, we'll merge that PR.

If that all goes through, the intent would be to let the 32-bit-builds-are-disabled behavior out into the world with v5.0.0 and let that get a bunch of time out in the real world before we actually remove any 32 bit infrastructure from Open MPI's code base. I.e., let's just do an easy thing to disable 32 bit builds, and see if anyone screams. If someone does, removing the configure block is easy enough. If "enough" time progresses and no one screams, we can talk about removing 32 bit infrastructure from within the OMPI code base.

[awlauria]

v5.0.x pr merged: #11334

@jsquyres did you want to close this?

[barracuda156]

The conclusion we came to was: we'll ask if anyone in the community wants to maintain 32 bit. So far, we're unaware of anyone who wants to maintain it, and are also unaware of any customers who care about 32 bit. As such, we'll propose a PR that has configure fail for 32 bit environments (#11282). If no one continues to care, we'll merge that PR.

If that all goes through, the intent would be to let the 32-bit-builds-are-disabled behavior out into the world with v5.0.0 and let that get a bunch of time out in the real world before we actually remove any 32 bit infrastructure from Open MPI's code base. I.e., let's just do an easy thing to disable 32 bit builds, and see if anyone screams. If someone does, removing the configure block is easy enough. If "enough" time progresses and no one screams, we can talk about removing 32 bit infrastructure from within the OMPI code base.

Sorry for being late to this, but I am interested to maintain 32-bit compatibility.