rework c function pointers

[t-bltg]

Fix #688.

Not yet ready for review ;)

[Gnimuc]

Is it still a problem after merging JuliaInterop/Clang.jl#406 ?

[t-bltg]

JuliaInterop/Clang.jl#406 is only for fixing debugging and printing stuff.

The question I want to ask here is: "is it possible to modify node function arguments" ?

Or do we have to modify the underlying node exprs generated (this seems unfeasible, since information is lost on the way (like name(argument)) ?

[Gnimuc]

(this seems unfeasible, since information is lost on the way ...)

The only "elegant" way is to overload _get_func_arg .

[t-bltg]

This was fun actually.
Monkey patching _get_func_arg is horrible, but it works ...

Don't merge this ;)

[Gnimuc]

I'm trying to understand the root cause of #688. To me, it seems like Clang.jl doesn't handle typedef function prototype well for MPI's special usage.

[t-bltg]

By the way, is the output_ignorelist option from generator.toml broken ?

It doesn't filter the function definitions anymore ...

[Gnimuc]

Only on the master branch? This could be related: JuliaInterop/Clang.jl#403

[giordano]

Worked for me in #692

[t-bltg]

Only on the master branch?

Ha ok, we have to adjust the generator.toml regexes.

[t-bltg]

I'm trying to understand the root cause of #688. To me, it seems like Clang.jl doesn't handle typedef function prototype well for MPI's special usage.

Right, I think we'd better fix this (I'm going to try):
The prorotype in mpi.h is:

typedef int (MPI_Type_copy_attr_function)(MPI_Datatype, int, void *, void *, 
					  void *, int *);

[t-bltg]

I also need to add a test for #688.

Hum I still got:

julia> MPI.get_name(MPI.Datatype(Char))
""

@giordano, what is in your test.jl from #688 ?

[giordano]

I also need to add a test for #688.

Revert #689 😛

[giordano]

@giordano, what is in your test.jl from #688 ?

#684 (comment), which is simply extracted from

MPI.jl/test/test_allgather.jl

Lines 3 to 13 in 7da078c

	MPI.Init()
	comm = MPI.COMM_WORLD
	size = MPI.Comm_size(comm)
	rank = MPI.Comm_rank(comm)
	for T in Base.uniontypes(MPI.MPIDatatype)
	# test vector input
	A = ArrayType{T}([rank + 1])
	synchronize()
	C = MPI.Allgather(A, comm)

and before #689 that was running on Char as well. Also, MPIDatatype should be moved to the tests.

[giordano]

I can confirm the test script works with this branch of MPI.jl on Ookami with MVAPICH:

[mosgiordano@fj004 mvapich]$ srun -n 2 julia --project test.jl 
(rank, C) = (0, ['\x01', '\x02'])
(rank, C) = (1, ['\x01', '\x02'])
[mosgiordano@fj004 mvapich]$ srun -n 4 julia --project test.jl 
(rank, C) = (1, ['\x01', '\x02', '\x03', '\x04'])
(rank, C) = (2, ['\x01', '\x02', '\x03', '\x04'])
(rank, C) = (3, ['\x01', '\x02', '\x03', '\x04'])
(rank, C) = (0, ['\x01', '\x02', '\x03', '\x04'])
[mosgiordano@fj004 mvapich]$ srun -n 8 julia --project test.jl 
(rank, C) = (3, ['\x01', '\x02', '\x03', '\x04', '\x05', '\x06', '\a', '\b'])
(rank, C) = (2, ['\x01', '\x02', '\x03', '\x04', '\x05', '\x06', '\a', '\b'])
(rank, C) = (5, ['\x01', '\x02', '\x03', '\x04', '\x05', '\x06', '\a', '\b'])
(rank, C) = (6, ['\x01', '\x02', '\x03', '\x04', '\x05', '\x06', '\a', '\b'])
(rank, C) = (7, ['\x01', '\x02', '\x03', '\x04', '\x05', '\x06', '\a', '\b'])
(rank, C) = (1, ['\x01', '\x02', '\x03', '\x04', '\x05', '\x06', '\a', '\b'])
(rank, C) = (0, ['\x01', '\x02', '\x03', '\x04', '\x05', '\x06', '\a', '\b'])
(rank, C) = (4, ['\x01', '\x02', '\x03', '\x04', '\x05', '\x06', '\a', '\b'])

🚀

[t-bltg]

I can confirm the test script works with this branch of MPI.jl on Ookami with MVAPICH:

So

julia> MPI.get_name(MPI.Datatype(Char))
""

remains expected ?

[giordano]

So

julia> MPI.get_name(MPI.Datatype(Char))
""

remains expected ?

Sadly yes:

julia> using MPI

julia> MPI.Init(;threadlevel=:single)
MPI.ThreadLevel(0)

julia> MPI.get_name(MPI.Datatype(Char))
""

I get the same with MPICH_jll (and MVAPICH has the MPICH ABI, so this shouldn't be surprising).

I don't know if there is a way to query the "MPI equivalent type" for Char.

[t-bltg]

Let's reserve that fix (if there is any) for another PR.

[giordano]

I spoke too soon, I hadn't closed the julia session:

julia> using MPI

julia> MPI.Init(;threadlevel=:single)
MPI.ThreadLevel(0)

julia> MPI.Datatype(Char)
MPI.Datatype(Char): 

julia> MPI.Finalize()

[813476] signal (11.1): Segmentation fault
in expression starting at REPL[4]:1
MPIR_Call_attr_delete at /lustre/software/mvapich2/gcc11/2.3.6/lib/libmpi.so (unknown line)
MPIR_Attr_delete_list at /lustre/software/mvapich2/gcc11/2.3.6/lib/libmpi.so (unknown line)
Allocations: 644473 (Pool: 643990; Big: 483); GC: 1
Segmentation fault (core dumped)
[mosgiordano@fj-debug2 mvapich]$

As I mentioned in #688 (comment), lots of segfaults happen at MPI_Finalize-time.

Also, this PR does not solve #684, there's a load of other segmentation faults I get there, with both MVAPICH2 and Open MPI, this is just the first one I got with MVAPICH.

[t-bltg]

Also, this PR does not solve #684, there's a load of other segmentation faults I get there

Ok, I will remove the fix ....

EDIT: @giordano, you're too fast 😆

[t-bltg]

By the way, buildkite should have some timeouts, there are jobs running for a week now:
https://buildkite.com/julialang/mpi-dot-jl/builds/999
https://buildkite.com/julialang/mpi-dot-jl/builds/1001

[simonbyrne]

By the way, buildkite should have some timeouts, there are jobs running for a week now: https://buildkite.com/julialang/mpi-dot-jl/builds/999 https://buildkite.com/julialang/mpi-dot-jl/builds/1001

Not currently possible, unfortunately:
https://forum.buildkite.community/t/timeout-waiting-for-agent/188/4

[simonbyrne]

Ah, sorry i merged too early.

@giordano doesn't this include the change from #688 (comment)?

[giordano]

I think it does: https://github.com/JuliaParallel/MPI.jl/pull/693/files#diff-b01acb82d6f2ed53e2d5907924a42adb7162f0e91fbfe6beb70aaaae0d0e2c36R162 ?

[simonbyrne]

Great!