Incompatibility between nvcc expected and gcc compiled space structure (or something like that)
So I'm unclear how exactly I managed to break this specific thing, and both should be using the same compiler (or well, gcc-4.8 and g++-4.8).
Both use #include "space.h", and almost everything else regarding the struct that I can see should be fine.
The normal swift library does some stuff, up until the point I call the CUDA swift extension to create the GPU tasks.
The correct space structure is seen by the normal swift library, and (using printf) it outputs
s = {dim= {1.000000, 1.000000, 1.000000}, periodic = 1, hs = {<No data fields>}, gravity = 0, width = {0.083333, 0.083333, 0.083333}, iwidth = {12.000000, 12.000000, 12.000000}, cell_min = 8.250000e-02, dx_max = 0.000000e+00, cdim = {12, 12, 12,}, maxdepth = 0, nr_cells = 1728, tot_cells = 1728
The code continues, and then aborts at some check in the code. At this point I tell gdb to output the same space structure as it currently believes it to be:
$4 = {dim = {1, 1, 1}, periodic = 1, hs = {<No data fields>}, gravity = 1431655765, width = {0.083333333333333329, 0.083333333333333329, 12}, iwidth = {12, 12, 0.082500000000000004},
cell_min = 2.5463949491583268e-313, dx_max = 1.68155816e-44, cdim = {12, 0, 1728}, maxdepth = 1728, nr_cells = 0, tot_cells = 51249152,
i.e. it appears to be misaligned by 8 byes after the hs. To check this isn't just a gdb issue I added a breakpoint at the print statement:
$6 = {dim = {1, 1, 1}, periodic = 1, hs = {<No data fields>}, gravity = 0, width = {0.083333333333333329, 0.083333333333333329, 0.083333333333333329}, iwidth = {12, 12, 12}, cell_min = 0.082500000000000004,
dx_max = 0, cdim = {12, 12, 12}, maxdepth = 0, nr_cells = 1728, tot_cells = 1728
I currently have a workaround (I think) which is to redefine struct hydro_space {float empty;};
in hydro_space.h and currently (I think through luck) this appears to give the correct result. However if I used float empty[4]
then the alignment was still broken (but differently to before). I'm going to use this workaround for now, however I feel like it may be a problem again later.