merge latest changes from clang (master branch) #27
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
…_rsqrt_ss. We don't need the insertion back into the original vector at the end. The builtin already understands that. This is different than _mm_sqrt_sd which takes two arguments and we do need to insert. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333572 91177308-0d34-0410-b5e6-96231b3b80d8
For example, given: enum __attribute__((deprecated)) T *p; -ast-print produced: enum T *p; The attribute was lost because the enum forward decl was lost. Another example is the loss of enum forward decls from C++ namespaces (in MS compatibility mode). The trouble was that the EnumDecl node was suppressed, as revealed by -ast-dump. The suppression of the EnumDecl was intentional in r116122, but I don't understand why. The suppression isn't needed for the test suite to behave. Reviewed by: rsmith Differential Revision: https://reviews.llvm.org/D46846 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333574 91177308-0d34-0410-b5e6-96231b3b80d8
…to indicate support for P0620R0. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333587 91177308-0d34-0410-b5e6-96231b3b80d8
…don't forget to push it into the class scope. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333589 91177308-0d34-0410-b5e6-96231b3b80d8
… that fail if you run it through -pedantic -ansi. All of these are lines that create a 'compound literal' to concatenate elements together. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333593 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333594 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333598 91177308-0d34-0410-b5e6-96231b3b80d8
…its template. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333599 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333600 91177308-0d34-0410-b5e6-96231b3b80d8
"Type metadata" is the term that we've been using for the CFI-related information on vtables for a while now. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333602 91177308-0d34-0410-b5e6-96231b3b80d8
Most of the origial comments used C style /* */ comments, but some C++ // comments had snuck in over time. Still need to convert all the doxygen comments. Which is much harder to do. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333603 91177308-0d34-0410-b5e6-96231b3b80d8
While here, mark three-way comparison as in progress and bump "Clang 6" items from yellow to green. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333606 91177308-0d34-0410-b5e6-96231b3b80d8
Discard the last uncompleted deferred region in a decl, if one exists. This prevents lines at the end of a function containing only whitespace or closing braces from being marked as uncovered, if they follow a region terminator (return/break/etc). The previous behavior was to heuristically complete deferred regions at the end of a decl. In practice this ended up being too brittle for too little gain. Users would complain that there was no way to reach full code coverage because whitespace at the end of a function would be marked uncovered. rdar://40238228 Differential Revision: https://reviews.llvm.org/D46918 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333609 91177308-0d34-0410-b5e6-96231b3b80d8
…bout receiver nullability Previously, the checker was using the nullability of the expression, which is nonnull IFF both receiver and method are annotated as _Nonnull. However, the receiver could be known to the analyzer to be nonnull without being explicitly marked as _Nonnull. rdar://40635584 Differential Revision: https://reviews.llvm.org/D47510 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333612 91177308-0d34-0410-b5e6-96231b3b80d8
I think this is a holdover from when we used to declare variables inside the macros. And then its been copy and pasted forward for years every time a new macro intrinsic gets added. Interestingly this caused some tests for IRGen to be slightly more optimized. We now return a zeroinitializer directly instead of going through a store+load. It also removed a bogus error message on another test. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333613 91177308-0d34-0410-b5e6-96231b3b80d8
…t to _m512(i|d)/_m256(i|d/_m128(i|d) first. The majority of the cases were correct. This fixes the few that weren't. I also removed some superfluous parentheses in non-macros that confused by attempts at grepping for missing casts. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333615 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333617 91177308-0d34-0410-b5e6-96231b3b80d8
…56-bit equivalents. Previously we were just passing -1 mask to the masked builtin. This changes it to the more generic way that the 128/256 bit use. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333626 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: In rL327851 the createUniqueFile() and createTemporaryFile() variants that do not return the file descriptors were changed to create empty files, rather than only check if the paths are free. This change was done in order to make the functions race-free. That change led to clang-tidy (and possibly other tools) leaving behind temporary assembly files, of the form placeholder-*, when using a target that does not support the internal assembler. The temporary files are created when building the Compilation object in stripPositionalArgs(), as a part of creating the compilation database for the arguments after the double-dash. The files are created by Driver::GetNamedOutputPath(). Fix this issue by cleaning out temporary files at the deletion of Compilation objects. This fixes https://bugs.llvm.org/show_bug.cgi?id=37091. Reviewers: klimek, sepavloff, arphaman, aaron.ballman, john.brawn, mehdi_amini, sammccall, bkramer, alexfh, JDevlieghere Reviewed By: aaron.ballman, JDevlieghere Subscribers: erichkeane, lebedev.ri, Ka-Ka, cfe-commits Differential Revision: https://reviews.llvm.org/D45686 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333637 91177308-0d34-0410-b5e6-96231b3b80d8
Add the ability to dump compiler option-related information to a JSON file via the -compiler-options-dump option. Specifically, it dumps the features/extensions lists -- however, this output could be extended to other information should it be useful. In order to support features and extensions, I moved them into a .def file so that we could build the various lists we care about from them without a significant increase in maintenance burden. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333653 91177308-0d34-0410-b5e6-96231b3b80d8
Differential Revision: https://reviews.llvm.org/D45935 Reviewers: compnerd git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333657 91177308-0d34-0410-b5e6-96231b3b80d8
When neither LHS nor RHS of a binary operator expression can be simplified, return the original expression instead of re-evaluating the binary operator. Such re-evaluation was causing recusrive re-simplification which caused the algorithmic complexity to explode. Differential Revision: https://reviews.llvm.org/D47155 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333670 91177308-0d34-0410-b5e6-96231b3b80d8
…urther. Memoize simplification so that we didn't need to simplify the same symbolic expression twice within the same program state. Gives ~25% performance boost on the artificial test in test/Analysis/hangs.c. Differential Revision: https://reviews.llvm.org/D47402 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333671 91177308-0d34-0410-b5e6-96231b3b80d8
…-fthinlto-index. Differential Revision: https://reviews.llvm.org/D47597 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333677 91177308-0d34-0410-b5e6-96231b3b80d8
Because our program states are immutable, methods like "add<>", "set<>", "bind" create a copy of the program state instead of mutating the existing state. If the updated state is discarded, it clearly indicates a bug. Such bugs are introduced frequently, hence the warn_unused_result annotation. Differential Revision: https://reviews.llvm.org/D47499 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333679 91177308-0d34-0410-b5e6-96231b3b80d8
…del() Ensure latest MPT decl has a MSInheritanceAttr when instantiating templates, to avoid null MSInheritanceAttr deref in CXXRecordDecl::getMSInheritanceModel(). See PR#37399 for repo / details. Patch by Andrew Rogers! Differential Revision: https://reviews.llvm.org/D46664 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333680 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Because wasm control flow needs to be structured, using WinEH instructions to support wasm EH brings several benefits. This patch makes wasm EH uses Windows EH instructions, with some changes: 1. Because wasm uses a single catch block to catch all C++ exceptions, this merges all catch clauses into a single catchpad, within which we test the EH selector as in Itanium EH. 2. Generates a call to `__clang_call_terminate` in case a cleanup throws. Wasm does not have a runtime to handle this. 3. In case there is no catch-all clause, inserts a call to `__cxa_rethrow` at the end of a catchpad in order to unwind to an enclosing EH scope. Reviewers: majnemer, dschuff Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits Differential Revision: https://reviews.llvm.org/D44931 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333703 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Clang does not have a corresponding QualType for a 1-bit APSInt, so use the BoolTy and extend the APSInt. Split from D35450. Fixes PR37622. Reviewers: george.karpenkov, NoQ Subscribers: mikhail.ramalho, xazax.hun, szepet, rnkovacs, cfe-commits, a.sidorin Differential Revision: https://reviews.llvm.org/D47603 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333704 91177308-0d34-0410-b5e6-96231b3b80d8
The WebAssembly committee has decided on the names `memory.size` and `memory.grow` for the memory intrinsics, so update the clang builtin functions to follow those names, keeping both sets of old names in place for compatibility. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333712 91177308-0d34-0410-b5e6-96231b3b80d8
A deferred region should end before the start of a label, and should not extend to the start of the label sub-statement. Fixes llvm.org/PR35867. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333715 91177308-0d34-0410-b5e6-96231b3b80d8
…add/fmsub/fmaddsub/fmsubadd builtins. Summary: We recently switch to using a selects in the intrinsics header files for FMA instructions. But the 512-bit versions support flavors with rounding mode which must be an Integer Constant Expression. This has forced those intrinsics to be implemented as macros. As it stands now the mask and mask3 intrinsics evaluate one of their macro arguments twice. If that argument itself is another intrinsic macro, we can end up over expanding macros. Or if its something we can CSE later it would show up multiple times when it shouldn't. I tried adding __extension__ around the macro and making it an expression statement and declaring a local variable. But whatever name you choose for the local variable can never be used as the name of an input to the macro in user code. If that happens you would end up with the same name on the LHS and RHS of an assignment after expansion. We might be safe if we use __ in front of the variable names because those names are reserved and user code shouldn't use that, but I wasn't sure I wanted to make that claim. The other option which I've chosen here, is to add back _mask, _maskz, and _mask3 flavors of the builtin which we will expand in CGBuiltin.cpp to replicate the argument as needed and insert any fneg needed on the third operand to make a subtract. The _maskz isn't truly necessary if we have an unmasked version or if we use the masked version with a -1 mask and wrap a select around it. But I've chosen to make things more uniform. I separated out the scalar builtin handling to avoid too many things going on in EmitX86FMAExpr. It was different enough due to the extract and insert that the minor duplication of the CreateCall was probably worth it. Reviewers: tkrupa, RKSimon, spatel, GBuella Reviewed By: tkrupa Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47724 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334159 91177308-0d34-0410-b5e6-96231b3b80d8
Previous, if no Decl's were checked, visibility was set to false. Switch it so that in cases of no Decl's, return true. These are the Decl's after being filtered. Also remove an unreachable return statement since it is directly after another return statement. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334160 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When requirement imposed by __target__ attributes on functions
are not satisfied, prefer printing those requirements, which
are explicitly mentioned in the attributes.
This makes such messages more useful, e.g. printing avx512f instead of avx2
in the following scenario:
```
$ cat foo.c
static inline void __attribute__((__always_inline__, __target__("avx512f")))
x(void)
{
}
int main(void)
{
x();
}
$ clang foo.c
foo.c:7:2: error: always_inline function 'x' requires target feature 'avx2', but would be inlined into function 'main' that is compiled without support for 'avx2'
x();
^
1 error generated.
```
bugzilla: https://bugs.llvm.org/show_bug.cgi?id=37338
Reviewers: craig.topper, echristo, dblaikie
Reviewed By: craig.topper, echristo
Differential Revision: https://reviews.llvm.org/D46541
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334174 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: We were missing the case when python-style comments in text protos start with `##`. Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47870 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334179 91177308-0d34-0410-b5e6-96231b3b80d8
… intrinsics. We still lower them to native shuffle IR, but we do it in CGBuiltin.cpp now. This allows us to check the target feature and ensure the immediate fits in 8 bits. This also improves our -O0 codegen slightly because we're able to see the zeroinitializer in the shuffle. It looks like it got lost behind a store+load previously. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334208 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Created a new protobuf and protobuf-to-C++ "converter" that wraps the entire C++ code in a single for loop. - Slightly changed cxx_proto.proto -> cxx_loop_proto.proto - Made some changes to proto_to_cxx files to handle the new kind of protobuf - Created ExampleClangLoopProtoFuzzer to test new protobuf and "converter" Patch by Emmett Neyman Reviewers: kcc, vitalybuka, morehouse Reviewed By: vitalybuka, morehouse Subscribers: mgorny, llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D47843 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334216 91177308-0d34-0410-b5e6-96231b3b80d8
This breaks the OpenFlags enumeration into two separate enumerations: OpenFlags and CreationDisposition. The first controls the behavior of the API depending on whether or not the target file already exists, and is not a flags-based enum. The second controls more flags-like values. This yields a more easy to understand API, while also allowing flags to be passed to the openForRead api, where most of the values didn't make sense before. This also makes the apis more testable as it becomes easy to enumerate all the configurations which make sense, so I've added many new tests to exercise all the different values. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334221 91177308-0d34-0410-b5e6-96231b3b80d8
The body of a `@finally` needs to be executed on both exceptional and non-exceptional paths. On landingpad platforms, this is straightforward: the `@finally` body is emitted as a normal (non-exceptional) cleanup, and then a catch-all is emitted which branches to that cleanup (the cleanup has code to conditionally re-throw based on a flag which is set by the catch-all). Unfortunately, we can't use the same approach for MSVC exceptions, where the catch-all will be emitted as a catchpad. We can't just branch to the cleanup from within the catchpad, since we can only exit it via a catchret, at which point the exception is destroyed and we can't rethrow. We could potentially emit the finally body inside the catchpad and have the normal cleanup path somehow branch into it, but that would require some new IR construct that could branch into a catchpad. Instead, after discussing it with Reid Kleckner, we decided that frontend outlining was the best approach, similar to how SEH `__finally` works today. We decided to use CapturedStmt (which was also suggested by Reid) rather than CaptureFinder (which is what `__finally` uses) since the latter doesn't handle a lot of cases we care about, e.g. self accesses, property accesses, block captures, etc. Extending CaptureFinder to handle those additional cases proved unwieldy, whereas CapturedStmt already took care of all of those. In theory `__finally` could also be moved over to CapturedStmt, which would remove some existing limitations (e.g. the inability to capture this), although CaptureFinder would still be needed for SEH filters. The one case supported by `@finally` but not CapturedStmt (or CaptureFinder for that matter) is arbitrary control flow out of the `@finally`, e.g. having a return statement inside a `@finally`. We can add that support as a follow-up, but in practice we've found it to be used very rarely anyway. Differential Revision: https://reviews.llvm.org/D47564 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334224 91177308-0d34-0410-b5e6-96231b3b80d8
…e checking. We still emit shufflevector instructions we just do it from CGBuiltin.cpp now. This ensures the intrinsics that use this are only available on CPUs that support the feature. I also added range checking to the immediate, but only checked it is 8 bits or smaller. We should maybe be stricter since we never use all 8 bits, but gcc doesn't seem to do that. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334237 91177308-0d34-0410-b5e6-96231b3b80d8
Adds support for these intrinsics, which are ARM and ARM64 only: _interlockedbittestandreset_acq _interlockedbittestandreset_rel _interlockedbittestandreset_nf _interlockedbittestandset_acq _interlockedbittestandset_rel _interlockedbittestandset_nf Refactor the bittest intrinsic handling to decompose each intrinsic into its action, its width, and its atomicity. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334239 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r334224. This is causing buildbot failures on Windows, presumably because some tests don't specify a triple. I'll test this on Windows locally and recommit with the tests fixed. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334240 91177308-0d34-0410-b5e6-96231b3b80d8
The windows-msvc target is used for MSVC ABI compatibility, including the exceptions model. It doesn't make sense to pair a windows-msvc target with a non-MSVC exception model. This would previously cause an assertion failure; explicitly error out for it in the frontend instead. This also allows us to reduce the matrix of target/exception models a bit (see the modified tests), and we can possibly simplify some of the personality code in a follow-up. Differential Revision: https://reviews.llvm.org/D47853 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334243 91177308-0d34-0410-b5e6-96231b3b80d8
…ble target feature checking and immediate range checking. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334244 91177308-0d34-0410-b5e6-96231b3b80d8
… feature requirements and check immediate range. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334249 91177308-0d34-0410-b5e6-96231b3b80d8
This reapplies r334224 and adds explicit triples to some tests to fix them on Windows (where otherwise they would have run with the default windows-msvc triple, which I'm changing the behavior for). Original commit message: The body of a `@finally` needs to be executed on both exceptional and non-exceptional paths. On landingpad platforms, this is straightforward: the `@finally` body is emitted as a normal (non-exceptional) cleanup, and then a catch-all is emitted which branches to that cleanup (the cleanup has code to conditionally re-throw based on a flag which is set by the catch-all). Unfortunately, we can't use the same approach for MSVC exceptions, where the catch-all will be emitted as a catchpad. We can't just branch to the cleanup from within the catchpad, since we can only exit it via a catchret, at which point the exception is destroyed and we can't rethrow. We could potentially emit the finally body inside the catchpad and have the normal cleanup path somehow branch into it, but that would require some new IR construct that could branch into a catchpad. Instead, after discussing it with Reid Kleckner, we decided that frontend outlining was the best approach, similar to how SEH `__finally` works today. We decided to use CapturedStmt (which was also suggested by Reid) rather than CaptureFinder (which is what `__finally` uses) since the latter doesn't handle a lot of cases we care about, e.g. self accesses, property accesses, block captures, etc. Extending CaptureFinder to handle those additional cases proved unwieldy, whereas CapturedStmt already took care of all of those. In theory `__finally` could also be moved over to CapturedStmt, which would remove some existing limitations (e.g. the inability to capture this), although CaptureFinder would still be needed for SEH filters. The one case supported by `@finally` but not CapturedStmt (or CaptureFinder for that matter) is arbitrary control flow out of the `@finally`, e.g. having a return statement inside a `@finally`. We can add that support as a follow-up, but in practice we've found it to be used very rarely anyway. Differential Revision: https://reviews.llvm.org/D47564 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334251 91177308-0d34-0410-b5e6-96231b3b80d8
Edited loop_proto and its converter to make more "vectorizable" code according to kcc's comment in D47666 - Removed all while loops - Can only index into array with induction variable Patch By: emmettneyman Differential Revision: https://reviews.llvm.org/D47920 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334252 91177308-0d34-0410-b5e6-96231b3b80d8
The windows-msvc target is meant to be ABI compatible with MSVC, including the exception handling. Ensure that a windows-msvc triple always equates to the MSVC personality being used. This mostly affects the GNUStep and ObjFW Obj-C runtimes. To the best of my knowledge, those are normally not used with windows-msvc triples. I believe WinObjC is based on GNUStep (or it at least uses libobjc2), but that also takes the approach of wrapping Obj-C exceptions in C++ exceptions, so the MSVC personality function is the right one to use there as well. Differential Revision: https://reviews.llvm.org/D47862 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334253 91177308-0d34-0410-b5e6-96231b3b80d8
…ture checking. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334256 91177308-0d34-0410-b5e6-96231b3b80d8
…ure checking and immediate range checking. Test changes are due to differences in how we generate undef elements now. We also changed the types used for extractf128_si256/insertf128_si256 to match the signature of the builtin that previously existed which this patch resurrects. This also matches gcc. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334261 91177308-0d34-0410-b5e6-96231b3b80d8
…4261. This was caught by the Header tests, but not the CodeGen tests. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334264 91177308-0d34-0410-b5e6-96231b3b80d8
…feature and immediate range checking. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334265 91177308-0d34-0410-b5e6-96231b3b80d8
… immediate range checking. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334266 91177308-0d34-0410-b5e6-96231b3b80d8
CGM.GetAddrOfConstantCString() sets the adress of the created GlobalValue to unnamed. When emitting the object file LLVM will mark the surrounding section as SHF_MERGE iff the string is nul-terminated and contains no other nuls (see IsNullTerminatedString). This results in problems when saving temporaries because LLVM doesn't set an EntrySize, so reading in the serialized assembly file fails. This never happened for the GPU binaries because they usually contain a nul-character somewhere. Instead this only affected the module ID when compiling relocatable device code. However, this points to a potentially larger problem: If we put a constant string into a named section, we really want the data to end up in that section in the object file. To avoid LLVM merging sections this patch unmarks the GlobalVariable's address as unnamed which also fixes the problem of invalid serialized assembly files when saving temporaries. Differential Revision: https://reviews.llvm.org/D47902 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334281 91177308-0d34-0410-b5e6-96231b3b80d8
These builtins are all handled by CGBuiltin.cpp so it doesn't much matter what the immediate type is, but int matches the intrinsic spec. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334310 91177308-0d34-0410-b5e6-96231b3b80d8
…eature checking. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334311 91177308-0d34-0410-b5e6-96231b3b80d8
schweitzpgi
pushed a commit
to schweitzpgi/obsolete-flang-driver
that referenced
this pull request
Apr 22, 2019
The assertion prevents it from applying fixes when used along with compilation
databases with relative paths. Added a test that demonstrates the assertion
failure.
An example of the assertion:
input.cpp:11:14: error: expected ';' after top level declarator
typedef int T
^
;
input.cpp:11:14: note: FIX-IT applied suggested code changes
clang-check: clang/tools/clang-check/ClangCheck.cpp:94: virtual std::string (anonymous namespace)::FixItOptions::RewriteFilename(const std::string &, int &): Assertion `llvm::sys::path::is_absolute(filename) && "clang-fixit expects absolute paths only."' failed.
#0 llvm::sys::PrintStackTrace(llvm::raw_ostream&) llvm/lib/Support/Unix/Signals.inc:494:13
flang-compiler#1 llvm::sys::RunSignalHandlers() llvm/lib/Support/Signals.cpp:69:18
flang-compiler#2 SignalHandler(int) llvm/lib/Support/Unix/Signals.inc:357:1
flang-compiler#3 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0)
flang-compiler#4 raise (/lib/x86_64-linux-gnu/libc.so.6+0x32fcf)
flang-compiler#5 abort (/lib/x86_64-linux-gnu/libc.so.6+0x343fa)
flang-compiler#6 (/lib/x86_64-linux-gnu/libc.so.6+0x2be37)
flang-compiler#7 (/lib/x86_64-linux-gnu/libc.so.6+0x2bee2)
flang-compiler#8 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag)
flang-compiler#9 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char*>(char*, char*, std::__false_type)
flang-compiler#10 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*)
flang-compiler#11 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
flang-compiler#12 (anonymous namespace)::FixItOptions::RewriteFilename(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int&) clang/tools/clang-check/ClangCheck.cpp:101:0
flang-compiler#13 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_data() const
flang-compiler#14 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_is_local() const
flang-compiler#15 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose()
flang-compiler#16 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
flang-compiler#17 clang::FixItRewriter::WriteFixedFiles(std::vector<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >*) clang/lib/Frontend/Rewrite/FixItRewriter.cpp:98:0
flang-compiler#18 std::__shared_ptr<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2>::get() const
flang-compiler#19 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::_M_get() const
flang-compiler#20 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::operator->() const
flang-compiler#21 clang::CompilerInstance::getFrontendOpts() clang/include/clang/Frontend/CompilerInstance.h:290:0
flang-compiler#22 clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:966:0
flang-compiler#23 __gnu_cxx::__normal_iterator<clang::FrontendInputFile*, std::vector<clang::FrontendInputFile, std::allocator<clang::FrontendInputFile> > >::operator++()
flang-compiler#24 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:943:0
flang-compiler#25 clang::tooling::FrontendActionFactory::runInvocation(std::shared_ptr<clang::CompilerInvocation>, clang::FileManager*, std::shared_ptr<clang::PCHContainerOperations>, clang::DiagnosticConsumer*) clang/lib/Tooling/Tooling.cpp:369:33
flang-compiler#26 clang::tooling::ToolInvocation::runInvocation(char const*, clang::driver::Compilation*, std::shared_ptr<clang::CompilerInvocation>, std::shared_ptr<clang::PCHContainerOperations>) clang/lib/Tooling/Tooling.cpp:344:18
flang-compiler#27 clang::tooling::ToolInvocation::run() clang/lib/Tooling/Tooling.cpp:329:10
flang-compiler#28 clang::tooling::ClangTool::run(clang::tooling::ToolAction*) clang/lib/Tooling/Tooling.cpp:518:11
flang-compiler#29 main clang/tools/clang-check/ClangCheck.cpp:187:15
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@357915 91177308-0d34-0410-b5e6-96231b3b80d8
schweitzpgi
pushed a commit
to schweitzpgi/obsolete-flang-driver
that referenced
this pull request
Apr 22, 2019
…heck.
The assertion prevents it from applying fixes when used along with compilation
databases with relative paths. Added a test that demonstrates the assertion
failure.
An example of the assertion:
input.cpp:11:14: error: expected ';' after top level declarator
typedef int T
^
;
input.cpp:11:14: note: FIX-IT applied suggested code changes
clang-check: clang/tools/clang-check/ClangCheck.cpp:94: virtual std::string (anonymous namespace)::FixItOptions::RewriteFilename(const std::string &, int &): Assertion `llvm::sys::path::is_absolute(filename) && "clang-fixit expects absolute paths only."' failed.
#0 llvm::sys::PrintStackTrace(llvm::raw_ostream&) llvm/lib/Support/Unix/Signals.inc:494:13
flang-compiler#1 llvm::sys::RunSignalHandlers() llvm/lib/Support/Signals.cpp:69:18
flang-compiler#2 SignalHandler(int) llvm/lib/Support/Unix/Signals.inc:357:1
flang-compiler#3 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0)
flang-compiler#4 raise (/lib/x86_64-linux-gnu/libc.so.6+0x32fcf)
flang-compiler#5 abort (/lib/x86_64-linux-gnu/libc.so.6+0x343fa)
flang-compiler#6 (/lib/x86_64-linux-gnu/libc.so.6+0x2be37)
flang-compiler#7 (/lib/x86_64-linux-gnu/libc.so.6+0x2bee2)
flang-compiler#8 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag)
flang-compiler#9 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char*>(char*, char*, std::__false_type)
flang-compiler#10 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*)
flang-compiler#11 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
flang-compiler#12 (anonymous namespace)::FixItOptions::RewriteFilename(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int&) clang/tools/clang-check/ClangCheck.cpp:101:0
flang-compiler#13 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_data() const
flang-compiler#14 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_is_local() const
flang-compiler#15 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose()
flang-compiler#16 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
flang-compiler#17 clang::FixItRewriter::WriteFixedFiles(std::vector<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >*) clang/lib/Frontend/Rewrite/FixItRewriter.cpp:98:0
flang-compiler#18 std::__shared_ptr<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2>::get() const
flang-compiler#19 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::_M_get() const
flang-compiler#20 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::operator->() const
flang-compiler#21 clang::CompilerInstance::getFrontendOpts() clang/include/clang/Frontend/CompilerInstance.h:290:0
flang-compiler#22 clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:966:0
flang-compiler#23 __gnu_cxx::__normal_iterator<clang::FrontendInputFile*, std::vector<clang::FrontendInputFile, std::allocator<clang::FrontendInputFile> > >::operator++()
flang-compiler#24 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:943:0
flang-compiler#25 clang::tooling::FrontendActionFactory::runInvocation(std::shared_ptr<clang::CompilerInvocation>, clang::FileManager*, std::shared_ptr<clang::PCHContainerOperations>, clang::DiagnosticConsumer*) clang/lib/Tooling/Tooling.cpp:369:33
flang-compiler#26 clang::tooling::ToolInvocation::runInvocation(char const*, clang::driver::Compilation*, std::shared_ptr<clang::CompilerInvocation>, std::shared_ptr<clang::PCHContainerOperations>) clang/lib/Tooling/Tooling.cpp:344:18
flang-compiler#27 clang::tooling::ToolInvocation::run() clang/lib/Tooling/Tooling.cpp:329:10
flang-compiler#28 clang::tooling::ClangTool::run(clang::tooling::ToolAction*) clang/lib/Tooling/Tooling.cpp:518:11
flang-compiler#29 main clang/tools/clang-check/ClangCheck.cpp:187:15
........
Breaks windows buildbots
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@357918 91177308-0d34-0410-b5e6-96231b3b80d8
schweitzpgi
pushed a commit
to schweitzpgi/obsolete-flang-driver
that referenced
this pull request
Apr 22, 2019
Re-commit r357915 with a fix for windows.
The assertion prevents it from applying fixes when used along with compilation
databases with relative paths. Added a test that demonstrates the assertion
failure.
An example of the assertion:
input.cpp:11:14: error: expected ';' after top level declarator
typedef int T
^
;
input.cpp:11:14: note: FIX-IT applied suggested code changes
clang-check: clang/tools/clang-check/ClangCheck.cpp:94: virtual std::string (anonymous namespace)::FixItOptions::RewriteFilename(const std::string &, int &): Assertion `llvm::sys::path::is_absolute(filename) && "clang-fixit expects absolute paths only."' failed.
#0 llvm::sys::PrintStackTrace(llvm::raw_ostream&) llvm/lib/Support/Unix/Signals.inc:494:13
flang-compiler#1 llvm::sys::RunSignalHandlers() llvm/lib/Support/Signals.cpp:69:18
flang-compiler#2 SignalHandler(int) llvm/lib/Support/Unix/Signals.inc:357:1
flang-compiler#3 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0)
flang-compiler#4 raise (/lib/x86_64-linux-gnu/libc.so.6+0x32fcf)
flang-compiler#5 abort (/lib/x86_64-linux-gnu/libc.so.6+0x343fa)
flang-compiler#6 (/lib/x86_64-linux-gnu/libc.so.6+0x2be37)
flang-compiler#7 (/lib/x86_64-linux-gnu/libc.so.6+0x2bee2)
flang-compiler#8 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag)
flang-compiler#9 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char*>(char*, char*, std::__false_type)
flang-compiler#10 void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*)
flang-compiler#11 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
flang-compiler#12 (anonymous namespace)::FixItOptions::RewriteFilename(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int&) clang/tools/clang-check/ClangCheck.cpp:101:0
flang-compiler#13 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_data() const
flang-compiler#14 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_is_local() const
flang-compiler#15 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose()
flang-compiler#16 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
flang-compiler#17 clang::FixItRewriter::WriteFixedFiles(std::vector<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >*) clang/lib/Frontend/Rewrite/FixItRewriter.cpp:98:0
flang-compiler#18 std::__shared_ptr<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2>::get() const
flang-compiler#19 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::_M_get() const
flang-compiler#20 std::__shared_ptr_access<clang::CompilerInvocation, (__gnu_cxx::_Lock_policy)2, false, false>::operator->() const
flang-compiler#21 clang::CompilerInstance::getFrontendOpts() clang/include/clang/Frontend/CompilerInstance.h:290:0
flang-compiler#22 clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:966:0
flang-compiler#23 __gnu_cxx::__normal_iterator<clang::FrontendInputFile*, std::vector<clang::FrontendInputFile, std::allocator<clang::FrontendInputFile> > >::operator++()
flang-compiler#24 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:943:0
flang-compiler#25 clang::tooling::FrontendActionFactory::runInvocation(std::shared_ptr<clang::CompilerInvocation>, clang::FileManager*, std::shared_ptr<clang::PCHContainerOperations>, clang::DiagnosticConsumer*) clang/lib/Tooling/Tooling.cpp:369:33
flang-compiler#26 clang::tooling::ToolInvocation::runInvocation(char const*, clang::driver::Compilation*, std::shared_ptr<clang::CompilerInvocation>, std::shared_ptr<clang::PCHContainerOperations>) clang/lib/Tooling/Tooling.cpp:344:18
flang-compiler#27 clang::tooling::ToolInvocation::run() clang/lib/Tooling/Tooling.cpp:329:10
flang-compiler#28 clang::tooling::ClangTool::run(clang::tooling::ToolAction*) clang/lib/Tooling/Tooling.cpp:518:11
flang-compiler#29 main clang/tools/clang-check/ClangCheck.cpp:187:15
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@357921 91177308-0d34-0410-b5e6-96231b3b80d8
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.
No description provided.