Jed Brown

I rebased this branch and will let CI run.

I see the Bazel job is [failing on main](https://github.com/EnzymeAD/Enzyme/actions/runs/11584501877) too. It's when building LLVM so must be unrelated to this PR.

Good catch, yes. @nafees01 This is an example in which the associated type you've been adding should be able to appear as a type constraint (without requiring a typed communicator)....

Good. I think one can still "cheat" with something like ```rs if rank % 2 == 0 { comm.all_reduce_into(&val_i32, &mut sum_i32, SystemOperation::sum()); } else { comm.all_reduce_into(&val_f64, &mut sum_f64, SystemOperation::sum()); }...

I'd be curious to test if you have a reproducer with the same MPI implementation, but I don't think rsmpi has anything (directly) to do with this behavior. In general,...

Note that a barrier does not affect behavior of a correct MPI program (you can delete them all and get correct results, unless you're communicating through side channels such as...

`panic!` must be doing some file descriptor tinkering or something. Replacing it with the two lines ```rs eprintln!("crashing only on root rank"); std::process::exit(101); ``` then I see the same behavior...

What about making the panic runtime use `MPI_Abort()`?

I'll close this because I don't think it's something rsmpi can or should change, though an application could. In general, one wants to avoid panics in MPI code.

@oxcrow Try building with `RUSTFLAGS='-C panic=abort' (or [put it](https://doc.rust-lang.org/cargo/reference/profiles.html#) in your profile). If that works like the C program, then this is the issue. Panics generally interact poorly with collective...