Fix printing of mlirUniformQuantizedSubChannelTypeGetNumBlockSizes in 32-bit machine.

[sdasgup3]

Fixes the issue reported in #120172 (comment)

cc @mgorny

[llvmbot]

@llvm/pr-subscribers-mlir

Author: Sandeep Dasgupta (sdasgup3)

Changes

Fixes the issue reporting in #120172 (comment)

---

Full diff: https://github.com/llvm/llvm-project/pull/133763.diff

1 Files Affected:

• (modified) mlir/test/CAPI/quant.c (+1-1)

diff --git a/mlir/test/CAPI/quant.c b/mlir/test/CAPI/quant.c
index 30f376ebeb112..be4595fd39e81 100644
--- a/mlir/test/CAPI/quant.c
+++ b/mlir/test/CAPI/quant.c
@@ -268,7 +268,7 @@ void testUniformSubChannelType(MlirContext ctx) {
           mlirTypeIsNull(illegalSubChannel));
 
   // CHECK: num dims: 2
-  fprintf(stderr, "num dims: %" PRId64 "\n",
+  fprintf(stderr, "num dims: %" PRIdPTR "\n",
           mlirUniformQuantizedSubChannelTypeGetNumBlockSizes(subChannel));
 
   // CHECK: axis-block-size-pair[0]: 0:1

[GleasonK]

LGTM. My main question was - should we just be using int64_t instead of intptr_t for the return type, but it looks like the way you currently have it is more in line with the existing "get num" APIs like intptr_t mlirUniformQuantizedPerAxisTypeGetNumDims(...) and the test

fprintf(stderr, "num dims: %" PRIdPTR "\n",
          mlirUniformQuantizedPerAxisTypeGetNumDims(perAxis));

[mgorny]

Thanks! I can confirm that it fixed the issue for me.