jhuber6 wrote:
> In addition to that `clang-nvlink-wrapper` should diagnose unrecognized > options rather than silently ignoring them. Do you agree? The default behavior is assuming that if something isn't supported by our interface, it will be supported by the underlying linker. There are loads of `nvlink` flags and NVIDIA will potentially add more. > @jhuber6, I see that `clang-nvlink-wrapper` doesn't support `-z` option (see > https://github.com/llvm/llvm-project/blob/main/clang/tools/clang-nvlink-wrapper/NVLinkOpts.td). > `-z,relro` is misparsed into `relro` input file, which was ignored before my > change (technically ignoring `-z,relro` option). I don't know off the top of my head what this did beforehand. I don't think our priority should be supporting literally everything. I do not know why these flags are appearing, normally through the LLVM builds these should be curated more. Maybe it's showing up because I need to do some spoofing of linker flags in the runtimes configure step for NVIDIA? We can't do a real cmake flag check because the user may not have nvlink. https://github.com/llvm/llvm-project/pull/201253 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
