Failing MLIR test caused by GCC 13 miscompilation
- Dominant language
- LLVM
- Stars
- 40.5k
- Forks
- 18.7k
- PR merge metrics
- PR metrics pending
Description
Potentially related issue: #76750.
I have been seeing for some weeks the following failing MLIR Lit test, which didn't seem to reproduce by the buildbots so I assumed to be a local misconfiguration:
```
$ ninja check-mlir
[70/71] Running the MLIR regression tests
FAIL: MLIR :: Dialect/Shape/canonicalize.mlir (83 of 3464)
******************** TEST 'MLIR :: Dialect/Shape/canonicalize.mlir' FAILED ********************
Exit Code: 1
Command Output (stdout):
--
# RUN: at line 1
llvm-project/build/bin/mlir-opt -split-input-file -allow-unregistered-dialect -canonicalize="test-convergence" llvm-project/mlir/test/Dialect/Shape/canonicalize.mlir | llvm-project/build/bin/FileCheck llvm-project/mlir/test/Dialect/Shape/canonicalize.mlir
# executed command: llvm-project/build/bin/mlir-opt -split-input-file -allow-unregistered-dialect -canonicalize=test-convergence llvm-project/mlir/test/Dialect/Shape/canonicalize.mlir
# executed command: llvm-project/build/bin/FileCheck llvm-project/mlir/test/Dialect/Shape/canonicalize.mlir
# .---command stderr------------
# | llvm-project/mlir/test/Dialect/Shape/canonicalize.mlir:1069:17: error: CHECK-NEXT: expected string not found in input
# | // CHECK-NEXT: shape.const_witness true
# | ^
# | :706:47: note: scanning from here
# | func.func @cstr_broadcastable_scalar_unranked(%arg0: tensor<*xf32>, %arg1: tensor) {
# | ^
...
```
Looking into it, I was able to pin down the cause to be the compiler used to build LLVM, and tracked down the patch causing this to start triggering to 9aaf0b89f5ab3c84f8ad24213992a8158d344b96. In particular, the NFC in [mlir/lib/Dialect/Shape/IR/Shape.cpp](https://github.com/llvm/llvm-project/blob/0cecacd971a5471803b79f2b4a976ce75a2539b2/mlir/lib/Dialect/Shape/IR/Shape.cpp#L816). Replacing back the `llvm::map_to_vector(...)` call with `llvm::to_vector(llvm::map_range(...))` makes the test pass again.
Apparently, there's some optimization that GCC does to the `anyChange` captured local variable that causes it to not get updated by the `canonicalizeOperand` lambda ran while initializing the vector. One way that I was able to confirm this was to just declare the `anyChange` variable as `volatile`, which also fixes the problem.
Steps to reproduce:
```
$ c++ --version
c++ (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cmake -G Ninja ../llvm -DCMAKE_BUILD_TYPE=RelWithDebInfo -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_BUILD_TESTS=ON -DLLVM_INCLUDE_TESTS=ON -DLLVM_TARGETS_TO_BUILD='X86' -DLLVM_ENABLE_ASSERTIONS=ON -DCMAKE_C_COMPILER_LAUNCHER=/usr/bin/ccache -DCMAKE_CXX_COMPILER_LAUNCHER=/usr/bin/ccache -DLLVM_ENABLE_PROJECTS='llvm;mlir' -DLLVM_INSTALL_UTILS=ON -DBUILD_SHARED_LIBS=ON -DCMAKE_CXX_STANDARD=17 -DLLVM_RUNTIME_TARGETS='default'
$ ninja && ninja check-mlir
```
I imagine this might be causing other silent problems elsewhere, not sure if there's anything to be done here or if we just avoid using that version of GCC to build LLVM.
Contributor guide
Research direction
Reproduce the failure with GCC 13 using the reported CMake configuration and `ninja check-mlir`. Inspect `mlir/lib/Dialect/Shape/IR/Shape.cpp` around the `llvm::map_to_vector` change in commit `9aaf0b89f5ab3c84f8ad24213992a8158d344b96`, then run `mlir/test/Dialect/Shape/canonicalize.mlir`. Done means explaining the miscompilation and establishing a fix or supported workaround without breaking the test.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cmake, cpp
- Domain
- build-system, compilers, testing-qa
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100