Skip to content

Conversation

@denialhaag
Copy link
Member

@denialhaag denialhaag commented Dec 4, 2025

Description

Fixes #1132

Checklist:

  • The pull request only contains commits that are focused and relevant to this change.
  • I have added appropriate tests that cover the new/changed functionality.
  • I have updated the documentation to reflect these changes.
  • I have added entries to the changelog for any noteworthy additions, changes, fixes, or removals.
  • I have added migration instructions to the upgrade guide (if needed).
  • The changes follow the project's style guidelines and introduce no new warnings.
  • The changes are fully tested and pass the CI checks.
  • I have reviewed my own code changes.

@denialhaag denialhaag self-assigned this Dec 4, 2025
@denialhaag denialhaag added minor Minor version update packaging Anything related to Python packaging labels Dec 4, 2025
@codecov
Copy link

codecov bot commented Dec 4, 2025

@denialhaag denialhaag added extensive-cpp-ci Adding this label indicates that extensive C++ CI runs should be started for this PR. and removed extensive-cpp-ci Adding this label indicates that extensive C++ CI runs should be started for this PR. labels Dec 4, 2025
@denialhaag denialhaag linked an issue Dec 4, 2025 that may be closed by this pull request
@denialhaag denialhaag removed the extensive-cpp-ci Adding this label indicates that extensive C++ CI runs should be started for this PR. label Dec 5, 2025
@burgholzer burgholzer added the extensive-cpp-ci Adding this label indicates that extensive C++ CI runs should be started for this PR. label Dec 6, 2025
burgholzer added a commit to munich-quantum-software/setup-mlir that referenced this pull request Dec 6, 2025
Testing in
[`mqt-core`](munich-quantum-toolkit/core#1356)
has revealed that using LTO leads to problems when compiling with
different compilers than the ones being used to compile the static
libraries.

This PR disables the LTO option for macOS arm64, which was the only
setting where it was enabled.

This also directly prepares a release, which should allow us to test the
actions capabilities of picking the latest released version of a
particular LLVM tag.
@denialhaag denialhaag removed the extensive-cpp-ci Adding this label indicates that extensive C++ CI runs should be started for this PR. label Dec 22, 2025
burgholzer added a commit that referenced this pull request Dec 31, 2025
## Description

This PR copies over some changes from
#1356 so that the
latter becomes a bit leaner and more focused on relevant changes.

## Checklist:

- [x] The pull request only contains commits that are focused and
relevant to this change.
- [x] ~I have added appropriate tests that cover the new/changed
functionality.~
- [x] ~I have updated the documentation to reflect these changes.~
- [x] ~I have added entries to the changelog for any noteworthy
additions, changes, fixes, or removals.~
- [x] ~I have added migration instructions to the upgrade guide (if
needed).~
- [x] The changes follow the project's style guidelines and introduce no
new warnings.
- [x] The changes are fully tested and pass the CI checks.
- [x] I have reviewed my own code changes.

---------

Signed-off-by: burgholzer <burgholzer@me.com>
Co-authored-by: burgholzer <burgholzer@me.com>
@burgholzer burgholzer added the extensive-cpp-ci Adding this label indicates that extensive C++ CI runs should be started for this PR. label Jan 1, 2026
@burgholzer
Copy link
Member

Okay, short summary of the latest findings here:

  • Compiling with gcc under macOS seems impossible with the current setup as there is an inherent incompatibility between the LLVM build that used AppleClang and the gcc build (they do use different C++ stdlib implementations by default, so I suppose this makes sense). Either we remove gcc builds entirely on macOS and add this to the documentation somewhere, or we try to provide additional LLVM builds on macOS compiled with gcc. I'd have a slight tendency to simply remove them.
  • the macOS-14 clang failures are apparently due to the clang version on macos-14 runners being too old to properly support C++20, in particular lambdas with structured bindings. We could work around this by rewriting the respective parts of the code or we could remove the runners from the matrix and declare the compiler version as not supported. The reason the MLIR tests worked here was simply that the MLIR tests where running on macos-15 with a newer version of AppleClang.
  • the Windows release builds fail in the QIR runner tests. This seems fixable and is probably due to some path logic.
  • the Windows debug builds all fail because of the mixture of LLVM libraries compiled in release mode and the project being compiled in debug mode. This triggers several errors because the respective C++ runtimes are not ABI compatible. For these builds to succeed, we need debug builds of LLVM, which I am trying to add in ✨🚸 Add Debug builds of the LLVM toolchain for Windows and optimize distributionΒ munich-quantum-software/portable-mlir-toolchain#4

The rest seems to work just fine already πŸ™ŒπŸΌ

@burgholzer burgholzer force-pushed the enable-mlir branch 5 times, most recently from f08ff04 to 3ecf0db Compare January 4, 2026 20:40
denialhaag and others added 19 commits January 7, 2026 17:26
Remove dedicated MLIR tests workflow and update workflows

Signed-off-by: burgholzer <burgholzer@me.com>
…tions

Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
Signed-off-by: burgholzer <burgholzer@me.com>
Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
…ndows

Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
…tions)`

Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
Signed-off-by: burgholzer <burgholzer@me.com>
Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
Signed-off-by: burgholzer <burgholzer@me.com>
Signed-off-by: burgholzer <burgholzer@me.com>
@burgholzer
Copy link
Member

Okay, given how we already merged the dialect redesign PR, which should not be part of v3.4, I am also going to merge this PR as soon as the CI is green in order to not have it sit around for too long and become stale again.
I'll try to get the stable v3.x branch set up afterwards as soon as possible.

@burgholzer burgholzer merged commit e1bd396 into main Jan 8, 2026
307 of 331 checks passed
@burgholzer burgholzer deleted the enable-mlir branch January 8, 2026 10:59
burgholzer added a commit that referenced this pull request Jan 8, 2026
## Description

This PR copies over some changes from
#1356 so that the
latter becomes a bit leaner and more focused on relevant changes.

## Checklist:

- [x] The pull request only contains commits that are focused and
relevant to this change.
- [x] ~I have added appropriate tests that cover the new/changed
functionality.~
- [x] ~I have updated the documentation to reflect these changes.~
- [x] ~I have added entries to the changelog for any noteworthy
additions, changes, fixes, or removals.~
- [x] ~I have added migration instructions to the upgrade guide (if
needed).~
- [x] The changes follow the project's style guidelines and introduce no
new warnings.
- [x] The changes are fully tested and pass the CI checks.
- [x] I have reviewed my own code changes.

---------

Signed-off-by: burgholzer <burgholzer@me.com>
Co-authored-by: burgholzer <burgholzer@me.com>
(cherry picked from commit 70b9d1f)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

extensive-cpp-ci Adding this label indicates that extensive C++ CI runs should be started for this PR. major Major version update packaging Anything related to Python packaging

Projects

None yet

Development

Successfully merging this pull request may close these issues.

πŸ“¦ MLIR - Enable by default and package MLIR/LLVM in Releases

3 participants