summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGenCXX
Commit message (Collapse)AuthorAgeFilesLines
* Revert r312224: "[ItaniumCXXABI] Always use linkonce_odr linkage for RTTI ↵Martin Storsjo2017-08-311-5/+0
| | | | | | | | | | | | | | data on MinGW" Breaks on buildbot: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/4548/steps/test-check-all/logs/stdio The test in CodeGenCXX/virt-dtor-key.cpp tests using %itanium_abi_triple; on non-windows platforms, this resolves to the current platform triple (where there was no behaviour change), while on windows, it resolves to a mingw triple (where the behaviour was intentionally changed). llvm-svn: 312229
* [ItaniumCXXABI] Always use linkonce_odr linkage for RTTI data on MinGWMartin Storsjo2017-08-311-0/+5
| | | | | | | | | | | | This fixes cases where dynamic classes produced RTTI data with external linkage, producing linker errors about duplicate symbols. This touches code close to what was changed in SVN r244266, but this change doesn't break the tests added in that revision. Differential revision: https://reviews.llvm.org/D37206 llvm-svn: 312224
* Test-case golfing.Adrian Prantl2017-08-301-33/+17
| | | | llvm-svn: 312175
* Adapt testcases to LLVM change r312144 in DIGlobalVariableExpressionAdrian Prantl2017-08-305-9/+9
| | | | llvm-svn: 312148
* [ms] Fix vbtable index for covariant overrides of vbase methodsReid Kleckner2017-08-291-0/+15
| | | | | | | | | | | | | | | Overriding a method from a virtual base with a covariant return type consumes a slot from the vftable in the virtual base. This can make it impossible to implement certain diamond inheritance hierarchies, but we have to follow along for compatibility in the simple cases. This patch only affects our vtable dumper and member pointer function mangling, since all other callers of getMethodVFTableLocation seem to recompute VBTableIndex instead of using the one in the method location. Patch by David Majnemer llvm-svn: 312017
* Revert r311857 "Emit static constexpr member as available_externally definition"Hans Wennborg2017-08-281-55/+0
| | | | | | | | | | | | | It caused PR759744. > Emit static constexpr member as available_externally definition > > By exposing the constant initializer, the optimizer can fold many > of these constructs. > > Differential Revision: https://reviews.llvm.org/D34992 llvm-svn: 311898
* Emit static constexpr member as available_externally definitionMehdi Amini2017-08-271-0/+55
| | | | | | | | | By exposing the constant initializer, the optimizer can fold many of these constructs. Differential Revision: https://reviews.llvm.org/D34992 llvm-svn: 311857
* Add flag to request Clang is ABI-compatible with older versions of itselfRichard Smith2017-08-262-18/+56
| | | | | | | | | | | | | | | | | | This patch adds a flag -fclang-abi-compat that can be used to request that Clang attempts to be ABI-compatible with some older version of itself. This is provided on a best-effort basis; right now, this can be used to undo the ABI change in r310401, reverting Clang to its prior C++ ABI for pass/return by value of class types affected by that change, and to undo the ABI change in r262688, reverting Clang to using integer registers rather than SSE registers for passing <1 x long long> vectors. The intent is that we will maintain this backwards compatibility path as we make ABI-breaking fixes in future. The reversion to the old behavior for r310401 is also applied to the PS4 target since that change is not part of its platform ABI (which is essentially to do whatever Clang 3.2 did). llvm-svn: 311823
* [IRGen] Evaluate constant static variables referenced through memberAlex Lorenz2017-08-251-0/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | expressions C++ allows us to reference static variables through member expressions. Prior to this commit, non-integer static variables that were referenced using a member expression were always emitted using lvalue loads. The old behaviour introduced an inconsistency between regular uses of static variables and member expressions uses. For example, the following program compiled and linked successfully: struct Foo { constexpr static const char *name = "foo"; }; int main() { return Foo::name[0] == 'f'; } but this program failed to link because "Foo::name" wasn't found: struct Foo { constexpr static const char *name = "foo"; }; int main() { Foo f; return f.name[0] == 'f'; } This commit ensures that constant static variables referenced through member expressions are emitted in the same way as ordinary static variable references. rdar://33942261 Differential Revision: https://reviews.llvm.org/D36876 llvm-svn: 311772
* [ubsan] PR34266: When sanitizing the 'this' value for a member function that ↵Richard Smith2017-08-241-0/+36
| | | | | | | | | | | | | happens to be a lambda call operator, use the lambda's 'this' pointer, not the captured enclosing 'this' pointer (if any). Do not sanitize the 'this' pointer of a member call operator for a lambda with no capture-default, since that call operator can legitimately be called with a null this pointer from the static invoker function. Any actual call with a null this pointer should still be caught in the caller (if it is being sanitized). This reinstates r311589 (reverted in r311680) with the above fix. llvm-svn: 311695
* Revert "[ubsan] PR34266: When sanitizing the 'this' value for a member ↵Adrian Prantl2017-08-241-21/+0
| | | | | | | | | function that happens to be a lambda call operator, use the lambda's 'this' pointer, not the captured enclosing 'this' pointer (if any)." This reverts commit r311589 because of bot breakage. http://green.lab.llvm.org/green/job/clang-stage2-cmake-RgSan_check/4115/consoleFull#15752874848254eaf0-7326-4999-85b0-388101f2d404. llvm-svn: 311680
* Fixups to FE tests affected by D36793Coby Tayree2017-08-241-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D36794 llvm-svn: 311640
* Fix mangling for dependent "type { expr-list }" expressions, and add ↵Richard Smith2017-08-232-6/+32
| | | | | | mangling for designated initializers matching recent cxx-abi-dev discussion. llvm-svn: 311612
* Fix a bug in CGDebugInfo::EmitInlineFunctionStart causing DILocations to beAdrian Prantl2017-08-231-0/+45
| | | | | | | | | parented in function declarations. Fixes PR33997. https://bugs.llvm.org/show_bug.cgi?id=33997 llvm-svn: 311601
* Parse and print DIExpressions inline to ease IR and MIR testingReid Kleckner2017-08-232-3/+2
| | | | | | | | | | | | | | | | | | | Summary: Most DIExpressions are empty or very simple. When they are complex, they tend to be unique, so checking them inline is reasonable. This also avoids the need for CodeGen passes to append to the llvm.dbg.mir named md node. See also PR22780, for making DIExpression not be an MDNode. Reviewers: aprantl, dexonsmith, dblaikie Subscribers: qcolombet, javed.absar, eraman, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D37075 llvm-svn: 311594
* [ubsan] PR34266: When sanitizing the 'this' value for a member function that ↵Richard Smith2017-08-231-0/+21
| | | | | | happens to be a lambda call operator, use the lambda's 'this' pointer, not the captured enclosing 'this' pointer (if any). llvm-svn: 311589
* PR19668, PR23034: Fix handling of move constructors and deleted copyRichard Smith2017-08-161-33/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
* PR34163: Don't cache an incorrect key function for a class if queried betweenRichard Smith2017-08-121-0/+13
| | | | | | | | | | | the class becoming complete and its inline methods being parsed. This replaces the hack of using the "late parsed template" flag to track member functions with bodies we've not parsed yet; instead we now use the "will have body" flag, which carries the desired implication that the function declaration *is* a definition, and that we've just not parsed its body yet. llvm-svn: 310776
* Revert "PR19668, PR23034: Fix handling of move constructors and deleted copy ↵Diana Picus2017-08-091-104/+33
| | | | | | | | | constructors when deciding whether classes should be passed indirectly." This reverts commit r310401 because it seems to have broken some ARM bot(s). llvm-svn: 310464
* Attempt #2 to appease buildbotsGeorge Burgess IV2017-08-091-1/+1
| | | | | | | "error: unable to create target: 'No available targets are compatible with this triple.'" llvm-svn: 310445
* Attempt to appease msc buildbotGeorge Burgess IV2017-08-091-1/+1
| | | | | | | | | | | | | It was timing out on this test, but for reasons unrelated to the specific bug it was testing for. Randomly breaking in gdb with `clang -target i686-windows -fmsc-version=1700` reveals *many* frames from MicrosoftCXXNameMangler. So, it would seem that some caching is needed there, as well... Fingers crossed that specifying a triple is sufficient to work around this. llvm-svn: 310444
* [AST] Cache intermediate visibility/linkage resultsGeorge Burgess IV2017-08-091-0/+41
| | | | | | | | | | | | This is a follow-up to r310436 with actual functional changes. Please see that commit message for a description of why a cache is appearing here. Suggestions for less-bad ways of testing this are appreciated. :) This fixes PR29160. llvm-svn: 310437
* Sema: disable implicit conversion from _Complex to real types in C++.Tim Northover2017-08-081-1/+1
| | | | | | | | | | | Converting a _Complex type to a real one simply discards the imaginary part. This can easily lead to loss of information so for safety (and GCC compatibility) this patch disallows that when the conversion would be implicit. The one exception is bool, which actually compares both real and imaginary parts and so is safe. llvm-svn: 310427
* [codeview] Emit nested enums and typedefs from classesReid Kleckner2017-08-081-0/+25
| | | | | | | | | | Previously we limited ourselves to only emitting nested classes, but we need other kinds of types as well. This fixes the Visual Studio STL visualizers, so that users can visualize std::string and other objects. llvm-svn: 310410
* PR19668, PR23034: Fix handling of move constructors and deleted copyRichard Smith2017-08-081-33/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. llvm-svn: 310401
* [codeview] Fix class name formattingReid Kleckner2017-08-081-1/+6
| | | | | | | In particular, removes spaces between template arguments of class templates to better match VS type visualizers. llvm-svn: 310331
* [ubsan] Have -fsanitize=vptr emit a null check if -fsanitize=null isn't ↵Vedant Kumar2017-08-022-7/+12
| | | | | | | | | | | | | | | | | | available In r309007, I made -fsanitize=null a hard prerequisite for -fsanitize=vptr. I did not see the need for the two checks to have separate null checking logic for the same pointer. I expected the two checks to either always be enabled together, or to be mutually compatible. In the mailing list discussion re: r309007 it became clear that that isn't the case. If a codebase is -fsanitize=vptr clean but not -fsanitize=null clean, it's useful to have -fsanitize=vptr emit its own null check. That's what this patch does: with it, -fsanitize=vptr can be used without -fsanitize=null. Differential Revision: https://reviews.llvm.org/D36112 llvm-svn: 309846
* [clang] Change the condition of unnecessary packed warningYan Wang2017-08-011-8/+85
| | | | | | | | | | | | | | | | | | | | Summary: Change the condition of this unnecessary packed warning. The packed is unnecessary when 1. the alignment of the struct/class won't alter. 2. the size is unchanged. 3. the offset of each field is the same. Remove all field-level warning. Reviewers: chh, akyrtzi, rtrieu Reviewed By: chh Subscribers: rsmith, srhines, cfe-commits, xazax.hun Differential Revision: https://reviews.llvm.org/D34114 llvm-svn: 309750
* Re-apply r309622 with a fix for MSVC.Peter Collingbourne2017-07-311-0/+15
| | | | | | Patch by Vlad Tsyrklevich! llvm-svn: 309635
* Revert r309622, "Fix logic for generating llvm.type.test()s"Peter Collingbourne2017-07-311-15/+0
| | | | | | | Caused a bot test failure: http://bb.pgr.jp/builders/test-clang-msc-x64-on-i686-linux-RA/builds/5325 llvm-svn: 309624
* Fix logic for generating llvm.type.test()sPeter Collingbourne2017-07-311-0/+15
| | | | | | | | | | | | | | CodeGenFunction::EmitTypeMetadataCodeForVCall() could output an llvm.assume(llvm.type.test())when CFI was enabled, optimizing out the vcall check. This case was only reached when: 1) CFI-vcall was enabled, 2) -fwhole-program-tables was specified, and 3) -fno-sanitize-trap=cfi-vcall was specified. Patch by Vlad Tsyrklevich! Differential Revision: https://reviews.llvm.org/D36013 llvm-svn: 309622
* Update comment in test case after r309308.Akira Hatanaka2017-07-281-1/+1
| | | | llvm-svn: 309352
* Revert r264998 and r265035.Akira Hatanaka2017-07-271-1/+1
| | | | | | | | | | r303175 made changes to have __cxa_allocate_exception return a 16-byte aligned pointer, so it's no longer necessary to specify a lower alignment (8-bytes) for exception objects on Darwin. rdar://problem/32363695 llvm-svn: 309308
* Add branch weights to branches for static initializers.Richard Smith2017-07-264-6/+135
| | | | | | | | | | | | | | | | | | | The initializer for a static local variable cannot be hot, because it runs at most once per program. That's not quite the same thing as having a low branch probability, but under the assumption that the function is invoked many times, modeling this as a branch probability seems reasonable. For TLS variables, the situation is less clear, since the initialization side of the branch can run multiple times in a program execution, but we still expect initialization to be rare relative to non-initialization uses. It would seem worthwhile to add a PGO counter along this path to make this estimation more accurate in future. For globals with guarded initialization, we don't yet apply any branch weights. Due to our use of COMDATs, the guard will be reached exactly once per DSO, but we have no idea how many DSOs will define the variable. llvm-svn: 309195
* [CodeGen] Correctly model std::byte's aliasing propertiesDavid Majnemer2017-07-251-0/+41
| | | | | | | | | | | | std::byte, when defined as an enum, needs to be given special treatment with regards to its aliasing properties. An array of std::byte is allowed to be used as storage for other types. This fixes PR33916. Differential Revision: https://reviews.llvm.org/D35824 llvm-svn: 309058
* [ubsan] Null-check pointers in -fsanitize=vptr (PR33881)Vedant Kumar2017-07-254-6/+57
| | | | | | | | | | | | | | | | | | | The instrumentation generated by -fsanitize=vptr does not null check a user pointer before loading from it. This causes crashes in the face of UB member calls (this=nullptr), i.e it's causing user programs to crash only after UBSan is turned on. The fix is to make run-time null checking a prerequisite for enabling -fsanitize=vptr, and to then teach UBSan to reuse these run-time null checks to make -fsanitize=vptr safe. Testing: check-clang, check-ubsan, a stage2 ubsan-enabled build Differential Revision: https://reviews.llvm.org/D35735 https://bugs.llvm.org/show_bug.cgi?id=33881 llvm-svn: 309007
* Revert "This patch enables the usage of constant Enum identifiers within ↵Eric Christopher2017-07-251-2/+2
| | | | | | | | Microsoft style inline assembly statements." as it is causing msan failures. This reverts commits r308985 and r308965 llvm-svn: 309004
* This patch enables the usage of constant Enum identifiers within Microsoft ↵Matan Haroush2017-07-251-2/+2
| | | | | | | | | | style inline assembly statements. Differential Revision: https://reviews.llvm.org/D33277 https://reviews.llvm.org/D33278 llvm-svn: 308965
* [CodeGen] Propagate dllexport to thunksShoaib Meenai2017-07-241-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under Windows Itanium, we need to export virtual and non-virtual thunks if the functions being thunked are exported. These thunks would previously inherit their dllexport attribute from the declaration, but r298330 changed declarations to not have dllexport attributes. We therefore need to add the dllexport attribute to the definition ourselves now. This is consistent with MinGW GCC's behavior. This redoes r306770 but limits the logic to Itanium. MicrosoftCXXABI's setThunkLinkage ensures that thunks aren't exported under that ABI, so I'm handling this in ItaniumCXXABI's setThunkLinkage for symmetry. We need to export these thunks because they can be referenced outside the library they're defined in. For example, if a child class without a key function inherits from a parent class with a key function, the parent's thunks will only be defined in the library with the key function, but the construction vtable for the parent in the child might be emitted outside the library (since the child doesn't have a key function), and it needs to reference the parent's thunks. We don't need to mark these thunks as imported since any references to them will occur in data, so the compiler can't generate the IAT load sequence anyway. Instead, we rely on the linker generating import thunks for the thunks. Differential Revision: https://reviews.llvm.org/D34972 llvm-svn: 308899
* Complex Long Double classification In RegCall calling conventionErich Keane2017-07-211-2/+10
| | | | | | | | | | | | | This change is part of the RegCall calling convention support for LLVM. Existing RegCall implementation was extended to include correct handling of Complex Long Double type. Complex long double types should be returned/passed in memory and not register stack. This patch implements this behavior. Patch by: eandrews Differential Revision: https://reviews.llvm.org/D35259 llvm-svn: 308769
* Update for LLVM IR metadata changes (DIImportedEntity now needs a DIFile).Adrian Prantl2017-07-192-6/+6
| | | | | | | | | <rdar://problem/33357889> https://bugs.llvm.org/show_bug.cgi?id=33822 Differential Revision: https://reviews.llvm.org/D35583 llvm-svn: 308399
* CodeGen: Insert addr space cast for automatic/temp var at right positionYaxun Liu2017-07-181-6/+27
| | | | | | | | | | | The uses of alloca may be in different blocks other than the block containing the alloca. Therefore if the alloca addr space is non-zero and it needs to be casted to default address space, the cast needs to be inserted in the same BB as the alloca insted of the current builder insert point since the current insert point may be in a different BB. Differential Revision: https://reviews.llvm.org/D35438 llvm-svn: 308313
* [clang] Remove redundant check-prefix=CHECK from tests. NFC.Mandeep Singh Grang2017-07-171-1/+1
| | | | | | | | | | | | Reviewers: t.p.northover, mstorsjo, rsmith, mcrosier Reviewed By: mstorsjo, mcrosier Subscribers: mcrosier, javed.absar, cfe-commits Differential Revision: https://reviews.llvm.org/D35465 llvm-svn: 308192
* [Sema] Mark a virtual CXXMethodDecl as used if a call to it can beAkira Hatanaka2017-07-132-3/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | devirtualized. The code to detect devirtualized calls is already in IRGen, so move the code to lib/AST and make it a shared utility between Sema and IRGen. This commit fixes a linkage error I was seeing when compiling the following code: $ cat test1.cpp struct Base { virtual void operator()() {} }; template<class T> struct Derived final : Base { void operator()() override {} }; Derived<int> *d; int main() { if (d) (*d)(); return 0; } rdar://problem/33195657 Differential Revision: https://reviews.llvm.org/D34301 llvm-svn: 307883
* Add missing dllimport member pointer template argument test from r307446Reid Kleckner2017-07-111-0/+58
| | | | llvm-svn: 307670
* CodeGen: Fix address space of global variableYaxun Liu2017-07-081-65/+86
| | | | | | | | | | | | | Certain targets (e.g. amdgcn) require global variable to stay in global or constant address space. In C or C++ global variables are emitted in the default (generic) address space. This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace and TargetInfo::getConstantAddressSpace to handle this in a general approach. It only affects IR generated for amdgcn target. Differential Revision: https://reviews.llvm.org/D33842 llvm-svn: 307470
* [AMDGPU] Fix size and alignment of size_t and pointer typesYaxun Liu2017-07-051-4/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D34995 llvm-svn: 307121
* [CodeGen] Check key function for typeinfo importShoaib Meenai2017-07-041-2/+8
| | | | | | | If the imported class does not have a key function, we should emit its typeinfo locally instead of attempting to import it. llvm-svn: 307052
* [MS] Test that deleting destructor thunks are not exportedReid Kleckner2017-06-301-0/+10
| | | | | | The MSVC linker emits the LNK4102 warning if they are. llvm-svn: 306836
* Revert "[CodeGen] Propagate dllexport to thunks"Reid Kleckner2017-06-301-9/+0
| | | | | | This reverts r306770, it causes LNK4102 warnings in MSVC builds. llvm-svn: 306835
OpenPOWER on IntegriCloud