This is a regression from clang 3.4
Set the result to ExprError and returns true, rather than simply
returns false because errors have been reported already and returning
false show a confusing error
llvm-svn: 214734
Summary:
Adding __int128 support explicitly for x86_64 because currently it's on
only when pointer size >= 64 which is not the case for x32.
Test Plan: One of the tests using __int128 is updated
Reviewers: atanasyan, chandlerc
Subscribers: cfe-commits, rob.khasanov, zinovy.nis, dschuff
Differential Revision: http://reviews.llvm.org/D4755
llvm-svn: 214710
Commit r213935 added additional validation of register constants/size for AArch64 and because these tests which contain Intel assembler the new validation caused these tests to fail when the default target is changed to an AArch64 target.
llvm-svn: 214706
CXXNameMangler::mangleUnqualifiedBlock believed that
MangleContext::getBlockId returned something that used Itanium-style
discriminator numbers.
Discriminator numbers start their numberign from 1 and the first
mangling that actually gets any sort of number mangled in is the second
discriminator.
However, Block IDs start from zero. The logic for omitting the mangling
number did a ' > 1' instead of a ' > 0' comparison; this could
potentially cause mangling conflicts.
llvm-svn: 214699
Instead of creating global variables for source locations and global names,
just create metadata nodes and strings. They will be transformed into actual
globals in the instrumentation pass (if necessary). This approach is more
flexible:
1) we don't have to ensure that our custom globals survive all the optimizations
2) if globals are discarded for some reason, we will simply ignore metadata for them
and won't have to erase corresponding globals
3) metadata for source locations can be reused for other purposes: e.g. we may
attach source location metadata to alloca instructions and provide better descriptions
for stack variables in ASan error reports.
No functionality change.
llvm-svn: 214604
Unsurprisingly, changing a file modification time to a specific
date/time doesn't give the same epoch time everywhere. Just make the
file move into the past and look at only the first few digits of the
epoch time.
llvm-svn: 214589
We've added support for a multiple functions with the same name in
LLVM's profile data, so the lookup returning the function hash it
found doesn't make sense anymore. Update to pass in the hash we
expect.
This also adds a test that the version 1 format is still readable,
since the new API is expected to handle that.
llvm-svn: 214586
Build systems tend to traffic in files and modification times, so having
them touch a file at the beginning of the build can be easier than
having them update the compile command they use every time they build.
llvm-svn: 214577
These tests seem like an exception to the rule against assembly emitting
tests in clang. I made an LLVM side change that can only be tested by
setting up the inline assembly machinery that is only implemented by
Clang.
llvm-svn: 214552
It appears that the backend does not handle all cases that were handled by clang.
In particular, it does not handle structs as used in
SingleSource/UnitTests/2003-05-07-VarArgs.
llvm-svn: 214512
Summary:
This patch causes clang to emit va_arg instructions to the backend instead of
expanding them into an implementation itself. The backend already implements
va_arg since this is necessary for NaCl so this patch is removing redundant
code.
Together with the llvm patch (D4556) that accounts for the effect of endianness
on the expansion of va_arg, this fixes PR19612.
Depends on D4556
Reviewers: sstankovic, dsanders
Reviewed By: dsanders
Subscribers: rnk, cfe-commits
Differential Revision: http://reviews.llvm.org/D4742
llvm-svn: 214497
they're somehow missing a body. Looks like this was left behind when the loop
was generalized, and it's not been problematic before because without modules,
a used, implicit special member function declaration must be a definition.
This was resulting in us trying to emit a constructor declaration rather than
a definition, and producing a constructor missing its member initializers.
llvm-svn: 214473
of a function has a resolved exception specification, then all declarations of
the function do.
We should probably improve the AST representation to make this implicit (perhaps
only store the exception specification on the canonical declaration), but this
fixes things for now.
The testcase for this (which used to assert) also exposes the actual bug I was
trying to reduce here: we sometimes fail to emit the body of an imported
special member function definition. Fix for that to follow.
llvm-svn: 214458
This patch is necessary to support constant expressions which replaces the integer value in the loop hint attribute with an expression. The integer value was also storing the pragma’s state for options like vectorize(enable/disable) and the pragma unroll and nounroll directive. The state variable is introduced to hold the state of those options/pragmas. This moves the validation of the state (keywords) from SemaStmtAttr handler to the loop hint annotation token handler.
Resubmit with changes to try to fix the build-bot issue.
Reviewed by Aaron Ballman
llvm-svn: 214432
Updating the diagnostics in the launch_bounds test since they have been improved in that case. Adding a test for nonnull since it has little test coverage, but has truly variadic arguments.
llvm-svn: 214407
Note that it's not clear whether this is the right behavior, please see
the review for the discussion.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4577
llvm-svn: 214401
or a class derived from T. We already supported this when initializing
_Atomic(T) from T for most (and maybe all) other reasonable values of T.
llvm-svn: 214390
Clang forgot that '++s.m' was a bitfield l-value and permit it's address
to be taken; this would crash at CodeGen-time.
Instead, propagate the object-kind when we see the prefix
increment/decrement.
This fixes PR20496.
Differential Revision: http://reviews.llvm.org/D4733
llvm-svn: 214386
This patch is necessary to support constant expressions which replaces the integer value in the loop hint attribute with an expression. The integer value was also storing the pragma’s state for options like vectorize(enable/disable) and the pragma unroll and nounroll directive. The state variable is introduced to hold the state of those options/pragmas. This moves the validation of the state (keywords) from SemaStmtAttr handler to the loop hint annotation token handler.
Reviewed by Aaron Ballman
llvm-svn: 214333
(Dropped the byte and word variants from the patch. Turns out these are not
part of AVX512F but only AVX512BW/VL.)
Part of <rdar://problem/17688758>
llvm-svn: 214314
As defined in the SPIR 1.2 specification, this node behaves similarly to
kernel_arg_type but will print the underlying type name, e.g., without
typedefs.
Example:
typedef unsigned int myunsignedint;
would report:
'myunsignedint' in the kernel_arg_type node
'uint' in the kernel_arg_base_type node
llvm-svn: 214308
a) add SKX support to Clang driver;
b) add tests for SKX target and AVX512BW, AVX512DQ, AVX512VL features into clang driver tests
Patch by Zinovy Nis <zinovy.y.nis@intel.com>
llvm-svn: 214306
This fixes a bug where kernel_arg_type was always changing 'unsigned ' to 'u'
for any parameter type, including non-canonical types.
Example:
typedef unsigned int myunsignedint;
would report:
"myunt"
llvm-svn: 214305
MaterializeTemporaryExpr already contains information about the lifetime
of the temporary; if the lifetime is not the full statement, we do not
want to emit a destructor at the end of the full statement for it.
llvm-svn: 214292
A templated using declaration may be used as a template-template
argument.
Unfortunately, the VS "14" chooses '?' as the sole marker for the
argument. This is problematic because it presupposes the possibility of
using more than one template-aliases as arguments to the same template.
This fixes PR20047.
llvm-svn: 214290
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
r197490 changed the behavior of LIBRARY_PATH to try to match GCC's behavior
for cross compilers and make clang work better on "bare metal" targets.
Unfortunately that change is breaking a number of MacPorts projects because
the LIBRARY_PATH environment variable is being ignored when compiling on a
64-bit host for a 32-bit target. Because the host and target architectures
differ, isCrossCompiling returns true. This does not make sense for Darwin,
where multiple architectures are supported natively via "fat" Mach-O slices
and where development is generally done against SDKs regardless. This patch
fixes the problem by overriding isCrossCompiling to return false for Darwin
toolchains.
llvm-svn: 214208
This broke the following gdb tests:
gdb.base__annota1.exp
gdb.base__consecutive.exp
gdb.python__py-symtab.exp
gdb.reverse__consecutive-precsave.exp
gdb.reverse__consecutive-reverse.exp
I will look into this.
This reverts commit 214162.
llvm-svn: 214163
This allows us to give more precise diagnostics.
Diego kindly tested the impact on debug info size: "The increase on average
debug sizes is 0.1%. The total file size increase is ~0%."
llvm-svn: 214162
The -mstrict-align option was originally added in r167619 as a target-
independent option. It was then changed in r167623 to be implemented with an
ARM-specific backend option, even though the code remained in the
target-independent Clang::ConstructJob function. This means that if you used
the -mstrict-align option with a non-ARM target, you would still get the
-arm-strict-align option getting passed to the backend, which was harmless
but gross. The driver option was then replaced by the GCC-compatible
-m[no-]unaligned-access option (r189175) and modified to work with AArch64
(r208075). However, in the process, the help text for -mstrict-align was
incorrectly changed to show it as only being supported for AArch64. Even worse,
the logic for handling these options together with -mkernel was wrong for
AArch64, where -mkernel does not currently imply strict alignment.
This patch fixes up all of those things. Besides the obvious change to the
option help text, it moves the logic into the ARM and AArch64-specific parts
of the driver, so that the option will be correctly ignored for non-ARM
targets. <rdar://problem/17823697>
llvm-svn: 214148
char-based types from "char" to "signed char". Adjust stdint.h to use
__INTx_TYPE__ directly without prefixing it with signed and to use
__UINTx_TYPE__ for unsigned ones.
The value of __INTx_TYPE__ now matches GCC.
llvm-svn: 214119
The new flag, WantFunctionLikeCasts, covers a subset of the keywords
covered by WantTypeSpecifiers that can be used in casts that look like
function calls, e.g. "return long(5);", while excluding the keywords
like "enum" and "const" that would be included when WantTypeSpecifiers
is true but cannot be used in something that looks like a function call.
llvm-svn: 214109
til::SExpr. This is a large patch, with many small changes to pretty printing
and expression lowering to make the new SExpr representation equivalent in
functionality to the old.
llvm-svn: 214089
While Clang now supports both ELFv1 and ELFv2 ABIs, their use is currently
hard-coded via the target triple: powerpc64-linux is always ELFv1, while
powerpc64le-linux is always ELFv2.
These are of course the most common scenarios, but in principle it is
possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on
little-endian systems (and GCC does support that), and there are some
special use cases for that (e.g. certain Linux kernel versions could
only be built using ELFv1 on LE).
This patch implements the Clang side of supporting this, based on the
LLVM commit 214072. The command line options -mabi=elfv1 or -mabi=elfv2
select the desired ABI if present. (If not, Clang uses the same default
rules as now.)
Specifically, the patch implements the following changes based on the
presence of the -mabi= option:
In the driver:
- Pass the appropiate -target-abi flag to the back-end
- Select the correct dynamic loader version (/lib64/ld64.so.[12])
In the preprocessor:
- Define _CALL_ELF to the appropriate value (1 or 2)
In the compiler back-end:
- Select the correct ABI in TargetInfo.cpp
- Select the desired ABI for LLVM via feature (elfv1/elfv2)
llvm-svn: 214074
lambda expressions (other than their capture initializers) nor blocks. Do walk
into default argument expressions and default initializer expressions.
These bugs were causing us to produce broken CFGs whenever a lambda expression
was used to initialize a libstdc++ std::function object!
llvm-svn: 214050
Parser::ParseDeclarationSpecifiers eagerly updates the source range of
the DeclSpec with the current token position. However, it might not
consume any more tokens.
Fix this by only setting the start of the range, not the end. This way
the SourceRange will be invalid if we don't consume any more tokens.
This fixes PR20413.
Differential Revision: http://reviews.llvm.org/D4646
llvm-svn: 214018
This moves some memptr specific code into the generic thunk emission
codepath.
Fixes PR20053.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D4613
llvm-svn: 214004
llvm revision 210639 renamed the -global-merge backend option to
-enable-global-merge. This change simply updates clang to match that.
Patch by Steven Wu!
llvm-svn: 213993
Previously we were building up the inalloca struct in the usual pattern
of return type followed by arguments. However, on Windows, 'this'
always precedes the 'sret' parameter, so we need to insert it into the
struct first as a special case.
llvm-svn: 213990
The target method of the thunk will perform the cleanup. This can't be
tested in 32-bit x86 yet because passing something by value would create
an inalloca, and we refuse to generate broken code for that.
llvm-svn: 213976
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
Summary:
This pragma is very rare. We could *hypothetically* lower some uses of
it down to @llvm.global_ctors, but given that GlobalOpt isn't able to
optimize prioritized global ctors today, there's really no point.
If we wanted to do this in the future, I would check if the section used
in the pragma started with ".CRT$XC" and had up to two characters after
it. Those two characters could form the 16-bit initialization priority
that we support in @llvm.global_ctors. We would have to teach LLVM to
lower prioritized global ctors on COFF as well.
This should let us compile some silly uses of this pragma in WebKit /
Blink.
Reviewers: rsmith, majnemer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4549
llvm-svn: 213593
Both /showIncludes and /E write to stdout. Allowing both results
in interleaved output and an error when double-closing the file
descriptor, intended to catch issues like this.
llvm-svn: 213589
Olivier Goffart