-
-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LLVM Flang 17 #28
LLVM Flang 17 #28
Conversation
* add lit * don't build tests * adapt bld.bat * reduce parallelism in `cmake --build` * build shared libs * use cos7 sysroot * host-depend on llvm/libclang-cpp for run-exports * use flang-new for now
* use CMake modules from LLVM source * set correct path for mlir-tblgen * use relative paths in bld.bat * add mlir as a build-dep when cross-compiling * don't enable -Werror on windows * need newer glibc
* add patch to ensure compiler-rt gets linked on windows/unix directly (patching HandleCompilerRT did not work) * remove -Werror also on unix (fails on osx) * run-depend on sysroot on linux * also use -DCMAKE_MODULE_PATH on unix
* add build env for outputs; for strong run-exports and because windows expects it * add ninja to install flang * avoid clobbering libs in other outputs * remove extra call in win flang tests * remove host-deps of libfortran-main * run-depend on compiler-rt for libflang on windows * depend on conda to deduplicate already-installed files * clean-up libfortran-main
for some silly reason, conda-build insists on merging build & host envs for the later outputs, leading to resolution conflicts due to llvm-opemp vs. libgomp coming from gcc. According to the link-check on linux, it's also not used anyway...
…nda-forge-pinning 2023.07.26.21.58.02
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
@isuruf, I'd like to drop It's also much less relevant based on the discussion that we don't need flang on linux/osx, so we don't have to worry about cross-compilation for aarch/ppc etc. The only point where I see this becoming relevant soon-ish is for win-arm64 support, but I'd like to cross that bridge when we get there, and not block flang on win-64 over that. Finally, https://reviews.llvm.org/D154869 will overhaul a lot of the upstream integration of the runtime libs (including fortran_main), so we'd have to redo whatever patches we come up with anyway. |
we don't need cross-compilation capabilities for now, linux & osx have gfortran anyway, and win-arm64 is not ready yet.
You had added a test using |
Co-authored-by: Isuru Fernando <[email protected]>
Alright, the sysroot on linux now gets found without having |
I've updated the todo list in the OP. The last big open question is how to do the windows compiler activation correctly. When we last spoke about this you mentioned we might need a separate feedstock. Is that necessary even if we're not doing the cross-compilation setup for now? |
@isuruf, what do you think we publish this to |
Sure.
Nope |
Let's keep using |
OK, thanks! Both those things ( |
Gentle ping @isuruf - OK for you if we push the button here? |
Yeah, sounds good. |
Carrying forward the work from #27 to LLVM 17. Expanding the open points from the last discussion into a TODO:
error LNK2019: unresolved external symbol __udivti3
due to a combination of missing compiler-rt support when using MSVC, and probably 128bit-support.{{ compiler('cxx') }}
in the test environment is necessary to properly find the sysroot on linux because of this; however the GCC-activation will setCONDA_BUILD_SYSROOT
, which is then picked up through our patched clang.libflang_main
needs to depend onlibfortran_main_{{ cross_platform }}
(not the other way around)we also need to put it on a path that's distinct per target triple to support e.g. having both x64 & aarch64 in the same environment (this will likely need patching of flang)/MD
, which will also likely have to go into a separate feedstocklibgfortran-ng
.Potentially:
flang-new
toflang
Also worth noting: https://reviews.llvm.org/D154869 will reshuffle the runtime libs a lot, but this didn't land for LLVM 17.