llvm / llvm/llvm-project

[flang][build] flang 23.1.0 build failing due to MLIR 22 bits being included: CMakeLists.txt inconsistency?

Open
#220,239 1 comment 0 reactions 0 assignees View on GitHub
build-problem flang
Dominant language
LLVM
Stars
40.5k
Forks
18.7k
PR merge metrics
PR metrics pending

Description

#### Build failure

While trying to compile a well-featured (projects lldb,lld,clang,mlir,flang and runtimes libcxx;libcxxabi;compiler-rt;libunwind;openmp;flang-rt) 23.1.0 ecosystem on my machine from a 22.1.8 installed one, I got an:
```
use of undeclared identifier 'getEmptyKey'

In file included from /home/bas/tmp/llvm-project-llvmorg-23.1.0/flang/include/flang/Optimizer/Dialect/Support/FIRContext.h:20:
In file included from /usr/local/clang+flang+libcxx+lld+lldb+omp+rt-22.1.8/include/mlir/Dialect/LLVMIR/LLVMAttrs.h:17:

```

#### Cause?

This looks to be due to **flang's build system mixing up headers from the local build tree (23.1.0) with the system ones (22.1.8)** (`getEmptyKey()` was widely used in mlir classes in version 22.1.8, but have been removed in 23.1.0 after f7f6e6f4011252)

I'm especially puzzled by **all [cross-project includes using `"…"`](https://github.com/llvm/llvm-project/blob/b1d1dcd3b15ed8a8666e88e7ac6743ea30360dd6/flang/include/flang/Optimizer/Dialect/Support/FIRContext.h#L20) while `CMakeLists.txt` [uses `include_directories(SYSTEM`](https://github.com/llvm/llvm-project/blob/b1d1dcd3b15ed8a8666e88e7ac6743ea30360dd6/flang/CMakeLists.txt#L176)**, generating a `-isystem` instead of a `-I`.

#### Cleanup?

Wouldn't it be more consistent to have either:
- all `mlir` and `llvm` includes under the `#include <…>` form instead of `"…"`?
(but `mlir`'s self-includes are in `"…"` form. That would lead down the rabbit hole)
- or `SYSTEM` removed from `flang/CMakeLists.txt`?
(but its use is justified to [prevent non-flang warnings](https://github.com/llvm/llvm-project/blob/5fa2c092ec28173562fa6f91023aaccf12eec526/flang/CMakeLists.txt#L187): is it the historical reason?)

Not that I'm familiar with `#include` subtleties, but choosing `-isystem` over `-I` seem to have effects both on warnings and on lookups, two goals that conflict here.

#### Context details

- In fact, due to being unable to build a full-fledged ecosystem in one shot, I make two passes per version (built 22.1.8 with only clang, installed it to `/usr/local`, then 22.1.8 with all aforementioned projects, installed it, then 23.1.0 with only clang, installed it, and was trying to build 23.1.0 with all projects).
- `/usr/local/include`, `…/bin` and `…/lib` symlink to the last installed version's corresponding directory, so everything pointed to the 23.1.0 install (notably `clang++`), except for `/usr/local/include/mlir` that still pointed to the full 22.1.8, as its symlink wasn't overwritten by the mlir-less 23.1.0 install.

Contributor guide

Open the contributing guide

Research direction

Start with flang/CMakeLists.txt and flang/include/flang/Optimizer/Dialect/Support/FIRContext.h, then inspect the generated compiler include paths for a build using the described installed versions. Reproduce with the stale /usr/local/include/mlir symlink and compare it with a clean installation; done means the source of the mixed MLIR headers and any required build-system change are established.

Written by the indexing model from the issue text.

Assessment

Tech stack
cmake, cpp
Domain
build-system, compilers
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.