Mon, Jun 17
Sun, Jun 16
Fri, Jun 14
Since you always include all three of //llvm/lib/Target/targets.gni, //llvm/lib/Target/targets_with_asm_parsers.gni, //llvm/lib/Target/targets_with_disassemblers.gni, why not just combine all of them into //llvm/lib/Target/targets.gni? If we ever need them separately and performance becomes an issue, we can split them later.
Thu, Jun 13
This broke all our macOS builders:
llvm-lit: /b/s/w/ir/k/llvm-project/llvm/utils/lit/lit/TestingConfig.py:102: fatal: unable to parse config file '/b/s/w/ir/k/recipe_cleanup/clangh7IvHV/llvm_build_dir/tools/lld/test/lit.site.cfg.py', traceback: Traceback (most recent call last): File "/b/s/w/ir/k/llvm-project/llvm/utils/lit/lit/TestingConfig.py", line 89, in load_from_path exec(compile(data, path, 'exec'), cfg_globals, None) File "/b/s/w/ir/k/recipe_cleanup/clangh7IvHV/llvm_build_dir/tools/lld/test/lit.site.cfg.py", line 31, in <module> lit.llvm.initialize(lit_config, config) File "/b/s/w/ir/k/llvm-project/llvm/utils/lit/lit/llvm/__init__.py", line 9, in initialize llvm_config = config.LLVMConfig(lit_config, test_config) File "/b/s/w/ir/k/llvm-project/llvm/utils/lit/lit/llvm/config.py", line 51, in __init__ if config.enable_shared: AttributeError: TestingConfig instance has no attribute 'enable_shared'
The problem is that enable_shared isn't defined in lld's lit.site.cfg.py. Is it possible to either fix this or revert this change?
Wed, Jun 12
Tue, Jun 11
Mon, Jun 10
One more thing, do you think it's reasonable to use llvm::sys::findProgramByName(Args)instead of Args when creating the driver instance? One of the failure modes I ran into is the case where the generated compilation database would contain just the executable name, e.g. clang++. If you invoke that command, everything works as expected because driver resolves the binary to a full path, but when used with clangd, it'll fail because that resolution will never happen, the Dir/InstalledDir will be an empty path and attempt to resolve C++ library headers will end up with /../include/c++/v1 which is invalid.
argv does carry important information though, I think this will break a lot of things. It's... concerning that no tests broke.
For example, if it's clang or g++ or clang-cl then that affects how command lines are parsed (regardless of whether the path actually exists).
Wed, Jun 5
Tue, Jun 4
This seems to have introduced PR42129.
Mon, Jun 3
https://storage.googleapis.com/fuchsia-build/reproducer/fuzzer.tar.bz2 is the reproducer.
We're now getting a lot of STT_SECTION symbol should be defined warnings when building libFuzzer: https://logs.chromium.org/logs/fuchsia/buildbucket/cr-buildbucket.appspot.com/8911634509805270864/+/steps/clang/0/steps/build/0/stdout. The libFuzzer uses lld to produce a single relocatable file with libc++ linked in: https://github.com/llvm/llvm-project/blob/master/compiler-rt/lib/fuzzer/CMakeLists.txt#L132. I haven't yet figured out what's going on (the warning could be also a little more specific, e.g. which symbol and which section). Do you have any idea what's going on?
Sat, Jun 1
Fri, May 31
Thu, May 30
Wed, May 29
I've tested this locally and it seems to be working fine, I'd like to land this to unbreak our bots.
-DLLVM_USE_RELATIVE_PATHS is very generic sounding and might give a false impression. Is there a name that emphasizes that this affects the debug info of the built compiler?
Does anyone have any opinion on add_compile_flags_if_supported vs check_cxx_compiler_flag + append_if? If not I'm going to land this as is.
It's not entirely clear to me that adding an option to control this is better than just doing it unconditionally. Have you run into a scenario where you didn't want to enable it (and if so, why?).
If that's "just in case", I'd suggest doing it unconditionally and adding an option later if a vendor wants to disable it.
Tue, May 28
Alternative would be to avoid add_compile_flags_if_supported altogether and instead the combination of check_cxx_compiler_flag and append_if as is used in libunwind (https://github.com/llvm/llvm-project/blob/master/libunwind/CMakeLists.txt#L274). The advantage of the latter is that we could in theory have different config-ix.cmake files (e.g. pre-populated ones for the runtimes build).