agozillon wrote: > > I am gonna sign off for the weekend as it's quite late here, so I'll reply > > in a little more detail on Monday and update the PR further. but I'd be > > happy to add a further flang test, although not too sure what it'd be, so > > suggestions are welcome. > > I tested this with an out of tree build of GPU libc (basically two seperate > > build directories) and found that -lgpuc wouldn't get the ordering correct > > to link the library correctly to the fortran runtime, so it seemed for this > > specific case of an out of tree build of GPU libc the option was the > > correct way to get it linked in in the correct order. In the case of it > > finding it in the correct directory i didn't quite manage the perfect build > > recipe for it (suggestions welcome here as well) and tend to not use the > > install option myself, but perhaps it would auto detect for Flang as well! > > However, in the case where it's an separately compiled and installed gpu > > libc it might be nice to have this option activated as well for Flang to > > make both methods of linking possible. However, i am a little bit of a > > driver and build environment/system noob so ill defer to everyone else's > > better judgement in this case! > > If you have the static library, and it contains an entry for the desired > architecture, it should just work so long as you're using the "new" driver > pipeline. However, ordering is important here. It behaves similarly to the > GNU BFD linker, where a static library is only checked against the current > state of the symbol table as it reads the files in input order. So `uses.o > -lfoo` will extract but `-lfoo uses.o` will not. > > It's possible that this just was being linked too late with however Fortran > handles it. I decided to be conservative with the default here because I'm > assuming very few people will actually have the GPU `libc`.
I think it might just have been a little too late, or perhaps I was doing it incorrectly, always a possibility, but in either case it's possible to have it auto-included similarly to Clang with Flang, if the library resides in the correct directory and if it's not available in the directory enabling these options will allow it to still be linked into the runtime correctly when the correct one is specified on the command line! So I believe it will work fine in the above cases, just passing the library directly on the command line via -lcgpu just won't work to resolve the necessary calls in the fortran runtime for now unfortunately, but as the other two methods work fine it's not particularly necessary! > It would be very interesting to see something like `puts` working from > Fortran, so let me know if there's anything I can do to help. I'd love to try more complex programs in the near future that depend on more runtime features (in particular the stdout you mentioned previously would be interesting to try, but I'm not too sure how the print functionality in flang-new actually works at the moment), for the moment this has primarily just been me trying to fix a test I came across that will utilise a Fortran runtime function on device without a user explicitly calling it (an assign operation that lowers to a runtime function call) and it works quite nicely with a fortran runtime compiled for GPU and then linked into the GPU libc library for now (with some other not driver or library related changes)! I imagine we'll be running into more uses for the runtime on device in the near future to test. https://github.com/llvm/llvm-project/pull/77135 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
