Test failure with qasm/0.2.12

[vrpascuzzi]

Failing tests on latest 2283e40 with qasm/02.12.

Test machine

• Apple M1 Max
• Ventura 13.1
• Apple clang version 14.0.0 (clang-1400.0.29.202)
  for architecture arm64e (Mach-O 64-bit executable arm64e)

Steps to reproduce

$ . conan_deps.sh
$ cd build && \
    conan install .. -pr macos_arm64_apple-clang_14_debug \
    -o qasm:shared=True --build=missing --build=gtest
$ cmake ../ -G "Ninja" -DCONAN=ON -DINSTALL_CONAN_DEPS=OFF \
    -DCMAKE_BUILD_TYPE=Debug
$ ninja check-tests

Partial output

<...>

[2/3] Running the QSS Compiler Core regression tests
-- Testing: 122 tests, 10 workers --
Testing:  0.
FAIL: QSS Compiler Core :: Frontend/OpenQASM3/bitstring-init.qasm (6 of 122)
******************** TEST 'QSS Compiler Core :: Frontend/OpenQASM3/bitstring-init.qasm' FAILED ********************

<...>

File: "/Users/vrpascuzzi/devel/ibm-q-restricted-system/qic-rta-driver/compiler/qss-compiler/test/Frontend/OpenQASM3/bitstring-init.qasm", Line: 28, Col: 13 Assignment may result in truncation.
Assertion failed: (getSignificantBits() <= 64 && "Too many bits for int64_t"), function getSExtValue, file APInt.h, line 1482.

<...>

Full log with stack dump: err-test-bitstring-init.qasm.log

[mhillenbrand]

That looks similar (or a regression of) what I fixed in upstream MLIR commit llvm/llvm-project@1ef32e7

For constant ops from arithmetic constants, MLIR chooses SSA value names that reflect the constant. That failed for ints with > 64 bits as the function that derived that name used a shortcut that did not apply (and assert(), as here) for ints with more than 64 bits.

[mhillenbrand]

My fix for upstream MLIR is not included in LLVM 14.0.6, yet we have backported to the branch of LLVM 14.0.6 that we use internally. That would explain why we see this in these CI runs - they use vanilla LLVM, right?!

[mhillenbrand]

Two workarounds come to mind:

• applying the fix as a patch to the build of LLVM in the CI
• disabling the test (as expected to fail) until we have updated to LLVM 15 (which includes the fix).

[vrpascuzzi]

Thanks, @mhillenbrand. I'm a proponent of (1), applying the fix as part of the build--unless we're planning to have LLMV-15 sometime soon.

[taalexander]

These have now been set to expected failures may we close?