Add more ifx 2023 versions to CI

[vchuravy]

No description provided.

[vchuravy]

I think the strategy here should be that we support the 2023 versions of ifx, and otherwise strongly recommend the use of Flang. It is unsustainable to support ifx since their stance seems to be "the use of LLVM is internal and we won't tell you what version you get"

[joewallwork]

I think the strategy here should be that we support the 2023 versions of ifx, and otherwise strongly recommend the use of Flang. It is unsustainable to support ifx since their stance seems to be "the use of LLVM is internal and we won't tell you what version you get"

Okay sure, I can rework this PR for you to only consider the 2023 versions.

[joewallwork]

I think the strategy here should be that we support the 2023 versions of ifx, and otherwise strongly recommend the use of Flang. It is unsustainable to support ifx since their stance seems to be "the use of LLVM is internal and we won't tell you what version you get"

Okay sure, I can rework this PR for you to only consider the 2023 versions.

Done in 2132de6. Added a note on this in 1c5697d.

[joewallwork]

Hm I thought that it was just the 2023.2.x series causing issues (based on #2902 and CI errors here) but when I drop that I now get errors with 2023.1.0. Perhaps I've set up the matrix incorrectly - will debug here.

[joewallwork]

Apologies for the noise. I'll create a separate debug PR.

[joewallwork]

There appears to be no consistency with which errors are cropping up with ifx. I've seen failures with 2023.2.4 (debug mode), 2023.0.0 (debug mode), and here 2023.0.0 (release mode) and 2023.1.0 (release mode).

All of the failures are in allocatedArraySimple_with_explicit_interface, although sometimes with ForwardMode and sometimes with ReverseMode. Most of the time, they are at -O0 and look like

/usr/lib/llvm-16/bin/opt -load-pass-plugin=/home/runner/work/Enzyme/Enzyme/build/Enzyme/LLVMEnzyme-16.so -load=/home/runner/work/Enzyme/Enzyme/build/Enzyme/LLVMEnzyme-16.so --enzyme-attributor=0 -opaque-pointers=0 -passes=enzyme -o /dev/stdout
error: <unknown>:0:0: in function selectfirst__enzyme_autodiff_.t228p.t229p.t230p.t231p.t232p void (void (%"QNCA_a0$float*$rank1$"*, float*)*, float*, float*, float*, float*): Enzyme: failed to find fn to differentiate  call void (...) @selectfirst__enzyme_autodiff_(void (%"QNCA_a0$float*$rank1$"*, float*)* %arg0, float* %arg1, float* %arg2, float* %arg3, float* %arg4) - found - void (%"QNCA_a0$float*$rank1$"*, float*)* %arg0

Occasionally there is an error such as https://github.com/EnzymeAD/Enzyme/actions/runs/28177099241/job/83456332058?pr=2875 at higher optimisation levels, too.

Given that the Fortran code in the allocatedArraySimple_with_explicit_interface examples hasn't been changed and those tests had been passing for several years, presumably recent changes to the lit config have broken things. Let's try reverting changes to those files to check.

[joewallwork]

Okay I've got a fix now. Apologies for the debugging here as some of it turned out not to be relevant. Removing changes to the test files in de72418. Once #2905 is merged, we can merge main here and hopefully things will be back online.