The patch ensures that a new storage unit is created when the new bitfield's
size is wider than the available bits.
rdar://36343145
Differential Revision: https://reviews.llvm.org/D42660
llvm-svn: 323921
Summary:
Convert clang::LangAS to a strongly typed enum
Currently both clang AST address spaces and target specific address spaces
are represented as unsigned which can lead to subtle errors if the wrong
type is passed. It is especially confusing in the CodeGen files as it is
not possible to see what kind of address space should be passed to a
function without looking at the implementation.
I originally made this change for our LLVM fork for the CHERI architecture
where we make extensive use of address spaces to differentiate between
capabilities and pointers. When merging the upstream changes I usually
run into some test failures or runtime crashes because the wrong kind of
address space is passed to a function. By converting the LangAS enum to a
C++11 we can catch these errors at compile time. Additionally, it is now
obvious from the function signature which kind of address space it expects.
I found the following errors while writing this patch:
- ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address
space to TargetInfo::getPointer{Width,Align}()
- TypePrinter::printAttributedAfter() prints the numeric value of the
clang AST address space instead of the target address space.
However, this code is not used so I kept the current behaviour
- initializeForBlockHeader() in CGBlocks.cpp was passing
LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}()
- CodeGenFunction::EmitBlockLiteral() was passing a AST address space to
TargetInfo::getPointerWidth()
- CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space
to Qualifiers::addAddressSpace()
- CGOpenMPRuntimeNVPTX::getParameterAddress() was using
llvm::Type::getPointerTo() with a AST address space
- clang_getAddressSpace() returns either a LangAS or a target address
space. As this is exposed to C I have kept the current behaviour and
added a comment stating that it is probably not correct.
Other than this the patch should not cause any functional changes.
Reviewers: yaxunl, pcc, bader
Reviewed By: yaxunl, bader
Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D38816
llvm-svn: 315871
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
According to the documentation, when encoding a bit-field, GNU runtime
needs its starting position in addition to its type and size.
https://gcc.gnu.org/onlinedocs/gcc/Type-encoding.html
Prior to r297702, the starting position information was not being
encoded, which is incorrect, and after r297702, an assertion started to
fail because an ObjCIvarDecl was being passed to a function expecting a
FieldDecl.
This commit moves LookupFieldBitOffset to ASTContext and uses the
function to encode the starting position of bit-fields.
llvm-svn: 306364
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
"aligned", by Vladimir Yakovlev
Fix clang/gcc incompatibility of bitfields layout in the presence of
pragma packed and attributes aligned and packed.
Differential Revision: http://reviews.llvm.org/D17023
llvm-svn: 261321
C++ emits vtables for classes that have key function present in the
current TU. While we compile CUDA the fact that key function was found
in this TU does not mean that we are going to generate code for it. E.g.
vtable for a class with host-only methods should not (and can not) be
generated on device side, because we'll never generate code for them
during device-side compilation.
This patch adds an extra CUDA-specific check during key method computation
and filters out potential key methods that are not suitable for this side
of CUDA compilation.
When we codegen vtable, entries for unsuitable methods are set to null.
Differential Revision: http://reviews.llvm.org/D15309
llvm-svn: 255911
This was already being done when injecting the VBPtr, but not
when injecting the VFPtr. This fixes a number of tests in LLDB's
test suite.
Reviewed by: David Majnemer
Differential Revision: http://reviews.llvm.org/D13276
llvm-svn: 249085
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
Summary:
The vtable takes its DLL storage class from the class, not the key
function. When they disagree, the vtable won't be exported by the DLL
that defines the key function. The easiest way to ensure that importers
of the class emit their own vtable is to say that the class has no key
function.
Reviewers: hans, majnemer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11913
llvm-svn: 244488
RecordLayoutBuilder is an inaccruate name because it does not build all
records. It only builds layouts for targets using the Itanium C++ ABI.
llvm-svn: 243225
MSVC 2015 appears to be unable to find the correct operator== here. I
haven't yet filed a bug with Microsoft as I've been unable to create a
reduced test case.
llvm-svn: 237862
It broke test/PCH/headersearch.cpp because it was using -Wpadding, which
only works for Itanium layout. Before this commit, we would use Itanium
record layout when using PCH, which is crazy. Now that the test uses an
explicit Itanium triple, we can reland.
llvm-svn: 230525
Covered by existing tests in test/CodeGen/override-layout.c and
test/CodeGenCXX/override-layout.cpp. Seriously, they found real bugs in
my code. :)
llvm-svn: 230446
Summary:
We should avoid a tail padding not only if the last field
has zero size but also if the last field is a struct with a flexible array.
If/when http://reviews.llvm.org/D5478 is committed,
this will also handle the case of structs with zero-sized arrays.
Reviewers: majnemer, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5924
llvm-svn: 220708
Summary:
The general approach is to add extra paddings after every field
in AST/RecordLayoutBuilder.cpp, then add code to CTORs/DTORs that poisons the paddings
(CodeGen/CGClass.cpp).
Everything is done under the flag -fsanitize-address-field-padding.
The blacklist file (-fsanitize-blacklist) allows to avoid the transformation
for given classes or source files.
See also https://code.google.com/p/address-sanitizer/wiki/IntraObjectOverflow
Test Plan: run SPEC2006 and some of the Chromium tests with -fsanitize-address-field-padding
Reviewers: samsonov, rnk, rsmith
Reviewed By: rsmith
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D5687
llvm-svn: 219961
Empty records do not always have size equivalent to their alignment.
They only do so when their alignment is at least as large as the minimum
empty struct size: 1 byte in C++ and 4 bytes in C.
llvm-svn: 218661
Usually, overriding a virtual function defined in a virtual base
required emission of a vtordisp slot in the record. However no vtordisp
is needed if the overriding function is pure; it should be impossible to
observe the pure virtual method.
This fixes PR21046.
llvm-svn: 218340
The MS ABI has a notion of 'required alignment' for fields; this
alignment supercedes pragma pack directives.
MSVC takes into account alignment attributes on typedefs when
determining whether or not a field has a certain required alignment.
Do the same in clang by tracking whether or not we saw such an attribute
when calculating the type's bitwidth and alignment.
This fixes PR20418.
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D4714
llvm-svn: 214274
We would correctly insert sufficiently aligned padding between vbases
when our leading base was empty, however we would neglect to increase
the required alignment of the most derived class.
This fixes PR20315.
llvm-svn: 213123
No functionality changed, just some cleanups:
- Switch some loops to range-based for.
- Name some iterators with a more creative name than "I".
- Reduce dependence on auto. Does RD->bases() give you a list of
CXXBaseSpecifiers or CXXRecordDecls? It's more clear to just say which
upfront.
llvm-svn: 213121
Previously, it was believed that #pragma vtordisp(0) would prohibit the
generation of any and all vtordisps.
In actuality, it only disables the generation of additional vtordisps.
This fixes PR19413.
llvm-svn: 206124
Alex Lorenz