added gkregex for Windows issue

[nimgould]

@amontoison do you know why this happens. It seems to relate to the extra gk functions you added to metis to get rid of the -lregex issue.

../src/metis/include/gk_externs.h(19): warning #303: explicit type is missing ("int" assumed)
1303
  extern __thread int gk_cur_jbufs;
1304
         ^
1305

1306
../src/metis/include/gk_externs.h(19): error: expected a ";"
1307
  extern __thread int gk_cur_jbufs;
1308
                  ^
1309

1310
../src/metis/include/gk_externs.h(20): error: variable "__thread" is not a type name
1311
  extern __thread jmp_buf gk_jbufs[];
1312
         ^
1313

1314
../src/metis/include/gk_externs.h(20): error: "jmp_buf" has already been declared in the current scope
1315
  extern __thread jmp_buf gk_jbufs[];
1316
                  ^
1317

1318
../src/metis/include/gk_externs.h(20): error: expected a ";"
1319
  extern __thread jmp_buf gk_jbufs[];
1320
                          ^
1321

1322
../src/metis/include/gk_externs.h(21): error: variable "__thread" is not a type name
1323
  extern __thread jmp_buf gk_jbuf;
1324
         ^
1325

1326
../src/metis/include/gk_externs.h(21): error: expected a ";"
1327
  extern __thread jmp_buf gk_jbuf;
1328
                          ^

[amontoison]

I think that we just need to uncomment this block:
https://github.com/ralna/GALAHAD/blob/master/meson.build#L166-L174

Can you try it?
We always need to specify the preprocessing flag on Windows...

[nimgould]

OK, trying now

[nimgould]

Sme progress, the windowns/gcc combo now runs. Butthat broke some of the Linux builds as well (the intel ones). Any ideas?

[amontoison]

It seems related to Intel OpenMP. We need to add the OpenMP flag for C compilers. I only did it for C++ and Fortran.

[nimgould]

How do we see the results of the tests? Are they written somewhere ... the actions seem to mention testlogs, but I can't find that file - is it saved, and if so, where? It is impossible to see what is going wrong without getting output from the tests.

[Edit - Jari told me where to find this, so please ignore]

[nimgould]

Reading more about the openmp flags, it seems that \Qopenmp is for Windows ifort/icc but
-qopenmp is the flag for Linux. Since I don't understand the logic of the meson.build file well enough, maybe someone else can update this file?

[nimgould]

Is it possible to add debug flags to the actions, so that we can see the precise lines where things go wrong. E.g., the -g flag for gfortran, -g -traceback for ifort and ifx. I realise that this will slow things down, and should be removed when we are ready, but it would really help

[amontoison]

Is it possible to add debug flags to the actions, so that we can see the precise lines where things go wrong. E.g., the -g flag for gfortran, -g -traceback for ifort and ifx. I realise that this will slow things down, and should be removed when we are ready, but it would really help

It's already compiled in debug mode Nick.
It's only for CI.
By default it's the release mode (-O3).

[nimgould]

OK, Alexis. In that case where do the messages giving the lines on which the sequence of calls on a failing run get written to? It is usual when an exception occurs for the -g flag to provide this information. I don't see it.

[amontoison]

You can these messages in the artifacts at the bottom of the page ("Summary") for GitHub Actions:

• https://github.com/ralna/GALAHAD/actions/runs/9417093593

For CirrusCI, you just need to click on a build and then the folder icon with "log" at the top of the page:

• https://cirrus-ci.com/task/4542987441537024

[amontoison]

I have this kind of error with "Int64" builds:

================================== 291/405 ===================================
test:         GALAHAD:dgo+double+C / dgot_c_double
start time:   12:40:39
duration:     0.02s
result:       exit status 2
command:      UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MALLOC_PERTURB_=188 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 /private/var/folders/xc/tpssff9959345bnqq4c6tlww0000gn/T/cirrus-ci-build/builddir/dgot_c_double
----------------------------------- stdout -----------------------------------
 C sparse matrix indexing

 tests options for all-in-one storage format

----------------------------------- stderr -----------------------------------
At line 416 of file ../src/hash/hash.F90 (unit = 1)
Fortran runtime error: Unit number in I/O statement too large

[nimgould]

I saw that, but it is not enough information, -g usually gives the entire call, e.g.
error in a line x
called from b on line y
called from c on line z
(etc). It is vital to know which path the code took to get to the failure point.

I should say that I am suspicious about the C interface to dgo, it certainly looks
to me like a memory mismatch between fortran and C. The io unit should be 6,
and it isn't changed by the code, so it looks like a memory overwrite.

Once I know the path, I can start debugging ... very slowly as the action tests everything,
while all I want to di is test one routine with one compiler!

[nimgould]

But not for now, its Friday night and beer o'clock. Have a good weekend

[amontoison]

I need to finish my copies today.
Only one exercice is remaining 💪
I can work again on GALAHAD after.

Should we plan a meeting next week?
Have a good week end!!

[amontoison]

I saw that, but it is not enough information, -g usually gives the entire call, e.g. error in a line x called from b on line y called from c on line z (etc). It is vital to know which path the code took to get to the failure point.

I should say that I am suspicious about the C interface to dgo, it certainly looks to me like a memory mismatch between fortran and C. The io unit should be 6, and it isn't changed by the code, so it looks like a memory overwrite.

Once I know the path, I can start debugging ... very slowly as the action tests everything, while all I want to di is test one routine with one compiler!

Something is probably converted to Int64 in the Fortran or C side but not the other one.
It causes the misalignment.
The issue is to find it now.

[nimgould]

That is my guess too. I had a look earlier, but nothing stuck out. As I said, in the worst case, I'll simply print each argument in turn until I find the one filled with nonsense

[nimgould]

And yes, let's talk next week. How about Tuesday at 3PM (our time)

[amontoison]

Yes, it's fine for me.

[amontoison]

The issue was related to the old and deprecated Intel compilers on Windows...
I removed them.