[PATCH] D101681: [Compiler-rt] Distinguish between testing just built runtime libraries and the libraries shipped with the compiler.

Petr Hosek via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon May 3 22:24:07 PDT 2021


phosek added a subscriber: ldionne.
phosek added a comment.

Do we know for sure that people are using compiler-rt test suite to test runtime libraries shipped with their compiler? I'm a bit surprised by that since it's not a case I've ever considered. I'd prefer if we always used `-nodefaultlibs` to prevent that case altogether since compiler-rt build is already exceedingly complicated and we should ideally strive to reduce the number of modes and options we have to support.



================
Comment at: compiler-rt/test/lit.common.cfg.py:54
+    path = os.path.join(path, 'darwin')
+  else:
+    return None
----------------
delcypher wrote:
> delcypher wrote:
> > @phosek I'd be curious how you think we should handle other platforms. If ` LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` wasn't a thing for Linux this would be just be something like.
> > 
> > ```lang=python
> > if config.host_os == 'Linux':
> >   path = os.path.join(path, 'linux')
> > ```
> > 
> > but `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` makes this more complicated.
> Hmm so doing something like `clang --target <target_triple> -print-runtime-dir` would actually help here. The problem is.
> 
> 1. This flag is so new it doesn't exist in the compilers I'm currently trying to test.
> 2. It actually returns a completely incorrect path on Darwin. I've put up a patch for this https://reviews.llvm.org/D101682
> 
> I suppose I could have the current code as a fallback if `-print-runtime-dir` isn't supported, but otherwise use `-print-runtime-dir`.
I'd prefer to make `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` the default, and eventually the only mode. It's something we've already discussed with @ldionne and I'm planning on sending out an RFC proposing that. Deprecating non-`LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` build might take a while so we may have to support both unfortunately for the foreseeable future.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101681/new/

https://reviews.llvm.org/D101681



More information about the llvm-commits mailing list