summaryrefslogtreecommitdiffstats
path: root/llvm/utils/gn
Commit message (Collapse)AuthorAgeFilesLines
...
* gn build: Merge r364389Nico Weber2019-06-261-0/+1
| | | | llvm-svn: 364408
* gn build: Merge r364288.Peter Collingbourne2019-06-261-0/+1
| | | | llvm-svn: 364374
* [GN] Generation failure caused by trailing space in file namePetr Hosek2019-06-231-1/+1
| | | | | | | | | | | | | | | | | | When I executed gn.py gen out/gn I got the following error: ERROR at //compiler-rt/lib/builtins/BUILD.gn:162:7: Only source, header, and object files belong in the sources of a static_library. //compiler-rt/lib/builtins/emutls.c is not one of the valid types. "emutls.c ", ^---------- See //compiler-rt/lib/BUILD.gn:3:5: which caused the file to be included. "//compiler-rt/lib/builtins", ^--------------------------- It turns out to be that the latest gn doesn't accept ill-format file name. And the emutls.c above has a trailing space. Remove the trailing space should work. Patch By: myhsu Differential Revision: https://reviews.llvm.org/D63449 llvm-svn: 364162
* gn build: Merge r364046.Peter Collingbourne2019-06-221-0/+1
| | | | llvm-svn: 364116
* [GN] Fix check-clang by disabling pluginsVitaly Buka2019-06-211-1/+2
| | | | | | We can't link Analysis/plugins without -fPIC llvm-svn: 364016
* [GN] Put libcxx include into the same place as cmake to fix ↵Vitaly Buka2019-06-212-2/+2
| | | | | | Driver/print-file-name.c test llvm-svn: 364015
* [GN] Fix buildVitaly Buka2019-06-214-8/+3
| | | | llvm-svn: 364004
* gn build: Merge r363948Nico Weber2019-06-201-0/+1
| | | | llvm-svn: 363960
* gn build: Merge r363757.Peter Collingbourne2019-06-191-1/+1
| | | | llvm-svn: 363865
* gn build: Merge r363848.Peter Collingbourne2019-06-191-0/+1
| | | | llvm-svn: 363864
* gn build: Merge r363846.Peter Collingbourne2019-06-191-0/+1
| | | | llvm-svn: 363863
* gn build: Merge r363794.Peter Collingbourne2019-06-191-0/+1
| | | | llvm-svn: 363862
* gn build: Merge r363680.Peter Collingbourne2019-06-191-0/+1
| | | | llvm-svn: 363861
* gn build: Merge r363712.Peter Collingbourne2019-06-191-1/+2
| | | | llvm-svn: 363860
* gn build: Merge r363658Nico Weber2019-06-181-0/+1
| | | | llvm-svn: 363673
* gn build: Merge r363649Nico Weber2019-06-181-1/+0
| | | | | | | This reverts commit "gn build: Merge r363626" because r363626 was reverted in r363649. llvm-svn: 363672
* gn build: Merge r363626.Peter Collingbourne2019-06-171-0/+1
| | | | llvm-svn: 363634
* gn build: Merge r363483.Peter Collingbourne2019-06-171-0/+2
| | | | llvm-svn: 363610
* gn build: Merge r363584.Peter Collingbourne2019-06-171-0/+1
| | | | llvm-svn: 363609
* gn build: Merge r363541Nico Weber2019-06-172-9/+7
| | | | llvm-svn: 363583
* gn build: Merge r363530Nico Weber2019-06-171-1/+1
| | | | llvm-svn: 363549
* gn build: Merge r363444Nico Weber2019-06-161-0/+1
| | | | llvm-svn: 363505
* gn build: Add NVPTX targetNico Weber2019-06-149-4/+167
| | | | | | | | | | | | | | | | | | | The NVPTX target is a bit unusual in that it's the only target without a disassembler, and one of three targets without an asm parser (and the first one of those three in the gn build). NVPTX doesn't have those because it's not a binary format. The CMake build checks for the existence of {AsmParser,Disassembler}/CMakeLists.txt when setting LLVM_ENUM_ASM_PARSERS / LLVM_ENUM_DISASSEBLERS (http://llvm-cs.pcc.me.uk/CMakeLists.txt#744). The GN build doesn't want to hit the disk for things like this, so instead I'm adding explicit `targets_with_asm_parsers` and `targets_with_disassemblers` lists. Since both are needed rarely, they are defined in their own gni files. Differential Revision: https://reviews.llvm.org/D63210 llvm-svn: 363437
* gn build: Simplify Target build filesNico Weber2019-06-1421-159/+73
| | | | | | | | | | | | | | | | Now that the cycle between MCTargetDesc and TargetInfo is gone (see revisions 360709 360718 360722 360724 360726 360731 360733 360735 360736), remove the dependency from TargetInfo on MCTargetDesc:tablegen. In most targets, this makes MCTargetDesc:tablegen have just a single use, so inline it there. For AArch64, ARM, and RISCV there's still a similar cycle between MCTargetDesc and Utils, so the MCTargetDesc:tablegen indirection is still needed there. Differential Revision: https://reviews.llvm.org/D63200 llvm-svn: 363436
* gn build: Merge r363376Nico Weber2019-06-142-7/+9
| | | | llvm-svn: 363378
* gn build: Merge r363204 (clang-scan-deps)Nico Weber2019-06-142-0/+21
| | | | llvm-svn: 363353
* gn build: Merge r363242Nico Weber2019-06-132-9/+7
| | | | llvm-svn: 363324
* gn build: Add SystemZ targetNico Weber2019-06-127-1/+194
| | | | llvm-svn: 363170
* gn build: Add Mips targetNico Weber2019-06-127-1/+253
| | | | llvm-svn: 363159
* gn build: add RISCV targetNico Weber2019-06-127-0/+234
| | | | | | | | Patch from David L. Jones <dlj@google.com>, with minor tweaks by me. Differential Revision: https://reviews.llvm.org/D61821 llvm-svn: 363154
* gn build: Merge r363122Nico Weber2019-06-121-0/+1
| | | | llvm-svn: 363152
* Share /machine: handling code with llvm-cvtres tooNico Weber2019-06-121-0/+1
| | | | | | | | | | | | | | r363016 let lld-link and llvm-lib share the /machine: parsing code. This lets llvm-cvtres share it as well. Making llvm-cvtres depend on llvm-lib seemed a bit strange (it doesn't need llvm-lib's dependencies on BinaryFormat and BitReader) and I couldn't find a good place to put this code. Since it's just a few lines, put it in lib/Object for now. Differential Revision: https://reviews.llvm.org/D63120 llvm-svn: 363144
* lld-link: Reject more than one resource .obj fileNico Weber2019-06-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Users are exepcted to pass all .res files to the linker, which then merges all the resource in all .res files into a tree structure and then converts the final tree structure to a .obj file with .rsrc$01 and .rsrc$02 sections and then links that. If the user instead passes several .obj files containing such resources, the correct thing to do would be to have custom code to merge the trees in the resource sections instead of doing normal section merging -- but link.exe rejects if multiple resource obj files are passed in with LNK4078, so let lld-link do that too instead of silently writing broken .rsrc sections in that case. The only real way to run into this is if users manually convert .res files to .obj files by running cvtres and then handing the resulting .obj files to lld-link instead, which in practice likely never happens. (lld-link is slightly stricter than link.exe now: If link.exe is passed one .obj file created by cvtres, and a .res file, for some reason it just emits a warning instead of an error and outputs strange looking data. lld-link now errors out on mixed input like this.) One way users could accidentally run into this is the following scenario: If a .res file is passed to lib.exe, then lib.exe calls cvtres.exe on the .res file before putting it in the output .lib. (llvm-lib currently doesn't do this.) link.exe's /wholearchive seems to only add obj files referenced from the static library index, but lld-link current really adds all files in the archive. So if lld-link /wholearchive is used with .lib files produced by lib.exe and .res files were among the files handed to lib.exe, we previously silently produced invalid output, but now we error out. link.exe's /wholearchive semantics on the other hand mean that it wouldn't load the resource object files from the .lib file at all. Since this scenario is probably still an unlikely corner case, the difference in behavior here seems fine -- and lld-link might have to change to use link.exe's /wholearchive semantics in the future anyways. Vaguely related to PR42180. Differential Revision: https://reviews.llvm.org/D63109 llvm-svn: 363078
* gn build: Merge r362939Nico Weber2019-06-112-0/+2
| | | | llvm-svn: 363020
* gn build: Merge r362972Nico Weber2019-06-111-0/+1
| | | | llvm-svn: 363019
* gn build: Merge r362913Nico Weber2019-06-101-1/+0
| | | | llvm-svn: 362932
* gn build: Merge r362857Nico Weber2019-06-081-0/+1
| | | | llvm-svn: 362864
* llvm-lib: Disallow mixing object files with different machine typesNico Weber2019-06-071-0/+1
| | | | | | | | | | | | | | | lib.exe doesn't allow creating .lib files with object files that have differing machine types. Update llvm-lib to match. The motivation is to make it possible to infer the machine type of a .lib file in lld, so that it can warn when e.g. a 32-bit .lib file is passed to a 64-bit link (PR38965). Fixes PR38782. Differential Revision: https://reviews.llvm.org/D62913 llvm-svn: 362798
* gn build: Merge r362766Nico Weber2019-06-071-0/+1
| | | | llvm-svn: 362796
* gn build: Merge r362774Nico Weber2019-06-071-0/+1
| | | | llvm-svn: 362795
* gn build: Run `git ls-files '*.gn' '*.gni' | xargs llvm/utils/gn/gn.py format`Nico Weber2019-06-071-1/+1
| | | | llvm-svn: 362794
* gn build: Merge r362685Nico Weber2019-06-061-0/+1
| | | | llvm-svn: 362719
* gn build: Add new tidy checks to gn filesIlya Biryukov2019-06-061-0/+2
| | | | | | The checks were added in r362673 and r362672. llvm-svn: 362709
* gn build: Merge r362578Nico Weber2019-06-051-0/+1
| | | | llvm-svn: 362598
* gn build: Merge r362459Nico Weber2019-06-042-0/+2
| | | | llvm-svn: 362498
* gn build: Merge r361896.Peter Collingbourne2019-06-032-0/+20
| | | | llvm-svn: 362445
* gn build: Merge r362371Nico Weber2019-06-033-0/+10
| | | | llvm-svn: 362433
* gn build: Merge r362352Nico Weber2019-06-031-0/+1
| | | | llvm-svn: 362428
* gn build: Merge r362160Nico Weber2019-05-311-0/+1
| | | | llvm-svn: 362223
* gn build: Merge r362196Nico Weber2019-05-311-0/+2
| | | | llvm-svn: 362222
OpenPOWER on IntegriCloud