I think the only hard decision I had to make here has to do with the definition of HIPSYCL_BUILTIN_GENERATOR_BINARY_T_INT.
I did not template the second argument and instead explicitly locked it to int to avoid collision/ambiguity with HIPSYCL_BUILTIN_GENERATOR_BINARY_T_GENINT.

Can you elaborate on what your concern is here? You have the two overloads once for genint and once for int as required by the spec. Is it because there might be a collision between the explicit int overload and the genint overload in case it's called with int argument?

I think the only hard decision I had to make here has to do with the definition of HIPSYCL_BUILTIN_GENERATOR_BINARY_T_INT.
I did not template the second argument and instead explicitly locked it to int to avoid collision/ambiguity with HIPSYCL_BUILTIN_GENERATOR_BINARY_T_GENINT.

Can you elaborate on what your concern is here? You have the two overloads once for genint and once for int as required by the spec. Is it because there might be a collision between the explicit int overload and the genint overload in case it's called with int argument?

Yeah, if we template the second argument then, e.g. on calls where both the floating-point and the integer arguments are scalars, there’d a collision and the compiler would complain of ambiguity. Like this, that risk doesn’t exist because the compiler will always choose the most specialised template.

It wasn’t so much a concern, but rather me pointing out a design choice, so you could double check it. :) You are right this covers the spec, that’s no accident. :) But I’ve noticed that sometimes we’re a bit more lenient and allow generic integral types, not just int.

Do you think it would make sense to also add a test case here?

Do you think it would make sense to also add a test case here?

Done.

Seems like there is an issue with vector types? https://github.com/OpenSYCL/OpenSYCL/actions/runs/4872132257/jobs/8689939849?pr=962

Seems like there is an issue with vector types? https://github.com/OpenSYCL/OpenSYCL/actions/runs/4872132257/jobs/8689939849?pr=962

Thanks, yes, this was caused by 20043bd and I adopted the suggested change there of using an explicit cast.
I've also fixed some floating-point imprecisions that were caught by the new GPU CI tests!
Should be good to go. :-)