[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro added inline comments. Comment at: flang/lib/Decimal/CMakeLists.txt:52 -add_flang_library(FortranDecimal INSTALL_WITH_TOOLCHAIN - binary-to-decimal.cpp - decimal-to-binary.cpp -) +add_compile_options(-fPIC) + efriedma wrote: > This `add_compile_options(-fPIC)` shouldn't be necessary? Pretty sure you're right, let me build/test without it to make sure and I'll update if everything is alright Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154869/new/ https://reviews.llvm.org/D154869 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
efriedma added a comment. The test changes look good to me. Comment at: flang/lib/Decimal/CMakeLists.txt:52 -add_flang_library(FortranDecimal INSTALL_WITH_TOOLCHAIN - binary-to-decimal.cpp - decimal-to-binary.cpp -) +add_compile_options(-fPIC) + This `add_compile_options(-fPIC)` shouldn't be necessary? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154869/new/ https://reviews.llvm.org/D154869 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro added a comment. In order to keep the scope of this patch manageable, and because further discussion is warranted first, no source files have been moved from flang into flang-rt. Although I would imagine that this may be something we would want to do in the future in order to continue our efforts at decoupling compiler and runtime. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154869/new/ https://reviews.llvm.org/D154869 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro added a comment. Some of the testcases have been reformatted by clang-format when I updated the patch with arcanist. If the community is against introducing extra changes like these I would be happy to re-update my patch without clang-formatting these files. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154869/new/ https://reviews.llvm.org/D154869 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro added inline comments. Comment at: flang/runtime/CMakeLists.txt:251 - INSTALL_WITH_TOOLCHAIN -) +if (DEFINED LLVM_ENABLE_RUNTIMES AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES) + add_flang_library(FortranRuntime STATIC efriedma wrote: > klausler wrote: > > pscoro wrote: > > > efriedma wrote: > > > > pscoro wrote: > > > > > efriedma wrote: > > > > > > pscoro wrote: > > > > > > > efriedma wrote: > > > > > > > > This "if" doesn't make sense to me. If we're not building > > > > > > > > flang-rt, we shouldn't be here, so I don't see why you need an > > > > > > > > "if" in the first place. > > > > > > > `add_subdirectory(runtime)` is a line that still exists in > > > > > > > `flang/CMakeLists.txt`. This exists because `Fortran_main` is > > > > > > > still being built at the same time as the compiler, and to do so, > > > > > > > the runtime subdirectory still needs to be added to flang > > > > > > > (`flang/CMakeLists.txt` -> `add_subdirectory(runtime)` -> > > > > > > > `flang/runtime/CMakeLists.txt` -> > > > > > > > `add_subdirectory(FortranMain)`. The solution I had was to just > > > > > > > add a check around the `FortranRuntime` library production so > > > > > > > that it only happens for flang-rt. > > > > > > > > > > > > > > If you have a better solution let me know. Overall, I'm not sure > > > > > > > if Fortran_main is currently being handled in the best way (ie, > > > > > > > its still being built at the same time as the compiler, which > > > > > > > doesn't seem ideal), but am not sure what course of action to > > > > > > > take with it since it doesn't really belong in flang-rt either > > > > > > > (see documentation for details) > > > > > > Fortran_main should be "part of" flang-rt in the sense that > > > > > > building flang-rt builds it. Most of the same reasons we want to > > > > > > build flang-rt.a as a runtime apply. > > > > > > > > > > > > Since the output needs to be separate, building flang-rt should > > > > > > produce two libraries: flang-rt.a and FortranMain.a. > > > > > I agree with this idea and have been trying to make it work but in > > > > > the process I discovered that my "fix" above (`if (DEFINED > > > > > LLVM_ENABLE_RUNTIMES AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)`) > > > > > is worse than I thought. > > > > > > > > > > By building the llvm target with flang-rt as an enabled runtime, we > > > > > are essentially saying: build the flang compiler, and then invoke > > > > > cmake again to build the runtimes project (externally), which builds > > > > > flang-rt. > > > > > > > > > > The problem is that check-all depends on check-flang which depends on > > > > > the runtime. The if guard above was not actually doing what I thought > > > > > it was, and the reason why configuring didnt fail with "flang-rt does > > > > > not exist" is because the if guard was still evaluating to true. > > > > > Basically, the guard ensured that FortranRuntime was only being built > > > > > if flang-rt is built, but the add_library call was still being > > > > > reached *during the configuration of the flang compiler*. > > > > > > > > > > I am having trouble dealing with this dependency since runtimes get > > > > > built externally (and after the compiler is built, which is when the > > > > > check-all custom target gets built). I will have to investigate more > > > > > closely how other runtimes handle this. My initial thought was > > > > > perhaps the runtime testing should be decoupled from > > > > > check-flang/check-all however I don't know if that's a good idea, and > > > > > I also think that only helps with flang-rt, but if Fortran_main is > > > > > required to build any executable I imagine that it should be needed > > > > > for check-flang? > > > > > > > > > > This is just an update of whats holding me back right now. If you > > > > > have any tips please let me know. Thanks for bringing this to my > > > > > attention. > > > > For comparison, check-clang doesn't require any runtime libraries at > > > > all. All the checks only check the generated LLVM IR/driver > > > > commands/etc. Any tests that require runtime execution go into either > > > > the regression tests for the runtimes themselves, or into > > > > lllvm-test-suite. > > > > > > > > Probably check-flang should do something similar. It probably makes > > > > sense to add a check-flang-rt target or something like that. (Not sure > > > > which existing flang tests are impacted.) > > > If we are decoupling the affected tests from flang-rt, then I think the > > > only component left coupled (that I'd argue shouldn't be coupled) is the > > > runtime source files. I'm seeing that for all the other runtimes in the > > > llvm-project, the sources exist in a top level directory. Would it make > > > sense and be feasible for flang-rt to act similarly? > > > > > > Comparing to the infrastructure for compiler-rt, I've been entertaining
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
efriedma added inline comments. Comment at: flang/runtime/CMakeLists.txt:251 - INSTALL_WITH_TOOLCHAIN -) +if (DEFINED LLVM_ENABLE_RUNTIMES AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES) + add_flang_library(FortranRuntime STATIC klausler wrote: > pscoro wrote: > > efriedma wrote: > > > pscoro wrote: > > > > efriedma wrote: > > > > > pscoro wrote: > > > > > > efriedma wrote: > > > > > > > This "if" doesn't make sense to me. If we're not building > > > > > > > flang-rt, we shouldn't be here, so I don't see why you need an > > > > > > > "if" in the first place. > > > > > > `add_subdirectory(runtime)` is a line that still exists in > > > > > > `flang/CMakeLists.txt`. This exists because `Fortran_main` is still > > > > > > being built at the same time as the compiler, and to do so, the > > > > > > runtime subdirectory still needs to be added to flang > > > > > > (`flang/CMakeLists.txt` -> `add_subdirectory(runtime)` -> > > > > > > `flang/runtime/CMakeLists.txt` -> `add_subdirectory(FortranMain)`. > > > > > > The solution I had was to just add a check around the > > > > > > `FortranRuntime` library production so that it only happens for > > > > > > flang-rt. > > > > > > > > > > > > If you have a better solution let me know. Overall, I'm not sure if > > > > > > Fortran_main is currently being handled in the best way (ie, its > > > > > > still being built at the same time as the compiler, which doesn't > > > > > > seem ideal), but am not sure what course of action to take with it > > > > > > since it doesn't really belong in flang-rt either (see > > > > > > documentation for details) > > > > > Fortran_main should be "part of" flang-rt in the sense that building > > > > > flang-rt builds it. Most of the same reasons we want to build > > > > > flang-rt.a as a runtime apply. > > > > > > > > > > Since the output needs to be separate, building flang-rt should > > > > > produce two libraries: flang-rt.a and FortranMain.a. > > > > I agree with this idea and have been trying to make it work but in the > > > > process I discovered that my "fix" above (`if (DEFINED > > > > LLVM_ENABLE_RUNTIMES AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)`) is > > > > worse than I thought. > > > > > > > > By building the llvm target with flang-rt as an enabled runtime, we are > > > > essentially saying: build the flang compiler, and then invoke cmake > > > > again to build the runtimes project (externally), which builds flang-rt. > > > > > > > > The problem is that check-all depends on check-flang which depends on > > > > the runtime. The if guard above was not actually doing what I thought > > > > it was, and the reason why configuring didnt fail with "flang-rt does > > > > not exist" is because the if guard was still evaluating to true. > > > > Basically, the guard ensured that FortranRuntime was only being built > > > > if flang-rt is built, but the add_library call was still being reached > > > > *during the configuration of the flang compiler*. > > > > > > > > I am having trouble dealing with this dependency since runtimes get > > > > built externally (and after the compiler is built, which is when the > > > > check-all custom target gets built). I will have to investigate more > > > > closely how other runtimes handle this. My initial thought was perhaps > > > > the runtime testing should be decoupled from check-flang/check-all > > > > however I don't know if that's a good idea, and I also think that only > > > > helps with flang-rt, but if Fortran_main is required to build any > > > > executable I imagine that it should be needed for check-flang? > > > > > > > > This is just an update of whats holding me back right now. If you have > > > > any tips please let me know. Thanks for bringing this to my attention. > > > For comparison, check-clang doesn't require any runtime libraries at all. > > > All the checks only check the generated LLVM IR/driver commands/etc. Any > > > tests that require runtime execution go into either the regression tests > > > for the runtimes themselves, or into lllvm-test-suite. > > > > > > Probably check-flang should do something similar. It probably makes sense > > > to add a check-flang-rt target or something like that. (Not sure which > > > existing flang tests are impacted.) > > If we are decoupling the affected tests from flang-rt, then I think the > > only component left coupled (that I'd argue shouldn't be coupled) is the > > runtime source files. I'm seeing that for all the other runtimes in the > > llvm-project, the sources exist in a top level directory. Would it make > > sense and be feasible for flang-rt to act similarly? > > > > Comparing to the infrastructure for compiler-rt, I've been entertaining the > > idea that FortranRuntime and FortranMain can be treated as a library with > > sources defined in `flang-rt/lib/FortranRuntime` and > > `flang-rt/lib/FortranMain`, similar to how compiler-rt has
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
klausler added inline comments. Comment at: flang/runtime/CMakeLists.txt:251 - INSTALL_WITH_TOOLCHAIN -) +if (DEFINED LLVM_ENABLE_RUNTIMES AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES) + add_flang_library(FortranRuntime STATIC pscoro wrote: > efriedma wrote: > > pscoro wrote: > > > efriedma wrote: > > > > pscoro wrote: > > > > > efriedma wrote: > > > > > > This "if" doesn't make sense to me. If we're not building > > > > > > flang-rt, we shouldn't be here, so I don't see why you need an "if" > > > > > > in the first place. > > > > > `add_subdirectory(runtime)` is a line that still exists in > > > > > `flang/CMakeLists.txt`. This exists because `Fortran_main` is still > > > > > being built at the same time as the compiler, and to do so, the > > > > > runtime subdirectory still needs to be added to flang > > > > > (`flang/CMakeLists.txt` -> `add_subdirectory(runtime)` -> > > > > > `flang/runtime/CMakeLists.txt` -> `add_subdirectory(FortranMain)`. > > > > > The solution I had was to just add a check around the > > > > > `FortranRuntime` library production so that it only happens for > > > > > flang-rt. > > > > > > > > > > If you have a better solution let me know. Overall, I'm not sure if > > > > > Fortran_main is currently being handled in the best way (ie, its > > > > > still being built at the same time as the compiler, which doesn't > > > > > seem ideal), but am not sure what course of action to take with it > > > > > since it doesn't really belong in flang-rt either (see documentation > > > > > for details) > > > > Fortran_main should be "part of" flang-rt in the sense that building > > > > flang-rt builds it. Most of the same reasons we want to build > > > > flang-rt.a as a runtime apply. > > > > > > > > Since the output needs to be separate, building flang-rt should produce > > > > two libraries: flang-rt.a and FortranMain.a. > > > I agree with this idea and have been trying to make it work but in the > > > process I discovered that my "fix" above (`if (DEFINED > > > LLVM_ENABLE_RUNTIMES AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)`) is > > > worse than I thought. > > > > > > By building the llvm target with flang-rt as an enabled runtime, we are > > > essentially saying: build the flang compiler, and then invoke cmake again > > > to build the runtimes project (externally), which builds flang-rt. > > > > > > The problem is that check-all depends on check-flang which depends on the > > > runtime. The if guard above was not actually doing what I thought it was, > > > and the reason why configuring didnt fail with "flang-rt does not exist" > > > is because the if guard was still evaluating to true. Basically, the > > > guard ensured that FortranRuntime was only being built if flang-rt is > > > built, but the add_library call was still being reached *during the > > > configuration of the flang compiler*. > > > > > > I am having trouble dealing with this dependency since runtimes get built > > > externally (and after the compiler is built, which is when the check-all > > > custom target gets built). I will have to investigate more closely how > > > other runtimes handle this. My initial thought was perhaps the runtime > > > testing should be decoupled from check-flang/check-all however I don't > > > know if that's a good idea, and I also think that only helps with > > > flang-rt, but if Fortran_main is required to build any executable I > > > imagine that it should be needed for check-flang? > > > > > > This is just an update of whats holding me back right now. If you have > > > any tips please let me know. Thanks for bringing this to my attention. > > For comparison, check-clang doesn't require any runtime libraries at all. > > All the checks only check the generated LLVM IR/driver commands/etc. Any > > tests that require runtime execution go into either the regression tests > > for the runtimes themselves, or into lllvm-test-suite. > > > > Probably check-flang should do something similar. It probably makes sense > > to add a check-flang-rt target or something like that. (Not sure which > > existing flang tests are impacted.) > If we are decoupling the affected tests from flang-rt, then I think the only > component left coupled (that I'd argue shouldn't be coupled) is the runtime > source files. I'm seeing that for all the other runtimes in the llvm-project, > the sources exist in a top level directory. Would it make sense and be > feasible for flang-rt to act similarly? > > Comparing to the infrastructure for compiler-rt, I've been entertaining the > idea that FortranRuntime and FortranMain can be treated as a library with > sources defined in `flang-rt/lib/FortranRuntime` and > `flang-rt/lib/FortranMain`, similar to how compiler-rt has libraries like > `compiler-rt/lib/asan` that are added to the final compiler-rt target. > > FortranDecimalRT's sources would still be gathered from the Flang source >
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro added inline comments. Comment at: flang/runtime/CMakeLists.txt:251 - INSTALL_WITH_TOOLCHAIN -) +if (DEFINED LLVM_ENABLE_RUNTIMES AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES) + add_flang_library(FortranRuntime STATIC efriedma wrote: > pscoro wrote: > > efriedma wrote: > > > pscoro wrote: > > > > efriedma wrote: > > > > > This "if" doesn't make sense to me. If we're not building flang-rt, > > > > > we shouldn't be here, so I don't see why you need an "if" in the > > > > > first place. > > > > `add_subdirectory(runtime)` is a line that still exists in > > > > `flang/CMakeLists.txt`. This exists because `Fortran_main` is still > > > > being built at the same time as the compiler, and to do so, the runtime > > > > subdirectory still needs to be added to flang (`flang/CMakeLists.txt` > > > > -> `add_subdirectory(runtime)` -> `flang/runtime/CMakeLists.txt` -> > > > > `add_subdirectory(FortranMain)`. The solution I had was to just add a > > > > check around the `FortranRuntime` library production so that it only > > > > happens for flang-rt. > > > > > > > > If you have a better solution let me know. Overall, I'm not sure if > > > > Fortran_main is currently being handled in the best way (ie, its still > > > > being built at the same time as the compiler, which doesn't seem > > > > ideal), but am not sure what course of action to take with it since it > > > > doesn't really belong in flang-rt either (see documentation for details) > > > Fortran_main should be "part of" flang-rt in the sense that building > > > flang-rt builds it. Most of the same reasons we want to build flang-rt.a > > > as a runtime apply. > > > > > > Since the output needs to be separate, building flang-rt should produce > > > two libraries: flang-rt.a and FortranMain.a. > > I agree with this idea and have been trying to make it work but in the > > process I discovered that my "fix" above (`if (DEFINED LLVM_ENABLE_RUNTIMES > > AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)`) is worse than I thought. > > > > By building the llvm target with flang-rt as an enabled runtime, we are > > essentially saying: build the flang compiler, and then invoke cmake again > > to build the runtimes project (externally), which builds flang-rt. > > > > The problem is that check-all depends on check-flang which depends on the > > runtime. The if guard above was not actually doing what I thought it was, > > and the reason why configuring didnt fail with "flang-rt does not exist" is > > because the if guard was still evaluating to true. Basically, the guard > > ensured that FortranRuntime was only being built if flang-rt is built, but > > the add_library call was still being reached *during the configuration of > > the flang compiler*. > > > > I am having trouble dealing with this dependency since runtimes get built > > externally (and after the compiler is built, which is when the check-all > > custom target gets built). I will have to investigate more closely how > > other runtimes handle this. My initial thought was perhaps the runtime > > testing should be decoupled from check-flang/check-all however I don't know > > if that's a good idea, and I also think that only helps with flang-rt, but > > if Fortran_main is required to build any executable I imagine that it > > should be needed for check-flang? > > > > This is just an update of whats holding me back right now. If you have any > > tips please let me know. Thanks for bringing this to my attention. > For comparison, check-clang doesn't require any runtime libraries at all. All > the checks only check the generated LLVM IR/driver commands/etc. Any tests > that require runtime execution go into either the regression tests for the > runtimes themselves, or into lllvm-test-suite. > > Probably check-flang should do something similar. It probably makes sense to > add a check-flang-rt target or something like that. (Not sure which existing > flang tests are impacted.) If we are decoupling the affected tests from flang-rt, then I think the only component left coupled (that I'd argue shouldn't be coupled) is the runtime source files. I'm seeing that for all the other runtimes in the llvm-project, the sources exist in a top level directory. Would it make sense and be feasible for flang-rt to act similarly? Comparing to the infrastructure for compiler-rt, I've been entertaining the idea that FortranRuntime and FortranMain can be treated as a library with sources defined in `flang-rt/lib/FortranRuntime` and `flang-rt/lib/FortranMain`, similar to how compiler-rt has libraries like `compiler-rt/lib/asan` that are added to the final compiler-rt target. FortranDecimalRT's sources would still be gathered from the Flang source directory, which would have to be known by flang-rt (also I see that multiple runtime files include `flang/Common` headers (but no sources get linked), so flang-rt would need to be aware of flang's
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
efriedma added inline comments. Comment at: flang/runtime/CMakeLists.txt:251 - INSTALL_WITH_TOOLCHAIN -) +if (DEFINED LLVM_ENABLE_RUNTIMES AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES) + add_flang_library(FortranRuntime STATIC pscoro wrote: > efriedma wrote: > > pscoro wrote: > > > efriedma wrote: > > > > This "if" doesn't make sense to me. If we're not building flang-rt, we > > > > shouldn't be here, so I don't see why you need an "if" in the first > > > > place. > > > `add_subdirectory(runtime)` is a line that still exists in > > > `flang/CMakeLists.txt`. This exists because `Fortran_main` is still being > > > built at the same time as the compiler, and to do so, the runtime > > > subdirectory still needs to be added to flang (`flang/CMakeLists.txt` -> > > > `add_subdirectory(runtime)` -> `flang/runtime/CMakeLists.txt` -> > > > `add_subdirectory(FortranMain)`. The solution I had was to just add a > > > check around the `FortranRuntime` library production so that it only > > > happens for flang-rt. > > > > > > If you have a better solution let me know. Overall, I'm not sure if > > > Fortran_main is currently being handled in the best way (ie, its still > > > being built at the same time as the compiler, which doesn't seem ideal), > > > but am not sure what course of action to take with it since it doesn't > > > really belong in flang-rt either (see documentation for details) > > Fortran_main should be "part of" flang-rt in the sense that building > > flang-rt builds it. Most of the same reasons we want to build flang-rt.a > > as a runtime apply. > > > > Since the output needs to be separate, building flang-rt should produce two > > libraries: flang-rt.a and FortranMain.a. > I agree with this idea and have been trying to make it work but in the > process I discovered that my "fix" above (`if (DEFINED LLVM_ENABLE_RUNTIMES > AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)`) is worse than I thought. > > By building the llvm target with flang-rt as an enabled runtime, we are > essentially saying: build the flang compiler, and then invoke cmake again to > build the runtimes project (externally), which builds flang-rt. > > The problem is that check-all depends on check-flang which depends on the > runtime. The if guard above was not actually doing what I thought it was, and > the reason why configuring didnt fail with "flang-rt does not exist" is > because the if guard was still evaluating to true. Basically, the guard > ensured that FortranRuntime was only being built if flang-rt is built, but > the add_library call was still being reached *during the configuration of the > flang compiler*. > > I am having trouble dealing with this dependency since runtimes get built > externally (and after the compiler is built, which is when the check-all > custom target gets built). I will have to investigate more closely how other > runtimes handle this. My initial thought was perhaps the runtime testing > should be decoupled from check-flang/check-all however I don't know if that's > a good idea, and I also think that only helps with flang-rt, but if > Fortran_main is required to build any executable I imagine that it should be > needed for check-flang? > > This is just an update of whats holding me back right now. If you have any > tips please let me know. Thanks for bringing this to my attention. For comparison, check-clang doesn't require any runtime libraries at all. All the checks only check the generated LLVM IR/driver commands/etc. Any tests that require runtime execution go into either the regression tests for the runtimes themselves, or into lllvm-test-suite. Probably check-flang should do something similar. It probably makes sense to add a check-flang-rt target or something like that. (Not sure which existing flang tests are impacted.) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154869/new/ https://reviews.llvm.org/D154869 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro added inline comments. Comment at: flang/runtime/CMakeLists.txt:251 - INSTALL_WITH_TOOLCHAIN -) +if (DEFINED LLVM_ENABLE_RUNTIMES AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES) + add_flang_library(FortranRuntime STATIC efriedma wrote: > pscoro wrote: > > efriedma wrote: > > > This "if" doesn't make sense to me. If we're not building flang-rt, we > > > shouldn't be here, so I don't see why you need an "if" in the first place. > > `add_subdirectory(runtime)` is a line that still exists in > > `flang/CMakeLists.txt`. This exists because `Fortran_main` is still being > > built at the same time as the compiler, and to do so, the runtime > > subdirectory still needs to be added to flang (`flang/CMakeLists.txt` -> > > `add_subdirectory(runtime)` -> `flang/runtime/CMakeLists.txt` -> > > `add_subdirectory(FortranMain)`. The solution I had was to just add a check > > around the `FortranRuntime` library production so that it only happens for > > flang-rt. > > > > If you have a better solution let me know. Overall, I'm not sure if > > Fortran_main is currently being handled in the best way (ie, its still > > being built at the same time as the compiler, which doesn't seem ideal), > > but am not sure what course of action to take with it since it doesn't > > really belong in flang-rt either (see documentation for details) > Fortran_main should be "part of" flang-rt in the sense that building flang-rt > builds it. Most of the same reasons we want to build flang-rt.a as a runtime > apply. > > Since the output needs to be separate, building flang-rt should produce two > libraries: flang-rt.a and FortranMain.a. I agree with this idea and have been trying to make it work but in the process I discovered that my "fix" above (`if (DEFINED LLVM_ENABLE_RUNTIMES AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)`) is worse than I thought. By building the llvm target with flang-rt as an enabled runtime, we are essentially saying: build the flang compiler, and then invoke cmake again to build the runtimes project (externally), which builds flang-rt. The problem is that check-all depends on check-flang which depends on the runtime. The if guard above was not actually doing what I thought it was, and the reason why configuring didnt fail with "flang-rt does not exist" is because the if guard was still evaluating to true. Basically, the guard ensured that FortranRuntime was only being built if flang-rt is built, but the add_library call was still being reached *during the configuration of the flang compiler*. I am having trouble dealing with this dependency since runtimes get built externally (and after the compiler is built, which is when the check-all custom target gets built). I will have to investigate more closely how other runtimes handle this. My initial thought was perhaps the runtime testing should be decoupled from check-flang/check-all however I don't know if that's a good idea, and I also think that only helps with flang-rt, but if Fortran_main is required to build any executable I imagine that it should be needed for check-flang? This is just an update of whats holding me back right now. If you have any tips please let me know. Thanks for bringing this to my attention. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154869/new/ https://reviews.llvm.org/D154869 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
efriedma added inline comments. Comment at: flang/runtime/CMakeLists.txt:251 - INSTALL_WITH_TOOLCHAIN -) +if (DEFINED LLVM_ENABLE_RUNTIMES AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES) + add_flang_library(FortranRuntime STATIC pscoro wrote: > efriedma wrote: > > This "if" doesn't make sense to me. If we're not building flang-rt, we > > shouldn't be here, so I don't see why you need an "if" in the first place. > `add_subdirectory(runtime)` is a line that still exists in > `flang/CMakeLists.txt`. This exists because `Fortran_main` is still being > built at the same time as the compiler, and to do so, the runtime > subdirectory still needs to be added to flang (`flang/CMakeLists.txt` -> > `add_subdirectory(runtime)` -> `flang/runtime/CMakeLists.txt` -> > `add_subdirectory(FortranMain)`. The solution I had was to just add a check > around the `FortranRuntime` library production so that it only happens for > flang-rt. > > If you have a better solution let me know. Overall, I'm not sure if > Fortran_main is currently being handled in the best way (ie, its still being > built at the same time as the compiler, which doesn't seem ideal), but am not > sure what course of action to take with it since it doesn't really belong in > flang-rt either (see documentation for details) Fortran_main should be "part of" flang-rt in the sense that building flang-rt builds it. Most of the same reasons we want to build flang-rt.a as a runtime apply. Since the output needs to be separate, building flang-rt should produce two libraries: flang-rt.a and FortranMain.a. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154869/new/ https://reviews.llvm.org/D154869 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro added inline comments. Comment at: flang/runtime/CMakeLists.txt:251 - INSTALL_WITH_TOOLCHAIN -) +if (DEFINED LLVM_ENABLE_RUNTIMES AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES) + add_flang_library(FortranRuntime STATIC efriedma wrote: > This "if" doesn't make sense to me. If we're not building flang-rt, we > shouldn't be here, so I don't see why you need an "if" in the first place. `add_subdirectory(runtime)` is a line that still exists in `flang/CMakeLists.txt`. This exists because `Fortran_main` is still being built at the same time as the compiler, and to do so, the runtime subdirectory still needs to be added to flang (`flang/CMakeLists.txt` -> `add_subdirectory(runtime)` -> `flang/runtime/CMakeLists.txt` -> `add_subdirectory(FortranMain)`. The solution I had was to just add a check around the `FortranRuntime` library production so that it only happens for flang-rt. If you have a better solution let me know. Overall, I'm not sure if Fortran_main is currently being handled in the best way (ie, its still being built at the same time as the compiler, which doesn't seem ideal), but am not sure what course of action to take with it since it doesn't really belong in flang-rt either (see documentation for details) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154869/new/ https://reviews.llvm.org/D154869 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
efriedma added inline comments. Comment at: flang/lib/Decimal/CMakeLists.txt:54 + +if (DEFINED LLVM_ENABLE_PROJECTS AND "flang" IN_LIST LLVM_ENABLE_PROJECTS) + add_flang_library(FortranDecimal I think it would make sense to use explicit CMake variables for the "if' statements (i.e. make flang/CMakeLists.txt define BUILDING_FLANG, and make flang-rt/CMakeLists define BUILDING_FLANGRT) . Comment at: flang/runtime/CMakeLists.txt:251 - INSTALL_WITH_TOOLCHAIN -) +if (DEFINED LLVM_ENABLE_RUNTIMES AND "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES) + add_flang_library(FortranRuntime STATIC This "if" doesn't make sense to me. If we're not building flang-rt, we shouldn't be here, so I don't see why you need an "if" in the first place. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154869/new/ https://reviews.llvm.org/D154869 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
vzakhari added inline comments. Comment at: flang-rt/CMakeLists.txt:17-23 +# Check if flang-rt is built as a standalone project. +if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR FLANG_RT_STANDALONE_BUILD) + project(FlangRT C CXX) + set(CMAKE_INCLUDE_CURRENT_DIR ON) + set(FLANG_RT_STANDALONE_BUILD TRUE) + set_property(GLOBAL PROPERTY USE_FOLDERS ON) +endif() pscoro wrote: > phosek wrote: > > pscoro wrote: > > > vzakhari wrote: > > > > phosek wrote: > > > > > I don't think we should support building FlangRT as a standalone > > > > > project. We've been moving all runtimes to the runtimes build, the > > > > > only leftover is compiler-rt and our hope is to address that soon. > > > > Hi @phosek, can you please explain what you mean by "We've been moving > > > > all runtimes to the runtimes build"? Can you please share references > > > > to the pipeline for the "runtimes build"? > > > If i understood correctly, i think @phosek is talking about building the > > > flang-rt target directly (`cmake llvm-project/flang-rt`) when he says > > > standalone. Meanwhile a runtimes build is `cmake llvm-project/runtimes > > > -DLLVM_ENABLE_RUNTIMES=flang-rt`. I chose not to change anything yet > > > because I was focused on some other bugs and was waiting for see if > > > anybody else had input on this first. Also, in case my understanding is > > > incorrect @phosek please correct me. > > Yes, that is correct. > I gave this a couple days in case anybody else in the community wanted to > voice their opinion but since there was no contradictions, I have removed > support for targeting flang-rt directly. Flang-rt is now only buildable via > the llvm target or the runtimes target. See documentation for details. Thank you for the explanation! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154869/new/ https://reviews.llvm.org/D154869 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro marked 3 inline comments as done.
pscoro added inline comments.
Comment at: flang-rt/CMakeLists.txt:17-23
+# Check if flang-rt is built as a standalone project.
+if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR
FLANG_RT_STANDALONE_BUILD)
+ project(FlangRT C CXX)
+ set(CMAKE_INCLUDE_CURRENT_DIR ON)
+ set(FLANG_RT_STANDALONE_BUILD TRUE)
+ set_property(GLOBAL PROPERTY USE_FOLDERS ON)
+endif()
phosek wrote:
> pscoro wrote:
> > vzakhari wrote:
> > > phosek wrote:
> > > > I don't think we should support building FlangRT as a standalone
> > > > project. We've been moving all runtimes to the runtimes build, the only
> > > > leftover is compiler-rt and our hope is to address that soon.
> > > Hi @phosek, can you please explain what you mean by "We've been moving
> > > all runtimes to the runtimes build"? Can you please share references to
> > > the pipeline for the "runtimes build"?
> > If i understood correctly, i think @phosek is talking about building the
> > flang-rt target directly (`cmake llvm-project/flang-rt`) when he says
> > standalone. Meanwhile a runtimes build is `cmake llvm-project/runtimes
> > -DLLVM_ENABLE_RUNTIMES=flang-rt`. I chose not to change anything yet
> > because I was focused on some other bugs and was waiting for see if anybody
> > else had input on this first. Also, in case my understanding is incorrect
> > @phosek please correct me.
> Yes, that is correct.
I gave this a couple days in case anybody else in the community wanted to voice
their opinion but since there was no contradictions, I have removed support for
targeting flang-rt directly. Flang-rt is now only buildable via the llvm target
or the runtimes target. See documentation for details.
Comment at: flang-rt/CMakeLists.txt:41-51
+set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
+set(CMAKE_LIBRARY_OUTPUT_DIRECTORY
+ ${CMAKE_BINARY_DIR}/lib)
+set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY
+ ${CMAKE_BINARY_DIR}/lib)
+set(CMAKE_CURRENT_BINARY_DIR ${CMAKE_LIBRARY_OUTPUT_DIRECTORY})
+
phosek wrote:
> None of this should be needed if building in the runtimes build.
I did some further testing and removed the module paths and include statements
that were not needed. However, not all of the lines could be removed, clang and
flang specific paths/includes were missing so they were left in here.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D154869/new/
https://reviews.llvm.org/D154869
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro updated this revision to Diff 541544.
pscoro marked an inline comment as done.
pscoro added a comment.
Removed support for "fully standalone" Flang-rt builds (ie CMake builds
targeting llvm-project/flang-rt).
Flang-rt is now buildable via the `llvm` target or the `runtimes` target. See
documentation for more
information.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D154869/new/
https://reviews.llvm.org/D154869
Files:
clang/lib/Driver/ToolChains/CommonArgs.cpp
flang-rt/CMakeLists.txt
flang/CMakeLists.txt
flang/cmake/modules/AddFlang.cmake
flang/docs/Flang-rt.md
flang/lib/Decimal/CMakeLists.txt
flang/runtime/CMakeLists.txt
flang/test/CMakeLists.txt
flang/test/Driver/linker-flags.f90
flang/test/lit.cfg.py
flang/tools/flang-driver/CMakeLists.txt
lld/COFF/MinGW.cpp
llvm/CMakeLists.txt
llvm/projects/CMakeLists.txt
runtimes/CMakeLists.txt
Index: runtimes/CMakeLists.txt
===
--- runtimes/CMakeLists.txt
+++ runtimes/CMakeLists.txt
@@ -19,7 +19,7 @@
# We order libraries to mirror roughly how they are layered, except that compiler-rt can depend
# on libc++, so we put it after.
-set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp")
+set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;flang-rt")
set(LLVM_SUPPORTED_RUNTIMES "${LLVM_DEFAULT_RUNTIMES};llvm-libgcc")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
Index: llvm/projects/CMakeLists.txt
===
--- llvm/projects/CMakeLists.txt
+++ llvm/projects/CMakeLists.txt
@@ -6,6 +6,7 @@
if(IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt)
if((NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/compiler-rt) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/dragonegg) AND
+ (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/flang-rt) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxx) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxxabi) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libunwind) AND
@@ -42,6 +43,8 @@
add_llvm_external_project(dragonegg)
add_llvm_external_project(openmp)
+add_llvm_external_project(flang-rt)
+
if(LLVM_INCLUDE_TESTS)
add_llvm_external_project(cross-project-tests)
endif()
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -149,7 +149,10 @@
# As we migrate runtimes to using the bootstrapping build, the set of default runtimes
# should grow as we remove those runtimes from LLVM_ENABLE_PROJECTS above.
set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind")
-set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc")
+if ("flang" IN_LIST LLVM_ENABLE_PROJECTS)
+ set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind;flang-rt")
+endif()
+set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc;flang-rt")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
if(LLVM_ENABLE_RUNTIMES STREQUAL "all")
@@ -171,6 +174,11 @@
endif()
endif()
+if ("flang" IN_LIST LLVM_ENABLE_PROJECTS AND NOT "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)
+ message(STATUS "Enabling flang-rt to be built with the flang project")
+ list(APPEND LLVM_ENABLE_RUNTIMES "flang-rt")
+endif()
+
# LLVM_ENABLE_PROJECTS_USED is `ON` if the user has ever used the
# `LLVM_ENABLE_PROJECTS` CMake cache variable. This exists for
# several reasons:
Index: lld/COFF/MinGW.cpp
===
--- lld/COFF/MinGW.cpp
+++ lld/COFF/MinGW.cpp
@@ -50,8 +50,7 @@
"libc++",
"libc++abi",
"libFortran_main",
- "libFortranRuntime",
- "libFortranDecimal",
+ "libflang-rt",
"libunwind",
"libmsvcrt",
"libucrtbase",
Index: flang/tools/flang-driver/CMakeLists.txt
===
--- flang/tools/flang-driver/CMakeLists.txt
+++ flang/tools/flang-driver/CMakeLists.txt
@@ -19,8 +19,7 @@
# These libraries are used in the linker invocation generated by the driver
# (i.e. when constructing the linker job). Without them the driver would be
# unable to generate executables.
- FortranRuntime
- FortranDecimal
+ flang-rt
Fortran_main
)
Index: flang/test/lit.cfg.py
===
--- flang/test/lit.cfg.py
+++ flang/test/lit.cfg.py
@@ -153,19 +153,16 @@
# the C++ runtime libraries. For this
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro marked 6 inline comments as done. pscoro added inline comments. Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:934-936 + // Default to the /../lib and + // /../runtimes/runtimes-bins/lib directories. This works fine + // on the platforms that we have tested so far. We will probably have to awarzynski wrote: > pscoro wrote: > > awarzynski wrote: > > > Am I correct thinking that: > > > * "/../lib" is for `Fortran_main.a`, and > > > * "/../runtimes/runtimes-bins/lib " is for `libflang-rt`? > > > > > > Could you document this? Thanks! > > Yep thats right, documentation added > > Yep thats right, documentation added > > Could you document _where_ these libraries are located? Also, could you add > some relevant comments here? For example: > ``` > // Add search path for XYZ > llvm::sys::path::append(BuildLibPath, "lib"); > ``` > Could you document _where_ these libraries are located? I've made the information more explicit in the documentation and added clarification that the `../runtimes/runtimes-bins/lib` path happens for runtimes built as part of an llvm target build, but during standalone runtimes builds `../lib` is used. (I am not sure why this behavior is what it is, but I don't think we should by changing or overriding the existing infrastructure) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154869/new/ https://reviews.llvm.org/D154869 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro updated this revision to Diff 541537.
pscoro marked an inline comment as done.
pscoro added a comment.
Updated documentation to address all nits
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D154869/new/
https://reviews.llvm.org/D154869
Files:
clang/lib/Driver/ToolChains/CommonArgs.cpp
flang-rt/CMakeLists.txt
flang/CMakeLists.txt
flang/cmake/modules/AddFlang.cmake
flang/docs/Flang-rt.md
flang/lib/Decimal/CMakeLists.txt
flang/runtime/CMakeLists.txt
flang/test/CMakeLists.txt
flang/test/Driver/linker-flags.f90
flang/test/lit.cfg.py
flang/tools/flang-driver/CMakeLists.txt
lld/COFF/MinGW.cpp
llvm/CMakeLists.txt
llvm/projects/CMakeLists.txt
runtimes/CMakeLists.txt
Index: runtimes/CMakeLists.txt
===
--- runtimes/CMakeLists.txt
+++ runtimes/CMakeLists.txt
@@ -19,7 +19,7 @@
# We order libraries to mirror roughly how they are layered, except that compiler-rt can depend
# on libc++, so we put it after.
-set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp")
+set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;flang-rt")
set(LLVM_SUPPORTED_RUNTIMES "${LLVM_DEFAULT_RUNTIMES};llvm-libgcc")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
Index: llvm/projects/CMakeLists.txt
===
--- llvm/projects/CMakeLists.txt
+++ llvm/projects/CMakeLists.txt
@@ -6,6 +6,7 @@
if(IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt)
if((NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/compiler-rt) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/dragonegg) AND
+ (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/flang-rt) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxx) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxxabi) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libunwind) AND
@@ -42,6 +43,8 @@
add_llvm_external_project(dragonegg)
add_llvm_external_project(openmp)
+add_llvm_external_project(flang-rt)
+
if(LLVM_INCLUDE_TESTS)
add_llvm_external_project(cross-project-tests)
endif()
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -149,7 +149,10 @@
# As we migrate runtimes to using the bootstrapping build, the set of default runtimes
# should grow as we remove those runtimes from LLVM_ENABLE_PROJECTS above.
set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind")
-set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc")
+if ("flang" IN_LIST LLVM_ENABLE_PROJECTS)
+ set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind;flang-rt")
+endif()
+set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc;flang-rt")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
if(LLVM_ENABLE_RUNTIMES STREQUAL "all")
@@ -171,6 +174,11 @@
endif()
endif()
+if ("flang" IN_LIST LLVM_ENABLE_PROJECTS AND NOT "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)
+ message(STATUS "Enabling flang-rt to be built with the flang project")
+ list(APPEND LLVM_ENABLE_RUNTIMES "flang-rt")
+endif()
+
# LLVM_ENABLE_PROJECTS_USED is `ON` if the user has ever used the
# `LLVM_ENABLE_PROJECTS` CMake cache variable. This exists for
# several reasons:
Index: lld/COFF/MinGW.cpp
===
--- lld/COFF/MinGW.cpp
+++ lld/COFF/MinGW.cpp
@@ -50,8 +50,7 @@
"libc++",
"libc++abi",
"libFortran_main",
- "libFortranRuntime",
- "libFortranDecimal",
+ "libflang-rt",
"libunwind",
"libmsvcrt",
"libucrtbase",
Index: flang/tools/flang-driver/CMakeLists.txt
===
--- flang/tools/flang-driver/CMakeLists.txt
+++ flang/tools/flang-driver/CMakeLists.txt
@@ -19,8 +19,7 @@
# These libraries are used in the linker invocation generated by the driver
# (i.e. when constructing the linker job). Without them the driver would be
# unable to generate executables.
- FortranRuntime
- FortranDecimal
+ flang-rt
Fortran_main
)
Index: flang/test/lit.cfg.py
===
--- flang/test/lit.cfg.py
+++ flang/test/lit.cfg.py
@@ -153,19 +153,16 @@
# the C++ runtime libraries. For this we need a C compiler. If for some reason
# we don't have one, we can just disable the test.
if config.cc:
-libruntime = os.path.join(config.flang_lib_dir,
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
awarzynski added inline comments. Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:934-936 + // Default to the /../lib and + // /../runtimes/runtimes-bins/lib directories. This works fine + // on the platforms that we have tested so far. We will probably have to pscoro wrote: > awarzynski wrote: > > Am I correct thinking that: > > * "/../lib" is for `Fortran_main.a`, and > > * "/../runtimes/runtimes-bins/lib " is for `libflang-rt`? > > > > Could you document this? Thanks! > Yep thats right, documentation added > Yep thats right, documentation added Could you document _where_ these libraries are located? Also, could you add some relevant comments here? For example: ``` // Add search path for XYZ llvm::sys::path::append(BuildLibPath, "lib"); ``` Comment at: flang/docs/Flang-rt.md:15-16 +``` +The flang driver requires two libraries for linking into any user executable, +`Fortran_main.a` and Flang-rt. +## Motivation This statement is not quite true - the driver can do a lot without requiring these libraries. I suspect that you wanted o say that generating executables requires these libraries. [nit] flang dirver --> Flang driver Comment at: flang/docs/Flang-rt.md:17 +`Fortran_main.a` and Flang-rt. +## Motivation +Before Flang-rt, the driver would need to link Fortran_main, FortranRuntime, Motivation for ...? It's not clear what the following section aims to achieve. I think that it would be good to take a step beck and decide who this documented is intended for. If it's the end-user then, imho, this section doesn't belong here. In documentation like this I'd focus on "what" and "how" as opposed to "why". Even if this document is intended for developers, I wouldn't focus too much on the original motivations for this change and instead explain the design and its benefits: * possibility to build the runtime independently of Flang (what's the benefit of that?) * CMake set-up that's consistent with other sub-projects in LLVM, * a convenient wrapper for multiple (i.e. 2) Flang runtime libraries, * automated logic to build shared and static version of the runtime libs (to enable supporting e.g. `-static`?). I hope that this makes sense. Comment at: flang/docs/Flang-rt.md:30-31 +## Fortran_main +Fortran_main is left out of Flang-rt because it is required to be linked +statically. The link type of Flang-rt can be configured with a CMake option. + Could you document "why"? Comment at: flang/docs/Flang-rt.md:35 +In order to decouple the common dependency between compiler and runtime, +FortranDecimal's sources get built a second time into a library target named +FortranDecimalRT. FortranDecimal is built for the compiler and FortranDecimalRT Perhaps turn this into a link to the CMake definition? Comment at: flang/docs/Flang-rt.md:61-63 +The two build paths mentioned above get implicitly added as library paths at the +invocation of the driver. If Flang-rt is a shared library, you must add its path +to the environment variable `LD_LIBRARY_PATH`. 1. Please add an example. 2. "you must add its path to the environment variable `LD_LIBRARY_PATH`" <-- this is just one way to provide a search path for the dynamic linker. There are other ways too. It would be good to clarify that a) one has to make the dynamic linker aware _where_ to look and that b) `LD_LIBRARY_PATH` is one such mechanism that can be used. But I would be careful not to "endorse" it - mishandling `LD_LIBRARY_PATH` can lead to tricky surprises. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154869/new/ https://reviews.llvm.org/D154869 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro marked an inline comment as done. pscoro added inline comments. Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:934-936 + // Default to the /../lib and + // /../runtimes/runtimes-bins/lib directories. This works fine + // on the platforms that we have tested so far. We will probably have to awarzynski wrote: > Am I correct thinking that: > * "/../lib" is for `Fortran_main.a`, and > * "/../runtimes/runtimes-bins/lib " is for `libflang-rt`? > > Could you document this? Thanks! Yep thats right, documentation added Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154869/new/ https://reviews.llvm.org/D154869 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro updated this revision to Diff 541040.
pscoro added a comment.
Added documentation for Flang-rt.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D154869/new/
https://reviews.llvm.org/D154869
Files:
clang/lib/Driver/ToolChains/CommonArgs.cpp
flang-rt/CMakeLists.txt
flang/CMakeLists.txt
flang/cmake/modules/AddFlang.cmake
flang/docs/Flang-rt.md
flang/lib/Decimal/CMakeLists.txt
flang/runtime/CMakeLists.txt
flang/test/CMakeLists.txt
flang/test/Driver/linker-flags.f90
flang/test/lit.cfg.py
flang/tools/flang-driver/CMakeLists.txt
lld/COFF/MinGW.cpp
llvm/CMakeLists.txt
llvm/projects/CMakeLists.txt
runtimes/CMakeLists.txt
Index: runtimes/CMakeLists.txt
===
--- runtimes/CMakeLists.txt
+++ runtimes/CMakeLists.txt
@@ -19,7 +19,7 @@
# We order libraries to mirror roughly how they are layered, except that compiler-rt can depend
# on libc++, so we put it after.
-set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp")
+set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;flang-rt")
set(LLVM_SUPPORTED_RUNTIMES "${LLVM_DEFAULT_RUNTIMES};llvm-libgcc")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
Index: llvm/projects/CMakeLists.txt
===
--- llvm/projects/CMakeLists.txt
+++ llvm/projects/CMakeLists.txt
@@ -6,6 +6,7 @@
if(IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt)
if((NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/compiler-rt) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/dragonegg) AND
+ (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/flang-rt) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxx) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxxabi) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libunwind) AND
@@ -42,6 +43,8 @@
add_llvm_external_project(dragonegg)
add_llvm_external_project(openmp)
+add_llvm_external_project(flang-rt)
+
if(LLVM_INCLUDE_TESTS)
add_llvm_external_project(cross-project-tests)
endif()
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -149,7 +149,10 @@
# As we migrate runtimes to using the bootstrapping build, the set of default runtimes
# should grow as we remove those runtimes from LLVM_ENABLE_PROJECTS above.
set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind")
-set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc")
+if ("flang" IN_LIST LLVM_ENABLE_PROJECTS)
+ set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind;flang-rt")
+endif()
+set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc;flang-rt")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
if(LLVM_ENABLE_RUNTIMES STREQUAL "all")
@@ -171,6 +174,11 @@
endif()
endif()
+if ("flang" IN_LIST LLVM_ENABLE_PROJECTS AND NOT "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)
+ message(STATUS "Enabling flang-rt to be built with the flang project")
+ list(APPEND LLVM_ENABLE_RUNTIMES "flang-rt")
+endif()
+
# LLVM_ENABLE_PROJECTS_USED is `ON` if the user has ever used the
# `LLVM_ENABLE_PROJECTS` CMake cache variable. This exists for
# several reasons:
Index: lld/COFF/MinGW.cpp
===
--- lld/COFF/MinGW.cpp
+++ lld/COFF/MinGW.cpp
@@ -50,8 +50,7 @@
"libc++",
"libc++abi",
"libFortran_main",
- "libFortranRuntime",
- "libFortranDecimal",
+ "libflang-rt",
"libunwind",
"libmsvcrt",
"libucrtbase",
Index: flang/tools/flang-driver/CMakeLists.txt
===
--- flang/tools/flang-driver/CMakeLists.txt
+++ flang/tools/flang-driver/CMakeLists.txt
@@ -19,8 +19,7 @@
# These libraries are used in the linker invocation generated by the driver
# (i.e. when constructing the linker job). Without them the driver would be
# unable to generate executables.
- FortranRuntime
- FortranDecimal
+ flang-rt
Fortran_main
)
Index: flang/test/lit.cfg.py
===
--- flang/test/lit.cfg.py
+++ flang/test/lit.cfg.py
@@ -153,19 +153,16 @@
# the C++ runtime libraries. For this we need a C compiler. If for some reason
# we don't have one, we can just disable the test.
if config.cc:
-libruntime = os.path.join(config.flang_lib_dir, "libFortranRuntime.a")
-libdecimal =
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
awarzynski added inline comments. Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:934-936 + // Default to the /../lib and + // /../runtimes/runtimes-bins/lib directories. This works fine + // on the platforms that we have tested so far. We will probably have to Am I correct thinking that: * "/../lib" is for `Fortran_main.a`, and * "/../runtimes/runtimes-bins/lib " is for `libflang-rt`? Could you document this? Thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154869/new/ https://reviews.llvm.org/D154869 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro updated this revision to Diff 540413.
pscoro added a comment.
Decided to remove all the commented code related to the previous approach
(wrapper library). The code that exists currently is for the object library
approach and is functional.
Currently, on phabricator there is a failing x64 Windows build. The failure
happens during building, the compiler seems to run out of heap space? I don't
see how this error could be related to my patch but if I am wrong and it is,
please let me know.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D154869/new/
https://reviews.llvm.org/D154869
Files:
clang/lib/Driver/ToolChains/CommonArgs.cpp
flang-rt/CMakeLists.txt
flang/CMakeLists.txt
flang/cmake/modules/AddFlang.cmake
flang/lib/Decimal/CMakeLists.txt
flang/runtime/CMakeLists.txt
flang/test/CMakeLists.txt
flang/test/Driver/linker-flags.f90
flang/test/lit.cfg.py
flang/tools/flang-driver/CMakeLists.txt
lld/COFF/MinGW.cpp
llvm/CMakeLists.txt
llvm/projects/CMakeLists.txt
runtimes/CMakeLists.txt
Index: runtimes/CMakeLists.txt
===
--- runtimes/CMakeLists.txt
+++ runtimes/CMakeLists.txt
@@ -19,7 +19,7 @@
# We order libraries to mirror roughly how they are layered, except that compiler-rt can depend
# on libc++, so we put it after.
-set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp")
+set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;flang-rt")
set(LLVM_SUPPORTED_RUNTIMES "${LLVM_DEFAULT_RUNTIMES};llvm-libgcc")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
Index: llvm/projects/CMakeLists.txt
===
--- llvm/projects/CMakeLists.txt
+++ llvm/projects/CMakeLists.txt
@@ -6,6 +6,7 @@
if(IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt)
if((NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/compiler-rt) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/dragonegg) AND
+ (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/flang-rt) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxx) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxxabi) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libunwind) AND
@@ -42,6 +43,8 @@
add_llvm_external_project(dragonegg)
add_llvm_external_project(openmp)
+add_llvm_external_project(flang-rt)
+
if(LLVM_INCLUDE_TESTS)
add_llvm_external_project(cross-project-tests)
endif()
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -149,7 +149,10 @@
# As we migrate runtimes to using the bootstrapping build, the set of default runtimes
# should grow as we remove those runtimes from LLVM_ENABLE_PROJECTS above.
set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind")
-set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc")
+if ("flang" IN_LIST LLVM_ENABLE_PROJECTS)
+ set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind;flang-rt")
+endif()
+set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc;flang-rt")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
if(LLVM_ENABLE_RUNTIMES STREQUAL "all")
@@ -171,6 +174,11 @@
endif()
endif()
+if ("flang" IN_LIST LLVM_ENABLE_PROJECTS AND NOT "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)
+ message(STATUS "Enabling flang-rt to be built with the flang project")
+ list(APPEND LLVM_ENABLE_RUNTIMES "flang-rt")
+endif()
+
# LLVM_ENABLE_PROJECTS_USED is `ON` if the user has ever used the
# `LLVM_ENABLE_PROJECTS` CMake cache variable. This exists for
# several reasons:
Index: lld/COFF/MinGW.cpp
===
--- lld/COFF/MinGW.cpp
+++ lld/COFF/MinGW.cpp
@@ -50,8 +50,7 @@
"libc++",
"libc++abi",
"libFortran_main",
- "libFortranRuntime",
- "libFortranDecimal",
+ "libflang-rt",
"libunwind",
"libmsvcrt",
"libucrtbase",
Index: flang/tools/flang-driver/CMakeLists.txt
===
--- flang/tools/flang-driver/CMakeLists.txt
+++ flang/tools/flang-driver/CMakeLists.txt
@@ -19,8 +19,7 @@
# These libraries are used in the linker invocation generated by the driver
# (i.e. when constructing the linker job). Without them the driver would be
# unable to generate executables.
- FortranRuntime
- FortranDecimal
+ flang-rt
Fortran_main
)
Index: flang/test/lit.cfg.py
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
phosek added inline comments. Comment at: flang-rt/CMakeLists.txt:17-23 +# Check if flang-rt is built as a standalone project. +if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR FLANG_RT_STANDALONE_BUILD) + project(FlangRT C CXX) + set(CMAKE_INCLUDE_CURRENT_DIR ON) + set(FLANG_RT_STANDALONE_BUILD TRUE) + set_property(GLOBAL PROPERTY USE_FOLDERS ON) +endif() pscoro wrote: > vzakhari wrote: > > phosek wrote: > > > I don't think we should support building FlangRT as a standalone project. > > > We've been moving all runtimes to the runtimes build, the only leftover > > > is compiler-rt and our hope is to address that soon. > > Hi @phosek, can you please explain what you mean by "We've been moving all > > runtimes to the runtimes build"? Can you please share references to the > > pipeline for the "runtimes build"? > If i understood correctly, i think @phosek is talking about building the > flang-rt target directly (`cmake llvm-project/flang-rt`) when he says > standalone. Meanwhile a runtimes build is `cmake llvm-project/runtimes > -DLLVM_ENABLE_RUNTIMES=flang-rt`. I chose not to change anything yet because > I was focused on some other bugs and was waiting for see if anybody else had > input on this first. Also, in case my understanding is incorrect @phosek > please correct me. Yes, that is correct. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154869/new/ https://reviews.llvm.org/D154869 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro added inline comments. Comment at: flang-rt/CMakeLists.txt:17-23 +# Check if flang-rt is built as a standalone project. +if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR FLANG_RT_STANDALONE_BUILD) + project(FlangRT C CXX) + set(CMAKE_INCLUDE_CURRENT_DIR ON) + set(FLANG_RT_STANDALONE_BUILD TRUE) + set_property(GLOBAL PROPERTY USE_FOLDERS ON) +endif() vzakhari wrote: > phosek wrote: > > I don't think we should support building FlangRT as a standalone project. > > We've been moving all runtimes to the runtimes build, the only leftover is > > compiler-rt and our hope is to address that soon. > Hi @phosek, can you please explain what you mean by "We've been moving all > runtimes to the runtimes build"? Can you please share references to the > pipeline for the "runtimes build"? If i understood correctly, i think @phosek is talking about building the flang-rt target directly (`cmake llvm-project/flang-rt`) when he says standalone. Meanwhile a runtimes build is `cmake llvm-project/runtimes -DLLVM_ENABLE_RUNTIMES=flang-rt`. I chose not to change anything yet because I was focused on some other bugs and was waiting for see if anybody else had input on this first. Also, in case my understanding is incorrect @phosek please correct me. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154869/new/ https://reviews.llvm.org/D154869 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
vzakhari added inline comments. Comment at: flang-rt/CMakeLists.txt:17-23 +# Check if flang-rt is built as a standalone project. +if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR FLANG_RT_STANDALONE_BUILD) + project(FlangRT C CXX) + set(CMAKE_INCLUDE_CURRENT_DIR ON) + set(FLANG_RT_STANDALONE_BUILD TRUE) + set_property(GLOBAL PROPERTY USE_FOLDERS ON) +endif() phosek wrote: > I don't think we should support building FlangRT as a standalone project. > We've been moving all runtimes to the runtimes build, the only leftover is > compiler-rt and our hope is to address that soon. Hi @phosek, can you please explain what you mean by "We've been moving all runtimes to the runtimes build"? Can you please share references to the pipeline for the "runtimes build"? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D154869/new/ https://reviews.llvm.org/D154869 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro updated this revision to Diff 540110.
pscoro added a comment.
Fix build failures
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D154869/new/
https://reviews.llvm.org/D154869
Files:
clang/lib/Driver/ToolChains/CommonArgs.cpp
flang-rt/CMakeLists.txt
flang-rt/src/dummy.cpp
flang/CMakeLists.txt
flang/cmake/modules/AddFlang.cmake
flang/lib/Decimal/CMakeLists.txt
flang/runtime/CMakeLists.txt
flang/test/CMakeLists.txt
flang/test/Driver/linker-flags.f90
flang/test/lit.cfg.py
flang/tools/flang-driver/CMakeLists.txt
lld/COFF/MinGW.cpp
llvm/CMakeLists.txt
llvm/projects/CMakeLists.txt
runtimes/CMakeLists.txt
Index: runtimes/CMakeLists.txt
===
--- runtimes/CMakeLists.txt
+++ runtimes/CMakeLists.txt
@@ -19,7 +19,7 @@
# We order libraries to mirror roughly how they are layered, except that compiler-rt can depend
# on libc++, so we put it after.
-set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp")
+set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;flang-rt")
set(LLVM_SUPPORTED_RUNTIMES "${LLVM_DEFAULT_RUNTIMES};llvm-libgcc")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
Index: llvm/projects/CMakeLists.txt
===
--- llvm/projects/CMakeLists.txt
+++ llvm/projects/CMakeLists.txt
@@ -6,6 +6,7 @@
if(IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt)
if((NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/compiler-rt) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/dragonegg) AND
+ (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/flang-rt) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxx) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxxabi) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libunwind) AND
@@ -42,6 +43,8 @@
add_llvm_external_project(dragonegg)
add_llvm_external_project(openmp)
+add_llvm_external_project(flang-rt)
+
if(LLVM_INCLUDE_TESTS)
add_llvm_external_project(cross-project-tests)
endif()
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -149,7 +149,10 @@
# As we migrate runtimes to using the bootstrapping build, the set of default runtimes
# should grow as we remove those runtimes from LLVM_ENABLE_PROJECTS above.
set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind")
-set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc")
+if ("flang" IN_LIST LLVM_ENABLE_PROJECTS)
+ set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind;flang-rt")
+endif()
+set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc;flang-rt")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
if(LLVM_ENABLE_RUNTIMES STREQUAL "all")
@@ -171,6 +174,11 @@
endif()
endif()
+if ("flang" IN_LIST LLVM_ENABLE_PROJECTS AND NOT "flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)
+ message(STATUS "Enabling flang-rt to be built with the flang project")
+ list(APPEND LLVM_ENABLE_RUNTIMES "flang-rt")
+endif()
+
# LLVM_ENABLE_PROJECTS_USED is `ON` if the user has ever used the
# `LLVM_ENABLE_PROJECTS` CMake cache variable. This exists for
# several reasons:
Index: lld/COFF/MinGW.cpp
===
--- lld/COFF/MinGW.cpp
+++ lld/COFF/MinGW.cpp
@@ -50,8 +50,7 @@
"libc++",
"libc++abi",
"libFortran_main",
- "libFortranRuntime",
- "libFortranDecimal",
+ "libflang-rt",
"libunwind",
"libmsvcrt",
"libucrtbase",
Index: flang/tools/flang-driver/CMakeLists.txt
===
--- flang/tools/flang-driver/CMakeLists.txt
+++ flang/tools/flang-driver/CMakeLists.txt
@@ -19,8 +19,7 @@
# These libraries are used in the linker invocation generated by the driver
# (i.e. when constructing the linker job). Without them the driver would be
# unable to generate executables.
- FortranRuntime
- FortranDecimal
+ flang-rt
Fortran_main
)
Index: flang/test/lit.cfg.py
===
--- flang/test/lit.cfg.py
+++ flang/test/lit.cfg.py
@@ -153,19 +153,16 @@
# the C++ runtime libraries. For this we need a C compiler. If for some reason
# we don't have one, we can just disable the test.
if config.cc:
-libruntime = os.path.join(config.flang_lib_dir, "libFortranRuntime.a")
-libdecimal = os.path.join(config.flang_lib_dir,
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro updated this revision to Diff 540026.
pscoro added a comment.
Fix driver usage of flang-rt
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D154869/new/
https://reviews.llvm.org/D154869
Files:
clang/lib/Driver/ToolChains/CommonArgs.cpp
flang-rt/CMakeLists.txt
flang-rt/src/dummy.cpp
flang/CMakeLists.txt
flang/cmake/modules/AddFlang.cmake
flang/lib/Decimal/CMakeLists.txt
flang/runtime/CMakeLists.txt
flang/test/CMakeLists.txt
flang/test/Driver/linker-flags.f90
flang/test/lit.cfg.py
flang/tools/flang-driver/CMakeLists.txt
lld/COFF/MinGW.cpp
llvm/CMakeLists.txt
llvm/projects/CMakeLists.txt
runtimes/CMakeLists.txt
Index: runtimes/CMakeLists.txt
===
--- runtimes/CMakeLists.txt
+++ runtimes/CMakeLists.txt
@@ -19,7 +19,7 @@
# We order libraries to mirror roughly how they are layered, except that compiler-rt can depend
# on libc++, so we put it after.
-set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp")
+set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;flang-rt")
set(LLVM_SUPPORTED_RUNTIMES "${LLVM_DEFAULT_RUNTIMES};llvm-libgcc")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
Index: llvm/projects/CMakeLists.txt
===
--- llvm/projects/CMakeLists.txt
+++ llvm/projects/CMakeLists.txt
@@ -6,6 +6,7 @@
if(IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt)
if((NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/compiler-rt) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/dragonegg) AND
+ (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/flang-rt) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxx) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxxabi) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libunwind) AND
@@ -42,6 +43,8 @@
add_llvm_external_project(dragonegg)
add_llvm_external_project(openmp)
+add_llvm_external_project(flang-rt)
+
if(LLVM_INCLUDE_TESTS)
add_llvm_external_project(cross-project-tests)
endif()
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -149,7 +149,10 @@
# As we migrate runtimes to using the bootstrapping build, the set of default runtimes
# should grow as we remove those runtimes from LLVM_ENABLE_PROJECTS above.
set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind")
-set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc")
+if ("flang" IN_LIST LLVM_ENABLE_PROJECTS)
+ set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind;flang-rt")
+endif()
+set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc;flang-rt")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
if(LLVM_ENABLE_RUNTIMES STREQUAL "all")
Index: lld/COFF/MinGW.cpp
===
--- lld/COFF/MinGW.cpp
+++ lld/COFF/MinGW.cpp
@@ -50,8 +50,7 @@
"libc++",
"libc++abi",
"libFortran_main",
- "libFortranRuntime",
- "libFortranDecimal",
+ "libflang-rt",
"libunwind",
"libmsvcrt",
"libucrtbase",
Index: flang/tools/flang-driver/CMakeLists.txt
===
--- flang/tools/flang-driver/CMakeLists.txt
+++ flang/tools/flang-driver/CMakeLists.txt
@@ -19,8 +19,7 @@
# These libraries are used in the linker invocation generated by the driver
# (i.e. when constructing the linker job). Without them the driver would be
# unable to generate executables.
- FortranRuntime
- FortranDecimal
+ flang-rt
Fortran_main
)
Index: flang/test/lit.cfg.py
===
--- flang/test/lit.cfg.py
+++ flang/test/lit.cfg.py
@@ -153,19 +153,16 @@
# the C++ runtime libraries. For this we need a C compiler. If for some reason
# we don't have one, we can just disable the test.
if config.cc:
-libruntime = os.path.join(config.flang_lib_dir, "libFortranRuntime.a")
-libdecimal = os.path.join(config.flang_lib_dir, "libFortranDecimal.a")
+libruntime = os.path.join(config.flang_lib_dir, "libflang-rt.a")
include = os.path.join(config.flang_src_dir, "include")
if (
os.path.isfile(libruntime)
-and os.path.isfile(libdecimal)
and os.path.isdir(include)
):
config.available_features.add("c-compiler")
tools.append(ToolSubst("%cc", command=config.cc,
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro updated this revision to Diff 539545.
pscoro added a comment.
Small changes, flang-rt seems to work with the flang-new driver now.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D154869/new/
https://reviews.llvm.org/D154869
Files:
clang/lib/Driver/ToolChains/CommonArgs.cpp
flang-rt/CMakeLists.txt
flang-rt/src/dummy.cpp
flang/CMakeLists.txt
flang/cmake/modules/AddFlang.cmake
flang/include/flang/Runtime/float128.h
flang/lib/Decimal/CMakeLists.txt
flang/runtime/CMakeLists.txt
flang/test/CMakeLists.txt
flang/test/Driver/linker-flags.f90
flang/test/lit.cfg.py
flang/tools/flang-driver/CMakeLists.txt
lld/COFF/MinGW.cpp
llvm/CMakeLists.txt
llvm/projects/CMakeLists.txt
runtimes/CMakeLists.txt
Index: runtimes/CMakeLists.txt
===
--- runtimes/CMakeLists.txt
+++ runtimes/CMakeLists.txt
@@ -19,7 +19,7 @@
# We order libraries to mirror roughly how they are layered, except that compiler-rt can depend
# on libc++, so we put it after.
-set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp")
+set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;flang-rt")
set(LLVM_SUPPORTED_RUNTIMES "${LLVM_DEFAULT_RUNTIMES};llvm-libgcc")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
Index: llvm/projects/CMakeLists.txt
===
--- llvm/projects/CMakeLists.txt
+++ llvm/projects/CMakeLists.txt
@@ -6,6 +6,7 @@
if(IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt)
if((NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/compiler-rt) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/dragonegg) AND
+ (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/flang-rt) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxx) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxxabi) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libunwind) AND
@@ -42,6 +43,8 @@
add_llvm_external_project(dragonegg)
add_llvm_external_project(openmp)
+add_llvm_external_project(flang-rt)
+
if(LLVM_INCLUDE_TESTS)
add_llvm_external_project(cross-project-tests)
endif()
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -149,7 +149,10 @@
# As we migrate runtimes to using the bootstrapping build, the set of default runtimes
# should grow as we remove those runtimes from LLVM_ENABLE_PROJECTS above.
set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind")
-set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc")
+if ("flang" IN_LIST LLVM_ENABLE_PROJECTS)
+ set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind;flang-rt")
+endif()
+set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc;flang-rt")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
if(LLVM_ENABLE_RUNTIMES STREQUAL "all")
Index: lld/COFF/MinGW.cpp
===
--- lld/COFF/MinGW.cpp
+++ lld/COFF/MinGW.cpp
@@ -50,8 +50,7 @@
"libc++",
"libc++abi",
"libFortran_main",
- "libFortranRuntime",
- "libFortranDecimal",
+ "libflang-rt",
"libunwind",
"libmsvcrt",
"libucrtbase",
Index: flang/tools/flang-driver/CMakeLists.txt
===
--- flang/tools/flang-driver/CMakeLists.txt
+++ flang/tools/flang-driver/CMakeLists.txt
@@ -19,8 +19,7 @@
# These libraries are used in the linker invocation generated by the driver
# (i.e. when constructing the linker job). Without them the driver would be
# unable to generate executables.
- FortranRuntime
- FortranDecimal
+ flang-rt
Fortran_main
)
Index: flang/test/lit.cfg.py
===
--- flang/test/lit.cfg.py
+++ flang/test/lit.cfg.py
@@ -153,19 +153,16 @@
# the C++ runtime libraries. For this we need a C compiler. If for some reason
# we don't have one, we can just disable the test.
if config.cc:
-libruntime = os.path.join(config.flang_lib_dir, "libFortranRuntime.a")
-libdecimal = os.path.join(config.flang_lib_dir, "libFortranDecimal.a")
+libruntime = os.path.join(config.flang_lib_dir, "libflang-rt.a")
include = os.path.join(config.flang_src_dir, "include")
if (
os.path.isfile(libruntime)
-and os.path.isfile(libdecimal)
and os.path.isdir(include)
):
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro updated this revision to Diff 539113.
pscoro added a comment.
Some small changes, still non functional
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D154869/new/
https://reviews.llvm.org/D154869
Files:
clang/lib/Driver/ToolChains/CommonArgs.cpp
flang-rt/CMakeLists.txt
flang-rt/src/dummy.cpp
flang/CMakeLists.txt
flang/cmake/modules/AddFlang.cmake
flang/include/flang/Runtime/float128.h
flang/lib/Decimal/CMakeLists.txt
flang/runtime/CMakeLists.txt
flang/test/CMakeLists.txt
flang/test/Driver/linker-flags.f90
flang/test/lit.cfg.py
lld/COFF/MinGW.cpp
llvm/CMakeLists.txt
llvm/projects/CMakeLists.txt
runtimes/CMakeLists.txt
Index: runtimes/CMakeLists.txt
===
--- runtimes/CMakeLists.txt
+++ runtimes/CMakeLists.txt
@@ -19,7 +19,7 @@
# We order libraries to mirror roughly how they are layered, except that compiler-rt can depend
# on libc++, so we put it after.
-set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp")
+set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;flang-rt")
set(LLVM_SUPPORTED_RUNTIMES "${LLVM_DEFAULT_RUNTIMES};llvm-libgcc")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
Index: llvm/projects/CMakeLists.txt
===
--- llvm/projects/CMakeLists.txt
+++ llvm/projects/CMakeLists.txt
@@ -6,6 +6,7 @@
if(IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt)
if((NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/compiler-rt) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/dragonegg) AND
+ (NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/flang-rt) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxx) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libcxxabi) AND
(NOT ${entry} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR}/libunwind) AND
@@ -42,6 +43,8 @@
add_llvm_external_project(dragonegg)
add_llvm_external_project(openmp)
+add_llvm_external_project(flang-rt)
+
if(LLVM_INCLUDE_TESTS)
add_llvm_external_project(cross-project-tests)
endif()
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -149,7 +149,10 @@
# As we migrate runtimes to using the bootstrapping build, the set of default runtimes
# should grow as we remove those runtimes from LLVM_ENABLE_PROJECTS above.
set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind")
-set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc")
+if ("flang" IN_LIST LLVM_ENABLE_PROJECTS)
+ set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind;flang-rt")
+endif()
+set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc;flang-rt")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
if(LLVM_ENABLE_RUNTIMES STREQUAL "all")
Index: lld/COFF/MinGW.cpp
===
--- lld/COFF/MinGW.cpp
+++ lld/COFF/MinGW.cpp
@@ -50,8 +50,7 @@
"libc++",
"libc++abi",
"libFortran_main",
- "libFortranRuntime",
- "libFortranDecimal",
+ "libflang-rt",
"libunwind",
"libmsvcrt",
"libucrtbase",
Index: flang/test/lit.cfg.py
===
--- flang/test/lit.cfg.py
+++ flang/test/lit.cfg.py
@@ -153,19 +153,16 @@
# the C++ runtime libraries. For this we need a C compiler. If for some reason
# we don't have one, we can just disable the test.
if config.cc:
-libruntime = os.path.join(config.flang_lib_dir, "libFortranRuntime.a")
-libdecimal = os.path.join(config.flang_lib_dir, "libFortranDecimal.a")
+libruntime = os.path.join(config.flang_lib_dir, "libflang-rt.a")
include = os.path.join(config.flang_src_dir, "include")
if (
os.path.isfile(libruntime)
-and os.path.isfile(libdecimal)
and os.path.isdir(include)
):
config.available_features.add("c-compiler")
tools.append(ToolSubst("%cc", command=config.cc, unresolved="fatal"))
tools.append(ToolSubst("%libruntime", command=libruntime, unresolved="fatal"))
-tools.append(ToolSubst("%libdecimal", command=libdecimal, unresolved="fatal"))
tools.append(ToolSubst("%include", command=include, unresolved="fatal"))
# Add all the tools and their substitutions (if applicable). Use the search paths provided for
Index: flang/test/Driver/linker-flags.f90
===
---
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro updated this revision to Diff 538749.
pscoro added a comment.
Comment out some code that irrelevant to current object library approach
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D154869/new/
https://reviews.llvm.org/D154869
Files:
clang/lib/Driver/ToolChains/CommonArgs.cpp
flang-rt/CMakeLists.txt
flang-rt/src/dummy.cpp
flang/cmake/modules/AddFlang.cmake
flang/include/flang/Runtime/float128.h
flang/lib/Decimal/CMakeLists.txt
flang/runtime/CMakeLists.txt
flang/test/CMakeLists.txt
flang/test/Driver/linker-flags.f90
flang/test/lit.cfg.py
lld/COFF/MinGW.cpp
llvm/CMakeLists.txt
runtimes/CMakeLists.txt
Index: runtimes/CMakeLists.txt
===
--- runtimes/CMakeLists.txt
+++ runtimes/CMakeLists.txt
@@ -19,7 +19,7 @@
# We order libraries to mirror roughly how they are layered, except that compiler-rt can depend
# on libc++, so we put it after.
-set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp")
+set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;flang-rt")
set(LLVM_SUPPORTED_RUNTIMES "${LLVM_DEFAULT_RUNTIMES};llvm-libgcc")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -149,7 +149,10 @@
# As we migrate runtimes to using the bootstrapping build, the set of default runtimes
# should grow as we remove those runtimes from LLVM_ENABLE_PROJECTS above.
set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind")
-set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc")
+if ("flang" IN_LIST LLVM_ENABLE_PROJECTS)
+ set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind;flang-rt")
+endif()
+set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc;flang-rt")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
if(LLVM_ENABLE_RUNTIMES STREQUAL "all")
Index: lld/COFF/MinGW.cpp
===
--- lld/COFF/MinGW.cpp
+++ lld/COFF/MinGW.cpp
@@ -50,8 +50,7 @@
"libc++",
"libc++abi",
"libFortran_main",
- "libFortranRuntime",
- "libFortranDecimal",
+ "libFlangRT",
"libunwind",
"libmsvcrt",
"libucrtbase",
Index: flang/test/lit.cfg.py
===
--- flang/test/lit.cfg.py
+++ flang/test/lit.cfg.py
@@ -153,19 +153,16 @@
# the C++ runtime libraries. For this we need a C compiler. If for some reason
# we don't have one, we can just disable the test.
if config.cc:
-libruntime = os.path.join(config.flang_lib_dir, "libFortranRuntime.a")
-libdecimal = os.path.join(config.flang_lib_dir, "libFortranDecimal.a")
+libruntime = os.path.join(config.flang_lib_dir, "libFlangRT.a")
include = os.path.join(config.flang_src_dir, "include")
if (
os.path.isfile(libruntime)
-and os.path.isfile(libdecimal)
and os.path.isdir(include)
):
config.available_features.add("c-compiler")
tools.append(ToolSubst("%cc", command=config.cc, unresolved="fatal"))
tools.append(ToolSubst("%libruntime", command=libruntime, unresolved="fatal"))
-tools.append(ToolSubst("%libdecimal", command=libdecimal, unresolved="fatal"))
tools.append(ToolSubst("%include", command=include, unresolved="fatal"))
# Add all the tools and their substitutions (if applicable). Use the search paths provided for
Index: flang/test/Driver/linker-flags.f90
===
--- flang/test/Driver/linker-flags.f90
+++ flang/test/Driver/linker-flags.f90
@@ -24,21 +24,18 @@
! GNU-LABEL: "{{.*}}ld{{(\.exe)?}}"
! GNU-SAME: "[[object_file]]"
! GNU-SAME: -lFortran_main
-! GNU-SAME: -lFortranRuntime
-! GNU-SAME: -lFortranDecimal
+! GNU-SAME: -lFlangRT
! GNU-SAME: -lm
! DARWIN-LABEL: "{{.*}}ld{{(\.exe)?}}"
! DARWIN-SAME: "[[object_file]]"
! DARWIN-SAME: -lFortran_main
-! DARWIN-SAME: -lFortranRuntime
-! DARWIN-SAME: -lFortranDecimal
+! DARWIN-SAME: -lFlangRT
! MINGW-LABEL: "{{.*}}ld{{(\.exe)?}}"
! MINGW-SAME: "[[object_file]]"
! MINGW-SAME: -lFortran_main
-! MINGW-SAME: -lFortranRuntime
-! MINGW-SAME: -lFortranDecimal
+! MINGW-SAME: -lFlangRT
! NOTE: This also matches lld-link (when CLANG_DEFAULT_LINKER=lld) and
! any .exe suffix that is added when resolving to the full path of
@@ -46,7 +43,6 @@
! when the executable is not found or on non-Windows platforms.
!
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
phosek added inline comments.
Comment at: flang-rt/CMakeLists.txt:17-23
+# Check if flang-rt is built as a standalone project.
+if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR
FLANG_RT_STANDALONE_BUILD)
+ project(FlangRT C CXX)
+ set(CMAKE_INCLUDE_CURRENT_DIR ON)
+ set(FLANG_RT_STANDALONE_BUILD TRUE)
+ set_property(GLOBAL PROPERTY USE_FOLDERS ON)
+endif()
I don't think we should support building FlangRT as a standalone project. We've
been moving all runtimes to the runtimes build, the only leftover is
compiler-rt and our hope is to address that soon.
Comment at: flang-rt/CMakeLists.txt:41-51
+set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
+set(CMAKE_LIBRARY_OUTPUT_DIRECTORY
+ ${CMAKE_BINARY_DIR}/lib)
+set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY
+ ${CMAKE_BINARY_DIR}/lib)
+set(CMAKE_CURRENT_BINARY_DIR ${CMAKE_LIBRARY_OUTPUT_DIRECTORY})
+
None of this should be needed if building in the runtimes build.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D154869/new/
https://reviews.llvm.org/D154869
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro added inline comments.
Comment at: flang/cmake/modules/AddFlang.cmake:68
llvm_add_library(${name} ${LIBTYPE} ${ARG_UNPARSED_ARGUMENTS} ${srcs})
+ set_target_properties(${name} PROPERTIES POSITION_INDEPENDENT_CODE ON)
This is something I am still investigating.
PIC is needed for the object libraries if FlangRT is being built as shared. I
am thinking I will add a condition for this to only be enabled for
FortranRuntime and FortranDecimalRT. Also, if my understanding is correct, if
we build FlangRT as static this change may also not be needed (and keeping it
may be slightly less optimal?), so I may ad a condition for this as well.
My understanding of PIC is limited so if anybody sees any problems with my
understanding please let me know.
Comment at: flang/include/flang/Runtime/float128.h:42
*/
-#if __x86_64__
-#if __GNUC__ >= 7 || __clang_major__ >= 7
-#define HAS_FLOAT128 1
-#endif
-#elif defined __PPC__ && __GNUC__ >= 8
-#define HAS_FLOAT128 1
-#endif
+//#if __x86_64__
+//#if __GNUC__ >= 7 || __clang_major__ >= 7
Entirely uncertain why this code was giving me issues during my testing. I
commented it out for the time being but I will take a closer look later. I hope
that it is related to my setup and not something about the patch itself,
however I will have to investigate further before I can draw any conclusions.
Comment at: flang/lib/Decimal/CMakeLists.txt:62
+if ("flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES OR FLANG_RT_STANDALONE_BUILD)
+ add_flang_library(FortranDecimalRT STATIC INSTALL_WITH_TOOLCHAIN
+binary-to-decimal.cpp
The code in AddFlang.cmake seems to build object libraries for calls to
`add_flang_library` by default when STATIC argument is passed.
Comment at: flang/runtime/CMakeLists.txt:252
+if ("flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)
+ add_flang_library(FortranRuntime STATIC
+${sources}
The code in AddFlang.cmake seems to build object libraries for calls to
`add_flang_library` by default when STATIC argument is passed.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D154869/new/
https://reviews.llvm.org/D154869
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D154869: [Flang] [FlangRT] Implement FlangRT library as solution to Flang's runtime LLVM integration
pscoro created this revision.
Herald added subscribers: sunshaoce, mstorsjo.
Herald added a reviewer: sscalpone.
Herald added a reviewer: awarzynski.
Herald added projects: Flang, All.
pscoro requested review of this revision.
Herald added subscribers: llvm-commits, libcxx-commits, cfe-commits, jplehr,
sstefan1, jdoerfert, MaskRay.
Herald added a reviewer: jdoerfert.
Herald added projects: clang, libc++, libc++abi, libunwind, LLVM.
Herald added a reviewer: libc++.
Herald added a reviewer: libc++abi.
Herald added a reviewer: libunwind.
Repository:
rG LLVM Github Monorepo
https://reviews.llvm.org/D154869
Files:
clang/lib/Driver/ToolChains/CommonArgs.cpp
flang-rt/CMakeLists.txt
flang-rt/src/dummy.cpp
flang/cmake/modules/AddFlang.cmake
flang/include/flang/Runtime/float128.h
flang/lib/Decimal/CMakeLists.txt
flang/runtime/CMakeLists.txt
flang/test/CMakeLists.txt
flang/test/Driver/linker-flags.f90
flang/test/lit.cfg.py
lld/COFF/MinGW.cpp
llvm/CMakeLists.txt
runtimes/CMakeLists.txt
Index: runtimes/CMakeLists.txt
===
--- runtimes/CMakeLists.txt
+++ runtimes/CMakeLists.txt
@@ -19,7 +19,7 @@
# We order libraries to mirror roughly how they are layered, except that compiler-rt can depend
# on libc++, so we put it after.
-set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp")
+set(LLVM_DEFAULT_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;flang-rt")
set(LLVM_SUPPORTED_RUNTIMES "${LLVM_DEFAULT_RUNTIMES};llvm-libgcc")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -149,7 +149,10 @@
# As we migrate runtimes to using the bootstrapping build, the set of default runtimes
# should grow as we remove those runtimes from LLVM_ENABLE_PROJECTS above.
set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind")
-set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc")
+if ("flang" IN_LIST LLVM_ENABLE_PROJECTS)
+ set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind;flang-rt")
+endif()
+set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc;flang-rt")
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
if(LLVM_ENABLE_RUNTIMES STREQUAL "all")
Index: lld/COFF/MinGW.cpp
===
--- lld/COFF/MinGW.cpp
+++ lld/COFF/MinGW.cpp
@@ -50,8 +50,7 @@
"libc++",
"libc++abi",
"libFortran_main",
- "libFortranRuntime",
- "libFortranDecimal",
+ "libFlangRT",
"libunwind",
"libmsvcrt",
"libucrtbase",
Index: flang/test/lit.cfg.py
===
--- flang/test/lit.cfg.py
+++ flang/test/lit.cfg.py
@@ -153,19 +153,16 @@
# the C++ runtime libraries. For this we need a C compiler. If for some reason
# we don't have one, we can just disable the test.
if config.cc:
-libruntime = os.path.join(config.flang_lib_dir, "libFortranRuntime.a")
-libdecimal = os.path.join(config.flang_lib_dir, "libFortranDecimal.a")
+libruntime = os.path.join(config.flang_lib_dir, "libFlangRT.a")
include = os.path.join(config.flang_src_dir, "include")
if (
os.path.isfile(libruntime)
-and os.path.isfile(libdecimal)
and os.path.isdir(include)
):
config.available_features.add("c-compiler")
tools.append(ToolSubst("%cc", command=config.cc, unresolved="fatal"))
tools.append(ToolSubst("%libruntime", command=libruntime, unresolved="fatal"))
-tools.append(ToolSubst("%libdecimal", command=libdecimal, unresolved="fatal"))
tools.append(ToolSubst("%include", command=include, unresolved="fatal"))
# Add all the tools and their substitutions (if applicable). Use the search paths provided for
Index: flang/test/Driver/linker-flags.f90
===
--- flang/test/Driver/linker-flags.f90
+++ flang/test/Driver/linker-flags.f90
@@ -24,21 +24,18 @@
! GNU-LABEL: "{{.*}}ld{{(\.exe)?}}"
! GNU-SAME: "[[object_file]]"
! GNU-SAME: -lFortran_main
-! GNU-SAME: -lFortranRuntime
-! GNU-SAME: -lFortranDecimal
+! GNU-SAME: -lFlangRT
! GNU-SAME: -lm
! DARWIN-LABEL: "{{.*}}ld{{(\.exe)?}}"
! DARWIN-SAME: "[[object_file]]"
! DARWIN-SAME: -lFortran_main
-! DARWIN-SAME: -lFortranRuntime
-! DARWIN-SAME: -lFortranDecimal
+! DARWIN-SAME: -lFlangRT
! MINGW-LABEL: "{{.*}}ld{{(\.exe)?}}"
! MINGW-SAME: "[[object_file]]"
! MINGW-SAME: -lFortran_main
-!
