Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenCL behavior when re-defining builtin math functions #152

Open
preda opened this issue Aug 30, 2024 · 0 comments
Open

OpenCL behavior when re-defining builtin math functions #152

preda opened this issue Aug 30, 2024 · 0 comments
Labels
device-libs Related to Device Libraries

Comments

@preda
Copy link

preda commented Aug 30, 2024

Consider the following example, which implements a complex multiply-add function named "mad" with a signature that clashes with the
builtin OpenCL math function mad(gentype, gentype, gentype)
(where gentype includes double2).

__attribute__((overloadable)) double2 mad(double2 a, double2 b, double2 c) {
  return (double2) (fma(a.x, b.x, fma(a.y, -b.y, c.x)), fma(a.x, b.y, fma(a.y, b.x, c.y)));
}

kernel void testKernel(global double2* out, global double2* in) {
  uint me = get_local_id(0);

  double2 a = in[3*me];
  double2 b = in[3*me + 1];
  double2 c = in[3*me + 2];
  out[me] = mad(a, b, c);
}

This example is compiled very differently by ROCm 6.1.3 and ROCm 6.2.0.
In both case it is accepted without errors or warnings.
The resulting compilation is:
With ROCm 6.1.3, the user-defined mad() is used,
with ROCm 6.2.0, the built-in mad() is used.

In particular the 6.2.0 behavior, where the user defined function is accepted without errors and silently ignored afterwards, is not acceptable IMO and represents a bug.

@lamb-j lamb-j added the device-libs Related to Device Libraries label Aug 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
device-libs Related to Device Libraries
Projects
None yet
Development

No branches or pull requests

2 participants