Barry Smith <[email protected]> writes: > I have switched back to using the > mpich-master-v3.0.4-106-g3adb59c.tar.gz I messed up and put that > change into a commit when I shouldn’t have. (I still miss the nice > bk gui that showed cleanly each change you were committing).
I never used the bk gui, but what is lacking in "git gui" or sourcetree? > But it is extremely worrisome that we need to use PARTICULAR > versions of MPI implementations to get clean compilers?!?!?! > > 1) Isn’t this fundamentally wrong? Like all dependencies, MPI implementations can have bugs. This was a bug and was fixed before it spent much time in the wild. The memory bug is more subtle and I have no idea why mpich-3.0.5 has not been released. > 1.5) Do we want to be in the business of saying, “if you use > compiler XX version YY then you need to use MPICH implementation > version ZZ, otherwise it won’t work? This is just a warning, but some MPI implementations have functions that crash at runtime. Others have space leaks (e.g., V1R2M0 on BG/Q). > 2) Shouldn’t we be portable to all the various MPI implementations that > are released at various times? > > 3) Do we need a configure test to properly handle the “broken” MPI > implementations? Lots of compilers have bugs too, including wrong code. I don't think it's maintainable to catalog all the bugs in all dependencies on all architectures. If something is buggy on a popular system, such that it creates complaints, we can work around it. Note that some packages like ParMETIS have major open bugs that people hit all the time, and we maintain patches that upstream inexplicably does not apply. In the case of MPI type tags, the user encounters the same warnings if they use MPI_2INT. Public shaming for known bugs that intentionally cannot be detected at configure time is one marginally-effective recourse.
pgpu7iAygY30I.pgp
Description: PGP signature
