The `-Wpadded` diagnostics are usually very noisy and generally not
helpful. However, reporting padding that was introduced in bit-fields is
rather helpful. For example, yesterday in SerenityOS's discord we had
very unpleasant experience of debugging Windows portability issue, and
its root cause was that under `x86_64-pc-windows-msvc` a padding was
introduced for one of the bit-fields.
So, this PR separates bit-field-related padding diagnostics into a new
`-Wpadded-bitfield`. The diagnostic group is also enabled by `-Wpadded`
for compatibility reasons.
This implements the [[msvc::no_unique_address]] attribute.
There is not ABI compatibility in this patch because the attribute is
relatively new and there's still some uncertainty in the MSVC version.
The recommit changes the attribute definitions so that instead of making
two separate attributes for no_unique_address
and msvc::no_unique_address, it modifies the attributes tablegen emitter
to allow spellings to be target-specific.
This reverts commit 71f9e7695b87298f9855d8890f0e6a3b89381eb5.
This reverts commit 4a55d426967b9c70f5dea7b3a389e11393a4f4c4.
Reverting because this breaks sphinx documentation, and even with it
fixed the format of the attribute makes the no_unique_address
documentation show up twice.
This assertion triggered when we have two base classes sharing the same offset
and the first base is empty and the second class is non-empty.
Remove it for correctness.
I can't add a test case for this because -foverride-record-layout doesn't read
base class info at all. I can add that support later for testing if needed.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D152472
The packed attribute can still be useful in this case if the struct is
then placed inside another packed struct - the non-pod element type's
packed attribute declares that it's OK to misalign this element inside
the packed structure. (otherwise the non-pod element is not packed/its
alignment is preserved, as per D117616/2771233)
Fixes PR62353
Differential Revision: https://reviews.llvm.org/D149182
RecordLayoutBuilder assumes the size of a potentially-overlapping
class/struct field with non-zero size as the size of the base subobject
type corresponding to the field type.
Make CGRecordLayoutBuilder to acknowledge that in order to avoid incorrect
padding insertion.
Differential Revision: https://reviews.llvm.org/D139741
There is already a GCC compatibility gap on AIX, & GCC compatibility is
not a concern on z/OS. GCC compatibility is not sufficient motivation
for breaking ABI on AIX and z/OS. This opts out of changes introduced in
https://reviews.llvm.org/D119051. For AIX only, also opt out of D117616
(which z/OS had picked up at the time ABI stabilization occurred).
Differential Revision: https://reviews.llvm.org/D142358
Allow completing a redeclaration check for anonymous structs/unions
inside `RecordDecl`, so we deserialize and compare anonymous entities
from different modules.
Completing the redeclaration chain for `RecordDecl` in
`ASTContext::getASTRecordLayout` mimics the behavior in
`CXXRecordDecl::dataPtr`. Instead of completing the redeclaration chain
every time we request a definition, do that right before we need a
complete definition in `ASTContext::getASTRecordLayout`.
Such code is required only for anonymous `RecordDecl` because we
deserialize named decls when we look them up by name. But it doesn't
work for anonymous decls as they don't have a name. That's why need to
force deserialization of anonymous decls in a different way.
rdar://81864186
Differential Revision: https://reviews.llvm.org/D140055
This reverts commit 731abdfdcc33d813e6c3b4b89eff307aa5c18083.
This commit breaks some tests in libcxx, e.g.
`std/utilities/expected/expected.expected/ctor/ctor.inplace.pass.cpp`
RecordLayoutBuilder assumes the size of a potentially-overlapping field
with non-zero size as the size of the base subobject type corresponding
to the field type.
Make CGRecordLayoutBuilder to acknowledge that in order to avoid incorrect
padding insertion.
Differential Revision: https://reviews.llvm.org/D139741
Mixing LLVM and Clang address spaces can result in subtle bugs, and there
is no need for this hook to use the LLVM IR level address spaces.
Most of this change is just replacing zero with LangAS::Default,
but it also allows us to remove a few calls to getTargetAddressSpace().
This also removes a stale comment+workaround in
CGDebugInfo::CreatePointerLikeType(): ASTContext::getTypeSize() does
return the expected size for ReferenceType (and handles address spaces).
Differential Revision: https://reviews.llvm.org/D138295
Seems there's a narrow case - where a packed type doesn't pack its base
subobjects (only fields), but when packing a field of the derived type,
GCC does pack the resulting total object - effectively packing the base
subobject.
So ensure that this non-pod type (owing to it having a base class) that
is packed, gets packed when placed in /another/ type that is also
packed.
This is a (smallish?) ABI fix to a regression introduced by D117616 -
but that regression/ABI break hasn't been released in LLVM as-yet (it's
been reverted on the release branch from the last two LLVM releases - I
probably should've just reverted the whole patch while we hashed out
this and other issues) so this change isn't itself an ABI break, as far
as LLVM releases are concerned (for folks releasing their own copies of
LLVM from ToT/without the LLVM release branch, and didn't opt into the
clang-abi-compat 14 or below (soon to be 15 or below, I guess I should
say) then this would be an ABI break against clang from the last 9
months or so)
Differential Revision: https://reviews.llvm.org/D135916
Since this didn't make it into the v14 release - anyone requesting the
v14 ABI shouldn't get this GCC-compatible change that isn't backwards
compatible with v14 Clang.
Differential Revision: https://reviews.llvm.org/D126334
Under the hood this prints the same as `QualType::getAsString()` but cuts out the middle-man when that string is sent to another raw_ostream.
Also cleaned up all the call sites where this occurs.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D123926
This matches GCC: https://godbolt.org/z/sM5q95PGY
I realize this is an API break for clang+clang - so I'm totally open to
discussing how we should deal with that. If Apple wants to keep the
Clang layout indefinitely, if we want to put a flag on this so non-Apple
folks can opt out of this fix/new behavior.
Differential Revision: https://reviews.llvm.org/D117616
Added warning for potential cases of
unaligned access when option
-mno-unaligned-access has been specified
Differential Revision: https://reviews.llvm.org/D116221
When have ObjCInterfaceDecl with the same name in 2 different modules,
hitting the assertion
> Assertion failed: (Index < RL->getFieldCount() && "Ivar is not inside record layout!"),
> function lookupFieldBitOffset, file llvm-project/clang/lib/AST/RecordLayoutBuilder.cpp, line 3434.
on accessing an ivar inside a method. The assertion happens because
ivar belongs to one module while its containing interface belongs to
another module and then we fail to find the ivar inside the containing
interface. We already keep a single ObjCInterfaceDecl definition in
redecleration chain and in this case containing interface was correct.
The issue is with ObjCIvarDecl. IVar decl for IRGen is taken from
ObjCIvarRefExpr that is created in `Sema::BuildIvarRefExpr` using ivar
decl returned from `Sema::LookupIvarInObjCMethod`. And ivar lookup
returns a wrong decl because basically we take the first ObjCIvarDecl
found in `ASTReader::FindExternalVisibleDeclsByName` (called by
`DeclContext::lookup`). And in `ASTReader.Lookups` lookup table for a
wrong module comes first because `ASTReader::finishPendingActions`
processes `PendingUpdateRecords` in reverse order and the first
encountered ObjCIvarDecl will end up the last in `ASTReader.Lookups`.
Fix by merging ObjCIvarDecl from different modules correctly and by
using a canonical one in IRGen.
rdar://82854574
Differential Revision: https://reviews.llvm.org/D110280
The "aligned" attribute can only increase the alignment of a struct, or struct member, unless it's used together with the "packed" attribute, or used as a part of a typedef, in which case, the "aligned" attribute can both increase and decrease alignment.
That said, we expect:
1. "aligned" attribute alone: does not interfere with the alignment upgrade instrumented by the AIX "power" alignment rule,
2. "aligned" attribute + typedef: overrides any computed alignment,
3. "aligned" attribute + "packed" attribute: overrides any computed alignment.
The old implementation achieved 2 and 3, but didn't get 1 right, in that any field marked attribute "aligned" would not go through the alignment upgrade.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D107394
Extend the information preserved in `TypeInfo` by replacing the `AlignIsRequired` bool flag with a three-valued enum, the enum also indicates where the alignment attribute come from, which could be helpful in determining whether the attribute should overrule.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D108858
Zero-width bitfields on AIX pad out to the natral alignment boundary but
do not change the containing records alignment.
Differential Revision: https://reviews.llvm.org/D106900
On AIX when there is a pragma pack, or pragma align in effect then zero-width bitfields should pad out to the end of the bitfield container but not increase the alignment requirements of the struct greater then the max field align.
Reviewed By: ZarkoCA
Differential Revision: https://reviews.llvm.org/D105635
This option implies -fdump-record-layouts but dumps record layout information with canonical field types, which can be more useful in certain cases when comparing structure layouts.
Reviewed By: stevewan
Differential Revision: https://reviews.llvm.org/D105112
1.[bool, char, short] bitfields have the same alignment as unsigned int
2.Adjust alignment on typedef field decls/honor align attribute
3.Fix alignment for scoped enum class
4.Long long bitfield has 4bytes alignment and StorageUnitSize under 32 bit
compile mode
Differential Revision: https://reviews.llvm.org/D87029
The existing Windows Itanium patches for dllimport/export
behaviour w.r.t vtables/rtti can't be adopted for PS4 due to
backwards compatibility reasons (see comments on
https://reviews.llvm.org/D90299).
This commit adds our PS4 scheme for this to Clang.
Differential Revision: https://reviews.llvm.org/D93203
Zero length bitfield alignment is not respected if they are leading members on z/OS target.
Reviewed By: abhina.sreeskantharajan
Differential Revision: https://reviews.llvm.org/D98890
Followup to D85191.
This changes getTypeInfoInChars to return a TypeInfoChars
struct instead of a std::pair of CharUnits. This lets the
interface match getTypeInfo more closely.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D86447
On some targets like AIX, last bitfield size is not always equal to last
bitfield type size. Some bitfield like bool will have the same alignment
as [unsigned]. So we'd like to use a more general term `StorageUnit` to
replace type in this field.
Differential Revision: https://reviews.llvm.org/D88260
In D79719, LayoutField was refactored to fetch the size of field
types in bits and then convert to chars, rather than fetching
them in chars directly. This is not ideal, since it makes the
calculations char size dependent, and breaks for sizes that
are not a multiple of the char size.
This patch changes it to use getTypeInfoInChars instead of
getTypeInfo.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D85191
Implement AIX default `power` alignment rule by adding `PreferredAlignment` and
`PreferredNVAlignment` in ASTRecordLayout class.
The patchh aims at returning correct value for `__alignof(x)` and `alignof(x)`
under `power` alignment rules.
Differential Revision: https://reviews.llvm.org/D79719
Currently the ItaniumRecordLayoutBuilder when laying out base classes has the virtual
and non-virtual bases mixed up when pulling the base class layouts from the external source.
This came up in an LLDB bug where on arm64 because of differences in how it deals with
tail padding would layout the bases differently without the correct layout from the
external source (LLDB). This would result in some fields being off by 4 bytes.
Differential Revision: https://reviews.llvm.org/D83008
