- User Since
- Oct 28 2014, 11:11 AM (430 w, 3 d)
Sat, Jan 7
I see the following in LLVM's CMakeLists.txt:
I've tested it with Python 3.10, but shouldn't the CI fail my commit if it doesn't build on the minimum required version of Python?
Ping. This should be quite straightforward to review.
Ping. Is this a good idea or a controversial change?
Dec 22 2022
Dec 21 2022
Dec 20 2022
Another attempt to fix build on Windows.
Attempt to fix build on Windows.
Dec 19 2022
Attempt to fix flang build.
Dec 17 2022
Rebased onto main, with changes. Posting here for pre-merge CI checks.
Dec 15 2022
Dec 14 2022
I have commit access, no worries. Thanks for asking though! Will land momentarily.
Attempt to fix failing builds on Debian/Windows.
Dec 13 2022
Rebase onto main, address review comments, and attempt to fix build on
Dec 6 2022
Dec 5 2022
Landed as 2a1962542423.
Rebased onto main
Dec 3 2022
Wrap overly long line.
Committed as 1e33330e29e7.
Committed as 57c89359.
Dec 2 2022
Done, thanks :)
Address review comment by @NatashaKnk.
Hi @ftynse. I don't have commit access, so could you commit this change for me? Thanks.
Address @ftynse's review.
Dec 1 2022
Abandoned in favor of D139091.
Fix all flang compile errors.
Nov 30 2022
Missed /g in gsed's replace command
Thanks for the suggestion @kazu! I'll try to tackle that in a follow-up patch. For now, I've updated the diff to a programmatically-generated and safe-subset replacement of llvm::Optional to std::nullopt. We should have additional assurance from the CI. I understand your concerns about wanting super-safe steps, but D138934 involved a lot of manual work, and I'm not sure how we can fix that: will it be sufficient to trust the CI in that case?
Address review comment by @kazu. Now, the patch is generated by the
Address some build failures in flang. Unfortunately, it's very
difficult to build flang locally, as it takes a really long time.
I'm relying on the CI to tell us about additional failures.
Unfortunately, there is no easy solution to replacing None without the llvm:: prefix. I edited it by hand in a few places.
Address review comment by @kazu, git clang-format.
Use using llvm::None to fix compile-time errors.
Okay, I see a TensorToLinalg. However, there is a tosa.pad -> tensor.pad conversion in TosaToLinalg: for consistency, do you recommend moving this to TosaToTensor?
Rebased on top of D138984.
Nov 29 2022
Committed as 537137ece1d.
Committed as d32ec5232c9e.
Nov 27 2022
Hi. Ever since the migration to the git monorepo (I know, it's been a while), I don't have commit access. Could you kindly commit this and D138765 for me? Thanks.
Mar 10 2021
Mar 8 2021
Aug 7 2016
The file was auto-formatted via clang-format on save, via Atom. Sorry about the noise.
Nov 12 2015
Nov 10 2015
Nov 4 2015
It's actually an extra newline character that my editor automatically stripped out. *nix has the requirement that all lines must end with a newline character, not that a file must end with an empty line.
Okay, so run this on the current HEAD:
$ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug ../lldb -- The C compiler identification is AppleClang 188.8.131.5220053 -- The CXX compiler identification is AppleClang 184.108.40.20620053 -- Check for working C compiler using: Ninja -- Check for working C compiler using: Ninja -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler using: Ninja -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done CMake Error at cmake/modules/LLDBStandalone.cmake:37 (get_filename_component): get_filename_component called with incorrect number of arguments Call Stack (most recent call first): CMakeLists.txt:3 (include)