Bug
src/matmul/AxBRowIP.c loads both input matrices from identical files:
// values
while (fscanf(file, "%f", &val) == 1) {
aD[idx] = val;
bD[idx] = val; // ← same value as aD
idx++;
}
// column indices
while (fscanf(file1, "%d", &number) == 1) {
aC[idx] = number;
bC[idx] = number; // ← same index as aC
idx++;
}
// row pointers
while (fscanf(file2, "%d", &number) == 1) {
aR[idx] = number;
bR[idx] = number; // ← same pointer as aR
idx++;
}
The program always computes A × A, never a general A × B with two distinct sparse matrices.
Impact
- The core library operation (SpGEMM: multiply two different sparse matrices) cannot be exercised at all.
- There is no correctness signal:
A × A will produce a result, but it cannot detect bugs that only manifest when A ≠ B (e.g. dimension mismatches, wrong row-pointer indexing for B).
- All benchmark numbers reported are for the degenerate A² case, not representative of real workloads where A and B differ in structure and density.
Fix
Add a second set of input files (or accept file paths as CLI arguments) and load bD, bC, bR from them independently:
// Example: separate files for B
FILE *fileB_val = fopen("matrix_data/B_CSR_values.txt", "r");
FILE *fileB_col = fopen("matrix_data/B_CSR_colIdx.txt", "r");
FILE *fileB_row = fopen("matrix_data/B_CSR_rowPtr.txt", "r");
// ... load into bD, bC, bR independently
Or accept matrix paths as argv so any two matrices can be multiplied without editing source.
Note
This is distinct from issue #21 (CSR×CSR general support at the algorithm level). That issue addresses the kernel; this issue means even the existing kernel cannot be called with two different matrices due to the hardcoded file loading.
Bug
src/matmul/AxBRowIP.cloads both input matrices from identical files:The program always computes A × A, never a general A × B with two distinct sparse matrices.
Impact
A × Awill produce a result, but it cannot detect bugs that only manifest when A ≠ B (e.g. dimension mismatches, wrong row-pointer indexing for B).Fix
Add a second set of input files (or accept file paths as CLI arguments) and load
bD,bC,bRfrom them independently:Or accept matrix paths as
argvso any two matrices can be multiplied without editing source.Note
This is distinct from issue #21 (CSR×CSR general support at the algorithm level). That issue addresses the kernel; this issue means even the existing kernel cannot be called with two different matrices due to the hardcoded file loading.