Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-06-20T20:44:45+00:00 2019-06-20T20:44:45+00:00 Richard Smith richard-llvm@metafoo.co.uk 2019-06-20T20:44:45+00:00 urn:sha1:78b239ea67cf248a5c04031050c32f707f127a9d Summary: Add support for the C++2a [[no_unique_address]] attribute for targets using the Itanium C++ ABI. This depends on D63371. Reviewers: rjmccall, aaron.ballman Subscribers: dschuff, aheejin, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63451 llvm-svn: 363976 2018-07-04T11:21:44+00:00 Gabor Buella gabor.buella@intel.com 2018-07-04T11:21:44+00:00 urn:sha1:ace7da1b11be1a9213c8b5c59d73d9a0561a16a7 llvm-svn: 336262 2018-05-21T14:28:43+00:00 Momchil Velikov momchil.velikov@arm.com 2018-05-21T14:28:43+00:00 urn:sha1:fe76b36ab1286a1248e7a302dcca4245e91714ad Handle attributes before checking the record layout (e.g. underalignment check during `alignas` processing), as layout may be cached without taking into account attributes that may affect it. Differential Revision: https://reviews.llvm.org/D46439 llvm-svn: 332843 2018-05-07T06:43:30+00:00 Richard Smith richard-llvm@metafoo.co.uk 2018-05-07T06:43:30+00:00 urn:sha1:b5a317fbf67a711f5cebad6b5c21324be103fa6c This implements the rule intended by the standard (see LWG 2358) and the rule intended by the Itanium C++ ABI (see https://github.com/itanium-cxx-abi/cxx-abi/pull/51), and makes Clang match the behavior of GCC, ICC, and MSVC. A pedantic reading of both the standard and the ABI indicate that Clang is currently technically correct, but that's not worth much when it's clear that the wording is wrong in both those places. This is an ABI break for classes that derive from a class that is empty other than one or more unnamed non-zero-length bit-fields. Such cases are expected to be rare, but -fclang-abi-compat=6 restores the old behavior just in case. Differential Revision: https://reviews.llvm.org/D45174 llvm-svn: 331620 2018-04-05T18:55:37+00:00 Richard Smith richard-llvm@metafoo.co.uk 2018-04-05T18:55:37+00:00 urn:sha1:b6070db0d0849481c6cd6cd9263530cbbb97b140 layout" rules. The new rules say that a standard-layout struct has its first non-static data member and all base classes at offset 0, and consider a class to not be standard-layout if that would result in multiple subobjects of a single type having the same address. We track "is C++11 standard-layout class" separately from "is standard-layout class" so that the ABIs that need this information can still use it. Differential Revision: https://reviews.llvm.org/D45176 llvm-svn: 329332 2017-03-10T15:04:58+00:00 Alex Lorenz arphaman@gmail.com 2017-03-10T15:04:58+00:00 urn:sha1:76377dcf99ddf628cdcd45833c839596e29e17f2 Printing typedefs or type aliases using clang_getTypeSpelling() is missing the namespace they are defined in. This is in contrast to other types that always yield the full typename including namespaces. Patch by Michael Reiher! Differential Revision: https://reviews.llvm.org/D29944 llvm-svn: 297465 2016-05-23T17:16:12+00:00 David Majnemer david.majnemer@gmail.com 2016-05-23T17:16:12+00:00 urn:sha1:cd3ebfe293d02e18397356daa21517e0fa06c32a The layout_version attribute is pretty straightforward: use the layout rules from version XYZ of MSVC when used like struct __declspec(layout_version(XYZ)) S {}; The empty_bases attribute is more interesting. It tries to get the C++ empty base optimization to fire more often by tweaking the MSVC ABI rules in subtle ways: 1. Disable the leading and trailing zero-sized object flags if a class is marked __declspec(empty_bases) and is empty. This means that given: struct __declspec(empty_bases) A {}; struct __declspec(empty_bases) B {}; struct C : A, B {}; 'C' will have size 1 and nvsize 0 despite not being annotated __declspec(empty_bases). 2. When laying out virtual or non-virtual bases, disable the injection of padding between classes if the most derived class is marked __declspec(empty_bases). This means that given: struct A {}; struct B {}; struct __declspec(empty_bases) C : A, B {}; 'C' will have size 1 and nvsize 0. 3. When calculating the offset of a non-virtual base, choose offset zero if the most derived class is marked __declspec(empty_bases) and the base is empty _and_ has an nvsize of 0. Because of the ABI rules, this does not mean that empty bases reliably get placed at offset 0! For example: struct A {}; struct B {}; struct __declspec(empty_bases) C : A, B { virtual ~C(); }; 'C' will be pointer sized to account for the vfptr at offset 0. 'A' and 'B' will _not_ be at offset 0 despite being empty! Instead, they will be located right after the vfptr. This occurs due to the interaction betweeen non-virtual base layout and virtual function pointer injection: injection occurs after the nv-bases and shifts them down by the size of a pointer. llvm-svn: 270457 2015-11-20T07:02:57+00:00 Alexey Bataev a.bataev@hotmail.com 2015-11-20T07:02:57+00:00 urn:sha1:3d42f340cd44edf7a79ee2d58e68251a4318a081 This patch adds support of #pragma vtordisp inside functions in attempt to improve compatibility. Microsoft compiler appears to save the stack of vtordisp modes on entry of struct methods' bodies and restore it on exit (method-local vtordisp). Differential Revision: http://reviews.llvm.org/D14467 llvm-svn: 253650 2015-10-22T18:04:22+00:00 David Majnemer david.majnemer@gmail.com 2015-10-22T18:04:22+00:00 urn:sha1:78945d0721ea631bfb4535ea36058567a07a6991 We got this right for Itanium but not MSVC because CGRecordLayoutBuilder was checking if the base's size was zero when it should have been checking the non-virtual size. This fixes PR21040. llvm-svn: 251036 2015-08-19T22:42:36+00:00 John McCall rjmccall@apple.com 2015-08-19T22:42:36+00:00 urn:sha1:0d461693b6c7944119d6384d3a38d6c675815317 alignment is ignored, and they always allocate a complete storage unit. Also, change the dumping of AST record layouts: use the more readable C++-style dumping even in C, include bitfield offset information in the dump, and don't print sizeof/alignof information for fields of record type, since we don't do so for bases or other kinds of field. rdar://22275433 llvm-svn: 245514