More details to follow.

It seems we encountered this in before. #123 appeared to have fixed this very problem. Perhaps the host code isn't properly setting CUDA_SEPARABLE_COMPILATION to ON. I'll give that a try.

Thanks, @kennyweiss , for pointing out that past PR. @bmhan12 , @publixsubfan , your ideas would be welcome.

More vexing clues: the host code had CUDA_SEPARABLE_COMPILATION on, and also tried setting CMAKE_CUDA_SEPARABLE_COMPILATION. Neither seemed to help.

Further: this error showed up in a call to axom::primal::intersection_volume() as well. Digging deeper into that function, within clip_impl.hpp, at https://github.com/LLNL/axom/blob/develop/src/axom/primal/operators/detail/clip_impl.hpp#L427, if I comment out the body of that loop, the ptxas error still occurs. If I comment out the iterator over planes, the ptxas error goes away.

Still trying to make a reproducer. Host code build configuration is probably playing a part in this. Many thanks to @adayton1 for his help in digging.

Unsure if this could be the solution here, but I have run into a similar error message before.
This was while porting the mesh_tester example over to device.
What ended up "fixing" the issue was changing the default constructor, like in this commit from that PR.
Some problem related to default constructor and/or initializer list.

The error message I recorded before the fix looked like this:

ptxas /var/tmp/han12/tmpxft_0002790c_00000000-5_intersect_impl.ptx, line 374; error   : Illegal operand type to instruction 'ld'
ptxas /var/tmp/han12/tmpxft_0002790c_00000000-5_intersect_impl.ptx, line 374; error   : Unknown symbol '_param_0'
ptxas /var/tmp/han12/tmpxft_0002790c_00000000-5_intersect_impl.ptx, line 423; error   : Illegal operand type to instruction 'ld'
ptxas /var/tmp/han12/tmpxft_0002790c_00000000-5_intersect_impl.ptx, line 423; error   : Unknown symbol '_param_0'
ptxas fatal   : Ptx assembly aborted due to errors

Thanks for the suggestion, @bmhan12! I'll give it a try!

In the end, the fix was analogous to the one that @bmhan12 linked. The Hexahedron class has an array of eight Point<T, NDIMS>. The change was from this:

PointType m_points[NUM_HEX_VERTS];

to this:

PointType m_points[NUM_HEX_VERTS] {PointType {},
                                     PointType {},
                                     PointType {},
                                     PointType {},
                                     PointType {},
                                     PointType {},
                                     PointType {},
                                     PointType {}};

The fix also required Polyhedron::m_vertices to be initialized with thirty-two of PointType{}.

Another important detail: this failing build is the debug build. The optimized build is not affected.