summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support
Commit message (Collapse)AuthorAgeFilesLines
...
* [X86] Remove asserts from getX86CpuIDAndInfo/getX86CpuIDAndInfoEx. Restore ↵Craig Topper2017-07-101-7/+10
| | | | | | | | | | past behavior of returning an unsupported indication to the caller instead. These asserts could only occur if we fail to properly detect the compiler, but an assert is not a good way to do that because it doesn't work in release builds. I wonder if we could use #error? llvm-svn: 307520
* [X86] Remove check for AVX512 support from skylake-avx512 detection in ↵Craig Topper2017-07-091-6/+1
| | | | | | | | getHostCPUName. Users of getHostCPUName should also use getHostCPUFeatures which will take care of making sure avx512 is disabled if the CPU doesn't support it. This is consistent with what we do for other CPUs. llvm-svn: 307495
* [Solaris] get rid of _RESTRICT_KYWD warning during the buildKamil Rytarowski2017-07-081-3/+0
| | | | | | | | | | | | | | | | | | Summary: (re)definition of _RESTRICT_KYWD rightfully causes a warning message during the Solaris build. This hack is not needed if build compiler is properly configured (.e.g /usr/bin/gcc) so just remove it. Reviewers: ro, mgorny, krytarowski, joerg Reviewed By: joerg Subscribers: quenelle, llvm-commits Patch by Fedor Sergeev (Oracle). Differential Revision: https://reviews.llvm.org/D35054 llvm-svn: 307469
* [X86] In getHostCPUName, remove some code that changes some AMD CPU names ↵Craig Topper2017-07-081-15/+1
| | | | | | | | | | | | based on features not being enabled. The CPU name is really just used for scheduler and other microarchitectural optimizations. The feature flags should be determined by getHostCPUFeatures which should always be used with getHostCPUName. Trying to alter CPU name strings to control features just isn't practical. Most of these types of things were removed from Intel CPUs a while ago. This is part of my plan to bring compiler-rt's cpu_model.c file up to date with the equivalent functionality in libgcc. A lot of the code in that file is copied from Host.cpp and we want to keep them reasonably in sync. llvm-svn: 307467
* [X86] Correct the BDVER4 model numbers to include 0x70-0x7f.Craig Topper2017-07-081-1/+1
| | | | | | According to wikipedia and some other googling suggests these should also be considered as BDVER4. llvm-svn: 307466
* [X86] Minor formatting fix. NFCCraig Topper2017-07-081-4/+2
| | | | llvm-svn: 307465
* [X86] Use 'unsigned' instead of 'unsigned int' for consistency in the X86 ↵Craig Topper2017-07-081-7/+7
| | | | | | portion of Host.cpp. llvm-svn: 307463
* [X86] Cleanup some CPUID usage in getAvailableFeatures.Craig Topper2017-07-081-5/+10
| | | | | | We should make sure leaf 1 is available before accessing it. Same with leaf 0x80000001. llvm-svn: 307462
* Update the Windows version of updateTripleOSVersion to account forAlex Lorenz2017-07-071-2/+2
| | | | | | changes in r307372 llvm-svn: 307377
* [Support] sys::getProcessTriple should return a macOS triple usingAlex Lorenz2017-07-073-7/+25
| | | | | | | | | | | | | | | the system's version of macOS sys::getProcessTriple returns LLVM_HOST_TRIPLE, whose system version might not be the actual version of the system on which the compiler running. This commit ensures that, for macOS, sys::getProcessTriple returns a triple with the system's macOS version. rdar://33177551 Differential Revision: https://reviews.llvm.org/D34446 llvm-svn: 307372
* Fix ODR violations due to abuse of LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTORRichard Smith2017-06-301-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | This is a short-term fix for PR33650 aimed to get the modules build bots green again. Remove all the places where we use the LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTOR macros to try to locally specialize a global template for a global type. That's not how C++ works. Instead, we now centrally define how to format vectors of fundamental types and of string (std::string and StringRef). We use flow formatting for the former cases, since that's the obvious right thing to do; in the latter case, it's less clear what the right choice is, but flow formatting is really bad for some cases (due to very long strings), so we pick block formatting. (Many of the cases that were using flow formatting for strings are improved by this change.) Other than the flow -> block formatting change for some vectors of strings, this should result in no functionality change. Differential Revision: https://reviews.llvm.org/D34907 Corresponding updates to clang, clang-tools-extra, and lld to follow. llvm-svn: 306878
* Unified logic for computing target ABI in backend and front end by moving ↵Eric Christopher2017-06-301-0/+36
| | | | | | | | | | this common code to Support/TargetParser. Modeled Triple::GNU after front end code (aapcs abi) and updated tests that expect apcs abi. Based heavily on a patch by Ana Pazos! llvm-svn: 306768
* Recommit "[Support] Add RetryAfterSignal helper function"Pavel Labath2017-06-293-25/+12
| | | | | | | | | | | | | | | | | | | | | | | | | The difference from the previous version is the use of decltype, as the implementation of std::result_of in libc++ did not work correctly for variadic function like open(2). Original summary: This function retries an operation if it was interrupted by a signal (failed with EINTR). It's inspired by the TEMP_FAILURE_RETRY macro in glibc, but I've turned that into a template function. I've also added a fail-value argument, to enable the function to be used with e.g. fopen(3), which is documented to fail for any reason that open(2) can fail (which includes EINTR). The main user of this function will be lldb, but there were also a couple of uses within llvm that I could simplify using this function. Reviewers: zturner, silvas, joerg Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D33895 llvm-svn: 306671
* [LLVM][X86][Goldmont] Adding new target-cpu: GoldmontMichael Zuckerman2017-06-291-1/+9
| | | | | | | | | | | | | | | | [LLVM SIDE] Connecting the GoldMont processor to his feature. Reviewers: 1. igorb 2. zvi 3. delena 4. RKSimon 5. craig.topper Differential Revision: https://reviews.llvm.org/D34504 llvm-svn: 306658
* Add support for Ananas platformEd Schouten2017-06-251-0/+2
| | | | | | | | | | | | | | | | | Ananas is a home-brew operating system, mainly for amd64 machines. After using GCC for quite some time, it has switched to clang and never looked back - yet, having to manually patch things is annoying, so it'd be much nicer if this was in the official tree. More information: https://github.com/zhmu/ananas/ https://rink.nu/projects/ananas.html Submitted by: Rink Springer Differential Revision: https://reviews.llvm.org/D32937 llvm-svn: 306237
* [APInt] Move the single word cases of countTrailingZeros and ↵Craig Topper2017-06-231-7/+2
| | | | | | countLeadingOnes inline for consistency with countTrailingOnes and countLeadingZeros. NFCI llvm-svn: 306153
* Fix a misleading indentation warning.Peter Collingbourne2017-06-231-3/+3
| | | | llvm-svn: 306130
* Make the size specification for cache_size_bytes case insensitive.Peter Collingbourne2017-06-231-1/+1
| | | | llvm-svn: 306129
* Add a ThinLTO cache policy for controlling the maximum cache size in bytes.Peter Collingbourne2017-06-231-15/+46
| | | | | | | | | | | | | | This is useful when an upper limit on the cache size needs to be controlled independently of the amount of the amount of free space. One use case is a machine with a large number of cache directories (e.g. a buildbot slave hosting a large number of independent build jobs). By imposing an upper size limit on each cache directory, users can more easily estimate the server's capacity. Differential Revision: https://reviews.llvm.org/D34547 llvm-svn: 306126
* Add a BinarySubstreamRef, and a method to read one.Zachary Turner2017-06-231-0/+6
| | | | | | | | | This is essentially just a BinaryStreamRef packaged with an offset and the logic for reading one is no different than the logic for reading a BinaryStreamRef, except that we save the current offset. llvm-svn: 306122
* [ADT] Add llvm::to_floatPavel Labath2017-06-232-19/+11
| | | | | | | | | | | | | | | | | | Summary: The function matches the interface of llvm::to_integer, but as we are calling out to a C library function, I let it take a Twine argument, so we can avoid a string copy at least in some cases. I add a test and replace a couple of existing uses of strtod with this function. Reviewers: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34518 llvm-svn: 306096
* Revert "[Support] Add RetryAfterSignal helper function" and subsequent fixPavel Labath2017-06-223-12/+25
| | | | | | | | | | | The fix in r306003 uncovered a pretty fundamental problem that libc++ implementation of std::result_of does not handle the prototype of open(2) correctly (presumably because it contains ...). This makes the whole function unusable in its current form, so I am also reverting the original commit (r305892), which introduced the function, at least until I figure out a way to solve the libc++ issue. llvm-svn: 306005
* [ProfileData, Support] Fix some Clang-tidy modernize-use-using and Include ↵Eugene Zelenko2017-06-213-37/+71
| | | | | | What You Use warnings; other minor fixes (NFC). llvm-svn: 305969
* [DWARF] Support for DW_FORM_strx3 and complete support for DW_FORM_strx{1,2,4}Wolfgang Pieb2017-06-211-0/+7
| | | | | | | | | | (consumer). Reviewer: aprantl Differential Revision: https://reviews.llvm.org/D34418 llvm-svn: 305944
* [Support] Add RetryAfterSignal helper functionPavel Labath2017-06-213-25/+12
| | | | | | | | | | | | | | | | | | | | | Summary: This function retries an operation if it was interrupted by a signal (failed with EINTR). It's inspired by the TEMP_FAILURE_RETRY macro in glibc, but I've turned that into a template function. I've also added a fail-value argument, to enable the function to be used with e.g. fopen(3), which is documented to fail for any reason that open(2) can fail (which includes EINTR). The main user of this function will be lldb, but there were also a couple of uses within llvm that I could simplify using this function. Reviewers: zturner, silvas, joerg Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D33895 llvm-svn: 305892
* Support: chunk writing on LinuxSaleem Abdulrasool2017-06-202-1/+16
| | | | | | | | This is a workaround for large file writes. It has been witnessed that write(2) failing with EINVAL (22) due to a large value (>2G). Thanks to James Knight for the help with coming up with a sane test case. llvm-svn: 305846
* [APFloat] Move the integerPartWidth constant into APFloatBase. Remove ↵Craig Topper2017-06-181-37/+30
| | | | | | integerPart typedef at file scope and just use the one in APFloatBase everywhere. NFC llvm-svn: 305652
* Implement AllocateRWX and ReleaseRWX for NetBSDKamil Rytarowski2017-06-181-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: NetBSD ships with PaX MPROTECT disallowing RWX mappings. There is a solution to bypass this restriction with double mapping RX (code) and RW (data) using mremap(2) MAP_REMAPDUP. The initial mapping must be mmap(2)ed with protection: PROT_MPROTECT(PROT_EXEC). This functionality to bypass PaX MPROTECT appeared in NetBSD-7.99.72. This patch fixes 20 failing tests: - LLVM :: DebugInfo/debuglineinfo-macho.test - LLVM :: DebugInfo/debuglineinfo.test - LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_Mips64r2N64_PIC_relocations.s - LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_N32_relocations.s - LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_N64R6_relocations.s - LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_O32R6_relocations.s - LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_O32_PIC_relocations.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/COFF_i386.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/COFF_x86_64.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF-relaxed.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_STT_FILE.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x64-64_PC8_relocations.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x64-64_PIC_relocations.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x86-64_PIC-small-relocations.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x86-64_debug_frame.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x86_64_StubBuf.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/MachO_empty_ehframe.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/MachO_i386_DynNoPIC_relocations.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/MachO_i386_eh_frame.s - LLVM :: ExecutionEngine/RuntimeDyld/X86/MachO_x86-64_PIC_relocations.s Sponsored by <The NetBSD Foundation> Reviewers: joerg, lhames Reviewed By: joerg Subscribers: sdardis, llvm-commits, arichardson Differential Revision: https://reviews.llvm.org/D33874 llvm-svn: 305650
* [CMake] Introduce LLVM_TARGET_TRIPLE_ENV as an option to override ↵NAKAMURA Takumi2017-06-172-1/+15
| | | | | | | | | | | | | | | | | | | LLVM_DEFAULT_TARGET_TRIPLE at runtime. No behavior is changed if LLVM_TARGET_TRIPLE_ENV is blank or undefined. If LLVM_TARGET_TRIPLE_ENV is "TEST_TARGET_TRIPLE" and $TEST_TARGET_TRIPLE is not blank, llvm::sys::getDefaultTargetTriple() returns $TEST_TARGET_TRIPLE. Lit resets config.target_triple and config.environment[LLVM_TARGET_TRIPLE_ENV] to change the default target. Without changing LLVM_DEFAULT_TARGET_TRIPLE nor rebuilding, lit can be run; TEST_TARGET_TRIPLE=i686-pc-win32 bin/llvm-lit -sv path/to/test/ TEST_TARGET_TRIPLE=i686-pc-win32 ninja check-clang-tools Differential Revision: https://reviews.llvm.org/D33662 llvm-svn: 305632
* Fix buildbots.Rui Ueyama2017-06-161-1/+2
| | | | llvm-svn: 305542
* Fix msan buildbot.Rui Ueyama2017-06-161-1/+2
| | | | | | | | | | | This patch should fix sanitizer-x86_64-linux-fast bot. The problem was that the contents of this stream are aligned to 4 byte, and the paddings were created just by incrementing `Offset`, so paddings had undefined values. When the entire stream is written to an output, it triggered msan. llvm-svn: 305541
* Hide dbgs() stream for when built with -fmodules.Frederich Munch2017-06-141-1/+5
| | | | | | | | | | | | | | Summary: Make DebugCounter::print and dump methods to be const correct. Reviewers: aprantl Reviewed By: aprantl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D34214 llvm-svn: 305408
* Support: Remove MSVC 2013 workarounds in ThreadPool class.Peter Collingbourne2017-06-141-16/+3
| | | | | | | | I have confirmed that these are no longer needed with MSVC 2015. Differential Revision: https://reviews.llvm.org/D34187 llvm-svn: 305347
* Support: Don't set RLIMIT_AS on child processes when applying a memory limitDavid Blaikie2017-06-121-10/+0
| | | | | | | | | | | | | | | | | | | | | | It doesn't seem relevant to set an address space limit - this isn't important in any sense that I'm aware & it gets in the way of things that use a lot of address space, like llvm-symbolizer. This came up when I realized that bugpoint regression tests were much slower with -gsplit-dwarf than plain -g. Turned out that bugpoint subprocesses (opt, etc) were crashing and doing symbolization - but bugpoint runs those subprocesses with a 400MB memory limit. So with plain -g, mmaping the opt binary would exceed the memory limit, fail, and thus be really fast - no symbolization occurred. Whereas with -gsplit-dwarf, comically, having less to map in, it would succeed and then spend lots of time symbolizing. I've fixed at least the critical part of bugpoint's perf problem there by adding an option to allow bugpoint to disable symbolization. Thus improving the perfromance for -gsplit-dwarf and making the -g-esque speed available without this quirk/accidental benefit. llvm-svn: 305242
* [ADT] Reduce duplication between {Contextual,}FoldingSet; NFCGeorge Burgess IV2017-06-121-21/+21
| | | | | | | | | | | | | This is a precursor to another change (coming soon) that aims to make FoldingSet's API more type-safe. Without this, the type-safety change would just duplicate 4 more public methods between the already very similar classes. This renames FoldingSetImpl to FoldingSetBase so it's consistent with the FooBase -> FooImpl<T> -> Foo<T> convention we seem to have with other containers. llvm-svn: 305231
* bugpoint: disabling symbolication of bugpoint-executed programsDavid Blaikie2017-06-091-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Initial implementation - needs similar work/testing for other tools bugpoint invokes (llc, lli I think, maybe more). Alternatively (as suggested by chandlerc@) an environment variable could be used. This would allow the option to pass transparently through user scripts, pass to compilers if they happened to be LLVM-ish, etc. I worry a bit about using cl::opt in the crash handling code - LLVM might crash early, perhaps before the cl::opt is properly initialized? Or at least before arguments have been parsed? - should be OK since it defaults to "pretty", so if the crash is very early in opt parsing, etc, then crash reports will still be symbolized. I shyed away from doing this with an environment variable when I realized that would require copying the existing environment and appending the env variable of interest. But it seems there's no existing LLVM API for accessing the environment (even the Support tests for process launching have their own ifdefs for getting the environment). It could be added, but seemed like a higher bar/untested codepath to actually add environment variables. Most importantly, this reduces the runtime of test/BugPoint/metadata.ll in a split-dwarf Debug build from 1m34s to 6.5s by avoiding a lot of symbolication. (this wasn't a problem for non-split-dwarf builds only because the executable was too large to map into memory (due to bugpoint setting a 400MB memory (including address space - not sure why? Going to remove that) limit on the child process) so symbolication would fail fast & wouldn't spend all that time parsing DWARF, etc) Reviewers: chandlerc, dannyb Differential Revision: https://reviews.llvm.org/D33804 llvm-svn: 305056
* [Linker] Remove warning when linking ARM and Thumb IR modules.Florian Hahn2017-06-071-0/+15
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch updates Triple::isCompatibleWith to make armxx and thumbxx triples compatible, as long as the subarch, vendor, os, envorionment and object format match. Thumb/ARM code generation should be controlled using the thumb-mode per-function target feature rather than by the triple to allow mixing Thumb and ARM functions. D33448 updates Clang's codegen to add thumb-mode for all functions with armxx or thumbxx triples. Reviewers: echristo, t.p.northover, rafael, kristof.beyls, rengolin, tejohnson Reviewed By: tejohnson Subscribers: rinon, eugenis, pcc, srhines, aemerson, mehdi_amini, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D33287 llvm-svn: 304884
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-073-716/+2
| | | | | | | | | | | | This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
* Allow VersionPrinter to print to arbitrary raw_ostreamsDimitry Andric2017-06-062-12/+9
| | | | | | | | | | | | | | | | | | | | | | | | Summary: I would like to add printing of registered targets to clang's version information. For this to work correctly, the VersionPrinter logic in CommandLine.cpp should support printing to arbitrary raw_ostreams, instead of always defaulting to outs(). Add a raw_ostream& parameter to the function pointer type used for VersionPrinter, and while doing so, introduce a typedef for convenience. Note that VersionPrinter::print() will still default to using outs(), the clang part will necessarily go into a separate review. Reviewers: beanz, chandlerc, dberris, mehdi_amini, zturner Reviewed By: mehdi_amini Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33899 llvm-svn: 304835
* AMDGPU/NFC: Move amdgpu code object metadata to supportKonstantin Zhuravlyov2017-06-062-0/+219
| | | | | | Differential Revision: https://reviews.llvm.org/D31437 llvm-svn: 304812
* Fix another ordering constraint with windows.h and comment aboutChandler Carruth2017-06-061-0/+2
| | | | | | a revers constraint that we got right (by chance). llvm-svn: 304792
* Fix one place where I missed a commented requirement for a particularChandler Carruth2017-06-061-1/+3
| | | | | | | | | include ordering. I've changed the structure so that clang-format will preserve this going forward. llvm-svn: 304788
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-0628-36/+33
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* Close DynamicLibraries in reverse order they were opened.Frederich Munch2017-06-052-2/+3
| | | | | | | | | | | | | | Summary: Matches C++ destruction ordering better and fixes possible problems of loaded libraries having inter-dependencies. Reviewers: efriedma, v.g.vassilev, chapuni Reviewed By: efriedma Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D33652 llvm-svn: 304720
* Fix building DynamicLibrary.cpp with musl libcDimitry Andric2017-06-051-2/+2
| | | | | | | | | | | | | | | | | | | | | Summary: The workaround added in rL301240 for stderr/out/in symbols being both macros and globals is only necessary for glibc, and it does not compile with musl libc. Alpine Linux has had the following fix for it: https://git.alpinelinux.org/cgit/aports/plain/main/llvm4/llvm-fix-DynamicLibrary-to-build-with-musl-libc.patch Adapt the fix in our DynamicLibrary.inc for Unix. Reviewers: marsupial, chandlerc, krytarowski Reviewed By: krytarowski Subscribers: srhines, krytarowski, llvm-commits Differential Revision: https://reviews.llvm.org/D33883 llvm-svn: 304707
* ADT: handle special case of ARM environment for SUSESaleem Abdulrasool2017-06-031-0/+4
| | | | | | | SUSE treats "gnueabi" as "gnueabihf" so make sure that we normalise the environment. llvm-svn: 304670
* Revert r304117 - WebAssembly object format isn't ready to be the defaultJacob Gravelle2017-06-021-4/+2
| | | | | | | | | | | | Summary: Wasm object format has some functionality regressions from the ELF format, and doesn't play nicely with the rest of the toolchain. It should eventually be the default, but not yet. Reviewers: sunfish, sbc100 Subscribers: jfb, dschuff, llvm-commits Differential Revision: https://reviews.llvm.org/D33811 llvm-svn: 304512
* [Solaris] Fix PR33228 - llvm::sys::fs::is_local_impl done rightKamil Rytarowski2017-06-011-0/+5
| | | | | | | | | | | | | | | | | | Summary: Solaris-specific implementation for llvm::sys::fs::is_local_impl. FStype pattern matching might be a bit unreliable, but at least it fixes the build failure. Reviewers: mgorny, nlopes, llvm-commits, krytarowski Reviewed By: krytarowski Subscribers: voskresensky.vladimir, krytarowski Differential Revision: https://reviews.llvm.org/D33695 llvm-svn: 304412
* Adding parsing ability for .res file.Eric Beckmann2017-05-301-0/+20
| | | | | | | | Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33566 llvm-svn: 304225
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-05-301-0/+2
| | | | llvm-svn: 304187
OpenPOWER on IntegriCloud