Merge 2020-08-31 into swift/tensorflow #1733
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently ConstantExpr::getWithOperands does not handle FNeg and subsequently treats FNeg as binary operator, leading to an assertion failure or segmentation fault if built without assertions. Originally I reproduced this with llvm-dis on a bitcode file, which I unfortunately cannot share and also cannot really reduce. But PR45426 describes the same issue and has a reproducer with Clang, so I'll go with that. Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D86274 (Cherry-picked from bc72a3a)
The MSVC toolchain implemented a resolution to DR1734, which results in `llvm::is_trivially_copyable` to not match with `std::is_trivially_copyable`. This is the minimal change that will match the ABI and allow building LLVM with a newer MSVC toolchain.
Support: add workaround for newer MSVC toolchains
…ting Fix GetTypeInfo for changes to decodeMangledType in Swift.
This reverts commit 7fb8148.
The ModuleManager's use of FileEntry nodes as the keys for its map of loaded modules is less than ideal. Uniqueness for FileEntry nodes is maintained by FileManager, which in turn uses inode numbers on hosts that support that. When coupled with the module cache's proclivity for turning over and deleting stale PCMs, this means entries for different module files can wind up reusing the same underlying inode. When this happens, subsequent accesses to the Modules map will disagree on the ModuleFile associated with a given file. In general, it is not sufficient to resolve this conundrum with a type like FileEntryRef that stores the name of the FileEntry node on first access because of path canonicalization issues. However, the paths constructed for implicit module builds are fully under Clang's control. We *can*, therefore, rely on their structure being consistent across operating systems and across subsequent accesses to the Modules map. To mitigate the effects of inode reuse, perform an extra name check when implicit modules are returned from the cache. This has the effect of forcing reused FileEntry nodes to stomp over existing-but-stale entries in the cache, which simulates a miss - exactly the desired behavior. rdar://48443680
Perform an Extra Consistency Check When Searching The ModuleManager's Cache For Implicit Modules
dan-zheng
approved these changes
Sep 2, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Weekly merge of latest changes to tensorflow branch.