On Mon, 27 Apr 2026 11:20:26 +0200 Drew Parsons <[email protected]> wrote:
Source: mumps
Version: 5.8.2-1
Severity: normal
X-Debbugs-Cc: [email protected]
User: [email protected]
Usertags: hppa
Control: block 1133815 by -1
Control: affects -1 src:mpich
Mumps build-time tests are failing on hppa
(32-bit, so using mpich)
https://buildd.debian.org/status/fetch.php?pkg=mumps&arch=hppa&ver=5.8.2-1&stamp=1777034697&raw=0
=== running c_example (serial) ===
Fatal error in internal_Allreduce: Invalid communicator, error stack:
internal_Allreduce(142): MPI_Allreduce(sendbuf=0xf947dfd0, recvbuf=0xf947dfc8,
count=1, MPI_2INTEGER, MPI_MINLOC, comm=0x0) failed
internal_Allreduce(45).: Invalid communicator
[unset]: PMIU_write error; fd=-1 buf=:cmd=abort exitcode=67710469 message=abort
:
system msg for write_line failure : Bad file descriptor
Debugging c_example.c show the error is occuring during the main dmumps_c run
(analyse, factorization and solve) id.job=6 at l.82,
/* Call the MUMPS package (analyse, factorization and solve). */
id.job=6;
dmumps_c(&id);
The same mumps code is running successfully with mpich on armf, i386
(including hurd) and x32, so it's hard to argue that it's a bug in
mumps itself.
Is it a bug in the hppa support of mpich?
Don't know, but did you take into account that hppa is 32-bit big-endian.
I see quite many warning like this:
warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type
‘int64_t’ {aka ‘long long int’} [-Wformat=]
This is quite dangerous.
On little-endian machines (armf, i386, x32..) %d will print the (correct) lower
32-bits.
But on hppa (big-endian), %d will print the (wrong) upper 32-bits of the
int64_t.
Just a guess....
Helge
--
debian-science-maintainers mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
