rolandschulz

Even though I see how this can be useful, it might cause confusion if a function called printf is behaving differently from the normal printf.

I said that this can cause confusion because it doesn't actual solve the problem. It just works around it for the one use case. But the actual problem (that implicit...

> IMO, passing to variadic functions is not a problem. It might be OK. It depends on what the variadic function is doing. The kind of issues we got with...

Does your use case require `vec` or can you use `marray`? If so why?

> I use vec because it provides interfaces to load/store/convert data. We probably should add a way to convert data (e.g. explicit cast marray of different types). Why use load/store...

I also can't reproduce the error. My versions: clang++: b59cd43a7ce29e20868fa51ef70a23b6d99145b7 device: gfx90a (MI200) rocm: 5.1.3 @al42and Is it reasonable easy for you to check whether you get the error also...

GROMACS version is aa-hwe-release-2022-dpcpp-hip. DPC++ not hipSYCL. @hqhy which version of clang++, device, and rocm are you testing with?

Using `__` is a solution in the sense that it guarantees that all code works independent of what weird macros are defined. But the ugly identifiers clearly impact readability of...

> You don't get to steal already-defined identifiers from the user just because they included your header; I think that's the key question whether that's true or not. I think...

I don't think this is a bug. Recursive function calls aren't allowed in device code. And there is no exception for constexpr. I think it is a reasonable request, that...