CL's /Zp flag is analogous to GCC's -fpack-struct, it controls the
default maximum alignment of records.
Differential Revision: http://reviews.llvm.org/D4671
llvm-svn: 213958
Specifically the part where we removed a warning to be compatible with GCC, which has been widely regarded as a bad idea.
I'm not quite happy with how obtuse this warning is, especially in the fairly common case of a 32-bit integer literal, so I've got another patch awaiting review that adds a fixit to reduce confusion.
llvm-svn: 213935
* Track override set across module load and save
* Track originating module to allow proper re-export of #undef
* Make override set properly transitive when it picks up a #undef
This fixes nearly all of the remaining macro issues with self-host.
llvm-svn: 213922
Summary:
This patch extends the __asm parser to make it keep parsing input tokens
as inline assembly if a single-line __asm line is followed by another line
starting with __asm too. It also makes sure that we correctly keep
matching braces in such situations by separating the notions of how many
braces we are matching and whether we are in single-line asm block mode.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4598
llvm-svn: 213916
it through the normal TreeTransform logic for Exprs (which will strip off
implicit parts of the initialization and never re-create them).
llvm-svn: 213913
Current versions of ld64 can't cope with "aarch64" being stored. I'm fixing
that, but in the transitionary period we'll need to still emit "arm64".
rdar://problem/17783765
llvm-svn: 213852
While -fno-rtti-data would correctly avoid referencing the RTTI complete
object locator in the VFTable itself, it would emit them anyway.
llvm-svn: 213841
The class seems to have an invariant that Entries is non-empty if
Invalid is false. It appears this method was previously private, and
all internal uses checked Invalid. Now there is an external caller, so
check Invalid to avoid array OOB underflow.
Fixes PR20420.
llvm-svn: 213816
This flag specifies that we are building an implementation file of the
module <name>, preventing importing <name> as a module. This does not
consider this to be the 'current module' for the purposes of doing
modular checks like decluse or non-modular-include warnings, unlike
-fmodule-name.
This is needed as a stopgap until:
1) we can resolve relative includes to a VFS-mapped module (or can
safely import a header textually and as part of a module)
and ideally
2) we can safely do incremental rebuilding when implementation files
import submodules.
llvm-svn: 213767
arm64_be doesn't really exist; it was useful for testing while AArch64 and
ARM64 were separate, but now the only real way to refer to the system is
aarch64_be.
llvm-svn: 213747
The main subtlety here is that the Darwin tools still need to be given "-arch
arm64" rather than "-arch aarch64". Fortunately this already goes via a custom
function to handle weird edge-cases in other architectures, and it tested.
I removed a few arm64_be tests because that really isn't an interesting thing
to worry about. No-one using big-endian is also referring to the target as
arm64 (at least as far as toolchains go). Mostly they date from when arm64 was
a separate target and we *did* need a parallel name simply to test it at all.
Now aarch64_be is sufficient.
llvm-svn: 213744
This tweaks the diagnostic wording slighly, and adds a fixit on a note.
An alternative would be to add the fixit directly on the diagnostic, see
the review thread linked to from the bug for a few notes on that approach.
llvm-svn: 213725
being declared, not at the end. When pretty-printing a non-type template
parameter, put the name of the parameter in the middle of the type, not at the
end.
llvm-svn: 213718
Windows ARM indicates __va_start as a variadic function. However, the function
itself is treated as having 4 formal arguments:
- (out) pointer to the va_list
- (in) address of the last named argument
- (in) slot size for the type of the last argument
- address of the last named argument
The last argument does not seem to have any bearing on codegen, and thus is not
explicitly type checked at this point.
Unlike the previous handling for __va_start, it does not currently validate if
the parameter is the last named parameter (it seems that MSVC currently accepts
this).
llvm-svn: 213595
If function parameters have default values, and that of the second
parameter is parsed with errors, function declaration would have
a parameter without default value that follows a parameter with
that. Such declaration breaks logic of selecting overloaded
function. As a solution, put opaque object as default value in such case.
This patch fixes PR20055.
Differential Revision: http://reviews.llvm.org/D4378
llvm-svn: 213594
David Majnemer