loongarch64: fix segfaults in copy kernels and adjust dsyrk block size

[HecaiYuan]

On LA464, dsyrk produces incorrect results with specific block dimension combinations (e.g., 80×16), which causes dcholesky and dpotrf to fail on positive-definite matrices.

Reduce GEMM_P from 112 to 96 for LoongArch64 LA464 double-precision builds, so the blocking logic avoids generating the problematic size.

The following minimal C program was used to pinpoint the issue:

// test_dsyrk.c
#include <stdio.h>
#include <cblas.h>
#include <stdlib.h>

#define N 194
int main(){
    double *A = malloc(N*N*sizeof(double));
    double *B = malloc(N*N*sizeof(double));
    for(int j=0;j<N;j++){
        for(int i=0;i<j;i++) A[i + j*N] = (double)rand()/RAND_MAX - 0.5;
        A[j + j*N] = (double)rand()/RAND_MAX + 8.0;
        for(int i=j+1;i<N;i++) A[i + j*N] = 0.0;
    }

    double alpha = 1.0, beta = 0.0;
    cblas_dsyrk(CblasColMajor, CblasLower, CblasNoTrans, N, N, alpha, A, N, beta, B, N);

    for (int i = 0; i < N; i++) 
        printf("B[%d][%d] = %g\n", i, i, B[i + i*N]);

    free(A); free(B);
    return 0;
}

Compile and run:

gcc test_dsyrk.c -o testd_syrk -I. -L. -lopenblas -lpthread -lm
./test_dsyrk

After fix: all diagonal elements remain positive as expected.

[martin-frbg]

Sorry, I cannot seem to reproduce the problem on LA464 with the reproducer you provided ?
(Specifically I tried on 3C5000L, the one type Loongson has made available to OSS developers through the GCC Compile Farm)

[HecaiYuan]

Sorry @martin-frbg for not specifying the reproduction environment earlier – that may have caused confusion. These issues occur on the Loongson 3A5000 platform.
Here is my environment information (from lscpu):

Architecture:          loongarch64
  CPU op-mode(s):      32-bit, 64-bit
  Address sizes:       48 bits physical, 48 bits virtual
  Byte Order:          Little Endian
CPU(s):                4
  On-line CPU(s) list: 0-3
Model name:            Loongson-3A5000-HV
  CPU family:          Loongson-64bit
  Model:               0x11
  Thread(s) per core:  1
  Core(s) per socket:  4
  Socket(s):           1
  BogoMIPS:            5000.00
  Flags:               cpucfg lam ual fpu lsx lasx crc32 complex crypto lvz lbt_x86 lbt_arm lbt_mips
Caches (sum of all):   
  L1d:                 256 KiB (4 instances)
  L1i:                 256 KiB (4 instances)
  L2:                  1 MiB (4 instances)
  L3:                  16 MiB (1 instance)
NUMA:                  
  NUMA node(s):        1
  NUMA node0 CPU(s):   0-3

Regarding the first three commits, they fix bugs exposed in three separate test cases, respectively:

slinpack.goto
sgesv.goto
sgetri.goto

You can reproduce the issues by running the following commands in order – each command corresponds to one of the tests:

./slinpack.goto 100 2000 100
./sgesv.goto 100 2000 100
./sgetri.goto 100 2000 100

After running ./test_dsyrk, the output shows incorrect values (the diagonal elements of matrix B become abnormal starting from index 108):

B[0][0] = 94.5673
... (normal values omitted) ...
B[107][107] = 78.6449
B[108][108] = -2.65987
B[109][109] = 2.86062
... (many subsequent abnormal or zero values) ...
B[192][192] = 68.5539
B[193][193] = 66.4082

[martin-frbg]

Thank you - it turns out the problem was masked by the larger core count of the "C" model